[10:06] <neXyon> awesome: http://pastebin.com/Nf8JBdvq :-(
[10:12] <vila> neXyon: shot in the dark: do you have a working tree with at least one revision here (as opposed to a just-created-never-committed one) ?
[10:12] <fullermd> That sounds familiar.
[10:13] <neXyon> vila: I just did a bzr branch, that's the cause?
[10:13] <fullermd> Though hazy enough that whatever it's reminding me of is well before 2.5...
[10:13] <vila> neXyon: what does 'bzr revno' says ? And 'bzr info' ?
[10:13] <fullermd> Is there a working tree there?
[10:15] <neXyon> I deleted the directory and branching again atm, will tell you then
[10:16] <vila> I suspect (as fullermd) that you have a branch with no working tree (i.e. the directory contains only a '.bzr' dir)
[10:17] <fullermd> Great minds think alike.
[10:17] <fullermd> And vila gets lucky sometimes, too.
[10:17] <vila> . o O (Glad I re-read his remark until I realized he meant *no* wt there )
[10:19] <neXyon> vila: yes true, only a .bzr dir
[10:19] <fullermd> On the one hand, it might point at the error.  Though, on the other, the command being run seems like something that might be embedded in a build script, not something you'd just come up with manually.
[10:21] <vila> so, first of all, this is a bug, at the very least a friendly error message should be displayed, not a traceback, so please file it at http://pad.lv/fb/bzr
[10:22] <vila> neXyon: now, what's your use case ?
[10:23] <neXyon> vila: I just did as http://doc.bazaar.canonical.com/latest/en/mini-tutorial/#creating-your-own-copy-of-another-branch told me to
[10:23] <vila> neXyon: and then, a workaround would be to do 'bzr checkout .' to create a working tree there
[10:23] <neXyon> vila: bzr init-repo stellarium; bzr branch lp:stellarium stellarium
[10:23] <vila> err, are you sure you didn't do 'bzr init-repo --no-trees' ?
[10:24] <vila> and my question is: why do you run 'bzr version-info' ?
[10:24] <neXyon> vila: the zsh does
[10:24] <vila> eeerk
[10:25] <neXyon> and no, I didn't add any --no-trees :D
[10:25] <vila> who told it to do that ? ;)
[10:25]  * vila scratches head
[10:25] <neXyon> the grml zsh configuration :D
[10:25] <fullermd> I never trust something with that few vowels.
[10:25] <vila> bzr branch creates a working tree by default
[10:25] <neXyon> so why didn't do it in this case?
[10:25] <neXyon> +it
[10:26] <vila> hehe, *you* tell me :)
[10:26] <vila> bzr alias ?
[10:26] <neXyon> how could I? xD
[10:26] <vila> neXyon: :)
[10:26] <vila> because it's probably caused by some setting on your side
[10:27] <vila> and my crystal ball is currently being checked in this place I cannot name
[10:27] <neXyon> nah, I have no alias for it and I also didn't change any bzr configuration
[10:28] <vila> so, back to previous question: 'bzr info -v' ?
[10:29] <neXyon> ah, sure
[10:29] <neXyon> vila: http://pastebin.com/03ddtbQE
[10:30] <vila> 'brz config' ?
[10:32] <neXyon> vila: nothing special there: http://pastebin.com/RPADTTY0
[10:33] <neXyon> Name Mail and IRCnick got changed by me before pasting ;)
[10:35] <vila> ls -lR .bzr
[10:37] <neXyon> vila: http://pastebin.com/wsKuASVA
[10:38] <vila> puzzling...
[10:38] <vila> so, there is indeed no working tree, get one with 'bzr  checkout .'
[10:39] <neXyon> yeah, that might fix it, but what about the bug that it isn't there as it should be? :D
[10:39] <vila> I don't understand how this can happen :-/ Try looking into in ~/.bzr.log ?
[10:39] <vila> s/ in / /
[10:39] <vila> gotta go soon
[10:41] <neXyon> vila: nothing special there
[10:41] <neXyon> the checkout however fixed it
[10:42] <vila> it should have happened at 'bzr branch' time, everybody is relying on it :)
[10:42] <vila> I know of only two ways to avoid it: 'bzr init-repo --no-trees' and 'bzr branch --no-tree'
[10:43] <vila> and your 'ls -lR' says you didn't use 'bzr init-repo --no-trees'...
[10:43] <fullermd> Once upon a time, --no-trees was the default for init-repo.  But that was a _long_ time ago.
[10:44] <vila> fullermd: and is reflected by a 'no_working_trees' file under .bzr/repository
[10:44] <fullermd> To be sure, it is a _little_ odd to make a shared repo, then have one branch in the root of it...
[10:44] <neXyon> vila: yes the log tells I didn't do it too
[10:45] <neXyon> fullermd: so what's the expected way to start developing on a launchpad project?
[10:45] <neXyon> fullermd: if it's not "bzr init-repo stellarium; bzr branch lp:stellarium stellarium"?
[10:45] <vila> it *is*, that's why it's puzzling, that's what everybody does :)
[10:46] <neXyon> xD
[10:46]  * fullermd peers at vila.
[10:46] <fullermd> Nobody I've ever met...
[10:46] <neXyon> fullermd: it's not? what else?
[10:46] <fullermd> (although, meeting other bzr users would require that I leave my cave in the first place, but still...)
[10:47] <fullermd> Generally, you'd have a branch in its own dir under the repo, not colocated with the repo root.  Otherwise, where would you put the second branch that would share space and make the shared repo be pointful anyway?
[10:47] <fullermd> But it's not something that should _break_ anything.  I think.
[10:48] <fullermd> Oh ho.  Back up.
[10:48] <fullermd> Yes, it is.
[10:48] <vila> eeerk, 'bzr init-repo xxx; *cd* xxx ; bzr branch lp:xx yyy'
[10:48] <fullermd> I can reproduce it.  If I bzr init-repo something, then bzr branch $SRC something, I wind up with a treeless branch.
[10:48] <fullermd> (lp: having nothing to do with it)
[10:49] <fullermd> So it's a behavioral oddity when the bzrdir exists.
[10:49] <vila> neXyon: you need to *CD* into the repo before branching
[10:50]  * vila nods @ fullermd, that's another bug (unless there is a rationale for it (doubtly))
[10:50] <vila> could also be a fallout from an unrelated fix
[10:50] <fullermd> It's probably a 2nd or 3rd order consequence of some other sensible behavior that nobody ever ran into.
[10:50] <neXyon> hah, so we found the bug :D
[10:51] <fullermd> Man, we should write some more wrong docs; think of all the extra bugs we could find!
[10:51] <vila> neXyon: roughly, you create a shared repo if you intend to create several branches (so they will share their revisions)
[10:51] <mgrandi> this seems like the weird thing i had if you try to make a branch a shared repo
[10:51] <vila> if you want a single branch, no need for a shared repo
[10:51] <mgrandi> you get really weird state
[10:51] <neXyon> vila: and how to create a not shared repo? xD
[10:52] <vila> just 'bzr branch'
[10:52] <vila> no 'init-repo'
[10:52]  * vila gone
[10:52] <fullermd> neXyon: You don't need to explicitly create a repo if you don't want a shared one.
[10:52] <neXyon> vila: I just want to develop somewhere; stay in sync with trunk and probably at some point be able to push the changes to trunk :)
[10:53] <neXyon> so I just had to run "bzr branch lp:stellarium stellarium" ?
[10:53] <fullermd> Might as well just ignore it.  If down the line you start having several branches around and want to switch them to sharing a repo, that's easy enough to do then.
[10:53] <fullermd> Correct.
[10:54] <mgrandi> don't even need to specify the 'stellarium', by default it creates that folder
[10:55] <neXyon> I first had a "bzr checkout lp:stellarium" is it possible to change that to a "bzr branch lp:stellarium"?
[10:55] <fullermd> You can use 'bzr unbind' if you avoid thinking too carefully about the semantics.
[10:56] <fullermd> Or something under 'reconfigure'.  I'd have to dig around to figure out what.
[10:56] <neXyon> fullermd: can I still keep it up to date with trunk after the unbind?
[10:56] <fullermd> Sure, just 'pull' whenever.
[10:59] <neXyon> awesome, well as it works currently with the shared repo, I'll leave it as it is :)
[10:59] <neXyon> fullermd: shall I report that bug somewhere or will you handle it?
[11:00] <fullermd> I can file it I guess.
[11:01] <neXyon> fullermd: if you wish, sure; otherwise I could too
[11:03] <fullermd> Well, I wouldn't want to steal your LP karma.
[11:04] <neXyon> fullermd: whatever that is xD
[11:05] <neXyon> nah, I know it, but no clue what it's for
[11:05] <fullermd> Neither do I.  But it's a number, so it MUST be important.
[11:30] <neXyon> fullermd: so? looks like we're both too lazy :)
[11:52] <fullermd> Laziness is a virtue.
[12:32] <jave> is someone having success using bzr on the fedora 17 prerelease?
[19:49] <AmberJ> Is there a way to search for when few consecutive lines of code were added to the repo?
[19:49] <AmberJ> I want to find the revision when those lines were added.
[19:58] <AmberJ> Nevermind, I used "Change to this file" in launchpad web GUI to find what I was looking for.
[19:58] <AmberJ> Though this was more of manual searching.


