[00:48] <hamiltont> cjwatson: FYI I'm going to move my kickseed changed from launchpad into the mailing list as you requested. Please disregard my launchpad code merge request - I'll close it down shortly
[10:39] <hyperair> did i declare the build-deps wrong, or is apt bugged?
[10:39] <hyperair> in banshee, that is
[10:39] <hyperair> libgpod-cil-dev (>= 0.8.2-7~), libgpod-cil-dev (<< 0.8.3-2) | libgpod-cil-dev (>= 0.8.3-4ubuntu3~)
[10:40] <hyperair> but when doing apt-get build-deps banshee, apt complains that libgpod-cil-dev is too new.
[10:44] <juliank> Wow that's a strange dependency.
[10:45] <juliank> hyperair: build-dep only chooses the first alternative IIRC
[10:46] <juliank> But really not entirely sure
[12:19] <hyperair> juliank: that seems like the wrong thing to do
[12:21] <juliank> hyperair: You might want to try with -o Debug::BuildDeps=true
[12:21] <juliank> and check what that says.
[12:22] <juliank> hyperair: build-dep does not use standard dependency solving algorithms. In any case, swapping the OR seems more coorrect.
[12:23] <juliank> or do you really want to prefer the older version?
[12:24] <hyperair> juliank: well, i just need to exclude a certain version.
[12:24] <juliank> in any case, tools should prefer the first alternative by definition, so putting the newer one there makes sense.
[12:24] <juliank> hyperair: or you just build-conflict with the broken version
[12:24] <hyperair> the problem was that i did a half-assed port of libgpod to gtk3 which i reverted.
[12:25] <hyperair> oh yeah, i forgot about that
[12:25] <juliank> A build-conflict is easier to handle here than an ORed build-dependency from APT's perspective
[12:27] <hyperair> alright
[12:28]  * ari-tczew notices Mom is broken again :-/
[12:28] <juliank> hyperair: If you want more detailed information about this, you need to ask DonKult in #debian-apt on OFTC, or wait for mvo to turn up tomorrow
[12:29] <juliank> They know more than me about APT itself.
[12:29] <hyperair> alright, thanks
[12:30] <hyperair> for the time being i've filed a bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1335614
[12:30] <hyperair> i'll just workaround it with build-conflicts
[12:33] <juliank> Some build servers (I believe the  Debian buildds) only consider the first alternative too, AFAIK
[12:34] <juliank> But it's been some time since I looked at this.
[12:34] <juliank> It creates more predictable builds to ignore alternatives.
[12:42] <juliank> Does anyone have contacts at Lenovo I could ask about documentation about the charging control ACPI interface, possibly under NDA?
[12:46] <hyperair> oh ffs, build-conflicts doesn't work unless i articulate it into = dependencies
[12:47] <hyperair> so i need one libgpod-cil-dev (= ...) for every version i need to conflict on
[12:47] <hyperair> goddamnit, why not just use the same dependency resolution engine when it so clearly works?
[12:52] <juliank> hyperair: Ah, I thought you only had one broken version.
[12:52] <juliank> Sorry about that.
[12:53] <juliank> hyperair: Just try swapping the OR then and it should work fine for build-dep and automatic builds. People can still manually build if they have the old version installed
[12:54] <juliank> In fact, Ubuntu build servers do consider alternatives too IIRC.
[13:06] <hyperair> juliank: automatic builds seem to have worked fine though.
[13:06] <hyperair> it's just that apt-get build-dep fails
[13:06] <juliank> Yes, as said, launchpad considers alternatives. Debian infrastructure doesn't.
[13:07] <wgrant> Launchpad doesn't exactly consider alternatives.
[13:07] <wgrant> It always takes the package named in the first alternative, but then applies versioned constraints afterwards.
[13:07] <hyperair> i see
[13:08] <wgrant> So in this case it will work, as the two constraints refer to the same package. But in the general alternative case, the first one wins.
[13:10] <cjwatson> ari-tczew: Should be fixed shortly, thanks.  usbredir was busted.
[13:11] <cjwatson> wgrant: Well, it falls back to other alternatives if the package named in the first alternative doesn't exist, which isn't true in Debian.  (i.e. what's now sbuild --resolve-alternatives)
[13:13] <wgrant> Ah yes, true.
[13:13] <wgrant> But it has to not exist, not just be a bad version.
[13:13] <cjwatson> Right.
[17:38] <LocutusOfBorg1> Hi cjwatson, I'm not sure if I waited enough
[17:38] <LocutusOfBorg1> but will vtk automatically be sync'd or not?
[17:38] <LocutusOfBorg1> because your changes are in debian now, but the changelog is different...
[17:39] <LocutusOfBorg1> I wonder how the sync/merge works exactly
[17:50] <infinity> LocutusOfBorg1: Packages with 'ubuntu' in the version aren't automatically synced.
[17:51] <infinity> LocutusOfBorg1: Did a manual sync now, after verifying the diff.
[17:53]  * jtaylor wonders if his tcl patches still work
[17:54] <jtaylor> didn't verify the debian package :/
[17:54] <jtaylor> (in vtk)
[18:04] <jtaylor> neat they still seem to work
[19:12] <michagogo> !sru
[19:20] <michagogo> 19:12:12 <stgr aber (spaced to avoid possibly-unwanted ping)> that's something which needs discussion with the sru team
[19:21] <michagogo> How is such a discussion initiated?
[19:21]  * michagogo is trying to figure out how to move bug 1314615 forward...
[19:21] <michagogo> erm, I mean bug 1314616