[02:25] <mwhudson> is there a thing that can show you which source packages build-depend on a particular package?
[02:25] <mwhudson> apt-cache rbuild-depends, except existing
[02:25] <jtaylor> reverse-depends -b, though it outputs binary packages
[02:26] <jtaylor> source you probably have to use grep-dctrl
[02:28] <mwhudson> jtaylor: good enough, thanks
[05:22] <Mirv> pitti`: thanks, I see you've updated cssutils which probably means powerpc caliber build would now succeed. trying.
[05:23] <Mirv> libre, even
[05:49] <pitti> Good morning
[06:03] <Tribaal> hi all! I'm super happy to see an update to chromium this morning :)
[06:03] <Tribaal> thanks for the hard work!
[07:46] <dholbach> good morning
[08:20] <LocutusOfBorg1> can anybody please merge filezilla? http://paste.ubuntu.com/8936186/
[08:20] <LocutusOfBorg1> I'm the previous uploader, should I open a bug?
[08:35] <pitti> ^ doing (but he's offline now)
[08:36] <pitti> nope, patch whitespace is totally garbled
[08:38] <pitti> wgrant: https://launchpadlibrarian.net/190079241/upload_6489523_log.txt → is there any way around this except introducing a package diff and updating the date?
[08:39] <infinity> pitti: Why would the *binary* packages have ancient timestamps? :/
[08:39] <infinity> pitti: Sound like someone's install method is "cp -a", which is insane.
[08:40] <pitti> I haven't checked yet, I just noticed this when cleaning up -proposed a bit
[08:46] <wgrant> pitti: That check cannot be overridden.
[08:47] <pitti> wgrant: I mean, why do we have it in the first place? being stricter than Debian means we have to carry around rather pointless deltas?
[08:48] <pitti> certainly the upstream build system does something funky there, but repacking the orig.tar.gz is painful
[08:48] <pitti> well, we could hack some "touch"es into debian/rules, but still painful
[08:49] <mvo> infinity: good morning, I prepared this apt upload I keep talking about for vivid in https://launchpad.net/~mvo/+archive/ubuntu/apt-vivid and I think its ready now (doing some testing still but all is looking good afaict). when is a good time for you for a upload ? in my evening?
[08:50] <mvo> infinity: https://launchpad.net/~mvo/+archive/ubuntu/apt-vivid/+sourcepub/4554564/+listing-archive-extra <- long changelog, this is why I'm a bit more cautious than usually
[08:50] <wgrant> pitti: I'm not sure why it's there, but it's been there forever.
[08:51] <pitti> wgrant: ah, so just the first time we hit this then, apparently
[08:53] <wgrant> It shows up occasionally, and usually indicates upstream is broken.
[08:56] <infinity> mvo: Does this still have the _apt user?
[08:56] <mvo> infinity: yeah, getting rid of this is a bit more work
[08:56] <infinity> :(
[08:56] <pitti> xnox: do you still plan on doing your merges, or should we take over? (I could do e. g. simplejson or at)
[08:57] <infinity> mvo: How much more work? :)
[08:57] <infinity>   * Ensure /etc/apt/auth.conf has _apt:root owner
[08:57] <infinity> mvo: I really don't like stuff like that, if we can void it.
[08:57] <infinity> It's gross.
[08:58] <infinity> Though, in a proper privsep world, that means root should be reading that and passing it to the backends via IPC.
[08:58] <infinity> mvo: Privsep that lets non-root processes read config files isn't really privsep.
[09:05] <mvo> infinity: yeah, its not the end of the road yet
[09:06] <infinity> mvo: I'd almost be inclined to say just tear out the new user creation and chmodding and let the backends run as root until the feature's complete, but that's just me.
[09:06] <infinity> mvo: Cause removing users and chmodding back as an upgrade path is a pain.
[09:07] <infinity> mvo: Assuming the goal is to have the backends run as nobody and never need to write to disk.
[09:07] <infinity> mvo: Though, I guess that might be tricky for the actual downloading bits.
[09:08]  * mvo nods and thinks about it
[09:08] <infinity> mvo: But, fundamentally, if I can screw with a backend enough to own the _apt user, then I can do anything that user can do, including reading private config files and poisoning the local cache.
[09:08] <infinity> mvo: Which seems not entirely ideal.
[09:09] <infinity> mvo: Sure, that's better than escalating to root, but most of what apt does is so close to being root anyway, that it's a pretty close hop away. :/
[09:11] <infinity> mvo: Also, minor nit about the current state of affairs if you wanted to ship it that way, making /etc/apt/auth.conf WRITEABLE by the _apt user is just wrong. :P
[09:11] <infinity> mvo: If you wanted to keep the user and let it be your reader of scary things, it should be in a group with read access, not the owner of the file.
[09:13] <mvo> infinity: *cough* that would be a bug then
[09:15] <mvo> infinity: so yeah, its pretty tricky to get it to a state that _apt can not do harm but posing the local cache should not be possible when we check the hashes indepdently, i.e. broken stuff will be detected. but yeah, the reading of config files needs to move into main apt and the method communication etc
[09:15] <mvo> infinity: unfortunately other tasks keep me quite busy I wish I could devote more time to finish this work
[09:18] <infinity> mvo: I'd probably just be inclined to ship it without the sandbox user set, and without the adduser and chown calls, so you don't have to undo it all later, but that's just me.
[09:18] <infinity> mvo: If you think this is a big enough win as-is, and you're prepared to deal with upgrade scenarios, meh.
[09:19] <mvo> infinity: right, thanks, let me ponder a bit about it but I think you have a valid point here
[09:40] <infinity> cjwatson: Do you remember how to reproduce the bug that unsubmitted-dlopen-static-crash.diff was meant to fix?
[09:44] <dholbach> @pilot in
[10:04] <cjwatson> infinity: Revert it, build an x86 phone image, try to run it in the emulator, watch it entirely fail to start unity8
[10:05] <cjwatson> (the nature of the beast is that I don't have a small test case)
[10:06] <infinity> cjwatson: Err, wrong patch. :)
[10:06] <infinity> cjwatson: I'm referring to the autoconf static dlopen segv thing we patched back in saucy.
[10:06] <infinity> cjwatson: Which I'm really not sure how to reproduce to know if it's been fixed better.
[10:07] <infinity> Because we cleverly never filed a proper bug for it or anything.
[10:07] <cjwatson> Oh.  Give me a few minutes not to be answering from my phone then ...
[10:07] <infinity> cjwatson: Heh, mostly a non-immediate-issue anyway, I was blaming a new testsuite failure on that patch, but reverting it made no difference.
[10:16] <mitya57> pitti: thanks for filing the bug, now we have this in #debian-python:
 [22:52] Does anyone still want to use lintian4python or should it be RMed?
 [23:30] Fixing #763206 aka #768988 will be your first task. :-)
[10:18]  * mitya57 uses lintian4python but doesn't speak Perl...
[10:19] <infinity> mitya57: Well, I just removed it from vivid, if you want to fix it and reupload, go nuts.
[10:19] <infinity> mitya57: Learning Perl isn't exactly rocket science if you know C.
[10:20] <infinity> mitya57: You just get to use all the characters on the top row of your keyboard for once.
[10:20] <infinity> ALL OF THEM.
[10:20] <mitya57> Well, I have a Compose key :D
[10:21] <mitya57> (And Shutdown)
[10:21] <seb128> does anyone know if vivid translations import is active/working?
[10:21] <seb128> dpm, pitti, wgrant, ^?
[10:22] <wgrant> seb128: vivid translations aren't happening yet. I hope to fix them in the next week or so.
[10:22] <seb128> wgrant, ok, thanks
[10:24] <wgrant> seb128: Anything in particular you're concerned about?
[10:25] <seb128> wgrant, no, I was wondering why https://translations.launchpad.net/ubuntu/vivid/+source/indicator-session is empty and https://translations.launchpad.net/ubuntu/vivid/+source/indicator-session/+imports is sitting on "approved" items but not importing those
[10:25] <seb128> wgrant, I was trying to verify a fix for a translation bug
[10:26] <seb128> wgrant, also I need https://translations.launchpad.net/ubuntu/vivid/+source/ubuntu-ui-extras/+imports to fix some touch non-translatable string issues
[10:26] <seb128> but I guess I'm just going to try to land that fix in rtm without testing on vivid first
[10:30] <wgrant> seb128: I hope to have it going soon. Just need to get enough off my plate that I can safely do it.
[10:30] <seb128> wgrant, ok, no worry, thanks for the status update
[10:31] <seb128> wgrant, I thought translations import would "just work" automatically for new series, I didn't know there was manual work involved
[10:31] <seb128> wgrant, keep the good work :-)
[10:31] <ogra_> ++
[10:31] <pitti> mitya57: ah, I don't care about lintian4python personally, it just holds back the new lintian
[10:32] <wgrant> seb128: It's still a separate manual process to get them going, and it's pretty reliable nowadays, but when it goes wrong you can usually say goodbye to a couple of days of useful work.
[10:32] <mitya57> pitti: I know, and also s/holds/held/ now
[10:33] <pitti> mitya57: oh, curious -- how did lintian get past this?
[10:35] <infinity> pitti: It got past it by me removing it. :P
[10:35] <infinity> https://launchpad.net/ubuntu/+source/lintian4python/0.28.4/+publishinghistory
[10:36] <pitti> hah
[10:36] <pitti> haha @ Allergy advice
[11:39] <LocutusOfBorg1> bdrung_work, I fixed the vlc master-daily build for trusty and utopic
[11:40] <LocutusOfBorg1> there is something that worries me now, vivid is failing because seems that the library has x11 linked https://code.launchpad.net/~videolan/+recipe/master-daily
[11:55] <pitti> LocutusOfBorg1: wb
[11:56] <pitti> LocutusOfBorg1: I wanted to upload your debdiff this morning, but it has totally garbled whitespace
[11:56] <pitti> LocutusOfBorg1: so better attach it to a bug, please
[12:54] <LocutusOfBorg1> LocutusOfBorg1> pitti, yes, I had already opened a bug :)
 seems somebody uploaded it
 dholbach, thanks :D
[13:00] <pitti> LocutusOfBorg1: ah, good
[13:04] <LocutusOfBorg1> (sorry for the double noise)
[13:29] <bdrung_work> LocutusOfBorg1, thanks
[13:32] <LocutusOfBorg1> thanks for what? I'm looking at the vivid build log, and I cannot find any clue, that plugin in the build log seems not built with X11 or xcb :s
[13:33] <LocutusOfBorg1> so for now I'm stuck :(
[13:33] <bdrung_work> for trusty and utopic
[13:33] <LocutusOfBorg1> oh... it was trivial, utopic was missing a b-d, and trusty I added the multimedia ppa for the new libsa
[13:34] <LocutusOfBorg1> s/libsa/libav
[13:34] <bdrung_work> i haven't found the time to even look at it
[13:34] <LocutusOfBorg1> I know, we are always overbusy, I'm having the same problem, this is why I'm giving up for now for vivid
[13:45] <ScottK> baloo-kf5 needs the libkf5filemetadata-dev minimum build-dep version bumped to to 5.1.1
[13:53] <dholbach> @pilot out
[14:05] <tedg> jodh, So rsalveti and I are discussing the behavior of a pulseaudio job in: https://code.launchpad.net/~ted/ubuntu-touch-session/indicator-sound-override/+merge/241300
[14:06] <tedg> jodh, It seems that what pulse does is that it does the forks, but then blocks until they write on a pipe.
[14:06] <tedg> jodh, Is Upstart just looking for the fork command, or for when the parent exits?
[14:08] <jodh> tedg: upstart counts the forks.
[14:10] <tedg> jodh, When does the post-start job run? When started is emitted or when the exec is complete?
[14:12] <jodh> tedg: it runs after exec and before started is emitted.
[14:13] <tedg> jodh, So if I add a post-start job, even /bin/true, it would wait until the parent exits before emitting started?
[14:20] <jodh> tedg: the flow is: main process (fork+exec), post-start (fork+exec), emit started.
[14:28] <tedg> jodh, So when I have the "expect daemon" stanza, does the main process component complete after the second fork() is called or when the initial process exits.
[14:37] <jodh> tedg: as mentioned, current upstart only counts forks. We do have a branch lingering around upstream that counts the exits (lp:~jamesodhunt/upstart/bug-530779), but that's unlikely to land now.
[14:45] <tedg> jodh, Okay, I understand, thanks!
[15:59] <tedg> stgraber, Saviq got some weird cgmanager errors in his log and then Unity couldn't connect to cgmanager, do they mean anything to you? http://pastebin.ubuntu.com/8942980/
[16:01] <stgraber> hallyn: ^
[16:14] <hallyn> tedg: possible to file a bug?
[16:21] <tedg> hallyn, Sure, but we're not sure how/what to file :-) we're using bug 1377332 right now.
[16:24] <hallyn> tedg: thanks, i'll look
[16:43] <LocutusOfBorg1> cjwatson, wonderful the plastimatch patch! you rock man!
[16:44] <LocutusOfBorg1> spoken too fast, there still are three tests failing in amd64 :(
[16:47] <cjwatson> LocutusOfBorg1: I reuploaded already
[16:47] <cjwatson> https://launchpad.net/ubuntu/+source/plastimatch/1.5.16+dfsg-1ubuntu2
[16:47] <LocutusOfBorg1> wonderful :)
[16:48] <cjwatson> reasonably sure this pile will migrate once that's done
[16:48] <LocutusOfBorg1> :)
[16:49] <cjwatson> then hopefully either vdr/imagemagick will migrate too or else it'll be clearer what's going on there
[16:51] <cjwatson> ah, it's blocked on the pyqt5 stuff that I believe Mirv is working on
[16:54] <pitti> kees, infinity, mdeslaur, slangasek, stgraber: anyone here today for TB, given memorial day?
[16:54] <mdeslaur> pitti: I'm here
[16:57] <kees> pitti: I'm here too
[16:57] <pitti> kees: ah, great; in theory you are chairing today
[16:59] <kees> pitti: yeah, we'll see if we have enough people :)
[17:00] <kees> infinity: you around for meeting?
[18:12] <cjwatson> ah, good, that's gdcm/hdf5/etc. migrated
[18:12] <cjwatson> gets it out of the way of imagemagick etc. once Mirv's done
[18:13]  * cjwatson EODs
[21:34] <hallyn> infinity: mwhudson:  ok, bug https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1389897 , i'm going to push that debdiff (in comment #10) to vivid?  any objections / new developments i've missed here?
[21:35] <mwhudson> hallyn: +1 from me
[21:35] <mwhudson> hallyn: i haven't built tested it on !amd664
[21:35] <mwhudson> wow good typing there michael
[21:37] <mdeslaur> hallyn: please don't SRU qemu yet, I have security updates that are building
[21:38] <mdeslaur> (in stable releases)
[21:38] <hallyn> mdeslaur: no, i was only going to push to vivid.
[21:38] <hallyn> mdeslaur: do you have fixes there?
[21:39] <hallyn> if so i'll happily wait
[21:39] <mdeslaur> hallyn: I'll have fixes, but not right now, so go ahead
[21:39] <hallyn> i'm only working on srus for libvirt
[21:39] <hallyn> ok, thx
[21:40] <hallyn> mdeslaur: btw, please do shout at me whe you do push to vivid, as i want to be sure to get everything into the debian git tree before i accidentally drop hcanges at next update/merge
[21:40] <hallyn> i do intend to merge next week into vivid
[21:40] <mdeslaur> hallyn: ok, sure
[21:40] <hallyn> (do it with rharper as a training execise)
[21:40] <hallyn> thanks
[21:54] <hallyn> mwhudson: but wait, i thought you'd tested it on ppc64el?
[21:54] <hallyn> time for me to find a porter box i guess :)
[21:54] <hallyn> or maybe i can nag smoser
[21:54] <mwhudson> hallyn: infinity did some ppc testing of the kvm wrapper bits
[21:55] <mwhudson> no package building afaik
[21:58] <hallyn> ok, thx, trying on the porter
[22:17] <smoser> hallyn, whats up?
[22:17] <smoser> i can get you a ppc64el system if you need.
[22:31] <hallyn> smoser: i'm trying the ppc64le porter box right now.  seems not too bad
[22:32] <smoser> ok.
[22:57] <hallyn> smoser: though it's taking forever,  if you wanted to grab the vivid qemu source and add the debdiff at http://people.canonical.com/~serge/qemu-8.debdiff and see if that builds there, that would rock
[22:57]  * hallyn will be afk for a bit, but bbl
[23:03] <hallyn> well build is *almost* done here.  looking good