[19:25] <SirSipe> Hey all! I've been evaluating Ubuntu Studio 24.04 since the beta release and there are still few issues, but nothing major. One thing that I haven't overcome is Discord. I can't get the latest Discord version launching at all. Any pointers on that? I've been evaluating using the Live version.
[19:28] <oerheks> discord snap in a live environment? https://snapcraft.io/install/discord/ubuntu
[19:29] <oerheks> not sure that runs fine..
[19:32] <SirSipe> damn I didn't even realize there's a snap
[19:32] <SirSipe> I've just downloaded it from discord page as .dep package
[19:32] <SirSipe> I'll test the snap later tonight
[19:36] <SirSipe> Keyboard layout doesn't work in release version either btw. This was issue in beta too, but in release you "can" choose e.g. English language with Finnish keyboard layout, but you still end up having only US keyboard layout. The tray doesn't work at all for changing it, only shows US. You have to go to Input Methods, install FI layout and remove US. Then it works.
[19:44] <SirSipe> tested already on VM, that snap package works. I wonder why I had to go with the .dep before...maybe there was some reason related to streaming or something.
[20:47] <Eickmeyer> SirSipe: I'm willing to bet the discord .deb support hasn't caught-up with the Ubuntu release compatibility yet. However, with the snap availability, you don't have to worry about that.
[20:51] <Eickmeyer> SirSipe: As for the keyboard layout issue, I'm going to chalk that one up to an ibus bug, which isn't specific to Ubuntu Studio but more the overarching Ubuntu distribution. Honestly, I don't know how to resolve that one, so open a Konsole window and type `ubuntu-bug ibus`. That should guide you through filing a bug.
[21:02] <SirSipe> Eickmeyer: ok, thanks.
[21:06] <SirSipe> I'm very much into professional audio stuff using Ubuntu Studio. I've had my doubts about Pipewire whether it's actually mature enough for LTS release. So far so good but while I now pretty much have solved my basic use cases, I really haven't tested for stability yet. I know stability was an issue in earlier Pipewire versions.
[21:06] <Eickmeyer> SirSipe: The PipeWire included in 24.04 LTS is 1.0, so you tell me what that implies.
[21:08] <SirSipe> Eickmeyer: Release notes state that it's now ready for professional use. Also PA+Jack configuration has been dropped from support
[21:08] <Eickmeyer> SirSipe: I demonstrated using PipeWire for live production in a 90-minute session without issues, flawlessly, in a session of about 20-50 people watching in Riga, Latvia at Ubuntu Summit 2023. It can be done.
[21:09] <Eickmeyer> SirSipe: I wrote the release notes.
[21:09] <SirSipe> Eickmeyer: Sure, I can also do many use cases with it nicely. But can I do them all using stable environment in my studio? That's another thing. Maybe, maybe not.
[21:10] <Eickmeyer> SirSipe: I also mastered a few songs for some various people using it. I'm not just the lead, I'm also a user.
[21:10] <Eickmeyer> I've been an audio engineer for 30 years.
[21:10] <Eickmeyer> I know what I'm talking about.
[21:12] <SirSipe> Eickmeyer: I don't want to bash PW. It's definitely an upgrade. Maturity vs jack is obviously not on par, but that's expected. This is a good way to get it mature, when people are forced to use it. But it doesn't change the facts that it doesn't come without issues still.
[21:12] <Eickmeyer> SirSipe: Perhaps you didn't read the part where the PW-JACK piece can be disabled to run pure JACK?
[21:13] <Eickmeyer> I mean, it's flexible. But I'll stake my life on it because I've done this in a professional setting already.
[21:14] <SirSipe> Eickmeyer: Yes I did and that's good otherwise except that newcomers must then use qjackctl instead of Studio Controls to set things up. Ease of setup is definitely a bit thing
[21:14] <SirSipe> *big
[21:15] <Eickmeyer> Ok. But don't come in here questioning whether or not what's written in the release announcement is true because 1) It wasn't a unilateral decision (I have another engineer who I consult with), and 2) I've been doing audio engineering for 30 years; I'm no veteran and I know what I'm talking about. You don't get to say what's ready for professional
[21:16] <SirSipe> Eickmeyer: Again, I have nothing against PW. It took me a while to figure out how I can do my basic setup with it. What I want do demostrate for others is simplicity and easy of setup because people still find it extremely hard to even try other than Win/Mac for studio usage.
[21:16] <Eickmeyer> and what's not.
[21:16] <Eickmeyer> *I'm no amateur
[21:17] <Eickmeyer> RE: Qjackctl: That's why we say it's for advanced users
[21:18] <SirSipe> Eickmeyer: I think there's a bit of miscommunication here. I wasn't criticizing you or misreading release notes, nor I have any belief you wouldn't know what you are talking about.
[21:19] <Eickmeyer> Ok. Well, I've been testing PW 1.0 since it came out, and it's solid. I haven't been able to break it.
[21:19] <Eickmeyer> Furthermore, every Ubuntu flavor is running it.
[21:19] <Eickmeyer> Not necessarily the JACK setup, but that's what I haven't been able to break.
[21:20] <SirSipe> What I want to do is to make the entry to Ubuntu Studio -for especially those millions of home studio guitarists- super simple. It's still pretty mystical and especially the fact that things like Neural Amp Modeler are now available for it makes a huge difference
[21:21] <Eickmeyer> That's my goal too. That's why Patchance is right in the taskbar by default; so one can just patch stuff right away, and it doesn't matter if it's a JACK app or what kind of app it is anymore.
[21:22] <SirSipe> Eickmeyer: execpt if you have more that one audio interface. Then you also need to setup the default device from PA controls as otherwise every single time you pause a youtube backing track, it connects to the wrong device.
[21:22] <Eickmeyer> Plug the guitar directly into the computer, throw it through an amp modeler, and listen to it through your headphones.
[21:23] <Eickmeyer> Ah! Then what you need is to turn on the dummy audio device in Ubuntu Studio Audio Configuration, set that as the default using the audio widget in the taskbar, and then send YouTube to where it's supposed to go.
[21:24] <SirSipe> Eickmeyer: Also if you start e.g. carla for the first time using save template, all connections between all loaded plugins are lost. I guess PW does some initialization when first jack client appears and this probably causes it. Just a guess though
[21:24] <SirSipe> Eickmeyer: Thanks! I'll use that probably when I do my tutorials
[21:25] <Eickmeyer> SirSipe: Oh, that's a problem with Carla. Send issues to https//github.com/falktx/Carla
[21:26] <Eickmeyer> SirSipe: That was precisely why I made the Dummy Audio Device in Ubuntu Studio Audio Configuration. I'm still working on documentation, but I do most development-related work Monday-Friday.
[21:29] <SirSipe> Eickmeyer: I think the dummy device solves actually quite many issues for me. I  always have carla running and I use PA bridge (actually two) that never goes direcly to any ouputs. I was struggling a lot with the fact that PW wanted to always auto-connect to some first input pair of some first device. These are the kind of things I mean when talking about making the entry simple and easy. It's really not there yet, hence the
[21:29] <SirSipe> need for loads of tutorials
[21:32] <Eickmeyer> SirSipe: Right, that was the reason I made it. In fact, per the PW developer, he suggested making one by hand, and that inspired me to make one using a GUI which makes it easy for everyone. My philosophy is that if it can only be done with the command line, then a way needs to be made for it to be done with a GUI.
[21:32] <SirSipe> Eickmeyer: for instance, my other audio device is Scarlett 18i20. I have configured it direct out without internal mixing (can be only done using the windows app). It's has two headphone outpus that are at outputs 6-7 and 8-9. So without routing the capture of 0-1 to both of the headphones, I actually wasn't able to use headphones at all to play along youtube videos.
[21:34] <Eickmeyer> SirSipe: One workaround you might use for your Carla issue is using RaySession. It can save all of your PipeWire connections as if they were JACK connections and remember them the next time you start the session.
[21:34] <Eickmeyer> Its interface is identical to Patchance.
[21:36] <SirSipe> Eickmeyer: I actually have that issue because I'm working on Makefile based Ubuntu Studio "Essentials Package" for guitarist. In addition to installing NAM, NAM models, Impulse Responses and GxPlugins, it also creates demo signal chains using as carla presets. First launch always fails because of that isssue I decribed before, but second one works. My script also figures out correct audio device to use and replaces that in the
[21:36] <SirSipe> carla presets so it's true "make & play" :D
[21:37] <Eickmeyer> I see.
[21:38] <SirSipe> Eickmeyer: but I'm sure if it's about some jack initialization related issue, I can probably workaround that by initializing some dummy client for a second or so. Haven't really looked too much into that
[21:39] <Eickmeyer> SirSipe: BTW, I always recommend against Scarlett interfaces because of their proprietary Windows app for some features. Believe it or not, I've recommended Behringer interfaces, especially the ones with the Midas preamps, since they're class-comliant and don't require drivers or extra software of any kind. In fact, I know a band, Lorenzo's Music,
[21:40] <Eickmeyer> who does all of their recording on Behringer interfaces and they sound amazing.
[21:40] <SirSipe> Eickmeyer: Btw here's my channel: https://www.youtube.com/@sudometalstudio nothing big or anything but I'm quite committed to learn all this stuff :)
[21:40] <Eickmeyer> SirSipe: Dude, you have no idea how much of a metal head I am. :D
[21:42] <SirSipe> Eickmeyer: Nice! If you do metal on Ubuntu, I'd love to know more about your process etc
[21:44] <Eickmeyer> SirSipe: Sadly, I don't. Most of my mixing is church contemporary these days. Not that I haven't done metal, but that was quite some time ago. Though, when I'm given an electric with a bit of crunch in the band, they tend to get a little extra "oomph" if you know what I mean. ;)
[21:47] <SirSipe> Eickmeyer: Sure :) But yea, I'm still in process of learning everything PipeWire and once I feel I have the perfect and simple explanation for everything, then I'll make a video about it.
[21:48] <Eickmeyer> SirSipe: Sounds great. Let me know about it either here or on Matrix (link in the topic). It sounds to me like that dummy audio device was key.
[21:48] <SirSipe> Eickmeyer: BTW, you should reallly consider adding the Mike Oliphants LV2 wrapped Neural Amp Modeler to repos, with Brummer10's GUI. It's the best thing ever happened to Linux guitarists.
[21:49] <SirSipe> Eickmeyer: this one: https://github.com/mikeoliphant/neural-amp-modeler-lv2
[21:49] <SirSipe> Eickmeyer: and here's the GUI: https://github.com/brummer10/neural-amp-modeler-ui
[21:50] <Eickmeyer> SirSipe: Yeah, these past two cycles were hectic. First one with PipeWire and figuring out how to implement, and the second one with implementing an entirely new installer. This next one we're having to transition to Plasma 6, so it is going to be hectic as well, but sadly, packaging plugins has had to take a back seat, but I'll throw those two on
[21:50] <Eickmeyer> my list.
[21:50] <Eickmeyer> So, it's been a hell of a year.
[21:53] <SirSipe> Eickmeyer: Great! And now that I'm writing to Santa, please also upgrade Hydrogen. Current version has a nasty bug that prevents using Midi input for it. Luckily it can be worked around quite easily (https://github.com/hydrogen-music/hydrogen/issues/1751)
[21:53] -ubottu:#ubuntustudio- Issue 1751 in hydrogen-music/hydrogen "MIDI note events not played" [Closed]
[21:56] <Eickmeyer> SirSipe: Yeah, Hydrogen is one of those packages where I'm at the mercy of Debian as it's automatically synced from there until Feature Freeze, which happened in February and for the next release, happens at the end of August. (if you don't see an "ubuntu" in the package version number, it didn't originate here but from Debian). So, sadly, that's
[21:56] <Eickmeyer> where if something happens, I might be able to backport it to the LTS, but that's assuming it lands in oracular (future 24.10) first.
[22:06] <SirSipe> Eickmeyer: Do you know if PW can be made work properly also under VirtualBox? PW performance under VirtualBox is...not there at all :D PA-Jack configuration actually works very well so it's definitely PW related.
[22:06] <Eickmeyer> SirSipe: I wouldn't even trust JACK under VirtualBox. :P
[22:06] <Eickmeyer> I wouldn't even trust PulseAudio under VirtualBox.
[22:06] <Eickmeyer> Even ALSA is flaky under VirtualBox.
[22:07] <SirSipe> Eickmeyer: I can actually run full setup and session under Virtual Box using PA-Jack configuration :D Works like a charm :D
[22:07] <Eickmeyer> Well, yeah, but the performance.... THE PERFORMANCE....
[22:07] <SirSipe> Eickmeyer: 128 buffer size! Latency under 3ms :)
[22:08] <Eickmeyer> Actually, that's how I do the .iso testing of 22.04 LTS when we have a point release.
[22:08] <SirSipe> Eickmeyer: Aaand I have proof! Here: https://www.youtube.com/watch?v=NZBtnQEDdQU
[22:08] <Eickmeyer> No no no. I have no doubt, I was just joking around.
[22:10] <Eickmeyer> I've had PW work properly under VirtualBox. In fact, that's how I tested the .iso images before beta. Before release I tested in VirtualBox and on real hardware. It can be done. Let me put it this way: if you run the Ubuntu Studio 24.04 LTS .iso image inside VirtualBox and you hear the sound when it first boots, it's working.
[22:12] <SirSipe> Eickmeyer: It's working yes, but PW also defauts to 1024 buffer size which is completely unusable for live performance i.e. when using virtual amp. 256 is the absolute minimun but fast stuff and drums really require 128.
[22:13] <Eickmeyer> SirSipe: So, I only use VirtualBox when testing the .iso images, I don't really test it for actual usability like that. Give it a shot. Ubuntu Studio Audio Configuration is where to go to set the buffer.
[22:13] <SirSipe> And I can do 128 easily with PA-Jack configuration under VirtualBox but not even 256 using PW.
[22:14] <Eickmeyer> It also depends on what the host machine is doing, so keep that in mind.
[22:14] <SirSipe> Eickmeyer: yea I know. My makefile script actually uses the pw commandline to setup "quantum" for playable level
[22:15] <Eickmeyer> Right, but bear in mind, the configurations that Ubuntu Studio Audio Configuration sets get reset every time you log-in.
[22:15] <Eickmeyer> Meaning, whatever you set in that are what gets set every time you log-in.
[22:15] <SirSipe> Eickmeyer: now THAT I didn't know. Goddamn, why is that? Why would anyone what to setup e.g. buffer size after every reboot?
[22:16] <SirSipe> Patchance also doesn't work for that btw. It stays for ~5s and then changes back to 1024
[22:17] <Eickmeyer> Right, because the quantum is controlled by PipeWire's meta. That can be controlled by Ubuntu Studio Audio Configuration.
[22:17] <Eickmeyer> So you can for instance set it to 128 and 48000 and it will be that next time you log-in.
[22:18] <SirSipe> Eickmeyer: oh but isn't that actually using pw-cli or pw-jack-setup or something similar to change the quantum? That's what I'm using
[22:20] <Eickmeyer> No, it's not. It used to be that it would set a system variable, but then that changed between versions. Now it sets it via pw-metatdata, which is what the PipeWire developer prescribed.
[22:20] <SirSipe> Ok, thanks! I'll need to take a deeper dive on that.
[22:21] <Eickmeyer> The code is in /usr/bin/ubuntustudio-audio-config if you want to inspect that.
[22:21] <SirSipe> I guess I'm at the point that testing with live is no longer an option. But I don't want to upgrade my production computer yet so I'll upgrade my old one first
[22:22] <Eickmeyer> Yeah. Sadly, it's all theory until put into practice.
[22:23] <SirSipe> Eickmeyer: Have you btw tested any persistent lives? I think there was some big change in previous LTS which made persistense break in many tools at least for a while
[22:23] <SirSipe> mkusb was the only one working last time I tested some year(s) ago
[22:24] <SirSipe> but e.g. Rufus for windows didn't work at all
[22:25] <Eickmeyer> We have a supported method of making a live USB that's linked on the website and in the release notes that's a tutorial on ubuntu.com that also has a link to making one with Windows, but I forgot what tool it uses.
[22:25] <Eickmeyer> Let me see what the factoid says (if it says one)
[22:25] <Eickmeyer> !liveusb
[22:25] <Eickmeyer> Aha!
[22:26] <Eickmeyer> Another option is having a second USB stick and simply installing to that. ¯\_(ツ)_/¯
[22:27] <SirSipe> Or boot "toram" and install on the same USB :)
[22:30] <SirSipe> Hmm... so UNetbootin is still the recommended method. That's a bit odd considering that every single tutorial I've seen uses something else. But I guess persistense is not considerent in many of the tutorials I've seen.
[22:32] <Eickmeyer> I think BalenaEtcher is probably the better one at this point, but I don't know. I use Ventoy for the most part.
[22:33] <Eickmeyer> SirSipe: That persistent USB article was last edited some 7 years ago. 💀
[22:34] <SirSipe> Eickmeyer: Yup, yet it's the second thing everyone wants after trying with live :)
[22:34] <Eickmeyer> The factoid bot isn't always kept up-to-date; it's shared by all the Ubuntu channels.
[22:36] <SirSipe> I actually said in one of may videos that no one should bother with persistent live. Just go with dual boot. People especially in audio world must be able to keep their already established setup alive even if they are a bit linux-curious (usually for performance reasons)
[22:36] <Eickmeyer> I was about to say just that. Space is so cheap anymore that it's not hard to carve out a partition.
[22:37] <SirSipe> Yes, but it's a whole another stress point for those that are not that tech-savvy. I'm actually very glad how the new installer looked. It was very clear and simple and had a clear option to install side-by-side
[22:38] <SirSipe> maybe it could stress even more that the existing system will not be touched at all, just some disk space reserved.
[22:45] <Eickmeyer> That's something you can add at https://bugs.launchpad.net/ubuntu-desktop-provision/+filebug
[22:45] <Eickmeyer> It'll be given the priority of "Wishlist", but that's still OK.


