=== timrc-afk is now known as timrc
[00:24] <siretart> Logan_: thanks :-)
[00:24] <Logan_> for what? :P
[00:25] <Logan_> oh, my PM?
[00:27] <siretart> yes :)
=== roadmr_afk is now known as roadmr
[00:46] <pfsmorigo> hi, what source this message came from? "An installation step failed. You can try to run the failing item again from the menu" I though that was from debian-installer but I did't find it.
=== roadmr is now known as roadmr_afk
[01:40] <siretart> infinity: libav built everywhere now. I think we're good to start the transition
=== roadmr_afk is now known as roadmr
[02:08] <alkisg> Hi, in Ubuntu 14.04, gedit depends on libzeitgeist-2.0-0. If I keep that library, but remove the zeitgeist app which happens to be preinstalled,
[02:08] <alkisg> then gedit won't start until I disable the "zeitgeist gedit plugin"
[02:08] <alkisg> Error message: ** (gedit:3187): CRITICAL **: zeitgeist_log_insert_event_no_reply: assertion 'self != NULL' failed
[02:08] <alkisg> Should I file a bug in upstream gedit to have the gedit zeitgeist plugin not crash gedit when zeitgeist isn't installed,
[02:08] <alkisg> or file a bug against debian/ubuntu to depend on zeitgeist, and not just its library?
[02:18] <siretart> alkisg: the former sounds appropriate in any case
[02:18] <alkisg> siretart: depending means that sysadmins that want zeitgeist off globally, can't remove it from their systems... is that a requirement for using gedit?
[02:18] <alkisg> Ah
[02:19] <alkisg> Really sorry, misread
[02:19] <alkisg> True, about the former, I was mostly asking if it's ubuntu specific or not
[02:19] <alkisg> If it's not ubuntu specific, then a bug should be filed, of course...
[02:23] <alkisg> Hmmm, the ubuntu-settings package seems to force enablement of zeitgeist plugin: /usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override:active-plugins = ['docinfo', 'modelines', 'filebrowser', 'spell', 'time', 'zeitgeistplugin']
[02:28] <alkisg> org.gnome.gedit.gschema.xml on the other hand says: <default>['docinfo', 'modelines', 'filebrowser', 'spell', 'time']</default>
[02:29] <alkisg> So I guess reverting the Ubuntu defaults to match the upstream defaults, would solve the issue, until it's fixed upstream, if they ever want to fix it...
[02:29]  * alkisg files a bug report about that...
=== salem_ is now known as _salem
[04:38] <Logan_> why isn't texlive-bin automatically syncing from unstable?
=== timrc is now known as timrc-afk
[06:06] <Noskcaj> How can i force dput to include a .orig file? MY ppa uploads are being rejected because the .orig isn't able to be found
=== Ursinha-afk is now known as Ursinha
[06:06] <rsalveti> pitti: ogra_: quite a few new error messages today when booting the emulator: http://paste.ubuntu.com/7549208/, not sure yet what caused that
=== tedg is now known as ted
[06:06] <rsalveti> probably in any touch image
[06:07] <ogra_> rsalveti, likely systemd transition fallout
[06:08] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/54.changes .... cgmanager, systemd/udev and sysvinit changed
[06:14] <Unit193> Noskcaj: -S -sa
[06:14] <Noskcaj> thanks
[06:14] <Unit193> -sa            uploaded source always includes orig.
=== ted is now known as tedg
[06:16] <ogra_> rsalveti, at least my flo still boots after upgrade ... phew
[06:17] <rsalveti> haha, yeah, emulator booted fine as well, but with some additional error messages
[06:18] <ogra_> you shocked me for a moment :P
[06:28] <xnox> rsalveti: mostly harmless, temporary until a reliable solution is available to re-enable parallel boot/shutdown again.
[06:33] <rsalveti> xnox: alright :-)
[06:40] <pitti> rsalveti: yes, known; I'll file a bug about this now, we couldn't fix it yesterday
[06:45] <rsalveti> pitti: thanks
[06:48] <pitti> RAOF: did you see that colord is depwait on argyll?
[06:49] <Noskcaj> rsalveti, I'm trying to make a ppa for the upower 1.0 transition. Any idea why powerd is FTBFS? https://launchpadlibrarian.net/176601456/buildlog_ubuntu-utopic-amd64.powerd_0.15%2B14.10.20140428-0ubuntu1ppa1_FAILEDTOBUILD.txt.gz I ask since you had the most recent commit to it
[06:49] <RAOF> pitti: In Ubuntu? Yeah.
[06:49] <RAOF> pitti: I'll need to disable that bit for Ubuntu.
[06:50] <pitti> RAOF: hm, conditional build deps sound tricky
[06:50] <Noskcaj> pitti, Do i need to do anything to make python-dbusmock build for upower 0.99?
[06:51] <RAOF> pitti: Actually, no; it only generates extra files to ship alongside existing ones in colord-data
[06:51] <pitti> Noskcaj, rsalveti: that souds like fallout from the platform-api API change of returning floats in out args instead of return vallues
[06:51] <pitti> Noskcaj, rsalveti: (as float returns are weird on arm with Android, it's using a differetn calling convention)
[06:51] <Noskcaj> um...
[06:52] <Noskcaj> I think i'll leave that till last then
[06:52] <pitti> Noskcaj: in principle not; the test suite calls upower --version and based on that decides whether to expect/emulate the 0.9 or 1.0 API
[06:52] <pitti> Noskcaj: I tested it against upower 0.99 back then; so unless the API changed again in 1.0 it sohuld still work
[06:52] <Noskcaj> 1.0 isn't out yet, just making a ppa to help (at the request of ubuntu-gnome)
[07:04] <infinity> xnox: procps is in the buildd chroots because initscripts (and its deps) is, because initscripts should be essential, except we screwed up. :P
[07:04] <ogra_> infinity, enough that we cant make the touch images writable anymore :P
[07:05] <ogra_> which breaks pretty much all testing in the lab
[07:05] <infinity> ogra_: Hrm?
[07:05] <ogra_> infinity, mountall remounts the fs readonly since today ... regardless if it is supposed not to
[07:05] <infinity> xnox: procps is neither essential or build-essential, though, if that was what you were asking in a roundabout way.
[07:06] <infinity> ogra_: How does the content of a buildd chroot have anything to do with that?
[07:06] <ogra_> i assume thats related to the initscripts/procps/sysvinit changes from yesterday
[07:06] <ogra_> infinity, "except we screwed up" ... i was referring to that part of the line ;)
[07:06] <xnox> infinity: thanks for details, luckily we didn't need procps chroot surgery as it didn't manage to slip into -release pocket and we deleted in from -proposed early enough.
[07:07] <infinity> ogra_: Totally unrelated screw up.
[07:08] <xnox> infinity: working on a patch to startpar at the moment, to make it become aware of upstart tasks, instead of modifying all upstart jobs which are tasks and have an initd script.
[07:08] <Noskcaj> pitti, https://launchpadlibrarian.net/176602234/buildlog_ubuntu-utopic-i386.python-dbusmock_0.10.1-1ppa1_FAILEDTOBUILD.txt.gz
[07:09] <pitti> Noskcaj: ok, so apparently it changed a bit more; can you please file a bug about this with a pointer to your PPA? can't do that right now (sprint)
[07:09] <Noskcaj> ok
[07:09] <pitti> thanks
=== Ursinha is now known as Ursinha-afk
[07:21] <xnox> pitti: http://paste.ubuntu.com/7549587/ of which 'rc' is false possitive, 'udev-finish' is fixed, 6 - to go.
[07:21] <xnox> pitti: or we can do a startpar patch to consider tasks as always done and ready.
[07:23] <pitti> xnox: oh, that looks manageable
[07:23] <pitti> xnox: I'd prefer a solution in upstart to track whether a task ever ran, but we need something today to unbreak the phone builds
[07:24] <pitti> xnox: ogra says they are completely broken
[07:24] <xnox> pitti: well, i have this solution -> (let me pastebinit)
[07:25] <xnox> pitti: http://paste.ubuntu.com/7549610/
[07:26] <pitti> xnox: WEXITSTATU"S" -- and erk system() :)
[07:27] <xnox> pitti: =) didn't compile yet
[07:27] <xnox> pitti: in that code, it does 'initctl status' but it should also check for 'not a task'
[07:28] <xnox> pitti: cause we should be resiliant to people who happen to have 3rd party things that have both an upstart job and init.d script.
[07:29] <ogra_> stgraber, poke ... could we rip out image 54 from the server ? people are not able to make the image writable anymore which will block quite a few peoples work i suspect (not to talk about the lab just exploding in flames)
[07:29] <pitti> xnox: so this will basically assume that upstart is always fast enough to execute task dependencies before startpar gets to it?
=== Ursinha-afk is now known as Ursinha
[07:31] <xnox> pitti: it assumes that events do happen, ahead of executing rc, yes. That is true on boot, in ubuntu, because we mostly do udev-based boot (instead of initscript based assembly of raid/lvm2 etc.). And also true on shutdown/stop -> all tasks are stopped.
[07:32] <xnox> pitti: (there is a small amount of upstart tasks which kick in on shutdown, but there is very little of those with no init.d scripts, i believe)
[07:32] <pitti> xnox: so yes, even if it might not be entirely correct it still sounds like progress over the current situation
[07:33] <pitti> xnox, ogra_: let me try what happens if we empty out all the affected init.d scripts
[07:33] <ogra_> ++
[07:40] <xnox> pitti: one simply shouldn't call update-rc.d on them, or we fix startpar/sysv and test&land it.
[07:40] <xnox> ogra_: when is the next image build?
[07:40] <ogra_> xnox, when we have a fix ;)
[07:44] <xnox> ogra_: ack
[07:45] <pitti> ogra_: just to avoid panic for everyone who reads u-phone@: that's got nothing to do with systemd :)
[07:46] <ogra_> pitti, it doesnt ?
[07:46] <pitti> ogra_: no, that's about catching up with Debian's sysvinit/insserv/upstart policy
[07:47] <ogra_> pitti, and thats not part of the systemd transition ?
[07:47] <pitti> ogra_: it's a pre-pre-pre-requisite, but something which we have to do anyway
[07:47] <ogra_> right, indeed :)
[07:47] <pitti> non-insserv for sysvinit has been deprecated by Debian a long time ago, so at some point we need to follow unless we also want to start maintaining init.d script runlevels ourselves
[07:49] <pitti> ogra_: the fun thing is that none of this is a problem when you actually do boot with systemd :)
[07:49] <pitti> ogra_: but anyway, be assured that we won't switch the phone to systemd anytime soon
[07:50] <ogra_> pitti, yeah, i annoyed slangasek enough with this question this week already ;)
[07:52] <slangasek> ogra_: weren't you /in/ the UDS session where we decided this? ;)
[07:52] <ogra_> slangasek, heh, yeah, i guess :)
[07:53] <ogra_> pitti, sent a followup mail to clearify a bit
[07:57] <pitti> ogra_: this seems to help quite a bit:
[07:57] <pitti> for f in checkroot.sh checkroot-bootclean.sh checkfs.sh mountkernfs.sh mountdevsubfs.sh mountall.sh mountnfs.sh mountnfs-bootclean.sh mountall-bootclean.sh; do echo '#!/bin/true' | sudo tee /etc/init.d/$f; done
[07:57] <pitti> ogra_: but NB this is not something which we ever want to put in our packages, but it might be a quick'n'dirty workaround for the image builds
[07:57] <pitti> ogra_: this essentially disables the init.d scripts which now get called although they shouldn't
[07:57] <pitti> but touching conffiles and stuff
[07:58] <ogra_> cant we just rm them ?
[07:58] <ogra_> pitti, we dont care about conffiles on system-images ... (well only at build time)
[07:58] <pitti> ogra_: that'll break updare-rc.d, so any package you try to install will cause failures from insserv
[07:58] <pitti> ogra_: right, hence my proposal to change them to /bin/true
[08:01] <pitti> xnox: inline comments in MPs!
[08:02] <slangasek> I realize this is a quickfix, but that sounds really horrible
[08:02] <ogra_> pitti, works fine ...
[08:03] <ogra_> slangasek, we wont promote any image before a reaal fix lands ... thats just to get developers usable development systesm again
[08:03] <pitti> slangasek: yes, I never want that to get near any .deb, just as a post-install fix in image builds
[08:03] <ogra_> *systems
[08:03] <pitti> slangasek: I'm reviewing xnox' MP now, but I have a feeling we won't land that in an hour
[08:03] <slangasek> pitti: I don't understand how you expect that to help anyway, these are the same scripts that already source /lib/lsb/init-functions so are a no-op on upstart
[08:03] <ogra_> i'll stuff it in a live-build hook script
[08:03] <pitti> slangasek: they aren't; the LSB hook only helps for "sudo /etc/init.d/..."
[08:04] <pitti> slangasek: but rc/upstart call them as /etc/rc?.d/Snnfoo, which isn't being recognized by the hook
[08:04] <slangasek> um
[08:04] <slangasek> then that lsb hook is broken and does not do what I understood it was meant to do
[08:04] <pitti> slangasek: initially I thought that was a bug, but xnox convinced me it's on purpose
[08:04] <xnox> slangasek: the hook was to fix, users/puppet/etc calling /etc/init.d/
[08:04] <ogra_> seems we find truckloads of wormy cans this week :)
[08:04] <slangasek> xnox: except our insserv transition also relied on this lsb hook providing us cover
[08:04] <pitti> slangasek: I tried to "fix" the LSB hook to do a readlink first, then it actually ignores the script; but I got a hung boot with that
[08:05] <slangasek> xnox: for the window between running update-rc.d for the do-not-run init script, and converting to insserv
[08:05] <slangasek> since that's the order it has to happen in
[08:05] <slangasek> sorry, I assumed that this is what the lsb init hook was doing
[08:05] <pitti> yes, so was I
[08:05] <slangasek> (despite having read the code earlier, I forgot it didn't)
[08:06] <pitti> slangasek: and I still think we should do that somehow; if not through the LSB hook then at least some moral equivalent
[08:06] <slangasek> it should just be in the LSB hook, we shouldn't add even more moving pats
[08:06] <slangasek> parts
[08:06] <xnox> slangasek: what do you think about the patch against sysvinit to consider task jobs as done?
[08:06] <xnox> well starpar component.
[08:07] <pitti> slangasek, xnox: one idea would be to disable startpar again until we fixed the handling of tasks properly, and instead ignore init.d scripts in /etc/init.d/rc if there is a corresponding upstart job
[08:07] <slangasek> xnox: so I understand that the current LSB hook *doesn't* make them no-ops when called directly; but what's the reason to *not* make them no-ops?
[08:07] <slangasek> xnox: i.e., pitti said you convinced him it's "on purpose"
[08:08] <slangasek> xnox: startpar patch> well I hope you aren't expecting me to tell you it's beautiful ;)
[08:08] <xnox> slangasek: calling via /etc/rc* -> can & should be no-ops. calling via /etc/init.d* -> should do what the user asked to do
[08:08] <slangasek> xnox: we talked earlier about startpar timeouts; wouldn't a timeout fix the problem without introducing a slowdown for users whose systems aren't broken?
[08:08] <jpds> Noskcaj: Probably.
[08:09] <jpds> Noskcaj: Feel free to update it, otherwise I'll look into it later.
[08:09] <xnox> slangasek: hahaha. Let me read more about the timeouts.
[08:09] <slangasek> xnox: ok.  In that case, you agree that the lsb hook should be fixed for this?
[08:09] <Noskcaj> jpds, I don't really understand the change, i'm just hoping it fixes the ftbfs. I'll leave it for you
[08:10] <xnox> slangasek: yes. As in, init.d behaviour stays the same (call the real action), rc*.d/[SK]\d* -> is a no-op.
[08:12] <jpds> Noskcaj: Oh, that's good to know, thanks.
[08:13] <ogra_> cjwatson, mind takeing a quick look at http://paste.ubuntu.com/7549809/ ?
[08:13] <ogra_> -e
[08:14] <slangasek> xnox: ok.  Can you put that together and I'll review?  And is that sufficient to unbreak the phone image?
[08:15] <ogra_> slangasek, xnox, so should i hld back the above hack ?
[08:15] <ogra_> *hold
[08:15] <xnox> slangasek: let me confirm both of those.
[08:16] <slangasek> ogra_: I estimate 1.5h before we can land this (proper) fix
[08:19] <ogra_> hmm, 1.5h + upload + propagation + image-build ... thats most likely the whole day we will block landings ...
[08:19] <ogra_> OTOH we would only be 1.5h earlier if i upload now ...
[08:19] <pitti> xnox, slangasek: added a blurb to the MP
[08:19] <ogra_> sil2100, thoughts ? ^^
[08:20] <pitti> xnox: calling via /etc/rc* -> can & should be no-ops. calling via /etc/init.d* -> should do what the user asked to do
[08:20] <sil2100> ogra_: let me think
[08:20] <pitti> xnox: so the LSB hook is behaving exactly opposite now
[08:21] <plars> sil2100: ogra_: are we still considering pulling the image out of s-i? there's still a risk I guess at the moment that someone updates to it
[08:21] <ogra_> plars, we cant really fix people that already upgraded ... going forward with a fixed image fast would be better
[08:21] <pitti> xnox: but I don't think that running /etc/init.d/foo should actually do that; I think running the upstart job instead is the right thing to do, no?
[08:22] <pitti> slangasek, xnox: I'll re-try with adding the missing readlink to the LSB hook; it hung yesteday
[08:22] <slangasek> pitti: we shouldn't drive execution of the upstart job, at boot time, from startpar
[08:22] <slangasek> (or from rc)
[08:22] <sil2100> ogra_, plars: I wouldn't worry about it that much, as people should be aware of that devel images can be broken by principle
[08:23] <pitti> slangasek: yes, fully agreed
[08:23] <ogra_> proposed you mean :)
[08:23] <slangasek> it's better to skip it entirely in this case than to risk running two copies of a daemon, or worse
[08:23] <sil2100> ogra_: I must say that I'm not particulary fond of landing a quick-fix to gain like only 1.5h
[08:23] <sil2100> ogra_: right ;) Typo
[08:23] <sil2100> (big one)
[08:23] <pitti> slangasek: WDYT about skipping init.d scripts in the non-startpar portion of /etc/init.d/rc if there's an upstart job?
[08:23] <ogra_> sil2100, right, but seeing that there is still a discussion about the proper way of fixing it here it might probably be more than 1.5h
[08:23] <pitti> slangasek: and keep startpar disabled for now (as in current utopic)
[08:23] <sil2100> ogra_: let's meet on the landing meeting and talk about it then
[08:24] <pitti> slangasek: that should essentially do what we always did
[08:24] <sil2100> It's like in 7 minutes
[08:24] <cjwatson> ogra_: err, what.  is it really quicker to do this madness than to fix the init scripts in question?
[08:24] <sil2100> ogra_: how does your workaround fix look like?
[08:24] <slangasek> cjwatson: the init scripts aren't "broken"
[08:24] <cjwatson> this is out of the blue for me
[08:24] <pitti> the upstart jobs are fine, so are teh init scripts; it's startpar not knowing about upstart tasks (nor upstart having a way to tell startpar) which is the problem
[08:24] <slangasek> cjwatson: we reintroduced the init scripts, relying on the lsb init-functions hook to make them all no-ops
[08:25] <pitti> hence my proposal to keep startpar disabled until we fix that properly
[08:25] <slangasek> (or pass-throughs)
[08:25] <pitti> can we meet in person somewhere?
[08:25] <slangasek> pitti: people have been looking for you and not finding ;)
[08:25] <pitti> ballroom
[08:25] <pitti> I can come someplace else
[08:25] <pitti> where are you?
[08:25] <slangasek> we're in studio 3, but xnox just went again looking for you; let's come there
[08:27] <pitti> ack, on my way
[08:27] <slangasek> pitti: no, we'll come to you
[08:28] <pitti> ack
[08:29] <xnox> pitti: i'm in studio 3.... where abouts are you?
[08:30]  * xnox is also attached to a power socket at the moment.
[08:41] <slangasek> xnox: can you come to the ballroom?
[08:42] <xnox> slangasek: yes
[08:44] <pitti> xnox: ballroom
[08:44] <slangasek> pitti: he's here
[08:45] <pitti> xnox: I'm testing an LSB hook update, then we can compare ideas
[08:46] <xnox> pitti: oh. ok.
[08:54] <sarnold> pitti,xnox: 1322296 init.d file for procps
[08:56] <pitti> sarnold: hm, procps already has an init. script?
[08:57] <ogra_> xnox, FYI i uploaded the livecd-rootfs hack right now so take your time, will be enough if it lands today and without hurry
[08:57] <infinity> pitti: The log in the bug report shows it was with the broken procps that was removed from proposed.
[08:57] <sarnold> pitti: oh, interesting, the bug report is about 1:3.3.9-1ubuntu4 but launchpad says 1:3.3.9-1ubuntu3 is the newest for utopic..
[08:58] <sarnold> did 4 make it to -release or was it only ever in -proposed?
[08:58] <infinity> sarnold: Only proposed, AFAIK from backscroll.
[08:59] <infinity> A fresh upload to supersede it should probably still be done, if the thing that broke it is no longer broken.
[09:00] <infinity> Oh, the thing that broke it was xnox. :P
[09:00] <sarnold> lol
[09:08] <pitti> infinity: not necessary any more
[09:08] <pitti> it's really wrong to un-task all our upstart tasks
[09:17] <xnox> ogra_: please no.
[09:17] <ogra_> xnox, no what ?
[09:18] <xnox> ogra_: uploading livecd-rootfs.
[09:18] <xnox> pitti: http://paste.ubuntu.com/7550129/
[09:18] <ogra_> xnox, already happened ... (and agreed on by all involved parties)
[09:18] <xnox> ogra_: slangasek, pitti and myself?!
[09:18] <xnox> ogra_: and cdimage team?
[09:19] <xnox> ogra_: please stop ignoring !landing
[09:19] <ogra_> xnox, yes
[09:19] <pitti> ogra_: yeah, I thought you had a way to modify the images that doesn't involve uploads; but *shrug* that's ok for now
[09:19] <pitti> once the the fixed lsb lands we can take out that hack again
[09:19] <ogra_> xnox, colin and steve were in the landing team meeting
[09:19] <ogra_> where we decided that
[09:19] <xnox> ogra_: cool.
[09:19] <pitti> it's really moot to discuss that now..
[09:19] <ogra_> xnox, i'll revert it immediately if your fix is in ... no worries
[09:20] <ogra_> xnox, the point is that we need test results for a certain set of landings in 54 and the archive moves underneath us ... that was the base of this decision
[09:20] <RAOF> infinity: Are you around anywhere?
[09:23] <pitti> xnox: http://paste.ubuntu.com/7550154/
[09:23] <slangasek> xnox: sorry, I did agree with ogra+LT that they should proceed with the interim fix - don't worry about it, just make the interim fix irrelevant ;)
[09:24] <infinity> RAOF: Not really.  I seem to be broken, and am therefor hiding in my room.
[09:24] <RAOF> infinity: Sorry to hear that.
[09:47] <xnox> ev: yes, my merge proposal has inline comment.
[09:54] <pitti> ogra_, slangasek: FYI, this will fix the phone without the crazy livefs-build hack: https://launchpad.net/ubuntu/+source/lsb/4.1+Debian11ubuntu8
[09:54] <pitti> I'll also do a sysvinit upload to remove some noise, but that's mostly cosmetical
[10:02] <pitti> sil2100: you want that for the next image build: https://launchpad.net/ubuntu/+source/lsb/4.1+Debian11ubuntu8
[10:03] <pitti> sil2100: and if you so please, we can revert the temporary hack from https://launchpad.net/ubuntu/+source/livecd-rootfs/2.215
[10:03] <infinity> pitti, xnox: I might nitpick that that now runs "initctl version" twice for no good reason sometimes.
[10:04] <pitti> infinity: when?
[10:04] <infinity> pitti: Oh, wait, no, I guess not.
[10:04] <pitti> it sucks enough that we have to call it for every init.d script already
[10:04] <infinity> pitti: I didn't read the tests right.
[10:04] <infinity> pitti: So, it's just ugly code duplication, but not actually running twice.
[10:04] <pitti> wishlist: provide a test for "am I running upstart" which just involves a stat
[10:05] <pitti> that'll go away again once we made startpar friends with upstart tasks, but that still seems to be disputed, and not trivial to do
[10:05] <sil2100> pitti: thanks for the info!
[10:05] <pitti> sil2100: yw; what a mess :/
[10:07] <slangasek> pitti: would really prefer we focus on sunsetting upstart and its related compatibility code instead of trying to optimize the per-init-script upstart check that is only relevant when *not* using startpar
[10:07] <slangasek> (which we should enable soon)
[10:08] <pitti> slangasek: yes, agreed
[10:09] <pitti> slangasek: until then it shouldn't matter that much whether we use startpar or not, but like that we'll probably see some boot time regression
[10:09] <pitti> but for enabling startpar we'll have to adjust upstart (unless anyone has a better idea?)
[10:10] <pitti> or the upstart starpar bridge (I don't fully know how that works, I just understood that it doesn't run all the time right now)
[10:12] <slangasek> pitti: I'd like to understand why we have as many task jobs as claimed that are also init scripts
[10:13] <pitti> slangasek: we have ~ 100 tasks; I didn't yet check which of those are also being used as dependencies of init.d scripts, but presumably not that many
[10:13] <pitti> slangasek: certainly 10 or less
[10:14] <slangasek> right - most tasks should not have corresponding init scripts
[10:14] <pitti> the problem is not that, but init.d scripts which *depend* on an upstart task
[10:15] <slangasek> yes
[10:15] <slangasek> well, both are problems
[10:15] <slangasek> because *any* init scripts shadowed by tasks would result in startpar waiting forever
[10:15] <slangasek> (the procps problem)
[10:16] <slangasek> init.d scripts really should not be depending on an upstart task, and I'd rather we fix this by exposing a non-task upstart interface in the package
[10:16] <slangasek> because this affects shutdown too, not just startup
[10:16] <pitti> slangasek: i. e. what we started with http://launchpadlibrarian.net/176539305/systemd_204-10ubuntu7_204-10ubuntu8.diff.gz ?
[10:17] <pitti> slangasek: it feels like a workaround to me, but indeed it's the only other way that I see aside from telling apart "never run" from "ran at least once"
[10:18] <slangasek> pitti: it's a workaround, it's a bit more work on different packages but this is all a one-off and requires much less design than trying to change upstart behavior or making deep changes to upstart/startpar interaction
[10:18] <pitti> slangasek: ok; WFM
[10:18] <xnox> slangasek: we can reorganise our jobs, but 3rd parties that ship both init.d script and upstart task can doom boot & shutdown still.
[10:18] <slangasek> pitti: and as for third-party jobs, I mentioned to xnox this morning that properly supporting startpar's timeout functionality for these jobs would handle that
[10:19] <xnox> slangasek: right.
[10:19] <xnox> slangasek: i didn't look into timeout yet, but it appeared that it was timeout for interractive jobs only, of which all upstart jobs are not.
[10:19] <xnox> but maybe i'm wrong.
[10:19] <slangasek> task+init.d would be a "local configuration error", but the failure scenario would just be that startpar delays the boot, then the system boots up, then the task is considered "already stopped" at shutdown (which is correct)
[10:19] <slangasek> xnox: ah
[10:24] <pitti> stgraber: would you mind fast-tracking lsb? enough tests have succeeded now to show that it should be ok, and we tested it on iron, tablet, VM, and chroot
[10:24] <BluesKaj> 'Morning
[10:24] <pitti> or cjwatson ^
[10:25] <xnox> pitti: nut is failing... http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb
[10:25]  * xnox check if it has a hint.
[10:25] <pitti> xnox: yes, bug 1291378, retried
[10:25] <ubottu> bug 1291378 in nut (Ubuntu) "test_CVE_2012_2944 autopkgtest is racy" [High,Confirmed] https://launchpad.net/bugs/1291378
[10:25] <pitti> that's the one I always have to retry umpteen times
[10:25] <pitti> I hope it's just a bad test, not a bad vuln fix
[10:27] <infinity> pitti: Hinted.
[10:27] <stgraber> infinity: gah, you're too fast :)
[10:27]  * stgraber goes for some food instead
=== Ursinha is now known as Ursinha-afk
[11:08] <infinity> pitti: I'm not sure what to make of http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-tetex-brev/7/
[11:08] <infinity> pitti: It looks like amd64/i386 are done, but the job still seems to be "running".
[11:09] <infinity> pitti: And, odder still, there's a reference to a ppc64el host in the corner?
[11:21] <ogra_> xnox, how is the migration looking ?
[11:25] <xnox> ogra_: migrated 41 minutes ago.
[11:25] <ogra_> perfect !
[11:25] <ogra_> let me revert the hack then
[11:25]  * xnox feels like personal service rmadison =)
=== Ursinha-afk is now known as Ursinha
=== tedg is now known as ted
=== ted is now known as tedg
[11:44] <xnox> sergiusens: cjwatson: rsalveti: bug #1324889
[11:44] <ubottu> bug 1324889 in click (Ubuntu) "click chroot should use -gles qt packages in the i386 chroot" [Undecided,New] https://launchpad.net/bugs/1324889
[11:44] <sergiusens> thanks
[11:45] <rsalveti> xnox: thanks
[11:45] <xnox> sergiusens: checked the code, it installs the stock variant only, which is gl on i386 =(
[11:51] <xnox> tedg: https://code.launchpad.net/~jamesodhunt/upstart/cgroups-mergeable-with-upstart-async
=== _salem is now known as salem_
[12:00] <pitti> infinity: the reference to the ppc64el host is a jenkins stupidity; it's running the "meta-job" which binds i386 and amd64 on an arbitrary node (but then doens't actually physically run stuff there)
[12:00] <pitti> infinity: thanks for hinting
[12:06] <Chipaca> https://wiki.ubuntu.com/Chipaca/PPU \o/
[12:06] <Chipaca> sergiusens: are you an ubuntu dev?
[12:06] <xnox> stgraber: are you in the unified mobile & desktop session now?
[12:06] <sergiusens> Chipaca: no; I'm not; just a ppu
[12:06] <xnox> stgraber: room 3, questions about lxc are raised...
[12:07] <Chipaca> sergiusens: so not that much point in you endorsing my ppu, i guess
[12:08] <Chipaca> hmmm. dobey? ev?
[12:11] <stgraber> xnox: ok, I'll come then
[12:26] <infinity> siretart: FWIW, there's a mention in that ppc64el bug that "qemu doesn't support it yet"... qemu in trusty-updates can happily boot and install (and run) ppc64le in full emulation (ie: on x86).
[12:26] <infinity> siretart: s/bug/patch/
=== salem_ is now known as _salem
[12:39] <xnox> sergiusens: i need to talk to you about ubuntu-emulator and how we wan it to handle booting normal or recovery, and how to communicate from the emulator to suggest what the next boot should be.
[12:39] <xnox> i have a few options now.
[12:39] <sergiusens> xnox: let's do that now
[12:39] <sergiusens> xnox: where can I find you?
[12:39] <xnox> i am outside studio 3 now.
[12:39] <xnox> sergiusens: you?
[12:39] <sergiusens> I'll go there
[12:40] <dobey> mvo: what is the path for the file i need to change for packagekit?
[12:42] <mvo> dobey: /etc/PackageKit/PackageKit.conf
[12:43] <dobey> i don't have that. is it not from a default-installed package?
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
[13:36] <pitti> bdmurray: apport 2.14.3 uploaded
[13:39] <xnox> Saviq: hey, you about?!
[13:39] <xnox> Saviq: looking at cgo and i would want to try a few things with you.
[13:39] <xnox> Saviq: i think it's trivial to enable it crosscompilation.
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== jcastro_ is now known as jcastro
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
[13:51] <goarilla> anyone here that navigated the ubuntu gfxboot inc configuration files ?
=== salem_ is now known as _salem
[13:55] <goarilla> how to I disable the F1,F2,F3 buttons and language overlay ?
[13:55] <goarilla> I have gfxboot-theme-ubuntu unpacked
=== timrc-afk is now known as timrc
=== _salem is now known as salem_
[15:40] <brendand> cjwatson, is it just me or is click buildsource pretty broken?
[15:41] <brendand> cjwatson, i get varying exceptions, depending on what i try
=== semiosis is now known as semiosis_
=== Ursinha is now known as Ursinha-afk
=== roadmr is now known as roadmr_afk
=== timrc is now known as timrc-afk
=== timrc-afk is now known as timrc
=== alexisb is now known as alexisb_lunch
=== roadmr_afk is now known as roadmr
=== pbn_ is now known as pbn
=== SpamapS_ is now known as SpamapS
[20:28] <Noskcaj> jdstrand, Could you merge telepathy-mission-control-5 sometime soon? The new debian release stops the use of upower
=== dunkel2_ is now known as dunkel2
=== semiosis_ is now known as semiosis
=== Ursinha-afk is now known as Ursinha
=== alexisb_lunch is now known as alexisb
=== salem_ is now known as _salem