[00:20] <robert_ancell> infinity, is clutter-gst-3.0 going to be promoted to main? The MIR is complete (bug 1466251) and totem is sitting in depwait (https://launchpad.net/ubuntu/+source/totem/)
[00:25] <infinity> robert_ancell: Sure.
[00:51] <robert_ancell> infinity, thanks
[01:38] <shadeslayer> doko: ping
[01:38] <shadeslayer> doko: is there a ETA for debian bug 787689
[03:45] <pitti> Good morning
[03:58] <saiarcot895> When running dpkg-buildpackage, is there any way to skip checking the files in the tarball with the files in the working directory?
[03:58] <saiarcot895> (Especially with large packages)
[04:32] <infinity> saiarcot895: How do you expect it to produce a diff or know if anything's changed if it doesn't?
[04:33] <infinity> saiarcot895: Unless you have no intention of building a source package, and you're just iterating binary test builds, then you want -b or -B (check the manpage to see the difference).
[04:33] <saiarcot895> infinity: The only changes I'm making are in the debian directory (and maybe adding a patch). Upstream sources themselves aren't being changed. I'm making a source-only package.
[05:47] <work_alkisg> tjaalton: good morning, may I ping you to approve this x11-utils SRU that's in the precise queue? https://bugs.launchpad.net/ubuntu/+source/x11-utils/+bug/1463663, https://launchpad.net/ubuntu/precise/+queue?queue_state=1, https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[06:05] <tjaalton> alkisg: sorry, midsummer here and i'm far from my desk :)
[06:05] <tjaalton> though when you step outside it feels like october..
[06:10] <alkisg> tjaalton: thank you, np, slangasek maybe you could do it as the backup SRU manager?
[06:42] <dholbach> good morning
[07:02] <seb128> hey dholbach
[07:03] <dholbach> hey seb128
[07:57] <seb128> cyphermox, hey, remember that nm-applet segfault you upstreamed a bit before vivid, there is a redhat bz pointing to this commit as fixing it, https://git.gnome.org/browse/network-manager-applet/commit/?id=98dc7a7657b2609fcac05134db99455a9de6610a
[07:57] <seb128> cyphermox, could you have a look and maybe test/backport the fix?
[09:04] <juliank> zyga: The PEP440 fix for python-apt is in wily now. I hope to get a 0.9.3.12 release out soon upstream (waiting from Debian stable release team ACK), then we can fix it in 0.9.3.12ubuntu1 for vivid. If that takes to long, we can also have a 0.9.3.11ubuntu1 before that.
[09:05]  * juliank only closed the other bug report as fixed and kept your bug report open, because he can't do release-specific things in the bug tracker
[09:21] <zyga> juliank: thanks, let's wait and see, for the immediate problem that we were facing the affected developers just applied the debdiff locally
[09:22]  * zyga wonders how to track a bug differently for different releases of ubuntu 
[09:23] <juliank> zyga: Oh, there's an option in launchpad for that if you have the right access level (I don't)
[09:24]  * zyga looks
[09:24] <juliank> zyga: See https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1132918, that has per release bug status
[09:25] <zyga> hmm
[09:25] <zyga> I wonder how one does that
[09:25] <zyga> I might just not have enough access
[09:25] <zyga> but that doesn't help to make the gui discoverable
[09:26] <juliank> Hmm, bdmurray should know, he filed that one above
[09:27] <zyga> yeah, I think I'd have to be a ubuntu-devel member or something
[09:27] <juliank> I wonder if this works for PPU too
[09:29] <zyga> juliank: ohhh, I would love that
[09:29] <zyga> that would actually allow me to work on maintaining the package I care about across ubuntu
[09:29] <zyga> mmm
[09:29] <juliank> It might also be a release managing thing, though
[09:29] <smb> pitti, Hi just noticed something odd on a Wily server VM and filed bug 1466790. Would that be more a systemd issue or ifupdown, you reckon?
[09:35] <LocutusOfBorg1> please can anybody sponsor the patch on bug 1297849?
[11:00] <pitti> smb: is this a fresh install? qemu/virtualbox etc? can you please check with "ip a" that there actually is an "eth0"?
[11:01] <smb> pitti, not fully fresh install but updated regularly. A second with ip a, but ifdown eth0 and ifup eth0 does work and also start the dhcllient
[11:03] <smb> pitti, So yes there is a eth0 and its KVM VM
[11:05] <smb> pitti, Also it somehow uses dhcp to get its address initially and is up and working. Just not running the dhclient which then fails to renew the lease
[14:33] <jamespage> doko, pitti: I've been scratching my head about what todo with junit4 in wily
[14:34] <jamespage> my only current feasible fix is to re-upload the previous 4.11 release as 4.12 - 4.12 drops ant build support upstream.
[15:10] <smoser> wgrant, https://bugs.launchpad.net/ubuntu/+source/cloud-utils/+bug/1285197 horay!
[15:13] <jamespage> meh - might has a slightly less nasty alternative
[15:41] <flexiondotorg> Anyone here who could do a little sponsoring for Ubuntu MATE please?
[16:50] <sladen> slangasek: apologies for the delay in replying
[16:51] <sladen> slangasek: it's often easier to get people talking by starting with topics that aren't like to be contraversial
[16:52] <sladen> slangasek: there is an update from mhall119 on the perception at http://irclogs.ubuntu.com/2015/06/18/%23ubuntu-meeting.html#t17:49
[16:53] <sladen> slangasek:I'm hopeful that it might be something that a personal on the techboard might be able to talk about with passion/enthusiasm/first-hand information
[17:46] <apostoj> hallyn: thanks for the reply. Sorry for just getting back to this. I'll just describe what I'm seeing and maybe someone can help:
[17:49] <apostoj> In /etc/network/if-up.d/upstart:37.  The comment in the all_interfaces_up function seems to indicate that a true value will be returned if the interfaces are found to be up...
[17:49] <apostoj> But the return values look swapped, zero will actually be returned if all are up
[17:50] <apostoj> This causes "static-network-up" to not be emitted. Boot then hangs until the failsafe Upstart job kicks in.
[18:04] <smoser> maybe a dumb question.
[18:04] <smoser> launched a wily instance. did 'apt-get install open-iscsi'.
[18:04] <smoser> that includes /usr/share/initramfs-tools/hooks/iscsi
[18:04] <smoser> initramfs did not get updated
[18:05] <smoser> shouldn't it?
[18:05] <infinity> smoser: Only if the postinst runs upadte-initramfs.  initramfs-tools doesn't have a watch trigger (though, maybe it should).
[18:06] <smoser> hm..
[18:07] <smoser> i guess one way or another .
[18:07] <infinity> smoser: apw and I have had long discussions about how much initramfs-tools triggering is suboptimal, we're working on improving life.
[18:07] <infinity> smoser: But yeah, as it stands, anything shipping hooks should be calling update-initramfs -u in postinst.
[18:08] <ogra_> hmm
[18:08] <infinity> And postrm.
[18:08] <ogra_> there useed to be a trigger in the past
[18:08] <infinity> ogra_: The trigger is on the binary.
[18:09] <infinity> ogra_: Not on the directories.
[18:09] <ogra_> ah, k
[18:09] <ogra_> i just remember i had to suppress it for some arm stuff in the past
[18:11] <smoser> "on the binary" ?
[18:11] <infinity> smoser: We trigger on calls to update-initramfs.
[18:11] <infinity> (And then attempt, poorly, to batch them, so you don't get 7 runs)
[18:11] <smoser> ah. ok. that makes sense.
[18:11] <smoser> and yeah, i agree on 'poorly'
[18:11] <smoser> :)
[18:11] <ogra_> yeah, ususally you end up with three then or some such :)
[18:12] <smoser> is that something you're hoping to fix in wily?
[18:12] <infinity> Well, part of the problem is that the kernel forcefully skips the trigger.
[18:12] <infinity> But it has to because the trigger is suboptimal.
[18:12] <smoser> silly kernel
[18:12] <infinity> We have this all specced out to fix it.
[18:12] <smoser> link ?
[18:12] <infinity> <a href=apw.brain#infinity.brain />
[18:13] <infinity> That implies by brain is a node of Andy's brain, but maybe that's not entirely untrue.
[18:13] <infinity> s/by/my/
[18:13] <smoser> hm... infinity.brain: no such file or directory
[18:13] <smoser> :-)
[18:13] <infinity> Don't start with me, or we'll have some CoC violations to deal with. ;)
[18:14]  * infinity shakes his fist.
[18:14] <smoser> thanks, infinity. i'll file a bug on openiscsi
[18:14] <infinity> smoser: But yeah, this is something we've dealt with in conversation and rehashed over and over until we're sure we're right, but it was pending a merge and some other bits, and you know how that goes.
[18:15] <smoser> yeah. do you want me to open a bug for you ?
[18:15] <smoser> so that you can at some later point fill it in with information ?
[18:15] <infinity> Nah, we're good.
[18:15] <infinity> I think Andy might have a bug already somewhere, but if not, we still know it needs fixing.
[18:17] <smoser> do you *mind* if i open a bug ?
[18:18] <infinity> You can if you want.
[18:18] <smoser> just so that at some later point, when someone asks "why did update-initramfs get called 17 times and take 3 minutes?" i can point them at that bug.
[18:18] <infinity> Sure.
[18:23] <hallyn> tych0: apostoj it's a shell script, return 0 means true :)
[18:23] <tych0> hallyn: ?
[18:23] <hallyn> sorry,
[18:24] <hallyn> your name wasn't supposed to be there :)
[18:24] <hallyn> just,
[18:24] <hallyn> apostoj: it's a shell script, return 0 means true :)
[18:24] <tych0> although i can use all the help with shell scripting i can get
[18:25] <hallyn> you're just a golang fanboy and that's that
[18:26] <infinity> hallyn: Harsh.
[18:27] <apostoj> hallyn: Ok that makes sense. But line 51 has "if all_interfaces_up ...", so if 0 would evaluate as false, right?
[18:30] <infinity> apostoj: 0 is always true in POSIX shell, !0 is false.
[18:32] <apostoj> Oh, I see. Thanks for the help.  :)
[18:33] <infinity> apostoj: If this confuses you, instead of cursing shell, you can trace this back to C, where "exit(0)" is the "I didn't have an error, yay." way to end a program.
[18:34] <infinity> apostoj: From there, it follows that shell must treat 0 as good and !0 as bad.
[18:35] <infinity> (since shell's entire raison d'etra for decades was to execute a bunch of C programs and operate on the returns)
[18:36] <infinity> s/d'etra/d'etre/
[18:37] <apostoj> Yes this makes sense now.
[18:38] <apostoj> Now that I think about it, all shell conditionals I have used were of the form [ -f $x ],  or maybe [ $x == $y ]. I need to work on my shell skills...
[18:39] <hallyn> (lots of places - like kernel source - also treat 0 as success in c fwiw.  you only need one success value, many error values :)
[18:39] <smoser> feel free to re-assign infinity https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1466965
[18:43] <infinity> apostoj: For the record "==" is a bashism, you want "=" up there. :)
[18:44] <infinity> hallyn: Well, the traditional Cism of "1 is success, everything else isn't" works fine too, except for the confusion between C and shell, since you're off-by-OMG-CONFUSED.
[18:52] <infinity> hallyn: The whole confusion could have been avoided in 1975 (or so), if they'd just matched 'if', 'return', and 'exit' to all use the same semantics.  But I'm fresh out of flux capacitors.
[18:52] <infinity> Though, apparently, I'm good on 80s references.
[18:57] <slangasek> sladen: Mark did raise the question on the TB of whether we would be willing to be a backup "change of venue" in case of a conflict of interest.  It was not represented as individual TB members standing in for individual CC members, as mhall119 says in that IRC log.  In any case, I don't feel that really answers the question I asked by email...
[18:59] <mhall119> slangasek: I thought that was mark's intention (individualls sitting in for other individuals), perhaps we should ask him for clarification on that point
[19:00] <hallyn> infinity: very good, the world needs more nostalgia :)
[19:08] <infinity> mhall119: Sitting in for individuals who choose to recuse themselves makes no sense, IMO.
[19:08] <infinity> mhall119: Since if one person recuses themselves, you guys can still vote without a standin.
[19:08] <infinity> mhall119: And, arguably, someone who is self-aware enough to recuse themselves is the least of your problems in a conflict of interest.
[19:08] <infinity> mhall119: As I read the thread, it was if the CC as a whole (or in large part) has a conflict of interest with the case at hand, another body should be brought in.
[19:10] <mhall119> infinity: makes sense, I just wanted to make sure that is what Mark had in mind
[19:12] <infinity> mhall119: I think that's the only way to read his mail, based on him already mentioning that individuals recusing themselves works today, but systemic conflict doesn't.
[19:12] <infinity> mhall119: I guess one could read that "if 3 people recuse, you need 3 standins", but I think if it's that systemic, you need an outside body, not fill-ins.  YMMV, etc.
[19:18] <sladen> slangasek: well, the 10 lines above are probably an even more useful result!
[22:35] <shadeslayer> is there a dh var for figuring out what the build dir is