[18:28] <Mkaysi> Hi MichealH
[18:29] <MichealH> Hi Mkaysi, AlanBell
[18:29] <MichealH> No meeting?
[18:29] <Mkaysi> MichealH: It was yesterday.
[18:29] <MichealH> Oh
[18:29] <MichealH> haha
[18:29] <MichealH> Date fail
[18:30] <MichealH> I thought it was the 24th
[18:30] <MichealH> :P
[18:30] <MichealH> and I also thought yesterday was Wednesday
[18:30] <MichealH> Thats weird


[13:55] <jared> jea: a little more tweaking an my LP score is over 95% ;)
[13:55] <jea> which LP score is that?
[13:56] <jared> lastpass, sorry, just realised the confusion
[13:56] <jea> ah, right
[13:56] <jea> yeah, i was thinking launchpad
[13:56] <jea> and wondering when karma turned into %
[13:56] <jea> that is a pretty good lastpass score
[13:57] <jared> Every password I'm actually responsible for is now 12+ characters and all include a-z and 0-9, where possible special characters as well.
[13:58] <jea> are they LP generated?
[13:59] <jared> Yeah pretty much
[13:59] <jared> Some of them were already like that
[13:59] <jea> Right. LP is good for that type of thing
[14:01] <jea> I am off to bed now. Speak to you later :)
[14:01] <jared> No worries, didn't know if you were here or not :)


[16:29] <ChrisAshton84> not sure if this is the right channel, but I need to find 32 bit tcl libs for x86_64 ubuntu - do you guys know where I could get this?
[16:46] <Mithrandir> I don't believe we ship those, but you could use a chroot
[16:50] <ChrisAshton84> Mithrandir: thanks for the suggestion but that's a bit of overkill :-P I managed to install the i386 version using a tool on the x86_64 forum but it installs a broken link :-/
[16:53] <ChrisAshton84> got it. getlibs available on the forums could be a great save for any x86_64 user w/ unsupported programs to run


[02:16] <seeit_> anyone in here able to help me with apt-build?
[02:18] <sarnold> irc works better with specific questions :)
[02:22] <seeit_> I am looking to build some packages with apt-build but if I do apt-build install <pkgname> I get a message that there must be some 'source' URIs in your sources.list, I've tried adding them but that doesn't work
[02:22] <sarnold> did you run apt-get update afterwards?
[02:22] <seeit_> I ran apt-build update
[02:23] <seeit_> just ran apt-get and i get the same message
[02:24] <sarnold> what do your apt sources.list files look like? (paste.ubuntu.com if they're more than three or four lines, please)
[02:27] <seeit_> ok, the deb-src lines were still commented out, thought I had fixed it but guess not, its working now, ty
[02:27] <seeit_> ls
[02:27] <sarnold> woot :)
[02:29] <seeit_> on a 4 core system with hyperthreading and 32gb of ram how long should I expect it to take to build world
[02:29] <sarnold> yikes, uh, what's in the "world" category?
[02:29] <seeit_> all currently installed packages
[02:30] <seeit_> ls
[02:30] <sarnold> probably a few weeks
[02:31] <seeit_> wow, any idea what causes the error ' the value 'apt-build' is invalid for APT::Default-Release as such a release is not available in the sources?
[02:31] <sarnold> you can find out how long launchpad takes to build specific packages; look up the source package name e.g. https://launchpad.net/ubuntu/+source/libreoffice click a triangle to expose the "builds", amd64 there says libreoffice took five hours, thirty one minutes...
[02:33] <seeit_> wow ok
[02:33] <seeit_> not interested in rebuilding libreoffice right nwo
[02:33] <seeit_> mostly some computational packages
[02:33] <sarnold> seeit_: wild-guess, maybe the '--target-release' option might help with the default-release setting  http://manpages.ubuntu.com/manpages/xenial/man1/apt-build.1.html
[02:36] <seeit_> sarnold it was exactly that
[02:40] <sarnold> man I love it it when things work as I expect :D
[02:45] <seeit_> ok, now for a weird one, I was just doing this all in a VM to test out apt-build, now I copied sources.list over to the host machine and I get the previous error to put some URIs into sources.list
[02:45] <seeit_> wait nm
[02:58] <seeit_> timing world on my system :P
[02:59] <sarnold> how many packages do you have installed?
[03:01] <seeit_> 2206
[03:01] <sarnold> the worst ones I can think off the top of my head would be firefox, chromium-browser, libreoffice, mysql...
[03:01] <sarnold> owwwwww
[03:01] <seeit_> i've got libreoffice and firefox in there
[03:01] <sarnold> hope you've got loads of drive space and even more free time :)
[03:02] <seeit_> I'm not using the cpu much most of the stuff I need is through citrix and about 500GB of space
[03:02] <seeit_> but doing everything through -pipe
[03:03] <seeit_> I'll be surprised if the system reboots after this
[03:04] <seeit_> then the big question is if this works how do I make a install iso out of all these packages
[03:07] <seeit_> I suspect libc won't work with -fstack-protector-strong, at least it hasn't in the past
[03:07] <jbicha> webkit2gtk is heavy too
[03:08] <seeit_> yeah I've done linux from scratch before in a VM and that one is pretty hefty
[03:08] <sarnold> three and ahalf hours there, yeah...
[03:10] <seeit_> is there a way to supress the output from the build? I'm sure that would speed it up some, at least it has on other compilations I've done
[03:10] <seeit_> > /dev/null maybe?
[03:10] <sarnold> it'd probably beb etter to save to a file so that you can figure out why things break, when they inevitably will..
[03:11] <sarnold> grab stderr too
[03:12] <seeit_> already failed on apparmor, "Sorry, no package to install"
[08:48] <doko_> jamespage: https://launchpad.net/ubuntu/+source/python-cryptography/1.5-1/+build/10678695
[11:07] <tjaalton> huh, the update manager reboot-popup somehow takes 30% cpu on both xorg and compiz (xenial)
[12:06] <jamespage> doko_, +1 thanks for sorting that out
[15:17] <doko_> jbicha: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1547395 totem doesn't migrate
[15:25] <ejat> anyone facing broken icon panel in 16.10 ?
[15:28] <ejat> http://picpaste.com/broken-icon-right-top-panel-yvqAsbg3.png
[16:47] <jbicha> doko_: could you demote libquvi to universe?


[10:33] <rmg51> Morning
[11:00] <JonathanD> Morning.
[13:16] <teddy-dbear> Morning peoples, dogs, turkeys?, hamsters and everything else
[16:19] <lazyPower> o/


