[05:55] ok I guess the GCC6 is now causing autopkgtest problems, so long Qt, KDE migration. but unity8 itself would now pass autopkgtests, which was the last blocker before. [05:57] infinity: doesn't look like yak iso's built last night - or at least those which I'd expect to see a version dated 05 at this time [05:58] but could you somehow hint that always the latest unity8 would be used for autopkgtest? for example http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src uses the current release pocket version which cannot be installed with the new qtbase. [05:59] because otherwise even though eg unity-scope-click wouldn't segfault (gcc6? new boost?) the whole excuses page wouldn't be green because of the old unity8 results [06:00] of course, if you'd think it's acceptable, just allow Qt, KDE migrate to release pocket regardless of the new transition problems [06:00] among else unity-scope-click did pass before [06:04] now one of the tests segfault [06:05] anyway, feedback/help welcome, the Qt/KDE won't migrate by itself ever regardless, some hinting will be required [06:42] flocculant: Oh, right, I need to reenable cron. I had it off to not mess with my release. [06:42] :D [06:43] I thought it might have been something like that [06:45] flocculant: Fixed. [06:45] infinity: thanks - have a more relaxing day today :) [06:45] flocculant: I'm taking Friday off, so it better be relaxing. [06:46] \o/ [06:46] infinity: have a great weekend then [10:44] anybody working on ghc transition? [12:22] hi! Qt and KDE could migrate, but I need archive admin help [12:22] AAs, you can reject the older numix-gtk-theme [12:22] 1. qml-module-qtpositioning would need promoted to main so that qtlocation5-examples would work: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtlocation-opensource-src [12:23] 2. some more s390x binary removals would be needed that pitti was doing a lot because of the upstart problem: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtpurchasing-opensource-src and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings [12:25] seb128: ^ can you help? [12:26] plasma-workspace needs NBS removed too [12:28] Mirv, hm, confused. britney says libpay2 is not satisfyable on s390x, yet it is built there.... [12:28] Mirv, it is less work not to remove s390x.... [12:28] Mirv, sorry but not atm, using my other laptop/doing some debugging and I don't have easy access to the acl from there, maybe later when I'm back at my desk [12:29] huh, built but not available [12:29] it's been removed [12:29] https://launchpad.net/ubuntu/yakkety/s390x/libpay2 [12:29] why? [12:29] xnox: I remember pitti mentioning something about links, maybe the fact that it was binary copied from a PPA [12:29] whoever decided to delete upstart on s390x would have better fixed the build [12:30] slangasek, what does ANAIS stand for [12:30] it's costing way more effort to deal with the things that keep getting blocked that it would have been to fix the build [12:30] architecture not allowed in source [12:30] xnox: so there is a big list of reverse dependencies removed (but not all yet as shown), because upstart on s390x did not get fixed but removed instead [12:31] in this case it build-depends on libubuntu-app-launch2-dev [12:31] which is not present on s390x [12:32] to be fair we all do have better things to deal with then chasing ubuntu-app-launch on s390x, but i see how much churn such a removal is causing. [12:32] maybe we (I) should have listened to steve in the beginning and like not compile upstart on s390x at all [12:32] that's just broken because of upstart isn't it? [12:33] Laney, disable upstart testsuite on s390x, upload, live happily ever after? [12:33] heh [12:33] somebody (Steve?) said that the issue was no s390x though but building on xenial builders [12:34] kernel issue if I recall [12:34] seb128, infinity did [12:34] and that it's going to bite other archs if we need to SRU a fix to xenial [12:34] so maybe we do need to fix upstart [12:34] so somebody needs to fix upstart eventually anyway [12:34] anyway [12:34] the removal hasn't been followed through to the end [12:34] so now we have issues like this [12:34] but i don't get this claim.... aren't our virtual builders running xenial? [12:35] well now, but at the time the xenial upstart was built it was on older builders it seems [12:35] 3.13.0-92-generic [12:35] rebuild today wouldn't work [12:35] * Laney tests that claim [12:36] https://launchpad.net/~laney/+archive/ubuntu/ppa/+build/10568298 [12:37] i wonder why cloud-builders are not using xenial cloud images as base [12:37] for buildds [12:37] cjwatson, ^ or is the move gonna happen only after trusty is end of live? [12:37] how about using hwe xenial kernel in the trusty cloud image? [12:39] anyway, it'd be nice if an archive admin could promote the qml-module-qtpositioning , NBS remove plasma-workspace and then remove the packages being discussed if/when upstart isn't going to be fixed soon still [12:39] that would be removal of libqt5purchasing5 qtpurchasing5-dev ubuntu-system-settings on s390x, or something else/more? [12:40] I wonder if didrocks would be around if seb128 might not have time at the moment [12:40] Check they have a build-dep which will prevent the binaries coming back the next time [12:41] ok, checking [12:45] yes for qtpurchasing packages, they can't be built on s390x anymore thanks to pitti's removals [12:47] however ubuntu-system-settings would reappear on next build, something would need to be done about that [12:52] not sure about the preferred action there, could simply state u-s-s not to build on s390x [12:53] add a build-dep on upstart or ual or something [12:53] right that'd be easiest, I can propose that for the next u-s-s landing [12:54] I think US archive admins would be online soon, hopefully they can help with those actions above if Europeans don't have time to. I will do the u-s-s MP and check back later if there's anything else to help with, but it'd be a nice present to everyone to get the migration going (or at least closer to being reality) [13:05] made the MP https://code.launchpad.net/~timo-jyrinki/ubuntu-system-settings/stop_s390x_problems_depend_on_upstart/+merge/302143 [13:14] * xnox uploaded upstart into PPA with a testsuite fix [13:16] :-o [13:16] is it a fix or a workaround? :P [13:17] let's wait to see if it works [13:17] non-system non-session (so upstart pretending to act like pid 1, but running as pid whatever and non-root) fails to connect to dbus when told so whilst stuck processing and spawning system jobs and generates loads of "failed to start plymouth" and what not [13:18] that test case only tries to call "initctl version" to check that upstart connects to session dbus when asked [13:18] changed test-suite to spawn upstart with "--no-startup-event" such that upstart in such configuration is simply spawned and connects to dbus, but doesn't try to mess with anything else [13:19] makes the tests pass on my machine at least, previously failing. [13:19] https://launchpadlibrarian.net/277265629/upstart_1.13.2-0ubuntu28_1.13.2-0ubuntu29.diff.gz [13:20] or hmm would apw still be around? [13:22] anyhow, I'd propose trying to get Qt & KDE migrated today with the actions above, and if there is some hope with upstart start re-enabling the chain of s390x next week [13:23] hm, somethings wrong build on amd64 done, still pending on s390x [13:25] still fails on s390x [14:17] Mirv: qtpurchasing/s390x binaries removed from yakkety-proposed; qml-module-qtpositioning promoted to main [14:18] was there anything else? [14:21] slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-workspace NBS [14:22] removed [14:22] Wooo \o/ [14:22] Let's see if we have more problems down the stack now [14:24] can't imagine this will be the end of the story [14:25] but it'll be clearer [15:10] slangasek: sil2100: hi, thanks! there was also ubuntu-system-settings/s390x removal http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings [15:10] and then a relook at update_output.txt probably [15:10] although u-s-s is actually not strictly required for the transition I think [15:11] since it does not depend on the private Qt ABI. I might be wrong too. more help with parsing excuses&output would be welcome. [15:14] Mirv: if I delete ubuntu-system-settings/s390x now, what prevents it from coming back again? [15:14] does it have any build-dependencies on s390x NBS packages? [15:15] he just made a MP to add that [15:16] a synthetic BD on upstart, or equivalent [15:16] slangasek: ^- [15:16] ok [15:20] Yeah, I reviewed that change, so it's just a matter of getting that MP released [15:25] I just think that's not necessarily the current remaining blocker but something else is, as u-s-s should not be a required part of the transition [15:26] * Mirv -> shopping [15:29] (neither is mediascanner, scopes-api etc) [16:51] sil2100: slangasek: can you check if something should be simple hinted a bit more to migrate together? if I look at update_output.txt and the last occurence of qtbase including Trying easy from autohinter section, it claims relatively little amount of packages "uninstallable" (or the per architecture list), but for example gammaray, plasma-desktop, plasma-workspace can be installed together [16:52] all of KDE needs to go in, as parts of it depend on Qt private 5.6 ABI and all of Frameworks / Plasma release in proposed depends on each other to go together [16:53] there are some in the lists though that do not need to migrate together with Qt/KDE [16:54] the combined set of packages that I know need to mostly go in together is the list of source names at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-011/+packages + https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+packages [16:54] others not so [16:56] anyway, even if I would have more time I think I cannot think of anything else myself, I can install everything required in my yakkety-proposed while some unrelated stuff like lubuntu-qt-desktop has problems (lubuntu meta depends on Laney / tedg 's click breaking / packagekit upgrade I think) [16:58] It'll be a bit irksome if you get entangled with that one [17:01] finally ubuntu-release-upgrader is running, now samba has settled down [17:10] Mirv: looks to me like the current problem is autopkgtests still running for plasma-workspace [17:58] hi. there is an issue with users wanting to upgrade from the EOL 15.04 right now. regular upgrade doesnt work and EOL upgrade with old-releases isnt activated yet. see bug #1609796 [17:58] bug 1609796 in update-manager-core (Ubuntu) "cant upgrade EOL 15.04" [Undecided,New] https://launchpad.net/bugs/1609796 [17:59] running do-release-upgrade -d works, strangely, but i doubt that is the planned way to upgrade the 15.04 now [18:34] infinity, bdmurray: ^^ I guess that's because 15.10 had the EOL switch flipped? [18:37] Erk, yeah, it's not been mirrored yet. [18:37] I guess I can flip it back until that's sorted. [18:41] slangasek: Reverted. Will sort it all out on Monday. [18:43] slangasek: Although, the bug report is more than just old-releases mirroring, we really *should* be supporting vivid->xenial, so probably need some SRUs to address that too. [18:43] ubuntu-release-upgrader has DistUpgrade.cfg files that allow upgrading from W -> X or T -> X. We could add more I guess. [18:44] Anyhow, it should be okayish with the revert for now, we can sort the proper solution. [18:44] infinity: did you update the changelogs server too? [18:44] ok, just tested my 15.04 vbox install and the do-release-upgrade now works. [18:44] bdmurray: Yep. [18:46] * infinity goes back to not being here, and wondering why he didn't buy a bunch of USB-C cables with his new phone. [18:46] imho there should be a decision if there should be a non-LTS upgrade path overstepping some releases. iirc there were some issues when 14.10 went EOL, too. [18:47] k1l_: Yes, I think the right answer is that we should always support upgrades to the next LTS directly, but that means testing those upgrade paths, not just flipping a switch and hoping. :) [18:48] yeah. but when 14.10 goes EOL there is no next LTS :/ imho there are some points of upgrade through that 4 years timeframe that need to have a rethink. [18:49] we had lots of users in #ubuntu wanting to go from 14.04(.X) to 15.10. but the releases inbetween were EOL already. [18:52] I thought the work I did in bug 1497024 should have allowed that. [18:52] bug 1497024 in update-manager (Ubuntu Vivid) "release upgrades should jump over unsupported releases" [High,Fix released] https://launchpad.net/bugs/1497024 [18:55] bdmurray: ok. than maybe there is just some needed clarification on what upgrade-path is supported on what situation. in #ubuntu there were a lot of issues with the jumping over releases so most supporters told to do EOL-upgrades. [19:03] k1l_: where would you want to see that clarification? [19:05] bdmurray: on the upgrade pages in the help or wiki dokumentation? so we have something to show people what the designed and tested upgradeplan is. [20:20] Mirv: so, plasma-workspace autopkgtests are failing on all archs, that's not going to migrate on its own [20:21] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-workspace === maclin1 is now known as maclin [21:48] slangasek: please badtest those, 2 of those test try to open windows that need to be closed by hand [21:48] I'll patch those out of the next upload [22:16] yofel: done, thanks