=== Ursinha-afk is now known as Ursinha
=== doko_ is now known as doko
* 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:04
ogra_curious how far it gets :)11:05
cjwatsonIf you use DEBUG=1 instead then it will dump everything to your console and won't send mail11:12
cjwatson(For next time)11:12
ogra_cjwatson, ah, i knew i had forgotten something11:22
ogra_how did i know that all this diversion madness would bite us some day :P11:23
xnoxcjwatson: 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 bulk11:26
xnoxof transitions.11:26
xnox(re:  CI airline)11:27
ogra_xnox, well, doesnt pocket copying from PA to PPA (or to the archive) essentially give us binNMU ?11:28
ogra_*from PPA11:29
xnoxogra_: 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:30
xnoxin debian there is a "+b$i" suffix added.11:31
xnoxthe pool/ is shared after all =)11:31
xnoxif copy-package gained --suffix-version-number or some such, that would be sufficient.11:32
xnox(or rather mangle)11:32
cjwatsonxnox: 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
cjwatsonI don't think it should be overloaded onto copyPackage etc. though.11:35
xnoxsure, implementation can be a better one =)11:36
xnoxinfinity: 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:40
xnoxwe 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:45
infinityxnox: 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:55
infinityxnox: 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. :P15:57
xnoxinfinity: 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:57
infinityxnox: Okay, that's not a binNMU, that's an automated sourceful rebuild, and I'd be all for THAT.15:58
infinityxnox: 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
infinityxnox: Totally cool with that concept.  Not cool with doing it per-arch, which is what a "binNMU" is to most people.15:59
xnoxinfinity: well =) ok, it's like a 1:1 timing subject to a time component =) like integration, which adds an unknown constant value.15:59
cjwatsonI still prefer binNMUs; the problems with them are eminently solvable, considering that Debian's doing them16:00
stgraberinfinity: 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
cjwatsonAnd I don't think the problems are particularly bad16:00
* xnox s/timing/mapping/16:00
infinitycjwatson: 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:00
cjwatsonAlso not breaking TIL on merges16:01
infinitystgraber: 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
cjwatsonSpeaking 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 heart16:01
cjwatsonAnd the multiarch skew issue was solved in Debian16:01
cjwatsonOK, worked around, if you care about the distinction16:02
infinitycjwatson: 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
infinitycjwatson: When was M-A skew fixed?16:02
infinitycjwatson: Or do you mean just by not amending the changelog?16:02
xnoxinfinity: 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:02
cjwatsonsbuild now puts the binNMU entry into a separate per-arch "changelog" so they don't clash, IIRC16:03
infinityErm, and does dpkg now let you install foo_1-2:arm64 and foo_1-2+b1:i386 together?16:03
xnoxinfinity: no, it doesn't at the moment.16:03
cjwatsonOh I see what you mean, no that still needs to be handled, indeed - the Debian release team just avoids doing such binNMUs16:03
xnoxcjwatson: do you know if version skew is at all allowed in dpkg yet?16:03
infinityxnox: Version skew is intentionally not allowed.16:04
cjwatsonBut there are plenty of non-M-A:same packages where binNMUs are still useful16:04
infinityxnox: One could make an exception for binNMU versioning but that means dpkg becoming mre Debian aware than it should.16:04
xnoxstgraber: 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
cjwatsonOr one could look at the Source field16:04
xnoxstgraber: sure, one will not reupload the orig tarball, but one typically still needs to fetch it.16:05
infinitycjwatson: Right, that's probably more sane.16:05
xnoxyeah, source-version enforcement would be nice. but anyway, i like the idea of "server-side-generated-dch-R style binNMUs"16:06
cjwatsonThe other advantage is that it would make new ports a bit less hair-raising16:06
xnoxcjwatson: wouldn't that break if one doesn't have -src lines enabled?16:06
cjwatsonxnox: No16:06
infinitycjwatson: Oh, you mean the option to rebuild the world?16:06
cjwatsonIf we get some vital bit of ABI wrong, we wouldn't have to reupload everything arch-dep ...16:06
infinitycjwatson: William and I had been discussing using copy archive for initial bootstraps.16:07
cjwatsonEven then we don't necessarily realise until later16:07
cjwatsoncf. ARMvINSANITY16: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
cjwatsonYeah, but why do horrible things when we could do nice things16:07
infinityWell, if you're talking a broken ABI, there's often no nice upgrade anyway. :)16:08
infinityWe did dump and rebuild hppa once for that reason.16:08
cjwatsonThe 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:08
cjwatsonAnd dump/rebuild wouldn't have been appropriate there.16:09
* xnox ponders how far up i386->i686 transition we are.16:09
infinityAbsolutely not.  Agreed.16:09
infinityxnox: Far enough.  Also, doesn't really matter for 99.9% of the archive.16:10
xnoxyeah, all important binaries have been re-uploaded many times over, since.16:10
infinitycjwatson: 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
xnoxcjwatson: 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
infinityxnox: I meant that it didn't matter even before they were reuploaded. :P16:11
xnox(if they are m-a:same)16:11
infinityxnox: Once they come from the same source version, you don't care about the binary version at all.16:12
xnoxah, ok.16:12
infinityxnox: In other worse, MA:same version checks should be against source-version, not binary-version.16:12
cjwatsonRight, that's what I mean16:13
cjwatsonAnd better than I could think of how to put it16:14
infinityWell, 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-216:17
infinity(I wouldn't, as it's crazy, but there are no tooling or archive constraints preventing me from such madness)16:17
=== adam_g_afk is now known as adam_g
xnoxi 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:19
infinityxnox: It's only encoded if there's a mismatch.16:21
infinityxnox: apt-cache show libgcc1, for instance.16:21
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
infinityWould make automating various scanning tooling tons easier if Source: was always complete.16:22
xnoxi 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:23
infinityIt's not apt-cache, it's dpkg-gencontrol, but yeah.16:24
xnox... or one of the wrapped commands therein =)16:24
infinityxnox: 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
infinitySo, 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
cjwatsonwajig was trying to be that16:25
cjwatsonI never really got on with it16:25
infinityMaybe 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
xnoxcjwatson: =)))))) was there a wajig-ng re-write in python as well?! =)16:26
cjwatsonit's been in python since 2001 ...16:27
cyphermoxxnox: so, removing kmediafactory and kx11grab?17:29
xnoxcyphermox: yeap, removal request at https://bugs.launchpad.net/ubuntu/+source/kmediafactory/+bug/1254011 should now confirm / subscribe ubuntu-archive to it.17:32
ubot2Launchpad bug 1254011 in libomxil-components (Ubuntu) "remove from ubuntu archive - never in debian, no upstream ports to libav9 / dead upstream" [Undecided,New]17:32
=== gaughen is now known as gaughen_
=== gaughen_ is now known as gaughen
stgraberinfinity: can you bump this one? https://launchpad.net/ubuntu/+source/android/20131125-1710-0ubuntu1/+build/526747019:48
stgraberthe builders seem slightly busy with all those kde packages ;)19:49
infinitystgraber: Done.19:50

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!