[06:56] <rvba> jtv: thanks for the review on my maas-test branch.  Doing the fixes you suggested now.
[06:57] <jtv> I was just looking.  :)
[06:57] <rvba> jtv: just pushed the fixes.
[07:14] <rvba> bigjools: the second problem I saw is that the NUC's power details are not properly autodetected.
[07:15] <rvba> bigjools: the third problem is that, even if I install amttool manually and fill the power details manually, power_on fails (because the IP is not correctly derived from the MAC address).
[07:15] <rvba> bigjools: hence my question to gmb "can you confirm that you got an AMT-based machine working with MAAS"…
[07:16] <bigjools> he said he had, previously
[07:16] <bigjools> the latter problem is arp cache
[07:16] <rvba> bigjools: no, the arp cache is fine, checked
[07:16] <bigjools> it needs something to populate that
[07:16] <bigjools> oh
[07:16] <bigjools> then.... wtf!
[07:16] <rvba> I* checked
[07:16] <rvba> Yeah, wtf indeed.
[07:16] <bigjools> I just plugged mine in for the first time, will have a play with it in a moment
[07:16] <rvba> okay
[07:17] <bigjools> I have no monitor on it :)
[07:20] <rvba> bigjools: btw, here is the manpage for the new --power-type/--power-parameters for maas-test: paste.ubuntu.com/7364567/
[07:21] <bigjools> rvba: you've been pasting urls without the http:// lately and they're not clickable!
[07:21] <rvba> bigjools: I know, fu**ing chromium is at fault.
[07:21] <jtv> Found documentation for those mysterious password requirements: “man amt-howto”
[07:21] <bigjools> rvba: I use chromium and it's not a problem here
[07:21] <rvba> jtv: yeah, you need to define an env var
[07:22] <jtv> ?  I meant the mysterious requirements for setting a new password instead of “admin.”
[07:22] <jtv> Where every password you can reasonably come up with is rejected without explanation.
[07:22] <rvba> jtv: ah, no.  I thought you where talking about passing the pw to amttool
[07:22] <jtv> Ah
[07:30] <rvba> bigjools: with the 'http://', for your clicking pleasure: http://paste.ubuntu.com/7364567/
[07:30] <bigjools> \o/
[07:31] <bigjools> rvba: tip top
[07:32] <rvba> Cool
[07:33] <bigjools> oh gee, thanks grub for removing the menu timeout on my headless server
[07:44] <rvba> jtv: all good with the changes I made to my 'power-type-support' branch?
[07:45] <rvba> (btw, I QAed it in the lab.  We only have IPMI-based nodes in the lab but at least that's a confirmation that my branch doesn't introduce regressions)
[07:45] <jtv> rvba: I didn't look in detail — but I have faith.
[07:45] <rvba> jtv: okay, thanks.  Landing it now :).
[07:46] <jtv> It was already Approved anyway.
[07:46] <jtv> Now, how do I know how to address my NUC on the network...
[07:46] <rvba> MAC Address + arp -n
[07:48] <jtv> That same MAC address that was so helpfully not displayed on boot, and found with random key-bashing...
[07:48] <rvba> jtv: precisely :)
[07:48] <rvba> jtv: or, nmap on the node's network will give you the MAC Address *and* the IP.
[07:50] <jtv> That might be better in this case...  not seeing any arp for the node.
[07:53] <jtv> Ahhh, my own machine hadn't got a dhcp address for whatever reason.
[08:07] <rvba> Christ, `sudo lshw -xml` doesn't return a lot of details on these NUCs… not surprised MAAS was unable to detect the number of cores or the amount of memory available.
[08:31] <bigjools> rvba: in which package does amttool live?
[08:31] <rvba> bigjools: amtterm
[08:32] <bigjools> ta
[08:34] <rvba> bigjools: so, the dependency is in 'Suggests'
[08:34] <bigjools> feh
[09:01] <bigjools> rvba, allenap, jtv, gmb: what did you think of the acquire() race?
[09:01] <bigjools> nasty
[09:01] <rvba> bigjools: I replied to the list about that
[09:01] <bigjools> I saww
[09:02] <rvba> bigjools: Like it said, it's unfortunate but Django doesn't do optimistic locking.
[09:02] <jtv> And yes, isolation level should prevent that.
[09:03] <bigjools> it needs a lock, yes :)
[09:03] <bigjools> this is very serious
[09:03] <bigjools> we need to fix this and backport everywhere
[09:04] <rvba> Yeah
[09:04] <rvba> And probably audit the code for other places where we need that locking.
[09:04] <bigjools> yep
[09:04] <bigjools> anyway I am switching locations to sort out the NUC
[09:04] <bigjools> ttfn
[09:05] <jtv> gmb: any suggestions on what to do about that 1.5 lander?
[09:06] <gmb> jtv: I appear to have missed context … what’s wrong with it?
[09:06] <rvba> gmb: "it's stone dead, that's what's wrong with it" :)
[09:06] <gmb> Oh poo.
[09:07] <jtv> what he said.
[09:08]  * gmb pokes
[09:09] <gmb> jtv, rvba Looks like tarmac is stuck. Hang on, I’ll kill it and run it manually to see what it’s choking on
[09:09] <jtv> Thanks.
[09:19] <rvba> gmb: how do you get the AMT card to issue a DHCP request?
[09:25] <jtv> AIUI it'd do that as soon as it's plugged into the network, even while off...
[09:26] <jtv> The lander seems to be running again, but running out of memory.  :(
[09:27] <rvba> jtv: you're right, it got an IP when I unplugged it and then plugged it back on.
[09:27] <rvba> The only problem was that the ARP table wasn't populated correctly.
[09:27] <gmb> Yeah, hard resets are the only way to get it to do it.
[09:27] <gmb> jtv, rvba: Re: the lander: “OSError: [Errno 12] Cannot allocate memory”
[09:27] <rvba> I had to manually run `nmap` to get the ARP table to be populated.
[09:28] <gmb> (Which is weard because there’s > 1G free)
[09:28] <jtv> I think the arp table is populated on demand.
[09:28] <rvba> bigjools: would you happen to know anything about that? ^.  My NUC gets an IP alright but then MAAS fails to power it up because the ARP table didn't contain a record for the NUC's MAC address.
[09:28] <rvba> bigjools: manually running `nmap` solves the problem of course.
[09:29] <jtv> Populated on demand.
[09:29] <rvba> Yeah, but doesn't this mean there is a bit of a flaw with the fact that MAAS expects the ARP table to be populated?
[09:30] <jtv> !
[09:30] <jtv> We rely on a cache lookup?
[09:30] <rvba> Yes we do.
[09:30] <jtv> Not a proper rarp lookup!?
[09:30] <rvba> (1 NUC in ready state)
[09:31] <rvba> jtv: we run `arp -n` and parse the output.
[09:31] <jtv> Yeah that won't work...
[09:31] <rvba> It doesn't.
[09:33]  * rvba files bug
[09:37] <bigjools> it's populated on demand
[09:37] <bigjools> as I keep saying :)
[09:37] <bigjools> which is why maas-test uses nmap
[09:37] <bigjools> it seems to work fine for me, I used its IP address
[09:38] <bigjools> FPI runs in 30 seconds, lol
[09:38] <rvba> bigjools: my testing shows that its very unreliable.
[09:38] <bigjools> v reliable for me!
[09:39] <bigjools> in my admittedly limited set of tests
[09:39] <rvba> That's a shame because we have the MAC<->IP correspondance in MAAS (from the parsing of the lease file).
[09:39] <bigjools> yes
[09:39] <bigjools> we can shortcut this for amt
[09:41] <rvba> Filed bug 1314559.
[09:41] <rvba> https://bugs.launchpad.net/maas/+bug/1314559
[09:49] <bigjools> ubuntu@nuc1:~$
[09:49] <bigjools> hehe
[09:52] <rvba> 30 seconds?  That seems quicker than what I saw.
[09:53] <bigjools> I'll test again tomorrow
[09:53] <rvba> Timing [hit start node → ssh connect] now….
[09:54] <rvba> 2min24s
[09:54] <rvba> (Using fpi)
[09:58] <allenap> bigjools, rvba, jtv: How about we bite the bullet and switch to serialized?
[09:59] <bigjools> why is there a bullet?
[09:59] <allenap> bigjools: Fallout from doing it. Having to add a middleware for retries.
[10:02] <bigjools> somehow I was naive enough to think that would have been handled by Django already
[10:03] <bigjools> allenap: but yes, we need to do it, the DB is not safe otherwise.
[10:03]  * gmb -> errands and lunch
[10:06] <rvba> allenap: there are a bunch of plugins for Django that implement optimistic locking.
[10:08] <rvba> jtv: I'm wondering if checking the the presence of a rogue DHCP server on the network *every minute* isn't a bit too aggressive… it certainly generates a lot of traffic/log noise.
[10:10] <jtv> rvba: Agreed.  I think the main thing is that we check initially...
[10:12] <rvba> jtv: filed https://bugs.launchpad.net/maas/+bug/1314571 (low priority of course)
[10:14] <bigjools> rvba: I'd be ok with that changing to say 15 minutes
[10:15] <rvba> bigjools: yeah, but like Jeroen said, it would be important to get the network scanned *initially* (i.e. when the user is likely to be configuring his DHCP server).
[10:15] <bigjools> yes
[12:59] <rvba> roaksoax: Hi Andres… as you probably know, we're testing MAAS on NUC nodes that use AMT for power-management.  Since amtterm is only in 'Suggests', these nodes don't work with MAAS "out-of-the-box"" you need to manually install amtterm to get the tool (amttool) that the AMT power template uses.  Isn't that a bit suboptimal (it's quite hard to understand what's wrong, you need to dig up the celery log file)?
[13:00] <rvba> Why was it decided not to add amtterm as a hard dependency (or, at least, as a 'recommends')?
[13:01] <rvba> gmb: Did the power credentials detection work on the AMT boxes you've used?
[13:02] <roaksoax> rvba: hey
[13:02] <roaksoax> roadmr:  release (universe)
[13:02] <roaksoax> rerrr
[13:02] <roaksoax> rvba: ^^
[13:03] <roaksoax> rvba: amtterm is in universe
[13:03] <rvba> arg
[13:03] <roadmr> roaksoax: masters of the universe unite!
[13:03] <roaksoax> roadmr: :)
[13:03] <rvba> roaksoax: I understand why it can't be a hard dependency then… but still, the experience is clearly suboptimal.
[13:04] <roaksoax> rvba: same as ipmitool
[13:04] <roaksoax> rvba: unfortunately, I don't think I added the dependency myself
[13:04] <roaksoax> rvba: so that should have gone through a MIR
[13:04] <rvba> roaksoax: IPMI works out of the box AFAIK
[13:04] <roaksoax> rvba: which means more dependencies
[13:04] <rvba> Because we're using free-ipmi or something
[13:04] <roaksoax> rvba: IPMI when it uses freeipmi-tools not when using ipmitool
[13:05] <rvba> roaksoax: so we should aim for either a) things working out of the box or b) a very clear message about what you need to install
[13:06] <roaksoax> rvba: i don't disagree what you are saying
[13:07] <roaksoax> rvba: i'm just saying that at the time of this happened, a request should have been made to take care of this dependency
[13:07] <roaksoax> rvba: but anyways, I no longer maintain the packaging :)
[13:07] <roaksoax> rvba: lutostag should be helping with this now
[13:08] <rvba> roaksoax: sure, I was asking you because you know packaging better than I do… and because the changelog says you added the 'suggests' :)
[13:08] <roaksoax> rvba: yeah I changed it from dependes to suggests
[13:08] <roaksoax> IIRC
[13:08] <roaksoax> rvba: but at the time that happened, it was too late to do something about it
[13:08] <roaksoax> I can't remembe really
[13:08] <rvba> roaksoax: all right.  I'll file a bug about this and see what lutostag can do about it.
[13:09] <roaksoax> rvba: thanks! he should be able to file a MIR for utopic and then we might be able to MIR
[13:13] <gmb> rvba: I don’t recall trying the credentials detection on the orange boxes.
[13:16] <rvba> gmb: ah ok… I'm not sure it's a feature that's supposed to be there…
[13:17] <rvba> tych0: do you happen to know if credential auto-detection is something that's possible with AMT/supposed to be working within MAAS right now. (I'm asking you because I see you've added the AMT power template.)
[13:17] <tych0> rvba: it isn't supposed to be working
[13:18] <tych0> i think it is possible, but i spent a day fiddling with it when i did it and i couldn't figure out how to do it
[13:19] <rvba> tych0: okay, fair enough.  If you have bits and pieces (i.e. a vague embryo of support), don't hesitate to file a bug with all the details you have so that, maybe, someone else will pick it up.
[13:19] <tych0> ok
[13:19] <tych0> i'll see what I can dig up
[13:20] <rvba> tych0: fwiw, I just filed bug https://bugs.launchpad.net/maas/+bug/1314629
[13:20] <tych0> ah, yeah
[13:20] <tych0> well, actually amtterm isn't that huge
[13:20] <tych0> it is like a 400 line perls cript
[13:20] <tych0> and maas doesn't even use most of it
[13:20] <tych0> so you could probably get away with using something else there
[13:21] <rvba> Something else as in "extract the bits that we need from amttool and ship it with MAAS" or as in "use another package"?
[13:27] <tych0> the former
[13:27] <tych0> i don't think there are any other packages, really
[13:27] <tych0> most of intel's tools are windows-based
[13:30] <rvba> I see.
[23:16] <newell_> Wondering if anyone is around that might be able to help me troubleshoot something I am running into.  I am running into the same issue as highlighted in this link:
[23:16] <newell_> http://askubuntu.com/questions/370971/ubuntu-13-10-server-maas-pb-to-import-boot-images
[23:17] <newell_> However, when I check for celery.log I do not find one in /var/log/maas
[23:18] <bigjools> hi
[23:18] <bigjools> I can try to help
[23:18] <newell_> hello bigjools, thanks appreciate it
[23:18] <newell_> I am running for latest source
[23:18] <bigjools> are you using maas from trusty?
[23:19] <newell_> I followed the HACKING.txt
[23:19] <bigjools> ah
[23:19] <newell_> so checked out the latest code
[23:19] <bigjools> running from source
[23:19] <newell_> yes
[23:19] <bigjools> doing that is a bit harder than using packages
[23:19] <newell_> yeah I know
[23:19] <newell_> but I want to fix some bugs
[23:19] <newell_> ;)
[23:20] <bigjools> did you start up maas?
[23:20] <newell_> yes
[23:20] <bigjools> "make run"
[23:20] <newell_> able to login to dashboard etc
[23:20] <bigjools> there's a logs/ dir at the top level of src
[23:20] <newell_> yeah I have been looking at those...still trying to track this down
[23:20] <bigjools> but unfortunately it will try to run stuff that is not installed
[23:21] <bigjools> I think there's code that assumes packaged locations
[23:21] <bigjools> you can try to run scripts/maas-import-pxe-files after editing etc/maas/bootresources.yaml
[23:21] <newell_> bigjools, what is your advice in terms of getting a setup that is conducive to fixing bugs and verifying the fix?
[23:21] <newell_> Ok
[23:22] <bigjools> we've never needed to import pxe files to test at this source level you
[23:22] <bigjools> s/you^//
[23:22] <bigjools> the testing is done in unit tests with fake resources
[23:22] <bigjools> otherwise working with such huge files would be a right pain
[23:23] <newell_> Okay if I wanted to work on a bug like this: https://bugs.launchpad.net/maas/+bug/1283106
[23:23] <bigjools> once a fix is in place, we do "make package" to build some .debs and install them in a separate VM
[23:23] <newell_> Do you guys usually just use your testing framework?
[23:23] <bigjools> yes - that one's pretty easy to fix, just needs some overlapping network checks
[23:23] <bigjools> there's an IPNetwork class somewhere
[23:23] <bigjools> you don't need to import images to fix it
[23:23] <newell_> ah okay
[23:24] <bigjools> thanks for looking to fix things!
[23:25] <newell_> bigjools, to verify the fix would you just try and manage two cluster interfaces with the same subnet and see if the error pops up again?
[23:26] <bigjools> newell_: yes - create a unit test case *first* to reproduce the problem
[23:26] <bigjools> then once done you can work on a fix and keep running the test until it passes
[23:39] <newell_> bigjools, so if I created my own unit test I would do something like:  Just to verify: $ ./bin/test.maas test src/maasserver/tests/test_cluster_subnets.py
[23:40] <bigjools> newell_: yes but don't make a new file just for one test, find existing tests for the functionality and add a new test case
[23:40] <newell_> k
[23:40] <newell_> thanks
[23:41] <bigjools> np


