[00:20] <ramblagir> Is there a way to download all (or a large part) of the development tools packages in the main repository as a disk image?
[00:41] <cjwatson> doko_: ok for me to merge dpkg? (you touched it last)
[00:45] <doko_> cjwatson: please don't ask, my upload was just a version fix
[00:46] <cjwatson> ok
[01:05] <mathiaz> mneptok: hi!
[01:05] <mathiaz> mneptok: re https://blueprints.launchpad.net/ubuntu/+spec/mariadb-inclusion
[01:06] <mathiaz> mneptok: could you rename it so that it starts with server-lucid- and assign mdz as the approver?
[01:21] <mneptok> mathiaz: done
[01:22] <mneptok> mathiaz: new URL - https://blueprints.edge.launchpad.net/ubuntu/+spec/server-lucid-mariadb-inclusion
[01:22] <mathiaz> mneptok: great - thanks
[01:43] <virtuald> +
[02:06] <hedkandi> anyone know about the debian rules file?
[02:08] <maco> hedkandi: what about it?
[02:08] <hedkandi> well I'm just trying to understand one here
[02:08] <hedkandi> http://revu.ubuntuwire.com/revu1-incoming/swiggle-0905081139/swiggle-0.4/debian/rules
[02:08] <hedkandi> what is the build target?
[02:20] <cristim> hello, I'm trying to build a package for intrepid using launchpad's PPA, and post it there on my PPA. is it enough to set in the latest changelog entry to intrepid instead of karmic?
[02:21] <maco> yep
[02:21] <maco> well maybe
[02:21] <maco> assuming its compatible with intrepid
[02:21] <cristim> yes
[02:21] <maco> ie, that all its dependencies exist in intrepid
[02:21] <cristim> it pnly depends on Perl
[02:21] <cristim> no matter which version
[02:21] <cristim> thanks!
[02:22] <cristim> is it possible to support them both?
[02:22] <cristim> I mean, will the karmic one dissapear if I add intrepid?
[02:23] <cristim> or is it accumulative
[02:29] <cristim> also, is there a time treshold for PPA uploads?
[02:30] <cristim> I've repeatedly uploaded a package and it seems it's not getting there at all
[02:32] <maco> the usual way is to make it like
[02:32] <maco> ~intrepid1
[02:32] <maco> and ~karmic1
[02:32] <maco> for the version #s
[02:35] <cristim> pygccxml (1.0.0-2-cristi1) karmic; urgency=low
[02:35] <cristim> is it supposed to be 1.0.0-2~cristi1 instead?
[02:45] <maco> yeah use ~ for sort order
[02:45] <maco> that way if 1.0.0-3 comes out, its considered newer than yours
[02:45] <maco> er...hmm im not sure in which cases it matters actually...dpkg has a --compare-versins to answer that question
[02:50] <cristim> thanks
[02:51] <cristim> is there a FAQ for PPA?
[02:54] <maco> no idea
[02:54] <maco> really, you're asking #ubuntu-motu questions
[02:54] <cody-somerville> no, #launchpad questions
[02:54] <maco> all you're asking is about normal debian packaging
[02:55] <maco> cody-somerville: hmmm? ok
[02:55] <cody-somerville> packaging questions can be asked in #ubuntu-motu, sure
[02:55] <cody-somerville> but generally questions about the PPA service should be asked in #launchpad
[03:56] <smwn> anyone ubuntu developers here?
[03:57] <cody-somerville> smwn, tons
[03:58] <smwn> oh just want to make a comment
[03:59] <smwn> I like ubuntu but it doesnt work with my usb wifi adapter
[03:59] <smwn> dwa 160
[03:59] <smwn> d link
[04:01] <TheMuso> smwn: Have you filed a bug?
[04:01] <smwn> No
[04:01] <smwn> how
[04:01] <maco> ubuntu-bug linux
[04:02] <smwn> is that a website
[04:02] <maco> its a command
[04:03] <maco> itll open the bug reporter
[04:03] <maco> you can hit alt+f2 and put that command in there
[04:03] <smwn> ah
[04:03] <smwn> I'm on windows
[04:04] <maco> oh right
[04:04] <smwn> cuz my net wont work
[04:04] <maco> uhh
[04:04] <smwn> once i get that sorted i'll delete windows
[04:04] <smwn> and install ubuntu
[04:04] <maco> right
[04:04] <smwn> I like the free software philosophy
[04:05] <maco> you cant report a bug in launchpad from web browser easily anymore... (possibly at all if the "no-redirect is broken" bug is still open)
[04:05] <maco> the bug reporter would attach information about your hardware
[04:05] <wgrant> maco: It's fixed, and even avoids redirecting by default if you give it a package name.
[04:05] <maco> are you *sure* its unsupported? maybe if you plug in with a wired connection itll offer to download teh wireless driver?
[04:05] <maco> wgrant: ooooh! yay!
[04:06] <maco> so thatd be http://bugs.launchpad.net/ubuntu/+source/linux/+filebug
[04:06] <maco> smwn: go there ^
[04:06] <wgrant> Correct.
[04:06] <smwn> ok
[04:06] <smwn> maybe it works not sure
[04:06] <smwn> i'm new
[04:06] <maco> smwn: try connecting to a wired network
[04:06] <smwn> ok
[04:07] <maco> smwn: system -> administration ->hardware drivers
[04:07] <maco> smwn: there are some wireless cards which that'll offer to fetch you drivers
[04:07] <maco> alternatively, get the windows driver and ask in #ubuntu about ndiswrapper
[04:07] <smwn> thanks
[04:07] <smwn> i'll try that
[04:08] <maco> alright, im popping off now
[05:30] <Natanaiel> what is a dpkg hook?
[05:49] <AnAnt> Hello, a question about 3.0 (quilt) source formats & sync'ing from Debian. If a package in Debian is in the 3.0 (quilt) source format, will it be sync'ed in lucid ?
[05:50] <AnAnt> I ask because when I asked before about the 3.0 (quilt) source format will be allowed in lucid, the answer is that it won't be for a little while yet
[05:51] <ScottK> That's still the answer.
[05:52] <AnAnt> ScottK: so the package won't be sync'ed that is ?
[05:52] <ScottK> Not yet.
[05:52] <AnAnt> ok
[05:52] <AnAnt> thanks
[06:01] <Natanaiel> what is a dpkg hook?
[07:56] <dholbach> good morning
[07:59] <Natanaiel> what is a dpkg hook?
[08:22] <pitti> Good morning
[10:03] <pitti> ttx, mathiaz, Riddell: FYI, I just went through https://blueprints.edge.launchpad.net/sprints/uds-l/+settopics (the proposed ones), accepted the "good" ones, and rejected the spam and the ones from people who don't attend; they should appear on summit.u.c. in a few minutes, so please schedule away
[10:08] <soren> Oh, ttx and mathiaz have scheduling powers? Cool.
[10:08] <ttx> soren: no we haven't
[10:08] <ttx> (or maybe I'm a superhero that ignores his own powers)
[10:09] <soren> Ah. :(
[10:09] <ttx> pitti: thanks anyway :)
[10:11] <pitti> hey, it's 11.11 11:11
[10:11] <pitti> (in CET anyway)
[10:12] <ogra> pitti, hmm, did you notice that rhythmbox stops playing if you switch to a console nobody is logged in ... is that polkit loosing its authority ?
[10:12] <pitti> ogra: it's you losing access to /dev/snd/ because you aren't on the active console anymore
[10:13] <soren> ogra: I believe it's intentional.
[10:13] <pitti> (unless you are in group "audio")
[10:13] <ogra> i wonder why the device permissions are so restrictive
[10:14] <Natanaiel> what is a dpkg hook?
[10:15] <pitti> ^ never heard about it
[10:15] <pitti> ogra: well, if you'd allow access to all consoles, you'd hear all user's music at the same time; hardly enjoyable?
[10:16]  * pitti leaves for an hour for some errands
[10:16] <ogra> depends :)
[10:16] <ogra> if there is just one user i dont really care :)
[10:19] <\sh> moins
[10:23] <soren> I think it's a rather odd assumption that because I switch to a different desktop or to a console, that I want to listen to different music.
[11:08] <cjwatson> Natanaiel: while dpkg has various extension mechanisms, there's nothing I know of that's generally referred to as just a "dpkg hook". Perhaps it would help if you gave some context.
[11:35] <joaopinto> there is a new HPLIP version which brings support for newer printer models, is this likely to get an SRU ? Is someone from HP working with Canonical on this ?
[11:36] <dholbach> joaopinto: if anybody knows, it's tkamppeter_, king of printing!
[11:37] <joaopinto> ok, there is a question https://answers.launchpad.net/hplip/+question/84333 , I am not sure it should be linked to a bug report
[11:42] <tkamppeter> joaopinto: The Ubuntu policy is that new upstream versions get only an SRU if they are pure bug fix releases and/or fix severe problems.
[11:42] <joaopinto> a non working printer is not a severe problem :) ?
[11:42] <tkamppeter> joaopinto: I have packaged HPLIP 3.9.10 for Lucid though.
[11:44] <joaopinto> I have asked my dad to buy HP all-in-one on the  assumption that it would work with the current Ubuntu release, there is a widely publicity that HP all in one printers wok fine on Ubuntu
[11:45] <joaopinto> I think is reasonable to provide support for hardware which was largely available when the release was out
[11:48] <joaopinto> the issue here is not new hw, but hw support coming late
[12:03] <pitti> stgraber: can you please do https://edge.launchpad.net/sprints/uds-l/+attend ? Otherwise it's hard to schedule your blueprints
[12:30] <cowgarden> will there be a global equalizer one day? I'd love it
[12:52] <\sh> Keybuk, RE: hw nic + virtual interfaces via /e/n/i == fail on startup in karmic... any more ideas to come up with to test this?
[13:06] <cjwatson> gilir: you should really check with the person who touched a package last before filing sync requests; I've come across quite a few cases in the archive admin request queue where the touched-it-last person has filed a sync request duplicating yours, so you're clearly duplicating work :-(
[13:07] <cjwatson> gilir: later in the cycle we might want to hoover up things that haven't been dealt with, but early on it's more efficient to just let the touched-it-last person take care of it
[13:13] <stgraber> pitti: hmm, I'm already on the list at https://edge.launchpad.net/sprints/uds-l ...
[13:13] <Laney> requestsync has a simple duplicate check which could help there
[13:14] <pitti> stgraber: ah, sorry, it was a real scheduling conflict; nevermind (resolved now)
[13:15] <stgraber> pitti: np
[13:15] <cjwatson> Laney: that would have avoided the duplicate reports, but not the duplicate work leading up to the reports
[13:15] <cjwatson> I'm not that bothered about having to hit the dup button occasionally
[13:15] <Laney> cjwatson: indeed, it's not a solution
[13:16] <cjwatson> doko_: which is why I asked you about dpkg, btw - it's not because I really thought you desperately wanted to merge it, it's because it's good standard practice
[13:21] <pitti> siretart: ^ speaking of which, I'd look at cryptsetup merge now, unless you already started?
[13:22] <siretart`> pitti: please proceed
[13:28] <lool> Hmm ureadahead is being installed on my system with SRU updates; isn't that a bit invasive?
[13:29] <ion> Well, even in the worst case scenario, the system will still boot just fine.
[13:29] <ion> And sreadahead totally killed the performance for a lot of machines with HDDs.
[13:30] <pitti> hm, is that deliberate? (the transitional sreadahead for karmic-proposed)
[13:30] <ion> I hope so. :-P
[13:30] <pitti> I NEWed it to universe, I think it should be promoted to main then
[13:30] <lool> pitti: Definitely
[13:30] <cjwatson> I definitely think we ought to - it's rather outside the usual parameters, but it makes *such* a difference on hard disks
[13:31] <pitti> +1
[13:31] <pitti> promoted
[13:31] <lool> I have a SSD so I didn't actually test it; if you have both first hand experience with it then i guess it's a good move  :-)
[13:31] <pitti> it's aaaaawesome
[13:31] <lool> haha
[13:32] <pitti> (which is why I'm concerned about being too biased to make the call :-P )
[13:32] <cjwatson> lool: it halved my boot time, near enough
[13:32] <pitti> 57 s -> 25 s for me (grub->gdm)
[13:32] <lool> Impressive indeed
[13:33]  * Laney is tempted to reboot just to see
[13:33]  * ogra rather bought an SSD instead of waiting for ureadahed :)
[13:33] <cjwatson> with readahead-type changes, you need to reboot twice to see benefits (the first reboot profiles)
[13:33] <Laney> yep
[13:33] <Laney> don't have bootchart installed already sadly
[13:33] <pitti> I deliberately keep my ultra-slow hd until after lucid, for better measurement of boot/desktop speed improvements :)
[13:36] <tgpraveen1> when can everybody view the lucid blueprints currently it says i
[13:36] <tgpraveen1> dont have enough priveleges with my username or osmething
[13:36] <pitti> tgpraveen1: https://blueprints.launchpad.net/ubuntu/lucid/+specs
[13:38] <cjwatson> tgpraveen1: the list won't be hugely meaningful until after UDS
[13:39] <soren> Keybuk: It seems ifenslave (recently?) grew an option to define the master/slave relationship the "other" way around. See e.g. /usr/share/doc/ifenslave-2.6/examples/two_hotplug_ethernet
[13:39] <tgpraveen1> pitti: cjwatson
[13:39] <tgpraveen1> tgpraveen •
[13:39] <tgpraveen1> Not allowed here
[13:40] <tgpraveen1> Sorry, you don't have permission to access this page.
[13:40] <tgpraveen1> You are logged in as tgpraveen.
[13:40] <pitti> weird
[13:40] <tgpraveen1> https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-empathy-indicator
[13:40] <tgpraveen1> and clicking Set the URL for this specification
[13:41] <cjwatson> writing specifications is meant to be a developer activity
[13:42] <cjwatson> so it may well require developer privileges
[13:43] <cjwatson> if you see "Set the URL for this specification" it means that nobody has fleshed out the summary into a wiki page yet; that will be one of the outputs from UDS
[13:54] <\sh> anyone has a clue to teach upstart to log all --info --debug stuff into a logfile? only reading from the console doesn't help
[14:07] <pitti> siretart`: cryptsetup merged; now my dk-disks test suite passes again \o/
[14:07] <pitti> (our karmic version didn't support DM_UUID yet)
[14:29] <siretart`> pitti: have you also tested that booting from crypted lvm still works?
[14:29] <siretart`> (aka, can I safely upgrade my laptop?) ;-)
[14:29] <siretart`> (just kidding)
[14:29] <pitti> siretart`: I didn't test that, no; but the differences to Debian are pretty small now
[14:30] <pitti> and I did test both LVM and LUKS partitions
[14:30] <pitti> both manually, and with my devkit-disks test suite
[14:30] <siretart`> ok. then I'll test the crypto lvm part :-)
[14:30] <pitti> danke
[14:48] <\sh> soren, but the option for the hotplug stuff doesn't work out properly, when interfaces are already added via udev...
[14:48] <soren> \sh: Huh?
[14:49] <\sh> soren, allow-hotplug eth0\n iface eth0 inet manual \n bond-master bond0 etc.pp.. the test (we talked about that example) fails, because the hotplug event doesn't come through...or the bond interface is not configured when the event occured
[14:50] <\sh> this bonding thing is really complicated sometimes
[14:50] <soren> It shouldn't depend on bond0 being configured ahead of time.
[14:51] <\sh> well...for our upstart thing it doesn't help...and I tried to get the console to my ilo virtual serial, and this fails too, because it stops somehow ... need to play with the speed of it
[14:52] <soren> Oh.
[14:52] <\sh> or something drops the console=ttySx
[14:52] <soren> It's because of the allow-hotplug. the upstart job doesn't set --allow=hotplug
[14:52]  * soren has to run for half an hour or so.
[14:55] <\sh> soren, where should it be set? during network-interface.conf pre-start script?
[15:16] <\sh> soren, no change in behaviour
[15:27] <\sh> soren, Oh wonder oh wonder...I can only see /etc/init/network-interface.conf be executed, but not /etc/init/networking.conf (added some script echo ... >> /tmp/upstart.log end script foo to the important files
[16:19] <tkamppeter> pitti, hi
[16:23] <siretart`> @ftpmasters: will emacs23 be semi-"automatically" be promoted to main and emacs22 demoted to universe during the usual archive cleanups, or is a full MIR report required for this?
[16:23] <pitti> siretart`: no full MIR necessary, it's by and large just a new version
[16:23] <pitti> if we can promote/demote at the same time, it will pretty much "just happen"
[16:24] <siretart`> ok great! thanks
[16:24] <unimatrix> pulseaudio sucks, please remove it from ubuntu, i need AC3 passthrough
[16:24] <ion> :-D
[16:24] <siretart`> I've already did the necessary uploads
[16:25] <siretart`> unimatrix: try #ubuntu. they will explain you what 'apt-get remove pulseaudio' does.
[16:25] <blackxored> Hello, I'm just finishing the debian NM process, I'm waiting for DAM approval for becoming an official debian developer, I'm now just wondering if the process in ubuntu is easier than the one I've just passed, to see if I can become an ubuntu dev or MOTU as well, any clues?
[16:25] <ion> unimatrix: That kind of attitude will get you far.
[16:26] <unimatrix> ion: but PA people don't like it when you're being nice, they just ignore feature requests
[16:26] <siretart`> blackxored: try the links in the #ubuntu-motu channel. you'll still need to do a report and stuff, but the process is much easier and faster than NM in debian. espc. because your debian contribution count as ubuntu contributions.
[16:27] <blackxored> siretart, great let me check the topic at that channel since I'm there as well
[16:28] <ion> What’s the point of AC3 passthrough in the first place? Why not simply decode the audio data just like all other audio data and then send it out using whatever method is available; for instance an AC3 output or an analog multi-channel output?
[16:28] <Laney> siretart`: They do? I mean, does that imply that any DD can automatically become an Ubuntu developer?
[16:28] <Laney> I would expect some kind of Ubuntu-specific experience too
[16:29] <siretart`> ion: because you might want to use the external AC3 decoder below your TV?
[16:29] <siretart`> Laney: no, I didn't say that
[16:29] <ion> siretart: How would this method hinder that?
[16:31] <siretart`> ion: because you do not want your computer decode ac3, but some external device?
[16:31] <unimatrix> ion: here's another example... your CPU is old, but you have an external decoder...
[16:32] <siretart`> or the speakers are connected to the external device only?
[16:40] <cjwatson> Laney: it's a fast track, not a no-effort track. :-)
[16:42] <Laney> cjwatson: Yeah I was trying to get at the fact that while previous Debian contributions may count somewhat towards an Ubuntu development application, it should only act as an informal shortcut and not a back door
[16:43] <Laney> A large part of assessing new developers seems to be determining that they know what they're doing technically, and Debian work should count for that
[16:43] <cjwatson> I think it's a formal shortcut; I'm fairly sure we've explicitly advertised that Debian developers will find it easier
[16:44] <Laney> well it at least doesn't seem to have a place in the applications procedure
[16:44] <Laney> whether it's something that the DMB or whoever will take into account is another matter
[16:44] <\sh> Keybuk, does upstart clean somehow /var/run after a job is stopped or finished?
[16:45] <Laney> but I don't know practically what people assessing applications would want to see from a DD wanting to be an Ubuntu developer
[16:46] <\sh> EUREKA ! I found a bug
[16:46] <Keybuk> \sh: no
[16:47] <\sh> Keybuk, ok...something removes /var/run/network directory, which you create inside /etc/init/network-interface in pre-start
[16:47] <\sh> Keybuk, therefore ifup -a inside /etc/init/networking.conf fails
[16:48] <\sh> adding pre-start script mkdir -p /var/run/network end script inside /etc/init/networking.conf helps to come up with all interfaces which /e/n/i defines
[16:49] <\sh> Keybuk, http://paste.ubuntu.com/316095/ <- this works as expected
[16:50] <cjwatson> Laney: that they've figured out how Ubuntu works, and normally a quick double-check on technical clue
[16:50] <\sh> soren, can you check if that helps you with your briding stuff, too?
[16:52] <Keybuk> \sh: why use a pre-start script there
[16:52] <Keybuk>   script
[16:52] <Keybuk>     mkdir -p /var/run/network
[16:53] <Keybuk>     exec ifup -a
[16:53] <Keybuk>   end script
[16:53] <Keybuk> would be better
[16:53] <\sh> Keybuk, you are the expert, I just wanted to make it work ;) now to find the bugger who removed /var/run/network after a job is stopped/finished..
[16:54] <Keybuk> no idea
[16:54] <Keybuk> /var/run is a tmpfs ;)
[16:54] <Keybuk> maybe you forgot "local-filesystems" in the ...and bits
[16:55] <Keybuk> maybe I forgot too :p
[16:55] <\sh> Keybuk, as you can see in the paste output, I didn't it's the normal job script for this
[16:56] <\sh> Keybuk, start on (local-filesystems and stopped udevtrigger) is the default content...so something else is triggering a removal
[17:02] <Riddell> doko_: gdb is still compiling, does this test suite really take a day to complete?
[17:04] <\sh> it works...
[17:05] <hdon> should gcc option -std=gnu99 define the _GNU_SOURCE macro?
[17:06] <ion> Probably not.
[17:06] <doko_> Riddell: no, this doesn't sound right
[17:06] <Riddell> doko_: they all seem to be failing too
[17:07] <Riddell> expect is running but it's not running very fast or using up much CPU
[17:11] <\sh> Keybuk, could be that /etc/init/networking.conf is being executed before /etc/init/network-interface.conf which means, /var/run/network is really not available at this time
[17:11] <Keybuk> yes, that's possible
[17:12] <\sh> Keybuk, testing your idea with "script..." only.
[17:14] <Keybuk> robbiew_ is brave
[17:14] <Keybuk> even I didn't just install those packages and reboot <g>
[17:14] <ion> Which packages?
[17:14] <StevenK> Keybuk: But robbiew_ does know where you live :-)
[17:14] <mathiaz> when are conffiles installed? during the unpack phase or the postinst phase?
[17:14] <Keybuk> robbiew: did it work?
[17:14] <doko_> Riddell: which version do you try to build?
[17:14] <robbiew> sort of :/
[17:14] <Keybuk> ion: plymouth ones
[17:15] <Riddell> doko_: the one from karmic
[17:15] <Riddell> doko_: with the pie patches removed
[17:15] <Keybuk> robbiew: sort of is unsurprising, even I haven't tested it yet :p
[17:15] <\sh> Keybuk, should I add a debdiff to ifupdown bug #446031 with the change ?
[17:15] <robbiew> I saw plymouth stuff on shutdown..but nothing on reboot
[17:15] <Keybuk> \sh: sure
[17:15] <robbiew> except usplash was removed
[17:15] <Keybuk> robbiew: yeah, there might be no startup splash yet <g>
[17:15] <Keybuk> but it works on shutdown <g>
[17:17] <doko_> Riddell: strange, not seen on the buildds. we once had the lpia build taking way long in the testsuite, but didn't investigate (neither kees nor me)
[17:18] <Riddell> doko_: meh, I'll try some different things then
[17:20] <robbiew> Keybuk: and apparently /usr/sbin/plymouth-set-default-theme requires nash :/
[17:20] <StevenK> robbiew: bash, even?
[17:21] <Keybuk> robbiew: haha, fail
[17:21] <Keybuk> StevenK: no, nash :p
[17:21] <StevenK> Hm. I just tried to look for that and failed
[17:21] <Keybuk> StevenK: install RedHat
[17:21] <Keybuk> it's their NIH shell ;)
[17:21]  * StevenK shivers
[17:22] <Keybuk> they are killing it
[17:22] <Keybuk> in favour of dracut
[17:22] <StevenK> Ooooh, another shell I haven't heard of. Fun!
[17:23] <Keybuk> dracut is their NIH initramfs-tools
[17:23]  * StevenK sobs
[17:24] <StevenK> What is it with RedHat giving things crappy names that have no relation to their function?
[17:24] <Keybuk> kudzu!
[17:24] <ion> ubuntu!
[17:24] <StevenK> Ubuntu *does* relate
[17:25] <ebroder> "byobu" :-P
[17:25]  * Keybuk wishes he didn't hear elmo everytime anyone says that
[17:28] <cjwatson> StevenK: I suppose there are tenuous justifications for casper and ubiquity
[17:28] <cjwatson> casper => magic ghost (since hardly anyone really understands live CD boot, or did at the time)
[17:28] <mvo> robbiew_: what plymouth packages? not the ones in the plymouth ppa?
[17:29] <cjwatson> ubiquity => get Ubuntu everywhere
[17:29] <Keybuk> the ones in alberto's ppa
[17:29] <StevenK> cjwatson: Right, there's a connection, albeit one that you have to squint and turn your head for, but it does exist
[17:29] <mvo> aha, ok. the one in the plymouth one is broken, happy to hear that alberto is fixing it
[17:29] <Keybuk> upstart => start up, but done the other way round to everyone else
[17:29] <cjwatson> StevenK: that may be the case for dracut, for all we know :)
[17:30]  * mvo should borrow his package and drop into the plymouth ppa
[17:30] <\sh> Keybuk, updated #446031 ->
[17:30] <StevenK> It's a special cut of crack that includes drano?
[17:30] <Keybuk> cjwatson: isn't dracut just the town where harald lives?
[17:30]  * StevenK wildly guesses
[17:30] <cjwatson> Keybuk: could well be, since it's a town in MA
[17:30] <cjwatson> I'll have to call my next project belfast. cambridge is probably used for something already
[17:31] <StevenK> Oooh. Named after the town the author lives in. That thread just snapped
[17:31] <Keybuk> Plymouth, MA as well
[17:31] <Keybuk> Fedora 10 was "Cambridge"
[17:31]  * Keybuk senses a naming scheme here
[17:32] <Keybuk> mvo: broken how>?
[17:32] <StevenK> Keybuk: Haha, sounds like one
[17:33] <Keybuk> mvo: it looks like he's updated it to 0.8.0 from your PPA
[17:33] <Keybuk> cjwatson: if I were to name something after the town in which I was born, it'd be "Crawley"
[17:33] <Keybuk> which is ...
[17:33] <Keybuk> unfortunate
[17:33] <cjwatson> it has to be a horror to do that
[17:34] <StevenK> That name just makes me think of a book by Neil Gainman
[17:34] <StevenK> Whose name currently escapes me
[17:34] <cjwatson> that was Crowley :) and you mean Good Omens
[17:34] <StevenK> Ah yes!
[17:35] <StevenK> So close!
[17:35] <Keybuk> The Nice And Accurate Prophecies of Agnes Nutter, Witch
[17:35]  * StevenK needs to re-read that
[17:37] <StevenK> Hm. The lag from being on an airplane at 37,000 ft isn't so bad
[17:38] <StevenK> It doesn't feel like two-way satellite, at least ...
[17:39] <maco> bragging about that airplane-with-tube-access?
[17:39] <StevenK> Not bragging, surprised
[17:42] <Keybuk> mvo: looking at this, I suspect this comes from a secret OEM stash of packages they don't give the Platform team <g>
[17:42] <mvo> Keybuk: I have not investigated, it seems like in the plymouth ppa something with the initramfs generation goes wrong (a file missing maybe) or something
[17:42] <Keybuk> probably stored in a candy jar or something
[17:42] <mvo> Keybuk: haha
[17:43]  * mvo was always good at plundering the candy jar
[17:44] <Keybuk> it's got an ubuntu theme in it and *everything*
[17:44] <Keybuk> written by someone called Michael Terry
[17:46] <highvoltage> mvo: and you admit to it in public? last time I said something like that I got 13 requests on facebook to join a all kinds of cookie jar groups!
[17:47] <mvo> highvoltage: weehh, scary - and this channel is logged too
[18:00] <mathiaz> Keybuk: upstart job question - I've got one upstart job that start avahi-publish with a script stanza
[18:00] <mathiaz> Keybuk: now if avahi-daemon is restarted, the avahi-publish process dies
[18:01] <mathiaz> Keybuk: how can I make sure that the avahi-publish job will be restarted if avahi-publish dies?
[18:01] <Keybuk> respawn?
[18:03] <mathiaz> Keybuk: \o/ - awesome! Thanks
[18:10] <hdon> using -DDB_DBM_HSEARCH=1 in order to enable the historic ndbm api #defines causes many redeclaration errors http://pastebin.mozilla.org/682943
[18:44] <hdon> donny@pacemates:~/gpsee/src$ echo -e '#include <pthread.h>\npthread_cleanup_push(foo, bar)' | gcc -Wall -E - | tail -n 1
[18:44] <hdon> do { __pthread_unwind_buf_t __cancel_buf; void (*__cancel_routine) (void *) = (foo); void *__cancel_arg = (bar); int not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *) __cancel_buf.__cancel_jmp_buf, 0); if (__builtin_expect (not_first_call, 0)) { __cancel_routine (__cancel_arg); __pthread_unwind_next (&__cancel_buf); } __pthread_register_cancel (&__cancel_buf); do {
[18:44] <hdon> what is with the malformed output of that macro?
[20:33] <dariocaruso> salve! vorrei chiedere a qualcuno quanlche info sul file changelog
[20:33] <dariocaruso> devo caricare un programma su launchpad
[20:34] <dariocaruso> ma launchpad lo rigetta
[20:34] <dariocaruso> suppongo che dipenda dal file changelog
[20:34] <dariocaruso> c'è qualcuno?
[20:35] <Goga777> soren, could you have a look please on libmms 0.5 patch http://launchpadlibrarian.net/35334345/checkborders.diff thanks
[21:35] <mathiaz> james_w: hi
[21:36] <mathiaz> james_w: seems that apr-util pkg branches are not up-to-date
[21:36] <mathiaz> james_w: for lucid and squeeze
[21:57] <billisnice> my kid said 9.10 sucked...lol
[21:58] <ion> That’s okay, he sucks, too.
[22:02] <billisnice> girl, the screen redraw and it hangs is so bad
[22:02] <billisnice> i hope it is being worked on
[22:03] <maco> teach her to file a bug?
[22:04] <Keybuk> ion: I'm delighted by a find
[22:04] <Keybuk> plymouth in git gained an X11 backend "for debugging" :-)
[22:04]  * Keybuk feels some abuse coming
[22:04] <ion> keybuk: :-)
[22:04] <billisnice> 9.04 worked faultlessly on an old dell, but this so bad
[22:04] <Keybuk> I wonder whether it's possible/easy to live switch renderers in plymouth
[22:04] <ion> That would be neat.
[22:04] <Keybuk> I reckon it is
[22:05] <Keybuk> so rather than quitting plymouth when X starts, you'd do plymouth --hide-splash and plymouth --show-splash either side
[22:06] <mathiaz> zul: bug 472924 - why sync from unstable instead of testing?
[22:09] <zul> mathiaz: cant remember why
[22:39] <mathiaz> james_w: hi - I've tried to use the merge-package command to merge libdbd-mysql-perl
[22:39] <mathiaz> james_w: following https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging
[22:39] <mathiaz> james_w: it failed with an error: bzr: ERROR: The upstream branches for the merge source and target have diverged.
[22:40] <mathiaz> james_w: not sure what to do next.
[22:41] <mathiaz> james_w: I don't see why the upstream branch would have diverged between lp:debian/squeeze/ and lp:ubuntu/lucid/
[22:46] <cjwatson> hdon: it isn't malformed, you're just not permitted to use pthread_cleanup_push without pthread_cleanup_pop. See the comments in the header file
[22:48] <slangasek> mathiaz: because the package is at a different upstream version in Debian vs. Ubuntu
[22:49] <slangasek> mathiaz: trying this merge here, I get an error message that says "resolve these conflicts, commit, and rerun merge-package"?
[22:50] <mathiaz> slangasek: yes - this is what I get
[22:52] <mathiaz> slangasek: the conflicts are in the upstream branch
[22:52] <mathiaz> slangasek: I thought I wouldn't have to touch the upstream branch
[22:53] <slangasek> mathiaz: <shrug> ideally no, but the Ubuntu package (at least) appears to have a patch applied directly to the upstream source
[22:54] <slangasek> mathiaz: so merge-package has a harder job to do, that does involve merging the upstream source
[22:55] <mathiaz> slangasek: on a related note - if I managed to get the merge right, how do I create the orig file?
[22:55] <slangasek> mathiaz: <mumble, handwave>
[22:55] <mathiaz> slangasek: bzr bd -S will take care of everything?
[22:55] <slangasek> not AFAIK; I think you have to grab it from somewhere - e.g. from merges.u.c
[22:56] <slangasek> bzr-builddeb does depend on pristine-tar, but the infrastructure to use it doesn't seem to be there yte
[22:56] <slangasek> yet
[22:57] <mathiaz> slangasek: ok - thanks for helping out.
[22:57] <slangasek> n/p
[22:57] <mathiaz> slangasek: I'll use the merge command instead
[22:57] <mathiaz> slangasek: bzr merge lp:debian/libdbd-mysql-perl worked as expected
[22:57] <slangasek> heh, ok
[22:57] <mathiaz> slangasek: and I don't plan to push the branch to LP - so it should work out correctly - I'll give it a try
[22:59]  * slangasek punches NFSv4+ftruncate in the neck
[23:01] <mathiaz> hm - I run into a bzr ci error now: there is utf-8 character (the arrow) in the changelog
[23:01] <mathiaz> and bzr bails out
[23:02] <mathiaz> james_w: lifeless: http://paste.ubuntu.com/316411/
[23:02] <cjwatson> Keybuk: does merges.ubuntu.com work now that it has a sensible dpkg?
[23:03] <Keybuk> ValueError: process failed 25: dpkg-source -x xbuffy_3.3.bl.3.dfsg-6.dsc /srv/patches.ubuntu.com/unpacked/x/xbuffy/3.3.bl.3.dfsg-6
[23:03] <Keybuk> hmm
[23:03] <cjwatson> http://packages.qa.debian.org/x/xbuffy/news/20091101T002911Z.html looks perhaps relevant
[23:03] <cjwatson> maybe we need quilt installed?
[23:04] <Keybuk> maybe :D
[23:04] <cjwatson> actually I think it was just a bug in that version of the package
[23:04] <cjwatson> judging from the next changelog along, anyway
[23:04] <Keybuk> yeah
[23:04] <Keybuk> I'll wipe it from the cache
[23:04] <Keybuk> the -7 is in there
[23:04] <cjwatson> though having quilt installed would insulate us from this
[23:04] <Keybuk> elmo: can you add quilt
[23:06] <elmo> Keybuk: done
[23:07] <Keybuk> elmo: thanking you kindly
[23:27] <Keybuk> \o/


