| Mirv | Laney: one day later, we're back to clean update_output.txt but now with UITK s390x fixed | 06:55 |
|---|---|---|
| Mirv | the familiar packages are still listed there | 06:55 |
| Trevinho | relase team, could you please unblock the sync from ppas in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= ? | 07:44 |
| seb128 | Trevinho, it's a SRU team job, not a release team one | 07:49 |
| seb128 | but yeah it would be nice if our main desktop SRUs weren't let sitting in the queue :-) | 07:49 |
| seb128 | though it seems not much have been reviewed for a week, we are feeling that pitti is on holidays :p | 07:50 |
| Trevinho | seb128: I know... but there's no sru team channel :) | 07:52 |
| seb128 | right, but they are on #ubuntu-devel | 07:52 |
| seb128 | Trevinho, 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 vac | 08:01 |
| Trevinho | yeah, I noticed that... but i guess it's still early for him | 08:02 |
| seb128 | yeah | 08:03 |
| Laney | Mirv: OK, looking - at least ffmpeg needs to go green | 08:28 |
| Laney | Seems to be having trouble on armhf, but somebody already retried that | 08:28 |
| Laney | And vlc too | 08:31 |
| Mirv | Laney: I retried them yes, but they might be some real problems too | 08:32 |
| Laney | Yes | 08:33 |
| Mirv | does 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#click | 08:34 |
| Mirv | Laney: 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 done | 08:36 |
| Laney | insightoolkit4 isn't in the hint that you're looking at | 08:36 |
| Laney | there's a bigger one further up | 08:36 |
| Laney | Which is mainly blocked on ffmpeg and webp stuff as far as I can tell right now | 08:36 |
| Mirv | oh, ok | 08:37 |
| Mirv | sil2100: ^ you'll be interested too, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt | 08:37 |
| Laney | Mirv: do you have access to snakefruit.canonical.com? | 08:37 |
| Mirv | well 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 |
| Mirv | Laney: no. | 08:38 |
| Laney | ok, but you can still use the script I was going to show you at home | 08:39 |
| Laney | https://bazaar.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper/download/head:/updateoutputhelper-20150813155719-m20yfaytzwyju4hk-1/update-output-helper | 08:39 |
| Laney | this is something I wrote a year or two ago to help with figuring out update_output.txt issues | 08:39 |
| Laney | do: update-output-helper -u; update-output-helper <the 'trying easy from' hint you are looking at> | 08:40 |
| Laney | then it gives you an apt command that you put the broken packages into, to see why they aren't installable | 08:40 |
| Mirv | wow | 08:41 |
| sil2100 | wow | 08:45 |
| Mirv | the bigger hint section seemed worse since it has more packages uninstallable | 08:46 |
| Laney | you don't always get to choose though | 08:46 |
| Laney | if there are entangled transitions | 08:46 |
| Mirv | with 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 |
| Laney | if you are using the script, look at the smaller one | 08:47 |
| Mirv | (http://pastebin.ubuntu.com/22893716/ is what I got) | 08:48 |
| Laney | it's easier to try one package at a time | 08:48 |
| Laney | Mirv: I use it like this https://paste.ubuntu.com/22893833/ | 08:50 |
| Mirv | sure 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 libwebp6 | 08:50 |
| Laney | Iterate by adding the packages that it tells you are a problem | 08:50 |
| Mirv | but that is also incorrect since muon-notifier/muon-updater have already been updated to not depend on the disappearing plasma-discover-updater | 08:51 |
| Mirv | Laney: right. | 08:52 |
| Laney | /usr/bin/ld.gold: --secure-plt: unknown option | 08:55 |
| Laney | what's that? | 08:55 |
| Mirv | it's a GCC6 feature. | 08:57 |
| xnox | why use gold? | 09:06 |
| Mirv | I'm disabling the gold on powerpc because of that for Qt 5, as suggested by do_ko | 09:06 |
| xnox | Mirv, 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 |
| xnox | the old dogma that "gold" is so much better, is not quite true any more. | 09:07 |
| xnox | anyway, /me goes back fighting with firefox | 09:08 |
| Laney | Trying a test build of ffmpeg on porter-armhf | 09:08 |
| Laney | don't know about vlc/s390x, looks like it's going to timeout | 09:08 |
| xnox | i'm still on firefox, so haven't looked into vlc yet. | 09:08 |
| Laney | doko did an upload to make it use -O2 | 09:08 |
| Laney | but looks like the build is hung to me, no output for 30 minutes or so | 09:09 |
| Laney | i'll brb | 09:09 |
| sil2100 | Laney: yeah, I see the armhf ffmpeg build dies reliably, one tests core-dumps with a Bus error | 09:09 |
| Mirv | xnox: I'd need to dig up Debian's git to see if there's any general reason or if it's an old habit | 09:10 |
| xnox | Mirv, right, also is gold upstream default? | 09:11 |
| xnox | that would be interesting, if it is. | 09:11 |
| Mirv | xnox: yes it's the default it seems | 09:12 |
| Mirv | (if available) | 09:12 |
| doko | Laney, yes it's this issue, but -O3 is still passed. apparently I didn't read the configury stuff correctly | 09:18 |
| Laney | doko: alright, thanks | 09:54 |
| Laney | sil2100: passes on porter-armhf, of course :( | 09:55 |
| sil2100 | :| | 09:58 |
| sil2100 | Now this is annoying | 09:58 |
| xnox | Laney, porter box is read armhf, builders are arm64 virtual machines.... | 09:59 |
| xnox | *real | 09:59 |
| Laney | shrug | 10:02 |
| sil2100 | I could try building that in an armhf chroot but that would take ages | 10:03 |
| Laney | I wonder if I can get access to one of those | 10:03 |
| Laney | via my autopkgtest account probably | 10:03 |
| xnox | Laney, if there is arm64 porter box, try armhf chroot on that? (if any are available...) | 10:04 |
| Mirv | ok click fix, try two now in archives | 10:07 |
| Laney | xnox: trying to remember how to work lxd :) | 10:07 |
| xnox | Laney, i have not managed to get lxd work cross-arch =/ it tries to setup network and blows on netlink or some such. | 10:08 |
| Laney | I think pitti says it sort of works, but is flaky | 10:09 |
| Laney | maybe enough for this | 10:09 |
| Mirv | yeah, vlc s390x failed the second time | 10:09 |
| Mirv | this time claiming ICE though | 10:09 |
| Laney | same as always | 10:10 |
| Mirv | oh it was the earlier time too, ok | 10:10 |
| Mirv | force build on gcc5... not much ideas | 10:10 |
| Laney | d_oko is on it | 10:11 |
| Mirv | oh, ok | 10:11 |
| Laney | xnox: I'm in, muhahaha | 10:12 |
| Laney | oh yeah, it died | 10:20 |
| LocutusOfBorg | cjwatson, 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 ghc | 10:24 |
| LocutusOfBorg | BTW transition up to level 17 :) | 10:25 |
| cjwatson | I don't object but I'm buried in other stuff right now. | 10:27 |
| LocutusOfBorg | I hope any other archive admin can help here ^^ slangasek :) | 10:28 |
| LocutusOfBorg | I 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 days | 10:28 |
| cjwatson | oh, wait, it's just NBS in -proposed isn't it | 10:28 |
| cjwatson | that's trivial | 10:28 |
| LocutusOfBorg | yes | 10:28 |
| cjwatson | or not NBS but ... whatever | 10:28 |
| LocutusOfBorg | never went to release | 10:29 |
| cjwatson | LocutusOfBorg: removed | 10:29 |
| LocutusOfBorg | ta | 10:29 |
| cjwatson | BTW I'd recommend retrying build failures before doing unnecessary source uploads | 10:30 |
| cjwatson | it's not very much effort to check for and it reduces the very large amount of noise on -changes a bit | 10:30 |
| cjwatson | e.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-1build4 | 10:31 |
| LocutusOfBorg | you are right, not sure how I missed that | 10:34 |
| LocutusOfBorg | indeed a bug in my script | 10:34 |
| LocutusOfBorg | thanks, will check | 10:34 |
| LocutusOfBorg | I 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 "[" > list | 10:49 |
| LocutusOfBorg | and then ubuntu-build and rebuild in case | 10:49 |
| LocutusOfBorg | damn, 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 issued | 10:52 |
| Mirv | sil2100: 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-extra | 12:37 |
| sil2100 | Mirv: hm, I would feel bad disabling all the tests just because of one core-dumping | 12:38 |
| Mirv | right, that's also an option, if there's just one. | 12:39 |
| Mirv | I don't know though how to query architecture in those .mak files to skip some single alaw related lavftest | 12:49 |
| Mirv | anyway, those are options if wanted to go forward in trying the migration | 12:50 |
| === davmor2_ is now known as davmor2 | ||
| Trevinho | arges: hey, you here? | 14:45 |
| arges | Trevinho: yes | 14:45 |
| Trevinho | arges: hey | 14:45 |
| Trevinho | arges: could you review the SRU queue for unity packages? | 14:46 |
| arges | Trevinho: sure | 14:46 |
| Trevinho | arges: basically sync from https://requests.ci-train.ubuntu.com/#/ticket/1737 and https://requests.ci-train.ubuntu.com/#/ticket/1778 | 14:46 |
| Trevinho | arges: thanks | 14:46 |
| Trevinho | pkg src I care more are frame, compiz and unity. | 14:47 |
| LocutusOfBorg | damn, I tried haskell-http-conduit in a qemu armhf pbuilder environment, everything is good and testsuite passes | 15:30 |
| arges | Trevinho: i messed with bug 1350523, just to confirm frame is fixed in yakkety? | 15:52 |
| ubot5 | bug 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/1350523 | 15:52 |
| Trevinho | arges: yes | 15:53 |
| arges | Trevinho: and could you add the SRU template to that bug (makes it easier to review) thanks | 15:54 |
| Trevinho | arges: sure | 15:54 |
| Trevinho | done | 15:56 |
| Trevinho | not that it's possible to reproduce it in a certain way... | 15:56 |
| seb128 | Trevinho, well then point to the e.u.c entry or ask to test for no regression at least | 16:00 |
| bdmurray | tjaalton: 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 |
| ubot5 | bug 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/1610434 | 17:04 |
| === davmor2 is now known as davmor2_Hols | ||
| bdmurray | slangasek: I've found multiple bad translations of a string in ubuntu-release-upgrader which are causing tracebacks e.g. https://errors.ubuntu.com/problem/50c8f7b892dd75b531ac7d68a07ec11541387013 | 19:16 |
| slangasek | :/ | 19:17 |
| bdmurray | Is that fixable via an SRU or are the translations separate? | 19:17 |
| slangasek | bdmurray: do we have some way to detect such mismatches at package build time? | 19:17 |
| slangasek | I imagine those translations are in ubuntu-release-upgrader, but maybe they're in the langpacks | 19:17 |
| bdmurray | slangasek: 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 |
| ginggs | hi, would someone remove the armhf binaries from wine-development, please? | 19:31 |
| sergiusens | arges or slangasek later in the day can you release the lock on snapcraft 2.14/xenial-proposed so it gets to -updates? | 19:38 |
| arges | sergiusens: i can do it | 19:39 |
| slangasek | bdmurray: 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 know | 19:39 |
| slangasek | sergiusens: ^^ your on-call SRU team member for today :) | 19:40 |
| slangasek | ginggs: what about arm64? | 19:40 |
| slangasek | ginggs: n/m, I see it's built but not reflected yet on p-m | 19:41 |
| arges | sergiusens: done | 19:42 |
| ginggs | slangasek: yup, the builds take a little longer on arm. LP: #1611922 for the reason | 19:42 |
| ubot5 | Launchpad bug 1611922 in wine-development (Ubuntu) "FTBFS on armhf" [Undecided,New] https://launchpad.net/bugs/1611922 | 19:42 |
| slangasek | ginggs: 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 |
| ginggs | slangasek: it would be great to get it fixed, but i don't see it happening soon | 19:46 |
| barry | bdmurray, 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 |
| slangasek | barry: validation that the translations don't have mismatched format strings | 20:28 |
| slangasek | which is something that we really want to catch at build time instead of tripping over at runtime | 20:28 |
| slangasek | I know we've hardened LP translation support against this sort of problem before, but don't know if/how it applies in the python case | 20:29 |
| barry | i thought msgfmt did that, but it's been a while | 20:29 |
| Saviq | can 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 happen | 20:35 |
| cjwatson | slangasek: right, msgfmt checks this provided that xgettext detected it as a format string and emitted an appropriate flag in the .po file | 21:19 |
| cjwatson | .pot file I mean | 21:19 |
| * cjwatson pokes around | 21:21 | |
| cjwatson | No python-format flag there ... | 21:26 |
| cjwatson | Ah, it's because xgettext doesn't know which language check-new-release-gtk is in | 21:30 |
| cjwatson | Maybe | 21:30 |
| cjwatson | I 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 too | 21:34 |
| cjwatson | slangasek,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 used | 21:37 |
| cjwatson | slangasek,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 |
| cjwatson | bdmurray: ^- | 21:38 |
| tjaalton | bdmurray: ok, I'll have a look tomorrow | 21:47 |
| bdmurray | tjaalton: thease the packages that weren't upgraded - http://pastebin.ubuntu.com/22929072/ | 21:47 |
| bdmurray | tjaalton: e.g. xserver-xorg-video-r128-lts-vivid was installed but the same lts-xenial package didn't get installed | 21:48 |
| tjaalton | bdmurray: mouse is no more, and r128/mach64 were not part of -video-all in wily either | 21:50 |
| bdmurray | tjaalton: but they were in utopic/vivid though right? | 21:51 |
| tjaalton | probably | 21:52 |
| bdmurray | I 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 |
| tjaalton | actually the metapackages were identical in vivid/wily | 21:58 |
| bdmurray | What are the metapackages for the HWE stack then? | 21:59 |
| tjaalton | utopic didn't pull r128 either | 21:59 |
| tjaalton | xserver-xorg-video-all-lts-foo | 21:59 |
| tjaalton | oh, it's -ati that depends on r128/mach64 | 22:03 |
| tjaalton | guess apt is just stupid then | 22:03 |
| bdmurray | the hwe support code doesn't have xserver-xorg-video-all-lts-foo as a metapackage, adding that will probably fix things up | 22:04 |
| tjaalton | or maybe because the depends were demoted to Suggests | 22:04 |
| tjaalton | what support code? | 22:04 |
| tjaalton | xserver-xorg-lts-foo should pull it | 22:04 |
| tjaalton | and -input-all-lts-foo | 22:04 |
| bdmurray | https://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/view/head:/hwe-support-status#L51 | 22:05 |
| bdmurray | well, if xserver-xorg-lts-foo should pull it in, I don't know what happened... | 22:07 |
| tjaalton | it's fine to not pull in -r128/-mach64 | 22:08 |
| bdmurray | it's fine to remove the vivid version and not pull in the xenial version? | 22:08 |
| tjaalton | the reason was that -ati demoted the depends to suggests | 22:08 |
| tjaalton | i bet noone has such hw | 22:09 |
| tjaalton | mach64 is from -94 | 22:09 |
| bdmurray | okay, I just don't want to strand someone | 22:09 |
| tjaalton | r128 (for Rage) is 95-99 | 22:10 |
| slangasek | "i bet no one has such hw"> too late for that thought | 22:18 |
| slangasek | if that was our position we should have not shipped those binary packages at all in the hwe stacks | 22:18 |
| slangasek | since we *have* created them, we should make sure anyone who has installed them, rightly or wrongly, gets the correct upgrade path | 22:18 |
| tjaalton | so a new -ati-lts-xenial then? | 22:25 |
| tjaalton | bdmurray: probably needs a new bug | 22:30 |
| tjaalton | for sru | 22:30 |
| bdmurray | tjaalton: I'll submit the bug shortly | 22:32 |
| infinity | tjaalton: If that's where the deps came from, yeah. | 22:33 |
| infinity | bdmurray: 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 |
| tjaalton | bdmurray: should I wait or upload it tomorrow?-) | 22:41 |
| bdmurray | tjaalton: your tomorrow works for me | 22:42 |
| tjaalton | cool | 22:44 |
| infinity | bdmurray: The other options is dpkg -l \*-lts-wily | gawk '/^ii/ {print gsub("-lts-wily","-lts-xenial",$2); print $2}' | xargs apt-get install | 22:46 |
| infinity | bdmurray: Which is gross, but also catches the weird virtualbox-lts-* junk. | 22:46 |
| infinity | Oh, that should be /^.i/ not /^ii/ | 22:47 |
| bdmurray | tjaalton: bug 1611982 | 22:53 |
| ubot5 | bug 1611982 in xorg-lts-xenial (Ubuntu) "HWE upgrade from vivid to xenial removes support for r128 and mach64" [Undecided,New] https://launchpad.net/bugs/1611982 | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!