=== _salem is now known as salem_ === dupingping__ is now known as dupingping === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [02:00] cjwatson, pitti, and anyone else interested: I'm finally putting together my application to upgrade to full core-dev, if you could sponsor me, I would appreciate it: https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication2 [02:05] psusi: no stackexchange / askubuntu mention? [02:06] I guess I could add that now ;) [02:06] don't think it was around back when I applied for contrib ;) [02:10] hehe I think I stumbled on one of your answers from 2011 or something the other day. at least that's my vague memory :) [02:12] Scott James Remnant was one of my sponsors for contrib and he's been gone for how long now? hehe... [02:12] iirc he left before I joined up, so > three years :) [02:14] * psusi is *finally* getting around to converting update-grub to use dpkg-triggers so no more dozens of several minutes long update-grubs during a dist-upgrade... [02:14] just had to get annoyed at it for the millionth time [02:15] psusi: oooh will that also fix the case when removing six kernels that the grub config is updated six times? [02:24] sarnold, bingo [02:25] psusi: yay! :) [02:25] which is *really* annoying for me because I have a dozen different logical volumes with different releases in them and probing them all takes *forever* [02:26] I filed a bug asking for it to be done a few years back when triggers were added hoping someone else would have time to do it before I did... finally got fed up enough with the waiting to just do it [02:31] psusi: All the best, but I'm sure you'll have no problem getting plus votes, given how long you've been involved. [02:32] TheMuso, thanks... surprised it has taken me this long to get off my arse and apply ;) [02:32] I guess I was complacent for a while there since pushing a bzr branch and requesting a merge worked fine... but UDD seems to be dieing [02:34] now if only it were being replaced with a similar system built on git-dpm... cjwatson really had a stroke of genius on that one [02:56] Back in the day, I enjoyed bzr... Now I find myself finding the experience unpleasant... [03:03] I found bzr tolerable. git is great... as long as you have a high pain tolerance. GNU still uses CVS to manage their project web pages and I just can't force myself to use CVS ever again === _salem is now known as salem_ [04:56] barry: I suppose at this point no interest in fastimport? :P [06:00] Good morning [06:31] pitti: it'd look like a faulty pkg-kde-tools exploded half of autopkgtests, but there'd seem to be a fixed version now in there [06:31] Mirv: good morning [06:31] Mirv: ah, I was about to ask, this looked horrible [06:31] thanks to yofel for the fix [06:43] Mirv: still upgrading base images, will mass-retry after that [06:46] pitti: thank you (and good morning) === cpaelzer is now known as cpaelzer_afk [07:46] good morning - i'm looking at update excuses... what needs to happen for petsc? does it need to be decrufted? [08:01] good morning [08:07] * pitti does a mass-retry of all failed autopkgtests, with the fixed pkg-kde-tools [08:07] hey dholbach! [08:08] hey pitti [08:08] hey there ;-) [08:32] tvoss, bug #1524130 just got filed, btw [08:32] bug 1524130 in unity8 (Ubuntu) "/usr/bin/unity8:11:__memcpy_neon:std::char_traits:std::basic_streambuf:std::basic_streambuf:std::__ostream_write" [Undecided,New] https://launchpad.net/bugs/1524130 [08:32] Saviq, yeah, just saw that [08:34] Saviq, it's a race on shutdown, but only finding time today to look into it in more detail === cpaelzer_afk is now known as cpaelzer [08:39] tvoss, ack, nw [09:22] pitti: hey again. any chance of a backport of that dbusmock revision into the stable overlay again? (we're still making dual landings for everything in the convergence world) === nudtrobert1 is now known as nudtrobert [10:21] * xnox is annoyed i got kicked out of my irc proxy [10:23] hi xnox! [10:23] looks like the woes are cleaning up a bit [10:23] Laney, a bit, but there are a tonnes of autopkgtest regression on qtbase with really something weird and broken. [10:24] pitti: have you noticed these random systemd errors https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/q/qtmir/20151209_101924@/log.gz ? [10:24] they got retried [10:24] if you mean the kdebase thing [10:24] erm pkg-kde-tools [10:24] xnox: a faulty pkg-kde-tools was uploaded which broke all kde tests [10:24] so some time wasted and now again back on track [10:24] Mirv, cool. [10:30] tvoss, is platform-api dual-landable? I can see there's a different package in xenial and overlay, and there's a separate /15.04 series, I hope it's just that it was never dual-landed yet? [10:31] Saviq, it is dual-landable again [10:31] Saviq, I will close down the 15.04 branch soon'ish [10:32] tvoss, ack, tx [10:35] Laney, libreoffice is still building... [10:36] cjwatson, did i break the world - http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20151209.log ? [10:36] IOError: [Errno 2] No such file or directory: '/srv/cdimage.ubuntu.com/ftp/dists/xenial/main/debian-installer/binary-s390x/Packages.gz' [10:37] not sure who is responsible for these sort of things... Laney ^ ? [10:37] xnox: yeah, I tried to give you a way to upload it earlier to get ahead on the armhf build [10:41] xnox: it's true that this doesn't exist but also I don't know how that mirror gets there [10:42] ok. horum ok. cjwatson infinity slangasek - could you please look at, maybe it makes some sense for you http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20151209.log [10:42] Laney, i bet something somewhere, needs to be taught that s390x is a split arch on ports, or some such. [10:43] The machine has a mirror which doesn't contain s390x [10:45] Laney, are there any more "cdimagy" branches i can modify? i did ubuntu-cdimage, live-build, livefs-rootfs. Are there more? [10:49] xnox: AFAICS this mirror is updated by anonftpsync in cdimage, but I don't see any arch-specific bits here [10:50] Laney, i remember is did adjust things, to mirror things, for ppc64el when we brought that up. mkay. === cpaelzer is now known as cpaelzer_afk [10:59] xnox: Looks like the mirror hasn't been updated since Nov 13 [10:59] But build.py is supposed to do that, so I wonder why that isn't happening [11:03] Laney, unless the lock is held. [11:03] Doesn't seem to be [11:03] Laney, or e.g. mirnyy.ubuntu.com doesn't have s390x. [11:03] no, that's just an example. [11:04] Laney, is there a "production/anonftpsync" somewhere? [11:04] yes, it points to ftpmaster.internal [11:04] Laney, and that, clearly, does have s390x et.al. [11:05] even the rsync.log file is from Nov 13 [11:05] I feel out of my depth :) [11:05] Laney, i blame that Nov 13 was a Friday, hence the world broke =) === vrruiz_ is now known as rvr [11:13] xnox: I'll sort it out [11:13] cjwatson, thanks. === cpaelzer_afk is now known as cpaelzer [11:14] doko, i'm thinking to teach hardening-wrapper about -no-pie [11:14] xnox, hardening-wrapper should die [11:15] $ reverse-depends -b src:hardening-wrapper --list | wc -l [11:15] 119 [11:15] cleared the lock, trying again [11:15] which lock was it? [11:15] (Nov 13 is too long ago to realistically investigate why it was held) [11:15] xnox, see the rc issue in Debian. kees isn't replying :-/ [11:15] cdimage/etc/.sem-build-image-set [11:15] ah [11:15] but important to check that there are no builds running before nuking it [11:15] I was looking for the anonftpsync one [11:16] if cdimage thinks that another build is running, it won't sync the mirror [11:16] note the "Parallel build" indicator in the log file [11:17] but there is a lurking bug somewhere that doesn't always clear the lock when it should === _salem is now known as salem_ === greyback__ is now known as greyback === cpaelzer is now known as cpaelzer_afk === cpaelzer_afk is now known as cpaelzer === salem_ is now known as _salem === marcusto_ is now known as marcustomlinson [12:32] infinity: You were right all that time ago when you guessed that Python try/finally doesn't cope with the case where cdimage is killed with certain signals. This should at long last fix our occasional woes: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1557 [12:33] xnox,Laney: ^- [12:35] \o/ [12:35] nice, thanks [12:35] Only taken me about seventeen failed attempts of staring at that before realising the obvious [12:36] Was clinging onto beliefs about try/finally which weren't true [12:36] (Obviously lots of other signals *could* happen, but those are the likely ones - aside from SIGINT, which already turns into KeyboardInterrupt) [12:37] ... so images had old stuff on them since 13th of november? i guess the debs, not the livefs things, cause livefs are built in launchpad and were all up to date. [12:37] I investigated what happened on 13 Nov - there were two ubuntu-core builds that were abruptly terminated before proceeding [12:37] cyphermox: are you looking at installer stuff? might want to look at bug 1523199 [12:37] bug 1523199 in debian-installer (Ubuntu) "Wily installer uses wrong seed location for systemd-random-seed.service" [Undecided,New] https://launchpad.net/bugs/1523199 [12:37] My guess is that somebody either killed them from another terminal, or used Ctrl-\ (SIGQUIT) [12:38] Because Ctrl-C wouldn't have caused this problem [12:38] xnox: Only the pool, indeed [12:41] Took cdimage an hour and a half to sync the archive after all that, but it's making progress now [12:43] UnknownArchitecture: No live filesystem builder known for s390x [12:43] Sigh, I wondered if that would happen [12:44] cjwatson, i thought i fixed things like that before. [12:44] No, this is weird legacy stuff [12:44] e.g. live-build livefs does succeed in launchpad. [12:44] I thought about it when reviewing your branch but decided it wouldn't happen :) [12:44] Yeah, the problem is that it tries to look for an old-style builder anyway [12:44] * xnox eye rolls -> i didn't do those buildd name tests [12:45] Fixing === dholbach_ is now known as dholbach [12:52] pitti: still some systemd timed out errors on some of the tests, will you rerun those? [12:53] Mirv, pitti: can you give examples? i believe that in the maintainer scripts systemctl commands should use --root=/ that way most of the things happen without talking/connecting to systemd [12:54] and instead done by the systemctl itself on the filesystem. [12:54] is it still the policykit-1 or some such? [12:54] (with --root=/ systemctl just fiddles with files in /run /etc, instead of trying to talk to systemd and ask that to do stuff) === _salem is now known as salem_ [12:59] Mirv: I retried all the regressions for ease, let's see [13:00] cjwatson: See, logically, I was fairly sure I was right (since it matched the symptoms), but proving it was harder, especially with my crap python skills. :P [13:00] cjwatson: Thanks for the fix! [13:00] xnox: pitti: http://is.gd/nMqBSz + http://is.gd/6pXahh + http://is.gd/BOvAm8 - armhf only? [13:00] thanks Iain [13:04] pitti: No script to make CDs bootable for s390x ... [13:04] err [13:04] pitti: sorry [13:04] xnox: No script to make CDs bootable for s390x ... [13:04] xnox: looks like we need some debian-cd backports; lp:~ubuntu-cdimage/debian-cd/ubuntu [13:12] cjwatson, well zipl should be run on the image. i shall look into that. [13:13] This branch is an import of the Bazaar branch at http://people.canonical.com/~cjwatson/bzr/debian-cd/ubuntu. [13:13] interesting [13:14] cjwatson, i'll look into that. [13:16] xnox: it'll probably involve backporting from https://anonscm.debian.org/cgit/debian-cd/debian-cd.git, though the branches are very very very very very diverged [13:16] xnox: I think still not a totally implausible backport though [13:17] xnox: that doesn't run zipl (which might not be possible bearing in mind that nusakan is x86?), but does stuff by hand [13:17] cjwatson, it could do nothing at all as well. [13:18] as there generally is no way to "boot iso" [13:18] let me finish poking qt* things [13:18] and then i'll look into debian-cd. [13:18] Yeah, what I was hearing was that the ISO is meant to just be mounted as an ftp/http mirror and you use the d-i build on the ISO to netboot. [13:19] Would be nice if we could do better than that, but not sure if that's possible. [13:20] that script has to do something, because it's what puts the installer bits onto the image [13:20] infinity: can you make me a member of the ubuntu installer team, please? [13:20] and Debian seems to have bothered to make it at least semi-bootable in some way, I assume they wouldn't just have done that for fun [13:20] mdeslaur, why? =) [13:20] infinity: oh wait, you're not an admin [13:20] xnox: can you? I have a fix to push [13:21] mdeslaur: Though, "why" is still a valid question. [13:21] mdeslaur, and the mandatory question - do you know how to filter tonnes of bug mail spam? [13:21] mdeslaur, merge proposals are welcome ;-) [13:21] xnox: ah crud, good point [13:21] * mdeslaur doesn't want more email [13:21] mdeslaur, it's a LOT of email [13:21] mdeslaur: Just give us an MP, or point at a debdiff and I'll commit for you?> [13:21] yeah, I guess :) [13:22] mdeslaur, make a merge proposal and like ping cyphermox about it. [13:22] infinity: sure, one ec [13:22] mdeslaur, bzr diff | pastebin works too ;-) [13:22] jamespage: just noticed that https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/xz-indexes/+merge/277880 failed again but I didn't notice in time for the build artifacts to still exist [13:22] jamespage: is this automated testing really going to be useful for this particular MP? [13:23] Mirv: yes, I saw; Laney, can you please mass-retry the armhf tests? [13:23] Laney: oh, you already did, thanks [13:24] Laney: seems we currently have a mass-killing from both plymouth and the new lxd.. [13:24] Laney: I'll see to turning those into normal failures, but not here [13:26] infinity: https://code.launchpad.net/~mdeslaur/ubiquity/fix-random-seed/+merge/280018 [13:27] morning [13:27] cyphermox: ^ [13:27] hi cyphermox [13:27] (Timing!) [13:27] yeah, I'm looking [13:28] mdeslaur: Oh, curious. I have both paths on this system, but the /var/lib/urandom one hasn't been touched since July. Should we be migrating/cleaning on upgrade if that's obsolete somehow? [13:28] mdeslaur: Or hardlinking them? [13:28] infinity: the old path belongs to the initscripts package [13:29] PS: Why does systemd need to "standardize" by randomly moving stuff around? [13:29] mdeslaur: Well, "belongs"... It doesn't belong to any package, from dpkg's POV. [13:30] update-alternatives: error: no alternatives for default.plymouth [13:30] sed: can't read /usr/share/plymouth/themes/.plymouth/.plymouth.plymouth: No such file or directory [13:30] E: /usr/share/initramfs-tools/hooks/plymouth failed with return 2. [13:30] didrocks: ^ any idea? [13:30] didrocks: that happens on autopkgtests (and serial-kills workers, but that's my problem) [13:30] infinity: well, the directory does. You want to remove the file? [13:30] init.d/urandom:SAVEDFILE=/var/lib/urandom/random-seed [13:30] Hrm. [13:30] do we still need /var/lib/urandom/random-seed for anything, like in the initramfs or something? [13:30] pitti: it's fixed already [13:30] cyphermox: I hope not, because it's not being updated [13:30] pitti: -3ubuntu2 FTW ;) [13:30] mdeslaur: I know ;_ [13:31] pitti: happened when you install the text theme without the logo one… [13:32] mdeslaur: Well, it's only updated if you're running sysvinit, which we don't support. [13:32] didrocks: ah, très bien; merci ! [13:32] Still feels like those should have just been the same location, though. [13:32] yeah [13:32] Which would be fixable in /lib/systemd/system/systemd-random-seed.service [13:33] pitti: dsl d'avoir cassé ton testbed ;) [13:33] And /lib/systemd/systemd-random-seed ... [13:33] mdeslaur, isn't it deprecated with 4.2 or 4.3 kernels anyway, and random-seed does nothing anymore. [13:33] xnox: Why would it do nothing? [13:33] infinity: I'm sure pitti won't mind more debian-specific stuff in systemd [13:33] xnox: Sure looks like it does something here. [13:33] infinity, because kernel no longer uses seeds. [13:33] xnox: hrm? [13:33] * xnox is looking for references [13:34] xnox: "kernel no longer uses seeds" sounds scary :) [13:34] mdeslaur: Either a hardlink or symlink between locations feels like the more correctly Debian-upstreamable thing to me. [13:35] mdeslaur: Since it's theoretically possible to flip-flop between systemd and sysv between boots. [13:35] Any current Ubuntu PHP maintainers around? [13:36] ondrej: We don't have anyone dedicated to PHP. [13:36] hi folks, nobody available for a quick backport? [13:36] ondrej: Closest you'd find is rbasak, perhaps. [13:36] [12:04:30] valhalla_: cosa intendi per "disco morto"? [13:36] oops [13:36] mdeslaur, infinity: http://lists.freedesktop.org/archives/systemd-devel/2015-June/033297.html [13:36] ondrej: Or, if there's something you want to argue about, I'm always up for telling people they're wrong. [13:36] ondrej: o/ [13:36] https://bugs.launchpad.net/wily-backports/+bug/1512982 [13:36] Launchpad bug 1512982 in wily-backports "Please backport hedgewars 0.9.22-dfsg-2 (universe) from xenial" [Undecided,New] [13:36] which points to http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-Crypto-Akcipher-PKE [13:37] and http://marc.info/?l=linux-kernel&m=143496272614455&w=2 [13:37] xnox: huh, interesting [13:37] ondrej: so I've been following php7.0 but haven't looked into it yet. [13:37] ondrej: your advice would be much appreciated. [13:37] xnox: Curious. [13:37] rbasak: just wanted to ask what are your plans for next LTS? PHP 7.0 or not? And if yes, there's a lot work to be done yet, and I could use some help polishing the new packaging :) [13:38] mdeslaur, infinity: basically it does crazy cpu jitter deltas to "seed" things on boot. [13:38] rbasak: my advice would be to go for PHP 7.0 and help me prepare transition path :-P [13:38] but honestly I don't think you can release without it [13:38] ondrej: I've not decided yet. My concern is how stable it will be at release. [13:38] xnox: So perhaps we can just drop those hunks from the installer entirely, rather than changing the path. [13:38] mdeslaur: ^ [13:39] infinity, yes. [13:39] ondrej: I don't want to release something that is horribly broken or extremely painful to fix after release due to SRU policy, that's all. [13:39] ondrej: if it's good, then I'd love to have 7.0 replace 5.6 and be in main in Xenial. [13:39] ondrej: do you have a list of what is outstanding? [13:40] rbasak: there's an option of keeping both (the old src:php5 and new src:php7.0), but it will need some work (there are some conflicts, mainly phar) [13:40] cjwatson, no I'm just going to land it [13:41] I'm not very keen on having both. It doubles maintenance work. Even though in theory 7.0 would be in universe and thus off my plate, in practice that doesn't happen. [13:41] infinity: mdeslaur: I'll all for removing code [13:41] We did it with MySQL 5.5 and 5.6 in Trusty, and even though 5.6 was in universe I think users had expectations about it. [13:41] rbasak: Yeah, concur, please don't ship two versions of PHP, it's insanity. [13:42] rbasak: Take it from someone who had to support both php3 and php4, and then both php4 and php5, it's hell. [13:42] ondrej: ^ [13:42] jamespage: ah, excellent, thanks [13:42] ondrej: Surely, you still remember the bad old days. :P [13:42] rbasak: I still can't build PECL extensions for multiple versions of PHP that could be coinstalled now (although I understand it's not high priority for Ubuntu stable release); PEAR got recently splitted out, so it might be broken [13:43] infinity: I remember only php4+php5 :) fortunately [13:43] ondrej: I'd rather just see php7 in experimental ASAP, and then slowly work out all rdeps until they all seem to more or less work, then just transition. Shipping both sucks. [13:43] ondrej: But that's just advice, since I washed my hands of PHP years ago, I get no real vote. :P [13:44] (I do, however, get some very strong votes about what's acceptable in Ubuntu) [13:44] infinity: the main php7 upload already made it to unstable, but I am missing other pieces and bits still in NEW (f.e. dh-php) [13:45] I see only two options. 1) Continue shipping php5 5.6 in main in Xenial, delete php7.0 from Xenial universe and blacklist it from autosync for this cycle. [13:45] 2) Move to php7.0 in main in Xenial. [13:45] rbasak, ondrej: it doesn't have to be default. php7 was uploaded into debian, so presumibly it is co-installable with 5, hence we will have it available, at least in universe. [13:45] 3) [ruled out] Ship 5.6 in main and 7.0 in universe. [13:45] rbasak: With my TB and release hats on, I concur. [13:46] xnox: As pointed out, that never works out for us in practice. [13:46] infinity: speaking of php (codecoverage specifically) - chroots with bootstrap archive pls? [13:46] xnox: Users love shiny. If we give them old in main and shiny in universe, they'll run shiny and complain when it sucks. [13:46] rbasak: I would advice start with checking what's in ppa:ondrej/php right now, I think it's manageable to polish it into Xenial if I have some help with testing and bit of patches [13:46] infinity, cyphermox, xnox: I'm uncomfortable making the call to drop the random seed for now [13:46] infinity: and if we give them old in main and nothing in universe, they'll still fetch shiny from somewhere and complain when it sukcs :) [13:46] *sucks [13:46] rbasak: from what I hear from people they are all keep on moving to php7 since the breakage is not so horrible [13:46] cjwatson: Yes, but they complain less directly to us. :P [13:47] cjwatson: fortunately, most of those grab the new and shiny from me :) [13:47] so not that bad [13:47] ondrej: off-topic, I think you have a MySQL PPA that is causing some breakage amongst users. [13:47] mdeslaur, i shall check the kernel source code again, i believe they left the seed writing there, but it's a no-op that does nothing. [13:47] mdeslaur, if that is the case, then i'll drop it for xenial and up. [13:48] xnox: if it is a no-op, then that's fine [13:49] rbasak: I have a issue tracker on github and I have only one bugreport about MySQL (something about process hanging on installation), haven't got time to look at it. [13:49] xnox: if you want to drop it, might want to review my merge again if you still want to test boot my changes [13:49] :D [13:49] ondrej: And yes, if 7.x isn't "production-ready" for xenial, I'd rather we don't ship it in universe at all, and let users get the shiny from your PPA. Cause we won't commit to supporting it very well (or at all), so we'd just be leading people down the garden path. [13:50] infinity: I concur and I have much easier job, since I just blame upstream when something breaks :) [13:50] ondrej: So, I'll let you and rbasak sort out how to get to "production-ready" and how long that will take, but with my various hats on, I think exclusively 5 or exclusively 7 are the only reasonable options for Ubuntu. [13:50] ondrej: I'm looking for a bug reference for you. It looks like users using your PPA ended up with some bits from the Ubuntu archive which are now (or were for a while) a higher version. [13:50] ondrej: And as a mostly uninterested bystander, I think only 7 should be a goal for Debian too. [13:51] mysql-common from one place and mysql-server-5.x from the other [13:51] infinity: rbasak: if you stay with php5 we should definitely make php5-fpm and php7.0-fpm coinstallable [13:51] ondrej: what I'd really like to see right now is a list of everything you think needs doing to make 7 ready. [13:51] infinity: Definitely, the only side-goal I have is to have an option to support multiple versions installed from third-party (mine) repository [13:52] ondrej: then we can inform an interim decision about which of the two options to aim for. [13:52] xnox: it says "DRBG is now seeded with both /dev/random and Jitter RNG.", but the random seed file is to seed /dev/random [13:52] xnox: random.c still mentions seeding being necessary [13:52] * mdeslaur isn't convinced yet [13:56] rbasak: everything that B-D on php5-dev needs to manually converted to php-all-dev (also s/dh-php5/dh-php/), checked and recompiled, same goes for everything that Depends on "php5" and variants [13:57] I only upgraded PECL exts that people care about [13:58] * rbasak looks [14:00] ondrej: any known bugs or shortcomings in the packaging that might bite us? [14:02] rbasak: debbugs#805222 - pkg-php-tools can't build PECL extensions now [14:04] rbasak: one more thing you should add to your consideration -> If you go with PHP 7.0.n where n is a small number you will probably end up with more security patches than if you stay with 5.6.m where m is a high number; on the other hand security support for PHP 5.6 ends on 28 Aug 2017 and it will be much harder to backport security patches from 7.0 tree because of changed internals [14:04] ondrej: thanks. [14:04] ondrej: re #805222 it's because of broken PEAR 1.10.1 [14:04] Security update are a factor for mdeslaur or sarnold to consider: ^^ [14:05] I assume they're OK to move to something newer though. Less backporting work for them I think. [14:05] rbasak: so perhaps the biggest help you could do is to look at php5 and php7.0 and come with a way how to make most of the packages live side by side [14:05] ondrej: why focus on making them live side by side? [14:06] ondrej: can we not just go for it and get everything migrated if we decide to get it done? [14:06] Something newer is preferable, but the fact that it's a .0 release is a bit problematic [14:06] rbasak: because that would help the users who want to stay with the old PHP 5.6 (yes, I still have inquiries about PHP 5.3) if you go with PHP 7, but also users who want new&shiny if you stay with PHP5 [14:06] that's when all the new features are introduced and quickly get rewritten/fixed [14:07] so there's usually a lot of code churn between a .0 and the next couple of point releases [14:07] which makes our job harder [14:07] ondrej: IMHO, Ubuntu users who want to stay on a previous PHP version can stay on a previous Ubuntu release. [14:07] (unless we decide to stick to 5.6 in Xenial) [14:08] mdeslaur: rbasak: right, the amount of security patches that go to 5.5.x is smaller than for 5.6.x [14:08] If it was something like 7.0.2, it would be a no-brainer [14:09] mdeslaur: so where are you on the balance of 5.6 vs. 7.0 in Xenial? [14:09] Maybe there's a chance that there will be a 7.0.2 before Xenial is released? [14:09] rbasak: well, it shouldn't be a huge amount of work acording to this user, who tried to tackle this: #807165 [14:09] for 7.0.0, there are pros and cons from a security point of view, so I don't have a stong opinion [14:09] rbasak: it would probably be easier to support 7.0.x in the LTS release [14:10] OTOH, if we ship 7 in Xenial then presumably that will increase the number of users of PHP 7.0 significantly over the next year, so we'll have created the problem ourselves, IYSWIM. [14:10] rbasak: as long as the big code churn changes are done in the first couple of point releases [14:10] mdeslaur: OK, thanks. [14:10] that's from a security point of vue [14:10] view [14:10] what users want in an LTS at this point in time, I don't know [14:11] I've been thinking about "what users want in an LTS at this point in time" [14:11] I've come to the conclusion that 7.0 would be better than 5.6 for Xenial from this perspective. [14:11] ok [14:11] Just because users who want to stay on 5.x can just stay on Trusty. [14:11] that's true [14:11] And they can move to Xenial and 7.0 at their own pace. [14:11] good point [14:12] but yeah, please don't ship two in the archive [14:13] ondrej: I think from both my Ubuntu and Canonical hats I can't justify spending time on co-installability. [14:13] ondrej: since that's not a goal at all for Ubuntu - in fact we specifically don't want it. [14:13] rbasak: I would be happy to add you to pkg-php alioth group if you want making changes directly in the main repo (or in the branch) [14:13] Thanks [14:13] I'm rbasak-guest on alioth. [14:13] rbasak: then please take care of all dependencies down the tree [14:14] That's something more palatable for me in principle I think. [14:14] I need to consider whether it's feasible to get this all done in time for Xenial feature freeze. [14:14] Given my other responsibilities too. [14:15] infinity: what do you think about leaving some reverse deps in universe behind if I run out of time? [14:15] infinity: suboptimal I know, but is it completely unacceptable? [14:16] If I focus on reverse deps in main I think that's probably feasible (though I haven't looked) [14:16] rbasak: alioth done [14:16] Thank you! [14:17] I have to go now, thanks for the chat and conclusion [14:18] xnox, infinity, cyphermox: I believe the comment on the systemd list is wrong and the random seed is still necessary. [14:18] mdeslaur, can you email systemd-devel about it please? [14:18] ondrej: thank you for bringing the discussion to us! [14:19] mdeslaur, and/or present your finding? i am a bit lost in the kernel code and i see that jitter is used to seed a lot of things, but i can't tell if everything uses it. [14:19] xnox: you're looking at the crypto stuff, the random devices don't use that at all AFAIK [14:21] wow [14:21] oh, i have a lot of whitespace. [14:22] haha [14:24] Laney, i thought i got switched to a RTL mode for a second, as it seemed like i'm typing RTL. [14:25] Does anybody develop ubuntu on a Windows Laptop? [14:28] xnox: I did have some short-term Wubi installs a long time ago. === fginther` is now known as fginther [14:28] xnox: however the lesson learnt from that is that relying Windows NTFS underneath wasn't such a great idea [14:29] Laney: I'm not sure if it's about hinting you sometimes do, but okteta on all archs would need to run its tests with the proposed version of qca-qt5 included - see the one pass here http://autopkgtest.ubuntu.com/packages/o/okteta/xenial/amd64/ [14:29] the newer runs are with the older qca [14:30] Mirv: hmm, I wonder how to do that [14:30] it tries to minimise the things used from proposed [14:31] let me try it with multiple --trigger [14:32] and qtmir-gles would also need hinting to run with updated qtbase-opensource-src (not just qtbase-opensource-src-gles) sources included so that libqt5test5 gets to its updated version so that the autopkgtest finds the version of libqt5test5 it expects to find [14:32] http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/xenial/amd64/ [14:33] or of course if wanting to just migrate one can check that both did succeed earlier and force migration _if_ everything else just happens to be in order - xnox, have you decrypted update_output lately on what needs to be done? [14:34] Mirv, no, cause there is no full update_output, when things are "not considered" due to autopkgtests. I believe i have unwound all the poppler changes. [14:34] I don't even find qtbase there at the moment, so I guess there's nothing to read yet [14:34] xnox: right, exactly [14:34] the issues I mentioned above are the ones remaining afaik [14:34] and they are kind of non-issues [14:35] Mirv, well, i'm gonna do another declarative upload with fixed symbols for s390x, which will trigger builds of the rest of the qt5.5 things. [14:35] * xnox ponders if i'm allowed to copy builds into the archive from a nonvirt ppa, instead of rebuilding things. [14:36] xnox: are you sure it's worth the delay at this point in case we could migrate everything to release pocket within a few hours? I mean, it seems every time we're near migration, something "happens" somewhere like pkg-kde-tools yesterday. [14:37] xnox: anyway, if you do consider please build with -v parameter so that 5.5.1-2ubuntu1 gets included in the .changes file so that LP hopefully gets full updates to all of the bug reports [14:37] xnox: that's OK if it's exactly correctly configured - needs to have debug symbol settings matching the archive, etc. [14:37] when they're finally fix released [14:37] xnox: which archive so I can check? [14:37] Mirv: that shouldn't matter [14:37] cjwatson, i think it's not -> https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages [14:37] Mirv: we need that for the SRU reports, but otherwise, LP should work it out for itself nowadays [14:37] cjwatson: I was thinking about the texts that get automatically put to the LP reports. ah, nice if there have been fixes. [14:37] cjwatson, uses proposed, but all components instead of matching to start with. [14:38] cjwatson, and doesn't build debug symbols, nor publishes them. [14:38] well yeah all PPAs use all components, that doesn't necessarily stop us copying from them [14:38] Mirv: those should be calculated from the copy ancestry [14:38] but debug symbols would be an impediment [14:38] xnox: furthermore, I don't think you necessarily get that much further with just qtdeclarative. next stop might be qtwebkit/qttools and only after those it starts to be a breeze. but as before, I'd really like to have these all migrate to release pocket as soon as possible as it's causing all kinds of trouble on the phone to have silos stuck. [14:39] xnox: for the future, you can flip the debug symbol settings yourself on +edit [14:39] cjwatson, yeap. [14:39] Mirv, i'm not convinced thigs will migrate, even if we mark all of them to skip all of autopkgtests. [14:40] xnox: it'd be nice to find out before causing more autopkgtests to be run. then if it seems it's something that again takes more time than a little, it wouldn't hurt to have qtdeclarative restarting jobs again. [14:41] every day I'm getting questions from almost every time that if the migration is happening or not... [14:41] s/time/team/ [14:41] Mirv, well that's easy to answer "no" =) it's only a "yes" when it migrates =) [14:42] pitti, Laney: there is a lot of green, can we mark remaining autopkgtests to be ingored and see if britney migrates things? [14:42] xnox: well, but it's not just a question but a plea to get it done asap to have landings work fluently again [14:43] Mirv, all landings should be building against -proposed, what's the problem with them? you can totally release them into xenial-proposed. [14:43] xnox: meanwhile you could see if you can build qtwebkit + qttools + qtmultimedia (in that order) for s390x. when those work and no symbol updates are needed, the rest of the modules would work pretty well. but before qttools works (requires qtwebkit), the rest won't build [14:43] silos aren't released until things migrate, which is deliberate so that people pay attention to migration [14:43] Mirv, if you are telling me they build against xenial-release, without proposed..... that's where they are going wrong =) [14:44] xnox, Mirv: can do; only the octeta issue holds it for now, so like last time I'll ignore that [14:44] cjwatson, ok. [14:44] cjwatson, can you give me disk space in https://launchpad.net/~xnox/+archive/ubuntu/nonvirt please =) [14:44] xnox: no, the problem is that landings don't merge to trunks, and people don't know what's the real status of their landings and if there's something blocking the migration other than Qt migration. so the train basically does not function as usual since everything is blocked in proposed. [14:44]