[03:14] <smoser> pitti, around ?
[03:15] <smoser> i think i relize the issue with letting the udevrule go through.
[03:15] <smoser> cloud-init wont have written the .link file to rename at the point when the udev rule processes the .link
[03:16] <smoser> so cloud-init local *will* have to re-trigger or otherwise have the systemd.link stuff fire again
[03:19] <smoser> how were you re-triggering with udev to get the .links processed ?
[03:23] <cyphermox> cjwatson: yes, will SRU. thanks. I was looking hard at base-installer, not at apt-setup :/
[03:23] <cyphermox> or at least, not at that part of base-installer that has apt-setup keys.
[03:23] <cyphermox> between us we might manage to really fix the overlay code.
[03:35] <smoser> pitti, 'udevadm test-builtin net_setup_link /sys/class/net/ens4' works to show that the cloud-init written .link files do the right thing.
[03:35] <smoser> but i think i have to re-send the hotplug event to get it renamed.
[07:08] <CarlFK> https://help.ubuntu.com/lts/installation-guide/armhf/apbs04.html#preseed-apt   how do I get it to not #comment out deb-src  lines?  (new in xenial)
[07:25] <zyga> good morning
[08:14] <tjaalton> wgrant: still around? I sent a soyuz question (#293230) about bumping the size of ppa:canonical-x/x-staging, llvm is taking all the space preparing next lts stack :)
[08:15] <wgrant> how on earth
[08:15] <wgrant> It's already 8GiB!
[08:15]  * wgrant doubles
[08:15] <tjaalton> llvm is big
[08:15] <tjaalton> thanks!
[08:24] <mwhudson> is there a script for doing the Maintainers: Ubuntu Developers, XSBC-Original-Maintainers: thing?
[08:24] <Laney> mwhudson: updata-maintainer
[08:24] <Laney> with spelling that is good
[08:26] <mwhudson> Laney: thanks
[08:27] <mwhudson> oh wow, python, i was expecting perl :-)
[08:27] <Laney> it was probably written this decade :P
[08:45] <zyga> hey mwhudson
[09:03] <cjwatson> CarlFK: d-i apt-setup/enable-source-repositories boolean true
[10:51] <sil2100> mvo: hey! Is it ok for me to release the currently staged changes in livecd-rootfs to yakkety?
[10:51] <sil2100> mvo: I have some of my changes that we'd need released to unblock image builds
[10:59] <mvo> sil2100: yeah, thats fine
[11:00] <mvo> sil2100: ogra_ also has some pending changes
[11:00] <sil2100> Thanks!
[11:00] <ogra_> mvo, oh, didnt you say you pushed them to trunk ?
[11:00] <sil2100> They're pushed to trunk but not released yet
[11:00] <sil2100> I'm releasing trunk right now if that's ok
[11:01] <ogra_> bah, i just upgraded my phone to tonights rc-proposed image ... no apps in the apps scope ... no matter how often i refresh
[11:01] <ogra_> ok, seems ten times is the charm ...
[12:09] <yofel> doko: did you intentionally drop the multiarch changes from libical?
[12:11] <doko> yofel, no, saw too late that they were only applied in experimental
[12:11] <doko> but I didn't check if we can sync the experimental package
[12:11] <doko> so maybe I better restore these
[12:12] <yofel> would be nice, it's causing build failures in some kde autopktests as cmake hardcodes the lib path in some places
[12:15] <doko> ahh, I remember
[12:16] <doko> breakfast first
[12:17] <yofel> doko: and thanks for merging digikam
[12:22] <alexbligh1> Is this the sort of thing you'd take a 14.04 SRU for (assuming my one character patch to fix it is OK): https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1578185
[12:23] <smoser> alexbligh1, if if it doesn't break working with older nbd servers' it would surely seem appropriate for sru from what that bug says.
[12:24] <alexbligh1> smoser, nope, it doesn't break anything. OK, I will persuade Wouter (Debian maintainer and nbd maintainer) my one line patch is a good plan :-)
[12:24] <alexbligh1> smoser, thx
[12:39] <shadeslayer> chrisccoulson: hi, I was wondering if you had a moment to talk about firefox? I seem to be hitting a race condition when the configure step is a bit too slow
[12:39] <shadeslayer> for eg. on armhf
[12:40] <rbasak> alexbligh1: thank you for looking after this. Let me know if you need any help with sponsorship etc.
[12:40] <shadeslayer> chrisccoulson: I was wondering if you had seen something similar?
[12:40] <alexbligh1> rbasak, thx - if you could tell me how to mark it as 14.04 only that would be great.
[12:42] <rbasak> alexbligh1: is it Fix Released in Yakkety then? I can add the Trusty task for you. AIUI, that was ACL-restricted to uploaders and triagers only because people kept misunderstanding the purpose or something.
[12:42] <rbasak> alexbligh1: done
[12:43] <alexbligh1> rbasak, yes it was fixed in wily when 3.10 was imported. Thanks.
[13:12] <roadmr> hey folks! so on xenial I get an "updates available" bubble but it's not actionable. Clicking on it does nothing, nor does the dancing update manager appar in the unity dash. I had to hunt it down manually. Is this a bug?
[13:22] <sergiusens> cjwatson pitti hello again, is the fact that I need to do this https://github.com/ubuntu-core/snapcraft/pull/499/files for yakkety a bug in snapcraft that went unnoticed (worked all through xenial) or the new apt/python-apt in yakkety?
[13:40] <cjwatson> sergiusens: Don't know, I'm afraid
[14:03] <ginggs> pitti: hi, can something be done about compute's ppc64el test failure blocking nvidia-cuda-toolkit please? From what I can see, nvidia-cuda-toolkit provides an alternate build-depends which isn't even being tested. The failures have been since the switch to boost1.60.
[14:14] <coreycb> bdmurray, arges: Hi, any chacne we could get a review for the liberty point release in bug 1569502 ?
[14:18] <pitti> ginggs: I added a compute/ppc64el ignore hint
[14:19] <ginggs> pitti: danke!
[14:32] <rbasak> "dpkg: dependency problems prevent processing triggers for ufw"
[14:32] <rbasak> Is this an apt bug? I don't see an obvious packaging deficiency or opportunity for there to be a dependency loop.
[14:33] <rbasak> http://paste.ubuntu.com/16218132/ is my reproduction of bug 1571174
[14:35] <rbasak> It seems to me that apt should have chosen to configure python3 first.
[15:24] <arges> coreycb: i got it
[15:31] <pitti> rcj: cat /sys/class/tty/console/active
[15:31] <rcj> pitti, thanks
[15:38] <doko> yofel, https://bugs.launchpad.net/ubuntu/+source/ffmpegthumbs/+bug/1578269 (only recommended by digikam)
[16:07] <cjwatson> doko: why do you disable entire test suites rather than just the failing test?  (survex, which I'd just started to look at upon noticing that you'd sledgehammered it)
[16:13] <doko> cjwatson, sure, I could have done this as well. however I didn't see any failure on the local build
[16:13] <tjaalton> doko: arm64 fails to build llvm-3.8 on trusty, log says "internal compiler error". this probably is a blocker for lts-xenial. should I file a bug against gcc-4.8?
[16:14] <doko> tjaalton, I'm not involved with the lts uploads of clang. does this persist when you give it back?
[16:15] <tjaalton> doko: built it on a ppa, haven't tried rebuilding
[16:15] <tjaalton> will do that now
[16:17] <doko> cjwatson, alsa-plugins-extra is also merged
[16:17] <cjwatson> doko: I don't see any failure right now on the local build either (I'm investigating), but the point of a test suite is to make problems on future builds less likely
[16:18] <doko> cjwatson, right, that's why I filed a bug report which I intend to re-open after the current transitions
[16:19] <cjwatson> IME those bug reports get lost
[16:21] <doko> ok, then I'll re-upload after the transition with the fix reverted
[16:22] <cjwatson> well like I say I was working on them anyway ...
[16:23] <doko> I only worked on these while you were bringing you kids to bed last night, and just re-started again. but it's not just ffmpeg which is blocking
[16:26] <cjwatson> valgrind shows what the survex problem probably is
[16:30] <cjwatson> and the freshplayerplugin problem is easily reproducible locally in a UTF-8 locale
[16:31] <hallyn> pitti: is there a 'dh_systemd_disable' sort of thing?
[16:32] <pitti> hallyn: there isn't, what should that do?
[16:32] <pitti> units are disabled by default, after all
[16:32] <hallyn> pitti: problem is, we currently have libvirt-bin.service, which is Alias=libvirtd.  We're switching to debian packaging, which has libvirtd.service instead
[16:33] <hallyn> Which I want to Alias=libvirt-bin for ahwile probably
[16:33] <hallyn> but how should i do the renaming?
[16:33] <hallyn> (sorry, biam)
[16:33] <pitti> hallyn: ah, so you need to rename the enablement symlinks in the prerm?
[16:33] <pitti> err, preinst
[16:33] <pitti> hallyn: I think this would be a conditionalized mv in the preinst
[16:38] <cjwatson> doko: When you said "Revert last change" in freshplayerplugin (presumably the build-dependency on libjack-dev), you don't seem to have actually done so.  Should I do so since I plan to upload it anyway?
[16:41] <hallyn> pitti: so i should do it manually using 'mv'?
[16:42] <pitti> hallyn: I think that's better than just rm'ing it and re-creating the new ones, if you want to maintain the fact that an admin manually disabled it
[16:43] <pitti> i. e. it should still be disabled after the upgrade
[16:45] <hallyn> pitti: yeah right now i was just trying to stop it (as in https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/tree/debian/libvirt-daemon-system.preinst?h=2016-05-02/yakkety) and i manually tried 'disabling' it, but that didn't suffice
[16:45] <hallyn> i'll try moving the files - then do i do a systemctl reload?  (from inside prerm?)
[16:45] <cjwatson> doko: Seems to make no difference to the configuration, so I'll go ahead and do that
[16:46] <hallyn> (of course, i *could* just punt on this and keep this as delta from debian, but i'd really like to minimize that)
[16:56] <cjwatson> doko: freshplayerplugin and survex both fixed
[16:56] <doko> ta \o/
[16:56] <tjaalton> doko: rebuild fails too
[17:01] <cjwatson> and uploading an ffmpeg patch that's supposed to fix the autopkgtest failure
[17:06] <hallyn> pitti: gonna try http://paste.ubuntu.com/16221711/
[17:08] <pitti> hallyn: looks good at first sight, and also gets rid of the bare systemctl invocation (which breaks under upstart and with policy-rc.d in e. g. chroots)
[17:09] <pitti> hallyn: FTR, if you ever have that case, please use deb-systemd-invoke, this checks policy-rc.d
[17:09] <pitti> or just invoke-rc.d
[17:10] <hallyn> pitti: ok, thx
[17:10] <hallyn> actually, lemme think.  we have cloud archives, so in fact what i have in that paste is not sufficent,
[17:11] <hallyn> as it'll break if someone in 14.04 upgrades to it
[17:11] <hallyn> i don't suppose we can hae any sort of sanity guarantees about lts-to-lts upgrades even with cloud archives?
[17:11] <hallyn> jamespage: ^ is there going to be a cloud archive providing yakkety's libvirt to pre-15.10 users?
[17:11] <hallyn> (i..e non-systemd-based)
[17:12] <hallyn> zul: ^
[17:14] <zul> hallyn: dunno yet :)
[17:14] <hallyn> well maybe i'll just leave it broken until we know
[17:14] <hallyn> bc 'fixing' it also means papering over other potential bugs
[17:15] <hallyn> pitti: so instead of checking for that symlink by hand should i be doing 'deb-systemd-invoke systemctl is_enabled libvirt-bin' ?
[17:16] <hallyn> nah
[17:16] <pitti> hallyn: deb-systemd-invoke is just for start/stop; enable/disable is fine, not a thing that policy-rc.d covers
[17:16] <pitti> hallyn: but it's by and large the same as checking for the symlink directly, so mostly a matter of preference I'd say
[17:17] <hallyn> ok - thanks
[17:17] <pitti> hallyn: actually
[17:18] <pitti> hallyn: deb-systemd-helper has is-enabled, enable, disable etc., and that might be better as /var/lib/systemd/deb-systemd-helper-enabled/ also needs to be updated
[17:18] <pitti> that's the crazy Debian thing to sync enablement over upgrades, across init systems etc.
[17:19] <pitti> this might fire back if we don't update this too
[17:19] <hallyn> ugh
[17:19] <pitti> hallyn: sorry, I think that might be the first time this kind of upgrade issue happens
[17:19] <hallyn> but what about renames?
[17:20] <hallyn> that is deb-systemd-helper enable/disable isn't quite enough...  oh, but
[17:20] <doko> wgrant, cjwatson, pitti: https://launchpadlibrarian.net/257883350/buildlog_ubuntu-yakkety-i386.slurm-llnl_15.08.10-1build1_BUILDING.txt.gz (packages modifying -dbgsym packages).  is there a plan when we'll switch to the new dbgsym packages?
[17:20] <hallyn> i can just disable, move the classical links by hand, then enable?
[17:20] <hallyn> pitti: put another way: what the heck is under /var/lib/systemd/deb-systemd-helper-enabled/
[17:20] <pitti> hallyn: so I think "if deb-system-helper is-enabled <old name> then disable the old name, otherwise disable the new name
[17:21] <pitti> hallyn: so, I'm fairly sure that just handling the links as you do it now should work
[17:21] <pitti> as the /var/lib/helper stuff never trumps admin changes
[17:21] <pitti> so, forget what I said
[17:21] <hallyn> ok
[17:22] <pitti> hallyn: the stuff in /var/lib basically tracks the distro defaults
[17:22] <hallyn> otherwise i was thinking i'd need to deb-systemd-helper purge; move the files, deb-systemd-helper enable
[17:22] <hallyn> ok - so those files should get dropped naturally?
[17:22] <hallyn> i'll make a note to check them in a test - thanks pt
[17:22] <hallyn> uh.  thanks pitti
[17:22] <pitti> this would be really ugly indeed
[17:23] <pitti> hallyn: for testing, I think check that it upgrades correctly with an enabled and disabled service, and that installing it again works
[17:23] <pitti> and ignore the /var stuff
[17:23] <hallyn> ok thx
[17:55] <hallyn> man sometimes ppas just take forever to publish after building...
[17:57] <doko> ubuntu-keyboard-swedish/amd64 unsatisfiable Depends: hunspell-sv-se
[17:57] <doko> ubuntu-keyboard-swedish/armhf unsatisfiable Depends: hunspell-sv-se
[17:57] <doko> ubuntu-keyboard-swedish/i386 unsatisfiable Depends: hunspell-sv-se
[17:57] <doko> sil2100, ^^^
[18:18] <hallyn> pitti: argh.  well i can't do that in pre-inst, apparently /lib/systemd/system/libvirt-bin.service has been removed by this point
[18:18] <pitti> hallyn: uh? that sounds wrong; preinst runs before unpack
[18:18] <hallyn> maybe i do it in the libvirt-bin (which is otherwise just a metapackage) preinst/
[18:19] <pitti> no, you can't rely on the unpack order then
[18:19] <hallyn> pitti: yeah but the libvirtd.service is in libvirt-daemon-system package;  libvirt-bin.servce is in libvirt-bin package
[18:19] <hallyn> so what to do?
[18:19] <pitti> oh
[18:20] <pitti> hallyn: does one depend on the other?
[18:20] <hallyn> yeah libvirt-bin depends on libvirt-daemon-system
[18:22] <hallyn> so, maybe it would be easier to keep libvirt-bin.service for now, and do that switch after we've gotten rid of the libvirt-bin package altogether?
[18:22] <hallyn> so the move is at least happening within one pkg?
[18:22] <pitti> hallyn: so you need to do it in the package which originally shipped the old name
[18:22] <hallyn> ok,
[18:22] <pitti> if that was libvirt-bin, its preinst needs to do that, yes
[18:22] <pitti> even if it's empty afterwards
[18:23] <hallyn> i can do that.  bu ti'm still worried about the file being gone,
[18:23] <pitti> but you need that empty package for upgrades anyway
[18:23] <hallyn> because at postinst time for libvirt-daemon-ssytem it still says that libvirt-bin.service exists
[18:23] <hallyn> so is that getting cached under /var/lib somewhere during package remove/unpack?
[18:26] <hallyn> all right so lemme try with that in libvirt-bin.preinst.  thx
[18:26] <pitti> hallyn: dependencies get configured before postinst runs; deb contents does not get cached, now
[18:26] <pitti> (sorry, distracted, sprint)
[18:27] <hallyn> pitti: hold on.  there is existing code there from debian's transition.  i was misreading that and thinking it was my code from an earlier upstart->systemd xition
[18:28] <hallyn> so actually mayb ei just need to tweak the version numbers there and it'll just work
[18:28] <hallyn> pitti: in particular, http://paste.ubuntu.com/16223586/
[18:28] <hallyn> does that look like it would work?
[18:29]  * hallyn tries
[18:31] <pitti> hallyn: that actually looks fairly good, yes
[18:31] <hallyn> cool let's see if it works
[18:31] <pitti> hallyn: it doesn't maintain admin changes, though
[18:32] <pitti> hallyn: i. e. if the admin manually disabled the service, it will restart after the upgrade
[18:32] <hallyn> hm
[18:32] <hallyn> and i can only check that from libvirt-bin.preinst?
[18:33] <hallyn> no, not if i use the deb-systemd helpers
[18:34] <hallyn> so to that hunk i could add a tmpfile created if the service is enabled, and only enable it by hand...
[18:34] <hallyn> pitti: by disabled you mean stopped or actually disabled so it won't start again?
[18:34] <pitti> hallyn: disabled (stopped is fine)
[18:36] <hallyn> sigh
[18:36] <hallyn> all right i'll test it both ways.  thx
[19:22] <hallyn> pitti: meh, that doesn't work. I still get http://paste.ubuntu.com/16224784/
[19:22] <hallyn> so i'll do it my way in libvirt-bin.preinst
[19:22] <hallyn> my way -> your way?  but not debian's way :)
[19:49] <doko> roaksoax, please could you have a look at https://launchpad.net/ubuntu/+source/virtualbox/5.0.20-dfsg-1/+build/9669239 ? currently blocking some transitions
[19:55] <roaksoax> doko: ???? I've never touched virtualbox i dont think ...
[19:56] <doko> ohh, looked at the wrong package
[19:58] <roaksoax> :)
[20:25] <cjwatson> doko: There is no current plan, nor am I even sure it's agreed that we will switch.
[20:26] <cjwatson> The way that ended up in Debian is significantly less convenient to deal with for no obvious advantage, although the delta is awkward.
[20:28] <doko> I should propose for debian policy not to modify dbgsym packages ...
[20:29] <pitti> cjwatson: we could make the delta a bit smaller by patching debhelper to name them .ddeb instead of .deb; in theory this should then not need LP changes, or am I missing something?
[20:31] <hallyn> pitti: nope, that (manual mv'ing in libvirt-bin.preinst) didn't work.  i'll use the deb-systemd-helper to disable and leave tmpfiles for postinst to know whether to reenable
[20:31] <hallyn> ugh
[20:33] <cjwatson> pitti: Not sure.  There's all the hairy stuff that arranges to control whether ddebs are built on an archive-by-archive basis
[20:33] <cjwatson> Build-Debug-Symbols etc.
[20:33] <pitti> cjwatson: oh, the parsing of /CurrentlyBuilding etc.
[20:38] <hallyn> oh great, this is helpful for testing:
[20:38] <hallyn> deb-systemd-helper is-enabled libvirt-bin.service
[20:38] <hallyn> /usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
[20:45]  * hallyn needs more info on deb-systemd-helper mask/unmask
[20:51] <doko> AlbertA: please could you have a look at https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1578381
[20:52] <AlbertA> doko: 0.21? shouldn't it be 0.22?
[20:54] <doko> AlbertA, there is no 0.22 in https://launchpad.net/ubuntu/+source/mir
[20:55] <AlbertA> camako: bregma: ^
[20:55] <AlbertA> doko: I thought the ci-train was supposed to release to the transitional overlay thingy
[20:56] <doko> AlbertA, it's my understanding that this is not yet in effect for yakkety
[20:56] <AlbertA> doko: in any case, the test failures look intermittent:
[20:56] <AlbertA> [ FAILED ] ClientLatency.throttled_input_rate_yields_lower_latency
[20:56] <AlbertA> I think that test will potentially fail if there's too much load on the build machines
[20:56] <doko> AlbertA, I can give them back and see what happens. can you save a copy of the build log locally?
[20:58] <AlbertA> if you re-run the builds it will most likely be ok
[21:41] <doko> AlbertA, give back succeeded. closing the issue. ta
[21:42] <AlbertA> doku: ack
[21:43] <camako> AlbertA, mir 0.22 is not in xenial either
[21:43] <camako> weird
[21:44] <camako> or meybe expected due to the overlay
[21:59] <roaksoax> 8
[22:08] <pitti> infinity: FYI, just committed bug 1577966, so happy proxying (if you run autopkgtest from git, like all the kool kids do :) )


