[00:06] <xnox> infinity: hm..... curl is depwait
[00:07] <xnox> infinity: can you promote libgnutls28-dev to main?
[00:07] <infinity> ...
[00:07] <infinity> Wasn't that the one with the problematic license that we were avoiding linking to?
[00:07] <xnox> infinity: yes.
[00:07] <xnox> infinity: and curl switched to it.
[00:07] <infinity> And we should switch curl back, then.
[00:08] <xnox> infinity: talk to the newest member of foundations team then =)
[00:08] <xnox> infinity: mvo that is.
[00:08] <infinity> Unless the license issues have magically gone away.
[00:09] <xnox> he also trumped my curl upload =/
[00:09] <xnox> before it had a chance to migrate.
[00:10] <xnox> infinity: although libgmp license did change for the better.
[00:10] <xnox> infinity: so if we have new libgmp10 then actually the license issue might be resolved for lgply things.
[00:10] <xnox> 2 or 3.
[00:11] <infinity> We do not have a gmp10 with that license.
[00:11] <xnox>   * copyright: Updated to reflect new dual-licensing (LGPLv3+ or GPLv2+).
[00:11] <xnox>     Closes: #741607.
[00:11] <xnox> infinity: so shall i upload curl that trumps mvo util we get new gmp?
[00:11] <infinity> We need 2:6.0.0+dfsg-1 merged.
[00:11] <infinity> Well, or higher, obviously.
[00:11] <xnox> who maintains gmp? doko?
[00:12] <infinity> He's TIL, but only for small changes.
[00:12] <infinity> I'll merge it now.
[00:12] <xnox> oh, debian schience team and steve =)
[00:12] <xnox> infinity: well, i can just take ubuntu delta into debian.
[00:13] <xnox> and i thought i did, or it could have been some other package with identical diff.
[00:14] <infinity> Looks like the ELFv2 patch is upstream in 6.0
[00:14]  * infinity checks for the rest.
[00:18] <infinity> Okay, looks like we only need the libstc++ delta.
[00:18] <infinity> The rest is unnecessary now.
[00:18] <infinity> I'll just upload with that, if you want to do a Debian upload later, up to you.
[00:23] <infinity> Oh, hrm, might need symbols updates too.
[00:23]  * infinity tosses it at his PPA out of laziness to see the fallout on arm64/ppc64el.
[00:26] <xnox> well building on ppc64el porter box at the moment (debian upload) =)
[00:28]  * infinity uploads harder, with orig...
[00:31] <infinity> Man, those are some bizarre arch combinations in that symbols file...
[00:31] <infinity> Glad I'm test building instead of guessing.
[00:31] <infinity> Aaaand, it's FTBFS on ppc64el before it gets that far.
[00:31] <xnox> fat fallout?
[00:32] <infinity> /build/buildd/gmp-6.0.0+dfsg/build/.libs/libgmp.so: undefined reference to `BMOD_1_TO_MOD_1_THRESHOLD'
[00:32] <infinity> collect2: error: ld returned 1 exit status
[00:32] <xnox> yeap
[00:32] <infinity> Bets on that being optimized out with -O3?
[00:33] <xnox> i've added ppc64el in debian/rules to pass --disable-fat
[00:33] <xnox> that gets it going i believe.
[00:33] <xnox> nope, still fails.
[00:33] <xnox> dropping -O3 -> maybe
[00:33] <infinity> Oh, it's -O3 on all arches, though.
[00:34] <infinity> Guess I need to actually read some source.
[00:35] <infinity> Hrm.  Scary hacks for that in arm...
[00:35] <infinity> ifdef(`BMOD_1_TO_MOD_1_THRESHOLD',,
[00:35] <infinity>   `define(`BMOD_1_TO_MOD_1_THRESHOLD',0xffffffff)')
[00:35]  * infinity shudders.
[01:04] <xnox> infinity: https://gmplib.org/repo/gmp/rev/4a6d258b467f ?
[01:13] <infinity> xnox: Feh, I just fixed it differently.  But that would work too.
[01:13]  * infinity waits for his build to finish to get symbols out of it, then will take that patch instead.
[01:15] <infinity> xnox: Let me fix up symbols files, suck in that patch, and run another all-arches test.
[01:15] <infinity> xnox: And then you can do whatever you want with that once it's in Ubuntu. :P
[01:16] <xnox> well debian updated whole bunch of symbols, no idea if they will work for ppc64el/arm64
[01:17] <infinity> xnox: They don't, that's why I did my test builds.  Fixing now.
[01:17] <xnox> cool.
[01:17] <cyphermox> infinity: xnox: anything I can help with re: helping gst-plugins-bad1.0 in particular and the huge chunk of text in update_output disappear?
[01:17] <xnox> cyphermox: guess what we are doing.... =)
[01:17] <cyphermox> I know ;)
[01:17] <cyphermox> that's why I'm proposing more hands
[01:19] <xnox> infinity: sign up cyphermox for +1 maint?
[01:19] <cyphermox> I have done +1 maint in the past
[01:20] <infinity> Consider him signed up.
[01:22] <cyphermox> I just need to know what to look at so as not to duplicate work
[01:25] <infinity> Anything that isn't gmp would have you not duplicating my evening. :P
[01:26] <cyphermox> k
[01:30]  * infinity hopes this one sticks.
[01:38] <infinity> xnox: There's a fair chance those ppc64el symbols changes will need to happen for ppc64 too, but I don't have a ppc64 chroot set up right now to check.
[01:38] <infinity> I guess I could debootstrap one quickly...
[01:39] <xnox> infinity: true. ppc64 build fails in debian with the same error that we are applying patch for.
[01:39] <infinity> Right, that patch will fix that, and then it'll probably fail on symbols.
[01:40] <xnox> and looks like there are symbols files changes for sh4 & alpha that i can pull from ports buildds.
[01:40] <infinity> Meh, I have nothing better to do in the next few minutes, let's see how badly broken debootstrapping ppc64 is.
[01:41] <xnox> infinity: here is my diff which does build on ppc64el http://paste.ubuntu.com/7370138/
[01:42] <xnox> should be pretty much the same what you got.
[01:42] <infinity> xnox: I already have a diff in Ubuntu.
[01:42] <infinity> (as in, I uploaded a long while ago)
[01:42] <xnox> i didn't see =)
[01:43] <infinity> xnox: My diff also, importantly, has one arm64 symbol fix too.
[01:43] <infinity> xnox: So, if you don't want to parse that by hand, you might want to just copy mine.
[01:44] <xnox> infinity: yeah, diffed what i have and what you did.
[01:44] <xnox> - (arch=!arm64 !armel !armhf !hppa !mips !mipsel !powerpc !ppc64el !s390x !sparc64 !any-i386)__gmpn_addaddmul_1msb0@Base 0
[01:44] <xnox> + (arch=!arm64 !armel !armhf !arm64 !hppa !mips !mipsel !powerpc !ppc64el !s390x !sparc64 !any-i386)__gmpn_addaddmul_1msb0@Base 0
[01:44] <xnox> looks funny
[01:44] <xnox> i guess listing arm64 doesn't hurt. (also no idea which side is which)
[01:44] <infinity> Erm, I didn't do that. :P
[01:45] <xnox> yeah =))) me
[01:46]  * infinity watches his ppc64 debootstrap grind away...
[01:46] <xnox> Also this one:
[01:46] <xnox> - (arch=ppc64el)__gmpn_sublsh2_n@Base 2:5.1.1
[01:46] <xnox> + (arch=ppc64el)__gmpn_sublsh2_n@Base 0
[01:46] <xnox> did you go for 2:5.1.1 just for consistency?
[01:47] <infinity> xnox: Yours might be more correct there, in theory, I don't have a version older than 5.1.1 on ppc64el to check. :P
[01:47] <infinity> (And there isn't one)
[01:47] <xnox> yeah, that's what i thought. if it never was any prior version, might as well go with 0.
[01:47] <xnox> anyway, reverting to your edition.
[01:48] <infinity> DEBOOTSTRAP HARDER, ARGH.
[01:49] <infinity> xnox: Test build on ppc64 will probably take 30m or so.  Not the fastest hardware here in my living room.
[01:54] <infinity> Err, crap.  I forgot to drop dh-autoreconf from my build-deps, despite dropping its usage in rules.
[01:54] <infinity> Oh well.
[01:56] <saiarcot895> Just out of curiosity, are the arm builders (at least the PPA ones) on actual ARM hardware, or are they using pre-compiled cross-compilers?
[01:57] <infinity> saiarcot895: The PPA builders use qemu-user-static.
[01:57] <infinity> saiarcot895: The distro builders are on real hardware.
[01:57] <infinity> saiarcot895: Neither uses cross-compilers.
[01:58] <saiarcot895> infinity: Might using the cross-compilers like g++-arm-linux-gnueabi be faster?
[01:58] <saiarcot895> and then compile on i386 or amd64?
[01:58] <NCommander> saiarcot895, introduces far too many problems
[01:59] <NCommander> cross-compilation fine for an embedded system or a small selection of packages, but cross-compilation adds massive amounts of complexity to the build process, and a lot of stuff just really goes and explodes
[01:59]  * NCommander once had to cross-build mysql and still has the scars from it
[02:00] <saiarcot895> NCommander: ah, I feared that
[02:00] <xnox> infinity: (arch=!alpha !arm64 !armel !armhf !hppa !mips !mipsel !powerpc !ppc64el !s390x !sh4 !sparc64 !any-i386)__gmpn_addaddmul_1msb0@Base 0
[02:00] <xnox> insn't that just arch=amd64-any ?
[02:01] <infinity> xnox: Might be.  I didn't read closely enough to match.
[02:02] <infinity> saiarcot895: Ubuntu and Debian are set up to be self-hosting systems, not cross systems.  So, yes, as NCommander hints at, we're in good shape to natively compile anything, in poor shape to cross many/most things.
[02:02] <infinity> saiarcot895: We've put a lot of work into making our base system cross-friendly, but after that, it falls apart quickly.  Crossing the PPAs would mean you could build about 200 packages. :P
[02:03] <NCommander> saiarcot895, when it comes to package compilation, its a massively distributable process :-)
[02:03] <infinity> xnox: Though, I assume you mean any-amd64
[02:04] <infinity> xnox: I don't see sparc on that list, but maybe it's missing from the whole symbols file due to sparc being relatively unbuildable while GCC is skewed...
[02:06] <infinity> Oo, but doko uploaded gcc-4.9 for sparc, that should clear up.
[02:06] <xnox> quite any-amd64
[02:06] <infinity> Could take two weeks for those poor buildds to catch up.
[02:07] <infinity> xnox: Okay, ppc64 finished, and it's more or less as I expected.  Want the dh_makeshlibs diff output, or just an updated-and-tested symbols file?
[02:08] <xnox> infinity: just the diff would be fine.
[02:08] <infinity> It's not quite as simple as "add ppc64 everywhere we have ppc64el".
[02:08] <xnox> infinity: i just walked alpha sh4 diffs.
[02:08] <infinity> http://paste.ubuntu.com/7370230/ <-- That's the diff against my Ubuntu upload.
[02:09] <infinity> xnox: Builds fine otherwise though, so yay.
[02:09] <infinity> xnox: No idea what the deal is with those .__ symbols...
[02:11] <infinity> Certainly looks a bit odd.
[02:11] <xnox> quite.... cuase they all exist without leading .
[02:12] <infinity> xnox: Those .__ ones are all there in 2:5.1.3+dfsg-1 too, so it's not a regression.
[02:12] <infinity> xnox: Just weird.
[02:13] <infinity> xnox: Old version for ref: http://paste.ubuntu.com/7370243/
=== jhodapp|afk is now known as jhodapp
[02:13] <infinity> (Not sure if they're *all* there, didn't compare, but the point is that there were a bunch of them and this isn't a new phenomenon)
[02:15] <infinity> xnox: Quite possibly an upstream bug or something, but also nothing that wasn't already there.
[02:15] <xnox> infinity: so i should add them for ppc64?!
[02:16] <infinity> xnox: Add them, or figure out a clever way to ignore them.  But yeah, they need to be there for dh_makeshlibs to not explode.
[02:18] <infinity> xnox: AFAICT, none of libgmp's rdeps link to the weird dot symbols.  They could probably be filtered out in a linker script.
[02:18] <infinity> xnox: But also, meh.
=== jhodapp is now known as jhodapp|afk
[06:52] <elfy> good morning release team - not sure if this is the right place to ask - but is there a reason why there's no xubuntu images on the utopic iso tracker?
[06:53] <cjwatson> They've been failing to build
[06:54] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/utopic/xubuntu/latest/livecd-i386.out
[06:54] <cjwatson> Haven't really investigated yet
[06:57] <elfy> cjwatson: ok - thanks
[06:58] <cjwatson> Looks like that should be fixed for the next build
[06:58] <cjwatson> https://launchpad.net/ubuntu/+source/hunspell-en-us/20070829-6ubuntu2
[06:58] <elfy> cjwatson: excellent - I can start haranguing my testers soon then :)
[06:59] <elfy> thanks for the info
[06:59] <cjwatson> np
[07:29] <infinity> Oh nice, gst-plugins-whatever migrated.
[07:30] <infinity> Still some AIEEE overflow madness, but should be getting near the end of it.
[07:30] <darkxst> infinity, any chance you can bump through g-i and gjs to trusty-proposed?
[07:31] <infinity> darkxst: If they're simple.  I'm only sort of awake.
[07:31]  * infinity looks
[07:31] <darkxst> g-i is simple, gjs should be a MRE
[07:33] <infinity> Bonus points for regenerating debian/control with a non-braindead pkg-gnome-thingee.
[07:36] <infinity> darkxst: MRE or not, a bug ref on the gjs upload would be nice, so there's some way to track that the binaries have been validated to be sane.
[07:37] <infinity> darkxst: (And that particular upload wouldn't really need an MRE anyway, if you wanted to validate all the upstream bugs it fixes, it's pretty straightforward)
[07:40] <darkxst> infinity, oh oops it should have been linked too bug 1283551
[07:40] <ubot2> Launchpad bug 1283551 in gjs (Ubuntu) "gjs-console crashed with signal 5" [Medium,Confirmed] https://launchpad.net/bugs/1283551
[07:40] <darkxst> but really there about 10 different bugs that will be fixed by the update
[07:40] <infinity> darkxst: Heh.  Oops.  Can you upload that yourself, or need a sponsor?
[07:40] <darkxst> I can re-upload
[07:41] <infinity> darkxst: Kay, cool.  Add a bug ref or two and I'll make sure it's identical other than the changelog, and we're good.
[07:42] <infinity> I like that upstream naively thinks sprinkling semicolons around is just "style changes" in javascript.
[07:43] <darkxst> javascript doesnt care so much about semi-colons!
[07:43] <infinity> JS being infamous for randomly changing flow based on if you do or don't semicolon post-brace, in circumstances that only language parsers and people who've never seen the sunlight understand.
[07:44] <infinity> darkxst: Trust me, that statement is patently false in many (most?) JS implementations. ;)
[07:45] <infinity> I got so fed up with random JS implementations doing different things with what seemed like simple C-style flow control that I have up and literally just put a semicolon on the end of EVERYTHING now.
[07:45] <infinity> Since that seems to be the only thing that's parsed consistently.
[07:45] <infinity> s/have up/gave up/
[07:48] <infinity> And since most people repurpose their JS parser for CSS (given the nearly identical syntax), I tend to do the same for CSS too.
[07:48] <infinity> This is my PTSD from a horrible past of web development.
[07:50] <darkxst> infinity, right I tend to avoid JS when I can these days, although I still have to deal with python's stupid handling of integers/floats everyday ;(
[07:51] <darkxst> ^infinity linked the top few bugs, but there are probably dozens more, need to go get dinner now though ;) ....
[07:52] <infinity> Oh, you didn't need a new version.
[07:52] <infinity> But meh.
[07:52] <darkxst> infinity, oh, ppa's do ;(
[07:53] <infinity> Yeah, the queue is a special place that exists outside the archive. :)
[07:53] <infinity> No big deal.
[07:54] <darkxst> infinity, right, you don't learn these things when going through sponsors ;)
[07:54] <infinity> Heh, you linked the same bug twice.
[07:55] <darkxst> cut+paste fail ;(
[07:55] <infinity> I'm going to officially not care.
[07:57] <darkxst> infinity, fixed now anyway
[08:07] <infinity> xnox: Repeated nag about boost1.55/gccxml
[09:37] <darkxst> infinity, still around? can you give gjs a rebuild in trusty-proposed (tests failed due to g-i update not being finished, and yes I probably should have added a depend on that....)
[09:38] <infinity> darkxst: You should be able to yourself, if you're the uploader.
[09:39] <darkxst> infinity, ah ok, yes!
[09:40] <infinity> Try not to abuse this newfound knowledge. ;)
[09:43] <darkxst> infinity, hah! why would I do that? according to Laney, I need to abuse my own server to get some warmth into this house ;)
[09:44] <infinity> He speaks wisdom.
[09:44] <infinity> This is why I'm trading all my ARM kit for old IA64 and PARISC stuff.
[09:45] <darkxst> my old P4 was a toaster! too bad I don't have it anymore ;(
[09:46] <darkxst> 95W TDP, shutdown a bunch of times from overheating, extactly what I could use now ;)
[09:50] <infinity> Huh.  I'm trying to decide if I think xbmc-bin-recommends-dummy.so is a really clever hack to avoid hardcoding recommended libraries in debian/control, or just vomitously horrid.
[09:50] <infinity> I guess it can be both.
[09:50] <cjwatson> Embrace the power of and.
[09:51] <infinity> I think I shall remember this awful hack the next time I feel the urge to depend/recommend on a library I don't actually link with.
[09:51] <infinity> It's certainly a cute trick.
[09:54] <cjwatson> Has it been clever enough not to actually ship the .so in question?
[09:55] <infinity> I didn't check the source, but I'd hope so.
[09:55] <infinity> dpkg-shlibdeps -pdlopenlibs -edebian/tmp/xbmc-bin-depends-dummy.so -xlibc6 -O >>debian/xbmc-bin.substvars
[09:55] <infinity> dpkg-shlibdeps -dRecommends -edebian/tmp/xbmc-bin-recommends-dummy.so -xlibc6 -O >>debian/xbmc-bin.substvars
[09:56] <infinity> So, yeah, it's not installed.
[09:56] <cjwatson> Good stuff
[09:57]  * cjwatson keeps going with the libmikmod/sdlgfx intertwined transitions
[09:57] <cjwatson> (tedious but not hard)
[09:57]  * infinity decides to give sleep another whirl.
[11:21] <xnox> cjwatson: libmikmod transition also needs libmikmod2-dev -> libmikmod-dev changes e.g. as in patch proposed in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744906
[11:21] <ubot2> Debian bug 744906 in bb "bb: Please build-depend on libmikmod-dev instead of libmikmod2-dev" [Wishlist,Open]
[11:21] <cjwatson> xnox: I already did all that
[11:22] <cjwatson> xnox: Although it probably isn't a problem in Debian because NBS works differently there so the Provides has a better chance of taking effect
[11:22] <cjwatson> Or at least not as much of a problem
[11:23] <xnox> right, i've been mislead by launchpad "latest upload" on bb was not the one from proposed.
[11:24] <cjwatson> Yeah, it took me two goes there
[11:24] <cjwatson> Dunno why it's confused about the latest upload
[11:24] <cjwatson> Oh, because build1 didn't change anything meaningful and so propagated to release
[11:25] <cjwatson> Anyhow, it should all be done now once builds finish
[11:26] <cjwatson> i.e. taoframework and widelands
=== jhodapp|afk is now known as jhodapp
[12:10] <elfy> superm1: I hope I remember you being something to do with mythbuntu - if not sorry for the bump - but I've seen reports that the 14.04 download from your website is broken - confirmed it
[13:23] <psivaa> cjwatson: infinity: autorun.inf and wubi.exe dont appear in the list in utopic desktop images. iso static vaildation tests are flagging this up.
[13:25] <cjwatson> psivaa: thanks, should be fixed next build
[13:25] <cjwatson> ubuntu-archive@snakefruit:~/public_html/wubi$ cp -a trusty utopic
[13:25] <psivaa> cjwatson: ack, thanks
[13:25] <arges> xnox: hmm I used the scripts, wonder why I didn't add the tag properly. anyway sounds like you got it resolved. thanks
[13:57] <michagogo|cloud> I thought wubi was dead? :-/
[13:58] <stgraber> michagogo|cloud: it's still used to show the autorun UI on Windows
[13:58] <michagogo|cloud> What autorejoin UI is there?
[13:58] <michagogo|cloud> Autorun*
[13:59] <michagogo|cloud> (Autocorrect)
[13:59] <stgraber> something telling you it's an Ubuntu CD, that you should reboot to start it and maybe still offering to change your boot.ini to boot from CD (not sure about that last part, especially with newer Windows)
[14:04] <tgm4883> elfy: thanks for the ping. We noticed it broke yesterday after the server's hard drive filled up. Not sure why it's still not working though
[14:14] <elfy> tgm4883: ok and welcome :)
[14:25] <Daviey> tgm4883, elfy: Fixed. Thanks.
[14:26] <elfy> \o/
[14:52] <apw> pitti, did we have an ADT hickup, a random selection of the tests run for sysvinit seem to be qemu being killed hard
=== jhodapp is now known as jhodapp|lunch
[17:00] <rtg> can somebody restart sysvinit autopackage testing ? qemu appears to have prematurely aborted on some tests.
[17:01] <xnox> rtg: do you have vpn access? you can restart the job yourself, i believe.
[17:02] <rtg> xnox, I only have Q/A lab VPN access AFAIK
[17:02] <xnox> rtg: ok, let me restart it.
[17:02] <rtg> xnox, thanks
[17:04] <xnox> rtg: do you mean sysvinit adt itself, or everything that it has triggered?
[17:04] <rtg> xnox, I'm not smart enough to know the difference.
[17:04] <rtg> you choose
[17:04] <xnox> rtg: which job /result you see aborted? url?
[17:05] <rtg> xnox, I'm looking at people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html in which I see a number of failures under sysvinit
[17:06] <xnox> rtg: right but e.g. mysql is a valid failure by the looks of things. i can retrigger them all.
[17:08] <rtg> xnox, I don't my patch could have cause a mysql failure, so there must be something new in Utopic causing this ? sysvinit was copied forward from trusty.
[17:09] <xnox> rtg: well some of these jobs have not yet ever passed on utopic....
[17:09] <rtg> I don't think*
[17:09] <xnox> rtg: retried all but linux, which is still in progress on i386
=== jhodapp|lunch is now known as jhodapp
=== doko_ is now known as doko
=== jhodapp is now known as jhodapp|afk
[21:16] <doko> demoted ruby1.9.1 \o/
[21:26] <xnox> doko: may day, may day, holliday!
[21:26] <xnox> =))))) *giggle*
[22:10] <xnox> gvfs is blocked on failed deja-dup and dbus-test-runner tests, that have never yet passed in utopic.
[22:11] <xnox> gvfs is a no-change rebuild for plist transition.
[22:11] <xnox> can it please be unblocked?
[22:25] <Laney> They both work in trusty fairly consistently so I think we at least need to figure out what's gone wrong
=== Ursinha is now known as Ursinha-afk
[22:28] <xnox> Laney: true.
=== Ursinha-afk is now known as Ursinha