MirvLaney: one day later, we're back to clean update_output.txt but now with UITK s390x fixed06:55
Mirvthe familiar packages are still listed there06:55
Trevinhorelase team, could you please unblock the sync from ppas in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= ?07:44
seb128Trevinho, it's a SRU team job, not a release team one07:49
seb128but yeah it would be nice if our main desktop SRUs weren't let sitting in the queue :-)07:49
seb128though it seems not much have been reviewed for a week, we are feeling that pitti is on holidays :p07:50
Trevinhoseb128: I know... but there's no sru team channel :)07:52
seb128right, but they are on #ubuntu-devel07:52
seb128Trevinho, https://wiki.ubuntu.com/StableReleaseUpdates has a publishing schedule and arges on shift for today, you might maybe convince him to do some reviews if he's not on vac08:01
Trevinhoyeah, I noticed that... but i guess it's still early for him08:02
LaneyMirv: OK, looking - at least ffmpeg needs to go green08:28
LaneySeems to be having trouble on armhf, but somebody already retried that08:28
LaneyAnd vlc too08:31
MirvLaney: I retried them yes, but they might be some real problems too08:32
Mirvdoes that https://code.launchpad.net/~timo-jyrinki/click/dont_use_@_in_testscontrol/+merge/302514 make sense to land? since the packagekit plugin is still mentioned in debian/control, "@" in debian/tests/control is my guess of causing that autopkgtest failure http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#click08:34
MirvLaney: anyway, with some copies to yakkety-proposed I just did, and that click branch, I'm officially out of ideas. for example, I don't understand that camitk that doesn't seem to be webp related, and all insighttoolkit4 related rebuilds have been done08:36
Laneyinsightoolkit4 isn't in the hint that you're looking at08:36
Laneythere's a bigger one further up08:36
LaneyWhich is mainly blocked on ffmpeg and webp stuff as far as I can tell right now08:36
Mirvoh, ok08:37
Mirvsil2100: ^ you'll be interested too, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt08:37
LaneyMirv: do you have access to snakefruit.canonical.com?08:37
Mirvwell I may have fixed some rtaudio migration issues with rebuilds now too, even if maybe unneeded. that's because I was looking at the lower hint and saw jacktrip.08:38
MirvLaney: no.08:38
Laneyok, but you can still use the script I was going to show you at home08:39
Laneythis is something I wrote a year or two ago to help with figuring out update_output.txt issues08:39
Laneydo: update-output-helper -u; update-output-helper <the 'trying easy from' hint you are looking at>08:40
Laneythen it gives you an apt command that you put the broken packages into, to see why they aren't installable08:40
Mirvthe bigger hint section seemed worse since it has more packages uninstallable08:46
Laneyyou don't always get to choose though08:46
Laneyif there are entangled transitions08:46
Mirvwith that I can see webp would be involved, but I couldn't decipher the ffmpeg out of it. (I gave the apt command all the hundred+ packages)08:46
Laneyif you are using the script, look at the smaller one08:47
Mirv(http://pastebin.ubuntu.com/22893716/ is what I got)08:48
Laneyit's easier to try one package at a time08:48
LaneyMirv: I use it like this https://paste.ubuntu.com/22893833/08:50
Mirvsure is it if there are not hundreds of them. with the smaller hint section I at least "correctly" (incorrectly) get insighttoolkit, rtaudio, plasma-discover-updater, and libwebp608:50
LaneyIterate by adding the packages that it tells you are a problem08:50
Mirvbut that is also incorrect since muon-notifier/muon-updater have already been updated to not depend on the disappearing plasma-discover-updater08:51
MirvLaney: right.08:52
Laney/usr/bin/ld.gold: --secure-plt: unknown option08:55
Laneywhat's that?08:55
Mirvit's a GCC6 feature.08:57
xnoxwhy use gold?09:06
MirvI'm disabling the gold on powerpc because of that for Qt 5, as suggested by do_ko09:06
xnoxMirv, why are you even use gold anywhere? all/most speed improvements of gold are long time in ld, and thus using gold is pointless everywhere.09:06
xnoxthe old dogma that "gold" is so much better, is not quite true any more.09:07
xnoxanyway, /me goes back fighting with firefox09:08
LaneyTrying a test build of ffmpeg on porter-armhf09:08
Laneydon't know about vlc/s390x, looks like it's going to timeout09:08
xnoxi'm still on firefox, so haven't looked into vlc yet.09:08
Laneydoko did an upload to make it use -O209:08
Laneybut looks like the build is hung to me, no output for 30 minutes or so09:09
Laneyi'll brb09:09
sil2100Laney: yeah, I see the armhf ffmpeg build dies reliably, one tests core-dumps with a Bus error09:09
Mirvxnox: I'd need to dig up Debian's git to see if there's any general reason or if it's an old habit09:10
xnoxMirv, right, also is gold upstream default?09:11
xnoxthat would be interesting, if it is.09:11
Mirvxnox: yes it's the default it seems09:12
Mirv(if available)09:12
dokoLaney, yes it's this issue, but -O3 is still passed. apparently I didn't read the configury stuff correctly09:18
Laneydoko: alright, thanks09:54
Laneysil2100: passes on porter-armhf, of course :(09:55
sil2100Now this is annoying09:58
xnoxLaney, porter box is read armhf, builders are arm64 virtual machines....09:59
sil2100I could try building that in an armhf chroot but that would take ages10:03
LaneyI wonder if I can get access to one of those10:03
Laneyvia my autopkgtest account probably10:03
xnoxLaney, if there is arm64 porter box, try armhf chroot on that? (if any are available...)10:04
Mirvok click fix, try two now in archives10:07
Laneyxnox: trying to remember how to work lxd :)10:07
xnoxLaney, i have not managed to get lxd work cross-arch =/ it tries to setup network and blows on netlink or some such.10:08
LaneyI think pitti says it sort of works, but is flaky10:09
Laneymaybe enough for this10:09
Mirvyeah, vlc s390x failed the second time10:09
Mirvthis time claiming ICE though10:09
Laneysame as always10:10
Mirvoh it was the earlier time too, ok10:10
Mirvforce build on gcc5... not much ideas10:10
Laneyd_oko is on it10:11
Mirvoh, ok10:11
Laneyxnox: I'm in, muhahaha10:12
Laneyoh yeah, it died10:20
LocutusOfBorgcjwatson, what about removing haskell-http-link-header on powerpc? it was never built on Debian, it built once for Ubuntu and now it is not building anymore, probably an hw issue on some powerpc machines, I prefer it to be kicked out since the probable patch is in the next ghc10:24
LocutusOfBorgBTW transition up to level 17 :)10:25
cjwatsonI don't object but I'm buried in other stuff right now.10:27
LocutusOfBorgI hope any other archive admin can help here ^^ slangasek :)10:28
LocutusOfBorgI don't want the next haskell-levels to use that binary in some obscure way, and have to remove many of them in the next few days10:28
cjwatsonoh, wait, it's just NBS in -proposed isn't it10:28
cjwatsonthat's trivial10:28
cjwatsonor not NBS but ... whatever10:28
LocutusOfBorgnever went to release10:29
cjwatsonLocutusOfBorg: removed10:29
cjwatsonBTW I'd recommend retrying build failures before doing unnecessary source uploads10:30
cjwatsonit's not very much effort to check for and it reduces the very large amount of noise on -changes a bit10:30
cjwatsone.g. haskell-wai-app-static, all architectures had previously failed on 3.1.5-1build3 so you could have just retried them all rather than uploading 3.1.5-1build410:31
LocutusOfBorgyou are right, not sure how I missed that10:34
LocutusOfBorgindeed a bug in my script10:34
LocutusOfBorgthanks, will check10:34
LocutusOfBorgI usually: copy paste the level from transition tracker, remove the stuff that is not red, cat file |cut -f 1 -d " " |cut -f 1 -d "[" > list10:49
LocutusOfBorgand then ubuntu-build and rebuild in case10:49
LocutusOfBorgdamn, there seems to be no return value from ubuntu-build :( so I can't just issue a rebuild in case there was no give-back issued10:52
Mirvsil2100: Laney: this would be readily built in case you come to a conclusion it could be acceptable for now for ffmpeg: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+sourcepub/6792728/+listing-archive-extra12:37
sil2100Mirv: hm, I would feel bad disabling all the tests just because of one core-dumping12:38
Mirvright, that's also an option, if there's just one.12:39
MirvI don't know though how to query architecture in those .mak files to skip some single alaw related lavftest12:49
Mirvanyway, those are options if wanted to go forward in trying the migration12:50
=== davmor2_ is now known as davmor2
Trevinhoarges: hey, you here?14:45
argesTrevinho: yes14:45
Trevinhoarges: hey14:45
Trevinhoarges: could you review the SRU queue for unity packages?14:46
argesTrevinho: sure14:46
Trevinhoarges: basically sync from https://requests.ci-train.ubuntu.com/#/ticket/1737 and https://requests.ci-train.ubuntu.com/#/ticket/177814:46
Trevinhoarges: thanks14:46
Trevinhopkg src I care more are frame, compiz and unity.14:47
LocutusOfBorgdamn, I tried haskell-http-conduit in a qemu armhf pbuilder environment, everything is good and testsuite passes15:30
argesTrevinho: i messed with bug 1350523, just to confirm frame is fixed in yakkety?15:52
ubot5bug 1350523 in frame "compiz assert failure: compiz: device.cpp:147: float frame_device_get_window_resolution_x(UFDevice): Assertion `status == UFStatusSuccess' failed." [Medium,In progress] https://launchpad.net/bugs/135052315:52
Trevinhoarges: yes15:53
argesTrevinho: and could you add the SRU template to that bug (makes it easier to review) thanks15:54
Trevinhoarges: sure15:54
Trevinhonot that it's possible to reproduce it in a certain way...15:56
seb128Trevinho, well then point to the e.u.c entry or ask to test for no regression at least16:00
bdmurraytjaalton: I've worked around the libwayland-egl1-mesa issue from bug 1610434 by adding it to the list of metapackages, however now a couple of other packages were not upgraded and I'm not sure whether or not to worry about it.17:04
ubot5bug 1610434 in xorg-lts-xenial (Ubuntu) "Ubuntu GNOME Trusty HWE upgrade fails to install libwayland-egl1-mesa-lts-xenial" [High,Triaged] https://launchpad.net/bugs/161043417:04
=== davmor2 is now known as davmor2_Hols
bdmurrayslangasek: I've found multiple bad translations of a string in ubuntu-release-upgrader which are causing tracebacks e.g. https://errors.ubuntu.com/problem/50c8f7b892dd75b531ac7d68a07ec1154138701319:16
bdmurrayIs that fixable via an SRU or are the translations separate?19:17
slangasekbdmurray: do we have some way to detect such mismatches at package build time?19:17
slangasekI imagine those translations are in ubuntu-release-upgrader, but maybe they're in the langpacks19:17
bdmurrayslangasek: I don't think there is anything currently setup to detect the mismatch.  This does seem like a familiar problem though so how could we do that?19:19
ginggshi, would someone remove the armhf binaries from wine-development, please?19:31
sergiusensarges or slangasek later in the day can you release the lock on snapcraft 2.14/xenial-proposed so it gets to -updates?19:38
argessergiusens: i can do it19:39
slangasekbdmurray: for other format string types (such as C format strings), I know there are tools to check compatibility at build time.  For python format strings I'm not sure what we have; maybe barry or cjwatson would know19:39
slangaseksergiusens: ^^ your on-call SRU team member for today :)19:40
slangasekginggs: what about arm64?19:40
slangasekginggs: n/m, I see it's built but not reflected yet on p-m19:41
argessergiusens: done19:42
ginggsslangasek: yup, the builds take a little longer on arm. LP: #1611922 for the reason19:42
ubot5Launchpad bug 1611922 in wine-development (Ubuntu) "FTBFS on armhf" [Undecided,New] https://launchpad.net/bugs/161192219:42
slangasekginggs: this same version of wine-development appears to have built successfully on armhf in Debian. why do we want it removed instead of fixed?19:43
ginggsslangasek: it would be great to get it fixed, but i don't see it happening soon19:46
barrybdmurray, slangasek: you want to extract i18n strings from python code?  modern xgettext should be able to do that, if they're marked with _('')20:27
slangasekbarry: validation that the translations don't have mismatched format strings20:28
slangasekwhich is something that we really want to catch at build time instead of tripping over at runtime20:28
slangasekI know we've hardened LP translation support against this sort of problem before, but don't know if/how it applies in the python case20:29
barryi thought msgfmt did that, but it's been a while20:29
Saviqcan someone please restart the regressions here with all-proposed https://requests.ci-train.ubuntu.com/static/britney/ticket-1771/landing-001-yakkety/excuses.html? it's still Qt 5.6 migration that didn't happen20:35
cjwatsonslangasek: right, msgfmt checks this provided that xgettext detected it as a format string and emitted an appropriate flag in the .po file21:19
cjwatson.pot file I mean21:19
* cjwatson pokes around21:21
cjwatsonNo python-format flag there ...21:26
cjwatsonAh, it's because xgettext doesn't know which language check-new-release-gtk is in21:30
cjwatsonI see at least one oops there (for hr) that was fixed in lp:ubuntu-release-upgrader on 2015-02-12, so there may be something to look into there too21:34
cjwatsonslangasek,barry: right, so with http://paste.ubuntu.com/22958656/, that string is correctly marked as fuzzy once the translation files are updated in the usual way, which will cause it not to be used21:37
cjwatsonslangasek,barry: however somebody should look at how to sort it out properly for the other Python programs in that package, which don't all have convenient .py symlinks that we can abuse for this purpose :)21:38
cjwatsonbdmurray: ^-21:38
tjaaltonbdmurray: ok, I'll have a look tomorrow21:47
bdmurraytjaalton: thease the packages that weren't upgraded - http://pastebin.ubuntu.com/22929072/21:47
bdmurraytjaalton: e.g. xserver-xorg-video-r128-lts-vivid was installed but the same lts-xenial package didn't get installed21:48
tjaaltonbdmurray: mouse is no more, and r128/mach64 were not part of -video-all in wily either21:50
bdmurraytjaalton: but they were in utopic/vivid though right?21:51
bdmurrayI think the object of HWE support is to get people off the lts-u/v/w (which they'd have if they just installed from 14.04.2...) packages on to lts-x.21:53
tjaaltonactually the metapackages were identical in vivid/wily21:58
bdmurrayWhat are the metapackages for the HWE stack then?21:59
tjaaltonutopic didn't pull r128 either21:59
tjaaltonoh, it's -ati that depends on r128/mach6422:03
tjaaltonguess apt is just stupid then22:03
bdmurraythe hwe support code doesn't have xserver-xorg-video-all-lts-foo as a metapackage, adding that will probably fix things up22:04
tjaaltonor maybe because the depends were demoted to Suggests22:04
tjaaltonwhat support code?22:04
tjaaltonxserver-xorg-lts-foo should pull it22:04
tjaaltonand -input-all-lts-foo22:04
bdmurraywell, if xserver-xorg-lts-foo should pull it in, I don't know what happened...22:07
tjaaltonit's fine to not pull in -r128/-mach6422:08
bdmurrayit's fine to remove the vivid version and not pull in the xenial version?22:08
tjaaltonthe reason was that -ati demoted the depends to suggests22:08
tjaaltoni bet noone has such hw22:09
tjaaltonmach64 is from -9422:09
bdmurrayokay, I just don't want to strand someone22:09
tjaaltonr128 (for Rage) is 95-9922:10
slangasek"i bet no one has such hw"> too late for that thought22:18
slangasekif that was our position we should have not shipped those binary packages at all in the hwe stacks22:18
slangaseksince we *have* created them, we should make sure anyone who has installed them, rightly or wrongly, gets the correct upgrade path22:18
tjaaltonso a new -ati-lts-xenial then?22:25
tjaaltonbdmurray: probably needs a new bug22:30
tjaaltonfor sru22:30
bdmurraytjaalton: I'll submit the bug shortly22:32
infinitytjaalton: If that's where the deps came from, yeah.22:33
infinitybdmurray: The upgrader should probably also be making sure video-all and input-all are installed.  Consider it similar to how we ensure flavour-desktop is installed after release upgrade, just a sanity check.22:33
tjaaltonbdmurray: should I wait or upload it tomorrow?-)22:41
bdmurraytjaalton: your tomorrow works for me22:42
infinitybdmurray: The other options is dpkg -l \*-lts-wily | gawk '/^ii/ {print gsub("-lts-wily","-lts-xenial",$2); print $2}' | xargs apt-get install22:46
infinitybdmurray: Which is gross, but also catches the weird virtualbox-lts-* junk.22:46
infinityOh, that should be /^.i/ not /^ii/22:47
bdmurraytjaalton: bug 161198222:53
ubot5bug 1611982 in xorg-lts-xenial (Ubuntu) "HWE upgrade from vivid to xenial removes support for r128 and mach64" [Undecided,New] https://launchpad.net/bugs/161198222:53

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