=== Ursinha-afk is now known as Ursinha
[04:35] <tjaalton> apparently :)
[05:57] <tjaalton> so, the libav/samba migration is blocked by libewf breaking the build of guymager
[05:58] <tjaalton> the version from experimental fails as well
[05:58] <tjaalton> no updates upstream
[06:07] <tjaalton> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713711
[06:07] <ubot2> Debian bug 713711 in src:guymager "guymager: FTBFS: libewf.h:35:21: fatal error: libbfio.h: No such file or directory" [Serious,Open]
[06:13] <tjaalton> i'll try building libewf with the old api
[06:18] <tjaalton> no dice
[06:34] <tjaalton> so, remove guymager until it's fixe?
[06:34] <tjaalton> +d
[10:06] <jpds> Could somebody poke netcfg into precise-proposed?
[10:09] <jpds> I've already verified that it fixes the problem locally.
[10:21] <xnox> tjaalton: remove guymager, or demote it to -proposed (move source & binaries into -proposed, such that it's still in the archive, but no longer blocks migrations)
[10:22] <infinity> xnox: I've been keeping an eye on that.
[10:22] <tjaalton> xnox: yeah
[10:23] <tjaalton> uploaded rebuilds of simgear & osgearth
[10:23] <tjaalton> now the list is down to libewf/libfreenect/xmount/sleuthkit
[10:23] <xnox> infinity: the next step in libav saga is to build openscenegraph against GLES on armhf, as it's very sad to be GL miss-aligned with Qt.
[10:24] <tjaalton> indeed
[10:24] <infinity> xnox: Why should that matter?  It wasn't build on armhf before.
[10:24] <infinity> (I mean, I'm all for fixing bugs along the way, but openscenegraph/armhf shouldn't be blocking the migration)
[10:25] <xnox> tjaalton: also note that new libav, drops "ffmpeg" package altogether and one is suppose to use libav-utils or some-such. That means anything depends or rdepends on ffmpeg needs changes to use libav-utils instead.
[10:25] <xnox> infinity: oh, ok. i somehow was under impression that it did build in the past.
[10:26]  * infinity notes there is no "libav-utils" package...
[10:26] <tjaalton> -tools
[10:26] <xnox> well whatever it's called =)
[10:27] <xnox> infinity: in bug #1253071 i've picked up 7 packages that were removed from testing for libav migration in debian.
[10:27] <ubot2> Launchpad bug 1253071 in zoneminder (Ubuntu) "demote to proposed for libav transition (removed from testing in Debian)" [Undecided,New] https://launchpad.net/bugs/1253071
[10:27] <xnox> we do have a few more (-0ubuntuX versions)
[10:28] <infinity> This is where I wish britney blocks could take a version.
[10:29] <infinity> (essentially, to simulate an RC bug)
[10:29] <xnox> infinity: well we do have blocking transition bug tag.
[10:29] <infinity> Because if I demote these before the transition is done, they'll migrate back in, rather than the transition doing so. :P
[10:29] <infinity> xnox: Yeah, I don't like using bugs for this, even though Colin did go and do that work.
[10:29]  * infinity shrugs.
[10:31] <infinity> I guess we could just add the tag to this meta-bug here, and I can not close the tasks when I demote.
[10:31] <xnox> infinity: yeap. that's what I did. (added tag with a comment)
[10:31] <infinity> Then close the bugs out when the transition is done, since they'll be blocked by deps at that point.
[10:32] <xnox> infinity: i will.
[10:34] <Laney> Could someone remove evolution-mapi from trusty-release please?
[10:35] <Laney> It got caught up with openchange
[10:35] <infinity> "got caught up with"?
[10:36] <tjaalton> xnox: hmm, should libav-tools provide ffmpeg?
[10:36] <infinity> Laney: You might need to expand your request here.  There's already an evolution-mapi in trusty-proposed, what's the rationale for trying to break the one in -release before that migrates?
[10:36] <xnox> tjaalton: no, because the command line name is different =/ i do think that libav-tools should ship ffmpeg symlink and do "profices: ffmpeg" it would make the world a better place.
[10:37] <tjaalton> yeah
[10:37] <seb128> infinity, we don't want to lock the openchange and evolution-data-server transitions together
[10:37] <Laney> infinity: That one won't migrate until openchange is done
[10:37] <seb128> infinity, evolution-mapi is involved in both
[10:37] <Laney> Would rather let evolution & friends through and then mapi can return in a little while once whoever has finished the openchange transition
[10:37] <seb128> what Laney says ;-)
[10:38] <xnox> i think you want to demote it to -proposed =)
[10:38] <infinity> And when I break the news that evolution appears to be tied up in libav and samba? :P
[10:38] <infinity> xnox: Can't demote, there's already an upload in proposed to transition it.
[10:38] <xnox> =(
[10:39] <seb128> infinity, you mean person!
[10:39] <seb128> samba is through exchange or something?
[10:39] <seb128> how come libav?
[10:39] <infinity> No idea.  Don't feel like unwinding it right now, but it clearly is.
[10:40] <seb128> shrug
[10:40] <Laney> Is it?
[10:40] <infinity> I'm pretty confused by why you care about this openchange transition, though.  It has, uhm, 1 rdep.  Which is evolution-mapi.  Which is transitioned.
[10:40] <infinity> That's not much of a "transition".
[10:41] <tjaalton> it's one of the rdepends blocked by either libewf or libav that samba needs, which then block openchange & sssd
[10:41] <seb128> infinity, I wonder if that's the one that makes us get samba in the mix :p
[10:41] <infinity> Anyhow, patience or help are both better than people trying to game the system to get their pet uploads through.
[10:42] <seb128> it's not really gaming anything
[10:42] <seb128> it's just that it makes sense to transition chunks when we can
[10:42] <infinity> By removing packages? :)
[10:42] <infinity> That's not, strictly speaking, transitioning.
[10:42] <seb128> drop the "s" there :p
[10:43] <infinity> Not if it's a package we intend to keep.  Cause now you need to keep tabs on it to make sure it gets back in.
[10:43] <infinity> So, your transition isn't done.
[10:43] <infinity> Anyhow.  There's no reason I see to do this.  The current transitions aren't breaking britney's logic or anything.  They're just not done.
[10:44] <seb128> right, keeping stuff in proposed for weeks and increasing the stack of things sitting in proposed can get in the way or getting work done/stuff landing though
[10:44] <seb128> but agreed, better if we can finish the samba&co transitions this week
[10:44] <seb128> is that likely to happen?
[10:44] <infinity> Seems plausible that we can polish off libav in pretty short order.
[10:44] <infinity> Which will make everything else fall out.
[10:45] <seb128> great
[10:45] <seb128> thanks
[10:45] <Laney> Including evolution-mapi.
[10:45] <infinity> Right.
[10:49] <xnox> Laney: is gstreamer 1.0 transition done? can we remove gstreamer0.10-ffmpeg?
[10:49] <Laney> So as it's going to be fixed anyway, I don't understand why it's a particular problem to cut off a part of the transition. But whatever.
[10:50] <Laney> xnox: doesn't it have rdeps?
[10:51] <Laney> * gallery-app [amd64 armhf i386]  (for gstreamer0.10-ffmpeg)
[10:51] <Laney> !!!
[10:51] <infinity> Laney: Stop viewing it from the unique snowflake position, and look at it if every upload made had a rider attached that said "Oh, and please delete this package too, it'll get fixed later, so it's all good".
[10:51] <Laney> If a fix weren't known I'd agree, but this package is already fixed and we know how to make it transition
[10:52] <infinity> While I hear arguments like "wouldn't it be nice to do the transition in chunks", what I'm actually hearing is "wouldn't it be nice to get evolution in", and you're not exactly the only people who want a package in, and where it could be fixed by removing another package or two.
[10:52] <xnox> Laney: ph =) gallery-app..... hm. is there a gstreamer1.0-ffmpeg? I don't see one in the archive.
[10:52] <xnox> (or rather gstreamer1.0-libav)
[10:52] <Laney> yes
[10:52] <Laney> you guessed the package name
[10:52] <xnox> excellent. so those rdeps should be transitioned to that one then.
[10:52] <xnox> =)
[10:53] <seb128> infinity, I'm not sure to be constructive to say "one person is blocked so we should block everybody else"
[10:54] <seb128> infinity, I would think that it's better to unblock as many people as we can so those can go on with their work
[10:54] <cjwatson> We have similar goals and different approaches
[10:54] <infinity> Or people could help with transitions instead of arguing on IRC about why they shouldn't have to.
[10:54] <cjwatson> The entire point of the +1 maintenance team is to unblock people as much as possible ...
[10:54] <seb128> infinity, sure some people have some special interest, that's fine, why should we block touch work to land because some libav universe rdepends didn't get transitionned yet?
[10:55] <cjwatson> (for instance)
[10:55] <Laney> Oh I'm not making an argument like that
[10:55] <infinity> seb128: We're not blocking anything from landing.  Just from migrating to -release.
[10:55] <seb128> cjwatson, well, sometimes transitions are not easy and take some time, I agree with the goal, it doesn't mean we should get things through in chunck when we can
[10:55] <Laney> My whole point in this case is that the package is transitioned already
[10:55] <Laney> It's removing an entanglement, nothing else
[10:55] <cjwatson> The experience of users of the archive is better if transitions are maximally completed
[10:56] <Laney> (well, and the package from the release pocket, obviously :P)
[10:56] <infinity> But hey, that goes back to a much older argument, where people seem to think they can't work until their previous work is in the release pocket or an "image".
[10:56] <seb128> sure, they are better
[10:56] <cjwatson> guymager, though; that's a hard one, I'm inclined to agree with xnox that it should be demoted since that was sitting around for a large chunk of last cycle and resisted multiple attempts to fix it
[10:56] <infinity> No one's actually being blocked from working here.
[10:56] <infinity> cjwatson: guymager needs to go, yes.  That's a different story entirely.
[10:57] <cjwatson> Let me attack a few of those and see if the transition falls into more pieces from that
[10:57] <infinity> cjwatson: If you want.  I was about to look at it all, given context and bug #1253071
[10:57] <ubot2> Launchpad bug 1253071 in zoneminder (Ubuntu) "block migration & demote to proposed for libav transition (removed from testing in Debian)" [Undecided,New] https://launchpad.net/bugs/1253071
[10:57] <cjwatson> infinity: OK, fair enough
[10:58] <cjwatson> All yours
[10:58] <infinity> If any of these have rdeps, though (*cough*gallery-app*cough*), this gets messy.
[10:58] <xnox> infinity: i am fixing that....
[10:58] <seb128> infinity, not yet, I just disagree on the statement that it's wrong on principle to kick out a non essential package to allow to unblock a transition
[10:58] <infinity> xnox: You're porting gallery-app to gst1.0-libav?
[10:59] <cjwatson> It's not wrong on principle, and we do it, but it requires careful consideration rather than it being the first resort.
[10:59] <xnox> infinity: hm, not yet, maybe don't demote that one for now.
[10:59] <infinity> seb128: Everyone's definition of non-essential is different.  It's absolutely wrong in principle to sacrifice random packages, it's a reasonable EXCEPTION to do it when other options seem unavailable.
[10:59] <xnox> Laney: are there raisins why gallery-app is not on gst1.0 yet?
[11:00] <Laney> Don't ask me
[11:00] <infinity> cjwatson: I like how we made seemingly opposing statements and said the same thing.  Bravo.
[11:00] <cjwatson> Heh, yeah
[11:00] <cjwatson> But yeah, seb128, you need to be careful about what arguments you're making because there are archive admins who'd consider touch non-essential.
[11:00] <cjwatson> So I don't think you want to set that precedent.
[11:00] <seb128> cjwatson, infinity: right, I agree with that, I think in this case dropping evolution-mapi temporary if needed would be an ok compromise
[11:00] <xnox> bug
[11:01] <xnox> bug #1221968
[11:01] <ubot2> Launchpad bug 1221968 in gallery-app (Ubuntu) "GStreamer 1.0 port of video thumbnailing" [Critical,In progress] https://launchpad.net/bugs/1221968
[11:02] <Laney> Please try not to assume bad faith on my part.
[11:03] <xnox> Laney: looks like there is a bug & branch in progress =) life is good.
[11:03] <seb128> cjwatson, right, I was listing touch randomly, I can as well say desktop work ... but I think some of us have a different personal opinion/cursor on what should be the focus (e.g on whether it's right that packages used by 0.01% of users can slow down work that benefit 40% of users))... but that's not new and not something we are going to agree on, so let's not discuss it more
[11:03] <Laney> xnox: Indeed, might take a while though
[11:04] <cjwatson> My entire position is that I want to take approaches that don't involve ever having the argument about whether something is 0.01% or not :-)
[11:04] <doko> now there are teams who don't send people for +1 maintenance ...
[11:04] <cjwatson> Because that argument is boring and nonproductive
[11:04] <infinity> cjwatson: As opposed to all the exciting and productive arguing we do?
[11:04] <cjwatson> Totally
[11:04] <seb128> sorry about that, you are right
[11:04]  * seb128 goes back to work
[11:05] <Laney> You'll note that I didn't make that argument, and indeed I've spoken against it in the past
[11:05] <Laney> Not going to convince anyone though, so yeah.
[11:05] <seb128> cjwatson, and yeah, in an ideal world I agree with you, in practice we end up with delays (even if it's not the end of the world I agree)
[11:05] <infinity> Right, let's all sit down to a virtual beer, resolve the libav transition, and pretend no one argued about evolution cause it'll migrate anyway. :P
[11:05] <seb128> Laney, don't worry, I don't think anyone put words in your mouth there
[11:06] <seb128> Laney, I'm the one doing that argument ;-)
[11:06] <seb128> infinity, sounds like a plan ;-)
[11:06] <Laney> seb128: Right, I think I was making a different argument to you.
[11:06] <Laney> carry on people
[11:06] <seb128> Laney, right, sorry for hijacking yours with mine :p
[16:51] <rtg> infinity, please drop kick precise linux-firmware into existence.
[16:54] <infinity> rtg: Looking.
[16:55] <rtg> infinity, just uploaded one, but I noticed a version is stalled in proposed.
[16:55] <infinity> rtg: The one in proposed never got anyone verifying the one bug...
[16:56] <rtg> yeah the HWE guys are sometimes not good about that. (or maybe I forgot to subscribe the SRU team)
[16:57] <rtg> nope, looks I did the right thing
[16:58] <infinity> rtg: Erm, this new one.  Did you mean to have the patch there as well as the files it creates?
[16:58] <rtg> shit
[16:58] <infinity> I'll take that as a no? :)
[16:58] <rtg> infinity, reject and I'll do a better clean
[16:59] <rtg> doh! what a dufus
[17:00] <infinity> rtg: Anyhow, after you clean it up, if you want to reupload with dpkg-genchanges -v1.79.7 I'll just accept it over the current one, and you can get both bugs verified.
[17:00] <infinity> (You'll want a -S on that too)
[17:01] <rtg> infinity, uploaded. should appear in a sec.
[17:02] <infinity> Holy crap, someone just submitted a patch to fix libglib-object-introspection-perl on big-endian arches.  I didn't expect that to happen in my lifetime.
[17:03] <infinity> cjwatson: My GTalk plugin is hating me something fierce right now and crashing in a loop.  I might need to reboot or something equally windowsish before the Release session in 2m.
[17:03] <infinity> slangasek / stgraber: ^-- Whoever was planning to attend that.
[17:03] <rtg> infinity, it the rick spencer show for the next hour
[17:03] <cjwatson> yeah, you have an hour
[17:03] <cjwatson> libglib-object-introspection-perl> blimey
[17:03] <infinity> cjwatson: Oh, I missed the hour in between.
[17:04] <infinity> Shiny.
[17:04] <rtg> yeah, that caught me yesterday
[17:17] <rtg> infinity, thanks
[17:17] <infinity> rtg: de rien
[17:58] <slangasek> infinity: how's your gtalk plugin?  Also, please join #ubuntu-uds-core-2
[17:58] <infinity> slangasek: It's crap, but we'll see how it survives.  Also multitasking a bit.
[17:58] <infinity> (Which will make it worse, whee)
[22:05] <rtg> infinity, linux_3.12.0-4.10 et al is in the pipe
[22:38] <bdmurray> slangasek: is it just me or does SRU'ing duplicity for Lucid seem like a waste of time?
[23:20] <slangasek> bdmurray: hum, yeah, I would reject that for lucid unless there's some critical dataloss bug