[15:49] <chrisccoulson> Sigh, why the explosion of useless bug reports?
[15:49] <chrisccoulson> i wish bug reporters would read our bug reporting guidelines, like we ask them to :(
[17:46] <micahg> chrisccoulson: if I seem to have some crazy feedback with firefox-trunk (15), unity-panel-service, and hud-service is it worth debugging or should I just wait for 16 to see if it still happens?
[20:58] <micahg> hrm, we are getting a slew of bugs this time around
[21:18] <chrisccoulson> they're all non-bugs. just ignore them ;)
[21:18] <chrisccoulson> see my earlier comment in this channel :)
[21:18] <chrisccoulson> i think i'm just going to unsubscribe from firefox bugs ;)
[21:37] <micahg> chrisccoulson: can you please document why you're adding the libxml-simple-perl build dependency in the changelog?
[22:35] <alex_mayorga> Any plans to provide the PPA for Quetzal?


[06:29] <Saviq> Morn \o
[08:11] <RAOF> Today:
[08:11] <RAOF> * Factored out a bunch of CPU-rendering code duplicated across the various platforms
[08:11] <RAOF> * Fixed CI for the platform-API branch (on at least one of the platforms; full tests pending)
[08:11] <RAOF> * Tested on my weird hybrid desktop; looks like I'm generating buffers with the wrong stride sometimes, needs further investigation.
[15:57] <Saviq> Today:
[15:57] <Saviq> - got back into checkbox, realized it's stripping env so need to work on that next
[16:57] <alan_g[m]> Today:
[16:57] <alan_g[m]> * reviewed and commented on recent issue reports (#2952 & #2958)
[16:57] <alan_g[m]> * reworked spike of DnD implementation and discovered more corners to nail dowm