[05:33] <dholbach_> good morning
[05:39] <pitti> Good morning
[05:40] <pitti> infinity: yes, on my list to investigate; seems a recent lightdm change during my holidays broke something, but so far I was still caught in backlog
[07:13] <pitti> bdmurray: does errors.u.c. still use -security indexes from ddebs.u.c.? I'd really like to remove them as they are way out of date and confusing to users
[08:49] <pitti> Unit193: hey, how are you?
[08:50] <pitti> Unit193: I'm looking at bug 1431200, and it seems I can't reproduce this any more; can you?
[09:44] <Riddell> mvo: I still get the problem :(
[09:45] <Riddell> mvo: how do I tell ubuntu-bug to upload all the logs?
[09:47] <mvo> Riddell: what base system do you use? anything beyond a stock install of kubuntu 14.10 (this is what I did)?
[09:47] <mvo> Riddell: how did you upgrade, apt itself or a frontend?
[09:48] <Riddell> mvo: stock install of 14.10 (no internet during install)
[09:49] <Riddell> then running /usr/bin/kubuntu-devel-release-upgrade which is a 1 line script to run 'kdesudo "do-release-upgrade -m desktop -f DistUpgradeViewKDE -d"'
[09:53] <mvo> Riddell: ok, let me try that then, I was doing a normal apt-get dist-upgrade
[09:53] <Riddell> mvo: you do know we don't support that right? :)
[09:58] <Riddell> hah seems ubuntu-bug doesn't work anyway because I broke apport, best look at that first :)
[09:58] <pitti> Riddell: QApplication import failure?
[09:59] <pitti> I still get that (see https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1436328/comments/3)
[10:01] <Riddell> pitti: failure at "from PyQt5 uic" which I had thought I'd fixed
[10:01] <Riddell> and I'd expect to have been picked up by pyflakes or something
[10:02] <pitti> Riddell: that's fixed in 2.17-0ubuntu1, uploaded this morning
[10:02] <pitti> Riddell: but I still get an import error on QApplication, apparently python3-pyqt5 isn't sufficient
[10:05] <pitti> Riddell: oh, hmm -- calling apport-kde here actually works now, but the test does
[10:05] <pitti> --- Testing ui_kde ---
[10:05] <pitti> SKIP: PyQt/PyKDE not available: cannot import name 'QApplication'
[10:06]  * Riddell installs to try it
[10:07] <pitti> ah!
[10:07] <pitti> from PyQt5.QtGui import QApplication, QTreeWidget, QIcon
[10:07] <pitti> that ought to be QtWidgets
[10:07] <pitti> Riddell: so just a bug in test/test_ui_kde.py, I'll fix
[10:08] <Riddell> thanks pitti
[10:08] <Riddell> I still can't work out how to report a bug on the release upgrade tool
[10:09] <pitti> Riddell: done in http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2938
[10:09] <pitti> Riddell: so vivid is fine now, and the tests will be fixed with the next upload (not urgent)
[10:11] <Riddell> yay
[10:28] <tseliot> pitti: is it possible that systemd stops gpu-manager before it can finish?
[10:37] <pitti> tseliot: what do you mean? killing it on shutdown?
[10:37] <tseliot> pitti: even on boot
[10:37] <pitti> tseliot: if an Exec* command like ExecStop= doesn't finish in 90 seconds (by default), it gets killed, yes
[10:38] <tseliot> pitti: for example, I see that gpu-manager writes the log saying that xorg.conf was written but then I can't find the file at times
[10:38] <pitti> if a unit fails to start in in 90s, it gets marked as failed, but it doesn't kill anything then
[10:39] <tseliot> pitti: in this case the unit started but I don't think it took 90 seconds to finish
[10:40] <pitti> tseliot: easy enough to tell with "systemctl status gpu-manager"
[10:42] <tseliot> pitti: ah, I'll try that, thanks
[11:05] <flexiondotorg> pitti, This is is not fixed in 15.04 for all flavours - https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875
[11:05] <flexiondotorg> pitti, More over boot is significantly delayed while mounting crypted swap tries and fails.
[11:06] <flexiondotorg> pitti, What can I do to help gather useful information/
[11:06] <pitti> flexiondotorg: can you please reopen with a current /etc/crypttab, /etc/fstab, and blkid output?
[11:06] <flexiondotorg> pitti, So branch new bug?
[11:06] <flexiondotorg> *brand new
[11:06] <xnox> pitti: https://github.com/juju/juju/commit/2ae93fe45df4b95bedf493adc07ee7049859fb2d is not that good. Checkout out the "shell script" to detect what is pid1.
[11:06] <pitti> flexiondotorg: reopening is fine
[11:07] <xnox> pitti: i've commented on it, but imho it still doesn't look trust worthy that juju has systemd support for ubuntu.
[11:07] <pitti> xnox: eek, yues
[11:07] <pitti> testing /run/systemd/system is correct, thanks for pointing that out there
[11:07] <flexiondotorg> pitti, I don't appear to be able to change the bug status.
[11:07] <xnox> pitti: please raise that further up to relevant people, e.g. gaughen ?
[11:08] <pitti> flexiondotorg: just follow up with the info then, I'll reopen; thanks!
[11:08] <flexiondotorg> pitti, I'll gather the info.
[11:09] <xnox> pitti: and it uses well known temp file.... /tmp/discover_init_system.sh it is security vulnerability right there as well.
[11:20] <flexiondotorg> pitti, I've added what you requested.
[11:29] <pitti> flexiondotorg: thanks, reopened
[11:30] <flexiondotorg> pitti, When I initially test Ubuntu MATE with systemd I mentioned to you that there was no option to eject the media after an install.
[11:30] <flexiondotorg> pitti, That bug was identified during beta 2 QA and partly fixed.
[11:30] <pitti> flexiondotorg: I believe cyphermox is working on that
[11:31] <flexiondotorg> pitti, No it ejects but the system hard locks and since that part fixed was introduced oem-config is somewhat broken.
[11:31] <flexiondotorg> pitti, Yeah, I've been trying to help cyphermox and wondered if you might be able to lend a hand?
[11:32] <pitti> he said he's going to ping me this evening about some stuff he wanted to discuss
[11:35] <mdeslaur> @pilot in
[11:45] <debfx> mdeslaur: could you please have another look at bug #1230917? I've attached a debdiff.
[11:45]  * mdeslaur looks
[11:51] <debfx> the version needs to be bumped because of the last security update
[11:51] <debfx> apart from that the debdiff should still apply
[11:56] <flexiondotorg> pitti, I've updated https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875 with just the systemd logs from syslog. Looks useful.
[12:48] <mdeslaur> debfx: uploaded, thanks
[12:48] <LocutusOfBorg1> Hi dholbach any news about 1424769 ?
[12:49] <LocutusOfBorg1> nobody replied to me, I don't know how to proceed
[12:50] <dholbach> seb128, ^ do you maybe know who could help with this?
[12:51] <LocutusOfBorg1> I'll write again, I would like to have a sponsor for the new virtualbox-lts-utopic package, which is ready for trusty (built against never xorg-lts and mesa-lts)
[12:51] <dholbach> maybe you could send a mail to ubuntu-devel@ about it too?
[12:52] <LocutusOfBorg1> I can do whatever you ask me, I would just like to avoid spamming :)
[12:53] <dholbach> don't worry about it
[12:53] <dholbach> you're not spamming
[12:59] <seb128> bug #1424769
[13:02] <LocutusOfBorg1> mail sent on -devel
[13:02] <seb128> LocutusOfBorg1, dholbach, is that a duplicate of bug #1424466?
[13:02] <seb128> that got fixed a week ago
[13:03] <LocutusOfBorg1> I need to test it then :)
[13:04] <LocutusOfBorg1> the problem however was also with xorg
[13:25] <cyphermox> flexiondotorg: please don't mix the oem-config and eject problems, they are separate, different issues
[13:25] <flexiondotorg> cyphermox, OK.
[13:26] <cyphermox> pitti: so, yeah, I've been fighting systemd unit files for a bit trying to figure out how to put things in the right place so they'd work correct, I think I have something that works for oem
[13:28] <cyphermox> but there are some complications with the ejection of the CD on shutdown, from the installer. Looks like plymouth is what is freezing up, unable to get the input to catch the enter key, but it's also possible this is happening (and more visible on qemu) because the input and screen are still used by lightdm/X
[13:32] <LocutusOfBorg1> seb128, nack
[13:32] <cyphermox> pitti: do you have a suggestion on what would be the best way to get a script to run very late on shutdown, after plymouth is started but before the system reboots or halts? for now I have Before=shutdown.target reboot.target halt.target, WantedBy=shutdown.target
[13:33] <LocutusOfBorg1>   virtualbox-guest-x11 : Depends: xorg-video-abi-15
[13:33] <LocutusOfBorg1>                         Depends: xserver-xorg-core (>= 2:1.14.99.902)
[13:33] <LocutusOfBorg1> seems still problematic
[13:33] <cyphermox> hmm. now I can't remember if I tried adding After=display-manager.service Conflicts=display-manager.service
[13:34] <pitti> cyphermox: display-manager should be kept out of this IMHO
[13:35] <pitti> cyphermox: shouldn't that be WantedBy=halt.target, and After=plymouth-halt.service (and the same for reboot/poweroff)?
[13:36] <pitti> cyphermox: similar to plymouth-halt.service itself?
[13:36] <cyphermox> I believe I tried that too, and it didn't really work any better
[13:36] <cyphermox> pitti: lemme just test this one thing first
[13:37] <cyphermox> pitti: can I have this without having to duplicate the jobs like plymouth-halt, plymouth-reboot, etc.?
[13:38] <pitti> cyphermox: you can have multiple WantedBy= lines
[13:38] <pitti> (or three targets in one WantedBy)
[13:38] <cyphermox> hrm, alright, just making sure
[13:40] <shadeslayer> cjwatson: pingly
[13:40] <shadeslayer> cjwatson: Could you possibly add a kubuntu-armhf target which generates a rootfs tar like ubuntu-core?
[13:44] <cjwatson> shadeslayer: Unlikely to have time at the moment, I'm afraid.  Hopefully somebody like infinity or mvo can help you
[13:44] <shadeslayer> would be nice :)
[13:46]  * shadeslayer creates tarball for debian manually meanwhile
[14:11] <Unit193> pitti: Noticed the netbook didn't hit 1431200, but the computer I reported that about did last I remembered.  I'll try it again, and if so try after a reboot.
[14:20] <bdmurray> pitti: no, it doesn't look like it
[14:21] <bdmurray> mvo: could you upload unattended-upgrades?
[14:21] <sidi> Laney, hiya, are you the person who built the glib2.0 Ubuntu packages?
[14:43] <pitti> apw: I have a better fix proposed in bug 1438612; I'd appreciate if you could give it a spin?
[14:49] <mvo> bdmurray: yes
[14:49] <bdmurray> mvo: thanks
[14:50]  * shadeslayer looks at mvo with puppy dog eyes
[14:50] <shadeslayer> mhall119: we have a thing in a few mins right?
[14:50] <mvo> shadeslayer: hm? oh, tarball, I'm in a meeting right now, what exactly you need, a tarball?
[14:51] <shadeslayer> mvo: ubuntu-core tarball + kubuntu-desktop^ more or less
[14:51] <mhall119> shadeslayer: in an hour and a few minutes, I've been told
[14:52] <shadeslayer> oh right
[14:52] <shadeslayer> 1600 UTC
[14:52] <shadeslayer> not 1500
[14:52]  * shadeslayer goes back to blasting music
[14:52] <mhall119> shadeslayer: yeah, DST changes have thrown me off too
[14:52] <shadeslayer> Yeah, quite annoying
[14:52] <shadeslayer> I keep wondering why it's still so bright at 7 PM
[14:53] <ericsnow> pitti, xnox: thanks for the feedback on the juju init system code
[15:00] <pitti> ericsnow: I just replied again (explanation of the vulnerability, and how to simplify this)
[15:00] <ericsnow> pitti: thanks
[15:02] <ericsnow> pitti: the presence of /run/systemd/system doesn't guarantee systemd is running (PID 1), does it?
[15:03] <pitti> ericsnow: it does; as I said, that's the officially blessed way to check if you run systemd
[15:03] <mbiebl> http://www.freedesktop.org/software/systemd/man/sd_booted.html
[15:04] <ericsnow> pitti: k
[15:08] <pitti> ericsnow: note that checking readlink /sbin/init is not robust
[15:08] <pitti> ericsnow: e. g. you could have upstart running, install systemd-sysv, and then your code would wrongly say "systemd is running"
[15:09] <pitti> ericsnow: or vice versa, with running systemd and installing upstart-sysv
[15:13] <ericsnow> pitti: what a pain
[15:13] <ericsnow> pitti: thanks for following up on this
[15:14] <pitti> ericsnow: yeah; I still think that "ssh remote.server test -d /run/systemd/system" should do exactly what you need, with minimum effort and avoiding writing tmp files
[15:15] <ericsnow> pitti: we have to run something similar for upstart as well
[15:19] <pitti> ericsnow: I mentioned some initctl command in the comment
[15:19] <ericsnow> pitti: k
[15:20] <pitti> $ initctl --system list >/dev/null 2>&1; echo $?
[15:20] <pitti> 1
[15:20] <pitti> ^ on a systemd syste
[15:20] <pitti> m
[15:20] <pitti> and it shoudl succeed on upstart
[15:20] <ericsnow> pitti: thanks, that helps
[15:20] <pitti> ericsnow: although we only really support systemd or upstart; you can't install anything else
[15:21] <ericsnow> pitti: sure, but we are getting juju working on other platforms too :)
[15:22] <pitti> ericsnow: ah, right
[15:22] <ericsnow> pitti: and I've heard that docker does it's own init system
[15:23] <infinity> In its purest form, docker doesn't do init systems at all, since the containers are single applications.  Or, you could say docker *is* the init system, depending on whether your world view is inside or outside the container.
[15:24] <ericsnow> infinity: good point
[15:39] <doko> zul, jamespage: any idea about the swift autopkg test failure?  my change to python-greenlet was only to fix the powerpc build, which should be unrelated to the amd64 build
[15:40] <jamespage> doko, will look
[15:41] <jamespage> doko, I think this was the issue with the missing service file - despite the fact we don;t have then in swift
[15:41] <doko> ahh
[15:59] <pitti> infinity, kees, stgraber, slangasek, mdeslaur: TB meeting now-ish, right? (even though we have an empty agenda)
[15:59] <mdeslaur> pitti: yep!
[15:59] <pitti> mdeslaur: wow, I got the time right even right after DST change :)
[16:01] <slangasek> indeed
[16:01] <jamespage> pitti, are any extra steps requires in packages which just ship init files to work with systemd?
[16:01] <jamespage> pitti, "Failed to restart swift-proxy.service: Unit swift-proxy.service failed to load: No such file or directory."
[16:01] <pitti> jamespage: as long as the init.d script works, no
[16:02] <jamespage> init script is present and should work
[16:02] <mdeslaur> pitti: hehe :)
[16:02] <pitti> jamespage: systemctl status swift-proxy.service says "not found" too, I presume?
[16:02] <jamespage> pitti, yes
[16:02] <jamespage> (Reason: No such file or directory)
[16:07] <jamespage> pitti, if I do a daemon-reload, systemd sees the init script
[16:07] <pitti> jamespage: right, but update-rc.d defaults should call that
[16:08] <jamespage> pitti, oh wait - all of the dh_installinit calls are done with --no-start
[16:09] <pitti> ah, it's invoke-rc.d which does the daemon-reload
[16:09] <pitti> update-rc.d only does daemon-reload for actual .service units, not for init.d scripts
[16:11] <debfx> mdeslaur: thank you
[16:18] <jamespage> pitti, that does not sound quite right
[16:19] <pitti> jamespage: so, if we need this to work with --no-start, we could fix update-rc.d to also call daemon-reload
[16:20] <jamespage> pitti, installing init files, and then not starting the daemon is not that common but is the case here - swift needs lots of config
[16:20] <jamespage> pitti, I guess that would work
[16:21] <pitti> jamespage: right, which is why it hasn't come up yet
[16:27] <mdeslaur> @pilot out
[16:40] <ricotz> chrisccoulson, hi
[16:41] <ricotz> chrisccoulson, did you notice the GCC bump to 4.7 for firefox beta? seems to be a problem for precise
[16:46] <chrisccoulson> ricotz, yeah, we discussed it before they made the change
[16:47] <chrisccoulson> ricotz, https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+sourcepub/4870120/+listing-archive-extra
[16:48] <ricotz> chrisccoulson, i see, i guess an official gcc backport wont work
[16:49] <ricotz> but yeah, this seems like a clean way
[16:51] <ricotz> chrisccoulson, maybe name it a bit more generic? since this would help building libreoffice too
[16:57] <infinity> ++ExecStop=/bin/true
[16:57] <infinity> ++KillMode=none
[16:57] <infinity> pitti: ^-- Gross, is there really no better systemd declarative way to do that?
[16:58] <pitti> infinity: there are several ways (see the upstream bug that I opened), but I'd like to discuss a "proper" solution with upstream first
[16:58] <infinity> pitti: Fair enough.
[16:59] <pitti> infinity: I also tested this with shifting around the boot order and it worked for me; but these are notoriously prone to causing dependency cycles, hence that quick fix to stop annoying people until we have a better fix
[16:59] <pitti> infinity: like, starting it earlier/stopping it later coudl again cause dependency loops with /usr or /var on NFS and the like (it shouldn't, but at this point in the release cycle I rather don't want to completely shift this around)
[17:00] <pitti> infinity: but it's actually not that evil -- stopping/restarting dbus has never ever worked
[17:00] <pitti> it brings down your whole session and half of the plumbing services
[17:01] <infinity> pitti: Sure.  I noted a little while ago that since the upstart->systemd move, we're stopping way too many services anyway.
[17:01] <pitti> infinity: so if I had any PR/marketing skills, I could sell this as a safety measure or so :)
[17:01] <infinity> pitti: Many years ago, keybuk went through our shutdown sequence and neutered everything that didn't *need* a clean shutdown, we seem to have lost all that, and my laptop has gone from 2s shutdowns to 30s shutdowns.
[17:01] <pitti> infinity: heck, 30s? it should be 5 or so
[17:02] <pitti> anything beyond that is an actual bug
[17:02] <infinity> pitti: Anyhow, I wasn't referring to "not stopping dbus" as being icky, it was the specific "ExecStop=/bin/true" which looked hackish. :)
[17:02] <pitti> and with all the things that are currently complaining about "OMG my dbus went away" this might actually help your's too :)
[17:03] <pitti> infinity: ah, I see; I acutally think KillMode=none should suffice
[17:03] <infinity> pitti: Having to fork /bin/true for a no-op feels a lot like a gap in the declarative config syntax.
[17:03] <infinity> pitti: But, yeah, I guess you can experiment over time, accepted for now.
[17:03] <Laney> pitti: interesting, wonder if this fixes my shutdown hang
[17:04] <pitti> infinity: yeah, as we come closer to the release with Easter holidays and an extra sprint, and so many bugs to address still, I guess I'm more and more prone to stopping debugging after half a day when I found some solution that got confirmed to work; sorry ..
[17:05] <pitti> (at least I did start discussing it with upstream, to clean up in the future)
[17:05] <pitti> but oh well, kdbus will save us all :)
[17:05] <infinity> pitti: Heh, that's fine, as long as there's a running list of hacks to revisit somewhere on your desk.
[17:05] <infinity> pitti: Forking true is hardly the worst of our problems. :P
[17:06] <pitti> infinity: yeah, there is; it's not that bad still, there's only three hacks that make me want to put a paperbag on, the rest was quite okay
[17:06] <pitti> (that dbus one, disabling one systemd test because I can't reproduce the jenkins failure for the live of me, and the workaround for bug 1423811); but they are all tracked
[17:07] <infinity> pitti: After this dbus lands, I'll retest my laptop's shutdown a bit, and see how things fare.
[17:08] <pitti> infinity: FTR, /usr/share/doc/systemd/README.Debian "Debugging boot/shutdown problems"
[17:08] <infinity> pitti: I'm positive that it won't be as fast as our upstart "don't actually stop anything unless it actually needs to fsync/close" sequence, but I agree that 30s can't be right.
[17:08] <pitti> yeah; so far we spent zero time on making things efficient, just making them work, and pretty much copying upstart scripts 1:1 and such
[17:09] <pitti> infinity: that's pretty much what happens, though -- stopping a service is pretty much "kill the whole cgroups" for most stuff (i. e. everything without an explicit ExecStop=)
[17:09] <pitti> my VMs poweroff in a split second
[17:10] <pitti> and my desktop in < 5, just sometimes modemmanager hangs
[17:10] <pitti> (but that sounds like another fallout of the above dbus issue)
[17:11] <infinity> pitti: Well, my laptop has a very slow and VERY fragmented disk, so that amplifies a lot of bugs.  Like I said, I'll see how things look after an upgrade to the new dbus, and whine at you later if it still seems unforgivably crap.
[17:12] <pitti> infinity: sounds like a plan
[17:12] <pitti> with that, /me waves good night; with that headache I won't be much useful any more today
[17:12] <infinity> 'Night.
[17:12]  * infinity throws pain killers at pitti.
[17:16] <roaksoax> stgraber: do you maintain http://images.linuxcontainers.org//meta/1.0/index-system ?
[17:17] <stgraber> yep
[17:18] <roaksoax> stgraber: is it down?
[17:18] <roaksoax> stgraber: doesn't seem accessible
[17:19] <stgraber> roaksoax: hmm, appears to be hanging at the moment, let me check
[17:19] <roaksoax> stgraber: thanks!
[17:20] <stgraber> fixed
[17:20] <stgraber> apache 2.4 being unhappy again... I really need to track down that bug
[17:20] <roaksoax> stgraber: awesome! thanks!
[17:25] <Riddell> tseliot: are you the dude who knows about nvidia-prima? how do I know if it's working with sddm? (I have no hardware)
[17:26] <Riddell> tseliot: you seem to have removed my sddm alternate addition :(
[17:33] <Riddell> mvo: any luck on bug 1426132 ?
[18:15] <mvo> Riddell: yes, I reproduced it
[18:16] <Riddell> that's good I suppose :)
[18:51] <mvo> Riddell: it is, I might even have a idea for a workaround, testing this just takes a awful amount of time
[19:26] <mvo> Riddell: I uploaded a potential fix, it worked locally, but lets see if it works once uploaded :)
[19:38] <Noskcaj> What packages still need rebuilding for osm-gps-map to migrate?
[19:42] <Noskcaj> gpxviewer should probably be RMed, like in debian
[20:25] <xnox> ubottu: help me test
[21:45] <AdvaitaZen> Suggestion: With a mouse, the side bars should be like auto-hide... or there should be a toggle to drag.... long drags don't seem to function at all for mice. Hard to try the desktop when you can't get past the tutorial...
[21:50] <dobey> i literally have no idea what that was about
[22:07] <ericsnow> pitti: you still around?
[22:09] <ericsnow> cherylj: did I just see the last 1.23 fix merge for the LICENCE files? :)
[22:13] <cherylj> ericsnow: yes, just have to do master!
[22:13] <ericsnow> cherylj: sweet!
[22:27] <sarnold> dobey: I suspect advaitazen's comments is similar to this from #ubuntu-desktop: < rcarlos> has anyone skipped unity8 intro tutorial on desktop next ?
[23:00] <tseliot> Riddell: I don't recall doing that. Maybe send me an email to refresh my memory?
[23:02] <tseliot> Riddell: oh, you did. I'll get back to you in the morning