=== Ursinha-afk is now known as Ursinha
=== doko_ is now known as doko
[11:04]  * ogra_ fires off a build with "ARCHES=i386 CDIMAGE_NOPUBLISH=1 for-project ubuntu-touch cron.daily-preinstalled --live" ... please ignore any build failurme mails for this 
[11:05] <ogra_> curious how far it gets :)
[11:12] <cjwatson> If you use DEBUG=1 instead then it will dump everything to your console and won't send mail
[11:12] <cjwatson> (For next time)
[11:22] <ogra_> cjwatson, ah, i knew i had forgotten something
[11:23] <ogra_> how did i know that all this diversion madness would bite us some day :P
[11:26] <xnox> cjwatson: infinity: in build.opensuse.org there is a feature to branch full archive, do a rebuild, merge back all binary builds. The 300 buildds help there. And then merge back. that way one can do large binary transitions quickly and in isolation. We really don't have such capacity, to have disposable non-virt PPAs with hundreds of throw away builds. It would make sense to have binNMUs in Launchpad, which is as lightweight as one can get for bulk
[11:26] <xnox> of transitions.
[11:27] <xnox> (re:  CI airline)
[11:28] <ogra_> xnox, well, doesnt pocket copying from PA to PPA (or to the archive) essentially give us binNMU ?
[11:29] <ogra_> *from PPA
[11:30] <xnox> ogra_: not really no. it does a rebuild, but it doesn't bump the version number on the binaries. One cannot have same version number, yet a new checksum on the *.deb. As packages will not be upgraded.
[11:31] <xnox> in debian there is a "+b$i" suffix added.
[11:31] <ogra_> ah
[11:31] <xnox> the pool/ is shared after all =)
[11:32] <xnox> if copy-package gained --suffix-version-number or some such, that would be sufficient.
[11:32] <xnox> (or rather mangle)
[11:35] <cjwatson> xnox: I don't need to be convinced about the utility of binNMUs, although I don't think I've managed to convince infinity yet.
[11:35] <cjwatson> I don't think it should be overloaded onto copyPackage etc. though.
[11:36] <xnox> sure, implementation can be a better one =)
[11:40] <xnox> infinity: i got convinced about binNMUs by Laney. In essence even today we have archive scew and thus we don't have one-to-one relationship between src-BinaryArchBuild. (it may FTBFS on armhf in one series, but succeed in next). Or retries succeed. With binNMUs it would be nice if we could keep each build-record/build-log and thus know how many times and on which builders a package was retried already (with or without version bumps)
[11:45] <xnox> we do binNMU already in a limited capacity (without version number bumps / when said version didn't manage to build on a given arch yet).
[11:49] <xnox> \o/
[15:55] <infinity> xnox: A build retry isn't a binNMU.  Wanting history for retries isn't the same as asking for icky version skews and the problems that come with that.
[15:57] <infinity> xnox: And I don't get your claiming that we don't have a 1:1 rel between source and binary.  We absolutely do.  Fail-and-then-succeed is still only one binary.  Maybe just not in the release you wanted it. :P
[15:57] <xnox> infinity: in my world binNMU creates a source record with bumped version & rebuilds across all arches. Cause otherwise it screws one over with version numbers across different arches & breaks multi-arch.
[15:58] <infinity> xnox: Okay, that's not a binNMU, that's an automated sourceful rebuild, and I'd be all for THAT.
[15:59] <infinity> xnox: Basically just automating what dch -R does, allowing people to edit the changelog (as Debian binNMUs do), and doing the sign/upload from a host in the DC instead of locally, so it doesn't take someone on dialup 5 days to rebuild openoffice.
[15:59] <infinity> xnox: Totally cool with that concept.  Not cool with doing it per-arch, which is what a "binNMU" is to most people.
[15:59] <xnox> infinity: well =) ok, it's like a 1:1 timing subject to a time component =) like integration, which adds an unknown constant value.
[16:00] <cjwatson> I still prefer binNMUs; the problems with them are eminently solvable, considering that Debian's doing them
[16:00] <stgraber> infinity: well, unless it's a massive native package, you don't need to re-upload the orig tarball for a rebuild, so it's usually not that big (well, a lot of people seem to forget that you don't have to bundle the orig if it's already in the archive...)
[16:00] <cjwatson> And I don't think the problems are particularly bad
[16:00]  * xnox s/timing/mapping/
[16:00] <infinity> cjwatson: No one's solved the multiarch skew issue.  And, frankly, we're not so low on resources that I care.  The only advantage binNMUs bring is less pressure on the buildd network.
[16:01] <cjwatson> Also not breaking TIL on merges
[16:01] <infinity> stgraber: Yeah, I'm fine with the status quo.  But I can much more readily get behind "automated sourceful rebuilds" than "automated binary version bumps".
[16:01] <cjwatson> Speaking as somebody who's TIL on a bunch of stuff I don't care about due to doing lots of rebuild-only uploads, this is an issue close to my heart
[16:01] <cjwatson> And the multiarch skew issue was solved in Debian
[16:02] <cjwatson> OK, worked around, if you care about the distinction
[16:02] <infinity> cjwatson: Okay, yeah, there's that, I have a ton of rebuild TIL too.  But I'm not sure per-arch binNMU falls out of wanting to fix that.
[16:02] <infinity> cjwatson: When was M-A skew fixed?
[16:02] <infinity> cjwatson: Or do you mean just by not amending the changelog?
[16:02] <xnox> infinity: cjwatson: imho, M-a skew of binnmus, should be solved on dpkg side. It should imho ignore version differences across arches (especially no-change binNMU version differences). E.g.  lib* package which only has multiarched .so files in multiarch locations, should be co-installable despite that usr/share/doc/changelog.Debian.gz is different.
[16:03] <cjwatson> sbuild now puts the binNMU entry into a separate per-arch "changelog" so they don't clash, IIRC
[16:03] <infinity> Erm, and does dpkg now let you install foo_1-2:arm64 and foo_1-2+b1:i386 together?
[16:03] <xnox> infinity: no, it doesn't at the moment.
[16:03] <cjwatson> Oh I see what you mean, no that still needs to be handled, indeed - the Debian release team just avoids doing such binNMUs
[16:03] <xnox> cjwatson: do you know if version skew is at all allowed in dpkg yet?
[16:03] <xnox> ack.
[16:04] <infinity> xnox: Version skew is intentionally not allowed.
[16:04] <cjwatson> But there are plenty of non-M-A:same packages where binNMUs are still useful
[16:04] <infinity> xnox: One could make an exception for binNMU versioning but that means dpkg becoming mre Debian aware than it should.
[16:04] <xnox> stgraber: well, one typically fetches the whole source package. If it was possible to just fetch .dsc & .debian.tar.gz and do a dpkg -R on it, that would be nice.
[16:04] <infinity> +b1 doesn't necessarily mean "hey, identical version, new build", except in Debian.
[16:04] <cjwatson> Or one could look at the Source field
[16:05] <xnox> stgraber: sure, one will not reupload the orig tarball, but one typically still needs to fetch it.
[16:05] <infinity> cjwatson: Right, that's probably more sane.
[16:06] <xnox> yeah, source-version enforcement would be nice. but anyway, i like the idea of "server-side-generated-dch-R style binNMUs"
[16:06] <cjwatson> The other advantage is that it would make new ports a bit less hair-raising
[16:06] <xnox> cjwatson: wouldn't that break if one doesn't have -src lines enabled?
[16:06] <cjwatson> xnox: No
[16:06] <xnox> ok.
[16:06] <infinity> cjwatson: Oh, you mean the option to rebuild the world?
[16:06] <cjwatson> If we get some vital bit of ABI wrong, we wouldn't have to reupload everything arch-dep ...
[16:06] <cjwatson> Right
[16:07] <infinity> cjwatson: William and I had been discussing using copy archive for initial bootstraps.
[16:07] <cjwatson> Even then we don't necessarily realise until later
[16:07] <cjwatson> cf. ARMvINSANITY
[16:07] <infinity> (And, to be fair, if we don't care if we have USERS of an arch, we can probably surgically remove it, dump it, and start over)
[16:07] <cjwatson> Yeah, but why do horrible things when we could do nice things
[16:08] <infinity> Well, if you're talking a broken ABI, there's often no nice upgrade anyway. :)
[16:08] <infinity> We did dump and rebuild hppa once for that reason.
[16:08] <cjwatson> The ARMv7 upgrade and the later ARMv5t downgrade in armel were examples that we really should not have had to do the way we did.
[16:09] <cjwatson> And dump/rebuild wouldn't have been appropriate there.
[16:09]  * xnox ponders how far up i386->i686 transition we are.
[16:09] <infinity> Absolutely not.  Agreed.
[16:10] <infinity> xnox: Far enough.  Also, doesn't really matter for 99.9% of the archive.
[16:10] <xnox> yeah, all important binaries have been re-uploaded many times over, since.
[16:11] <infinity> cjwatson: I dunno.  If we can make dpkg behave, and model it not entirely unpleasantly in LP, I might be sold.  But binNMUs as they exist today in Debian are, other than the TIL annoyance, worse by far than our sourceful rebuilds.
[16:11] <infinity> (Solvable problems, I agree, but problems that exist)
[16:11] <xnox> cjwatson: i didn't quite understand version skew solution: for two packages of different architecture, check that they come from the same source, and only then accept "+bN" differences between them on client/dpkg side?
[16:11] <infinity> xnox: I meant that it didn't matter even before they were reuploaded. :P
[16:11] <xnox> (if they are m-a:same)
[16:12] <infinity> xnox: Once they come from the same source version, you don't care about the binary version at all.
[16:12] <xnox> ah, ok.
[16:12] <infinity> xnox: In other worse, MA:same version checks should be against source-version, not binary-version.
[16:13] <cjwatson> Right, that's what I mean
[16:14] <cjwatson> And better than I could think of how to put it
[16:17] <infinity> Well, it would have to check source-name:source-version tuple, to be complete, as I could, for instance, upload eglibc 2.18-1 producing libc6 2.18-1 and glibc 2.18-1 producing libc6 2.18-2
[16:17] <infinity> (I wouldn't, as it's crazy, but there are no tooling or archive constraints preventing me from such madness)
[16:17] <cjwatson> Indeed
=== adam_g_afk is now known as adam_g
[16:19] <xnox> i didn't know that "Source: srcname (srcver)" is encoded in the .debs them-self. =) i guess, that's because apt-cache binpackage, doesn't print (srcversion)
[16:21] <infinity> xnox: It's only encoded if there's a mismatch.
[16:21] <infinity> xnox: apt-cache show libgcc1, for instance.
[16:22] <infinity> (I'd argue that the "only if mismatch" behaviour is wrong, and long overdue for fixing, but that's the current state)
[16:22] <infinity> Would make automating various scanning tooling tons easier if Source: was always complete.
[16:23] <xnox> i see, yeah, this conditional behaviour of apt-cache is rather inconvenient. Also, i guess since on ubuntu there are no binNMUs the full version is printed rarely.
[16:24] <infinity> It's not apt-cache, it's dpkg-gencontrol, but yeah.
[16:24] <xnox> ... or one of the wrapped commands therein =)
[16:25] <infinity> xnox: I mean, it's not on the mirror side, it's in the deb itself.  dpkg-gencontrol only generates the Source field if source and binary name don't match, and only adds (version) if the versions don't match.
[16:25] <infinity> So, when you lack a Source field, you assume that Package: and Version: match the source.
[16:25]  * xnox ponders if there will be the "ultimate wrapper" that wrapps: all apt*, dpkg*, *debuild* tools =))))
[16:25] <cjwatson> wajig was trying to be that
[16:25] <cjwatson> I never really got on with it
[16:26] <infinity> Maybe this made sense back in the days when people thought saving a few bytes here and there was admirable, but it's mostly just confusing.
[16:26] <xnox> cjwatson: =)))))) was there a wajig-ng re-write in python as well?! =)
[16:27] <cjwatson> it's been in python since 2001 ...
[16:32] <xnox> ok.
[17:29] <cyphermox> xnox: so, removing kmediafactory and kx11grab?
[17:32] <xnox> cyphermox: yeap, removal request at https://bugs.launchpad.net/ubuntu/+source/kmediafactory/+bug/1254011 should now confirm / subscribe ubuntu-archive to it.
[17:32] <ubot2> Launchpad bug 1254011 in libomxil-components (Ubuntu) "remove from ubuntu archive - never in debian, no upstream ports to libav9 / dead upstream" [Undecided,New]
[17:33] <cyphermox> ack
=== gaughen is now known as gaughen_
=== gaughen_ is now known as gaughen
[19:48] <stgraber> infinity: can you bump this one? https://launchpad.net/ubuntu/+source/android/20131125-1710-0ubuntu1/+build/5267470
[19:49] <stgraber> the builders seem slightly busy with all those kde packages ;)
[19:50] <infinity> stgraber: Done.
[19:50] <stgraber> thanks