[00:42] <valorie> !grub
[00:43] <valorie> oh, they left
[00:43] <valorie> of course
[05:33] <redphantom_> Im on 17.10 - my Internet doesn't connect automatically on startup ever since configuring openvpn to connect via the NetworkManager GUI. I always need to press "Connect" manually and things connect just fine. I have the automatically connect option selected, but still no dice. Any ideas?
[07:44] <redphantom_> Im on 17.10 - my Internet doesn't connect automatically on startup ever since configuring openvpn to connect via the NetworkManager GUI. I always need to press "Connect" manually and things connect just fine. I have the automatically connect option selected, but still no dice. Any ideas?
[08:06] <Guest3062> hello?
[08:41] <redphantom_>  Im on 17.10 - my Internet doesn't connect automatically on startup ever since configuring openvpn to connect via the NetworkManager GUI. I always need to press "Connect" manually and things connect just fine. I have the automatically connect option selected, but still no dice. Any ideas?
[13:01] <BluesKaj> Hi folks and Merry Christmas!
[15:55] <D0U91E> morning BluesKaj
[15:55] <D0U91E> ... Merry Christmas!!!
[16:00] <BluesKaj> D0U91E, Merry Christmas! to you too :-)
[18:07] <gerardi> hello
[18:09] <DarinMiller> gerardi: Hi
[18:10] <gerardi> bonsoir
[18:10] <gerardi> je fais des essais; je découvre l'outil !!!!


