[03:20] <teward> infinity: (late response) I will do so if i see no activity, but I trust it'll be on the radar so long as that norbert guy keeps poking it
[05:36] <pitti> Good morning
[05:36] <pitti> tyhicks: ah, thanks; I wasn't working on an SRU yet, mostly on the vivid update; and I was waiting for kirkland to push the two script fixes upstream
[05:37] <pitti> sarnold: ssh bug> most probably a too eager (default) KillMode= in openssh's .service file; I'll have a look
[05:37] <pitti> sarnold: IMHO it's best to file them against the affected package with tagging "systemd-boot"
[05:37] <pitti> cjwatson: ^ FYI
[05:39] <pitti> tyhicks: ah thanks, so I'll upload my ecryptfs update on top of that
[05:39] <pitti> tyhicks: but why does the PPA have 104-0ubuntu4 for vivid? current vivid has -0ubuntu1..
[05:39] <wgrant> pitti: When you're done with, you know, switching init systems and stuff, we're ready from the LP end to switch on ddebs. Are the ddeb-retriever changes reasonably doable in the near future?
[05:39] <pitti> mdeslaur: ok, that worked for me, so I need more precise information about your setup; I'll answer in the bug
[05:45] <pitti> hey wgrant
[05:46] <pitti> wgrant: I need to find a day to do that rewrite
[05:46] <pitti> I hope I can get to it this week, as I'll be on vac for the following 1.5 weeks
[06:14] <wgrant> pitti: Let us know if we can help at all.
[06:24] <pitti> wgrant: if you want, the code is in https://code.launchpad.net/~pitti/%2Bjunk/ddeb-retriever/ ; it has tests and such, although they'll be a lot harder to write for LP
[06:25] <pitti> wgrant: do you have a suggestion/do we have a project how to mock launchpadlib?
[06:25] <pitti> i. e. the part that's going to fetch the ddebs
[06:25] <pitti> although I guess with the standard python mock one should get far enough
[06:25] <pitti> and just make that return a static list of ddeb URLs
[06:26] <wgrant> You probably only care about one or two methods, and it's easy enough to wrap those in a function that you can mock out.
[06:27] <wgrant> pitti: Oh, that code isn't nearly as terrifying as the legends foretold.
[06:28] <pitti> well, I wrote most of it in 2005; I was young and ...
[06:28] <pitti> ah, 2006
[06:29] <wgrant> Yup
[06:39] <lifeless> there is a launchpadlib mock thingy
[06:39] <lifeless> several
[06:39] <lifeless> none really mature IIRC
[06:58] <mitya57> ScottK: can't we just sync/merge newer qtwebkit from Debian?
[07:00] <mitya57> Should have been done earlier, I suppose
[07:38] <pitti> jodh: thanks for looking into the upstart test regression -- tests for the win! so it indeed seems this is a kernel regression?
[07:58] <dholbach> good morning
[08:21] <LocutusOfBorg1> hi folks!
[08:21] <LocutusOfBorg1> dholbach, do you think there's hope for my virtualbox new package here? bug 1424769
[08:21] <LocutusOfBorg1> I don't know how new trusty packages are handled :)
[08:22] <dholbach> maybe ping one of the archive admins to find out how it's done?
[08:23] <dholbach> I need to run out to the dentist now :)
[08:25] <LocutusOfBorg1> oh... good luck!
[08:26] <dholbach> thanks
[09:47] <seb128> cjwatson, hey, do you have any opinion on http://bazaar.launchpad.net/~robert-ancell/+junk/sync-blacklist-indic/revision/557 ?
[09:48] <seb128> cjwatson, to me it looks like you added a bunch of sources to that list cycles ago to get autosync going and nobody looked again at those again, is that correct?
[09:48] <cjwatson> pitti: well, it's certainly not using the default KillMode= ...
[09:49] <cjwatson> pitti: lp:ubuntu-cdimage has an approach to mocking launchpadlib which, well, isn't complete or anything but it's quite simple to extend, maybe that could be useful
[09:49] <pitti> cjwatson: oh right, it's already "process"; anyway, this didn't yet bubble up to the top of my TODO list, but I'll get to it for sure
[09:49] <pitti> cjwatson: thanks for pointing out
[09:50] <cjwatson> seb128: well, that one was specifically a problem for a few cycles until Robert tackled the ttf-indic-fonts merge in trusty
[09:50] <cjwatson> seb128: but I can certainly look at that, it's probably reasonable now
[09:51] <seb128> cjwatson, I was going to trust robert_ancell and merge the change, it look fine and he said he would deal with issues that could result from the change, but if you want to double check that would be welcome!
[09:52] <cjwatson> seb128: ok, why don't you go ahead and merge it, and we should see the result in the next auto-sync dry-run well before Robert wakes up again
[09:53] <cjwatson> seb128: i.e. in a bit over an hour
[09:53] <seb128> cjwatson, wfm, I just wanted to check with you before doing the change
[09:53] <seb128> thanks
[09:53] <cjwatson> yeah, it's provisionally fine
[09:53] <cjwatson> thanks for checking
[09:53] <seb128> yw!
[09:59] <pitti> smoser: did you see my question in bug 450463? each and every cloud image these days boots in degraded mode because we are trying to load a nonexisting module; where is acpiphp added these days?
[10:19] <mlankhorst> mvo: ping for apt-get?
[10:29] <pitti> hallyn_, stgraber: it seems cgmanager's tests don't work under systemd (https://jenkins.qa.ubuntu.com/job/vivid-adt-cgmanager/21/ARCH=i386,label=adt/console); is that a bug? or do the tests just need some adjustments? or should we run the tests under upstart?
[10:37] <mardy> pitti: hi! So, I wrote my dbusmock template, but now I don't know how to register it: ImportError: No module named 'dbusmock.templates./home/mardy/src/bzr/accounts-sso/online-accounts-api/mock-template/src/daemon/online-accounts'
[10:38] <pitti> mardy: oh, it's not a template in the "dbusmock.templates.*" sense, Python doesn't allow this kind of namespace mangling (or at least makes it really hard)
[10:40] <mardy> pitti: any hints on how to have my template loaded?
[10:41] <pitti> mardy: your online-accounts isn't a  Python module?
[10:41] <pitti> they need to end in .py
[10:41] <pitti> and have no dashes in it eitehr
[10:42] <pitti> mardy: so spawn_server_template('/full/path/to/mocks/online_accounts.py', params) ought to work?
[10:43] <pitti> mardy: (relative path ought to work, too)
[10:46] <mardy> pitti: OK, I'll try; I'm using libqtdbusmock, I guess it will have something equivalent
[11:24] <ScottK> mitya57: I didn't have time to check.
[11:51] <xnox> pitti: did you switch to systemd by default?
[11:51] <xnox> pitti: and do i need to do the crazy upstart split we agreed to do on here in a sensible way?
[11:52] <pitti> xnox: yes, it got switched yesterday
[11:52] <flexiondotorg_> There are some new MATE packages in Debian unstable that just fix bugs. Do I need to file a FFE to sync these?
[11:52] <pitti> flexiondotorg_: no, bug fixes only -> no new features -> nothing to except :)
[11:53] <flexiondotorg_> pitti So, what is the process to request the sync?
[11:53] <cjwatson> requestsync(1)
[11:53] <flexiondotorg_> cjwatson, Thanks.
[11:53] <pitti> xnox: split? would be nice to move the conffiles to upstart-bin indeed
[11:54] <pitti> but I don't think we need to further split the package; they aren't that big to warrant that IMHO
[11:54] <xnox> pitti: well, i believe the decission was slightly different. Keep conffiles in upstart, but move all other things that conflic with systemd-sysv from upstart -> upstart-sysv
[11:54] <pitti> my /etc/init is 452 K, and that includes jobs from a lot of other packages
[11:54] <pitti> xnox: ah! and adjusting systemd's conflicts accordingly, and init's dependencies? a lot more intrusive, but certainly doable
[11:55] <pitti> xnox: but then we don't need upstart-bin either any more?
[11:55] <xnox> pitti: make upstart-sysv depend on upstart. and yeah.
[11:55] <xnox> pitti: well upstart-bin is kind of the minimal thing one needs to run /user session/ only.
[11:55] <xnox> pitti: but certantly would be possible to merge that back into upstart.
[11:55] <xnox> pitti: i still don't know what the upgrade path will look like.
[11:56] <pitti> I didn't really follow why it's impossible to move a conffile between packages
[11:56] <xnox> pitti: e.g. should I make this new split with "upstart depends: systemd-sysv" ?
[11:56] <pitti> xnox: well, I'm not yet convinced that this is the best way; this sounds like crying for more upgrade troubles TBH
[11:56] <pitti> xnox: err, upstart depends: systemd-sysv? that looks wrong :)
[11:56] <xnox> pitti: so we obviously do not want upstart to depend on upstart-sysv, and apt can decide to purge old one before unpacking the new one, wiping modified conffiles away
[11:57] <xnox> pitti: or generating a conffile prompt.
[11:57] <xnox> pitti: do we have any dist-upgrader hook to install systemd-sysv?
[11:57] <pitti> this stuff should work with apt-get too
[11:57] <xnox> pitti: or people who don't have ubuntu-minimal are screwed?
[11:58] <pitti> xnox: right, people without ubuntu-standard won't get upgraded to systemd (for now, anyway)
[11:58] <xnox> pitti: having upstart split the same way as systemd is split would be nice.
[11:58] <pitti> xnox: I agree, splitting it that way makes more sense; I just can't tell you that it will work on upgrades
[11:58] <pitti> (it should, but needs testing)
[11:59] <pitti> well, actually it shouldn't be that bad
[11:59] <pitti> we just split out a new upstart-sysv with /sbin/init, telinit, shutdown, etc.
[11:59] <xnox> pitti: upstart depends: upstart-sysv | systemd-sysv -> such that people end up with an init?
[11:59] <pitti> which we wouldn't even install on upgrades
[11:59] <xnox> or whatever that metapackage thing is to provide init.
[11:59] <pitti> xnox: no need
[11:59] <pitti> xnox: init is required now (and in ubuntu-minimal)
[12:00] <pitti> xnox: well, it could depends: init, to make sure
[12:00] <xnox> pitti: i don't want to upgrade upstart to a package without /sbin/init and break everyone who doesn't have ubuntu-minimal installed, you see.
[12:00] <xnox> and without any dependency that provides /sbin/init
[12:00] <pitti> xnox: yup, understood; so depend: init?
[12:00] <xnox> yeah.
[12:00] <xnox> maybe i should introduce "Depends: init" and see how badly this breaks.
[12:01] <pitti> xnox: ok, that sounds good to me
[12:01] <xnox> (without any splits)
[12:01] <xnox> .. changes, that is)
[12:27] <mdeslaur> pitti: thanks for looking at my nfs issue. I assume you are going to enable NetworkManager-wait-online.service? I have a few other things that also fail to wait for networking, like ntp, etc.
[12:28] <seb128> mdeslaur, hey, sorry my IRC timeouted yesterday and I think you didn't get my reply, feel free to open a bug about those gtk deprecation warnings, we might try to turn some off for release or something
[12:28] <mdeslaur> seb128: what whould I file it under, gtk+3.0?
[12:28] <pitti> mdeslaur: ah, are you *only* using NM, not ifupdown?
[12:29] <mdeslaur> pitti: only NM
[12:29] <xnox> mdeslaur: you get to keep both pieces =)
[12:29] <mdeslaur> xnox: wth are you talking about, this has worked for the past 6 years
[12:29] <xnox> mdeslaur: or enable network-manager wait online target yourself =)))))
[12:29] <pitti> nah, I think we should enable it by default
[12:29] <xnox> mdeslaur: systemd-networkd is the future man! =)
[12:30] <mdeslaur> xnox: well, I live in the present :)
[12:30] <pitti> I just wasn't aware that our ntp, nfs etc. jobs waited for NM
[12:30] <xnox> mdeslaur: NM is so two thousand and late </finished trolling>
[12:30] <mdeslaur> xnox: who needs ipv6 anyway, right? :)
[12:30] <mlankhorst> can't we move the networking to the cloud?
[12:30] <seb128> mdeslaur, yes, describe the warnings and where you see them, Laney&co and probably going to push to fix the apps to not use deprecated apis or properties rather than turning off the deprecations warnings, so we need to see what is impacted and be pragmatic about it
[12:31] <xnox> mdeslaur: http://dilbert.com/strip/2014-12-04 and ipv4 address
[12:31]  * xnox <3 BOB
[12:31] <mdeslaur> xnox: oh, actually looks like systemd-network gained ipv6 support since the last time I asked :P
[12:31] <mdeslaur> s/asked/looked/
[12:32] <mdeslaur> seb128: ok, cool thanks.
[12:32] <xnox> mdeslaur: have you looked at libnss_resolve module in systemd source tree? If you guess that it uses system dbus to call to org.freedesktop.resolve1 service to query dns - you are obsolutely correct!
[12:33]  * mdeslaur spits coffee at screen
[12:33] <mdeslaur> xnox: no wonder the push for kdbus :)
[12:34] <xnox> mdeslaur: also you cannot login without system dbus - as nologin isn't lifted until system login acquires name on the system dbus. And well pam_systemd will also fail as required.
[12:35] <mdeslaur> hrm
[12:41] <mdeslaur> seb128: bug 1430307, thanks
[12:44] <flexiondotorg_> I've been reuest some sync from Debian with requestsync. No problem.
[12:44] <flexiondotorg_> However, one package reports the same version exists in Debian and Ubuntu,
[12:44] <flexiondotorg_> E: The versions in Debian and Ubuntu are the same already (1.8.1+dfsg1-4). Aborting.
[12:44] <didrocks> slangasek: hey, mind giving your opinion when you have some time on bug #1428486?
[12:44] <flexiondotorg_> But, as far as I can see Ubuntu has 1.8.1+dfsg1-3
[12:44] <flexiondotorg_> Ummm. Confused.
[12:45] <didrocks> flexiondotorg_: would be easier with the package name :)
[12:45] <flexiondotorg_> didrocks, mate-power-manager
[12:46] <didrocks> flexiondotorg_: $ rmadison mate-power-manager
[12:46] <didrocks>  mate-power-manager | 1.8.1+dfsg1-4 | vivid/universe  | source, amd64, arm64, armhf, i386, powerpc, ppc64el
[12:47] <didrocks> so vivid has 1.8.1+dfsg1-4
[12:47] <didrocks> requestsync isn't lying :)
[12:47] <didrocks> you could as well check this one launchpad: https://launchpad.net/ubuntu/+source/mate-power-manager
[12:47] <flexiondotorg_> http://packages.ubuntu.com/vivid/mate-power-manager
[12:47] <didrocks> (note that there is a slight publishing cycle difference between launchpad and rmadison)
[12:48] <didrocks> flexiondotorg_: packages.ubuntu.com mirrors data from launchpad/the archives
[12:48] <didrocks> use rmadison as the source of trust
[12:48] <seb128> mdeslaur, thanks
[12:48] <flexiondotorg_> didrocks, OK. It is great that this newer package has landed. But I am confused.
[12:48] <didrocks> (or launchpad)
[12:48] <flexiondotorg_> didrocks, What caused that sync to happen? I thought Debian sync was disabled now?
[12:49] <flexiondotorg_> That package was only uploaded to Debian unstable 4 days ago.
[12:50] <seb128> flexiondotorg_, cjwatson did it today apparently
[12:50] <seb128> not sure why
[12:50] <flexiondotorg_> cjwatson, Thanks :)
[12:50] <didrocks> yeah, it's the auto-sync archive being run, not sure why as well
[12:50] <seb128> it might have been a sponsoring request in the queue
[12:50] <didrocks> flexiondotorg_: https://launchpad.net/ubuntu/+source/mate-power-manager/+publishinghistory for the publishing infos
[12:50] <flexiondotorg_> didrocks, Thanks.
[12:51] <didrocks> https://bugs.launchpad.net/ubuntu/+source/mate-power-manager/+bug/1428131
[12:52] <didrocks> flexiondotorg_: that's why it was synced ^
[12:52] <flexiondotorg_> didrocks, OK. So linking to an upstream bug will trigger a sync?
[12:52] <mvo> mlankhorst: hey, sorry for the delay. what commands do I need to run to reproduce the issue you ran into?
[12:52] <didrocks> flexiondotorg_: surely not, this has been a sponsoring thing I think
[12:53] <flexiondotorg_> didrocks, OK, thanks for the explanation. All understood.
[12:53] <flexiondotorg_> cjwatson, Thanks for your sponsoring.
[12:58] <mlankhorst> mvo: I have a workaround now, but on a 14.02 image try installing ubuntu-sdk
[12:59] <mlankhorst> workaround is allowing the -dev packages for the unrenamed stack to be installed with the renamed stack
[12:59] <smoser> pitti, "degrated" ?
[13:00] <smoser> oh. i see.
[13:00] <mvo> mlankhorst: aha, let me try that
[13:00] <mlankhorst> but when I add depends: renamed | unrenamed for all dev packages to ubuntu-sdk-libs-dev to nudge the depends a bit it will work on renamed, but not on unrenamed..
[13:02] <mlankhorst> so I'm tempted to just sru the fixed mesa package every time I upload a new lts stack
[13:02] <smoser> pitti, http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/vmbuilder-cloudimg-fixes
[13:02] <mvo> mlankhorst: thanks, let me check that once my image is downloaded
[13:06] <mlankhorst> oke
[13:06] <mlankhorst> apt-get install ubuntu-sdk should be uninstallable
[13:07] <cjwatson> flexiondotorg_,seb128,didrocks: yeah, I occasionally go through the auto-sync output looking for obvious syncs
[13:07] <flexiondotorg_> cjwatson, Thanks.
[13:08] <cjwatson> it wasn't a sponsoring thing
[13:15] <mardy> pitti: if you have a minute, can you have a look at this? I get an error saying that the request_access method is not part of DBusMockObject
[13:15] <mardy> pitti: http://bazaar.launchpad.net/~mardy/online-accounts-api/mock-template/view/head:/src/daemon/online_accounts.py#L50
[13:15] <mardy> pitti: I guess I'm doing something very stupid :-)
[13:15] <smoser> utlemming, Odd_Bloke : https://bugs.launchpad.net/ubuntu/+bug/1430323
[13:38] <Odd_Bloke> smoser: utlemming: I've pushed up a fix to livecd-rootfs, so it should be fixed in the next vivid build (or perhaps the one after that).
[13:39] <smoser> Odd_Bloke, i would apply the change to trusty and utopic also.
[13:39] <smoser> its clearly just noise on those systems even if upstarts module-loading job is less complainy
[13:40] <Odd_Bloke> smoser: Ack, will do.
[13:45] <pitti> smoser: ah, thanks for the bug; I suppose this can just be dropped, as we don't have the module any more
[13:47] <pitti> mardy: right, it isn't
[13:47] <pitti> mardy: it's a toplevel function, not a method of your "self"
[13:48] <mardy> pitti: I'm calling setattr() on mock, to add these methods, and now it works. Is it OK?
[13:49] <pitti> mardy: it's a bit of a hack, but sure :)
[13:57] <Odd_Bloke> smoser: http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/revision/655
[14:02] <pitti> mdeslaur: would you mind trying something?
[14:02] <mdeslaur> pitti: sure
[14:02] <pitti> mdeslaur: do you have /var on NFS, or something similar?
[14:02] <pitti> (/home is fine)
[14:02] <mdeslaur> I have /mnt/server on NFS, nothing else
[14:02] <mdeslaur> it's not an important mount
[14:02] <pitti> mdeslaur: I just updated the bug(s)
[14:03] <pitti> mdeslaur: so, could you replace $remote_fs with $local_fs in /etc/init.d/console-setup
[14:03] <pitti> mdeslaur: (that will break with /var on NFS)
[14:03] <pitti> mdeslaur: and then sudo systemctl enable NetworkManager-wait-online.service
[14:03] <pitti> mdeslaur: AFAICS console-setup should be the only remaining problem in a default install
[14:04] <pitti> mdeslaur: this ought to fix NFS for you
[14:04] <doko> jamespage, rbasak: I was looking at the GCC 5 ftbfs in open-vm-tools. any reason that the package is not merged since trusty?
[14:04] <mdeslaur> pitti: I do have other $remote_fs in /etc/rcS.d
[14:05] <mdeslaur> pitti: or do they not matter because they have systemd jobs also?
[14:05] <pitti> mdeslaur: right
[14:06] <mdeslaur> pitti: ok, give me a few minutes and I'll try it
[14:06] <rbasak> utlemming: ^^ can you speak for open-vm-tools, please?
[14:06] <pitti> mdeslaur: grep -l DefaultDependencies /run/systemd/generator.late/*.service | xargs egrep 'remote-fs|network-online'
[14:07] <pitti> mdeslaur: for me that only yields console-setup.service
[14:07] <mdeslaur> pitti: me too
[14:07] <Odd_Bloke> rcj may also be able to speak on open-vm-tools.
[14:08] <pitti> mdeslaur: hm, hang on
[14:08] <pitti> mdeslaur: before you reboot, let me test something
[14:08] <mdeslaur> ok
[14:20] <pitti> mdeslaur: OK, it actually works here in my VM
[14:21] <mdeslaur> pitti: I'll test it in about 30 min
[14:22] <pitti> mdeslaur: there is a really fishy/broken thing in NM-wait-online.service, so I wanted to check first
[14:25] <ogra_> pitti, hmmm ... so the touch change seems to kill the i386 buildd
[14:26] <ogra_> https://pastebin.canonical.com/127272/
[14:28] <pitti> oh, that seems related to what xnox and I discussed this morning
[14:28] <pitti> e. g. we need to keep the /etc/init/ scripts in upstart, and split out upstart-sysv instead
[14:29] <xnox> pitti: i can't see that paste....
[14:29] <xnox> pitti: don't the i386 touch build wants upstart as init?
[14:29] <ogra_> pitti, cjwatson suggested that init/conf.c is missing a nih_free
[14:29] <xnox> pitti: ditto desktop-next
[14:29]  * xnox can't see that paste
[14:29] <xnox> (un authenticated)
[14:29] <ogra_>  in the case where nih_file_read fails
[14:29] <cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.621603] init: /home/buildd/build-LIVEFSBUILD-22254/chroot-autobuild/build/chroot/etc/init/tty1.conf: Unable to reload configuration after override deletion
[14:30] <cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.642455] init: file.c:110: Unhandled error from nih_file_read: No such file or directory
[14:30] <cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.754281] init: Caught abort, core dumped
[14:30] <cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.754375] init: file.c:110: Unhandled error from nih_file_read: No such file or directory
[14:30] <cjwatson> Mar 10 13:46:55 allspice kernel: [3743880.757830] init: Caught abort, core dumped
[14:30] <cjwatson> and then the buildd dies
[14:30] <cjwatson> so regardless of the structure of the packages, this is a bug in the version of upstart running in the host system
[14:31] <cjwatson> and I'm not sure it's one that's been fixed even upstream; if nih_file_read returns NULL then AFAICS it leaves an outstanding nih_error lying around which must be freed
[14:31] <pitti> xnox: I sent a summary to bug 1422681, I think that's what we resolved to?
[14:32] <cjwatson> (i.e. regardless of the structure of the packages, it should never be possible to crash the host init like this)
[14:33] <rcj> doko, I'm looking at syncing open-vm-tools with the release in debian.
[14:33] <cjwatson> anyway, will leave it to you lot, just try to stop taking out my buildds ;-)
[14:34] <doko> rcj, cool, please can you address https://launchpadlibrarian.net/196777507/buildlog_ubuntu-vivid-amd64.open-vm-tools_2%3A9.4.0-1280544-5ubuntu6_FAILEDTOBUILD.txt.gz as well? GCC 5 ftbfs
[14:34] <rcj> doko, will do. Thank
[14:35] <xnox> cjwatson: thanks. That doesn't look good indeed.
[14:35] <xnox> ogra_: cjwatson: is there a launchpad bug with the full log somewhere against upstart about that?
[14:36] <xnox> doko: started packaging boost1.57. It's building fine, just -doc package generation fails, this is where i've stopped at yesterday.
[14:36] <ogra_> xnox, i only noticed it minutes ago ... cjwatson is looking at it a few mins more i think
[14:36] <cjwatson> xnox: not afaik
[14:36] <cjwatson> and that's all the log I have
[14:36] <xnox> ah, ok.
[14:36] <ogra_> so no, unless Spads filed one
[14:36] <cjwatson> (well, until the builder was manually rebooted 12 minutes later)
[14:36] <Spads> I can provide more log, but there's not much more that's interesting there
[14:37] <Spads> those reboots you see are me manually hitting power
[14:37] <cjwatson> s/12/22/
[14:37] <Spads> (well, virtually)
[14:37] <cjwatson> indeed
[14:37] <cjwatson> Launchpad doesn't extract the full build log until the end, so I don't have that side of things, although it *might* be lying around in /var/log/launchpad-buildd/
[14:38]  * Spads checks which default.log might fit
[14:38] <xnox> cjwatson: it killed the _host_ init?! /o\
[14:38] <cjwatson> Spads: everything since 13:32:42 on allspice, I guess
[14:38] <ogra_> xnox, yeah, shiny, aint it ?
[14:38] <Spads> xnox: charming, innit?
[14:39] <cjwatson> xnox: right, hi chroot sessions
[14:39] <xnox> cjwatson: ogra_: infinity disabled usptart chroot sessions on _all_ buildds
[14:39] <cjwatson> maybe not hard enough?
[14:39] <xnox> cjwatson: Spads: and that's the default now. Is that not enabled on these buildds?
[14:39] <cjwatson> how did he do that?
[14:39] <cjwatson> given that he doesn't have admin access to these buildds afaik
[14:40] <xnox> cjwatson: so in later upstarts we have them disabled chroot sessions by default.
[14:40] <ogra_> well, interestingly the armhf build of the same image still runs fine https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch
[14:40] <xnox> cjwatson: which upstart is running there?
[14:40] <cjwatson> xnox: allspice/toyol are iirc precise
[14:40] <ogra_> so it might indeed be machine specific
[14:40] <cjwatson> armhf will be a later base system, probably
[14:41]  * cjwatson checks landscape
[14:41] <xnox> cjwatson: there is no correct cleanup / garbage collections of chroot sessions. They pile up eventually. I had a hairy reorg to monitor and free chroot sessions properly, but instead we decided that nobody uses them, it was a bad idea, and we are moving on to systemd.
[14:41] <cjwatson> yeah but this is not a GC issue
[14:41] <cjwatson> it's pretty clear that it's an uncleared error state
[14:42] <cjwatson> allspice is precise, upstart 1.5-0ubuntu7.2
[14:43]  * xnox 's mk-sbuild is still running
[14:43] <cjwatson> toyol likewise
[14:43] <cjwatson> the armhf build is on kishi02
[14:44] <cjwatson> which is also precise, upstart 1.5-0ubuntu7.2
[14:44] <xnox> Spads: cjwatson: you want "--no-sessions" in the kernel cmdline, in trusty and up chroot sessions are disabled by default as we have gained "proper" upstart in the user session.
[14:44] <xnox> which is much better than the old user/chroot sessions.
[14:45] <cjwatson> I'm wary of doing significant maintenance on how the devirt buildds boot
[14:45] <tyhicks> pitti: re the security-proposed ppa having version 104-0ubuntu4> I've iterated on the packages in the PPA a few times while the upstream changes were being reviewed/tested
[14:45] <cjwatson> given that this year we plan to migrate everything into the virt farm
[14:45] <cjwatson> this bug looks like it ought to be a one-liner plus tests to fix
[14:45] <xnox> cjwatson: I'm wary of 3 year old usptart SRU =)
[14:45] <xnox> true.
[14:46] <xnox> cjwatson: well migration to virt farm -> is migration to trusty right?
[14:46] <pitti> tyhicks: ah, ok; so that'll presumably land as ubuntu2? when do you plan on doing that? (I don't want to wait too long with the fix as it causes nasty boot delays, but also don't want to step on your feet)
[14:46] <xnox> cjwatson: incidentally?
[14:46] <cjwatson> right
[14:46] <cjwatson> ok, the armhf build is killing builders now too
[14:46] <rbasak> alexbligh1: apache2 2.4.7-1ubuntu4.4 is a security update that includes your fix.
[14:46] <xnox> lovelly.
[14:46] <cjwatson> it was probably just slower to die
[14:46]  * xnox =(
[14:46] <rbasak> alexbligh1: thank you!
[14:47] <tyhicks> pitti: today (within a few hours, I think)
[14:47] <pitti> tyhicks: ah, sounds good, thanks; I'll upload mine after that then
[14:47] <tyhicks> thanks!
[14:47] <cjwatson> ok, let me try to extract a sanitised combined log from Spads' dump
[14:47] <xnox> cjwatson: ah, it's a libnih assert
[14:48] <cjwatson> right, which is because nih is returning an error which upstart is failing to clear
[14:49] <xnox> because inotify reloads inside session, which is in progress being purged =(
[14:50]  * xnox pokes it more to have a simple patch for this.
[14:51] <cjwatson> Hah, it's literally when removing the build tree at the end
[14:51] <cjwatson> http://paste.ubuntu.com/10574985/
[14:51] <xnox> cjwatson: can you remove things in order? =) like rm the .overrides first =)
[14:52] <cjwatson> no, this is not in build-specific code :P
[14:52] <xnox> cjwatson: i know i know, i'm joking.
[14:52] <cjwatson> anyway, yeah, finishes the whole build, starts rm -rf, then 11 seconds later the buildd dies
[14:52] <cjwatson> ogra_,pitti: ^-
[14:52] <cjwatson> enjoy it while it lasts, we won't be able to extract build logs like this with virtualised builders :P
[14:53] <pitti> hm, so the host's upstart inotifies the job files in the chroot?
[14:53] <xnox> cjwatson: but that's what i wanted to do -> when chroot root dir starts disappearing start ignoring config changes and free the conf structures et.al.
[14:53] <cjwatson> maybe we should sort out a jenkins-like continuous-fetch thing
[14:53] <cjwatson> pitti: precise's upstart treated the chroot as a session, yeah
[14:53] <xnox> pitti: yeah, and upstart expected for foo.conf to still exist when inotify handler fires for removal of foo.override.
[14:54] <cjwatson> so does this actually have anything to do with the migration to systemd-sysv?
[14:54] <pitti> so how come that this didn't happen before..
[14:55] <cjwatson> is it perhaps that the directory entries are in a different order?
[14:55] <pitti> just because that slightly changed the unpack order etc?
[14:55] <cjwatson> because maybe now upstart is installed after the overrides are
[14:55] <xnox> cjwatson: no. however init is growing memory with each chroot.
[14:55] <xnox> cjwatson: and eventually runs out of inotify watches as well.
[14:55] <cjwatson> this has killed at least three buildds in succession
[14:55] <cjwatson> it doesn't make sense for it to be just a memory pressure issue like that
[14:56] <cjwatson> and, as I say, there is a pretty obvious bug in init/conf.c
[14:56] <xnox> cjwatson: well these builds you are doing have a lot of .override files. touch is the only one that _ships_ /etc/init/*.override files.
[14:56] <xnox> previously packages never shipped them.
[14:56] <cjwatson> touch builds weren't failing before today
[14:59] <xnox> cjwatson: that's the only place where error is not freeed after unsuccesful call to conf_reload_path. lovely.
[14:59] <cjwatson> so, if removing the .override files first is a workaround, livecd-rootfs could remove those from the chroot after building the image
[14:59] <cjwatson> but this is still not good because any build cancellation will run into the same thing
[14:59] <pitti> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1430280/comments/6 has the steps you can try; works here in VM
[14:59] <cjwatson> (or potentially also build failures, although livecd-rootfs could handle those if it tried hard)
[15:00] <mdeslaur> pitti: thanks, I'll let you know
[15:01] <bdmurray> pitti: can you have a look at bug 1419061?
[15:02] <cjwatson> xnox: Not the only one
[15:02] <cjwatson> xnox: For instance conf_source_reload_file frees an unrelated error, but not the one from nih_file_read
[15:02] <cjwatson> (called by conf_reload_path)
[15:03] <cjwatson> But yeah, I think those are the only two
[15:03] <pitti> bdmurray: replied to teh bug
[15:03] <xnox> cjwatson: sure. So i believe i hit this race when adding support for multiple configuration directories. Thus the whole iteration is done consistently now - that is any .override removal triggers full rescan of sources from all dirs, rather then straight to load .conf next to it.
[15:04] <xnox> cjwatson: since with multiple dirs we don't know exactly where it is.
[15:04] <xnox> cjwatson: so the place where precise asserts was gone in https://code.launchpad.net/~xnox/upstart/overrides/+merge/141914
[15:04] <cjwatson> Right
[15:04] <xnox> cjwatson: but that merge is not suitable for SRU
[15:05] <cjwatson> Certainly not
[15:05] <xnox> cjwatson: i think "if (error) nih_free(error);" is a good one-liner for precise SRU though. With a test simulating this behaviour.
[15:05] <xnox> jodh: are you busy? ^
[15:06] <xnox> cjwatson: removing .overrides first should also work as a plug....
[15:06] <cjwatson> I don't think it's if(error)
[15:06] <xnox> or boot with --no-session
[15:06] <cjwatson> nih_error_get maybe
[15:07]  * xnox needs to check if it's system or niherror.
[15:07] <xnox> plus not sure about that codebase from precise.
[15:07] <cjwatson> xnox: The pattern near the end of conf_file_visitor would be appropriate, I think
[15:07] <cjwatson> I don't even know where to start with trying to add a kernel parameter to every devirt buildd, or even every x86 and armhf devirt buildd
[15:08] <xnox> cjwatson: yes. and we know that one works =)
[15:08] <cjwatson> most of them aren't in puppet afaics
[15:08] <bdmurray> pitti: thanks!
[15:08] <xnox> (pattern that is)
[15:08] <cjwatson> they get autoinstalled and I've no idea where the code for that is
[15:09] <xnox> cjwatson: anyway, my jenkins is ready, got to go. I can prepare SRU tonight for this. Unless someone beats me to it.
[15:09] <cjwatson> and I don't really want to have to get GSA to re-autoinstall several dozen buildds, either
[15:09] <cjwatson> xnox: appreciated, thanks
[15:10] <xnox> re-autoinstalltion - will certantly can grave some of them =)
[15:10] <cjwatson> ogra_,pitti: do you think one of you could work on changing livecd-rootfs to remove .override files from the chroot tree after building the image, as a temporary workaround for this?
[15:11] <pitti> cjwatson: yes, can do
[15:11] <cjwatson> thanks!  what a horrible bug
[15:11] <doko> xnox, any reason that boost1.54 is still in the archive?
[15:13] <xnox> doko: http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.55.html dc-qt dynare?
[15:13] <ogra_> cjwatson, hmm, thats tricky, it that the outer chroot or the actual rootfs chroot you refer to ?
[15:13] <xnox> doko: is it in release or in proposed?
[15:14] <ogra_> the rootfs ships a ton og override files ... they would need to be backed up and put in place again
[15:14] <ogra_> s/og/of/
[15:14] <cjwatson> no you misunderstand
[15:14] <cjwatson> *after* building the image
[15:14] <ogra_> oh
[15:14] <cjwatson> immediately before exiting
[15:14] <cjwatson> and it's in the actual rootfs chroot
[15:14] <cjwatson> you can see it in the log, the full path from the host system is /home/buildd/build-LIVEFSBUILD-22254/chroot-autobuild/build/chroot/etc/init/tty1.conf
[15:15] <ogra_> right, that shouldnt be any prob if we can do it after tarball creation
[15:15] <pitti> ogra_: are you familiar with this? I'm a bit overloaded, can we look at this together?
[15:15] <cjwatson> livecd-rootfs will be running chrooted into /home/buildd/build-LIVEFSBUILD-22254/chroot-autobuild
[15:16] <xnox> cjwatson: another thing we can do, is stop making chroots trying to talk to host pid 1 - which triggers the chroot session creation in the first place.
[15:16] <xnox> that would be a change in e.g. vivid.
[15:16] <cjwatson> I didn't know they got the option to avoid that
[15:18] <cjwatson> ogra_: doing it right at the end of livecd-rootfs/live-build/auto/build would be a vaguely decent stopgap
[15:18] <xnox> cjwatson: so something connects to usptart socket, and dbus_connection_get_unix_process_id is fetched and then we do readlink on /proc/%lu/root and then we create chroot session.
[15:18] <cjwatson> the current working directory will be /build within the chroot, so should be just something like "rm -f chroot/etc/init/*.override"
[15:18] <xnox> one can mediate upstart's private socket, or e.g. mount proc with hidepid=2
[15:19] <ogra_> cjwatson, pitti http://paste.ubuntu.com/10575139/
[15:19] <ogra_> cjwatson, right, thats what i just committed :)
[15:19] <cjwatson> ogra_: yep, but I'd do it even after those lb calls
[15:19] <ogra_> oh, ok
[15:19] <jodh> xnox: cjwatson: looks like the problem of not clearing the error stems from the function doc for nih_file_read() claiming it only returns NULL on insufficient memory :(. So, we need a "if (! buf) { err = nih_error_get(); nih_free(err); .. }" by the looks of it.
[15:19] <cjwatson> shouldn't matter, but
[15:20] <cjwatson> jodh: right
[15:20] <pitti> ogra_: ah, thanks! I was still reading the files to see what they do in teh first place
[15:21] <xnox> cjwatson: oh, but on precise one cannot reliably remount proc with hidepid option, proc fstab entry is ignored by mountall...
[15:23] <jodh> xnox: cjwatson: since this still affects the latest version of upstart, should we consider a 1.13.3 release and then cherry pick in the minimal fix as a precise SRU?
[15:23]  * xnox ponders if initctl in the chroot can be direvert, or all calls to upstart be avoiding.
[15:23]  * xnox ponders if initctl in the chroot can be direvert, or all calls to upstart be avoided
[15:23] <ogra_> pitti, cjwatson, uploaded
[15:23] <cjwatson> I don't object, although it'll basically be an independent fix rather than a cherry-pick
[15:23] <cjwatson> given that the baseline code in question has gone away
[15:24] <pitti> ogra_: danke!
[15:24] <ogra_> i'll trigger a new build once rmadison tells me i can
[15:27] <stgraber> pitti: not sure if hallyn responded. But my guess is that remove-on-empty doesn't work in that case because systemd is the release_agent, so probably something to fix in the test but I'll let hallyn look at it
[15:31] <jodh> Spads: please could you raise an upstart bug for this issue?
[15:31] <pitti> stgraber: ah, that makes sense
[15:32] <ogra_> oh, FWIW the armhf build also failed in the end
[15:32] <ogra_> (without producing a lo)
[15:32] <ogra_> *log
[15:34] <Spads> jodh: me?
[15:35] <Spads> jodh: I just schlepped logs from buildds :)
[15:35] <Spads> I'm not entirely sure what the diagnosis turned out to be
[15:39] <cjwatson> I'll file one
[15:40] <alexbligh1> If I do (e.g.) apt-get download libapache2-mod-proxy-html for version 1:2.4.7-1ubuntu4.4, the resultant filename is libapache2-mod-proxy-html_1%3a2.4.7-1ubuntu4.4_amd64.deb - if I'm putting files into a repo, should I really % encode a colon character, or is that apt-get download being funny?
[15:40] <cjwatson> the epoch is conventionally stripped entirely in a repo
[15:40] <cjwatson> so it would be libapache2-mod-proxy-html_2.4.7-1ubuntu4.4_amd64.deb
[15:41] <alexbligh1> cjwatson, thanks
[15:42] <cjwatson> jodh: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1430403
[15:44] <jodh> cjwatson: thanks.
[15:53] <hallyn_> stgraber: pitti: hm.  i wonder whether cgmanager, in the case where a controller was premounted and prune() is called, should fork a thread to manually do the prune
[15:54] <hallyn_> :(
[15:54] <hallyn_> i mean yes i just not do that test in the systemd case :)
[15:54] <tjaalton> huh, upgrade killed my session
[15:56] <tjaalton> dpkg got stuck at libc postinst
[15:56] <hallyn_> pitti: well i'll fix it in a vivid-specific update for now
[15:57] <hallyn_> what's the best way to detect systemd?
[15:57] <pitti> hallyn_: cheers!
[15:57] <pitti> hallyn_: the canonical way is [ -d /run/systemd/system ]
[15:57] <pitti> hallyn_: i. e. if that directory exists, systemd is running
[15:57] <hallyn_> pitti: and to be sure, the tests will never be run inside an upstart container on a systemd host (in our buildfarm) right?
[15:58] <hallyn_> (bc otherwise testing for upstart would not suffice)
[15:58] <xnox> hallyn_: well, if container has it's own /run you are out of luck testing for host's pid 1.
[15:59] <hallyn_> xnox: of course
[15:59] <stgraber> hallyn_: grep -q cgm-release-agent /proc/$(pidof cgmanager)/root/run/cgmanager/fs/<controler>/release_agent
[15:59] <hallyn_> but right now i'm only wanting to avoid the testcase during pkg build, bc we know what's going on.
[16:00] <hallyn_> stgraber: would you agree that long-term cgmanager should fork a thread and just stick around and wait to remove the directories?
[16:01] <stgraber> hallyn_: yeah, I'd be fine with that. I don't like us turning useful features off when running on systemd
[16:04] <hallyn_> i should see how much functionality i can move into systemd during 15.10
[16:04] <hallyn_> (while adding features to cgmanager as contingency)
[16:07] <pitti> hallyn_: that could happen, if we run a test for an older release
[16:08] <tjaalton> hm, systemd/n-m failed to start br0 bridge
[16:36] <Riddell> pitti: any thoughts on bug 1430428? live cd booting into ubiquity dm now which doesn't transition into live desktop
[16:46] <hallyn_> pitti: i made the mistake of upgrading my laptop to vivid.  how do i (1) do the equivalient of running upstart user session, and (2) configuring my (*$&%$ network?  (or just disable the network stuff so i can run wpa_suplicant by hand)
[16:47] <hallyn_> btw, now that i'm temporarily back on the network, pushed the cgmanager with workaround
[16:48]  * hallyn_ is livid
[16:51] <hallyn_> of course the update did crash mid-way, so maybe netowrking wont' be effed after reboot after dpkg- --configure -a
[17:00] <seb128> bdmurray, mvo, could you look at bug #1430436?
[17:00] <seb128> bdmurray, you added the lines which create the issue so maybe you know why they are needed/if they need to be adapted for systemd?
[17:00] <seb128>         os.remove("%s/sbin/initctl" % mount)
[17:00] <seb128>         os.symlink("%s/bin/true" % mount, "%s/sbin/initctl" % mount)
[17:00] <seb128> replacing initctl by /bin/true
[17:01] <bdmurray> seb128: I'll have a look, but that was quite some time ago.
[17:08] <stgraber> mterry: sorry for the very long delay in responding to bug 1413402, just remembered it now...
[17:12] <seb128> bdmurray, I've proposed https://code.launchpad.net/~seb128/click/initctl-not-there/+merge/252479 which is the obvious "don't try if the fail is not there", that should makes the sdk creation not fail but that might not be right/enough (unsure if we want to do something similar with systemctl in the systemd case
[17:16] <seb128> bdmurray, in fact it seems logic to do the same for systemctl, updated to do that
[17:20] <mterry> stgraber, ah thanks  :)
[17:23] <hallyn_> pitti: ok, nm, looks like the failed upgrade was the cause of the trouble;  upstart user jobs under systemd are running now
[17:24] <mdeslaur> pitti: it worked, my nfs mount mounted at boot
[17:29] <bdmurray> seb128: I really don't recall why that's there and I'm not in the click hackers group as it stands so I think mvo is a better contact.
[17:30] <seb128> bdmurray, k, fair enough, mvo is not around though... but I guess the sdk can be buggy until tomorrow in vivid, not the end of the world
[17:30] <cjwatson> seb128: I commented, I don't think the systemctl case is necessary, better to stay in line with the other tools
[17:31] <cjwatson> bdmurray,pitti: https://bugs.launchpad.net/launchpad/+bug/1430431 - what is it that likes to dupe crashes even if the dupe target is private, anyway?
[17:31] <cjwatson> it's clearly not a Launchpad bug, we can't just show private bugs because it upsets people when we don't, but I don't know where to reassign that
[17:32] <bdmurray> cjwatson: its the retracer
[17:32] <cjwatson> bdmurray: is that the daisy project?
[17:33] <cjwatson> or apport?
[17:33] <bdmurray> cjwatson: its apport in this case
[17:33] <cjwatson> thanks
[17:34] <bdmurray> cjwatson: bug 675875
[17:34] <cjwatson> aha
[17:34] <seb128> cjwatson, ok, thanks
[17:37] <seb128> cjwatson, I changed it back to just check for initctl and do nothing if not there, if you want to approve I can put that in a silo
[17:41] <sarnold> pitti: thanks for the systemd-boot hint
[17:45] <seb128> tyhicks, hey, you marked https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/769595 as invalid for ecryptfs, do you think there is any chance to make home mounts work out of the box/without requiring user edition for ecryptfs users? (that currently makes the sdk fail to create schroots envs in a non obvious way)
[17:52] <tyhicks> seb128: hey - what do you mean by "requiring user edition"?
[17:52] <seb128> tyhicks, https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264
[17:53] <jodh> cjwatson: slangasek: I've attached a minimal patch to bug 1430403 along with a way to recreate. I guess you may want to consider applying this before the official SRU gets out.
[17:53] <seb128> tyhicks, basically schroot seems grumpy/can't unmount userdirs it mounts with the default fstab
[17:53] <seb128> tyhicks, which is what is described in that bug no?
[17:55] <tyhicks> seb128: I can't see how that could be fixed with a change to eCryptfs
[17:55] <tyhicks> seb128: but I'll poke at it a bit and update the bug with what I find
[17:56] <seb128> tyhicks, well, I didn't say it should be fixed in ecryptfs, but you seemed to have an understanding of the problem so I wanted to know if you had any suggestion on how we could get things to work out of the box
[17:56] <doko> cjwatson, infinity: https://launchpad.net/ubuntu/+source/dynare/4.4.3-1 says that dynare-matlab should be in the archive, but apt-cache show doesn't say so
[17:56] <seb128> tyhicks, we just had a new designer running into the same "can't unmount" issue making the schroot creating fail for the sdk
[17:57] <tyhicks> seb128: I think kirkland's suggestion is actually the better fix (if it works): https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/769595/comments/2
[17:57] <cjwatson> doko:  dynare-matlab | 4.4.3-1        | vivid/multiverse   | all
[17:57] <cjwatson> fix your sources.list
[17:58] <doko> argh
[17:58] <cjwatson> it's in contrib in Debian, so that matches
[17:58] <doko> sorry
[17:58] <tyhicks> (oh, kirk land didn't suggest that)
[17:58] <seb128> tyhicks, https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/791908 suggests that rbind is disabled in our kernel because it creates issues with autofs
[17:59] <seb128> tyhicks, in fact the default config uses rbind in click, but that seems to not work, I guess due to ^
[18:01] <tyhicks> seb128: I don't see where anyone says that we've disabled rbind in our kernel
[18:01] <tyhicks> seb128: sounds like rbind interacts badly with autofs but it is still available to use at the kernel level
[18:05] <seb128> tyhicks, I misread "Once the kernel is fixed to allow rbind to work safely, we can re-enable this."
[18:06] <seb128> tyhicks, I don't know why the default config that uses rbind doesn't work then
[18:07] <tyhicks> seb128: ok, I'll take a look at that by eod
[18:08] <seb128> tyhicks, thanks a lot
[18:08] <tyhicks> np!
[18:21] <tjaalton> hrm, the latest libc upgrade has now killed sessions on two of my desktops while it was setting it up
[18:24] <tjaalton> xserver crashes: (EE) Cannot establish any listening sockets
[18:25] <sarnold> anything in dmesg?
[18:25] <tjaalton> systemd started
[18:26] <tjaalton> so maybe it's messing things up a bit
[18:27] <cjwatson> seb128: that's fine thanks, please go ahead
[18:27] <cjwatson> (click/initctl)
[18:27] <seb128> cjwatson, thanks
[18:30] <infinity> mlankhorst: Oh, before I forget and we have the same timing fiasco again, can we make sure the lts-vivid stack is prepped early and kept refreshed, so you can land it pretty much right after vivid's release?
[18:30] <infinity> tjaalton: Was your system booted with upstart before the upgrade?
[18:31] <mlankhorst> infinity: I've had utopic stack ready in the ppa before the release, just didn't apply some of the sru's..
[18:32] <tjaalton> infinity: yes
[18:32] <infinity> tjaalton: Given that the latest libc upgrade was before the systemd swap, I'm guessing perhaps some bad interaction between updating libc (which tries to restart init) and systemd taking over the world.
[18:32] <tjaalton> yeah :/
[18:32] <tjaalton> X gets seriously confused
[18:34] <infinity> tjaalton: Hrm.  We'll definitely need to fix that one.  But I'm trying to think of how best to go about it.
[18:36] <tjaalton> pre-depends?
[18:36] <infinity> No.
[18:36] <infinity> Also, ew.
[18:37] <infinity> It's just that the "detect your init system and decide what to do" logic used in a few postinsts (libc isn't alone here) never accounted for the bizarre idea that you might swap the provider of /sbin/init halfway through your upgrade.
[18:38] <infinity> Or, rather, the provider of telinit, but same end result.
[18:39] <infinity> I would almost be inclined to suggest it's a systemd bug that "telinit u" execs systemd when the currently running PID 1 *isn't* systemd.
[18:39] <infinity> pitti: ^-- Thoughts?
[18:39] <infinity>        u, U
[18:39] <infinity>            Serialize state, reexecute daemon and deserialize state again. This is equivalent to
[18:39] <infinity>            systemctl daemon-reexec.
[18:39] <smoser> barry, so lets just say that i am being a luddite. and i'd like for fh.write(some_bytes_or_string)) to behave just like it did in simpler times of python2.
[18:39] <infinity> Seems unintuitive that "daemon-reexec" will also just do a frech exec if it has nothing to serialize and re-exec.
[18:40] <smoser> is there a way to accomplish such a thing?
[18:40] <lifeless> smoser: you can write a wrapper
[18:40] <lifeless> smoser: MagicFile(somebyteorientedfile, encoding)
[18:41] <smoser> right.. but more i'm asking what was the magic decoding that happened in python2.
[18:41] <lifeless> smoser: and in that create two handles
[18:41] <barry> smoser: well, a str in py2 is not the same thing as a str in py3, so you're really asking for fh.write(some_bytes_or_string_or_unicode)
[18:41] <lifeless> smoser: the magic decoding was that any operation between str and unicode triggered a .decode('ascii') on the str side
[18:41] <barry> which i think is fundamentally flawed ;)
[18:41] <lifeless> smoser:which is so reidiculously fragile....
[18:42] <lifeless> smoser: and that mechanism doesn't exist in 3; so you have to actually do type inspection in ones own code
[18:42] <lifeless> smoser: to emulate it
[18:43] <barry> smoser: what you might do is before the fh.write() call, do an isinstance test, and if the thing is not a bytes, encode it to utf-8 first.  (you could try ascii, catch the exception, and then try utf-8, and maybe you want/need other encodings too, but mostly utf-8 should do the trick in the common cases)
[18:43] <lifeless> smoser: see e.g. the cpython implementation of makedirs which does an isinstance check for bytes vs string in its own innards
[18:44] <smoser> but what did python2 do ?
[18:44] <lifeless> smoser: whats the thing you're doing where this is attractive?
[18:44] <smoser> because you never got a encoding exception if it was trying to fit into ascii what didn't fit there.
[18:44] <lifeless> smoser: I answered that above - the interpreter triggered a .decode('ascii') call
[18:45] <smoser> lifeless, i already admitted to being a luddite.
[18:45] <barry> smoser: right, but also, the io system was completely different in py2 so py3 is more strict (properly so) about whether you're trying to e.g. write bytes to a fh open in text mode
[18:45] <barry> or vice versa, season to taste
[18:45] <lifeless> smoser: I'm confused
[18:45] <lifeless> smoser: are you trying to understand what happened, or to reproduce it in Python 3?
[18:46] <infinity> tjaalton: Can you file a bug against systemd and subscribe pitti and I, so it doesn't get lost in the noise of IRC and brain backscroll?
[18:46] <lifeless> smoser: since you can't reproduce the entire thing in Python 3, I think barry and I are trying to offer enough support to let you figure out the closest approximation
[18:46] <infinity> tjaalton: I *think* I want to blame systemd, but if we have to, we can alter a bunch of postinsts to work around it.
[18:46] <ericsnow> pitti: ping
[18:46] <smoser> lifeless, in this case i want it to behave like python2. because that worked. and i understand all the reasons that that is bad.
[18:47] <lifeless> smoser: so we can do that for a single call site at a time.
[18:47] <infinity> ericsnow: It's late in pitti-land, a contentless ping might not get you much.
[18:47] <lifeless> smoser: we cannot do that for a whole program with all the things it might call
[18:47] <ericsnow> infinity: k, thanks
[18:47] <infinity> ericsnow: Adding some content might get you something useful though. :P
[18:48] <barry> lifeless: without some homebrew helper he uses everywhere of course :)
[18:48] <lifeless> smoser: if you have a small number of common objects that are causing you grief (e.g. you're just now porting something with confused string types)
[18:48] <ericsnow> infinity: I'm just trying to verify that vivid made the systemd switch yesterday
[18:48] <barry> ericsnow: it did
[18:48] <lifeless> smoser: then the best thing to do is to add isinstnace code either around or inside those common things
[18:48] <tjaalton> infinity: sure thing
[18:48] <ericsnow> barry: that's what it smelled like :)
[18:48] <barry> ericsnow: it borked one of my vms, but i had a disk snapshot which i reverted to and the second time it upgraded (almost) flawlessly
[18:49] <barry> ericsnow: one possibility: are you on vivid channel or devel channel?
[18:50] <barry> smoser: yep, i think `if not isinstance(obj, bytes): obj = obj.encode('utf-8')` is probably as close as you're going to get
[18:50] <ericsnow> barry: neither (other than ubuntu-devel, if that's what you mean)
[18:50] <barry> which isn't so much a fix as a tourniquet ;)
[18:51] <smoser> barry, lifeless thanks.
[18:51] <ericsnow> barry: ah, unicode porting issue :/
[18:51] <barry> ericsnow: i use rolling releases and was on 'devel' channel in sources.list but that seemed to cause my problem.  when i restored the disk image and s/devel/vivid/ it seemed to be okay
[18:51] <lifeless> barry: smoser: and/or .decode as appropriate
[18:51] <barry> ericsnow: yep.  more fun than any developer should be allowed to have
[18:51] <lifeless> smoser: what code base is it, and is our guess about porting right?
[18:51] <barry> lifeless: yep
[18:52] <ericsnow> barry: oh, that kind of channel (thought you meant IRC)
[18:52] <barry> ericsnow: yeah :)  other possibility of course is upgrading from utopic to vivid, but i wasn't doing that
[18:52] <ericsnow> smoser: if you're looking at how to decide the init system, you could check out how we're doing it in juju: https://github.com/juju/juju/blob/master/service/discovery.go
[18:53] <infinity> barry: devel is literally just a symlink to vivid, I expect your science was flawed there.
[18:53] <barry> infinity: or i was just unlucky in my timing
[18:54] <barry> infinity: although i have seen some errors from apt-get upgrade when literally using devel that don't show up w/vivid.  i suppose i should report that somewhere
[18:54] <smoser> lifeless, well, i'm looking at curtin now. i've had plenty of pain in 2to3 already.
[18:55]  * barry wishes he really had guido's time machine keys and could go back and kill the automatic coercion grandpa
[18:56] <infinity> ericsnow: Assuming init system based on OS version is probably not the sanest thing, FWIW.
[18:57] <tjaalton> infinity: filed, pitti should get all the bugs already
[18:57] <infinity> ericsnow: Ahh, nevermind, that's a last ditch fallback attempt after trying to do it sanely, I guess.
[18:57] <ericsnow> infinity: right
[18:58] <ericsnow> infinity: though we also key off the version in cases where we are working with a remote host (e.g. building a cloud init script)
[18:58] <lifeless> smoser: personally I never use 2to3
[18:58] <lifeless> smoser: six + single source is much easier to maintain IME
[18:58] <smoser> i'm not using 2to3
[18:58] <lifeless> smoser: oh good :) I was thrown by your comment about pain in it
[18:58] <smoser> writing code for 2 different interpreters is painful
[18:59] <lifeless> smoser: right - so this is what I do:
[18:59] <lifeless>  - write for 2.7 only
[18:59] <barry> smoser: only when the str/bytes model isn't clean (which unfortunately is the case for a lot of existing py2 code)
[18:59] <lifeless>  - use the backported io subsystem (which was added in 2.6) instead of the default IO subsystem
[19:00] <lifeless> this works pretty well
[19:00] <lifeless> with a very small number of PY2 checks - unittest2, traceback2, linecache2, testtools etc are all like this
[19:02] <lifeless> oh, and unicode string literals make a huge swath of pain go away
[19:02] <lifeless> IIRC they are 2.7 only, so I can't use them yet since my projects tend to still support 2.6 and 3.2
[19:03] <lifeless> so I have u("9~...") everywhere
[19:03] <jtaylor> why 3.2?
[19:03] <jtaylor> that should have pretty much 0 users
[19:03] <barry> precise lts is my guess
[19:04] <jtaylor> its in precise, but I doubt anybody actually uses it
[19:04] <lifeless> precise
[19:04] <jtaylor> if your stuck on precise you are more likely also still using python2
[19:04] <lifeless> easier to support it than to get bug reports
[19:04] <lifeless> on every release
[19:04] <barry> jtaylor: the server code which generates system-image.ubuntu.com :(
[19:04] <barry> (in my particular case)
[19:05] <lifeless> e.g. if I broke 3.2 support in unittest2, barry might well get unhappy :)
[19:05] <lifeless> (or in testtools, or ...)
[19:05] <hallyn_> except... apparently my custon /etc/acpi scripts were removed
[19:05] <smoser> is there a way to open sys.stdout in bytes ?
[19:05] <hallyn_> bastards
[19:05] <barry> :)
[19:05] <lifeless> smoser: yes
[19:06] <lifeless> smoser: python3 -u
[19:06] <lifeless> smoser: (or reopen at runtime, just fdopen however you want it and assign to sys.stdout
[19:07] <smoser> k. thanks, lifeless.
[19:07] <lifeless> smoser: but - I'd worry about doing this - why do you need stdout in binary?
[19:07] <smoser> because this code is just piping to 2 different places (stdout) and to a log the output of a command.
[19:08] <smoser> and i'd rather not take overhead of encode() on every byte read.
[19:08] <smoser> nor do i want to deal with failure to encode
[19:09] <lifeless> smoser: but AFAICT curtin has one entry point
[19:09] <lifeless> so you're going to force byte-internals for all of curtin if you do it this way, no ?
[19:10] <lifeless> smoser: why don't you put the pip in nonblocking mode rather than reading byte at a time
[19:10] <lifeless> smoser: that would be a lot faster overall - more than enough to offset the encode/decode overheads
[19:11] <lifeless> smoser: also you can write to sys.stdout.buffer directly if you have bytes to write
[19:11] <lifeless> smoser: assuming you're talking about http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/curtin/commands/install.py#L137
[19:13] <smoser> lifeless, yes, thats the code. the write there is getting output of a command.
[19:13] <smoser> ie, the subprocess.PIPE stdout.
[19:13] <smoser> i'm certain that this is not the best way to do this.
[19:28] <lifeless> smoser: right so the least change is to change self.write to use stdout.buffer.write rather than stdout.write
[19:29] <zyga> hey, not sure who to address this to, I'm interested in seeing the Ubuntu SDK components in Debian
[19:29] <zyga> I'm not sure if this includes unity
[19:29] <zyga> I'm hoping for the lowest common denominator
[19:29] <zyga> so that a converged mobile/desktop application which works fine in Ubuntu
[19:29] <zyga> can be also available in Debian
[19:30] <zyga> I need hints on who to talk to and if this has been attempted before
[19:30] <lifeless> smoser: (or make a new io.BufferedWriter(sys.stdout.buffer)
[19:31] <lifeless> smoser: hmm no need for that, just use sys.stdout.buffer, its a BufferedWriter already
[19:44] <lifeless> smoser: and open install_log as 'wb' to get a bytes expecting log
[19:44] <smoser> yeah.
[19:44] <smoser> did that.
[19:45] <lifeless> if you have other code thats writing string literals to install log, you could have two objects, one Text and one the BufferedWriter
[19:48] <smoser> lifeless, in python2, no sys.stdout.buffer.
[19:49] <lifeless> smoser: ok, so you need single source
[19:49] <lifeless> smoser: let me dig up a code ref for you
[19:51] <lifeless> smoser: https://github.com/testing-cabal/subunit/blob/master/python/subunit/run.py#L133
[19:51] <lifeless> oh, nope thats not the code I was thinking of
[19:51] <lifeless> smoser: but its generalisable
[19:52] <smoser> i was just doing the hasattr check on sys.stdout
[19:53] <lifeless> if you do the io.open(stdout.fileno(), 'wb', 0) thing you'll get a stdout thats in binary mode,
[19:53] <lifeless> if you open it in 'wt' via io.open you'll get the three stack, IIRC.
[19:53] <lifeless> in both 2.x and 3.x
[19:56] <lifeless> smoser: so http://paste.openstack.org/show/191400/
[19:56] <lifeless> smoser: then you just write good type aware code through the rest of curtin - stdout for text, stdout.buffer for bytes
[19:56] <smoser> lifeless, but in this case i dont want it in wt
[19:56] <lifeless> smoser: (that trasnscript is from 2.7)
[19:56] <smoser> right ? i want it in bytes.
[19:56] <lifeless> smoser: you're never going to write messages for humans?
[19:57] <lifeless> smoser: anywhere in curtin ?
[19:57] <lifeless> e.g. localisation
[19:59] <smoser> ok. i was just confused.
[19:59] <smoser> you're saying opening in wt still allows me to write bytes to .buffer
[19:59] <lifeless> yes
[19:59] <lifeless> it will give you the same structure as python3 has by default
[20:00] <lifeless> on python3 open is io.open, on python2 open is a builtin magic thing and io.open is there if you wish to use it
[20:46] <tjaalton> win 23
[20:46] <Unit193> /
[20:46] <tjaalton> indeed
[21:58] <seb128> could some buildd admin retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-025/+build/7048336 ?
[22:23] <wgrant> seb128: Done.
[22:23] <seb128> wgrant, thanks
[22:45] <bluesabre> Is anybody available to force a rebuild of three packages? https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1424887/comments/12
[23:00] <roaksoax> pitti: are we keeping service commands for systemd or should we also adapt our code to do systemctl ?
[23:01] <cjwatson> bluesabre: doesn't need an archive admin, just any uploader - Ubuntu doesn't have special binNMUs like Debian, we just do new source uploads
[23:01] <cjwatson> roaksoax: service still exists and works
[23:02] <bluesabre> cjwatson: It's outside of the xubuntu packageset, so was hoping to grab somebody in here
[23:02] <roaksoax> cjwatson: but in vivid it will start systemd units
[23:03] <cjwatson> roaksoax: yes, that's worked for ages.  grep systemctl /usr/sbin/service
[23:03] <cjwatson> bluesabre: sure, I'm just saying that if you're looking for core-devs rather than archive admins then that's a much wider pool of people
[23:12] <roaksoax> cjwatson: cool thanks
[23:12] <bluesabre> cjwatson: agreed, thanks :)