| === _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 | ||
| psusi | 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:00 |
|---|---|---|
| sarnold | psusi: no stackexchange / askubuntu mention? | 02:05 |
| psusi | I guess I could add that now ;) | 02:06 |
| psusi | don't think it was around back when I applied for contrib ;) | 02:06 |
| sarnold | 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:10 |
| psusi | Scott James Remnant was one of my sponsors for contrib and he's been gone for how long now? hehe... | 02:12 |
| sarnold | iirc he left before I joined up, so > three years :) | 02:12 |
| * 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 | |
| psusi | just had to get annoyed at it for the millionth time | 02:14 |
| sarnold | psusi: oooh will that also fix the case when removing six kernels that the grub config is updated six times? | 02:15 |
| psusi | sarnold, bingo | 02:24 |
| sarnold | psusi: yay! :) | 02:25 |
| psusi | 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:25 |
| psusi | 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:26 |
| TheMuso | psusi: All the best, but I'm sure you'll have no problem getting plus votes, given how long you've been involved. | 02:31 |
| psusi | TheMuso, thanks... surprised it has taken me this long to get off my arse and apply ;) | 02:32 |
| psusi | 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:32 |
| psusi | 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:34 |
| TheMuso | Back in the day, I enjoyed bzr... Now I find myself finding the experience unpleasant... | 02:56 |
| psusi | 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 | 03:03 |
| === _salem is now known as salem_ | ||
| Unit193 | barry: I suppose at this point no interest in fastimport? :P | 04:56 |
| pitti | Good morning | 06:00 |
| Mirv | 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 |
| pitti | Mirv: good morning | 06:31 |
| pitti | Mirv: ah, I was about to ask, this looked horrible | 06:31 |
| Mirv | thanks to yofel for the fix | 06:31 |
| pitti | Mirv: still upgrading base images, will mass-retry after that | 06:43 |
| Mirv | pitti: thank you (and good morning) | 06:46 |
| === cpaelzer is now known as cpaelzer_afk | ||
| ginggs | good morning - i'm looking at update excuses... what needs to happen for petsc? does it need to be decrufted? | 07:46 |
| dholbach | good morning | 08:01 |
| * pitti does a mass-retry of all failed autopkgtests, with the fixed pkg-kde-tools | 08:07 | |
| pitti | hey dholbach! | 08:07 |
| dholbach | hey pitti | 08:08 |
| seb128 | hey there ;-) | 08:08 |
| Saviq | tvoss, bug #1524130 just got filed, btw | 08:32 |
| ubottu | 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 |
| tvoss | Saviq, yeah, just saw that | 08:32 |
| tvoss | Saviq, it's a race on shutdown, but only finding time today to look into it in more detail | 08:34 |
| === cpaelzer_afk is now known as cpaelzer | ||
| Saviq | tvoss, ack, nw | 08:39 |
| pete-woods | 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) | 09:22 |
| === nudtrobert1 is now known as nudtrobert | ||
| * xnox is annoyed i got kicked out of my irc proxy | 10:21 | |
| Laney | hi xnox! | 10:23 |
| Laney | looks like the woes are cleaning up a bit | 10:23 |
| xnox | Laney, a bit, but there are a tonnes of autopkgtest regression on qtbase with really something weird and broken. | 10:23 |
| Mirv | 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 |
| Laney | they got retried | 10:24 |
| Laney | if you mean the kdebase thing | 10:24 |
| Laney | erm pkg-kde-tools | 10:24 |
| Mirv | xnox: a faulty pkg-kde-tools was uploaded which broke all kde tests | 10:24 |
| Mirv | so some time wasted and now again back on track | 10:24 |
| xnox | Mirv, cool. | 10:24 |
| Saviq | 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:30 |
| tvoss | Saviq, it is dual-landable again | 10:31 |
| tvoss | Saviq, I will close down the 15.04 branch soon'ish | 10:31 |
| Saviq | tvoss, ack, tx | 10:32 |
| xnox | Laney, libreoffice is still building... | 10:35 |
| xnox | cjwatson, did i break the world - http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20151209.log ? | 10:36 |
| xnox | IOError: [Errno 2] No such file or directory: '/srv/cdimage.ubuntu.com/ftp/dists/xenial/main/debian-installer/binary-s390x/Packages.gz' | 10:36 |
| xnox | not sure who is responsible for these sort of things... Laney ^ ? | 10:37 |
| Laney | xnox: yeah, I tried to give you a way to upload it earlier to get ahead on the armhf build | 10:37 |
| Laney | xnox: it's true that this doesn't exist but also I don't know how that mirror gets there | 10:41 |
| xnox | 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 |
| xnox | Laney, i bet something somewhere, needs to be taught that s390x is a split arch on ports, or some such. | 10:42 |
| Laney | The machine has a mirror which doesn't contain s390x | 10:43 |
| xnox | Laney, are there any more "cdimagy" branches i can modify? i did ubuntu-cdimage, live-build, livefs-rootfs. Are there more? | 10:45 |
| Laney | xnox: AFAICS this mirror is updated by anonftpsync in cdimage, but I don't see any arch-specific bits here | 10:49 |
| xnox | Laney, i remember is did adjust things, to mirror things, for ppc64el when we brought that up. mkay. | 10:50 |
| === cpaelzer is now known as cpaelzer_afk | ||
| Laney | xnox: Looks like the mirror hasn't been updated since Nov 13 | 10:59 |
| Laney | But build.py is supposed to do that, so I wonder why that isn't happening | 10:59 |
| xnox | Laney, unless the lock is held. | 11:03 |
| Laney | Doesn't seem to be | 11:03 |
| xnox | Laney, or e.g. mirnyy.ubuntu.com doesn't have s390x. | 11:03 |
| xnox | no, that's just an example. | 11:03 |
| xnox | Laney, is there a "production/anonftpsync" somewhere? | 11:04 |
| Laney | yes, it points to ftpmaster.internal | 11:04 |
| xnox | Laney, and that, clearly, does have s390x et.al. | 11:04 |
| Laney | even the rsync.log file is from Nov 13 | 11:05 |
| Laney | I feel out of my depth :) | 11:05 |
| xnox | Laney, i blame that Nov 13 was a Friday, hence the world broke =) | 11:05 |
| === vrruiz_ is now known as rvr | ||
| cjwatson | xnox: I'll sort it out | 11:13 |
| xnox | cjwatson, thanks. | 11:13 |
| === cpaelzer_afk is now known as cpaelzer | ||
| xnox | doko, i'm thinking to teach hardening-wrapper about -no-pie | 11:14 |
| doko | xnox, hardening-wrapper should die | 11:14 |
| xnox | $ reverse-depends -b src:hardening-wrapper --list | wc -l | 11:15 |
| xnox | 119 | 11:15 |
| cjwatson | cleared the lock, trying again | 11:15 |
| Laney | which lock was it? | 11:15 |
| cjwatson | (Nov 13 is too long ago to realistically investigate why it was held) | 11:15 |
| doko | xnox, see the rc issue in Debian. kees isn't replying :-/ | 11:15 |
| cjwatson | cdimage/etc/.sem-build-image-set | 11:15 |
| Laney | ah | 11:15 |
| cjwatson | but important to check that there are no builds running before nuking it | 11:15 |
| Laney | I was looking for the anonftpsync one | 11:15 |
| cjwatson | if cdimage thinks that another build is running, it won't sync the mirror | 11:16 |
| cjwatson | note the "Parallel build" indicator in the log file | 11:16 |
| cjwatson | but there is a lurking bug somewhere that doesn't always clear the lock when it should | 11:17 |
| === _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 | ||
| cjwatson | 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:32 |
| cjwatson | xnox,Laney: ^- | 12:33 |
| xnox | \o/ | 12:35 |
| Laney | nice, thanks | 12:35 |
| cjwatson | Only taken me about seventeen failed attempts of staring at that before realising the obvious | 12:35 |
| cjwatson | Was clinging onto beliefs about try/finally which weren't true | 12:36 |
| cjwatson | (Obviously lots of other signals *could* happen, but those are the likely ones - aside from SIGINT, which already turns into KeyboardInterrupt) | 12:36 |
| xnox | ... 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 |
| cjwatson | I investigated what happened on 13 Nov - there were two ubuntu-core builds that were abruptly terminated before proceeding | 12:37 |
| mdeslaur | cyphermox: are you looking at installer stuff? might want to look at bug 1523199 | 12:37 |
| ubottu | 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 |
| cjwatson | My guess is that somebody either killed them from another terminal, or used Ctrl-\ (SIGQUIT) | 12:37 |
| cjwatson | Because Ctrl-C wouldn't have caused this problem | 12:38 |
| cjwatson | xnox: Only the pool, indeed | 12:38 |
| cjwatson | Took cdimage an hour and a half to sync the archive after all that, but it's making progress now | 12:41 |
| cjwatson | UnknownArchitecture: No live filesystem builder known for s390x | 12:43 |
| cjwatson | Sigh, I wondered if that would happen | 12:43 |
| xnox | cjwatson, i thought i fixed things like that before. | 12:44 |
| cjwatson | No, this is weird legacy stuff | 12:44 |
| xnox | e.g. live-build livefs does succeed in launchpad. | 12:44 |
| cjwatson | I thought about it when reviewing your branch but decided it wouldn't happen :) | 12:44 |
| cjwatson | 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:44 | |
| cjwatson | Fixing | 12:45 |
| === dholbach_ is now known as dholbach | ||
| Mirv | pitti: still some systemd timed out errors on some of the tests, will you rerun those? | 12:52 |
| xnox | 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:53 |
| xnox | and instead done by the systemctl itself on the filesystem. | 12:54 |
| xnox | is it still the policykit-1 or some such? | 12:54 |
| xnox | (with --root=/ systemctl just fiddles with files in /run /etc, instead of trying to talk to systemd and ask that to do stuff) | 12:54 |
| === _salem is now known as salem_ | ||
| Laney | Mirv: I retried all the regressions for ease, let's see | 12:59 |
| infinity | 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 |
| infinity | cjwatson: Thanks for the fix! | 13:00 |
| Mirv | xnox: pitti: http://is.gd/nMqBSz + http://is.gd/6pXahh + http://is.gd/BOvAm8 - armhf only? | 13:00 |
| Mirv | thanks Iain | 13:00 |
| cjwatson | pitti: No script to make CDs bootable for s390x ... | 13:04 |
| cjwatson | err | 13:04 |
| cjwatson | pitti: sorry | 13:04 |
| cjwatson | xnox: No script to make CDs bootable for s390x ... | 13:04 |
| cjwatson | xnox: looks like we need some debian-cd backports; lp:~ubuntu-cdimage/debian-cd/ubuntu | 13:04 |
| xnox | cjwatson, well zipl should be run on the image. i shall look into that. | 13:12 |
| xnox | This branch is an import of the Bazaar branch at http://people.canonical.com/~cjwatson/bzr/debian-cd/ubuntu. | 13:13 |
| xnox | interesting | 13:13 |
| xnox | cjwatson, i'll look into that. | 13:14 |
| cjwatson | 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 |
| cjwatson | xnox: I think still not a totally implausible backport though | 13:16 |
| cjwatson | 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 |
| xnox | cjwatson, it could do nothing at all as well. | 13:17 |
| xnox | as there generally is no way to "boot iso" | 13:18 |
| xnox | let me finish poking qt* things | 13:18 |
| xnox | and then i'll look into debian-cd. | 13:18 |
| infinity | 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:18 |
| infinity | Would be nice if we could do better than that, but not sure if that's possible. | 13:19 |
| cjwatson | that script has to do something, because it's what puts the installer bits onto the image | 13:20 |
| mdeslaur | infinity: can you make me a member of the ubuntu installer team, please? | 13:20 |
| cjwatson | 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 |
| xnox | mdeslaur, why? =) | 13:20 |
| mdeslaur | infinity: oh wait, you're not an admin | 13:20 |
| mdeslaur | xnox: can you? I have a fix to push | 13:20 |
| infinity | mdeslaur: Though, "why" is still a valid question. | 13:21 |
| xnox | mdeslaur, and the mandatory question - do you know how to filter tonnes of bug mail spam? | 13:21 |
| xnox | mdeslaur, merge proposals are welcome ;-) | 13:21 |
| mdeslaur | xnox: ah crud, good point | 13:21 |
| * mdeslaur doesn't want more email | 13:21 | |
| xnox | mdeslaur, it's a LOT of email | 13:21 |
| infinity | mdeslaur: Just give us an MP, or point at a debdiff and I'll commit for you?> | 13:21 |
| mdeslaur | yeah, I guess :) | 13:21 |
| xnox | mdeslaur, make a merge proposal and like ping cyphermox about it. | 13:22 |
| mdeslaur | infinity: sure, one ec | 13:22 |
| xnox | mdeslaur, bzr diff | pastebin works too ;-) | 13:22 |
| cjwatson | 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 |
| cjwatson | jamespage: is this automated testing really going to be useful for this particular MP? | 13:22 |
| pitti | Mirv: yes, I saw; Laney, can you please mass-retry the armhf tests? | 13:23 |
| pitti | Laney: oh, you already did, thanks | 13:23 |
| pitti | Laney: seems we currently have a mass-killing from both plymouth and the new lxd.. | 13:24 |
| pitti | Laney: I'll see to turning those into normal failures, but not here | 13:24 |
| mdeslaur | infinity: https://code.launchpad.net/~mdeslaur/ubiquity/fix-random-seed/+merge/280018 | 13:26 |
| cyphermox | morning | 13:27 |
| infinity | cyphermox: ^ | 13:27 |
| mdeslaur | hi cyphermox | 13:27 |
| infinity | (Timing!) | 13:27 |
| cyphermox | yeah, I'm looking | 13:27 |
| infinity | 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 |
| infinity | mdeslaur: Or hardlinking them? | 13:28 |
| mdeslaur | infinity: the old path belongs to the initscripts package | 13:28 |
| infinity | PS: Why does systemd need to "standardize" by randomly moving stuff around? | 13:29 |
| infinity | mdeslaur: Well, "belongs"... It doesn't belong to any package, from dpkg's POV. | 13:29 |
| pitti | update-alternatives: error: no alternatives for default.plymouth | 13:30 |
| pitti | sed: can't read /usr/share/plymouth/themes/.plymouth/.plymouth.plymouth: No such file or directory | 13:30 |
| pitti | E: /usr/share/initramfs-tools/hooks/plymouth failed with return 2. | 13:30 |
| pitti | didrocks: ^ any idea? | 13:30 |
| pitti | didrocks: that happens on autopkgtests (and serial-kills workers, but that's my problem) | 13:30 |
| mdeslaur | infinity: well, the directory does. You want to remove the file? | 13:30 |
| infinity | init.d/urandom:SAVEDFILE=/var/lib/urandom/random-seed | 13:30 |
| infinity | Hrm. | 13:30 |
| cyphermox | do we still need /var/lib/urandom/random-seed for anything, like in the initramfs or something? | 13:30 |
| didrocks | pitti: it's fixed already | 13:30 |
| mdeslaur | cyphermox: I hope not, because it's not being updated | 13:30 |
| didrocks | pitti: -3ubuntu2 FTW ;) | 13:30 |
| cyphermox | mdeslaur: I know ;_ | 13:30 |
| didrocks | pitti: happened when you install the text theme without the logo one… | 13:31 |
| infinity | mdeslaur: Well, it's only updated if you're running sysvinit, which we don't support. | 13:32 |
| pitti | didrocks: ah, très bien; merci ! | 13:32 |
| infinity | Still feels like those should have just been the same location, though. | 13:32 |
| mdeslaur | yeah | 13:32 |
| infinity | Which would be fixable in /lib/systemd/system/systemd-random-seed.service | 13:32 |
| didrocks | pitti: dsl d'avoir cassé ton testbed ;) | 13:33 |
| infinity | And /lib/systemd/systemd-random-seed ... | 13:33 |
| xnox | mdeslaur, isn't it deprecated with 4.2 or 4.3 kernels anyway, and random-seed does nothing anymore. | 13:33 |
| infinity | xnox: Why would it do nothing? | 13:33 |
| mdeslaur | infinity: I'm sure pitti won't mind more debian-specific stuff in systemd | 13:33 |
| infinity | xnox: Sure looks like it does something here. | 13:33 |
| xnox | infinity, because kernel no longer uses seeds. | 13:33 |
| mdeslaur | xnox: hrm? | 13:33 |
| * xnox is looking for references | 13:33 | |
| mdeslaur | xnox: "kernel no longer uses seeds" sounds scary :) | 13:34 |
| infinity | mdeslaur: Either a hardlink or symlink between locations feels like the more correctly Debian-upstreamable thing to me. | 13:34 |
| infinity | mdeslaur: Since it's theoretically possible to flip-flop between systemd and sysv between boots. | 13:35 |
| ondrej | Any current Ubuntu PHP maintainers around? | 13:35 |
| infinity | ondrej: We don't have anyone dedicated to PHP. | 13:36 |
| LocutusOfBorg1 | hi folks, nobody available for a quick backport? | 13:36 |
| infinity | ondrej: Closest you'd find is rbasak, perhaps. | 13:36 |
| LocutusOfBorg1 | [12:04:30] <mfv> valhalla_: cosa intendi per "disco morto"? | 13:36 |
| LocutusOfBorg1 | oops | 13:36 |
| xnox | mdeslaur, infinity: http://lists.freedesktop.org/archives/systemd-devel/2015-June/033297.html | 13:36 |
| infinity | ondrej: Or, if there's something you want to argue about, I'm always up for telling people they're wrong. | 13:36 |
| rbasak | ondrej: o/ | 13:36 |
| LocutusOfBorg1 | https://bugs.launchpad.net/wily-backports/+bug/1512982 | 13:36 |
| ubottu | Launchpad bug 1512982 in wily-backports "Please backport hedgewars 0.9.22-dfsg-2 (universe) from xenial" [Undecided,New] | 13:36 |
| xnox | which points to http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-Crypto-Akcipher-PKE | 13:36 |
| xnox | and http://marc.info/?l=linux-kernel&m=143496272614455&w=2 | 13:37 |
| mdeslaur | xnox: huh, interesting | 13:37 |
| rbasak | ondrej: so I've been following php7.0 but haven't looked into it yet. | 13:37 |
| rbasak | ondrej: your advice would be much appreciated. | 13:37 |
| infinity | xnox: Curious. | 13:37 |
| ondrej | 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:37 |
| xnox | mdeslaur, infinity: basically it does crazy cpu jitter deltas to "seed" things on boot. | 13:38 |
| ondrej | rbasak: my advice would be to go for PHP 7.0 and help me prepare transition path :-P | 13:38 |
| ondrej | but honestly I don't think you can release without it | 13:38 |
| rbasak | ondrej: I've not decided yet. My concern is how stable it will be at release. | 13:38 |
| infinity | xnox: So perhaps we can just drop those hunks from the installer entirely, rather than changing the path. | 13:38 |
| infinity | mdeslaur: ^ | 13:38 |
| xnox | infinity, yes. | 13:39 |
| rbasak | 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 |
| rbasak | ondrej: if it's good, then I'd love to have 7.0 replace 5.6 and be in main in Xenial. | 13:39 |
| rbasak | ondrej: do you have a list of what is outstanding? | 13:39 |
| ondrej | 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 |
| jamespage | cjwatson, no I'm just going to land it | 13:40 |
| rbasak | 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 |
| cyphermox | infinity: mdeslaur: I'll all for removing code | 13:41 |
| rbasak | 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 |
| infinity | rbasak: Yeah, concur, please don't ship two versions of PHP, it's insanity. | 13:41 |
| infinity | rbasak: Take it from someone who had to support both php3 and php4, and then both php4 and php5, it's hell. | 13:42 |
| infinity | ondrej: ^ | 13:42 |
| cjwatson | jamespage: ah, excellent, thanks | 13:42 |
| infinity | ondrej: Surely, you still remember the bad old days. :P | 13:42 |
| ondrej | 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:42 |
| ondrej | infinity: I remember only php4+php5 :) fortunately | 13:43 |
| infinity | 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 |
| infinity | ondrej: But that's just advice, since I washed my hands of PHP years ago, I get no real vote. :P | 13:43 |
| infinity | (I do, however, get some very strong votes about what's acceptable in Ubuntu) | 13:44 |
| ondrej | 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:44 |
| rbasak | 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 |
| rbasak | 2) Move to php7.0 in main in Xenial. | 13:45 |
| xnox | 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 |
| rbasak | 3) [ruled out] Ship 5.6 in main and 7.0 in universe. | 13:45 |
| infinity | rbasak: With my TB and release hats on, I concur. | 13:45 |
| infinity | xnox: As pointed out, that never works out for us in practice. | 13:46 |
| cjwatson | infinity: speaking of php (codecoverage specifically) - chroots with bootstrap archive pls? | 13:46 |
| infinity | 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 |
| ondrej | 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 |
| mdeslaur | infinity, cyphermox, xnox: I'm uncomfortable making the call to drop the random seed for now | 13:46 |
| cjwatson | 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 |
| cjwatson | *sucks | 13:46 |
| ondrej | rbasak: from what I hear from people they are all keep on moving to php7 since the breakage is not so horrible | 13:46 |
| infinity | cjwatson: Yes, but they complain less directly to us. :P | 13:46 |
| ondrej | cjwatson: fortunately, most of those grab the new and shiny from me :) | 13:47 |
| ondrej | so not that bad | 13:47 |
| rbasak | ondrej: off-topic, I think you have a MySQL PPA that is causing some breakage amongst users. | 13:47 |
| xnox | 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 |
| xnox | mdeslaur, if that is the case, then i'll drop it for xenial and up. | 13:47 |
| mdeslaur | xnox: if it is a no-op, then that's fine | 13:48 |
| ondrej | 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 |
| cyphermox | 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 |
| cyphermox | :D | 13:49 |
| infinity | 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:49 |
| ondrej | infinity: I concur and I have much easier job, since I just blame upstream when something breaks :) | 13:50 |
| infinity | 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 |
| rbasak | 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 |
| infinity | ondrej: And as a mostly uninterested bystander, I think only 7 should be a goal for Debian too. | 13:50 |
| rbasak | mysql-common from one place and mysql-server-5.x from the other | 13:51 |
| ondrej | infinity: rbasak: if you stay with php5 we should definitely make php5-fpm and php7.0-fpm coinstallable | 13:51 |
| rbasak | 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 |
| ondrej | infinity: Definitely, the only side-goal I have is to have an option to support multiple versions installed from third-party (mine) repository | 13:51 |
| rbasak | ondrej: then we can inform an interim decision about which of the two options to aim for. | 13:52 |
| mdeslaur | 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 |
| mdeslaur | xnox: random.c still mentions seeding being necessary | 13:52 |
| * mdeslaur isn't convinced yet | 13:52 | |
| ondrej | 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:56 |
| ondrej | I only upgraded PECL exts that people care about | 13:57 |
| * rbasak looks | 13:58 | |
| rbasak | ondrej: any known bugs or shortcomings in the packaging that might bite us? | 14:00 |
| ondrej | rbasak: debbugs#805222 - pkg-php-tools can't build PECL extensions now | 14:02 |
| ondrej | 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 |
| rbasak | ondrej: thanks. | 14:04 |
| ondrej | ondrej: re #805222 it's because of broken PEAR 1.10.1 | 14:04 |
| rbasak | Security update are a factor for mdeslaur or sarnold to consider: ^^ | 14:04 |
| rbasak | I assume they're OK to move to something newer though. Less backporting work for them I think. | 14:05 |
| ondrej | 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 |
| rbasak | ondrej: why focus on making them live side by side? | 14:05 |
| rbasak | ondrej: can we not just go for it and get everything migrated if we decide to get it done? | 14:06 |
| mdeslaur | Something newer is preferable, but the fact that it's a .0 release is a bit problematic | 14:06 |
| ondrej | 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 |
| mdeslaur | that's when all the new features are introduced and quickly get rewritten/fixed | 14:06 |
| mdeslaur | so there's usually a lot of code churn between a .0 and the next couple of point releases | 14:07 |
| mdeslaur | which makes our job harder | 14:07 |
| rbasak | ondrej: IMHO, Ubuntu users who want to stay on a previous PHP version can stay on a previous Ubuntu release. | 14:07 |
| rbasak | (unless we decide to stick to 5.6 in Xenial) | 14:07 |
| ondrej | mdeslaur: rbasak: right, the amount of security patches that go to 5.5.x is smaller than for 5.6.x | 14:08 |
| mdeslaur | If it was something like 7.0.2, it would be a no-brainer | 14:08 |
| rbasak | mdeslaur: so where are you on the balance of 5.6 vs. 7.0 in Xenial? | 14:09 |
| rbasak | Maybe there's a chance that there will be a 7.0.2 before Xenial is released? | 14:09 |
| ondrej | rbasak: well, it shouldn't be a huge amount of work acording to this user, who tried to tackle this: #807165 | 14:09 |
| mdeslaur | 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 |
| mdeslaur | rbasak: it would probably be easier to support 7.0.x in the LTS release | 14:09 |
| rbasak | 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 |
| mdeslaur | rbasak: as long as the big code churn changes are done in the first couple of point releases | 14:10 |
| rbasak | mdeslaur: OK, thanks. | 14:10 |
| mdeslaur | that's from a security point of vue | 14:10 |
| mdeslaur | view | 14:10 |
| mdeslaur | what users want in an LTS at this point in time, I don't know | 14:10 |
| rbasak | I've been thinking about "what users want in an LTS at this point in time" | 14:11 |
| rbasak | I've come to the conclusion that 7.0 would be better than 5.6 for Xenial from this perspective. | 14:11 |
| mdeslaur | ok | 14:11 |
| rbasak | Just because users who want to stay on 5.x can just stay on Trusty. | 14:11 |
| mdeslaur | that's true | 14:11 |
| rbasak | And they can move to Xenial and 7.0 at their own pace. | 14:11 |
| mdeslaur | good point | 14:11 |
| mdeslaur | but yeah, please don't ship two in the archive | 14:12 |
| rbasak | ondrej: I think from both my Ubuntu and Canonical hats I can't justify spending time on co-installability. | 14:13 |
| rbasak | ondrej: since that's not a goal at all for Ubuntu - in fact we specifically don't want it. | 14:13 |
| ondrej | 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 |
| rbasak | Thanks | 14:13 |
| rbasak | I'm rbasak-guest on alioth. | 14:13 |
| ondrej | rbasak: then please take care of all dependencies down the tree | 14:13 |
| rbasak | That's something more palatable for me in principle I think. | 14:14 |
| rbasak | I need to consider whether it's feasible to get this all done in time for Xenial feature freeze. | 14:14 |
| rbasak | Given my other responsibilities too. | 14:14 |
| rbasak | infinity: what do you think about leaving some reverse deps in universe behind if I run out of time? | 14:15 |
| rbasak | infinity: suboptimal I know, but is it completely unacceptable? | 14:15 |
| rbasak | If I focus on reverse deps in main I think that's probably feasible (though I haven't looked) | 14:16 |
| ondrej | rbasak: alioth done | 14:16 |
| rbasak | Thank you! | 14:16 |
| ondrej | I have to go now, thanks for the chat and conclusion | 14:17 |
| mdeslaur | xnox, infinity, cyphermox: I believe the comment on the systemd list is wrong and the random seed is still necessary. | 14:18 |
| xnox | mdeslaur, can you email systemd-devel about it please? | 14:18 |
| rbasak | ondrej: thank you for bringing the discussion to us! | 14:18 |
| xnox | 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 |
| mdeslaur | xnox: you're looking at the crypto stuff, the random devices don't use that at all AFAIK | 14:19 |
| xnox | wow | 14:21 |
| xnox | oh, i have a lot of whitespace. | 14:21 |
| Laney | haha | 14:22 |
| xnox | Laney, i thought i got switched to a RTL mode for a second, as it seemed like i'm typing RTL. | 14:24 |
| xnox | Does anybody develop ubuntu on a Windows Laptop? | 14:25 |
| sladen | xnox: I did have some short-term Wubi installs a long time ago. | 14:28 |
| === fginther` is now known as fginther | ||
| sladen | xnox: however the lesson learnt from that is that relying Windows NTFS underneath wasn't such a great idea | 14:28 |
| Mirv | 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 |
| Mirv | the newer runs are with the older qca | 14:29 |
| Laney | Mirv: hmm, I wonder how to do that | 14:30 |
| Laney | it tries to minimise the things used from proposed | 14:30 |
| Laney | let me try it with multiple --trigger | 14:31 |
| Mirv | 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 |
| Mirv | http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/xenial/amd64/ | 14:32 |
| Mirv | 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:33 |
| xnox | 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 |
| Mirv | I don't even find qtbase there at the moment, so I guess there's nothing to read yet | 14:34 |
| Mirv | xnox: right, exactly | 14:34 |
| Mirv | the issues I mentioned above are the ones remaining afaik | 14:34 |
| Mirv | and they are kind of non-issues | 14:34 |
| xnox | 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:35 | |
| Mirv | 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:36 |
| Mirv | 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 |
| cjwatson | xnox: that's OK if it's exactly correctly configured - needs to have debug symbol settings matching the archive, etc. | 14:37 |
| Mirv | when they're finally fix released | 14:37 |
| cjwatson | xnox: which archive so I can check? | 14:37 |
| cjwatson | Mirv: that shouldn't matter | 14:37 |
| xnox | cjwatson, i think it's not -> https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages | 14:37 |
| cjwatson | Mirv: we need that for the SRU reports, but otherwise, LP should work it out for itself nowadays | 14:37 |
| Mirv | cjwatson: I was thinking about the texts that get automatically put to the LP reports. ah, nice if there have been fixes. | 14:37 |
| xnox | cjwatson, uses proposed, but all components instead of matching to start with. | 14:37 |
| xnox | cjwatson, and doesn't build debug symbols, nor publishes them. | 14:38 |
| cjwatson | well yeah all PPAs use all components, that doesn't necessarily stop us copying from them | 14:38 |
| cjwatson | Mirv: those should be calculated from the copy ancestry | 14:38 |
| cjwatson | but debug symbols would be an impediment | 14:38 |
| Mirv | 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:38 |
| cjwatson | xnox: for the future, you can flip the debug symbol settings yourself on +edit | 14:39 |
| xnox | cjwatson, yeap. | 14:39 |
| xnox | Mirv, i'm not convinced thigs will migrate, even if we mark all of them to skip all of autopkgtests. | 14:39 |
| Mirv | 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:40 |
| Mirv | every day I'm getting questions from almost every time that if the migration is happening or not... | 14:41 |
| Mirv | s/time/team/ | 14:41 |
| xnox | Mirv, well that's easy to answer "no" =) it's only a "yes" when it migrates =) | 14:41 |
| xnox | pitti, Laney: there is a lot of green, can we mark remaining autopkgtests to be ingored and see if britney migrates things? | 14:42 |
| Mirv | xnox: well, but it's not just a question but a plea to get it done asap to have landings work fluently again | 14:42 |
| xnox | Mirv, all landings should be building against -proposed, what's the problem with them? you can totally release them into xenial-proposed. | 14:43 |
| Mirv | 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 |
| cjwatson | silos aren't released until things migrate, which is deliberate so that people pay attention to migration | 14:43 |
| xnox | Mirv, if you are telling me they build against xenial-release, without proposed..... that's where they are going wrong =) | 14:43 |
| pitti | xnox, Mirv: can do; only the octeta issue holds it for now, so like last time I'll ignore that | 14:44 |
| xnox | cjwatson, ok. | 14:44 |
| xnox | cjwatson, can you give me disk space in https://launchpad.net/~xnox/+archive/ubuntu/nonvirt please =) | 14:44 |
| Mirv | 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 |
| xnox | cjwatson, enough to built all of qt5. 30GB? | 14:44 |
| Laney | pitti: I'm retrying okteta, assuming that adding --trigger causes a package to be used from proposed | 14:45 |
| Laney | Mirv says it should be fixed | 14:45 |
| Mirv | it already passed once | 14:45 |
| pitti | Laney: correct; but it was "fixed" before ubunt4 | 14:45 |
| cjwatson | xnox: IIRC 20GiB is usually fine, bumped to that | 14:45 |
| xnox | cjwatson, thanks. | 14:45 |
| Mirv | and takes over 3h to rerun so it would be useful to ignore | 14:45 |
| pitti | Laney: overriding anyway to unblock this, if it's ok for you? | 14:45 |
| Laney | ok | 14:47 |
| === xnox_ is now known as xnox | ||
| Mirv | pitti: kio seems to also randomly fail on armhf + ppc64el http://autopkgtest.ubuntu.com/packages/k/kio/ | 14:50 |
| xnox | Mirv, well, it's just i will go through pain of all of these autopkgtests independently when i do upload things for s390x.... | 14:52 |
| * xnox thinks windows10 is bonkers, looks nice on a 4k display - but "updating windows 5% present, it will restart multiple times is scary." | 14:56 | |
| xnox | pitti, looks like qtbase-opensource-src-gles will not be considered, but it should go at the same time (i think), ideally it would need a similar hammer as done to plain qtbase variant. | 15:07 |
| xnox | Mirv, qt3d-oepnsource-src-gles depends on qt3d builds of matching versions which are no longer satisfiabled?! | 15:08 |
| xnox | Mirv, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qt3d-opensource-src-gles | 15:08 |
| xnox | pitti, ditto qtdeclarative-opensource-src | 15:08 |
| xnox | and qtdeclarative-opensource-src-gles | 15:09 |
| * xnox starts a pad with hints | 15:09 | |
| xnox | qtscript-opensource-src | 15:10 |
| xnox | qtsensors-opensource-src | 15:10 |
| xnox | qtx11extras-opensource-src | 15:10 |
| * xnox ponders if http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libqapt will affect the transition | 15:12 | |
| pitti | xnox: so we need to ignore okteta and kio failures? | 15:13 |
| xnox | pitti, yes please. | 15:13 |
| * xnox retires ktexteditor/arm64 | 15:14 | |
| xnox | missing build | 15:15 |
| Mirv | xnox: ah it needs a no-change rebuild, sorry | 15:15 |
| Mirv | (qt3d) | 15:16 |
| Mirv | uploading | 15:16 |
| xnox | britney is very good at generating excuses. | 15:16 |
| pitti | (NB: these will come back with the next Qt update) | 15:16 |
| xnox | pitti, qtmir-gles is confusing in the whole output it's sometimes listed as "amd64 pass, armhf always failed, i386 pass, ppc64el always failed" and sometimes as "amd64 pass, i386 regression" | 15:17 |
| Mirv | uploaded the rebuild | 15:17 |
| xnox | shouldn't all the results be the same? | 15:17 |
| Mirv | xnox: the -gles packages only build for amd64 + i386 | 15:18 |
| * Mirv switches to low availability mode | 15:18 | |
| pitti | xnox: indeed, for qtmir-gles itself the tests aren't limited to the arches where it's actually available, so on arm/ppc it's always failed | 15:19 |
| pitti | xnox: shouldn't block anything, but a cosmetical wart indeed | 15:19 |
| Laney | can we make autopkgtest forget the kio/armhf kio/ppc64el passes? | 15:20 |
| xnox | pitti, in qtbase-opensource-src-gles qtmir-gles is listed as regression, when i wouldn't think so... anyway, will wait for Mirv's no change rebuild and updated britney output. | 15:20 |
| Laney | looks like they shouldn't have passed | 15:20 |
| Laney | I retried gles and it passed now | 15:22 |
| pitti | Laney: we can; but I have too crappy internet to do it from here | 15:23 |
| pitti | +force-badtest okteta/4:15.08.2-0ubuntu2 | 15:23 |
| pitti | +force-badtest kio/5.15.0-0ubuntu3 | 15:23 |
| pitti | for now I pushed these | 15:23 |
| pitti | Laney: i. e. we need to delete the passed results from swift and from britney's results.cache | 15:23 |
| pitti | (feel free to, of course) | 15:23 |
| Laney | pitti: let me try | 15:28 |
| xnox | pitti, qtbase-opensourse-src-gles is still not considred. looks like we need | 15:39 |
| xnox | force-badtest kdepimlibs/4:15.08.2-0ubuntu2 | 15:39 |
| pitti | xnox: I just hinted orce-badtest kaccounts-integration/4:15.08.2-0ubuntu1 | 15:39 |
| xnox | and kaccoutns-ingegration, yeap. | 15:40 |
| pitti | test suite timed out | 15:40 |
| pitti | xnox: committed | 15:42 |
| === tvoss is now known as tvoss|dinner | ||
| Laney | hmm, apparently those swift deletes weren't enough | 15:47 |
| pitti | Laney: did you also drop the successful results of that package from results.cache? | 15:47 |
| pitti | Laney: (in principle you can also rm it, but then it'll take > 1 h hour to re-download) | 15:47 |
| pitti | so better to just delete all results of that package, or at least the "true" ones | 15:48 |
| Laney | pitti: oh right, I removed the bad arches | 15:48 |
| Laney | is the web UI going to update? | 15:48 |
| pitti | Laney: oh, and results.cache editing needs to happen while britney.py is not running (it's ok in --print-uninst mode, though) | 15:48 |
| xnox | pitti, Laney: if i'm reading things right apt transition is entangled, and not currently considered hence e.g. at least on s390x qtbase transition causes a bunch of apt* things to become uninstallable. | 15:48 |
| pitti | Laney: no, that won't magically see removed results | 15:49 |
| pitti | Laney: but debci is irrelevant for britney | 15:51 |
| Laney | yeah, just tidiness | 15:54 |
| Laney | xnox: could be | 15:54 |
| Laney | it'll look a lot better once the other qt* become candidates | 15:55 |
| xnox | and now britney has a traceback http://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2015-12-09/15:48:18.log | 15:55 |
| xnox | ValueError: Expecting property name: line 34287 column 5 (char 631482) | 15:55 |
| xnox | Laney, ^ did you make a typo? =) | 15:55 |
| * xnox is watching http://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2015-12-09/15:54:26.log | 15:56 | |
| Laney | weird | 15:57 |
| xnox | pitti, Laney, i think britney doesn't like the edited cache. | 15:57 |
| Laney | I thought i followed the pitti instructions, let me try deleting all kio | 15:57 |
| pitti | does it crash? forgot a trailing comma somewhere? | 15:57 |
| pitti | json is awfully sensitive against those | 15:57 |
| xnox | Laney, one must not have trailing commas, this is not python json barfs at them. | 15:58 |
| xnox | i.e. [foo,bar,baz,] will crash, but [foo, bar, baz] is good. | 15:58 |
| Laney | it's all gone | 15:58 |
| pitti | check with json_pp or similar | 15:58 |
| xnox | ok, a bunch of them are valid candidates now. | 16:17 |
| xnox | maybe we need to hint things together. | 16:17 |
| * xnox digs | 16:17 | |
| Laney | xnox: I'm following amarok down | 16:18 |
| pitti | update_output has a nice collection | 16:18 |
| xnox | pitti, yeah, it does look rather complete. | 16:18 |
| Laney | it seems to come down to qtdeclarative/s390x | 16:19 |
| xnox | really?! | 16:19 |
| xnox | on amd64 | 16:19 |
| pitti | oh, do we enforce britney on s390 already? | 16:19 |
| xnox | pitti, yes, we always have. | 16:19 |
| xnox | Laney, well qtdeclarative/s390x is easy - it builds in my ppa, will re-trigger the world, and then the rest of qt builds. | 16:20 |
| pitti | ARCHITECTURES = amd64 arm64 armhf i386 powerpc ppc64el | 16:20 |
| pitti | not that I can see | 16:20 |
| pitti | but there seem to be some hand-crafted s390 things in excuses | 16:20 |
| xnox | Laney, but there is no qtdeclarative in xenial-release, why would it matter? | 16:20 |
| xnox | pitti, http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/287 ? | 16:21 |
| Laney | I'm looking on amd64 | 16:21 |
| pitti | xnox: err, sure there is? | 16:21 |
| Laney | but wait, I got confused, let me check again | 16:21 |
| xnox | Laney, how can anything on amd64 need a qtdeclarative/s390x. if you elaborate... | 16:22 |
| pitti | xnox: ah, thanks | 16:22 |
| xnox | it's a NEW_ARCH, but not a f##ked one | 16:23 |
| pitti | xnox, Laney: seems it's hinging on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src-gles#libqapt | 16:23 |
| xnox | pitti, yeah, i think so. | 16:23 |
| Laney | xnox: Nah, it needs python-apt to be candidate | 16:23 |
| caribou | Any reason why 'pull-debian-source' would fail indicating an invalid signature whereas dget correctly download & verify the source package ? | 16:24 |
| xnox | Laney, well the fact that libqapt remove apt when trying to do autopkgtest is not good either. | 16:24 |
| pitti | argh, apt isn't in yet either? | 16:24 |
| pitti | probably that depends on qapt too, and that seems rather broken | 16:24 |
| xnox | pitti, no, cause it wants new qt =) | 16:24 |
| xnox | i think we should hint apt into the qt doom. | 16:25 |
| pitti | this is like the entire wily -> xenial in one step | 16:25 |
| Laney | haha | 16:25 |
| pitti | given that the libqtapt tests want to remove a gazillion packages, it smells like the transition isn't complete there | 16:25 |
| pitti | we can't possibly hint over that | 16:25 |
| pitti | or it has been fixed since and the qapt tests just need a re-run | 16:26 |
| Laney | apt is in the doom | 16:26 |
| Laney | autohinter is good at that | 16:26 |
| pitti | how do you mean? | 16:26 |
| xnox | well, in a -proposed enabled chroot libqapt & new qt coinstall fine | 16:26 |
| xnox | can we rerun libqapt test with qtbase as a trigger? | 16:27 |
| * pitti just retries the qapt tests, they shold be reasonably quick | 16:27 | |
| xnox | pitti, and retrigger software-properties too? | 16:28 |
| xnox | from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src-gles#libqapt | 16:28 |
| xnox | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libqapt | 16:28 |
| pitti | I retriggered all retry-autopkgtest-regressions|grep apt | 16:28 |
| xnox | ooo. fancy =) | 16:28 |
| Laney | could probably do with a tracker for apt | 16:28 |
| xnox | Laney, yeah. | 16:29 |
| xnox | well, it's apt libqapt, packagekit, python-apt, synaptic and ubuntu-core-meta | 16:30 |
| xnox | for some reason.... | 16:30 |
| xnox | which looks fishy | 16:30 |
| xnox | ARGH! ubuntu-core-meta | 16:30 |
| pitti | Depends: libapt-inst1.7, libapt-pkg4.16, | 16:31 |
| pitti | WTF? | 16:31 |
| pitti | since when do we see particular ABIs? | 16:31 |
| pitti | oh, it's full of that | 16:31 |
| xnox | pitti, we used to do that on the phone, back in phonedations days... mvo ? ^ | 16:31 |
| === cpaelzer is now known as cpaelzer_afk | ||
| pitti | so that needs seed update and -meta rebuild | 16:32 |
| xnox | pitti, i'm fixing that | 16:32 |
| pitti | xnox: danke | 16:32 |
| Laney | apt tracker pushed, copied from debian | 16:34 |
| didrocks | ximion: hey! icon-format-unsupported | 16:35 |
| didrocks | ximion: we got that for some .xpm | 16:35 |
| * Laney hopes python-apt gets better | 16:35 | |
| pitti | xnox: well, on the phone it was a really nasty hack to break our own rules of producing click packages | 16:35 |
| pitti | xnox: but on snappy we don't have that | 16:35 |
| pitti | so I don't understand why we need to seed library sonames | 16:35 |
| Laney | this not being candidate breaks kde-runtime | 16:35 |
| Laney | which is presumably all the k* | 16:35 |
| didrocks | ximion: is that expected or just a parser false positive? (as they shows up quite well in various software, didn't try in Gnome Software though) | 16:35 |
| xnox | hopefully if we can get apt in, qt will follow and the doom will land =/ | 16:36 |
| pitti | Laney: yeah, same sorryness than libqapt and libapt-pkg-perl | 16:36 |
| * xnox is redoing ubuntu-core | 16:36 | |
| xnox | pitti, what about libapt-pkg-perl? | 16:37 |
| pitti | the tests all rip out half of the system | 16:37 |
| xnox | oh. | 16:37 |
| Laney | pitti: indeed, waiting for the retries to see if it's still bad | 16:37 |
| pitti | i. e. same as the others | 16:37 |
| pitti | meh, seems not | 16:37 |
| xnox | and presumibly aptitude ftbfs on ppc64el is bad too | 16:37 |
| xnox | collect2: error: ld returned 1 exit status -> thanks?! | 16:38 |
| pitti | this might be a case where packages don't have tight enough dependencies and the apt pinning fails | 16:38 |
| pitti | but actually these ought to fall back to unpinned automatically | 16:39 |
| pitti | well, at least some of those seem to work now | 16:40 |
| * pitti needs to teach autopkgtest to recover from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/apt-clone/20151209_163754@/log.gz and remove pinning | 16:42 | |
| xnox | pitti, well, it seems to me that given that i can co-install those, with new apt and qt, they should work fine.... | 16:45 |
| pitti | xnox, Laney: ok, cowboy solution: I temporarily disabled apt pinning in the worker | 16:48 |
| Laney | yeehaw | 16:48 |
| pitti | so another set of retries should work better | 16:48 |
| pitti | and I'll work out how to fix apt pinning for this case | 16:48 |
| pitti | my train staion is coming up, need to leave | 16:49 |
| pitti | Laney: can you retry-auto-pkgtest-regressions|grep apt|sh again? | 16:49 |
| * pitti runs | 16:49 | |
| ximion | didrocks: jup, that's expected - XPM is generally unsupported | 16:49 |
| * xnox is still waiting for ubuntu core to update | 16:49 | |
| ximion | (and I wonder how an xpm icon even got in the loop, unless it's from installed software, which we have no influence on) | 16:50 |
| didrocks | ximion: ok, I need to check what we display then, as we have a svg as well, thanks for confirming! | 16:51 |
| ximion | svgs should be fine - some of our tools though give up on the first icon they find, and if that happens to be .xpm, the component gets skipped | 16:52 |
| ximion | (usually only happens for software defining an absolute path to a .xpm icon though) | 16:52 |
| ximion | didrocks: btw, full DEP-11 support in Debian is nearly finished - it will need AppStream 0.9 and the latest APT to work though, and the AppStream 0.9 release is what I am currently working on (contains some API changes, which unfortunately started already before I knew that I need to implement some Debian support there) | 16:54 |
| xnox | Laney, ubuntu-core-meta is in, apperantly last apt transition i did similar replace.... | 16:55 |
| Laney | super | 16:56 |
| infinity | pitti: Why did you sync the experimental findutils? | 16:56 |
| xnox | infinity, because you were not on the phone call last thursday?! (mumble) | 16:58 |
| infinity | xnox: The mumble meeting was about findutils? :P | 16:58 |
| cjwatson | ximion: did Laney talk to you about the feasibility of running the dep-11 generator without a local mirror (i.e. having it fetch just the packages it determines that it needs based on Contents)? | 16:58 |
| xnox | infinity, the foundations talking yeah. some of us thought it was a good idea. | 16:59 |
| ximion | cjwatson: Jup, see https://github.com/ximion/appstream-dep11/issues/5 - basically I have nothing against populating the "ignored-packages" cache before running the actual extraction, but just using the Contents file might lead to inconsitencies | 17:00 |
| ximion | (and us ignoring packages we should process) | 17:00 |
| infinity | xnox: Fun. Did anyone who thought it was a good idea also think to check if it builds everywhere first? :) | 17:00 |
| ximion | what one could to is mirror packages based on the Contents file, and demote the warning about a missing .deb package to not-an-error, if some PartialArchive option is set... | 17:01 |
| xnox | infinity, talk to pitti who ran away from a train station. | 17:01 |
| xnox | infinity, i'd want it purged if it ftbfs. | 17:01 |
| xnox | cause it is scary. | 17:01 |
| infinity | I'm inclined to delete it from -proposed and let someone try again later if they're willing to commit. | 17:02 |
| infinity | But that's just me. | 17:02 |
| cjwatson | ximion: ah right, thanks | 17:02 |
| xnox | infinity, it totally should use silo landing, yes ;-) | 17:02 |
| cjwatson | ximion: we generate Contents daily, so maybe one option is to do timestamp fuzzing based on the date of Contents | 17:02 |
| cjwatson | i.e. anything newer than Contents - fuzz-factor we might have to rescan when Contents info becomes available | 17:03 |
| cjwatson | I agree that scanning things like binaries in PATH might mean it's not worth it though | 17:04 |
| ximion | cjwatson: that feature is something some people want very much - I still need to figure out a smart way how to do this though, without exploding the size of the Components.gz file | 17:05 |
| xnox | Laney, uploading packagekit | 17:10 |
| xnox | Laney, and then will do the rest of s390x. | 17:10 |
| Laney | cool | 17:10 |
| xnox | Laney, pitti, is there a magic proxy one can set in autopkgtests to get internetz? | 17:28 |
| Laney | xnox: Not that I know of, for http we use proxies which are set in the environment for you | 17:35 |
| xnox | Laney, i guess it's something funny http_proxy: http://squid.internal:3128 | 17:36 |
| xnox | and autopkgtest related | 17:36 |
| Laney | what is? | 17:36 |
| xnox | Laney, nah, nothing, talking to myself. | 17:40 |
| xnox | Laney, aptitude ppc64el FTBFS who wants to fix it? infinity - do you like aptitude FTBFS bug? =) | 17:40 |
| pitti | infinity, xnox: fine for me to remove findutils from experimental; chiluk, do you want to backport that fix instead? | 17:44 |
| pitti | xnox: proxy is already set | 17:44 |
| pitti | Laney: did you already retry after removing apt pinning? | 17:44 |
| xnox | pitti, so i'm now waiting on a bunch of arm64 builds for apt transition. | 17:44 |
| Laney | yep | 17:44 |
| xnox | pitti, and there is packagekit FTBFS all arches, and aptitude/ppc64el FTBFS which will hold up apt =( | 17:44 |
| Laney | looks like aptdaemon has some new failures which are real | 17:44 |
| pitti | seems not, I'll re-retry to see what fallout remains | 17:45 |
| Laney | I did | 17:46 |
| pitti | oh, ok | 17:46 |
| pitti | it's a looot less now, though | 17:46 |
| Laney | there's more green now | 17:46 |
| Laney | for python-apt it might even turn out to just be aptdaemon that needs work | 17:47 |
| ximion | xnox: packagekit won't build in this ancient version Ubuntu ships | 17:51 |
| xnox | ximion, fun. | 17:51 |
| ximion | the aptcc backend changed quite a lot between the Ubuntu version and what we currently ship upstream, so I am not sure if it is easier to backport patches or just to upgrade PK | 17:52 |
| cjwatson | somebody needs to finish off https://code.launchpad.net/~mvo/click/native-dbus | 17:52 |
| cjwatson | otherwise the phone breaks | 17:52 |
| cjwatson | (not me, I'm not working on click at that level any more) | 17:52 |
| xnox | at the moment aptitude/ppc64el FTBFS & packagekit FTBFS, against new apt block the world of things in xenial-proposed. So i'm looking at minimal patches to resolve the build failures. | 17:52 |
| xnox | mvo, are you busy? =) | 17:53 |
| mvo | xnox: we will need the new PK from debian | 17:53 |
| mvo | xnox: no idea why aptitude fails, that should be ok :/ | 17:53 |
| cjwatson | mvo: which means we need click native-dbus | 17:53 |
| ximion | mvo: btw, you could at least upgrade PK to 0.9.5-2 | 17:53 |
| ximion | that was the release before plugin support was dropped | 17:53 |
| mvo | ximion: will it work with the latest apt :) ? if not that won't help us | 17:54 |
| ximion | no, it won't work with the latest APT, but in theory backporting patches to that release might be easier | 17:54 |
| ximion | the PK version in Ubuntu is pretty much dead | 17:55 |
| ximion | (upstream) | 17:55 |
| xnox | ximion, backport from where... if plugin support was dropped, i would assume nobody fixed deb-file.cpp to work with new apt... | 17:55 |
| xnox | or wel fix libpk_backend_aptcc | 17:55 |
| * xnox goes to look | 17:55 | |
| mvo | cjwatson: yeah, I hope the team around alecu can have a look at https://code.launchpad.net/~mvo/click/native-dbus I think its pretty much done except for final testing | 17:55 |
| ximion | xnox: when looking for ancient Debian packages, http://snapshot.debian.org/package/packagekit/0.9.5-2/ is the place to go :) | 17:56 |
| ximion | but fixing whatever is blocking PK 1.0.11 in Ubuntu would of course be even better :) | 17:57 |
| xnox | mvo, i'll try to cherrypick https://github.com/hughsie/PackageKit/commit/30bfee4d41944bbfbd7a40c7f3fa1004fc6effa9 | 17:58 |
| alecu | mvo: with that branch, can we drop the usage of packagekit in click? | 18:03 |
| alecu | mvo: I guess click scope/system updater can start using that new dbus interface instead of using packagekit to install apps. | 18:04 |
| cjwatson | alecu: right, anything explicitly using the pk interface would have to switch over to the native one, and then we can drop the pk one | 18:05 |
| cjwatson | alecu: it was intended as a graceful transition | 18:06 |
| cjwatson | (would have been slightly more graceful if finished off a year ago, but there you go ...) | 18:06 |
| alecu | yeah, shifting priorities :-) | 18:07 |
| alecu | cjwatson: sounds great, thanks. | 18:07 |
| cjwatson | and of course anyone in the habit of using pkcon needs to stop doing so, iirc that branch makes "click install" work more gracefully | 18:07 |
| alecu | wonderful | 18:08 |
| alecu | dobey: ^^^ | 18:08 |
| * xnox ponders why aptitude build downloads firefox | 18:09 | |
| dobey | hmm, ok | 18:12 |
| xnox | alecu, dobey: it's just someone who still uses click should finish that native-dbus work. cause everyone else who used to do it, moved on to other things or snappy. | 18:14 |
| alecu | xnox: agreed | 18:14 |
| dobey | well, what will be the equivilent command line to run for "pkcon install-local" ? | 18:18 |
| xnox | Laney, packagekit is in.... it builds.... | 18:18 |
| mvo | dobey: "click install" will do the right thing and act like pkcon install-local" | 18:46 |
| dobey | mvo: so click install will no longer require root like it does now? | 18:47 |
| mvo | dobey: yeah, it will call itself via pkexec iirc | 18:48 |
| mvo | dobey: if run without root privs | 18:48 |
| mvo | elopio: still all looking good? | 18:55 |
| balrogg_cs | Brazilian here or channel ubuntu-devel from brazilian? | 18:55 |
| elopio | mvo: yes. Do you want to release today or tomorrow? | 19:05 |
| elopio | mvo: yes. Do you want to release today or tomorrow? | 19:05 |
| xnox | slangasek, mvo, pitti, Laney, Mirv - so aptitude ppc64el build should work with -O2, uploaded now. Hopefully qt & apt will now migrate over.... | 19:23 |
| === cpaelzer_afk is now known as cpaelzer | ||
| * gammax ciao | 19:33 | |
| dobey | mvo: does that mean it will request a password from the user to elevate privs? or it will talk to a system dbus service that's running as root, to unpack the files? | 19:38 |
| === cpaelzer is now known as cpaelzer_afk | ||
| === cpaelzer_afk is now known as cpaelzer | ||
| === cpaelzer is now known as cpaelzer_afk | ||
| === gammax is now known as cortinico | ||
| === salem_ is now known as _salem | ||
| === tvoss|dinner is now known as tvoss | ||
| === bschaefer_ is now known as bschaefer | ||
| mvo | elopio: I think I push to stable tonight and do the rest tomorrow | 20:23 |
| mvo | dobey: asks for a password | 20:23 |
| dobey | mvo: that won't be acceptable for installing packages from the scope then | 20:24 |
| dobey | we need equivalent behavior to "pkcon install-local" | 20:24 |
| mvo | dobey: it will use pkexec, is that not what pkcon is also doing? | 20:25 |
| dobey | mvo: pkcon doesn't require entering a password | 20:25 |
| dobey | i don't know the technical details of the implementation | 20:25 |
| dobey | i just know it doesn't require asking for the pin/passwrod to elevate privileges to install packages | 20:26 |
| mvo | dobey: yeah, I think that is because we whitelist it via policykit, its been ~1y since I worked on that branch, let me have a look to refresh my memory | 20:27 |
| pitti | xnox: cool, thanks! | 20:27 |
| mvo | dobey: I'm pretty sure we had the scope in mind when doing this | 20:28 |
| xnox | pitti, just waiting on armhf aputpkgtest queue to drain. | 20:28 |
| mvo | dobey: or at least we thought about it so that its easy to do passwordless installs via policykit | 20:28 |
| pitti | xnox, Laney: I know what's going on with the failed package install under pinning; I have a fix now, currently running tests | 20:29 |
| xnox | pitti, and aptitude/armhf to publish | 20:29 |
| pitti | then I can remove the cowboying again | 20:29 |
| dobey | mvo: ok, well i'm just expressing my concerns about how it might break, and stating what we need in terms of how the scope works | 20:29 |
| pitti | "--apt-pocket=proposed=src:python-apt -U apt-clone" works now | 20:29 |
| mvo | dobey: right, I agree, this needs to be approached carefully | 20:30 |
| dobey | mvo: anyway, there's no need to rush this either, as phone images are going to stay on 15.04 until after at least 16.04 release. | 20:31 |
| dobey | and at that point we may not have click on the phone anyway :) | 20:31 |
| mvo | dobey: aha, great. that gives us some room then | 20:31 |
| mvo | dobey: good point | 20:31 |
| xnox | pitti, although we still have real looking aptdaemon failure https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/aptdaemon/20151209_192259@/log.gz | 20:33 |
| pitti | indeed; 100 is apt's typical error code | 20:34 |
| pitti | Laney, xnox: cowboy change removed, proper fix deployed | 20:46 |
| pitti | xnox: it seems aptdaemon isn't totally broken, but I'd feel better if mvo could have a look before we hint it | 20:47 |
| pitti | i. e. if it's harmless enough to fix it after apt lands | 20:47 |
| Laney | pitti: it's a bit worrying to me if we let the aptdaemon regressions through since they seem caused by the new (python-)apt | 21:10 |
| Laney | good work on the pinning fix | 21:10 |
| pitti | right, hence I'm hesitant | 21:10 |
| pitti | and it can't just be ignored for a longer time, at most to untangle this | 21:11 |
| rharper | stgraber: do you know what triggers upstart net-device-added for interface aliases (eth1:0) ? | 21:44 |
| xnox | rharper, upstart-udev-bridge no? | 21:47 |
| rharper | xnox: for physical devs, but a device alias isn't physical | 21:47 |
| stgraber | rharper: does it trigger? I wouldn't think it would | 21:47 |
| rharper | stgraber: I'm guessing not because we do the 120second wait on interface dance, then eventually it shows up | 21:48 |
| rharper | trying to understand how it's showing up at all then if nothing emits the signal to trigger upstart to touch the /run/network/$iface file | 21:48 |
| xnox | rharper, try running udevadm monitor, or retrigger udevadm events. if things show up there, voila there is your answer - udev (or something) synthesized udev event, which upstart-udev-bridge noticed and emitted net-device-added. | 21:51 |
| xnox | rharper, oh, and stuff in /run/network/ is also done without any upstart stuff in the initramfs and it's propagated across to the booted system too. | 21:51 |
| xnox | (and installer) | 21:51 |
| rharper | right | 21:51 |
| rharper | I've looked that /var/log/udev (which looks like a stream of events) ; nothing in there seems to be "virtual" ; all physical devices ; | 21:53 |
| xnox | rharper, sure it is. | 21:54 |
| xnox | $ sudo udevadm trigger -c add -s net -n -v | 21:54 |
| xnox | rharper, try ^ that should print the net added events that udev emits, which upstart-udev-bridge sees and propagates. I have a few things. This way you can verify what's coming from udev & bridge side of things. | 21:55 |
| xnox | i have all my tunnels and bridges there. and lo | 21:55 |
| xnox | and that's it. | 21:56 |
| rharper | cool | 21:56 |
| * rharper collects some more data | 21:56 | |
| xnox | everything listed in that output, at some point in the past, had upstart net-device-added event. | 21:56 |
| rharper | but no timestamps to see in what order or when | 21:57 |
| xnox | rharper, no. this is just a dump of current udev database. if you want to see that, increase udev verbosity (and initramfs as well) and then you'll have a fuller log. | 21:57 |
| xnox | rharper, boot upstart with more detailed verbosity to have a log of events. | 21:58 |
| rharper | ok | 21:58 |
| rharper | is there a boot param to bump upstart verbosity ? | 21:58 |
| xnox | rharper, yes, in the upstart cookbook | 21:58 |
| xnox | rharper, http://upstart.ubuntu.com/cookbook/#add-verbose-or-debug-to-the-kernel-command-line | 21:58 |
| rharper | thx | 21:59 |
| cjwatson | dobey: right, as mvo says, whitelisting click native-dbus via policykit is just as easy as whitelisting the relevant bit of packagekit, if anything I think slightly easier | 23:09 |
| cjwatson | dobey: oh, in fact, click native-dbus gets to be smarter because it knows it's doing things for a particular user, and it doesn't in fact need policykit auth at all, or didn't last time I touched the branch | 23:12 |
| cjwatson | mvo^- | 23:12 |
| cjwatson | dobey: so the system dbus service runs as root but it checks what user is calling it and does things on their behalf | 23:12 |
| cjwatson | dobey: pkexec isn't involved, I think mvo is misremembering there | 23:14 |
| cjwatson | http://bazaar.launchpad.net/~mvo/click/native-dbus/view/head:/click/install.py#L454 | 23:14 |
| cjwatson | http://bazaar.launchpad.net/~mvo/click/native-dbus/view/head:/lib/click/dbus-service.vala is the service code | 23:15 |
| juliank | Something went wrong with the packagekit ubuntu numbering: 0.8.17-4ubuntu6~gcc5.4ubuntu1 | 23:20 |
| Saviq | doko, hey, Q about our toolchain... would you ever expect a "undefined reference to..." error to depend on build flags? we're looking at a situation in xenial where we can link fine against liblightdm-qt5-3 in Debug, but not in Release or RelWithDebInfo... | 23:26 |
| juliank | Laney: (Just want to leave that here before I go to sleep) There should be no regressions caused by python-apt 1.0 -> 1.1~beta1, they are most likely caused by APT itself. | 23:27 |
| doko | Saviq, sure, if the reference doesn't exist in an optimized build. I saw that in the past for template instantiations which were not explicit but just assumed | 23:29 |
| doko | I think that was in one of the myriads of webkit | 23:30 |
| Saviq | doko, ack, thanks | 23:31 |
| Saviq | doko, hmm but wait, I'm talking about a situation where the reference "goes missing" in the released library, as packaged, it's the "downstream" project that links in debug but not in release, think that might still be optimizations? | 23:33 |
| doko | Saviq, an example might help | 23:34 |
| doko | please just file a bug report | 23:35 |
| Saviq | doko, ok, we'll do | 23:35 |
| Saviq | tx | 23:35 |
| === cpaelzer_afk is now known as cpaelzer | ||
| roaksoax | doko: howdy! any ideas when newer twisted-py3 will hit the archive? allenap did some python3 porting and pushed it upstream | 23:42 |
| doko | roaksoax, hopefully never, see https://ftp-master.debian.org/new/twisted_15.5.0-3.html | 23:43 |
| cjwatson | roaksoax: I don't think that porting work has been in an upstream release yet; from what I remember it was a bit late for 15.5.0 | 23:46 |
| doko | 15.5.3 is the current one | 23:48 |
| cjwatson | err, no it's not - https://pypi.python.org/pypi/Twisted | 23:48 |
| roaksoax | thanks for the updates | 23:49 |
| roaksoax | doko: when do you think python3-twisted will be hitting the ubuntu archive? | 23:49 |
| roaksoax | doko: we are curretnly working against python3-twisted-experimental | 23:50 |
| roaksoax | doko: and we are blocked on it at the same time it not being in Main | 23:50 |
| doko | roaksoax, not my priority. please ask free about it | 23:50 |
| doko | he works for the maas team ... | 23:50 |
| cjwatson | it'll auto-sync once it's through Debian NEW anyhoe | 23:50 |
| cjwatson | *anyhow | 23:50 |
| doko | sure, that was my intention too | 23:51 |
| roaksoax | doko: free works for landscape :) | 23:51 |
| doko | oops | 23:51 |
| roaksoax | cjwatson: ack! thanks | 23:51 |
| roaksoax | any ideas of when that might be ? | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!