=== stokachu_ is now known as stokachu | ||
=== FourDollars_ is now known as FourDollars | ||
=== Trevinho_ is now known as Trevinho | ||
LocutusOfBorg | hi cjwatson did the gemrb demote to multiverse fail? I still don't see it migrating | 09:23 |
---|---|---|
LocutusOfBorg | hi folks, what is missing to see liquidsoap migrate? I'm honestly lost in the ocaml stuff | 10:03 |
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:05 |
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 |
=== \b is now known as benonsoftware | ||
mapreri | LocutusOfBorg: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#biniou is your friend. | 10:06 |
LocutusOfBorg | yes, but botch is utterly broken, also in debian | 10:07 |
LocutusOfBorg | I saw that, but I guess some force-hints seems needed | 10:08 |
LocutusOfBorg | or demote | 10:08 |
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:10 |
LocutusOfBorg | because I don't feel good in giving orders, I like to mask them under a stupid question :) | 10:11 |
mapreri | :> | 10:11 |
=== Saviq_ is now known as Saviq | ||
cjwatson | LocutusOfBorg: oh right, need to do it in yakkety-proposed as well as yakkety. done | 10:19 |
LocutusOfBorg | thanks! I was wondering about how long would it take to be effective :) | 10:20 |
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 :) | 10:21 |
infinity | LocutusOfBorg: What "help" were you hoping for? You could help it by fixing goldendict... | 11:53 |
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) | 11:56 |
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:36 |
LocutusOfBorg | well, count is uint64_t, I can't cast to 32 bits | 12:38 |
LocutusOfBorg | forwarded upstream | 12:51 |
LocutusOfBorg | infinity, I guess it is a qt issue, because on debian/s390x is building now fine | 13:00 |
infinity | LocutusOfBorg: The last build log disagrees. Or did you just try on a porter? | 13:12 |
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:20 |
LocutusOfBorg | do you want to see a build? | 13:21 |
LocutusOfBorg | zelenka.debian.org has an ongoing build | 13:21 |
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:24 |
LocutusOfBorg | exactly, even symbols file arent showing differences | 13:25 |
LocutusOfBorg | moreover I already took the latest qt4 in my last attempt | 13:25 |
LocutusOfBorg | I'm seeing something interesting now | 13:26 |
LocutusOfBorg | "-DHAVE_X11" < is not passed in the porterbox | 13:26 |
LocutusOfBorg | but I see a -DQT_WEBKIT instead | 13:27 |
LocutusOfBorg | damn, the apt-get source is getting the testing version | 13:34 |
LocutusOfBorg | blah something is bad with unstable mirrors | 13:35 |
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:55 |
LocutusOfBorg | actually that file is coming from there, so I guess we are good | 13:56 |
infinity | LocutusOfBorg: That seems like an odd hack to work around qFromLittleEndian() breaking, if that's the real bug. | 13:57 |
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:58 |
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 | 13:59 |
LocutusOfBorg | https://github.com/goldendict/goldendict/issues/714 | 14:02 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
infinity | Oookay. | 14:10 |
ogra_ | (there was a long and heated discussion about SRUing ... i kind of lost :/ ) | 14:10 |
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:11 |
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:12 |
cjwatson | infinity: Hopefully; it's bug 1586770 | 14:13 |
ubot5 | bug 1586770 in python-libnacl (Ubuntu Xenial) "Add pymacaroons to xenial" [High,In progress] https://launchpad.net/bugs/1586770 | 14:13 |
ogra_ | instead of exposing it on cdimage at all | 14:13 |
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:14 |
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:15 |
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:17 |
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:18 |
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:19 |
cjwatson | infinity: added | 14:21 |
infinity | cjwatson: ^^ | 14:24 |
cjwatson | yay, thanks | 14:24 |
infinity | cjwatson: Will babysit binary NEW, but if I get distracted, feel free to self-accept. | 14:25 |
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:28 |
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. | 14:31 |
jbicha | could I get a yes or no on bug 1584522 please? | 15:16 |
ubot5 | bug 1584522 in One Hundred Papercuts "[UIFe] Don't show GNOME Books by default" [Medium,Triaged] https://launchpad.net/bugs/1584522 | 15:16 |
infinity | jbicha: Seems entirely reasonable to me, +1 | 15:55 |
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 | 16:37 |
=== tyhicks` is now known as tyhicks | ||
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:41 |
slangasek | sergiusens: if you are following https://wiki.ubuntu.com/SnapcraftUpdates, it should not get stuck | 20:59 |
sergiusens | slangasek yeah, we are following that, it's just that this is the first time snapcraft gets stuck in the 'new' queue | 21:02 |
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:12 |
sergiusens | slangasek I just checked and you happen to be one :-) | 21:18 |
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:19 | |
slangasek | no blockers, but best practice is to look at lintian output for both the source and binary packages | 21:20 |
slangasek | ^^ and, accepted for yakkety | 21:21 |
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:23 |
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! | 21:24 |
=== bluesabre is now known as bluesabre1 | ||
=== bluesabre1 is now known as bluesabre |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!