=== stokachu_ is now known as stokachu === FourDollars_ is now known as FourDollars === Trevinho_ is now known as Trevinho [09:23] hi cjwatson did the gemrb demote to multiverse fail? I still don't see it migrating [10:03] hi folks, what is missing to see liquidsoap migrate? I'm honestly lost in the ocaml stuff [10:05] BTW with liquidsoap and gemrb migrated, I think we are good wrt libpng12 removal [10:05] everything else seems false positive (libpng-dev | libpng12-dev in b-d) [10:06] Depends: liquidsoap yojson (not considered) [10:06] which is because of 'Depends: yojson biniou (not considered)' [10:06] which is because of 'autopkgtest for botch 0.16-2ubuntu2: ppc64el: Regression ♻ , s390x: Regression ♻' === \b is now known as benonsoftware [10:06] LocutusOfBorg: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#biniou is your friend. [10:07] yes, but botch is utterly broken, also in debian [10:08] I saw that, but I guess some force-hints seems needed [10:08] or demote [10:10] 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] because I don't feel good in giving orders, I like to mask them under a stupid question :) [10:11] :> === Saviq_ is now known as Saviq [10:19] LocutusOfBorg: oh right, need to do it in yakkety-proposed as well as yakkety. done [10:20] thanks! I was wondering about how long would it take to be effective :) [10:21] can anybody please help hunspell migrate? I think goldendict failing on s390x is the only reason for it not migrating [10:21] half an hour or so, bit longer for the proposed-migration cycle [10:21] but it is broken in debian too [10:21] cjwatson, nope, I was wondering that before asking again today, not now :) [11:53] LocutusOfBorg: What "help" were you hoping for? You could help it by fixing goldendict... [11:56] 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] infinity, is adding a cast https://sources.debian.net/src/goldendict/1.5.0%7Egit20160508.g92b5485-1/ripemd.cc/#L176 [12:36] a reasonable solution? [12:36] thanks for the *useful* hint, I didn't think about 64 bits [12:36] I excluded BE because others were fin [12:36] I'm testing on a debian porterbox [12:38] well, count is uint64_t, I can't cast to 32 bits [12:51] forwarded upstream [13:00] infinity, I guess it is a qt issue, because on debian/s390x is building now fine [13:12] LocutusOfBorg: The last build log disagrees. Or did you just try on a porter? [13:20] infinity, I tried in a Debian porterbox and asked a give back on debian buildd [13:20] not sure why ubuntu failed again [13:20] the qt4 stuff is mostly in sync [13:21] do you want to see a build? [13:21] zelenka.debian.org has an ongoing build [13:24] LocutusOfBorg: Different qt versions between the last Debian failure and your recent attempt? [13:24] Not that I see much interesting in the qt4-x11 changelog. [13:25] exactly, even symbols file arent showing differences [13:25] moreover I already took the latest qt4 in my last attempt [13:26] I'm seeing something interesting now [13:26] "-DHAVE_X11" < is not passed in the porterbox [13:27] but I see a -DQT_WEBKIT instead [13:34] damn, the apt-get source is getting the testing version [13:35] blah something is bad with unstable mirrors [13:55] infinity, does it sound ok for you? http://paste.ubuntu.com/16946618/ [13:55] I took some bits from libavutil [13:55] https://ffmpeg.org/doxygen/2.3/bswap_8h_source.html [13:56] actually that file is coming from there, so I guess we are good [13:57] LocutusOfBorg: That seems like an odd hack to work around qFromLittleEndian() breaking, if that's the real bug. [13:58] infinity, seems that qFromLittleEndian doesn't exist for 64 bit data types [13:58] LocutusOfBorg: But it worked previously? I mean, this is just a rebuild. [13:59] no infinity [13:59] this is a new upstream release [13:59] the old one was #include now they embedded it there [13:59] with some changes, including this one [13:59] LocutusOfBorg: Ahh. [13:59] https://github.com/goldendict/goldendict/commit/a04917833c4fca355123157c4a03ea706fa31c19 [13:59] LocutusOfBorg: Okay, that makes more sense. [13:59] and more sadness [14:02] https://github.com/goldendict/goldendict/issues/714 [14:04] 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] 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] 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] infinity, already uploaded on Ubuntu, and on deferred/5 for debian [14:06] LocutusOfBorg: Shiny. [14:06] I don't care about upstream code :) [14:06] they want to embed stuff, they have to handle it [14:07] and now I want hunspell to migrate :D [14:07] 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] well, ubuntu is fixed, so I don't care too much about some days [14:08] but I'll consider it [14:08] Release Candidate: xenial-archive + xenial-security/-updates + snapd stable PPA [14:08] ogra_: ^-- Why a PPA there? We're SRUing snapd intentionally to keep it up to date. [14:09] infinity, yeah, thats apparently not desired anymore [14:09] ogra_: ... [14:09] 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] 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] Oookay. [14:10] (there was a long and heated discussion about SRUing ... i kind of lost :/ ) [14:11] the original wikipage only said "archive + -updates/-security" for the last image ... [14:11] 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] ogra_: Then everything will end up in a pleasant subdir in the tree. [14:11] 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] (something i dont know about) [14:12] Not that I can think of off the top of my head. [14:12] 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] cjwatson: I can have a look. Bug paperwork all looks good, etc? [14:12] so the "switch" would only define the channel to upload to [14:13] infinity: Hopefully; it's bug 1586770 [14:13] bug 1586770 in python-libnacl (Ubuntu Xenial) "Add pymacaroons to xenial" [High,In progress] https://launchpad.net/bugs/1586770 [14:13] instead of exposing it on cdimage at all [14:14] 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] ogra_: Cause your cronjobs would just be '$var $var for-project thing && upload-to-store thing $channel' [14:15] 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] ah [14:15] ogra_: And then we need no knowledge of any of this. You're just triggering a build and vacuuming the result. [14:15] you would separate the uploader ... clever [14:15] yeah, good idea ... i'll play with that idea. thanks ! [14:17] infinity, can you please remove vmtk/powerpc? insighttookit is going to be removed, and insighttookit4 is not powerpc ready [14:17] Debian dropped it too [14:17] cjwatson: I see that's all in universe. No ongoing MIR for snapcraft? [14:18] 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] infinity: Not AFAIK ... [14:18] cjwatson: Kay. Well, if one happens, we can retroactively promote in xenial too. [14:19] cjwatson: Lemme do some differy and get back to you. [14:19] cjwatson: Oh, and add a bit to the bug about how you intend to test these, please. [14:21] infinity: added [14:24] cjwatson: ^^ [14:24] yay, thanks [14:25] cjwatson: Will babysit binary NEW, but if I get distracted, feel free to self-accept. [14:28] 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] Picky, picky. [14:28] Yeah, I know. :) [14:31] 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] 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] could I get a yes or no on bug 1584522 please? [15:16] bug 1584522 in One Hundred Papercuts "[UIFe] Don't show GNOME Books by default" [Medium,Triaged] https://launchpad.net/bugs/1584522 [15:55] jbicha: Seems entirely reasonable to me, +1 [16:37] 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 === tyhicks` is now known as tyhicks [20:41] 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] sergiusens: if you are following https://wiki.ubuntu.com/SnapcraftUpdates, it should not get stuck [21:02] slangasek yeah, we are following that, it's just that this is the first time snapcraft gets stuck in the 'new' queue [21:12] oh [21:12] 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] slangasek I just checked and you happen to be one :-) [21:19] yes [21:19] not sure I should whack anyone though :-P [21:19] sergiusens: 'lintian -I snapcraft_2.10+16.10_amd64.changes' has a few things to say [21:19] * sergiusens checks [21:20] no blockers, but best practice is to look at lintian output for both the source and binary packages [21:21] ^^ and, accepted for yakkety [21:23] 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] slangasek some are really easy to fix and I can [21:23] sergiusens: nope, none of those are blockers for xenial either [21:24] slangasek thanks btw! [21:24] slangasek ok, I'll log a bug against snapcraft to fix those for 2.11 [21:24] and get you to review [21:24] thanks! === bluesabre is now known as bluesabre1 === bluesabre1 is now known as bluesabre