[01:31] <starrats> Don't know if this is a 'bug report' or not but I'm still experiencing a 'lock-out on login/password screen after a major update/upgrade when it rerquests a re-start to complete the action.
[01:32] <bluesabre> Unit193... it works O.O
[01:32] <Unit193> bluesabre: Of course it does, I'm better than Logan_. ;)
[01:33] <bluesabre> lol
[01:33] <Unit193> (Hah, juuust kidding, he wins.)
[01:33] <bluesabre> what did you change? :)
[01:34] <Unit193> I was on the right track, just wrong change.  dpkg-buildflags uses -Wl,-Bsymbolic-functions in Ubuntu but not Debian, so in the rules file I exported LDFLAGS=-Wl,-z,relro and rebuilt.  (Spotted it in the diff he linked to.)
[01:34] <bluesabre> aha
[01:34] <Unit193> (Note, that may not be the proper change, but it's a test at least.)
[01:35] <bluesabre> if it works, its better than what we have now ;)
[01:35] <Unit193> Now, I need to bookmark that site, because that's a nice diff tool.
[01:36] <bluesabre> well, if we are happy with it, I can toss it into a PPA and request some testing
[01:37] <Logan_> Unit193: I figured it had something to do with that
[01:37] <Unit193> bluesabre: See? ^  Already knew.
[01:37] <bluesabre> :)
[01:39] <Unit193> http://paste.openstack.org/show/75380 This is what I used.
[01:41] <Unit193> Logan_: Another oddity, the libdrm include.
[01:43] <Logan_> Unit193: that's because it's a B-D of something else in Debian but not in Ubuntu
[01:44] <Unit193> Yes, but adding the dep didn't include it, not even sure it's needed for anything.
[01:46] <Unit193> bluesabre: Is there a need to test it?
[01:47] <bluesabre> I don't think so
[01:47] <bluesabre> I mean, it works :D
[01:48] <bluesabre> I'll make a branch with that and poke Logan_ to merge it ;)
[01:49] <Logan_> sure :)
[01:49] <Unit193> Is this something we can push to Corsac? :/
[01:49]  * Unit193 liked that parole would sync.
[01:50] <bluesabre> we can try
[01:58] <bluesabre> done, poked Corsac
[01:59] <bluesabre> and put the ball in Unit193's court
[01:59] <Unit193> Hah, like I know anything. :P
[01:59] <bluesabre> :D
[01:59] <bluesabre> more than I do in this instance
[01:59] <Unit193> So, I'm done with the parole thing right?  I don't need to do anything else with it since you seem to have it from here?
[02:00] <bluesabre> most likely
[02:00] <bluesabre> I might poke/ping you two more times
[02:02] <starrats> should i file a bug report?
[02:03] <bluesabre> hey starrats
[02:04] <bluesabre> what do you mean by that 'lock-out'?
[02:05] <bluesabre> brb, rebooting my server to fix ssl
[02:05] <starrats> well my cursor is free but when I try to put in my password it won't let me just a flashing line then goes solid
[02:10] <bluesabre> starrats, that sounds odd
[02:11] <bluesabre> go ahead and file a bug, we'll look into it
[02:11] <starrats> okay
[02:12] <starrats> I know it's odd and only happens after a large update/upgrade session on term
[06:29] <jhenke> good morning
[06:47] <brainwash> ochosi: did you test the new xfpm upload?
[06:49] <Noskcaj> Can someone please propose https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfdesktop4/4.11.6 for merging?
[06:49] <Noskcaj> My launchpad won't log in
[06:50] <brainwash> lp broken?
[06:50] <brainwash> Invalid OpenID transaction
[06:51] <Noskcaj> yep
[06:56] <brainwash> now it worked
[07:11] <elfy> brainwash: no inviscursor on this - can't help with that one ...
[07:11] <brainwash> but you are a black screen expert :)
[07:12] <brainwash> I've uploaded power-manager + ochosi's test patch
[07:13] <elfy> ok - when I'm on a real install I will look at that then :)
[07:13] <brainwash> but he claimed that it's somewhat broken, because suspend via power-amaner stopped working for him
[07:14] <elfy> ok - well I'm all up for breaking it if at all possible :D
[07:14] <brainwash> so I've rebuilt and re-uploaded the same thing
[07:15] <elfy> lol
[07:17] <Noskcaj> Unit193, That patch for parole could end rather badly
[07:17] <Noskcaj> since you broke hardening, and the various existing flags
[07:18] <brainwash> did he reveal the patch? :)
[07:19] <Unit193> Noskcaj: That's kind of the point, "breaking" existing flags.
[07:20] <Noskcaj> ok. because relro is on anyway.
[07:20] <Unit193> Did you check?  Is hardening disabled?
[07:21] <Noskcaj> Unit193, I didn't check, i'm just looking at your patch
[07:21] <Noskcaj> And pretty much repeating what corsac said
[07:22] <Unit193> ...He hasn't said anything.  Also, I did kind of say this was good enough to test, but beyond that...
[07:23] <Noskcaj> Unit193, https://bugzilla.xfce.org/show_bug.cgi?id=9904#c10
[07:24] <Unit193> Right, he missed that it's trying to disable a default flag, I think.  But yes, I was hoping for a better way to disable it.
[07:26] <Noskcaj> ok
[07:40] <Unit193> Is indicator-messages broken with the latest update?
[08:37] <elfy> brainwash ochosi : installed xfpm from brainwash's ppa, still black screen where it was failing yesterday
[09:31] <brainwash> elfy: I assume that you've restarted xfpm before doing the test run, right?
[09:36] <elfy> machine had been out of xubuntu and into windows and out again
[09:46] <bluesabre> Unit193: want to proceed on that?
[09:46] <bluesabre> ;)
[09:47] <Unit193> Not quite, still waiting for a better way. :/
[09:49] <bluesabre> :(
[10:03] <Unit193> bluesabre: Could try to push it anyway, can't think of a better way.
[10:04] <bluesabre> want to comment on the bug? Corsac is pretty stubborn about his packages and I really don't "get" what's going on
[10:05]  * Unit193 wonders if bluesabre, the upstream, can fix it so it compiles with -Bsymbolic-functions :P
[10:06]  * bluesabre wouldn't even know where to start
[10:08] <Unit193> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570617
[10:11] <Unit193> bluesabre: Does https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025367.html help you at all?
[10:13] <bluesabre> O.o
[10:13] <bluesabre> I think weak symbols is how parole's plugin system is designed
[10:14] <bluesabre> yeah
[10:15] <bluesabre> it creates a plugin instance
[10:15] <bluesabre> then drops in the plugins functionality, overriding the previously defined methods
[10:16] <Unit193> That's weird, but alright.
[10:16] <bluesabre> I didn't design it
[10:16] <bluesabre> if it were up to me, I'd use totem's python plugin system
[10:16]  * Unit193 blames bluesabre for not changing it. :P
[10:16] <bluesabre> and I suppose it is
[10:16] <Unit193> Eww, python. :P
[10:16] <bluesabre> but thats a lot of work
[10:16] <Unit193> bluesabre: Read about pyston?
[10:17] <bluesabre> nope
[10:17] <Unit193> (Also, think I came up with something I like out of a test env.  Trying it now.)
[10:17] <bluesabre> wait a sec
[10:18] <bluesabre> pyston is a new thing
[10:18] <bluesabre> yet they target python 2.7
[10:18] <bluesabre> kill me
[10:18] <bluesabre> kill -9 1
[10:18] <Unit193> killall5 ?
[10:19] <bluesabre> oh, but its being developed by the dropbox folks
[10:19] <bluesabre> so thats a good thing
[10:22] <Unit193> bluesabre: Fixed it in a way I'd feel OK pushing to the Archive and to Corsac. :)
[10:22] <bluesabre> oh
[10:24] <Unit193> bluesabre: http://paste.openstack.org/show/v1RMkdv0fJ8JNCU6i3Yk/ push that to Log an?
[10:25] <bluesabre> I'll ping Corsac with the new version :)
[10:25] <Unit193> Okay.
[10:37] <bluesabre> sound reasonable?
[10:37] <bluesabre> So, with the above rules, -Bsymbolic-functions flag is removed as it breaks parole.
[10:37] <bluesabre> Referring to this write-up, https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025367.html
[10:37] <bluesabre> Rewriting Parole's plugin architecture would be a huge undertaking.  Parole relies on weak symbols to initialize a plugin.  Here, a base plugin's interface is overridden by the actual plugin's functionality. the -Bsymbolic-functions flag completely breaks that. Adding this protection to the packaging ensures that plugins will continue to build correctly even when default build flags are altered (as they are in Ubuntu).
[10:38] <brainwash> Noskcaj: finally xfdesktop4 4.11.6, thanks!
[10:39] <brainwash> you can close bug 1302101 then
[10:39] <bluesabre> brainwash, Noskcaj: huzzah! :)
[10:39] <Unit193> bluesabre: As long as it's helpful to link to that, sure.
[10:39] <bluesabre> it is for me
[10:40] <bluesabre> that helped me understand the source of the issue
[10:40] <Unit193> Great!  Glad I could be helpful. :)
[10:40] <bluesabre> and why it never happens when building normally
[10:40] <Unit193> Also, see x-dev?
[10:45] <brainwash> elfy: looks like we need a different approach to fix this, I've uploaded xfpm + another patch which tweaks the timings when triggering the lock screen
[10:46] <Unit193> brainwash: Status of xfce4-indicator-plugin and indicator-service-start event?
[10:46] <brainwash> waiting to be merged, bluesabre prepared the branch
[10:47] <brainwash> https://code.launchpad.net/~smd-seandavis/ubuntu/trusty/xfce4-indicator-plugin/upstart-init
[10:48] <brainwash> instead of hardcoding it, we could use an upstart job to start the indicator services
[10:49] <brainwash> but our current solution works fine too
[10:56] <bluesabre> Unit193: <Corsac> also, would it not be possible to remove the linker flag from the build systems itself, so it gets removed only for plugins, not for the whole stuff (or would it need to be removed for the main binary, actually?)
[10:56] <bluesabre> I'm thinking no, but how would something like that be done from the d/rules?
[11:06] <brainwash> wow, so many uploads (thunar, xfdesktop4, xfwm4)
[11:08] <Unit193> bluesabre: That'd be somehow in the makefile, no?
[11:09] <Unit193> http://paste.openstack.org/show/sy6gQIx34EWDeXxJe3Ds works for me.
[11:19] <Unit193> Upstart job does make sense, unless you don't use a user session (can you do this?)
[11:30] <bluesabre> if yes, dunno where or how :)
[11:32] <bluesabre> I'll check it out tonight
[11:32] <bluesabre> RC tomorrow, let me know if there is anything I need to focus my efforts on next
[11:32] <bluesabre> bbl
[12:20] <ochosi> brainwash: sorry, no testing for me until maybe next week, i'll be mostly afk
[12:25] <brainwash> ochosi: ok :/
[13:28] <RFleming> Good day!
[13:33] <RFleming> Quick question.  Lately it seems when I apply updates, I'm losing my wallpaper and am left with plain grey
[13:34] <RFleming> I'm using the default 14.04 xubuntu-wallpaper
[13:38] <starrats> RFleming this is also happening to me but i have imported a few photos to be my wallpaper.
[13:38] <elfy> RFleming: fix is in pipeline
[13:39] <starrats> so I need not to add to my bug report on this elfy?
[13:39] <elfy> me too existing bugs where they exist please
[13:40] <RFleming> elfy, what's the bug #?
[13:40]  * RFleming REALLY needs to learn how to use launchpad
[13:41] <starrats> I filed a bug report last night per bluesabres request on my problem and the plain gray screen is part of that, just forgot to add it in the comment section of the report
[13:41] <RFleming> elfy, starrats I've been using the lack of a background as a 'notice' to reboot :)
[13:43] <brainwash> please install the latest updates
[13:45] <starrats> brainwash who?
[13:46] <brainwash> both of you
[13:46] <starrats> ok
[13:46] <brainwash> after doing so and relogging once bug 1302101 should be fixed
[13:51] <starrats> updaste is finished for me, but when i run upgrade right after update that's when my screen will turn 'dirty white' and then i get locked out from logging back in and it takes afew times
[13:51] <starrats> to get bak on
[13:52] <starrats> that is the bug report i filed last night
[13:52] <elfy> I think that you have got serious issues if you still have this being locked out issue
[13:52] <starrats> this is of course after i re-started my comp from running those two in term.
[13:53] <starrats> my cursor is 'free' now so i don't know
[13:53] <starrats> this morning I got on te first time so i think there's another issue elfy
[13:55] <brainwash> Logan_: hey, are you in the mood to prepare yet another bugfix release?
[13:58] <brainwash> Logan_: if yes, please take a look at https://bugs.launchpad.net/ubuntu/+source/abiword/+bugs?orderby=-id&start=0 - we got 3 patches for abiword
[13:59] <elfy> hi brainwash
[14:00] <brainwash> hey elfy :)
[14:00] <elfy> not sure where we got to with this suspend thing - to recap, I upgraded to your ppa version - logged out - no difference with lid close
[14:01] <brainwash> apt-cache policy xfce4-power-manager?
[14:01] <brainwash> which version
[14:01] <elfy> you want me to turn it on again lol
[14:02]  * elfy wanted to debug with a guessing game today :D
[14:02] <brainwash> check your apt-get history then
[14:03] <elfy> 1.2.0-3ubuntu4
[14:03] <brainwash> ok, thanks
[14:03] <elfy> it's not this machine :) this is like yours - no lid ;)
[14:04] <starrats> just finished my upgrade and the screen went dirty white half way through the upgrade.
[14:04] <mzr1> a laptop....with no lid....*mind blown*...
[14:04] <elfy> starrats: yes it will - just do it and then logout/in and it will be fixed
[14:05] <starrats> ok
[14:05] <brainwash> desktop pc
[14:05] <brainwash> :D
[14:05] <starrats> why though elfy does it do that?
[14:05] <starrats> tell me after I log back in
[14:06] <elfy> brainwash: afaik that's the one from your ppa
[14:13] <xnox> so the debian splash is comming from usr/share/wallpapers/joy_inksplat/contents/screenshot.png
[14:13] <brainwash> it's the fallback option, or?
[14:13] <xnox> where is the desired background?
[14:14] <xnox> (on the cd)
[14:14] <Logan_> brainwash: I'll take a look at abiword later today
[14:16] <xnox> found it in /usr/share/xfce4/backdrops
[14:16] <brainwash> Logan_: thanks :)
[14:17] <brainwash> xnox: installed by the package xubuntu-artwork
[14:20] <brainwash> xnox: did http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6044 break it?
[14:31] <xnox> brainwash: elfy: who/what/where paints the background on a full xubuntu session these days?
[14:32] <xnox> the debian swoosh is painted by unity-settings-daemon, which doesn't have any key set and it looks like in inherited schemas from debian they do paint backgrounds with gnome-settings-daemon (or at least synchronise the settings there)
[14:33] <xnox> if there is a xubuntu gsettings schemas overrides package we could fix it there
[14:33] <elfy> xnox: I'm not sure tbh
[14:33] <xnox> alternatively we should be loading the desktop wallpaper natively, i thought xsettingsd should do it
[14:33] <brainwash> xnox: there is, in xubuntu-default-settings
[14:33] <xnox> but it only loads up a black screen.
[14:35] <brainwash> http://bazaar.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk/files/head:/debian/
[14:35] <xnox> thanks looking.
[14:39] <brainwash> xnox: so I guess all flavors which don't use gsettings to specify the background should be affected by this problem, or?
[14:39] <xnox> elfy: brainwash: the "background" override pointing at debian image is comming from desktop-base package which seems to be xfce4 dependency
[14:39] <xnox> previously there was no unity-settings-daemon nor gnome-settings-daemon on the xubuntu images, and thus something Xfcish painted the background.
[14:43] <brainwash> sounds rather confusing
[14:44] <brainwash> so overriding the background value won't help in this case?
[14:45] <xnox> so i've launched xfce4-settings-manager and it shows that my background is correct - e.g. the mouse picture
[14:45] <xnox> yet my background is black
[14:45] <xnox> how come?
[14:45] <brainwash> in a normal session?
[14:46] <xnox> no, ubiquity
[14:46] <brainwash> xfdesktop4 usually paints the desktop background
[14:47] <brainwash> does "xfdesktop --reload" restore the background?
[14:49] <xnox> brainwash: that works, but i get icons on the desktop =))))
[14:49] <brainwash> that means that xfdesktop4 isn't being used in the first place
[14:49] <xnox> any key i can set to disable icons?
[14:50] <brainwash> will this affect the live session?
[14:51] <xnox> no, i'll revert the key
[14:51] <brainwash> http://bazaar.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk/view/head:/etc/xdg/xdg-xubuntu/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml
[14:51] <brainwash> this is the config file for xfdesktop4
[14:52] <brainwash> now it's getting really confusing :)
[14:54] <brainwash> and what about lubuntu and co? shouldn't there be solution which works for every flavor?
[14:54] <brainwash> sadly I'm not familiar with ubiquity at all
[14:54] <xnox> well it used be gnome-settings-daemon that painting the background. let's tinker further.
[14:56] <brainwash> what about something simple like feh or hsetroot?
[14:56] <xnox> oh, there is xsetroot codepath and feh codepaths but i don't want to use them =)
[14:56] <xnox> i'd rather drop them.
[14:56] <xnox> let me see.
[14:58] <brainwash> anything that works would be fine.  we don't want to ship a LTS release and confuse the user with a debian background :)
[15:09] <elfy> indicator-messages appears to have taken a hit like indicator-sound did
[15:11] <brainwash> it disappeared?
[15:15] <elfy> yep - after the recent update/grade - deactivated in autostart apps
[15:16] <brainwash> kinda expected change
[15:16] <elfy> because?
[15:17] <elfy> I thought we were using -messages?
[15:18] <brainwash> we do, but the autostart launchers for the different indicators have been or will be changed
[15:19] <brainwash> https://code.launchpad.net/~smd-seandavis/ubuntu/trusty/xfce4-indicator-plugin/upstart-init/+merge/214713
[15:19] <brainwash> ^
[15:21] <brainwash> xnox: the init process does not exit immediately, we need to save the PID to kill it on logout
[15:22] <brainwash> initially we called the init process twice (copy&paste failure), this resulted in an init process still running after logout and there keeping the session alive
[15:22] <brainwash> therefore
[15:23] <brainwash> btw lightdm-gtk-greeter and unity-greeter do it the same way
[15:25] <xnox> brainwash: i'm not involved in that at all.
[15:25] <xnox> brainwash: i dislike starting indicators via upstart user session only. Imho they should have stayed dbus-activatable.
[15:25] <brainwash> xnox: indeed :(
[15:25] <brainwash> but we need to fix this now asap
[15:26] <xnox> brainwash: also I'm Dimitri and I'm not Dmitry Shachnev (mitya57)  =)
[15:26] <brainwash> xnox: oh... my fault, sorry
[15:26] <brainwash> got it mixed up
[15:26] <xnox> figured as much =)
[15:27] <brainwash> really stressful days before the final release :D
[15:32] <elfy> and we still have to finallyt decide to throw ibus out today
[16:12] <brainwash> xnox: wow, you've already uploaded x-d-s 14.04.4, thanks a lot :)
[16:14] <brainwash> ochosi: maybe we should migrate <control> to <primary> before release, see bug 1299637
[17:26] <elfy> knome: so it's i-day - my vote is remove ibus
[17:33]  * starrats is not a happy camper at this moment, when Trusty tahr is released on the 17th, next week, I will be burning a new image and do a total install hoping all is fixed
[17:41] <Pwnna> are we fixing that issue with no screen after login anytime soon? i like lightlocker and wish to reenable it
[17:43] <elfy> what bug number is that?
[17:44] <elfy> Pwnna: you mean the black screen after suspend one?
[17:48] <Pwnna> yeah
[17:48] <Pwnna> power manager doesn't get power.
[17:48] <Pwnna> elfy: that one
[17:49] <Pwnna> it's an upstream one
[17:49] <elfy> if it's the same one as the one we've spent hours on lately - do you get the issue if you suspend from menu?
[17:50] <elfy> I can only replicate it as suspend with lid close
[17:59] <brainwash> can anyone please re-enable the xfce4-power-manager try icon (settings manager > power manager > show icon always) and then suspend the system via the new tray icon?
[17:59] <brainwash> someone who can reproduce the black screen issue
[18:02] <brainwash> elfy: I've noticed that if you set the keyboard layout manually (e.g. setxkbmap de) and then start ibus-daemon, ibus will pick the correct kb layout just fine
[18:02] <brainwash> so a workaround is possible
[18:03] <elfy> brainwash: that's as maybe - there are other workarounds possible - at the moment though we cannot use it and it just work
[18:03] <elfy> my vote won't be changing ;)
[18:03] <elfy> if it's fixed by .1 then I don't mind it being put back
[18:04] <brainwash> we read the system layout config and re-set it via setxkbmap on an early stage of the session startup
[18:05] <brainwash> sadly it is a bit late for experiments
[18:06] <brainwash> but a workaround seems to be possible, maybe even a proper solution with this information in minde
[18:06] <brainwash> mind
[18:06] <elfy> suspend from tray icon works fine here
[18:06] <elfy> bbl
[18:23] <brainwash> elfy: I've installed light-locker on my main system (13.10) and suspend via lid close managed by xfpm works fine here
[18:28] <elfy> ok
[18:33] <brainwash> elfy: can you check light-locker-settings please
[18:35] <brainwash> is "automatically lock the session" set to "... is deactivated"?
[18:36] <elfy> auto lock session is set to never
[18:37] <brainwash> ok
[18:39] <brainwash> time to watch soccer, cya :)
[18:39] <elfy> cya
[20:20] <ochosi> ali1234: comments on the comment from mitya on https://code.launchpad.net/~smd-seandavis/ubuntu/trusty/xfce4-indicator-plugin/upstart-init/+merge/214713 ?
[20:20] <Unit193> ochosi: You see the upstart job I created this morning?
[20:20] <ochosi> sry, no, was busy/away all day
[20:20] <ochosi> only have a few minutes now, then i have to run off again
[20:21] <ochosi> so you wanna fix this outside the plugin?
[20:21] <Unit193> That was the idea brainwash had, I just tried it and it's not bad.
[20:22] <ochosi> the downside is that then indicators get started no matter what
[20:22] <ochosi> so if you don't have the plugin in the panel, the services still start
[20:22] <ochosi> that's a bit meh
[20:22] <ochosi> and that was the main reason i seconded the inclusion of the job in the plugin
[20:30] <Unit193> Also, no, it doesn't quit.
[20:30] <ochosi> yeah
[20:30] <ochosi> we'd have to patch xfce4-session to send that signal
[20:30] <ochosi> so meh, let's stick with the plugin solution for now
[20:31] <ochosi> unless you guys come up with another solution that is nicer
[20:36] <Unit193> "You guys" :P
[20:40] <brainwash> you can write a better upstart job
[20:40] <brainwash> not such a basic one
[20:40] <brainwash> but there is no need for it :)
[20:41] <ali1234> bluesabre: i just spotted a bug in the indicator patch...
[20:41] <ochosi> oh, good that it hasn't been uploaded then
[20:42] <ali1234> it's a trivial bug that won't actually affect anything
[20:42] <ochosi> still time to update the merge-request
[20:42] <ali1234> i will fix the error message too
[20:42] <ochosi> well there are also those comments about storing PID and error message
[20:42] <ochosi> so we can amend the patch
[20:42] <ali1234> libupstart is a bit of a big change this close to release
[20:42] <ali1234> storing the pid is a requirement
[20:42] <ochosi> yeah, i think they're aware of that
[20:42] <Unit193> ochosi: But, he's wrong on that point as it doesn't exit.
[20:42] <ali1234> yeah ^
[20:43] <ochosi> right, i didn't read the comment very closely, tbh
[20:43] <Unit193> Also, anyone else getting resolvconf failing to write any nameserver in /etc/resolv.conf and just blanking it? ;/
[20:43] <ochosi> mostly wanted to forward it to ali1234 as i wasn't sure whether he's subscribed to it
[20:44] <ochosi> Unit193: what was the result on parole btw?
[20:44] <ochosi> only saw some backlog, but not enough time to read it all
[20:44] <Unit193> ochosi: Uhh, I made it so I like the change now, I don't see why it can't be uploaded.
[20:45] <ochosi> that sounds good
[20:45] <Unit193> http://paste.openstack.org/show/9bRq11DcdahwuW5A7pJv/ something like that (drop the prefixed space.)
[20:45] <ochosi> bbl
[20:56] <Unit193> Logan_: Ready for upload: http://paste.openstack.org/show/CA7tPtWrKXWZ5txofePk or https://sigma.unit193.net/source/parole_0.6.1-0ubuntu2.dsc depending on what you like.
[20:59] <Logan_> Unit193: tarball plz
[20:59] <Logan_> meh, I guess it's okay
[20:59] <Unit193> It's there, dget should find it fine...
[21:04] <Unit193> Anything else needed?
[21:06] <Logan_> Unit193: no, not at the moment
[21:06] <Logan_> although, do you know why it works?
[21:07] <Unit193> Yes.
[21:07] <Unit193> https://bugzilla.xfce.org/show_bug.cgi?id=9904#c12  And, \o/
[21:12] <Logan_> ah, I see
[21:15]  * Unit193 seemingly actually knows something, even if he doesn't use parole at all. :D
[21:37] <Logan_> Unit193: uploaded
[21:37] <Logan_> thanks for your help, Unit :)
[21:39] <Unit193> Logan_: Thanks for all your help!
[21:39] <Logan_> yup, no problem
[21:39] <Logan_> I should really study for this exam ugh
[21:39] <Logan_> #collegeproblems
[21:39] <Unit193> Hah, before it hits #ohcrapnotthattimeagain. :P
[21:40] <Logan_> yup :/
[21:40] <Logan_> I'm thinking of improving my description on Launchpad
[21:40] <Logan_> but then again no
[22:01] <Noskcaj>  Logan_ once you give up studying, can you look at lp:~noskcaj/ubuntu/trusty/xfce4-xkb-plugin/lp-733563  ?
[22:12] <knome> can agree with elfy; we should probably drop ibus and reintroduce it for .1 if it seems to make any sense (eg. the bug is fixed and there are actually people who are bothered by it not being installed)
[22:22] <ochosi> knome: +1
[22:22] <ochosi> thanks a lot for the fix Unit193
[22:22] <ochosi> and thanks for uploading, Logan_
[22:23] <knome> if we want to dig a bit deeper, we could talk with somebody who actually uses ibus with xubuntu
[22:24] <knome> and ask them how big inconvenience it would be to have to install ibus
[22:24] <ochosi> yeah, i guess those ppl will get in touch with us anyhow if ibus isn't there anymore :)
[22:24] <knome> we don't even seed any languages that would need ibus to input, i guess
[22:27] <ochosi> does the whole section "input methods" go?
[22:27] <ochosi> http://bazaar.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.trusty/view/head:/desktop#L30
[22:27] <ochosi> i mean is im-config good for anything without ibus?
[22:28] <ochosi> oh right, seems unrelated
[22:28] <ochosi> so only the ibus stuff would go
[22:30] <brainwash> let it go, let it go!
[22:38] <brainwash> ochosi: I've installed light-locker on 13.10 and suspend via lid close managed by xfpm works fine for me
[22:38] <ochosi> hm, is that good news?
[22:38] <ochosi> sorry that i have to take off again
[22:39] <brainwash> dunno
[22:48] <Unit193> ochosi: Sure thing, glad I could help.
[22:48] <knome> thanks Unit193
[22:48] <ochosi> Unit193: since you've tampered with seed files before, in case you wanna take a look at the desktop-seed merge i proposed...
[22:49] <ochosi> just to be sure
[22:49] <ochosi> thanks and night!
[22:49] <Unit193> Sure, but not right now.  Checked to see what depends on it?
[22:49] <ochosi> nope, that's exactly why i'm asking others to review it ;)
[22:50] <ochosi> (because i wouldn't have thought of that, not because i didn't want to do the work)
[23:59] <bluesabre> ali1234: would you say its worthy of a separate merge?
[23:59] <bluesabre> or has mine been merged yet
[23:59]  * bluesabre needs to get his ideas in order


