/srv/irclogs.ubuntu.com/2014/05/30/#ubuntu-devel.txt

=== timrc-afk is now known as timrc
siretartLogan_: thanks :-)00:24
Logan_for what? :P00:24
Logan_oh, my PM?00:25
siretartyes :)00:27
=== roadmr_afk is now known as roadmr
pfsmorigohi, 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.00:46
=== roadmr is now known as roadmr_afk
siretartinfinity: libav built everywhere now. I think we're good to start the transition01:40
=== roadmr_afk is now known as roadmr
alkisgHi, 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
alkisgthen gedit won't start until I disable the "zeitgeist gedit plugin"02:08
alkisgError message: ** (gedit:3187): CRITICAL **: zeitgeist_log_insert_event_no_reply: assertion 'self != NULL' failed02:08
alkisgShould I file a bug in upstream gedit to have the gedit zeitgeist plugin not crash gedit when zeitgeist isn't installed,02:08
alkisgor file a bug against debian/ubuntu to depend on zeitgeist, and not just its library?02:08
siretartalkisg: the former sounds appropriate in any case02:18
alkisgsiretart: 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
alkisgAh02:18
alkisgReally sorry, misread02:19
alkisgTrue, about the former, I was mostly asking if it's ubuntu specific or not02:19
alkisgIf it's not ubuntu specific, then a bug should be filed, of course...02:19
alkisgHmmm, 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:23
alkisgorg.gnome.gedit.gschema.xml on the other hand says: <default>['docinfo', 'modelines', 'filebrowser', 'spell', 'time']</default>02:28
alkisgSo 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...02:29
=== salem_ is now known as _salem
Logan_why isn't texlive-bin automatically syncing from unstable?04:38
=== timrc is now known as timrc-afk
NoskcajHow can i force dput to include a .orig file? MY ppa uploads are being rejected because the .orig isn't able to be found06:06
=== Ursinha-afk is now known as Ursinha
rsalvetipitti: ogra_: quite a few new error messages today when booting the emulator: http://paste.ubuntu.com/7549208/, not sure yet what caused that06:06
=== tedg is now known as ted
rsalvetiprobably in any touch image06:06
ogra_rsalveti, likely systemd transition fallout06:07
ogra_http://people.canonical.com/~ogra/touch-image-stats/54.changes .... cgmanager, systemd/udev and sysvinit changed06:08
Unit193Noskcaj: -S -sa06:14
Noskcajthanks06:14
Unit193-sa            uploaded source always includes orig.06:14
=== ted is now known as tedg
ogra_rsalveti, at least my flo still boots after upgrade ... phew06:16
rsalvetihaha, yeah, emulator booted fine as well, but with some additional error messages06:17
ogra_you shocked me for a moment :P06:18
xnoxrsalveti: mostly harmless, temporary until a reliable solution is available to re-enable parallel boot/shutdown again.06:28
rsalvetixnox: alright :-)06:33
pittirsalveti: yes, known; I'll file a bug about this now, we couldn't fix it yesterday06:40
rsalvetipitti: thanks06:45
pittiRAOF: did you see that colord is depwait on argyll?06:48
Noskcajrsalveti, 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 it06:49
RAOFpitti: In Ubuntu? Yeah.06:49
RAOFpitti: I'll need to disable that bit for Ubuntu.06:49
pittiRAOF: hm, conditional build deps sound tricky06:50
Noskcajpitti, Do i need to do anything to make python-dbusmock build for upower 0.99?06:50
RAOFpitti: Actually, no; it only generates extra files to ship alongside existing ones in colord-data06:51
pittiNoskcaj, rsalveti: that souds like fallout from the platform-api API change of returning floats in out args instead of return vallues06:51
pittiNoskcaj, rsalveti: (as float returns are weird on arm with Android, it's using a differetn calling convention)06:51
Noskcajum...06:51
NoskcajI think i'll leave that till last then06:52
pittiNoskcaj: in principle not; the test suite calls upower --version and based on that decides whether to expect/emulate the 0.9 or 1.0 API06:52
pittiNoskcaj: I tested it against upower 0.99 back then; so unless the API changed again in 1.0 it sohuld still work06:52
Noskcaj1.0 isn't out yet, just making a ppa to help (at the request of ubuntu-gnome)06:52
infinityxnox: procps is in the buildd chroots because initscripts (and its deps) is, because initscripts should be essential, except we screwed up. :P07:04
ogra_infinity, enough that we cant make the touch images writable anymore :P07:04
ogra_which breaks pretty much all testing in the lab07:05
infinityogra_: Hrm?07:05
ogra_infinity, mountall remounts the fs readonly since today ... regardless if it is supposed not to07:05
infinityxnox: procps is neither essential or build-essential, though, if that was what you were asking in a roundabout way.07:05
infinityogra_: 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 yesterday07:06
ogra_infinity, "except we screwed up" ... i was referring to that part of the line ;)07:06
xnoxinfinity: 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:06
infinityogra_: Totally unrelated screw up.07:07
xnoxinfinity: 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
Noskcajpitti, https://launchpadlibrarian.net/176602234/buildlog_ubuntu-utopic-i386.python-dbusmock_0.10.1-1ppa1_FAILEDTOBUILD.txt.gz07:08
pittiNoskcaj: 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
Noskcajok07:09
pittithanks07:09
=== Ursinha is now known as Ursinha-afk
xnoxpitti: http://paste.ubuntu.com/7549587/ of which 'rc' is false possitive, 'udev-finish' is fixed, 6 - to go.07:21
xnoxpitti: or we can do a startpar patch to consider tasks as always done and ready.07:21
pittixnox: oh, that looks manageable07:23
pittixnox: I'd prefer a solution in upstart to track whether a task ever ran, but we need something today to unbreak the phone builds07:23
pittixnox: ogra says they are completely broken07:24
xnoxpitti: well, i have this solution -> (let me pastebinit)07:24
xnoxpitti: http://paste.ubuntu.com/7549610/07:25
pittixnox: WEXITSTATU"S" -- and erk system() :)07:26
xnoxpitti: =) didn't compile yet07:27
xnoxpitti: in that code, it does 'initctl status' but it should also check for 'not a task'07:27
xnoxpitti: 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:28
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
pittixnox: so this will basically assume that upstart is always fast enough to execute task dependencies before startpar gets to it?07:29
=== Ursinha-afk is now known as Ursinha
xnoxpitti: 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:31
xnoxpitti: (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
pittixnox: so yes, even if it might not be entirely correct it still sounds like progress over the current situation07:32
pittixnox, ogra_: let me try what happens if we empty out all the affected init.d scripts07:33
ogra_++07:33
xnoxpitti: one simply shouldn't call update-rc.d on them, or we fix startpar/sysv and test&land it.07:40
xnoxogra_: when is the next image build?07:40
ogra_xnox, when we have a fix ;)07:40
xnoxogra_: ack07:44
pittiogra_: just to avoid panic for everyone who reads u-phone@: that's got nothing to do with systemd :)07:45
ogra_pitti, it doesnt ?07:46
pittiogra_: no, that's about catching up with Debian's sysvinit/insserv/upstart policy07:46
ogra_pitti, and thats not part of the systemd transition ?07:47
pittiogra_: it's a pre-pre-pre-requisite, but something which we have to do anyway07:47
ogra_right, indeed :)07:47
pittinon-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 ourselves07:47
pittiogra_: the fun thing is that none of this is a problem when you actually do boot with systemd :)07:49
pittiogra_: but anyway, be assured that we won't switch the phone to systemd anytime soon07:49
ogra_pitti, yeah, i annoyed slangasek enough with this question this week already ;)07:50
slangasekogra_: weren't you /in/ the UDS session where we decided this? ;)07:52
ogra_slangasek, heh, yeah, i guess :)07:52
ogra_pitti, sent a followup mail to clearify a bit07:53
pittiogra_: this seems to help quite a bit:07:57
pittifor 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; done07:57
pittiogra_: 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 builds07:57
pittiogra_: this essentially disables the init.d scripts which now get called although they shouldn't07:57
pittibut touching conffiles and stuff07:57
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
pittiogra_: that'll break updare-rc.d, so any package you try to install will cause failures from insserv07:58
pittiogra_: right, hence my proposal to change them to /bin/true07:58
pittixnox: inline comments in MPs!08:01
slangasekI realize this is a quickfix, but that sounds really horrible08:02
ogra_pitti, works fine ...08:02
ogra_slangasek, we wont promote any image before a reaal fix lands ... thats just to get developers usable development systesm again08:03
pittislangasek: yes, I never want that to get near any .deb, just as a post-install fix in image builds08:03
ogra_*systems08:03
pittislangasek: I'm reviewing xnox' MP now, but I have a feeling we won't land that in an hour08:03
slangasekpitti: 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 upstart08:03
ogra_i'll stuff it in a live-build hook script08:03
pittislangasek: they aren't; the LSB hook only helps for "sudo /etc/init.d/..."08:03
pittislangasek: but rc/upstart call them as /etc/rc?.d/Snnfoo, which isn't being recognized by the hook08:04
slangasekum08:04
slangasekthen that lsb hook is broken and does not do what I understood it was meant to do08:04
pittislangasek: initially I thought that was a bug, but xnox convinced me it's on purpose08:04
xnoxslangasek: 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
slangasekxnox: except our insserv transition also relied on this lsb hook providing us cover08:04
pittislangasek: 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 that08:04
slangasekxnox: for the window between running update-rc.d for the do-not-run init script, and converting to insserv08:05
slangaseksince that's the order it has to happen in08:05
slangaseksorry, I assumed that this is what the lsb init hook was doing08:05
pittiyes, so was I08:05
slangasek(despite having read the code earlier, I forgot it didn't)08:05
pittislangasek: and I still think we should do that somehow; if not through the LSB hook then at least some moral equivalent08:06
slangasekit should just be in the LSB hook, we shouldn't add even more moving pats08:06
slangasekparts08:06
xnoxslangasek: what do you think about the patch against sysvinit to consider task jobs as done?08:06
xnoxwell starpar component.08:06
pittislangasek, 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 job08:07
slangasekxnox: 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
slangasekxnox: i.e., pitti said you convinced him it's "on purpose"08:07
slangasekxnox: startpar patch> well I hope you aren't expecting me to tell you it's beautiful ;)08:08
xnoxslangasek: calling via /etc/rc* -> can & should be no-ops. calling via /etc/init.d* -> should do what the user asked to do08:08
slangasekxnox: 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
jpdsNoskcaj: Probably.08:08
jpdsNoskcaj: Feel free to update it, otherwise I'll look into it later.08:09
xnoxslangasek: hahaha. Let me read more about the timeouts.08:09
slangasekxnox: ok.  In that case, you agree that the lsb hook should be fixed for this?08:09
Noskcajjpds, I don't really understand the change, i'm just hoping it fixes the ftbfs. I'll leave it for you08:09
xnoxslangasek: yes. As in, init.d behaviour stays the same (call the real action), rc*.d/[SK]\d* -> is a no-op.08:10
jpdsNoskcaj: Oh, that's good to know, thanks.08:12
ogra_cjwatson, mind takeing a quick look at http://paste.ubuntu.com/7549809/ ?08:13
ogra_-e08:13
slangasekxnox: ok.  Can you put that together and I'll review?  And is that sufficient to unbreak the phone image?08:14
ogra_slangasek, xnox, so should i hld back the above hack ?08:15
ogra_*hold08:15
xnoxslangasek: let me confirm both of those.08:15
slangasekogra_: I estimate 1.5h before we can land this (proper) fix08:16
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
pittixnox, slangasek: added a blurb to the MP08:19
ogra_sil2100, thoughts ? ^^08:19
pittixnox: calling via /etc/rc* -> can & should be no-ops. calling via /etc/init.d* -> should do what the user asked to do08:20
sil2100ogra_: let me think08:20
pittixnox: so the LSB hook is behaving exactly opposite now08:20
plarssil2100: 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 it08:21
ogra_plars, we cant really fix people that already upgraded ... going forward with a fixed image fast would be better08:21
pittixnox: 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:21
pittislangasek, xnox: I'll re-try with adding the missing readlink to the LSB hook; it hung yesteday08:22
slangasekpitti: we shouldn't drive execution of the upstart job, at boot time, from startpar08:22
slangasek(or from rc)08:22
sil2100ogra_, plars: I wouldn't worry about it that much, as people should be aware of that devel images can be broken by principle08:22
pittislangasek: yes, fully agreed08:23
ogra_proposed you mean :)08:23
slangasekit's better to skip it entirely in this case than to risk running two copies of a daemon, or worse08:23
sil2100ogra_: I must say that I'm not particulary fond of landing a quick-fix to gain like only 1.5h08:23
sil2100ogra_: right ;) Typo08:23
sil2100(big one)08:23
pittislangasek: 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.5h08:23
pittislangasek: and keep startpar disabled for now (as in current utopic)08:23
sil2100ogra_: let's meet on the landing meeting and talk about it then08:23
pittislangasek: that should essentially do what we always did08:24
sil2100It's like in 7 minutes08:24
cjwatsonogra_: err, what.  is it really quicker to do this madness than to fix the init scripts in question?08:24
sil2100ogra_: how does your workaround fix look like?08:24
slangasekcjwatson: the init scripts aren't "broken"08:24
cjwatsonthis is out of the blue for me08:24
pittithe 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 problem08:24
slangasekcjwatson: we reintroduced the init scripts, relying on the lsb init-functions hook to make them all no-ops08:24
pittihence my proposal to keep startpar disabled until we fix that properly08:25
slangasek(or pass-throughs)08:25
pittican we meet in person somewhere?08:25
slangasekpitti: people have been looking for you and not finding ;)08:25
pittiballroom08:25
pittiI can come someplace else08:25
pittiwhere are you?08:25
slangasekwe're in studio 3, but xnox just went again looking for you; let's come there08:25
pittiack, on my way08:27
slangasekpitti: no, we'll come to you08:27
pittiack08:28
xnoxpitti: i'm in studio 3.... where abouts are you?08:29
* xnox is also attached to a power socket at the moment.08:30
slangasekxnox: can you come to the ballroom?08:41
xnoxslangasek: yes08:42
pittixnox: ballroom08:44
slangasekpitti: he's here08:44
pittixnox: I'm testing an LSB hook update, then we can compare ideas08:45
xnoxpitti: oh. ok.08:46
sarnoldpitti,xnox: 1322296 init.d file for procps08:54
pittisarnold: hm, procps already has an init. script?08:56
ogra_xnox, FYI i uploaded the livecd-rootfs hack right now so take your time, will be enough if it lands today and without hurry08:57
infinitypitti: The log in the bug report shows it was with the broken procps that was removed from proposed.08:57
sarnoldpitti: 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:57
sarnolddid 4 make it to -release or was it only ever in -proposed?08:58
infinitysarnold: Only proposed, AFAIK from backscroll.08:58
infinityA fresh upload to supersede it should probably still be done, if the thing that broke it is no longer broken.08:59
infinityOh, the thing that broke it was xnox. :P09:00
sarnoldlol09:00
pittiinfinity: not necessary any more09:08
pittiit's really wrong to un-task all our upstart tasks09:08
xnoxogra_: please no.09:17
ogra_xnox, no what ?09:17
xnoxogra_: uploading livecd-rootfs.09:18
xnoxpitti: http://paste.ubuntu.com/7550129/09:18
ogra_xnox, already happened ... (and agreed on by all involved parties)09:18
xnoxogra_: slangasek, pitti and myself?!09:18
xnoxogra_: and cdimage team?09:18
xnoxogra_: please stop ignoring !landing09:19
ogra_xnox, yes09:19
pittiogra_: yeah, I thought you had a way to modify the images that doesn't involve uploads; but *shrug* that's ok for now09:19
pittionce the the fixed lsb lands we can take out that hack again09:19
ogra_xnox, colin and steve were in the landing team meeting09:19
ogra_where we decided that09:19
xnoxogra_: cool.09:19
pittiit's really moot to discuss that now..09:19
ogra_xnox, i'll revert it immediately if your fix is in ... no worries09:19
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 decision09:20
RAOFinfinity: Are you around anywhere?09:20
pittixnox: http://paste.ubuntu.com/7550154/09:23
slangasekxnox: 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:23
infinityRAOF: Not really.  I seem to be broken, and am therefor hiding in my room.09:24
RAOFinfinity: Sorry to hear that.09:24
xnoxev: yes, my merge proposal has inline comment.09:47
pittiogra_, slangasek: FYI, this will fix the phone without the crazy livefs-build hack: https://launchpad.net/ubuntu/+source/lsb/4.1+Debian11ubuntu809:54
pittiI'll also do a sysvinit upload to remove some noise, but that's mostly cosmetical09:54
pittisil2100: you want that for the next image build: https://launchpad.net/ubuntu/+source/lsb/4.1+Debian11ubuntu810:02
pittisil2100: and if you so please, we can revert the temporary hack from https://launchpad.net/ubuntu/+source/livecd-rootfs/2.21510:03
infinitypitti, xnox: I might nitpick that that now runs "initctl version" twice for no good reason sometimes.10:03
pittiinfinity: when?10:04
infinitypitti: Oh, wait, no, I guess not.10:04
pittiit sucks enough that we have to call it for every init.d script already10:04
infinitypitti: I didn't read the tests right.10:04
infinitypitti: So, it's just ugly code duplication, but not actually running twice.10:04
pittiwishlist: provide a test for "am I running upstart" which just involves a stat10:04
pittithat'll go away again once we made startpar friends with upstart tasks, but that still seems to be disputed, and not trivial to do10:05
sil2100pitti: thanks for the info!10:05
pittisil2100: yw; what a mess :/10:05
slangasekpitti: 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 startpar10:07
slangasek(which we should enable soon)10:07
pittislangasek: yes, agreed10:08
pittislangasek: until then it shouldn't matter that much whether we use startpar or not, but like that we'll probably see some boot time regression10:09
pittibut for enabling startpar we'll have to adjust upstart (unless anyone has a better idea?)10:09
pittior 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:10
slangasekpitti: I'd like to understand why we have as many task jobs as claimed that are also init scripts10:12
pittislangasek: 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 many10:13
pittislangasek: certainly 10 or less10:13
slangasekright - most tasks should not have corresponding init scripts10:14
pittithe problem is not that, but init.d scripts which *depend* on an upstart task10:14
slangasekyes10:15
slangasekwell, both are problems10:15
slangasekbecause *any* init scripts shadowed by tasks would result in startpar waiting forever10:15
slangasek(the procps problem)10:15
slangasekinit.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 package10:16
slangasekbecause this affects shutdown too, not just startup10:16
pittislangasek: i. e. what we started with http://launchpadlibrarian.net/176539305/systemd_204-10ubuntu7_204-10ubuntu8.diff.gz ?10:16
pittislangasek: 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:17
slangasekpitti: 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 interaction10:18
pittislangasek: ok; WFM10:18
xnoxslangasek: we can reorganise our jobs, but 3rd parties that ship both init.d script and upstart task can doom boot & shutdown still.10:18
slangasekpitti: and as for third-party jobs, I mentioned to xnox this morning that properly supporting startpar's timeout functionality for these jobs would handle that10:18
xnoxslangasek: right.10:19
xnoxslangasek: 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
xnoxbut maybe i'm wrong.10:19
slangasektask+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
slangasekxnox: ah10:19
pittistgraber: 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 chroot10:24
BluesKaj'Morning10:24
pittior cjwatson ^10:24
xnoxpitti: nut is failing... http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb10:25
* xnox check if it has a hint.10:25
pittixnox: yes, bug 1291378, retried10:25
ubottubug 1291378 in nut (Ubuntu) "test_CVE_2012_2944 autopkgtest is racy" [High,Confirmed] https://launchpad.net/bugs/129137810:25
pittithat's the one I always have to retry umpteen times10:25
pittiI hope it's just a bad test, not a bad vuln fix10:25
infinitypitti: Hinted.10:27
stgraberinfinity: gah, you're too fast :)10:27
* stgraber goes for some food instead10:27
=== Ursinha is now known as Ursinha-afk
infinitypitti: 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
infinitypitti: It looks like amd64/i386 are done, but the job still seems to be "running".11:08
infinitypitti: And, odder still, there's a reference to a ppc64el host in the corner?11:09
ogra_xnox, how is the migration looking ?11:21
xnoxogra_: migrated 41 minutes ago.11:25
ogra_perfect !11:25
ogra_let me revert the hack then11:25
* xnox feels like personal service rmadison =)11:25
=== Ursinha-afk is now known as Ursinha
=== tedg is now known as ted
=== ted is now known as tedg
xnoxsergiusens: cjwatson: rsalveti: bug #132488911:44
ubottubug 1324889 in click (Ubuntu) "click chroot should use -gles qt packages in the i386 chroot" [Undecided,New] https://launchpad.net/bugs/132488911:44
sergiusensthanks11:44
rsalvetixnox: thanks11:45
xnoxsergiusens: checked the code, it installs the stock variant only, which is gl on i386 =(11:45
xnoxtedg: https://code.launchpad.net/~jamesodhunt/upstart/cgroups-mergeable-with-upstart-async11:51
=== _salem is now known as salem_
pittiinfinity: 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
pittiinfinity: thanks for hinting12:00
Chipacahttps://wiki.ubuntu.com/Chipaca/PPU \o/12:06
Chipacasergiusens: are you an ubuntu dev?12:06
xnoxstgraber: are you in the unified mobile & desktop session now?12:06
sergiusensChipaca: no; I'm not; just a ppu12:06
xnoxstgraber: room 3, questions about lxc are raised...12:06
Chipacasergiusens: so not that much point in you endorsing my ppu, i guess12:07
Chipacahmmm. dobey? ev?12:08
stgraberxnox: ok, I'll come then12:11
infinitysiretart: 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
infinitysiretart: s/bug/patch/12:26
=== salem_ is now known as _salem
xnoxsergiusens: 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
xnoxi have a few options now.12:39
sergiusensxnox: let's do that now12:39
sergiusensxnox: where can I find you?12:39
xnoxi am outside studio 3 now.12:39
xnoxsergiusens: you?12:39
sergiusensI'll go there12:39
dobeymvo: what is the path for the file i need to change for packagekit?12:40
mvodobey: /etc/PackageKit/PackageKit.conf12:42
dobeyi don't have that. is it not from a default-installed package?12:43
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
pittibdmurray: apport 2.14.3 uploaded13:36
xnoxSaviq: hey, you about?!13:39
xnoxSaviq: looking at cgo and i would want to try a few things with you.13:39
xnoxSaviq: i think it's trivial to enable it crosscompilation.13:39
=== 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_
goarillaanyone here that navigated the ubuntu gfxboot inc configuration files ?13:51
=== salem_ is now known as _salem
goarillahow to I disable the F1,F2,F3 buttons and language overlay ?13:55
goarillaI have gfxboot-theme-ubuntu unpacked13:55
=== timrc-afk is now known as timrc
=== _salem is now known as salem_
brendandcjwatson, is it just me or is click buildsource pretty broken?15:40
brendandcjwatson, i get varying exceptions, depending on what i try15:41
=== 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
Noskcajjdstrand, Could you merge telepathy-mission-control-5 sometime soon? The new debian release stops the use of upower20:28
=== 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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!