=== psivaa_ is now known as psivaa === Trevinho_ is now known as Trevinho === czchen_ is now known as czchen === Guest97591 is now known as Guest20083 === FourDollars_ is now known as FourDollars === broder_ is now known as broder === wdean_ is now known as wdean === psivaa_ is now known as psivaa === Guest20083 is now known as Ursinha === pjdc_ is now known as pjdc === Guest90815 is now known as rcj === timrc is now known as timrc-afk === ttx` is now known as ttx === tvoss__ is now known as tvoss [06:53] good morning === Adri2000_ is now known as Adri2000 === wgrant_ is now known as wgrant === dendroba` is now known as dendrobates === bigon_ is now known as bigon [07:49] dholbach, hi, do you think you can sync lucene++ [07:49] no rdeps, bugfix only, and should fix two ubuntu bugs [07:50] there are spurious build failures with the old release, I never had them in debian with the new one, and I remember I might have fixed some packaging bugs, together with sil2100 [07:52] LocutusOfBorg1, "1285 files changed, 128753 insertions(+), 144491 deletions(-)" [07:52] it's a bit hard for me to see what was changed [07:52] it'd be good if somebody could take a look and maybe come up with a changelog or something and have a chat with the release team [07:52] It's mostly LocutusOfBorg1 great job, since I'm so busy with other stuff that I was not really much of a help... [07:52] we're just a week away from release [07:52] :< [07:54] some files seem to have a lot of whitespace changes in them [07:54] but it's a hard for me to find out what exactly changed [07:55] maybe you can file a bug about it and explain what changed [07:56] mmm there was a rdep, but it has been removed, so actually no programs should use it [07:56] but maybe we can sync after utopic release [07:58] BTW can you please remove boinc-app-milkyway? the version is too old to be useful [07:58] and I cannot upload the new one because of nvidia license [07:58] so please let it go :) [07:59] can you file a bug about it and subscribe ubuntu-archive? [08:00] it'd be good if there's some explanation why it can be dropped [08:01] bug 1381384 [08:01] bug 1381384 in boinc-app-milkyway (Ubuntu) "please remove milkyway from archive [RoM]" [Undecided,New] https://launchpad.net/bugs/1381384 [08:01] I quoted the debian bug [08:02] great, thanks [08:09] thanks to you :) [08:12] pitti, hey, any idea if -dbgsyms from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-006/+sourcepub/4473892/+listing-archive-extra are available somewhere? [08:12] Saviq: they should be in http://ddebs.ubuntu.com/ubuntu-rtm/queue/ [08:12] pitti, indeed, awesome, thanks! [08:22] tvoss, this is gaining severity by the minute bug #1380736 [08:22] bug 1380736 in unity8 (Ubuntu) "Unlocking sim while dash is not loaded leads to a system lockup" [Critical,New] https://launchpad.net/bugs/1380736 [08:23] tvoss, could you have a look please, dbus-cpp and media-hub involved [08:23] Saviq, sure [08:23] Wellark even has some suspects there [08:23] tvoss, if you need, got the coredump here [08:24] Saviq, ack, got it [08:25] Saviq: morning! [08:25] Wellark, heyo [08:26] Saviq, Wellark why is media-hub involved here? did somebody look at dbus traffic? [08:27] Saviq, Wellark so this only happens if the wizard has been run? [08:27] tvoss: I looked at the stacktrace and the involved libraries [08:27] Wellark, sure, that might be misleading here, though [08:27] tvoss: I suspect it's qtubuntu-media [08:28] tvoss, no, it just happened to me on boot when unlocking the SIM cards [08:28] I just slammed media-hub there before I found out about qtubuntu-media [08:28] tvoss: but, [08:28] Saviq, did we investigate in this direction: https://bugs.launchpad.net/indicator-network/+bug/1380736/comments/4 [08:28] Ubuntu bug 1380736 in unity8 (Ubuntu) "Unlocking sim while dash is not loaded leads to a system lockup" [Critical,New] [08:29] tvoss, unrelated, it just makes it easier to reproduce, probably due to high CPU load by dash [08:29] tvoss, for me it happened regardless of what the dash was doing [08:29] tvoss: actually there might be two issues.. the errors.u.c. report that mterry posted seems like the one you get when you forget to disconect() [08:29] Wellark, did you try removing the audio source in unity8? [08:30] but [08:30] the one that I posted [08:30] Wellark, a crash is somewhat fine, but why would everything hang? [08:30] seems like a uncaught exception [08:30] tvoss, no no [08:30] tvoss, it's a crash [08:30] tvoss: it's crashihng unity8 [08:30] and as apport runs [08:30] tvoss, "hang" is just apport collecting the core [08:30] it's seems that the system is hanged [08:31] which takes up to a minute [08:31] Saviq, ah okay [08:32] Wellark, did you try making sure that the respective signal is disconnected? [08:32] Saviq, is it an abort or a segfault? I would expect a segfault [08:33] tvoss: I just looked at the code last night at 3.30am as I didn't have anything better to do [08:33] Wellark, ack, I will look at it [08:33] tvoss, segv [08:33] :) [08:33] Saviq, ack, that makes sens [08:33] e [08:33] Saviq, could it be that the audio source is destroyed/reinitalized somewhere? [08:33] tvoss, it definitely is destroyed [08:34] Saviq, ack, then that's the likely issue here [08:34] let me see [08:34] Saviq, cross-check: channel is rtm, correct? [08:34] tvoss, it happens when the SIM unlock dialog (ugh.. notification) is being destroyed, and it does have Audio { } in there [08:34] tvoss, either [08:34] Saviq, ack [08:34] tvoss, at least yesterday it was either, this morning I repro'd in rtm yes [08:35] Saviq, branching qtubuntu-media and trying a fix [08:35] Saviq, Wellark do we have a silo for the bug, yet? [08:35] tvoss, no [08:36] Saviq, ack, let me request one [08:36] tvoss: thanks! [09:05] jodh, can you merge my branch then? [09:26] dholbach: done, thanks. [09:28] jodh, package uploaded, should be sitting in the queue now. [09:28] dholbach: thanks again! [09:28] tvoss, on another topic, I've been unable to get a location on my phone for a while now when dogfooding [09:28] Saviq, sorry, can we please postpone that until I have this fix mp'd? [09:28] tvoss, let me know if you have some time to try and debug why [09:29] tvoss, ↑ [09:29] s/if/if\/when/ [09:29] Saviq, ack [09:34] Saviq, Wellark https://code.launchpad.net/~thomas-voss/qtubuntu-media/fix-races-for-access-to-destroyed-controls/+merge/238404 [09:38] tvoss, thanks [09:38] Saviq, requesting silo right now [09:38] now if only launchpad would show the diff :) [09:50] can you fix imminently? :-) [09:52] yes [09:52] rocking [09:52] jodh, Laney, bdrung_work: I commented on the MP [09:54] dholbach, bdrung_work: if that date is correct, could we also update http://en.wikipedia.org/wiki/List_of_Ubuntu_releases#Ubuntu_14.10_.28Utopic_Unicorn.29 to match? [09:55] bdrung_work: do you want me to change the MP or are you going to jfdi? [09:55] jodh, I don't understand [09:56] stgraber: oh, I just found out why I was getting an EPERM trying to remove /var/cache/lxc/utopic/rootfs-amd64 -- it's a separate btrfs subvolume [09:56] stgraber: OOI, why is this done? [09:56] dholbach: sorry, that wikipedia link was meant to link to the 'Table of versions' entry for utopic that currently just shows "2015-07". [09:58] stgraber: is that more efficient wrt. mounting in the container? [09:58] hum [09:58] sorry [09:59] let me doublecheck [09:59] yes, AFAICS this should be correct: [09:59] 14.10,Utopic Unicorn,utopic,2014-04-17,2014-10-23,2015-07-23 [10:00] ^ can somebody doublecheck? [10:00] it matches https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule + the usual 9 months of support [10:02] Laney, dholbach: just uploaded distro-info-data 0.22 to unstable. please sync it once it's there [10:03] ty [10:03] and here is the change: http://anonscm.debian.org/cgit/collab-maint/distro-info-data.git/commit/?id=aaad145d76739cfa41c53cf26265fb6bcaa574ee [10:04] thanks bdrung_work [10:04] LGTM [10:06] bdrung_work: thanks. [10:07] you're welcome [10:23] doko_: so I have a fix ready to upload for the FTBFS for armhf in your rebuild test. Only I just want to do a final test before uploading and realised that a newer version has been stuck in utopic-proposed all along. [10:23] And this version additionally fails on powerpc. [10:23] pitti: it's so containers can be created with a simple subvolume snapshot rather than rync the whole thing [10:23] Fixing armhf needed hand-examination of the arm assembly output. If powerpc needs to do the same, I'm not capable of doing it quickly as I don't know powerpc assembly. [10:24] Can we keep the version the same as in utopic (not utopic-proposed), but with my cherry-picks to fix armhf? Then we'll have something in the archive that doesn't FTBFS on all architectures. [10:25] But I think this would need a 0.4.4-1really0.4.2.1ubuntu1 version number of something. [10:25] rbasak, yep, sound good. did you test your version on porter-powerpc? [10:25] No. I can do that. I only touched armhf-specific code. === doko_ is now known as doko [10:27] doko: does 0.4.4-1really0.4.2.1ubuntu1 sound appropriate to you? I don't know what we do about the second hyphen there, so I changed it to a dot. [10:29] I would use as the upstream part: 0.4.4really0.4.2 and then -0ubuntu1 [10:29] That sounds better - thanks. [10:31] Ah - and that way I don't get a confused upstream tarball. My wouldn't work. [10:32] stgraber: ah, nice [10:38] rbasak: You don't need a really version here [10:38] rbasak: It sounds like we can remove the package from utopic-proposed and then you can go backwards (which is OK since utopic-proposed isn't expected to have widespread apt clients using it) [10:38] rbasak: What package is this? [10:39] cjwatson: python-greenlet [10:39] I didn't realise that was acceptable. If you're happy to delete from utopic-proposed, then yes please. [10:39] I think it's nicer than a really version, yeah [10:40] OK [10:40] I'll prepare a 0.4.2-1build1ubuntu1 [10:40] Or, 0.4.2-1ubuntu1? [10:40] yes [10:40] I guess that's higher. [10:41] The latter [10:41] ack [10:41] Presumably any future version of 0.4.4 would need to be patched to include your change, rather than resurrecting 0.4.4 [10:41] er resurrecting 0.4.4-1 [10:42] Yes. My change has already been accepted upstream. The Debian maintainer asked upstream for a new release to incorporate my fixes. [10:42] rbasak: nuked, you can upload [10:42] Thank you! [10:42] * rbasak build tests on armhf and powerpc first. [10:50] Uploaded. === pete-woods is now known as pete-woods-lunch [11:38] Oh great. It failed on amd64 :-/ [11:44] Someone hit the retry button? It succeeds locally. [11:44] As in, did someone hit the retry button? I was just about to do it. [11:44] I did [11:44] Thanks [11:44] I don't understand the failure. I makes no sense to me. [11:45] It [11:46] greenlet seems to have turned into a bit of a nemesis for me. I refuse to let it defeat me :) [11:48] \o/ === MacSlow is now known as MacSlow|lunch [12:10] jodh, just saw your mail ... i think you should talk to stgraber aboout the "writagble-image" options (i dont know what sync actually does, never used it) [12:11] ogra_: ack, thanks. === _salem is now known as salem_ [12:12] (and i guess yu guys can easily talk in person this week ;) ) [12:14] ogra_: nope, jodh isn't at Plumbers [12:14] and I'm rarely online [12:16] oh === timrc-afk is now known as timrc [12:26] dbarth: long time not seen / talked / chatted. [12:27] * sunweaver is Mike Gabriel from upstream X2Go and also now a DD packaging MATE for Debian. [12:27] I plan to bring my work power to the Ubuntu MATE team and need Ubuntu Developers that maybe would like to write an endorsement statement under my application. [12:27] At least you have seen a bit of my work, even if some time ago. [12:28] dbarth: here is the application page anyway: https://wiki.ubuntu.com/MikeGabriel/DeveloperApplication === pete-woods-lunch is now known as pete-woods [12:29] dbarth: maybe you find some time and are willing to add a statement... [12:29] THANKS! [12:35] sunweaver: o/ will take a look later (deep inside a debug session w/mardy right now) [12:35] dbarth: o/ THANKS! === Sweetsha1k is now known as Sweeshark === Sweeshark is now known as Sweetshark === MacSlow|lunch is now known as MacSlow [12:49] tseliot, there are some MIR's missing for your last nvidia-graphics-drivers-304 upload [12:50] doko: MIRs? [12:51] tseliot, https://wiki.ubuntu.com/MainInclusionProcess [12:51] for ocl-icd and khronos-opencl-headers [12:51] and bumblebee [12:52] doko: I don't recall requesting that [12:52] not bumblebee, at least, only bbswitch [12:52] also, do you have a relevant bug report? [12:53] tseliot, the nvidia-graphics-drivers-304 and nvidia-graphics-drivers-331 packages do that. [12:53] tseliot, no, *you* are required to file this bug report with the MIR information [12:53] let me check the packaging [12:57] doko: maybe the problem with nvidia-graphics-drivers-304 is that nvidia-opencl-icd-304 depends on ocl-icd-libopencl1 | nvidia-libopencl1-304, and ocl-icd-libopencl1 is in universe [12:58] it should be the same for nvidia-graphics-drivers-331 [12:59] tseliot, ahh, nvidia-331 recommends nvidia-prime (>= 0.5) | bumblebee, which is correct, and the component-mismatch wrong [12:59] doko: yep [13:02] doko: do you think I should still file a MIR for the opencl stuff, even though it's just an alternative dependency? [13:03] do you want opencl? :P [13:11] tseliot, why isn't nvidia-libopencl1-304 listed as the first alternative? [13:14] doko: they are interchangeable, and it's best to build against the open one (to avoid missing symbols) [13:15] tseliot, well, then I assume we should have it in main? [13:16] doko: yes [13:16] tseliot, then please file the MIR issue [13:16] mlankhorst, I don't want it, but if it is required according to tseliot [13:17] doko: ok === dobey_ is now known as dobey [13:18] we'll also need it for fglrx in utopic+1 [13:20] pitti, i think i saw you were having an issue with a unity-settings-daemon crash ? is that right ? [13:20] i'm pretty much wrecked by it. launchpad seems unresponsive now, or i'd have a link. [13:20] smoser: yes, it and compiz were crashing every minute or so [13:21] yeah. :-( [13:21] smoser: larsu fixed in a branch yesterday; if you are on amd64 you can install the debs from http://people.canonical.com/~pitti/tmp/usd/ [13:21] (that's a straight build from his branch) [13:21] smoser: since then, not a single crash any more [13:21] I just accepted the fix [13:21] \o/ [13:21] after having the same crash happen to me a dozen of times today :) [13:22] am i the only one that can't load launcpad bugs ? [13:22] also, I'm a bit disappointed that the apport retracer didn't duplicate my 4-5 bugs to the right ones, took me a while to figure out exactly what was going on :) [13:22] pitti, smoser: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-008 [13:22] seb128, thank you. [13:22] pitti, better to recommend ^ so we get testers for the version we want to land [13:22] tvoss, asac, cjwatson, please have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt and tell me which of the packages in "Source and binary movements to universe" belong to the phablet, and maybe should be seeded [13:23] seb128: binaries are now also on https://launchpad.net/ubuntu/+source/unity-settings-daemon/14.04.0+14.10.20141014-0ubuntu1 [13:23] oh, upload got accepted [13:23] nice [13:23] lol [13:23] stgraber: oh? I tried to report it and I already got stopped on the client side due to the bug pattern [13:23] 3 minutes ago [13:23] pitti is on top of things ;-) [13:23] seb128: stgraber | I just accepted the fix [13:24] stgraber, pitti: thanks [13:24] it's the "ubuflu" for laptops [13:24] I never had that crash at home [13:24] and as soon as you walk to a conference your desktop gets effectivley wrecked [13:24] but yeah, a day with XFCE was illustrative :) [13:24] pitti: here it was letting me report it, grabbing the logs and then compiz was being ignored due to supposedly being out of date (my system was updated about 10s before the crash so that seems unlikely) and u-s-d was duped to aonther bug report which wasn't the same used for the u-s-d fix [13:25] stgraber, pitti: there are some variants of the bt I think, refcont issues leading to slightly different errors [13:26] ok [13:27] well, I guess someone will have to do some serious bug cleanup for u-s-d and compiz in the next few days to clear up all the related crashes :) [13:27] lol [13:28] I think people stopped fighting launchpad noise [13:29] pitti: btw, shouldn't we be flipping some kind of flag about now to get crashes to errors.u.c instead of uploaded to LP? [13:29] stgraber: ah yes, that shold be on the "release checklist" [13:29] pitti: also, are you in a session or are we both chatting from opposite side of the lobby or something? :) [13:29] stgraber: I'll upload apport, then the release team can accept at their convenience [13:29] ok, thanks [13:29] stgraber: I'm in room 2, for some comfy hacking [13:30] basically, last chance to get something done for 14.10 and also jessie [13:30] yeah, I guess infinity and I will go through the checklist on Friday and upload everything before we leave Düsseldorf [13:33] joy. i seem to be in a routing black hole to bugs.launchpad.net [13:37] doko: sure, if we need it then no choice :P [13:37] stgraber: apport uploaded for disabling LP crash reports [13:37] thanks [14:10] barry, you did it again ... system-image now pulling in pip via nose2 this time ... [14:14] doko: i uploaded nose2 over a month ago. why is that suddenly happening? [14:15] barry, it has (or got) a build dependency on tox [14:16] yeah, but there's been no new nose2 in a long time [14:21] wine and cheese get better with aging, not software [14:23] barry: I can't quite sort out why it seems to have popped up on reports today, but it was a known problem for months, wasn't it? [14:23] infinity: first i've heard of it [14:24] barry: Err, and no one uploaded nose2 "over a month ago", unless you count "over a year ago" as that. [14:25] infinity: oops, yeah i misread the year in the changelog ;) [14:25] Ahh, and that's what confused the reports. It was copied to main a month or so ago, then demoted to universe, which makes the reports say slightly different things. [14:26] infinity: it's not an explicit dependency (i.e. not in d/control) but it must be getting pulled in via requires/setup [14:26] barry: Anyhow, this is absolutely not the first you've heard of it, we had a discussion, at length, about system-image pulling in pip/venv. I remember, I was there. [14:26] infinity: that was a different issue. system-image had an explicit b-d on tox, which i fixed [14:27] barry: Ahh, but it now has an implicit one via nose2 having an explicit one. :) [14:27] infinity: vice versa :) it has an explicit b-d on nose2 which apparently has an implicit b-d on tox (it's not explicit in the d/control of nose2) [14:29] there's a new nose2 on pypi, which i can look at, although they conveniently forgot to update their changelog :( however, as i mentioned before, i still think it's a losing battle to keep tox out of main. but whatever, we can just keep whacking the moles one by one [14:29] infinity: so when's the archive reorg gonna land? :) [14:29] barry: Not before release. [14:30] infinity: c'mon dude, you have at least 12h before final freeze, how much time do you need? [14:31] * barry will shut up now [14:31] barry: Erm, implicit build-depends? How would that work? [14:32] infinity: actually, yeah, that makes no sense. let me investigate anyway [14:32] python-tox, [14:32] * barry was thinking implicit Depends [14:32] It's right there. [14:32] In d/control [14:33] ah shit, your right. i was looking at a different repo [14:33] well, let me see if i can get rid of that [14:35] * barry curses udd [14:40] *grumpf* bug #1381570 [14:40] bug 1381570 in util-linux (Ubuntu) "libuuid1 uses chsh in postinst which breaks upgrades" [Critical,In progress] https://launchpad.net/bugs/1381570 [14:40] lol, what ? [14:48] infinity, doko nose2_0.4.7-2ubuntu1 [14:50] barry: So, the build-dep wasn't actually necessary? [14:50] infinity: no [14:50] infinity: tests were never run at build time anyway [14:50] :/ [14:51] barry: Unfortunate, but at least not a regression. [14:51] ogra_: upgrade explodes in spectacular ways if libuuid has a login shell, I'm fixing it now [14:51] barry: Could the tests be turned into dep-8 tests, which don't have to have pocket consistency? [14:53] infinity: probably, but as i've said before, as tox becomes more prevalent, this will increase the pressure to delta from debian over time. this is a band-aid but not a long-term solution. [14:53] * mvo chuckles at version number 1:0.30.0~git20131003.d20b8d+really20110821-0.2ubuntu13 [14:53] barry: Well, the same "run them as dep-8 instead of build-time" solution is perfectly reasonable for Debian too. [14:54] barry: But perhaps we can revisit the pip/venv-in-main situation, just not this week. [14:54] infinity: right, but because debian doesn't have the same restriction, if a dd uploads a package that runs tox tests at build time, we will have to delta it if it's a main package. i don't think we can reasonably tell debian devs not to do that because ubuntu. [14:54] seb128: the error tracker retracing queues were reset yesterday [14:55] infinity: oh fer sher. let's do talk about it for vain vulture [14:55] barry: vindictive velociraptor. [14:56] infinity: anyway, please review, but i think in this case mole is whacked [14:56] infinity: much better :) [14:56] vulgar vole? [14:56] barry: Nothing to review, really. The delta is obvious (and it already built). [14:56] coolio [14:57] So, we'll see how this settles down component-mismatches once it publishes and migrates. [14:57] infinity: one other thing to think about... later. that c-m email notification is not super helpful. it doesn't mention the packages affected afaict [14:58] barry: The email is literally just the diff between the previous run and the current, it does no analysis. [14:59] barry: The svg is often the simplest analysis tool. [14:59] http://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:59] yeah. [14:59] barry: +1. The email doesn't tell me if I need to act, or if someone else will take care of it. Without investigating each individual email. So I look at the SVG like infinity says. But at that point, the email is just a notification to look at the SVG, and most of the time it doesn't affect me. [15:00] rbasak: and the email doesn't even include a link to the svg, so unless you already know where to look, it still isn't helpful ;) [15:00] pitti: Is that util-linux upload the same change that was made in Debian for that bug? [15:01] pitti: I feel like there was more to it, but I haven't been watching closely. We might actually want to try a merge and see how scary it is. [15:05] mvo: Oh, the above to pitti was meant to be for you. [15:06] infinity: yeah, the initial patch was too simple, I upload the debian version of it now [15:11] hallyn: I intend to approve this slof MIR, can we get a qemu upload where qemu-system-ppc recommends or depends on qemu-slof instead of suggesting it? [15:12] mterry, thanks for the MIR reviews.... [15:12] jamespage, yw! :) [15:18] jamespage, just saw https://launchpad.net/ubuntu/+source/tuskar/0.4.2-2 [15:18] doko, oh [15:19] doko, yeah more openstack sprawl [15:19] I'll look [15:19] doko, oh zigo epoched novaclient [15:19] * jamespage goes to see why [15:21] seb128: did you hear from mlankhorst about the i386 vm/llvm issue? [15:22] jamespage: Ghe Rivero added the first 1: when the version went from 2.6.7 to 2012, which IMO wasn't needed, then we moved to 2: when it went back to 2.x scheme ... [15:22] Laney: should be fixed I think :P we set a more sane cpu in the autopkgtest now [15:22] Laney, no [15:22] zigo, yeah that was quite a while ago now [15:23] Yup. [15:23] Laney, seems you get his attention though ;è) [15:23] mlankhorst: not that [15:23] ;-) [15:23] zigo, I'll tweak tuskar for ubuntu versions; we'll talk about epoch alignment next cycle [15:23] mlankhorst: How does "setting a more sane CPU" make it not a bug anymore? [15:24] mlankhorst: Not all i386 machines are as new as the one you're now emulating. [15:24] jamespage: So you need to fix tuskar's depends when importing it because of that epoc? [15:24] jamespage: FYI, I'm planning on removing Tuskar from Jessie when it gets frozen. [15:24] The current problem is that booting an i386 vm (with "qemu-system-i386 -enable-kvm -monitor stdio -m 1024 -cdrom utopic-desktop-i386.iso", for example) fails to bring up unity7 and logs have the same 'cannot split operator' message. [15:24] zigo, oh - not good then? [15:24] jamespage: As well as all TripleO stuff, Designate and probably more. [15:24] I might just request it removed [15:25] jamespage: I don't think it's production ready, and I'm sure I wont get upstream support for long enough. [15:25] jamespage: Yeah, just ask it to get removed. [15:25] jamespage: Oh, and Ironic too ... [15:25] jamespage: But that's stuff from Icehouse. [15:25] zigo, I have an ironic maintainer [15:26] (thanks adam_g) [15:26] jamespage: The stuff from Icehouse are not production ready (no driver in Nova Icehouse anyway...), though Juno should be good enough. [15:26] zigo, yeah - this was for juno [15:27] jamespage: For Juno, it's only in Experimental, you know that, right? [15:27] zigo, oh yes [15:28] jamespage: You got to get the latest openstack-pkg-tools where I did some fixes to support better systemd & upstart. I generate these now ... [15:28] (as well as the sysv-rc scripts btw...) [15:28] doko, bug 1381601 [15:29] bug 1381601 in tuskar (Ubuntu) "Please remove tuskar from utopic" [Undecided,New] https://launchpad.net/bugs/1381601 [15:29] zigo, next cycle :-) [15:29] zigo, systemd configs will def be an objective - might be a good opporunity to re-align Debian/Ubuntu a bit [15:31] jamespage: What I did is *very* basic for systemd. Basically, I just took the init script dependency, and dumped it in the .service file, and then I call "systemd-start" from the init script in the .service file. [15:31] jamespage, it's only in -proposed [15:31] jamespage: I'd like to do things a way better ... [15:32] jamespage: It'd be a good idea IMO, if we could work that out together. [15:32] doko, does that make a difference? right now its cluttering the proposed break list imho [15:43] mlankhorst: indeed it boots fully if I pass -cpu core2duo [15:45] Laney: Right, which means the bug isn't fixed, IMO. That's a workaround. [15:45] mlankhorst: ^ [15:46] Yes [15:49] jamespage, removed [15:49] doko, thanks! [15:49] bdmurray, any idea about the whoopsie ftbfs? [15:50] jpds, strongswan ping [15:50] doko: Yep, I've had test builds running this afternoon. [15:51] Laney: Oh, unless it's a qemu bug. When you boot without a -cpu, it might be reporting the wrong caps for what it's emulating. :/ [15:52] doko: yeah, there are some test failures (due to https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/revision/633) I'm trying to sort out (without much luck) [15:56] mvo, I'd quite like to get that cloud-archive:juno fix into software-properties in trusty asap - are you planning any updates or shall I SRU away [15:56] ? [16:00] jamespage: just SRU, I have no plans right now [16:00] mvo, ack [16:13] infinity: yup, I can push that. after the partay i suppose [16:13] infinity: thanks, that'll cut down on a lot of (frustrating for the user) bug reports :) [16:15] hi, does anyone know what package gives me /usr/bin/write? [16:15] infinity: yeah but I have no idea what the fuck the real fix has to be [16:15] apt-file doesn't shed any light [17:20] doko: jpds has a fix for strongswan that I'm happy to sponsor, but it involves the same as we did for python-greenlet - ditch the version in utopic-proposed, and a packaging bump to the version in utopic to fix the FTBFS from the rebuild test. [17:20] Is this acceptable [17:20] ? [17:21] (this would be 5.1.2-0ubuntu3) [17:21] strongswan | 5.1.2-0ubuntu2 | utopic | source, all [17:21] strongswan | 5.1.3-0ubuntu1 | utopic-proposed | source, all [17:23] He's already prepared 5.2.0 for V, but it looks too invasive for Utopic IMHO. [17:23] So I think it's unlikely we'll want 5.1.3-0ubuntu1, which FTBFS on arm64 and ppc64el anyway. === roadmr is now known as roadmr_afk [18:01] rbasak, sure, sounds fine [18:18] apw, could you have a look at the keyutils ftbfs, and if that might be a kernel issue on the buildds? I think these are still running precise === tvoss is now known as tvoss|test === beisner- is now known as beisner === masACC is now known as maswan === Zic is now known as Guest45869 === roadmr_afk is now known as roadmr [21:00] If checkinstall misses some files (I don't know/understand how) then do I have any recourse to still use checkinstall, or do I have to go the full packaging route? [21:08] Can someone point me to how ubuntu pkgs are built by the build server? For example, the args passed to ./configure, make, the process for building the DEB etc? [21:08] Surely this is automated [21:16] geomyidae_: of course, it's controlled from debian/rules in each package [21:16] geomyidae_: the build servers use dpkg-buildpackage to do the work [21:17] by the way, "deb" is not an acronym and should not be capitalised [21:17] cjwatson: cool. those are probably the keywords I need to get going. Also, didn't know that, will keep in mind. :) Cheers. [21:20] I'm afraid I don't know anything about checkinstall though [21:26] sergiusens, hey, could ciborium not notify on almost every boot about a SD card that's permanently in there? [21:27] Saviq: I can remove that for on start or you can do what ogra_ did and disable notifiations from system settings [21:27] Saviq: to be fair, users aren't expected to reboot every 5 minutes and I guess that's where you are getting annoyed [21:28]