[00:56] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3366 Generating diffs
[04:07] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3366 Failed to build
[09:30] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3367 Preparing packages
[09:35] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3367 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[09:37] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3367 Generating diffs
[11:28] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3367 Pending binary packages
[11:45] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3285 Needs rebuild due to higher version at destination
[11:47] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3367 Successfully built
[13:03] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3363 Needs rebuild due to higher version at destination
[14:06] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3365 Publishing packages
[14:18] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3356 Diff missing (cosmic/ubuntu-sounds). Needs rebuild due to burned version number (cosmic/yaru-theme). Needs rebuild due to higher version at destination (cosmic/ubuntu-settings). Release pocket (cosmic/mutter). Successfully built (cosmic/gnome-session, cosmic/gnome-shell, cosmic/meson, cosmic/ubuntu-themes)
[14:26] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3365 Proposed pocket
[14:48] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3368 Ready to build
[14:56] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3368 Preparing packages
[15:08] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3368 Needs rebuild due to higher version at destination
[15:11] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[15:32] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Pending binary packages
[15:52] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Diff missing
[15:56] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3370 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[15:58] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3370 Generating diffs
[16:10] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3371 Preparing packages
[16:31] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3370 Successfully built
[17:05] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3365 Release pocket
[17:11] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3371 Successfully built
[17:49] -queuebot:#ubuntu-ci-eng- bdmurray, https://bileto.ubuntu.com/#/ticket/3328 Needs rebuild due to higher version at destination
[18:16] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3372 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[18:18] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3372 Generating diffs
[18:29] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3346 Needs rebuild due to higher version at destination (cosmic/dolphin, cosmic/k3b, cosmic/kmag, cosmic/okular). Proposed pocket (cosmic/ffmpegthumbs, cosmic/filelight, cosmic/granatier, cosmic/gwenview, cosmic/kaccounts-integration, cosmic/kaccounts-providers, cosmic/kalzium, cosmic/kamera, cosmic/kamoso, cosmic/kanagram, cosmic/kapman, cosmic/kapptemplate, cosmic/katomic, cosmic/kblackbox, cosmi
[18:33] -queuebot:#ubuntu-ci-eng- tsimonq2 mitya57 acheronuk, https://bileto.ubuntu.com/#/ticket/3291 Needs rebuild due to higher version at destination (cosmic/analitza, cosmic/kwin, cosmic/kxmlgui, cosmic/libqtxdg, cosmic/plasma-integration, cosmic/pythonqt, cosmic/qt3d-opensource-src, cosmic/qtav, cosmic/qtbase-opensource-src, cosmic/qtcharts-opensource-src, cosmic/qtconnectivity-opensource-src, cosmic/qtcurve, cosmic/qtdeclarative-opensource-src, cosmic/qtgraphicaleffects-
[18:33] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3372 Successfully built
[18:36] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3373 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[18:46] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3345 Release pocket
[18:49] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3346 Needs rebuild due to higher version at destination (cosmic/dolphin, cosmic/k3b, cosmic/kmag, cosmic/okular). Release pocket (cosmic/ark, cosmic/artikulate, cosmic/audiocd-kio, cosmic/baloo-widgets5, cosmic/blinken, cosmic/bomber, cosmic/bovo, cosmic/cervisia, cosmic/dolphin-plugins, cosmic/dragon, cosmic/ffmpegthumbs, cosmic/filelight, cosmic/granatier, cosmic/gwenview, cosmic/kaccounts-integr
[18:52] -queuebot:#ubuntu-ci-eng- tsimonq2 mitya57 acheronuk, https://bileto.ubuntu.com/#/ticket/3291 Needs rebuild due to higher version at destination (cosmic/analitza, cosmic/kwin, cosmic/kxmlgui, cosmic/libqtxdg, cosmic/plasma-integration, cosmic/pythonqt, cosmic/qt3d-opensource-src, cosmic/qtav, cosmic/qtbase-opensource-src, cosmic/qtcharts-opensource-src, cosmic/qtconnectivity-opensource-src, cosmic/qtcurve, cosmic/qtdeclarative-opensource-src, cosmic/qtgraphicaleffects-
[19:12] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Currently building (cosmic/kdepim-addons, cosmic/kdepim-runtime, cosmic/kf5-messagelib, cosmic/kopete, cosmic/libkf5libkleo, cosmic/libkgapi, cosmic/syndication). Diff missing (cosmic/akonadi, cosmic/akonadi-contacts, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/calligra, cosmic/digikam, cosmic/kalarm, cosmic/kjots, cosmic/kmymoney, cosmic/zanshin). Failed to build (cosmic/kmail, cosmi
[19:21] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3346 Merging branches
[19:23] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3374 Preparing packages
[19:24] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3374 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[19:32] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Currently building (cosmic/kdepim-addons, cosmic/kdepim-runtime, cosmic/kopete). Diff missing (cosmic/akonadi-calendar, cosmic/akonadi-calendar-tools, cosmic/akonadi-contacts, cosmic/akonadi-import-wizard, cosmic/akonadi-mime, cosmic/akonadi-notes, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/calligra, cosmic/digikam, cosmic/grantlee-editor, cosmic/kaddressbook, cosmic/kalarm, cosmic/k
[19:38] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3374 Needs rebuild due to higher version at destination (cosmic/pkg-kde-tools). Pending binary packages (cosmic/attica-kf5, cosmic/baloo-kf5, cosmic/bluez-qt, cosmic/breeze-icons, cosmic/extra-cmake-modules, cosmic/frameworkintegration, cosmic/kactivities-kf5, cosmic/kactivities-stats, cosmic/kapidox, cosmic/karchive, cosmic/kauth, cosmic/kbookmarks, cosmic/kcmutils, cosmic/kcodecs, cosmic/kcomplet
[19:41] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3371 Publishing packages
[19:52] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Diff missing (cosmic/akonadi, cosmic/akonadi-calendar, cosmic/akonadi-calendar-tools, cosmic/akonadi-contacts, cosmic/akonadi-import-wizard, cosmic/akonadi-mime, cosmic/akonadi-notes, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/akregator, cosmic/calligra, cosmic/digikam, cosmic/grantlee-editor, cosmic/kaddressbook, cosmic/kalarm, cosmic/kalarmcal, cosmic/kblog, cosmic/kcalcore, cosmic
[19:52] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3371 Proposed pocket
[19:53] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3373 Diff missing
[19:55] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3373 Generating diffs
[19:56] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3373 Successfully built
[19:58] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3356 Diff missing (cosmic/ubuntu-sounds). Needs rebuild due to burned version number (cosmic/yaru-theme). Needs rebuild due to higher version at destination (cosmic/gnome-session, cosmic/ubuntu-settings). Release pocket (cosmic/mutter). Successfully built (cosmic/gnome-shell, cosmic/meson, cosmic/ubuntu-themes)
[19:58] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3374 Pending binary packages
[20:12] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Diff missing (cosmic/akonadi, cosmic/akonadi-calendar, cosmic/akonadi-calendar-tools, cosmic/akonadi-contacts, cosmic/akonadi-import-wizard, cosmic/akonadi-mime, cosmic/akonadi-notes, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/akregator, cosmic/calligra, cosmic/digikam, cosmic/grantlee-editor, cosmic/kaddressbook, cosmic/kalarm, cosmic/kalarmcal, cosmic/kblog, cosmic/kcalcore, cosmic
[20:13] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3373 Pending binary packages
[20:18] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3374 Diff missing
[20:32] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Currently building (cosmic/libkf5libkdepim). Diff missing (cosmic/akonadi, cosmic/akonadi-calendar, cosmic/akonadi-calendar-tools, cosmic/akonadi-contacts, cosmic/akonadi-import-wizard, cosmic/akonadi-mime, cosmic/akonadi-notes, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/akregator, cosmic/calligra, cosmic/digikam, cosmic/grantlee-editor, cosmic/kaddressbook, cosmic/kalarm, cosmic/kal
[20:33] -queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3373 Successfully built
[20:52] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Diff missing (cosmic/akonadi, cosmic/akonadi-calendar, cosmic/akonadi-calendar-tools, cosmic/akonadi-contacts, cosmic/akonadi-import-wizard, cosmic/akonadi-mime, cosmic/akonadi-notes, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/akregator, cosmic/calligra, cosmic/digikam, cosmic/grantlee-editor, cosmic/kaddressbook, cosmic/kalarm, cosmic/kalarmcal, cosmic/kblog, cosmic/kcalcore, cosmic
[21:12] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Currently building (cosmic/knotes, cosmic/libkf5ksieve, cosmic/libkf5mailcommon). Diff missing (cosmic/akonadi, cosmic/akonadi-calendar, cosmic/akonadi-calendar-tools, cosmic/akonadi-contacts, cosmic/akonadi-import-wizard, cosmic/akonadi-mime, cosmic/akonadi-notes, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/akregator, cosmic/calligra, cosmic/digikam, cosmic/grantlee-editor, cosmic/ka
[21:18] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3356 Diff missing (cosmic/ubuntu-sounds). Needs rebuild due to burned version number (cosmic/yaru-theme). Needs rebuild due to higher version at destination (cosmic/gnome-session, cosmic/mutter, cosmic/ubuntu-settings). Successfully built (cosmic/gnome-shell, cosmic/meson, cosmic/ubuntu-themes)
[21:32] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3371 Release pocket
[21:32] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Currently building (cosmic/libkf5eventviews, cosmic/libkf5mailcommon). Diff missing (cosmic/akonadi, cosmic/akonadi-calendar, cosmic/akonadi-calendar-tools, cosmic/akonadi-contacts, cosmic/akonadi-import-wizard, cosmic/akonadi-mime, cosmic/akonadi-notes, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/akregator, cosmic/calligra, cosmic/digikam, cosmic/grantlee-editor, cosmic/kaddressbook,
[21:52] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Currently building (cosmic/pim-data-exporter, cosmic/pim-sieve-editor). Diff missing (cosmic/akonadi, cosmic/akonadi-calendar, cosmic/akonadi-calendar-tools, cosmic/akonadi-contacts, cosmic/akonadi-import-wizard, cosmic/akonadi-mime, cosmic/akonadi-notes, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/akregator, cosmic/calligra, cosmic/digikam, cosmic/grantlee-editor, cosmic/kaddressbook
[22:12] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3369 Currently building (cosmic/korganizer). Diff missing (cosmic/akonadi, cosmic/akonadi-calendar, cosmic/akonadi-calendar-tools, cosmic/akonadi-contacts, cosmic/akonadi-import-wizard, cosmic/akonadi-mime, cosmic/akonadi-notes, cosmic/akonadi-search, cosmic/akonadiconsole, cosmic/akregator, cosmic/calligra, cosmic/digikam, cosmic/grantlee-editor, cosmic/kaddressbook, cosmic/kalarm, cosmic/kalarmca
[23:17] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3374 Currently building (cosmic/baloo-kf5, cosmic/kdelibs4support, cosmic/kemoticons, cosmic/kfilemetadata-kf5, cosmic/kglobalaccel, cosmic/kguiaddons, cosmic/ki18n, cosmic/kiconthemes, cosmic/kinit, cosmic/kio, cosmic/kirigami2, cosmic/kitemmodels, cosmic/kpeople, cosmic/kross, cosmic/ksyntax-highlighting, cosmic/kunitconversion, cosmic/kwayland, cosmic/kwidgetsaddons, cosmic/kwindowsystem, cosmic
[23:37] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3374 Currently building (cosmic/kwayland, cosmic/kwidgetsaddons, cosmic/modemmanager-qt, cosmic/networkmanager-qt, cosmic/oxygen-icons5, cosmic/solid, cosmic/sonnet, cosmic/threadweaver). Diff missing (cosmic/attica-kf5, cosmic/bluez-qt, cosmic/breeze-icons, cosmic/extra-cmake-modules, cosmic/kactivities-kf5, cosmic/kactivities-stats, cosmic/kapidox, cosmic/karchive, cosmic/kauth, cosmic/kbookmarks
[23:58] -queuebot:#ubuntu-ci-eng- acheronuk, https://bileto.ubuntu.com/#/ticket/3374 Currently building (cosmic/oxygen-icons5). Diff missing (cosmic/attica-kf5, cosmic/baloo-kf5, cosmic/bluez-qt, cosmic/breeze-icons, cosmic/extra-cmake-modules, cosmic/frameworkintegration, cosmic/kactivities-kf5, cosmic/kactivities-stats, cosmic/kapidox, cosmic/karchive, cosmic/kauth, cosmic/kbookmarks, cosmic/kcmutils, cosmic/kcodecs, cosmic/kcompletion, cosmic/kconfig, cosmic/kconfigwidgets,