[09:23] <LocutusOfBorg> hi cjwatson did the gemrb demote to multiverse fail? I still don't see it migrating
[10:03] <LocutusOfBorg> hi folks, what is missing to see liquidsoap migrate? I'm honestly lost in the ocaml stuff
[10:05] <LocutusOfBorg> BTW with liquidsoap and gemrb migrated, I think we are good wrt libpng12 removal
[10:05] <LocutusOfBorg> everything else seems false positive (libpng-dev | libpng12-dev in b-d)
[10:06] <mapreri> Depends: liquidsoap yojson (not considered)
[10:06] <mapreri> which is because of 'Depends: yojson biniou (not considered)'
[10:06] <mapreri> which is because of 'autopkgtest for botch 0.16-2ubuntu2: ppc64el: Regression ♻ , s390x: Regression ♻'
[10:06] <mapreri> LocutusOfBorg: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#biniou is your friend.
[10:07] <LocutusOfBorg> yes, but botch is utterly broken, also in debian
[10:08] <LocutusOfBorg> I saw that, but I guess some force-hints seems needed
[10:08] <LocutusOfBorg> or demote
[10:10] <mapreri> LocutusOfBorg: then why do you came here with "why liquidsoap doesn't migrate" instead of asking for a kick for src:biniou directly? :)
[10:11] <LocutusOfBorg> because I don't feel good in giving orders, I like to mask them under a stupid question :)
[10:11] <mapreri> :>
[10:19] <cjwatson> LocutusOfBorg: oh right, need to do it in yakkety-proposed as well as yakkety.  done
[10:20] <LocutusOfBorg> thanks! I was wondering about how long would it take to be effective :)
[10:21] <LocutusOfBorg> can anybody please help hunspell migrate? I think goldendict failing on s390x is the only reason for it not migrating
[10:21] <cjwatson> half an hour or so, bit longer for the proposed-migration cycle
[10:21] <LocutusOfBorg> but it is broken in debian too
[10:21] <LocutusOfBorg> cjwatson, nope, I was wondering that before asking again today, not now :)
[11:53] <infinity> LocutusOfBorg: What "help" were you hoping for?  You could help it by fixing goldendict...
[11:56] <infinity> LocutusOfBorg: If it's a helpful hint, the failure doesn't look to be s390x-specific, but rather 64-bit-big-endian (sparc64 failed the same way, and ppc64 probably would if it had been attempted)
[12:36] <LocutusOfBorg> infinity, is adding a cast https://sources.debian.net/src/goldendict/1.5.0%7Egit20160508.g92b5485-1/ripemd.cc/#L176
[12:36] <LocutusOfBorg> a reasonable solution?
[12:36] <LocutusOfBorg> thanks for the *useful* hint, I didn't think about 64 bits
[12:36] <LocutusOfBorg> I excluded BE because others were fin
[12:36] <LocutusOfBorg> I'm testing on a debian porterbox
[12:38] <LocutusOfBorg> well, count is uint64_t, I can't cast to 32 bits
[12:51] <LocutusOfBorg> forwarded upstream
[13:00] <LocutusOfBorg> infinity, I guess it is a qt issue, because on debian/s390x is building now fine
[13:12] <infinity> LocutusOfBorg: The last build log disagrees.  Or did you just try on a porter?
[13:20] <LocutusOfBorg> infinity, I tried in a Debian porterbox and asked a give back on debian buildd
[13:20] <LocutusOfBorg> not sure why ubuntu failed again
[13:20] <LocutusOfBorg> the qt4 stuff is mostly in sync
[13:21] <LocutusOfBorg> do you want to see a build?
[13:21] <LocutusOfBorg> zelenka.debian.org has an ongoing build
[13:24] <infinity> LocutusOfBorg: Different qt versions between the last Debian failure and your recent attempt?
[13:24] <infinity> Not that I see much interesting in the qt4-x11 changelog.
[13:25] <LocutusOfBorg> exactly, even symbols file arent showing differences
[13:25] <LocutusOfBorg> moreover I already took the latest qt4 in my last attempt
[13:26] <LocutusOfBorg> I'm seeing something interesting now
[13:26] <LocutusOfBorg> "-DHAVE_X11" < is not passed in the porterbox
[13:27] <LocutusOfBorg> but I see a -DQT_WEBKIT instead
[13:34] <LocutusOfBorg> damn, the apt-get source is getting the testing version
[13:35] <LocutusOfBorg> blah something is bad with unstable mirrors
[13:55] <LocutusOfBorg> infinity, does it sound ok for you? http://paste.ubuntu.com/16946618/
[13:55] <LocutusOfBorg> I took some bits from libavutil
[13:55] <LocutusOfBorg> https://ffmpeg.org/doxygen/2.3/bswap_8h_source.html
[13:56] <LocutusOfBorg> actually that file is coming from there, so I guess we are good
[13:57] <infinity> LocutusOfBorg: That seems like an odd hack to work around qFromLittleEndian() breaking, if that's the real bug.
[13:58] <LocutusOfBorg> infinity, seems that qFromLittleEndian doesn't exist for 64 bit data types
[13:58] <infinity> LocutusOfBorg: But it worked previously?  I mean, this is just a rebuild.
[13:59] <LocutusOfBorg> no infinity
[13:59] <LocutusOfBorg> this is a new upstream release
[13:59] <LocutusOfBorg> the old one was #include <libavutil/file.h> now they embedded it there
[13:59] <LocutusOfBorg> with some changes, including this one
[13:59] <infinity> LocutusOfBorg: Ahh.
[13:59] <LocutusOfBorg> https://github.com/goldendict/goldendict/commit/a04917833c4fca355123157c4a03ea706fa31c19
[13:59] <infinity> LocutusOfBorg: Okay, that makes more sense.
[13:59] <LocutusOfBorg> and more sadness
[14:02] <LocutusOfBorg> https://github.com/goldendict/goldendict/issues/714
[14:04] <ogra_> infinity, mind takeing a look at this ? https://wiki.ubuntu.com/QATeam/OSSnapPromotion ... i have some issues to solve and wonder if you know an easy way that doesnt require to much cdimage hackery
[14:05] <infinity> LocutusOfBorg: Casting count to a 32-bit type would possibly also fix it, but gross either way.  But if this code is stolen from libav and libav has a fix, that seems reasonable to me.
[14:06] <ogra_> essentially we want to build three types of xenial images from different archives, while that is easy to achieve with cdimage vars and different crontab entries, i have no idea how i should actually reflect that on cdimage wrt output dirs ... i dont want all of them in the same www dir
[14:06] <LocutusOfBorg> infinity, already uploaded on Ubuntu, and on deferred/5 for debian
[14:06] <infinity> LocutusOfBorg: Shiny.
[14:06] <LocutusOfBorg> I don't care about upstream code :)
[14:06] <LocutusOfBorg> they want to embed stuff, they have to handle it
[14:07] <LocutusOfBorg> and now I want hunspell to migrate :D
[14:07] <infinity> LocutusOfBorg: FWIW, the goldendict maintainer is listed in the LowNMU table, you could delete the delayed upload and just upload straight to the queue.
[14:08] <LocutusOfBorg> well, ubuntu is fixed, so I don't care too much about some days
[14:08] <LocutusOfBorg> but I'll consider it
[14:08] <infinity> Release Candidate: xenial-archive + xenial-security/-updates + snapd stable PPA
[14:08] <infinity> ogra_: ^-- Why a PPA there?  We're SRUing snapd intentionally to keep it up to date.
[14:09] <ogra_> infinity, yeah, thats apparently not desired anymore
[14:09] <infinity> ogra_: ...
[14:09] <cjwatson> Any chance somebody could look at python-libnacl and pymacaroons in xenial-proposed NEW?  Straight backports from yakkety, needed to avoid vendored code in snapcraft
[14:09] <ogra_> instead snapd will be a dummy package (an installer for the ubuntu-core snap) and just use the executable from inside the snnap
[14:10] <infinity> Oookay.
[14:10] <ogra_> (there was a long and heated discussion about SRUing ... i kind of lost :/ )
[14:11] <ogra_> the original wikipage only said "archive + -updates/-security" for the last image ...
[14:11] <infinity> ogra_: So, I think our best bet here might be to invent a concept of sub-series in cdimage.  So you can do xenial-edge, xenial-beta, and xenial builds.
[14:11] <infinity> ogra_: Then everything will end up in a pleasant subdir in the tree.
[14:11] <ogra_> yeah, but that sounds like a lot of work ... i was wondering of there isnt something in place already that i could abuse
[14:12] <ogra_> (something i dont know about)
[14:12] <infinity> Not that I can think of off the top of my head.
[14:12] <ogra_> i'm also not sure we want to expose the snaps on cdimage at all in the end ... once there is proper store integration everywhere
[14:12] <infinity> cjwatson: I can have a look.  Bug paperwork all looks good, etc?
[14:12] <ogra_> so the "switch" would only define the channel to upload to
[14:13] <cjwatson> infinity: Hopefully; it's bug 1586770
[14:13] <ogra_> instead of exposing it on cdimage at all
[14:14] <infinity> ogra_: Right, I'm equally unconvinced about publishing them to the www tree.  And, indeed, if that's something we can avoid today, then this is almost a moot point.
[14:15] <infinity> ogra_: Cause your cronjobs would just be '$var $var for-project thing && upload-to-store thing $channel'
[14:15] <ogra_> right, they would have to go directly to the store instead ... though that still needs some kind fo "channel-selector" based on the archives used
[14:15] <ogra_> ah
[14:15] <infinity> ogra_: And then we need no knowledge of any of this.  You're just triggering a build and vacuuming the result.
[14:15] <ogra_> you would separate the uploader ... clever
[14:15] <ogra_> yeah, good idea ... i'll play with that idea. thanks !
[14:17] <LocutusOfBorg> infinity, can you please remove vmtk/powerpc? insighttookit is going to be removed, and insighttookit4 is not powerpc ready
[14:17] <LocutusOfBorg> Debian dropped it too
[14:17] <infinity> cjwatson: I see that's all in universe.  No ongoing MIR for snapcraft?
[14:18] <LocutusOfBorg> I guess also insighttookit can be removed, reverse-depends shows nifti2dicom and vmtk but only for powerpc (does it need to migrate first?)
[14:18] <cjwatson> infinity: Not AFAIK ...
[14:18] <infinity> cjwatson: Kay.  Well, if one happens, we can retroactively promote in xenial too.
[14:19] <infinity> cjwatson: Lemme do some differy and get back to you.
[14:19] <infinity> cjwatson: Oh, and add a bit to the bug about how you intend to test these, please.
[14:21] <cjwatson> infinity: added
[14:24] <infinity> cjwatson: ^^
[14:24] <cjwatson> yay, thanks
[14:25] <infinity> cjwatson: Will babysit binary NEW, but if I get distracted, feel free to self-accept.
[14:28] <infinity> cjwatson: I'm not reviewing the new binaries for sanity, do be a dear and make sure your testplan involves at least importing both py2 and py3 modules to make sure they exist on disk and such. ;)
[14:28] <cjwatson> Picky, picky.
[14:28] <infinity> Yeah, I know. :)
[14:31] <infinity> cjwatson: Oh, and given the regression potential is <= 0, if you need this ASAP for $reasons, I'm fine with fast-tracking the promotion once you've tested.
[14:31] <cjwatson> I think next week is probably fine.  They seem to have temporarily vendored it anyway, but obviously want to get rid of that pretty soon.
[15:16] <jbicha> could I get a yes or no on bug 1584522 please?
[15:55] <infinity> jbicha: Seems entirely reasonable to me, +1
[16:37] <slangasek> bdmurray: lp:~brian-murray/ubuntu-archive-tools/add-release-tasks merged; I do note a lot of code duplication between sru-accept and sru-review which is suboptimal and ought to be refactored, but no sense in blocking on that right now
[20:41] <sergiusens> slangasek hey, quick question, will this get stuck in xenial when I want to SRU/MRE it as well https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=snapcraft ?
[20:59] <slangasek> sergiusens: if you are following https://wiki.ubuntu.com/SnapcraftUpdates, it should not get stuck
[21:02] <sergiusens> slangasek yeah, we are following that, it's just that this is the first time snapcraft gets stuck in the 'new' queue
[21:12] <slangasek> oh
[21:12] <slangasek> sergiusens: so it will also have to go through binary new, but it shouldn't get "stuck" beyond possibly you having to whack an archive admin into action ;)
[21:18] <sergiusens> slangasek I just checked and you happen to be one :-)
[21:19] <slangasek> yes
[21:19] <sergiusens> not sure I should whack anyone though :-P
[21:19] <slangasek> sergiusens: 'lintian -I snapcraft_2.10+16.10_amd64.changes' has a few things to say
[21:19]  * sergiusens checks
[21:20] <slangasek> no blockers, but best practice is to look at lintian output for both the source and binary packages
[21:21] <slangasek> ^^ and, accepted for yakkety
[21:23] <sergiusens> slangasek well my plan is to upload the same thing for X so if it is going to be blocked I'd like to know what would block it
[21:23] <sergiusens> slangasek some are really easy to fix and I can
[21:23] <slangasek> sergiusens: nope, none of those are blockers for xenial either
[21:24] <sergiusens> slangasek thanks btw!
[21:24] <sergiusens> slangasek ok, I'll log a bug against snapcraft to fix those for 2.11
[21:24] <sergiusens> and get you to review
[21:24] <sergiusens> thanks!