[05:46] <Mirv> doko_: qt pong
[05:57] <pitti> teward, infinity: yes, jenkins broke down again yesterday, sorry for the noise
[05:57] <pitti> Good morning
[08:12] <dholbach> good morning
[08:35] <Tribaal> hi guys! I found a regression in LXC on Vivid, how can I help with fixing it, besides opening a launchpad bug?
[08:47] <pitti> Tribaal: I suggest talking to stgraber or hallyn, they are upstream (but probably both asleep right now)
[08:52] <Tribaal> pitti: I shall
[09:17] <geser> pitti: Hi, do you know by chance if the systemd (packaging) helpers cope well with a backslash in a unit name? (run-vmblock\x2dfuse.mount)
[09:17] <pitti> geser: I haven't seen those myself yet, so I'm afraid I don't know
[09:21] <geser> pitti: during an update a couple days ago, I got some messages where I'm not sure if expected or the result of the \ in the filename
[09:22] <geser> like "Failed to get unit file state for run-vmblockx2dfuse.mount: No such file or directory" (no \ before the x2d) and "run-vmblock\x2dfuse.mount is a disabled or a static unit, not starting it."
[09:23] <geser> the package was "open-vm-tools-desktop"
[09:37] <Odd_Bloke> pitti: I've added a Wants/After dependency on (e.g.) foo.service; is that safe if foo.service doesn't exist on the system?
[09:39] <pitti> Odd_Bloke: yes, it is
[09:39] <pitti> Odd_Bloke: that's what Wants= is for: if it doesn't exist, it is ignored
[09:40] <pitti> Odd_Bloke: (contrary to Requires=)
[09:40] <Odd_Bloke> Great, that's what I thought.
[09:40] <Odd_Bloke> Thanks!
[09:54] <flexiondotorg> Morning. pitti dholbach I've got some feedback about a couple of bugs (one critial in my opinion) and what looks like a trivial fix for both.
[09:55] <flexiondotorg> pitti, dholbach The fix involves grub. Something I am still learning about. Is there someone I can discuss the potential fix with the ensure there are not unintended side affects?
[09:55] <flexiondotorg> pitti, dholbach The bugs are:
[09:55] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/
[09:56] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1386005
[09:57] <flexiondotorg> Both appear to be resolved by adding 'GRUB_TERMINAL=console' to '/etc/default/grub' and running 'update-grub'.
[09:57] <dholbach> flexiondotorg, I'm not sure I'm a good person to discuss these bugs with - I have no idea about any of them :-/
[09:58] <dholbach> pitti might know, or somebody in the foundations team
[09:58] <flexiondotorg> dholbach, I'm asking who I should discuss them with ;)
[09:58] <dholbach> ah ok
[09:58] <flexiondotorg> dholbach, Guessed it would be foundations but the only guys I know in that team are not in my timezone :(
[09:58] <dholbach> https://launchpad.net/~canonical-foundations/+members#active
[09:58] <flexiondotorg> dholbach, Thanks.
[09:59] <dholbach> anytime
[10:00] <pitti> flexiondotorg: there's a chance that cjwatson has time to comment on this, but he's working on other things now
[10:00] <flexiondotorg> pitti, Yeah, I'm trying to not ping cjwatson for everything ;) I know he is a busy man.
[10:00] <pitti> but it seems odd that this would be flavor specific, unless it's a specific problem wiht the plymouht theme?
[10:01] <flexiondotorg> pitti, No flavour specific.
[10:01] <flexiondotorg> pitti, Reproducable on all flavours I tested.
[10:01] <pitti> either way, if this is right, then this would be an "unbreak my system" setting which really shouldn't be in a config file but just be the default
[10:01] <pitti> flexiondotorg: ah, specific to virtualbox then
[10:01] <pitti> flexiondotorg: yeah, QEMU's various graphics card sometimes act up on plymouth too, indeed
[10:02] <flexiondotorg> Yes, that bit is specific to VirtualBox. But the more important fix is being able to enter the full disk encryption passphrase.
[10:02] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1386005
[10:10] <cjwatson> pitti,flexiondotorg: Not at the moment, sorry.
[10:10] <pitti> flexiondotorg: can you select a different graphics card in virtualbox?
[10:11] <pitti> that helps with qemu, anyway
[10:11] <cjwatson> GRUB_TERMINAL=console affecting things indicates that the problem is likely with the graphical console handover to plymouth.
[10:43] <rbasak> hallyn: so about http://paste.ubuntu.com/10626570/
[10:43] <rbasak> It needs the Breaks/Replaces upstart -> upstart-bin as you pointed out.
[10:43] <rbasak> I noticed that that one of the packages (I think apparmor?) has some documentation on how to use apparmor-profile-load - that probably needs to be updated.
[10:44] <rbasak> And the mechanism added to ensure that init-system-helpers is pulled in by every package that uses apparmor-profile-load. infinity suggested that dh_installinit grep for apparmor-profile-load and if found add init-system-helpers to ${misc:Depends}.
[10:44] <rbasak> And then to rebuild affected packages (from my list).
[10:45] <rbasak> Or maybe given the list is small it's OK to require that packages depend on it manually, and then document that where apparmor packaging has it documented already?
[10:46] <rbasak> It looks like lxc would need to explicitly depend on it anyway - or maybe skip it and depend on apparmor and use the new /lib/apparmor/profile-load instead?
[11:02] <GunnarHj> pitti: Hi Martin!
[11:03] <pitti> hey GunnarHj, how are you?
[11:04] <GunnarHj> pitti: Fine, thanks. Hope you are too.
[11:04] <GunnarHj> pitti: Hoping for your input at bug #1435492. The switch to bash in lightdm and gdm means that ~/.bashrc gets sourced unlike before. Good or bad? Or are you neutral?
[11:04] <pitti> GunnarHj: I am, yes, had some nice vacations
[11:04] <pitti> GunnarHj: queueing, I'll respond in the bug report
[11:05] <GunnarHj> pitti: Ok, thanks.
[11:05] <rbasak> Bug 1432715 - FTBFS on Trusty to to the date, but no user-impacting issue right now. SRU-worthy? Might be useful for the security team or any future SRUs. Do we have any process to leave a fix somewhere for someone to find it later in case an update to Trusty is needed?
[11:06] <rbasak> mdeslaur: ^^ do you have an opinion on this please?
[11:08] <mdeslaur> rbasak: I don't think it's SRU-worthy...typically when something FTBFS people will look to see if it got fixed in later releases
[11:08] <rbasak> mdeslaur: OK, thanks. We'll leave it.
[11:08] <mdeslaur> leave the bug open, I'll close it next security update
[11:08] <rbasak> ack
[12:21] <doko> Mirv, please could you have a look at component mismatches and tell if everything can be demoted, which wants to be demoted?
[12:21] <infinity> tedg: remote-login-service is originally your code, right?  Can you have a look at why the testsuite fails miserably when built on vivid (or, alternately, tell me that no one cares and I can remove it :P)
[12:23]  * infinity seeds upstart-sysv to keep it in main.
[12:34] <Mirv> doko: the "binary only movements to universe" portion? qml*/qt* listed seem fine to be in universe for now. qml-module-qtlocation qml-module-qtpositioning may be wanted back at some point, and same for the qmake-arm-cross but currently the SDK is in universe too
[12:35] <Mirv> qtdecla* are transitional dummy packages
[12:37] <infinity> rbasak: Depending directly on apparmor only makes sense if you *require* apparmor to function.  The nice thing about the i-s-h wrapper is that you can make the apparmor use conditional.
[12:37] <infinity> rbasak: But I agree that if the number of packages that call profile-load is reasonably low, it's just as sensible to make them manually depend on it, just like you'd manually depend on any other non-Essential binary you call.
[12:37] <infinity> rbasak: Where "it" is init-system-helpers, not apparmor...
[12:38] <rbasak> infinity: you mean for lxc depending on apparmor? Yeah - I don't know whether lxc *requires* apparmor or not, but I get what you're saying if it doesn't.
[12:38] <rbasak> infinity: OK - thanks. Saves us having to hack on dh_installinit then.
[12:38] <infinity> rbasak: I'm almost positive it doesn't depend on it.
[12:38] <rbasak> Fair enough then.
[12:39]  * Mirv wishes our x86 builders would be as fast as ppc64el builders
[12:39] <infinity> Mirv: I love it when an arch leapfrogs another, and you hear weird statements like that. :)
[12:40] <Mirv> :)
[12:40] <infinity> Mirv: powerpc used to be the fastest ten years ago too, and then we stopped upgrading them for a decade until they were the slowest.  And now they're the fastest again.  Whee.
[12:41] <infinity> rbasak: The nice thing is that init-system-helpers is in minimal so, while packages calling that wrapper absolute MUST depend on init-system-helpers, it's also true that it's a bug you can afford to get wrong, since 99% of people will have it installed. :P
[12:41] <Mirv> yes I still remember the 20h qtwebkit powerpc builds
[12:41] <infinity> rbasak: So, we can fix as we spot the issues.
[12:41] <rbasak> infinity: OK, thanks. I'm more comfortable now that you've seen our plan and have no particular objection to anything :)
[12:42] <infinity> Mirv: "I wish x86 was as fast as powerpc" still isn't as comical as "I wish x86 was as fast as armhf", though (often uttered by people who do massive numbers of builds in parallel, like doko, where kishi's scale out beats the Intel buildds' scale up every time)
[12:53] <tedg> infinity, I can take a look, dbarth was looking after it for a while too, he may have hints as well.
[12:53] <tedg> infinity, Do you have a build log?
[12:54] <pitti> GunnarHj: replied
[12:55] <infinity> tedg: http://lucifer.0c3.net/~adconrad/remote-login-service_1.0.0-0ubuntu3_amd64.build
[12:56]  * tedg clicks
[12:56] <infinity> tedg: One of the failures there is clearly just an attempt to write to ~/.cache, which shouldn't be expected to exist, but the rest look more seriously broken.
[12:57] <tedg> Yeah, looks like the new libnm might have changed things a bit for it.
[12:57] <infinity> tedg: Unless they're all fallout from that same class of bug, in which case it would work on our buildds (where ~buildd does actually exist), but it's still wrong.
[12:57] <tedg> infinity, It's so wrong it's right?
[12:58] <infinity> Heh.
[12:58] <infinity> I keep meaning to remove ~buildd from our buildds, but need to do it at the very beginning of a cycle to have a hope of fixing all the naughty packages that assume $HOME should exist during build.
[13:00] <infinity> tedg: Anyhow, if you could fix this (or tell me to drop it), that would be great, it's the only package keeping libgcrypt11 in the archive now.
[13:00] <infinity> tedg: Which a rebuild would solve... If it could build. :)
[13:01] <tedg> infinity, I think that it's still being used by the unity7 greeter, so we couldn't drop it this late. But I don't know if anyone is actually using the feature, I think we stopped pushing it.
[13:01] <infinity> tedg: Right, well, I'm guessing fixing it won't be hard for someone who knows the code.
[13:01] <tedg> There I think dbarth would know more, but I'm guessing we could drop it in Waffling Walrus.
[13:01] <dbarth> infinity: this service is not maintained anymore; i would suggest to disable and switch to universe
[13:01] <dbarth> tedg: yes, exactly
[13:02] <cjwatson> dbarth: Dropping a package to universe doesn't make a difference in terms of whether it keeps old library packages in the archive.
[13:02] <infinity> dbarth: It's already in universe.  Dropping it from the archive is what I was referring to (if no one can be bothered to fix it).
[13:05] <mdeslaur> kill it with fire! :)
[13:06] <dbarth> ah ok
[13:07] <dbarth> well, then yes; i think the package can be dropped
[13:09] <infinity> dbarth: Alright, works for me.
[13:09] <dbarth> infinity: if you want to file a bug for the build failure; i can comment on it to request the package being removed from the archive
[13:10] <dbarth> to have a record of the request
[13:10] <tedg> dbarth, Then should we remove lightdm-remote* as well?
[13:11] <infinity> tedg: It doesn't depend on it.  Should it have?
[13:12] <infinity> In fact, nothing depends on remote-login-service
[13:12] <tedg> infinity, No, unity-greeter calls those if remote-login-service tells it to. If there's no one to tell it to, they'll just not be used.
[13:14] <dbarth> tedg: yes, as a consequence
[13:14] <dbarth> good catch
[13:18] <infinity> tedg: Alright, removing remote-login-service, tell me what else should go with it.
[13:20] <infinity> tedg: lightdm-remote-session-freerdp and lightdm-remote-session-uccsconfigure?
[13:20] <tedg> infinity, lightdm-remote-session-freerdp lightdm-remote-session-uccsconfigure
[13:20] <tedg> infinity, Yes, we'll also shorten the average package name by like 10 characters :-)
[13:20] <mdeslaur> lol
[13:22] <infinity> tedg, dbarth: All gone from vivid.
[13:26] <dbarth> infinity, tedg: thank you
[13:47] <flexiondotorg> pitti, cjwatson Sorry, was in a meeting all morning.
[13:48] <flexiondotorg> pitti, cjwatson - No, you can't change the "video card" in virtualbox.
[14:01] <pitti> Riddell: note that in your apport upload you are missing mitya57 's followup syntax fix -- like that it just crashes (http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2933)
[14:05] <Riddell> pitti: oh doh, please reject
[15:01] <roaksoax> slangasek: was IPv6 UEFI boot/pxe boot Broken?
[15:15] <flexiondotorg> pitti, cjwatson - I've tested creating /boot/grub/custom.cfg which set the termina input and output to console. That "fixes" the VirtualBox resolution.
[15:16] <flexiondotorg> pitti, cjwatson - I'm now creating a system with full disk encryption to see if the same "fix" allow entry of the passphrase.
[15:16] <flexiondotorg> pitti, cjwatson - I'm still interested to know if there are potential drawback to this approach?
[15:17] <cjwatson> It's not suitable in general; it makes the GRUB menu much less capable and useful.
[15:18] <cjwatson> Fine for narrowing down a bug, or for a local workaround, but it's not a good general fix.
[15:18] <flexiondotorg> cjwatson, OK, understood.
[15:18] <flexiondotorg> cjwatson, What about if I was to create a new configuration file /etc/grub.d that detects the presence of VirtualBox and apply this workaround?
[15:18] <cjwatson> No, stop this.
[15:19]  * flexiondotorg stops.
[15:19] <cjwatson> My guess is that a kernel or maybe X developer needs to look at it.
[15:19] <cjwatson> We shouldn't hack out the graphical handover in GRUB just for this.
[15:19] <cjwatson> If we do need to, there's a blacklisting mechanism already, but it's a last resort.
[15:20] <cjwatson> (grub-gfxpayload-lists)
[15:20] <cjwatson> We generally only use that for non-free drivers where we therefore have no alternative.
[15:22] <cjwatson> flexiondotorg: Now, we do have vmware listed in grub-gfxpayload-lists, so it wouldn't be without precedent to add the relevant virtualbox IDs there first; but a kernel developer should have a look first.
[15:22] <cjwatson> s/ first//
[15:23] <flexiondotorg> cjwatson, OK. I'll try add the vbox IDs to see if the end result is the same.
[15:24] <cjwatson> flexiondotorg: Right; this is less invasive than GRUB_TERMINAL=console because it only disables the handover, not GRUB's entire graphical terminal system.  However, it's also not suitable in general because it disables the system that permits flicker-free boot (insofar as that works properly, but anyway)
[15:24] <cjwatson> Fortunately not many systems appear to need it ...
[15:25] <flexiondotorg> cjwatson, Thanks for the information. All interesting stuff.
[15:51] <flexiondotorg> cjwatson, Adding 11_virtualbox to the grub-gfxpayload-lists works. In as much that graphical boot is disabled, therefore I can always enter my ful disk encryption passphrase and the resulting Vbox resolution is sensisble.
[15:54] <cjwatson> flexiondotorg: OK, can you chase this up with #ubuntu-kernel?  If they declare it hopeless then I'm happy to change grub-gfxpayload-lists
[15:55] <doko> pitti, is the systemd auto pkg test regression real?
[15:55] <flexiondotorg> For reference, here is the ID for the VBOX video device: v80eedbeef.*
[15:56] <flexiondotorg> cjwatson, I'll follow up with #ubuntu-kernel and report back.
[15:56] <cjwatson> flexiondotorg: Thanks
[15:56]  * flexiondotorg updates some bugs with relevant info first.
[16:04] <pitti> doko: uh, it seems it started failing during my holidays, indeed; not an infrastructure issue at least
[16:05] <pitti> apparently the RT overrode that
[16:06] <flexiondotorg> cjwatson, Got a nic I can ping in #ubuntu-kernel?
[16:06] <cjwatson> flexiondotorg: No
[16:07] <strikov> Hi guys. Is it right that package creates /etc/systemd/system/<packagename>.service symlink during installation? This symlink points to /lib/systemd/system/<packagename>.service I thought that /etc/systemd/ is something used on top of /lib/systemd which mean that this symlink is useless. Where I'm wrong?
[16:07] <pitti> doko: I'll wave through the blocked packages
[16:10] <pitti> didrocks: hm, http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-systemd/137/ARCH=i386,label=adt/consoleText started failing on i386 during my holidays (consistently since then)
[16:10] <pitti> all of the failed tests involve lightdm; do you happen to know some changes related to that?
[16:11] <pitti> it coincides with https://launchpad.net/ubuntu/+source/lightdm/1.13.2-0ubuntu1, so that could be a possible reason
[16:15] <flexiondotorg> cjwatson, For completeness. My notes show that I "fixed" the entering your full disk encryption pass phrase issue in my unofficial Ubuntu MATE 14.10 by removing the graphical Plymouth theme and leaving just the text theme.
[16:15] <doko> pitti, and looking for php-zeta-console-tools, gmsh, swift
[16:16] <doko> jamespage, is swift a real regression?
[16:16] <flexiondotorg> cjwatson, The pass phrase entry is not limited to just VirtualBox. Many different hardware video devices are also affected.
[16:22] <cjwatson> flexiondotorg: It's possible that plymouth is failing to deal correctly with being entered in text mode.  I'm sure somebody here can help out with that, but I'm sorry, I can't.
[16:22] <didrocks> pitti: ah, it's consistent, we thought it was random. I would bet on this systemd upload
[16:29] <didrocks> pitti: sorry s/systemd/lightdm/ yeah
[16:56] <arges> hallyn: have you seen bug 1434999? I'm not exactly sure which apparmor rule to fix, any ideas? thanks
[17:40] <flexiondotorg> cjwatson, I've discussed the Vbox video issue in #ubuntu-kernel. Concensus is to blacklist the vbox video device ID in grub-gfxpayload-lists
[17:40] <flexiondotorg> cjwatson, Do you want me to prepare a merge proposal or a debdiff?
[17:40] <flexiondotorg> cjwatson, Or will you take it on?
[17:40] <slangasek> roaksoax: yes, ipv6 uefi boot is broken, bug #1229458
[17:41] <pitti> flexiondotorg: I suggest preparing a bug with a debdiff, and please paste the IRC conversation in it too for the records
[17:43] <flexiondotorg> pitti, This is the existing bug - https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1368784/
[17:43] <flexiondotorg> pitti, Can I added the #ubuntu-kernel discussion to it and attach the debdiff there?
[17:43] <pitti> flexiondotorg: sounds good
[17:43] <flexiondotorg> pitti, Thanks.
[17:45] <cjwatson> flexiondotorg: Bug is fine, yes
[17:46] <cjwatson> flexiondotorg: No need for a debdiff given when you've already added there
[17:55] <cjwatson> flexiondotorg: Uploaded, thanks
[19:03] <hallyn> arges: not clear to me either.  i think jdstrand knows what's up
[19:06] <sarnold> that's not the first bug report I've seen with unexpected lttng-ust-wait-5 denials
[19:31] <jdstrand> hallyn, arges: I've been quite clear-- don't change the policy, disable lttng-ust
[19:31] <jdstrand> or make the open non-fatal
[19:32] <jdstrand> if you adjust the policy, we break guest isolation
[19:32] <jdstrand> we can't do that