| smoser | pitti, i tried 'adt-buildvm-ubuntu-cloud -vv' and ended in a hang/timeout with a prompt about keyboard configuration. i'm trying http://paste.ubuntu.com/15639799/ as a fix. | 00:02 |
|---|---|---|
| nacc | Pharaoh_Atem: well, it works, so there's that | 00:16 |
| nacc | slangasek: so, i think, at this point, all packages that are on your list either have pending sponsorships, FFe upgrades, or are going to be left broken | 00:17 |
| nacc | slangasek: pad is updated with my current notes | 00:17 |
| nacc | jgrimm: --^ FYI | 00:17 |
| nacc | jgrimm: pad is at http://pad.ubuntu.com/8eABivrkBv | 00:17 |
| smoser | pitti, the paste there fixed the issue for me. the fix is really in the DEBIAN_FRONTEND=non-interactive. theres a large performance increase in only running a single 'apt-get purge' command rather than many of them. | 00:49 |
| nacc | slangasek: Pharaoh_Atem: debian's fix turns out to be identical to what i am suggesting, as ondrej is just picking up my chagnes :) | 01:07 |
| slangasek | well there you go | 01:07 |
| Unit193 | BenC: Congrats. | 01:08 |
| BenC | Thanks | 01:08 |
| === alexisb-afk is now known as alexisb | ||
| slangasek | nacc: btw php-radius is stuck in -proposed because php-common needed its versioned breaks: adjusted; I did that and reuploaded php-defaults, it has a bunch of autopkgtest regressions that are almost certainly false-positives, but can you help me sort through those and confirm which ones I should retry? | 01:12 |
| nacc | slangasek: i think all of the php-defaults ones were due to the php-pecl-http breakage | 01:12 |
| nacc | slangasek: let me go through and verify right now | 01:12 |
| nacc | slangasek: so only 3 are "real" -- php-monolog, php-email-validator and php-horde-icalendar; the last is an internal timeout in autopkgtest | 01:18 |
| nacc | looking at the first two | 01:18 |
| slangasek | nacc: thanks, throwing the others back | 01:18 |
| nacc | slangasek: hrm, i cna reproduce those two failures here, will need to investigate first thing in the AM | 01:20 |
| BenC | * Laney to start an onboarding page for new dmb members (15:11) | 01:41 |
| BenC | ACTION: laney stop slacking and write onboarding page | 01:41 |
| BenC | Answers one of my questions :) | 01:41 |
| xnox | BenC, you should join #ubuntu-dmb and chat there about dmb private stuff ;-) | 01:47 |
| xnox | BenC, congrats btw | 01:47 |
| BenC | That was not on the wiki…I hope someone gets that onboarding doen…thanks | 01:47 |
| aatish910 | How are the official ISO images generated? Both me and tsimonq2 want to know | 02:34 |
| tsimonq2 | specifically Desktop | 02:35 |
| === shuduo-afk is now known as shuduo | ||
| slangasek | nacc: ok, I believe I have everything uploaded now, and the only things left are autopkgtests, mysql-5.7 blockage, and package removals | 02:57 |
| slangasek | aatish910, tsimonq2: lp:ubuntu-cdimage, which dispatches to launchpad to run the build scripts from the livecd-rootfs package | 02:58 |
| tsimonq2 | slangasek: thank you :) | 02:59 |
| aatish910 | Uncompressed "Packages" is not available in http://archive.ubuntu.com/ubuntu/dists/trusty/universe/binary-amd64/ but it is listed in http://archive.ubuntu.com/ubuntu/dists/trusty/Release | 03:43 |
| infinity | aatish910: That's a feature, not a bug. | 03:43 |
| infinity | (And has been like that for, well, ever) | 03:43 |
| aatish910 | I was getting Hash sum mismatch on clean Xubuntu 14.04 install, and found that bzip2 version of "Packages" caused that problem. I then switched to "gz" with Acquire::CompressionTypes::Order::=gz and the problem is gone. | 03:44 |
| infinity | The compression method doesn't relate to your mismatches, timing does. | 03:45 |
| aatish910 | Timing? | 03:45 |
| infinity | Unless you have a transparent proxy between you and the archive that had an old version of Packages.bz2, but no copy of Packages.gz | 03:45 |
| infinity | Timing. You can download the old Release and then the new Packages, and they mismatch. Or if your mirror isn't a two-stage mirror, there can be a loooong period where Release and Packages don't match. | 03:46 |
| aatish910 | I was using the main mirror. | 03:46 |
| infinity | This is all being fixed with fancy new by-hash indexing, which is almost landed. | 03:46 |
| sarnold | infinity: oh please oh please tell me it'll land before xenial. | 03:47 |
| infinity | Anyhow, just saying that "switching to gz fixed it" was bad science. | 03:47 |
| sarnold | infinity: .. and will the by-hash indexing also fix the translations? | 03:47 |
| infinity | sarnold: There's a prototype on dogfood, Colin's plan is certainly to land it for xenial. That said, even if he doesn't, we can retrofit xenial with it and the client will DTRT. | 03:47 |
| sarnold | infinity: yay :D | 03:48 |
| infinity | (Well, and it's not actually important for the release pocket post-release anyway, since it doesn't change, so landing it post-xenial for just updates/security/proposed/backports would also be fine) | 03:48 |
| aatish910 | I downloaded the bz2 version using wget - got md5sum af89c33be26ac1e6a58158a3a2c00a64, but md5 listed in Release is 39929667be5295b337096d56a22ff00d | 03:48 |
| infinity | aatish910: Which file? | 03:48 |
| aatish910 | infinity, http://archive.ubuntu.com/ubuntu/dists/trusty/universe/binary-amd64/Packages.bz2 | 03:49 |
| infinity | $ md5sum Packages.bz2 | 03:49 |
| infinity | 39929667be5295b337096d56a22ff00d Packages.bz2 | 03:49 |
| infinity | aatish910: I'd suggest you have a transparent proxy between you and the archive. | 03:49 |
| infinity | And it's busted. | 03:49 |
| aatish910 | infinity, Thanks, I am going to call my ISP. | 03:50 |
| sarnold | try the two tests here too http://www.lagado.com/proxy-test | 03:50 |
| aatish910 | sarnold, Yup, the second test revealed the proxy | 03:52 |
| sarnold | neat, nice to know it works :) | 03:53 |
| infinity | Oh, if that test worked, it's not even a transparent proxy. | 03:56 |
| sarnold | this one aims for the more-transparent of the proxies http://www.lagado.com/tools/cache-test | 03:57 |
| infinity | Oh, I missed that little link. | 03:57 |
| infinity | Who else misses the world before CSS when every href was blue? | 03:57 |
| * infinity raises hand. | 03:57 | |
| * sarnold raises hand | 03:58 | |
| infinity | Oh. The best part there is that there's ARE blue, but black for :visited. | 03:58 |
| infinity | And I'd apparently been there before. :P | 03:58 |
| sarnold | I also miss the grey background | 03:58 |
| infinity | s/there's/theirs/ | 03:58 |
| sarnold | hah | 03:58 |
| aatish910 | How do you raise the hand? :) | 03:59 |
| sarnold | aatish910: /me raises hand | 03:59 |
| * aatish910 raises hand | 04:00 | |
| aatish910 | Is "Acquire::BrokenProxy=True" right for my scenario? | 04:00 |
| sarnold | I don't see any mention of "brokenproxy" in my apt.conf | 04:02 |
| mwhudson | heh i just hit that but the proxy was my own | 05:21 |
| mwhudson | which stick do i hit squid-deb-proxy with to get it out of that situation? | 05:22 |
| cpaelzer | good morning | 05:49 |
| === JanC_ is now known as JanC | ||
| pitti | Good morning | 06:49 |
| pitti | smoser: confirming the hang, I fixed the a-b-u-c yesterday; just syncing it into xenial | 06:49 |
| seb128 | hey pitti! | 06:49 |
| pitti | smoser: I more or less have the same fix (DEBIAN_FRONTEND=noninteractive) and also dropped the purging of xkb-data | 06:50 |
| pitti | hey seb128, wie gehts? | 06:51 |
| seb128 | pitti, gut, danke! und dir? | 06:52 |
| pitti | seb128: good as well, just slept too long | 06:52 |
| seb128 | there is no such thing | 06:52 |
| pitti | doko: sorry for some libhunspell collisions last night | 07:02 |
| pitti | doko: so I suppose we can sync hunspell now, this should fix the FTBFS; aside from our transitional -v5 package the other ubuntu changes are in Debian | 07:02 |
| pitti | doko: ah, you merged already; note that Debian already has M-A: same, you just moved it two lines down :) | 07:03 |
| pitti | doko: is it possible to retry something on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html ? I tried dutch and gnupg-doc locally last night, and they build fine | 07:05 |
| wgrant | pitti: Done. | 07:05 |
| pitti | ah, thanks | 07:06 |
| === NCommander is now known as mcasadevall | ||
| tjaalton | doko: mesa is now in depwait, is libva good to move? | 08:23 |
| pitti | tjaalton: looks ok, promoting | 08:34 |
| tjaalton | thanks! | 08:37 |
| tjaalton | oh and it's build-dep too libset-scalar-perl | 08:37 |
| tjaalton | this is bug 1558820 btw | 08:37 |
| ubottu | bug 1558820 in libva (Ubuntu) "[MIR] libva" [Wishlist,Fix released] https://launchpad.net/bugs/1558820 | 08:37 |
| pitti | yes, sure, see bug 1558820 | 08:37 |
| pitti | tjaalton: I don't promote stuff without looking for an MIR :) | 08:38 |
| tjaalton | noted :) | 08:38 |
| tjaalton | pitti: will mesa try again on it's own, or should I kick the builds at some point? | 09:03 |
| pitti | tjaalton: it will retry by itself; it just takes a while for the publisher to pick up the promotion | 09:03 |
| tjaalton | right | 09:03 |
| pitti | give it another 30 mins or so | 09:03 |
| tjaalton | sure thing, I remember ppa's need to be manually triggered, at least in the past | 09:04 |
| darkxst | what happened to the casper branch? where is it hiding these days | 09:04 |
| pitti | apt-get source it is, I guess | 09:04 |
| infinity | lp:casper is only 6 years out of date. ;) | 09:05 |
| cjwatson | tjaalton: dep-waits have never needed to be manually triggered, but some build-dep installation failures can't be turned into dep-waits. It's not about PPAs vs. primary archive. | 09:17 |
| cjwatson | darkxst: lp:ubuntu/casper I believe | 09:18 |
| infinity | cjwatson: No exist. | 09:18 |
| cjwatson | Ah, could be | 09:18 |
| darkxst | cjwatson, that is what I though, but no | 09:18 |
| infinity | pull-lp-source :P | 09:18 |
| cjwatson | We should maybe grab lp:ubuntu/wily/casper and shove it back to lp:casper | 09:18 |
| cjwatson | Or gitify it | 09:18 |
| darkxst | I'll just debdiff it for now ;) | 09:19 |
| tjaalton | cjwatson: ok, bad memory then | 09:25 |
| darkxst | cjwatson, infinity, casper one-liner http://pastebin.com/5TiiguNS | 09:27 |
| infinity | darkxst: Hrm. Curious. So does that mean one can't have a passwordless user on an installed system? | 09:34 |
| infinity | Not that I'd recommend anyone running passwordless, but that seems like a regression. | 09:35 |
| darkxst | infinity, normal user will be User1000 | 09:35 |
| darkxst | its not possible for a user to create a uid of 999 | 09:35 |
| darkxst | and besides the casper scripts only run on the live session | 09:36 |
| infinity | darkxst: No, that's my point. This fixes the live session to allow passwordless login, but I assume it means after install, one can't have a passwordless user, if they're so insanely inclined? | 09:36 |
| infinity | Well, other than setting that unintuitive key. :P | 09:37 |
| darkxst | GNOME won't allow setting a blank password | 09:39 |
| darkxst | so they would have to user passwd or something | 09:39 |
| infinity | But the system sure does, so one can create the user without the help of GNOME tools. | 09:39 |
| infinity | Anyhow, one bug at a time; happy to sponsor the casper workaround. | 09:40 |
| darkxst | infinity, right, and gdm doesnt use the nopasswd group like lightdm | 09:41 |
| darkxst | although I am not sure that is much of a better solution | 09:41 |
| infinity | darkxst: Err, wait. I would be happy to sponsor this, except are you sure it works? :P | 09:42 |
| infinity | darkxst: Pretty sure you're missing a chroot in there. | 09:43 |
| darkxst | infinity, I can't test it, because I can't login after I have updated casper | 09:43 |
| infinity | darkxst: Boot with break=casper-bottom and then run your bits manually from the initramfs prompt, then exit. | 09:44 |
| infinity | darkxst: It almost certainly needs a "chroot root/" at the very least. | 09:44 |
| infinity | chroot /root even. | 09:46 |
| infinity | darkxst: I'm going to go see if anyone sells coffee at 4am. Lemme know if you've been able to manually test from the initramfs. | 09:47 |
| * infinity wanders off. | 09:47 | |
| Saviq | pitti, hey, when you have some time to spare, I'd like to pick your brainz on something wrt. running autopkgtests over adb :) | 10:03 |
| ginggs | Unit193: LP: #1406825 has been fixed 5.34-2 in Debian, do you want to update your merge? | 10:04 |
| ubottu | Launchpad bug 1406825 in xscreensaver (Ubuntu) "xscreensaver complains "This version of xscreensaver is VERY OLD!"" [Medium,Confirmed] https://launchpad.net/bugs/1406825 | 10:04 |
| darkxst | infinity, oh there is no dbus apparently | 10:04 |
| infinity | darkxst: Well, that also makes some sense, being that you're in the initrd still. | 10:04 |
| infinity | darkxst: Perhaps scripts/casper-bottom/32disable_hibernation might give some hints? | 10:06 |
| infinity | The only occurrence of the string "freedesktop", was a grep in the dark. :P | 10:07 |
| infinity | darkxst: Alternately, if it must be done with dbus instead of a config snippet, there's prior art at the end of scripts/casper-bottom/19keyboard | 10:08 |
| darkxst | I tried that, dbus-launch gdbus call ... and it also failed | 10:09 |
| darkxst | will try config snippet | 10:10 |
| infinity | config snippet is at least more comfortably testable once booted. | 10:10 |
| infinity | Since you can login on a tty and mangle it, and then restart gdm. | 10:11 |
| infinity | If you can come up with a config bit to drop in place, that's probably the simplest. | 10:11 |
| darkxst | not to mention I somehow lost my ability to type in the init shell ;( | 10:12 |
| darkxst | well short of mashing each key 10 times | 10:12 |
| darkxst | infinity, I don't quite see how polkit actions correlate to dbus properties | 10:23 |
| darkxst | its seem to be more about access to dbus etc? | 10:24 |
| infinity | darkxst: Well, fair. Was just figuring there might be some generit config snippet way to abuse other bits on boot. | 10:24 |
| infinity | dbus is very not my area of expertise. | 10:24 |
| darkxst | like that snippit from before just says, no you can;t call that method | 10:24 |
| * infinity experiments. | 10:28 | |
| === DrKranz is now known as DktrKranz | ||
| doko | seb128, please could you have a look at the libspectre ftbfs? http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html | 10:42 |
| seb128 | doko, k | 10:43 |
| seb128 | doko, likely need https://cgit.freedesktop.org/libspectre/commit/?id=34a52f30400aab1c21c69c31122d496751d7d99e | 10:44 |
| infinity | darkxst: So, I'm thinking you might want to stuff a systemd service in that launches with gdm and pokes dbus then, or something gross like that. | 10:49 |
| darkxst | infinity, I was just thinking exactly the same thing | 10:50 |
| infinity | darkxst: Not only is dbus intentionally unconfigured on the squashfs (which one can hack around early, and I did), then it still fails to love me for other reasons. | 10:50 |
| infinity | darkxst: Pretty sure that call in 19keyboard, if ever reached, doesn't work. :P | 10:50 |
| darkxst | accountsservice has code to set the PasswordMode flags, but not sure if they are trigger by the low level tools at all, and certainly not before the daemon is running! | 10:52 |
| doko | jamespage, python-oslo.service is dep-wait | 10:52 |
| infinity | darkxst: Right, so you probably want to inject a service that starts After=gdm.service (or gdm3 or whatever it is), and just does the poking then, and Bob's your ungle. | 10:54 |
| infinity | Or uncle. | 10:54 |
| infinity | darkxst: A oneshot service, obviously. | 10:55 |
| darkxst | infinity, actually Bob is my uncle :P | 10:55 |
| darkxst | yes of course | 10:55 |
| infinity | Hah. | 10:56 |
| infinity | Growing up in a part of the world without that idiom, it confused me to no end when I first heard it. | 10:56 |
| infinity | And now I seem to be infected. | 10:56 |
| darkxst | its pretty common around here, but always seemed strange when its just a real fact | 10:57 |
| pitti | Saviq: what's up? | 10:59 |
| jamespage | coreycb,^^ re oslo.policy | 11:01 |
| darkxst | infinity, anywill I will play with a systemd service, but in the meantime would be good to get bug 1565177 landed | 11:01 |
| ubottu | bug 1565177 in ubuntu-release-upgrader (Ubuntu) "screensaver is not disabled during release upgrade" [High,In progress] https://launchpad.net/bugs/1565177 | 11:01 |
| darkxst | that causes some nasty side-effects if the screenlocks! | 11:02 |
| pitti | rbasak: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-5.7 now holds up a sizable number of packages in -proposed, as we build everything against the new library now; dbconfig-common is still failing even after the previous patch, and its own tests are now failing too | 11:05 |
| pitti | rbasak: not sure if you are already aware, as we don't have email notifications on test regressions, so relaying on IRC :0 | 11:05 |
| pitti | and it seems ruby-mysql needs adjustment too ("Access denied for user 'root'@'localhost' | 11:06 |
| rbasak | pitti: thanks. We're aware. Skuggen and I are working on it. | 11:06 |
| pitti | rbasak: great, thanks | 11:07 |
| pitti | yofel: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#baloo-kf5 has been stuck on the 32 bit regression for a month now; should we pull this from -proposed? | 11:07 |
| yofel | pitti: I'm not sure what to do there, maybe... when I asked upstream what they're proposal is the response was "we don't support 32bit, over" | 11:08 |
| pitti | oh, wow | 11:08 |
| pitti | I thought ARM was a target for KDE | 11:08 |
| yofel | maybe they simply didn't care about the tests, but it's not like this would work in real work conditions... and I don't think we have 32bit testers in our team either | 11:10 |
| yofel | OTOH, I'll ask around if someone can test the old baloo and see how that works. Most people run the 64bit build from our PPA | 11:11 |
| pitti | there's the theoretical option of removing the binaries from i386 and armhf, but it has a sizable chunk of reverse dependencies | 11:11 |
| Skuggen | pitti: The dbconfig failure now seems to be a dependency issue | 11:11 |
| Skuggen | pitti: I've fixed ruby-mysql2, actually | 11:12 |
| infinity | yofel: "We don't support 32-bit" is a pretty crazy stance for an upstream. The bug is probably trivial too. | 11:12 |
| pitti | Skuggen: oh, https://launchpad.net/ubuntu/+source/ruby-mysql2/0.4.3-2build2 ? (it fails to build) | 11:12 |
| yofel | infinity: well yeah, but I couldn't get anyone to help me figure it out, and I don't have enough time myself to troubleshoot C++ code :( | 11:13 |
| Skuggen | pitti: No, I only uploaded it to the test ppa we're using, so far | 11:13 |
| pitti | Skuggen: ah, ok; great to hear that there's progress, thanks | 11:13 |
| infinity | yofel: Is there a bug filed, perhaps with (hopefully) a gdb backtrace? | 11:13 |
| Skuggen | pitti: It needs an --insecure to the mysql_db_install command | 11:13 |
| infinity | yofel: It'll probably jump out as someone doing a long->int conversion somewhere and chopping off half, or something similar. Might even jump out in compiler warnings in the build log. | 11:14 |
| yofel | bug not sure, but I do have a gdb backtrace somewhere. I'll gather that later | 11:14 |
| infinity | And "we don't support 32-bit" is a poor excuse for writing bad C, if it's that sort of bug. :P | 11:15 |
| infinity | s/C/C++/ but same thing in this case. | 11:15 |
| pitti | oh, it seems the previous version didn't even run the test suite as part of the autopkgtest | 11:17 |
| pitti | so it might not actually be a regression, but just expose the 32 bit crash now as we actually run the tests now | 11:17 |
| infinity | pitti: It's possible. If that can be confirmed, I'm happy with a badtest on it for now. But it's clearly also shoddy code and a real bug. | 11:17 |
| infinity | I'm also wondering how badly one needs to screw up to segv while moving a file... | 11:18 |
| infinity | That should be, like, two lines. | 11:18 |
| yofel | IIRC the crash came from the DB initialization or something like that | 11:19 |
| infinity | yofel: But every other test passes. So, that's a bit fishy. Unless it's the test itself passing shoddy data, and the backend is fine. | 11:19 |
| yofel | I still had gdb open on my raspi: http://paste.ubuntu.com/15645578/ | 11:21 |
| yofel | I can try the old version later and see if that crashes the same | 11:23 |
| infinity | Not guaranteed to be the issue, but... | 11:24 |
| infinity | In file included from ../../../src/engine/transaction.cpp:38:0: | 11:24 |
| infinity | ../../../src/engine/idutils.h: In function ‘quint64 Baloo::devIdAndInodeToId(quint32, quint32)’: | 11:24 |
| infinity | ../../../src/engine/idutils.h:37:44: warning: cast from ‘quint32* {aka unsigned int*}’ to ‘quint64* {aka long long unsigned int*}’ increases required alignment of target type [-Wcast-align] | 11:24 |
| infinity | return *(reinterpret_cast<quint64*>(arr)); | 11:24 |
| infinity | ^ | 11:24 |
| infinity | ../../../src/engine/idutils.h:37:45: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] | 11:24 |
| infinity | return *(reinterpret_cast<quint64*>(arr)); | 11:24 |
| infinity | ^ | 11:24 |
| infinity | That looks preeeeeeetty suspicious. | 11:24 |
| yofel | pitti, infinity: baloo-kf5 5.15 fails the same, so feel free to badtest it | 11:47 |
| infinity | pitti: Be my guest, I'm still injecting enough caffeine to understand how keyboards work. | 11:48 |
| Skuggen | Hehe | 11:49 |
| Skuggen | I feel like I've been banging my head on these packages for a full day already :| | 11:49 |
| Skuggen | well, many many days, really | 11:49 |
| zyga | jdstrand: hey, I'm adding a flag to all interfaces that indicates if it should auto-connect | 12:14 |
| zyga | jdstrand: I'd love a review of that when you have a moment | 12:14 |
| jdstrand | zyga: sure thing | 12:18 |
| jdstrand | just point me at it | 12:18 |
| zyga | jdstrand: currently nothing auto conncets | 12:18 |
| zyga | *connects | 12:18 |
| zyga | I was wondering if I should do a quick pass for likely candidates | 12:19 |
| infinity | @pilot in | 12:20 |
| === udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: beta freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity | ||
| jdstrand | zyga: well, that depends on the autoconnect policy and how assertions play into. prior to 16.04, we would autoconnect everything and let the store (review tools) flag on dangerous stuff | 12:20 |
| jdstrand | I don't have the larger picture of how autoconnect is supposed to work | 12:20 |
| jdstrand | in 16.04 | 12:20 |
| flexiondotorg | infinity, seb128 If you have the time I have a couple of small sponsoring requests I really like to get integrated. | 12:21 |
| flexiondotorg | https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1563971 | 12:21 |
| ubottu | Launchpad bug 1563971 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 16.04.6 bug fix release [debdiff attached]" [Undecided,New] | 12:21 |
| zyga | jdstrand: I'd be conservative now, we can always be more lenient later | 12:21 |
| zyga | jdstrand: I'd do network and network-bind | 12:21 |
| === _salem is now known as salem_ | ||
| zyga | jdstrand: and perhaps nothing else for now | 12:22 |
| flexiondotorg | IN fact, it is just that one for now. | 12:22 |
| jdstrand | zyga: I agree | 12:22 |
| jdstrand | the other things give privileges access | 12:22 |
| jdstrand | privileged* | 12:22 |
| zyga | jdstrand: cool, I'll open the pull request shortly | 12:23 |
| jdstrand | zyga: what happens if a snap plugs say firewall-control and you install it? ie, it isn't autoconnected | 12:23 |
| zyga | it isn't auto-connected | 12:24 |
| jdstrand | heh | 12:24 |
| jdstrand | I get that | 12:24 |
| zyga | I think we'll auto connect that when assertions are in place | 12:24 |
| zyga | (that was hard to parse) | 12:24 |
| jdstrand | I mean, what is the UX | 12:24 |
| zyga | ahh | 12:24 |
| zyga | well, nothing happens | 12:24 |
| zyga | the UX is poorish now | 12:24 |
| jdstrand | the user just has to know to connect it? or is there some sort of feedback? | 12:24 |
| zyga | with auto-connect nothing happens either | 12:24 |
| zyga | there's none right now (install still hasn't landed) | 12:24 |
| zyga | but there are ideas on how to do that | 12:24 |
| zyga | it's just so so post 16.04 | 12:25 |
| jdstrand | I see | 12:25 |
| infinity | flexiondotorg: On it. | 12:26 |
| zyga | we have ways to push messages (websocket); currently (AFAIR) we poll; the bigger issue is that there's no UX design yet | 12:26 |
| flexiondotorg | infinity, Cheers. | 12:26 |
| flexiondotorg | infinity, Just preparing what should be that last one. | 12:26 |
| flexiondotorg | Ubuntu MATE Welcome fixes and new translations. | 12:27 |
| * zyga realized this is the wrong channel | 12:27 | |
| infinity | flexiondotorg: You might want to switch ubuntu-mate-artwork from native to non-native so you can stuff all those massive images in an orig. | 12:29 |
| * infinity says, uploading a 67MB package. | 12:30 | |
| flexiondotorg | infinity, OK. Can that be a 16.10 thing? | 12:30 |
| infinity | flexiondotorg: Sure. Well, this also assumes you change non-image bits more often than the images. | 12:31 |
| infinity | flexiondotorg: If both change a lot, you won't get much of a win from breaking it apart. *shrug* | 12:31 |
| infinity | flexiondotorg: I have 10Mb up, I'm just being whiney. :P | 12:31 |
| flexiondotorg | infinity, I have 4Mb up ;-) | 12:31 |
| flexiondotorg | Added to the work sheet for 16.10. | 12:32 |
| infinity | flexiondotorg: Like I said, it only makes sense if the text/theme bits change more often than the images (or if there are translations in there you update regularly, etc) | 12:32 |
| infinity | flexiondotorg: If you're constantly replacing images, you kinda lose, and the current format works fine. | 12:32 |
| flexiondotorg | Generally we do all the image and theme changes together. | 12:33 |
| flexiondotorg | Then you get a few theme only fixes toward the end of the cycle. | 12:33 |
| infinity | flexiondotorg: Yeah, so ignore me. The current format works, I'll just complain less. | 12:33 |
| flexiondotorg | infinity, I do appreciate all the feedback. I want to learn best practice. | 12:33 |
| pitti | yofel, infinity: hinted | 12:34 |
| yofel | thanks | 12:34 |
| infinity | pitti: Do you have context on the weird gcc-5-cross-ports madness in excuses? | 12:35 |
| infinity | pitti: Or, rather, the lack of it in excuses. | 12:35 |
| pitti | infinity: this one? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-defaults-ports | 12:35 |
| Saviq | pitti, actually I think I managed - the default pinning on touch devices made it so adt did not pick up the newer packages in the PPA - I'm checking now whether that's the case (unless you can already tell me otherwise - I didn't know pinning affects how adt selects the source package to test) | 12:35 |
| pitti | infinity: no, doesn't tell me anything | 12:35 |
| infinity | pitti: No, the thing it depends on. That isn't there. | 12:36 |
| infinity | pitti: gcc-5-cross-ports is in -proposed, and britney knows enough to know that gcc-defaults-ports depends on it, but... It's not there. | 12:36 |
| infinity | pitti: Which is a bit 'wat'. | 12:36 |
| pitti | infinity: I don't understand -- there simply is no binary gcc-5-cross-ports | 12:37 |
| infinity | pitti: No. It's a source package. | 12:37 |
| pitti | i. e. I suppose that's a wrong dependency in the new gcc-defaults-ports or so | 12:37 |
| infinity | pitti: Which isn't in excuses. | 12:37 |
| infinity | pitti: Despite being in proposed. | 12:37 |
| pitti | not according to rmadison | 12:38 |
| doko | pitti: but which one would that be? | 12:38 |
| pitti | $ rmadison gcc-5-cross-ports | 12:38 |
| pitti | gcc-5-cross-ports | 7ubuntu3 | xenial/universe | source | 12:38 |
| * infinity blinks. | 12:38 | |
| infinity | https://launchpad.net/ubuntu/+source/gcc-5-cross-ports/7ubuntu4 | 12:38 |
| infinity | Okay, I can copy it over itself to fix that, but before I do, I think this needs an LP person to examine WTF. | 12:38 |
| pitti | yeah, it seems it never got published | 12:39 |
| infinity | cjwatson: Yo, LP person. | 12:39 |
| infinity | https://launchpad.net/ubuntu/+source/gcc-5-cross-ports/7ubuntu4/+publishinghistory <-- WTF, iz not on disk. | 12:39 |
| infinity | cjwatson: Assuming copying it over itself will "fix" it, but figured you might want the current state to persist long enough to cry a bit. | 12:39 |
| pitti | doko: as britney says -- gcc-defaults-ports binary depends on gcc-5-cross-ports which doesn't exist | 12:40 |
| doko | yeah, it's the unpublished package | 12:40 |
| pitti | no, not really -- that binary isn't on https://launchpad.net/ubuntu/+source/gcc-5-cross-ports/7ubuntu4/+build/9385392 either | 12:41 |
| pitti | i. e. that's not just a publishing problem | 12:41 |
| doko | there is no gcc-5-cross-ports binary | 12:41 |
| infinity | pitti: That binary dep also doesn't exist in the build. | 12:42 |
| infinity | pitti: As in, I think britney's just super confused right now, due to the unpublished mess. | 12:42 |
| pitti | yeah, apparently; I figure the "impossible dependency" thing is source based, as gcc-defaults-ports also does not exist as a binary | 12:43 |
| infinity | ... | 12:43 |
| infinity | All the binaries are published, but not the source? | 12:43 |
| infinity | *head explodes* | 12:43 |
| * infinity will give Colin an hour or so to respond and have a poke at it before he just fixes it. | 12:44 | |
| infinity | doko: Should clear up later today if that's the only issue (which I think it is). | 12:44 |
| infinity | wgrant: If you're around, you might be interested. | 12:44 |
| cjwatson | It's in pool but not dists, hmm | 12:46 |
| cjwatson | 2016-04-06 12:10:17 INFO a-f: E: DSC file '/srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/g/gcc-5-cross-ports/gcc-5-cross-ports_7ubuntu4.dsc' is too large! | 12:46 |
| cjwatson | haha, go apt-ftparchive | 12:46 |
| infinity | cjwatson: Which would imply either it's not ending up in the file list, or... Very broken a-f cache? | 12:46 |
| infinity | Oh. | 12:46 |
| infinity | WAT. | 12:46 |
| infinity | Fixed buffer? | 12:46 |
| cjwatson | too many binaries for a-f's little mind, I imagein | 12:46 |
| cjwatson | *imagine | 12:46 |
| infinity | At least it doesn't overflow it? :P | 12:46 |
| doko | seb128, will you fix libspectre? | 12:47 |
| infinity | mvo: Dude. | 12:47 |
| cjwatson | So copying over itself is unlikely to help. | 12:47 |
| infinity | cjwatson: Indeed. | 12:47 |
| mvo | infinity: hm? | 12:47 |
| infinity | cjwatson: Is that happening on every publisher run? | 12:47 |
| seb128 | doko, feel free to do it if you want, but otherwise yes, I've it on my list, just dealing with some other things I had started before | 12:47 |
| doko | ta | 12:47 |
| infinity | mvo: 2016-04-06 12:10:17 INFO a-f: E: DSC file | 12:47 |
| infinity | '/srv/launchpad.net/ubuntu-archive/ubuntu/pool/universe/g/gcc-5-cross-ports/gcc-5-cross-ports_7ubuntu4.dsc' is too large! | 12:47 |
| cjwatson | infinity: Sure is. | 12:47 |
| infinity | cjwatson: Kay, so a fixed apt will magically fix it. That's something at least. | 12:47 |
| infinity | mvo: We can haz fix for that? :P | 12:48 |
| mvo | infinity: uh, I think so | 12:48 |
| cjwatson | It's fixed in latest apt | 12:48 |
| doko | cjwatson, could be, builds two more cross compilers than the same package in debian | 12:48 |
| cjwatson | But I'm guessing not trusty's | 12:48 |
| infinity | cjwatson: You already hunted down a fixed commit? | 12:48 |
| pitti | wgrant, doko: hm, it seems the retry on dutch works, but gnupg-doc retry still FTBFS (without an useful error message in the log); I still can't reproduce in a local build | 12:48 |
| cjwatson | 31be38d205406d4c756684e20b93d62c4701e091 | 12:48 |
| mvo | most (all?) fixed buffers got fixed in the recent months so happy to hear that this is not an issue in 16.04 | 12:48 |
| cjwatson | "128 KiB DSC files ought to be enough for everyone" | 12:49 |
| infinity | Heh. | 12:49 |
| cjwatson | Let's see if it backports easily | 12:49 |
| mvo | the whole commit message is very nice indeed | 12:49 |
| infinity | Right, if we can get a single-commit SRU, v-done it with a rollout to pepo, that would work for me. | 12:51 |
| cjwatson | pepo's already running a patched backport, so I'm just going to patch it further for now | 12:51 |
| cjwatson | (Yes, this isn't completely ideal, but until we get round to SRUing source caching ...) | 12:51 |
| infinity | cjwatson: Oh, is it? What are we missing in the archive? | 12:52 |
| infinity | cjwatson: Oh, we never SRUed source caching? | 12:52 |
| infinity | cjwatson: I guess we could just upgrade to xenial soon and never bother. | 12:52 |
| infinity | mvo: Still probably worth SRUing that commit, I guess, for anyone running trusty's a-f against either doko's cross madness or the Debian linux package. | 12:53 |
| infinity | mvo: But far less urgent if Colin's fixing it out of band for ftpmaster. | 12:53 |
| cjwatson | We also have some array -> std::vector backports from 1.1~exp1 | 12:54 |
| cjwatson | But it is indeed all backports, nothing original | 12:54 |
| infinity | cjwatson: I'm inclined to suggest that we just make pepo->xenial an upgrade priority. | 12:55 |
| infinity | cjwatson: I mean, I'm all for real bugfixes (like this one) in trusty, but feature backports probably don't make sense this close to a new LTS. | 12:55 |
| cjwatson | It'll be a policy argument. | 12:55 |
| cjwatson | Because of the "newer than precise, you have to juju" rule. | 12:55 |
| infinity | cjwatson: Surely, pepo has a free pass on the... That. | 12:55 |
| cjwatson | Hasn't had to come up yet. | 12:56 |
| infinity | cjwatson: Given it's basically the backbone of everything. | 12:56 |
| cjwatson | (Also I'm not sure we've tried running LP code on xenial, and running LP spanning three LTSes is a bit exciting.) | 12:56 |
| cjwatson | trusty with a direct backport of xenial's apt might be more feasible. | 12:57 |
| infinity | Well, by "make a priority", I didn't mean "upgrade blindly and hope". ;) | 12:57 |
| infinity | The last time we did that went so well. | 12:57 |
| ogra_ | if it is high-priority-hope ? | 12:57 |
| infinity | cjwatson: Odd of landing that before EOD? I'd like to tick this one off the WTF list. | 12:58 |
| infinity | cjwatson: Though, I also really want the donkey model, so... | 12:58 |
| cjwatson | infinity: EOD today is ambitious, but I'll get things moving and EOD tomorrow should be doable. | 12:59 |
| infinity | cjwatson: Kay. WFM. It's been broken for ages, just want it off the list "soon". | 12:59 |
| infinity | doko: Looks like you get fixed tomorrowish. | 12:59 |
| cyphermox | awe: what's your fix for VPN? I wouldn't mind applying it here now ;) | 13:00 |
| awe | did you seee the bug? | 13:00 |
| awe | https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1552424/comments/20 | 13:01 |
| ubottu | Launchpad bug 1552424 in network-manager-vpnc (Ubuntu) "[FFE] NetworkManager 1.2-beta" [Undecided,Confirmed] | 13:01 |
| seb128 | awe, good work figuring it out! | 13:01 |
| awe | cyphermox, I haven't been able to verify it yet | 13:01 |
| awe | but pretty sure that's it | 13:01 |
| seb128 | cyphermox, awe, does it mean the packages would be good to go now if release was to give an ack? | 13:01 |
| awe | no | 13:01 |
| seb128 | :-( | 13:01 |
| awe | well... maybe | 13:01 |
| awe | cyphermox's package is based on beta1 | 13:02 |
| awe | my package for the phone is based on beta2 | 13:02 |
| seb128 | if it's not this week we can forget about it | 13:02 |
| awe | and rc1 was released yesterday | 13:02 |
| cyphermox | ahah oops | 13:02 |
| awe | and...there's at least one crasher bug fixed in rc1 | 13:02 |
| seb128 | how come cyphermox and you are working on different packages? | 13:02 |
| awe | that I reported upstream | 13:02 |
| seb128 | looks like everybody should work on the xenial package atm to get that landed | 13:02 |
| awe | because cyphermox stopped working on it, and I kept moving fwd and re-based last week on beta2 | 13:03 |
| seb128 | we don't have a working touch/xenial atm so that can probably be rebased then? | 13:03 |
| cyphermox | seb128: package version at that level is more or less irrelevant, as long as it's >=1.1.91 | 13:03 |
| awe | correct, no working touch xenial | 13:03 |
| seb128 | awe, I guess I don't understand why you two don't work on a common vcs | 13:03 |
| seb128 | rather than duplicating work | 13:03 |
| seb128 | or diverging | 13:03 |
| cyphermox | awe: so that was my fault I thinko'd when I ported to setserversex, sorry | 13:03 |
| awe | because (a) we forked from desktop due to lack of stability | 13:04 |
| awe | and desktop kept moving fwd | 13:04 |
| cyphermox | seb128: it's a branch I have where I did the work before merging to lp~network-manager/network-manager/ubuntu, which is the correct packaging branch | 13:04 |
| awe | I started working in moving touch from 0.9.10x ( the vivid version ) to 1.2 | 13:04 |
| awe | an then cyphermox picked up on the same | 13:04 |
| awe | but again... there are differences our 1.2 branches dues to xenial vs. vivid | 13:05 |
| seb128 | k, so basically the fork has bitten us | 13:05 |
| awe | no, not really | 13:05 |
| cyphermox | no, it has not | 13:05 |
| cyphermox | what bit you is that I don't have the time to work as hard on NM | 13:05 |
| awe | it kept touch somewhat stable... and we were really waiting for 1.2, as it re-wrote significant portions of the WiFi code | 13:05 |
| seb128 | right | 13:06 |
| seb128 | I guess I would have started by updating the xenial/desktop codebase to current beta | 13:06 |
| seb128 | before doing that for the phone as you did | 13:06 |
| seb128 | because if we don't land the desktop side now we don't do it at all | 13:06 |
| seb128 | oh well | 13:06 |
| seb128 | I guess that part is past and we all agree we should update cyphermox's vcs to rc1 | 13:07 |
| seb128 | and land to xenial | 13:07 |
| cyphermox | that's not entirely true -- we could do a xenial overlay | 13:07 |
| awe | for what? | 13:07 |
| awe | touch? | 13:07 |
| seb128 | for touch | 13:07 |
| seb128 | if xenial doesn't get 1.2 | 13:07 |
| awe | that's a bit premature | 13:07 |
| cyphermox | for landing 1.2 to "xenial" and then land vivid | 13:07 |
| cyphermox | right, if we can't upload to -release | 13:07 |
| awe | as we don't know if the phone will be re-based on 16.04 or 16.10 | 13:07 |
| awe | ( if & when we upgrade ) | 13:08 |
| infinity | mvo: Every time I see a commit message or comment like that, I'm reminded of Will's rapid descent into madness in the comments of: https://git.collabora.com/cgit/user/sjoerd/wocky.git/commit/?id=f6f96522cc9ff0e7541f6087f254e62900454fbf | 13:08 |
| awe | I'm still of the opinion that desktop 16.04 should get nm1.2 either prior to release, or post release as a SRU | 13:08 |
| flexiondotorg | infinity, If you are able this would be a big help for the Ubuntu MATE team - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1566837 | 13:08 |
| ubottu | Launchpad bug 1566837 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.7 bug fix and translations [dsc attached]" [Undecided,New] | 13:08 |
| cyphermox | awe: it's not that simple | 13:09 |
| awe | well.. then we end up with an LTS with an older version of NM | 13:09 |
| awe | if everyone's fine with that | 13:09 |
| awe | so be it | 13:09 |
| awe | touch *is* moving to 1.2, as we're continually battling problems WiFi with 0.9.10, and 1.0x doesn't help us | 13:10 |
| cyphermox | as I mentioned, just convince the release team that that upload is bug-free ;) | 13:11 |
| infinity | cyphermox: No upload of NM is ever bug-free. | 13:11 |
| infinity | cyphermox: So, it's more about trading bug we know for bugs we don't. | 13:11 |
| cyphermox | ok, reasonably looking like the bugs aren't terrifying | 13:11 |
| infinity | flexiondotorg: Are all these -welcome changes tested? It's a pretty unreviewable diff. | 13:14 |
| flexiondotorg | They are extremely well tested. | 13:14 |
| cyphermox | awe: I'm testing your patch as soon as it's done building | 13:14 |
| flexiondotorg | And we are highly motivated to ensure Welcome works properly. | 13:14 |
| barry | uh oh. with today's dist-ugprade, has alt-backtick broken for anybody else? | 13:16 |
| infinity | barry: WFM, but I haven't logged out in a while. | 13:16 |
| awe | cyphermox, k | 13:16 |
| seb128 | cyphermox, do you have any slot to update your branchs/ppa to rc1? or do we need somebody to help with that? | 13:16 |
| seb128 | cyphermox, did you mention to slangasek that this update was kind of important and that it would be nice if other could maybe help | 13:17 |
| barry | infinity: yeah, i just dist-upgraded and rebooted. looks like a regression. i'll dig in a bit | 13:17 |
| cyphermox | it's quick enough, I'll bump the version and see if things still build | 13:17 |
| awe | seb128, as mentioned, I can problem prepare a branch after I finish with the touch update | 13:17 |
| awe | unless cyphermox can do so | 13:17 |
| cyphermox | seb128: I mentioned I didn't know if the desktop team felt it was critical to land in xenial | 13:17 |
| seb128 | e.g Łukasz worked on some of the updates in the cycle | 13:17 |
| cyphermox | to me it seems like we pretty well missed the deadline. | 13:17 |
| cyphermox | (since as infinity mentioned, no NM upload is ever bug-free) | 13:18 |
| infinity | With two weeks until release, I'd need a pretty solid commitment from the desktop team to clean up any regressions found very, very quickly. | 13:18 |
| cyphermox | awe: it would help me a whole lot if you could (or anyone really) take the packages currently in my PPA or buildable from the code branch and see if autopkgtest is happy with them | 13:18 |
| infinity | And words are cheap. :P | 13:19 |
| awe | cyphermox, I have to admit, I don't know how to do that | 13:19 |
| awe | that said, I will volunteer to create an updated branch for rc1 | 13:19 |
| awe | and do that before I update the touch branch | 13:19 |
| awe | cool with you? | 13:19 |
| seb128 | bah, that all sucks | 13:19 |
| seb128 | I though it was handled when cyphermox files the ffe a month earlier | 13:20 |
| seb128 | that's why we didn't look at it more | 13:20 |
| seb128 | it would be a real shame to not have the update in the LTS | 13:20 |
| cyphermox | awe: http://packaging.ubuntu.com/html/auto-pkg-test.html | 13:20 |
| awe | lI still fail to see why this couldn't be SRU'd with proper testing vs. trying to rush this now | 13:20 |
| smoser | pitti, have you seen issues adt-run and adt-virt-qemu on amd (non-intel amd64) | 13:21 |
| infinity | SRUing new versions is even more dangerous than shoving them in at the last minute. | 13:21 |
| infinity | Because NM is notorious for changing behaviour. | 13:21 |
| smoser | last night i ran and it complained that kvm was not available (i assume in a nested guest). | 13:21 |
| infinity | And users like the (mis)features they know to keep working (or not) the same way. | 13:21 |
| seb128 | awe, you can't mess up SRUs, you have customers/real world business depending on things to be stable | 13:21 |
| seb128 | better to get a bug in release and fix it in a SRU | 13:21 |
| seb128 | than creating it in a SRU | 13:21 |
| pitti | smoser: I'm not aware of any, no; what do you see? | 13:21 |
| smoser | well, just that. i dont have the log, but i'm running again and will collect it. from memory, it was kvm module i think. i'll get the log. | 13:22 |
| xnox | smoser, adt-run by default doesn't cause nested kvm... and i'm not sure if nested accelerated kvm is supported on amd. | 13:22 |
| smoser | xnox, nested accelerated kvm is supported on amd (and was years before that landed in intel) | 13:22 |
| infinity | seb128: If you can hunt down people willing to take ownership (including their management chain signing off on them spending the time to *actually* take ownership), I'm not completely against a late update of NM. But of all our upstreams, they're one of the worst for introducing more bugs than they fix. | 13:23 |
| xnox | cool | 13:23 |
| seb128 | infinity, btw, n-m is maintained by foundations (cyphermox) afaik? | 13:23 |
| smoser | hm.. adt-run doesn't by default cause nested kvm. | 13:23 |
| pitti | xnox: ubuntu's qemu packages enable nested kvm by default | 13:23 |
| smoser | ok, then its probably not nested that did it :) | 13:23 |
| infinity | seb128: Not sure who actually owns it. Maybe us. But we're not the ones asking for the update. :P | 13:23 |
| pitti | xnox: and recent autopkgtest also enables it for Debian's qemu | 13:23 |
| xnox | seb128, hehehe who is no longer in ue/devices =) | 13:23 |
| pitti | smoser: ^ | 13:23 |
| smoser | currently running: adt-run -dd --apt-upgrade --built-binaries --unbuilt-tree open-iscsi/ -o /home/ubuntu/tmp/adt-tmp/ --- adt-virt-qemu --ram-size=2048 -d adt-xenial-amd64-cloud.img | 13:23 |
| seb128 | infinity, well, cyphermox filed the ffe :p but yeah, in any case if we can update I would be happy for desktop to help tracking issues/getting them resolved as a priority | 13:23 |
| smoser | from matsubara's open-iscsi branch. | 13:24 |
| pitti | smoser: btw, matsubara is working on the nested open-iscsi tests, he just asked me to re-run the test from git | 13:24 |
| pitti | smoser: ah, you're aware of that, good | 13:24 |
| seb128 | cyphermox, are you swamped with other work or could you handle updating to rc1 and landing the update if the ffe is acked? | 13:24 |
| pitti | smoser: http://autopkgtest.ubuntu.com/running.shtml#pkg-open-iscsi has running tests from matsubara's git | 13:25 |
| cyphermox | seb128: it's maintained by me only because I was the last to touch it, it's not something that would normally be under foundations. | 13:25 |
| seb128 | slangasek, ^ can we cyphermox to get some slots to get the n-m update in the lts? | 13:25 |
| cyphermox | seb128: and I care enough about it to do updates when I can | 13:25 |
| seb128 | cyphermox, why not? it's infra | 13:25 |
| === directhex_ is now known as directhex | ||
| cyphermox | because it's infra only used by desktop :) | 13:25 |
| awe | and touch, and snappy | 13:25 |
| infinity | If nm-cli had ever become a useful thing, maybe it would be for everyone. | 13:26 |
| seb128 | well, anyway, no point to argue over ownership | 13:26 |
| infinity | seb128: I was literally just typing that. | 13:26 |
| smoser | ok. pitti so this is probably luser error, but what is going wrong here: http://paste.ubuntu.com/15650198/ | 13:26 |
| seb128 | cyphermox, you have the most context on the package and the update at this point | 13:26 |
| seb128 | so it would be easier if you could help pushing that through | 13:26 |
| seb128 | we can help on bugfixing and look at taking over it/be more involved then | 13:27 |
| infinity | seb128: I know cyphermox is pretty busy from now until release, but you might talk Steve into letting him take a day to clean up NM if your team trades resources to give it love post-upload. | 13:27 |
| pitti | smoser: ah, one of my most favourite zombie bugs, bug 1384706 | 13:27 |
| ubottu | bug 1384706 in autopkgtest (Ubuntu) "tar: Unexpected EOF in archive in copyup()" [Medium,Triaged] https://launchpad.net/bugs/1384706 | 13:27 |
| seb128 | we are just not going to learn the codebase over night | 13:27 |
| awe | seb128, again... I'm willing to do the branch update today | 13:27 |
| pitti | smoser: I can't get this on my machine, and so far I didn't get ssh to a machine where this happens | 13:27 |
| awe | but I may need some help | 13:27 |
| pitti | smoser: usually it helps to just retry | 13:27 |
| seb128 | awe, that would be most useful, thanks ;-) | 13:27 |
| awe | I already have touch 1.2-beta2 prep'd and was planning on re-basing on rc1 today | 13:27 |
| seb128 | awe, right, which is why I'm trying to see if cyphermox can give an hand there | 13:28 |
| awe | with the dnsmasq fix | 13:28 |
| pitti | smoser: but if you can reproduce this reliably, ssh for me to investigate would be highly appreciated; supposedly some weird bug in qemu's 9p file system | 13:28 |
| awe | ( which still needs verification; which cypher is working on ) | 13:28 |
| seb128 | infinity, right , I assumed so, as said we would be happy to pay back the favor by helping with issues due to the update/SRU and other things | 13:28 |
| smoser | pitti, sure. if it fails again i'll let you in. | 13:28 |
| smoser | one thing possibly related was i was | tee out.log | 13:28 |
| smoser | ie, possibly some buffer got in the way or something | 13:29 |
| pitti | smoser: maybe; but with -l out.log it's not entirely different | 13:29 |
| pitti | or -o | 13:29 |
| pitti | smoser: but this is tar unpacking/packing files from a local (or testbed) tmp dir through the auxverb (9p file system in QEMU's case), so it shouldn't be related to the actual terminal | 13:29 |
| smoser | xnox, bah. so adt *does* for this test cause nested kvm. | 13:35 |
| smoser | duh. i should have realized that. thats how this test works. it runs kvm with iscsi root . where iscsi root is provided via tgt on host. | 13:36 |
| xnox | =/ | 13:36 |
| pitti | right, that was the idea | 13:38 |
| pitti | it downloads a cloud image, and boots that (in nested kvm) with open-scsi | 13:39 |
| pitti | matsubara is currently working out some quirks to make that work in scalingstack | 13:39 |
| pitti | as that runs trusty's qemu which works significantly worse with nested kvm than on xenial | 13:39 |
| cyphermox | awe: your fix works, and the code was obviously correct but I spotted something else that is wrong -- it completely replaces nameservers, doesn't include the ones for other connections | 13:40 |
| awe | cyphermox, ack; mind sending me the updated patch when you're done; I'm working on updating your branch for rc1 | 13:41 |
| smoser | pitti, can you confirm something for me? | 13:42 |
| smoser | Restrictions: needs-root isolation-machine breaks-testbed | 13:42 |
| smoser | is that causing each of the 'Tests:' to be run in its own clean environment ? | 13:42 |
| pitti | smoser: the breaks-testbed is, yes | 13:42 |
| smoser | is there a way to say that all these tets could run together (they dont break eachother) but they probably leave the system in a suspect state. | 13:43 |
| pitti | smoser: you can only have the last test declare breaks-testbed, but not the others | 13:43 |
| pitti | saves you the set up of new testbeds in between, indeed | 13:44 |
| smoser | how do you do that ? | 13:44 |
| pitti | Tests: a | 13:44 |
| smoser | http://paste.ubuntu.com/15650640/ | 13:44 |
| pitti | Restrictions: i-m | 13:44 |
| pitti | Tests: b | 13:44 |
| smoser | ah. just multiple lines. that'd be much nicer. | 13:44 |
| pitti | Restrictions: i-m, breaks-testbed | 13:44 |
| smoser | as even as it is right now, *all* the tests are installing qemu-sytem | 13:44 |
| smoser | but only one of them needs it | 13:44 |
| smoser | :) | 13:44 |
| pitti | smoser: if the tests have different test deps, arrange them in the order of "ascending" test deps | 13:45 |
| smoser | yeah, perfect. | 13:45 |
| smoser | thank you. | 13:45 |
| pitti | smoser: if the current test in the list has any test dep that the next test does *not* have, then the next test will get a fresh testbed | 13:45 |
| infinity | pitti: Is it spec that tests are always processed in control order, or just current implementation? | 13:46 |
| pitti | whereas new test deps are just installed | 13:46 |
| infinity | pitti: Cause if people rely on that, it should be specced. | 13:46 |
| pitti | infinity: the intention is certainly that this is the order, and I'd consider it a bug if it's not | 13:46 |
| infinity | (I certainly wouldn't expect order to matter) | 13:46 |
| pitti | well, you can influence it externally of course with --testname | 13:46 |
| smoser | pitti, so 'install' test. | 13:46 |
| pitti | it doesn't matter from a functionality POV, but with arranging the tests in a certain order you can optimize the runtime | 13:46 |
| infinity | Yeah. It's lacking make-style recipe deps. | 13:47 |
| smoser | *should* that 'breaks-testbed' ? | 13:47 |
| smoser | as you'd really not want to re-use a system after installing some arbitrary package. | 13:47 |
| pitti | smoser: well, from that POV all tests would be breaks-testbed | 13:47 |
| pitti | arguably this is a fuzzy concept | 13:47 |
| infinity | Well, no. | 13:47 |
| pitti | it basically means "never try to run this on real iron | 13:48 |
| infinity | Cause "test-deps" can be tracked by the implementation for removal. | 13:48 |
| pitti | merely installing a package should not count as that | 13:48 |
| infinity | Installing something in the test itself can't be tracked. | 13:48 |
| infinity | So that breaks testbed. | 13:48 |
| pitti | infinity: adt-run doesn't do removals | 13:48 |
| smoser | infinity, yeah, and installation of packages and then removal could not possibly cause permenant issues :) | 13:48 |
| infinity | pitti: No, but it could. I'm talking spirit here, not implementation. | 13:48 |
| smoser | even if you spelled permanent right. | 13:48 |
| pitti | it just installs, and if the next test has fewer test deps, it starts over with a fresh testbed | 13:48 |
| infinity | pitti: think old-skool sbuild, where we installed build-deps and removed at the end. That's trackable and, in theory, assuming your packages don't suck, it reverts to a pristine state. Nevermind that we stopped doing that precisely because packages *do* suck, the intent is still valid. :P | 13:49 |
| smoser | for packages in archive, it might be a ideal that you could at least hope for. | 13:50 |
| infinity | So, I'd say anything that fiddles with the root filesystem *in the test* breaks testbed. While installing test-deps from control doesn't. | 13:50 |
| infinity | smoser: piuparts does a pretty good job of testing this, but we don't run it against Ubuntu. We really should. | 13:50 |
| pitti | infinity: right, that's about the common practice | 13:50 |
| smoser | but if you're testing paackages before they get into the archive (or me wanting to test someone elses suggestion) then thats different. | 13:50 |
| pitti | or mucking around with grub etc. | 13:50 |
| smoser | pitti, http://paste.ubuntu.com/15650781/ | 13:51 |
| smoser | that is how its failing for me on amd | 13:51 |
| cyphermox | awe: scratch that, working as designed... | 13:51 |
| infinity | I mean, Debian packages have a pretty good track record of removing cleanly. But it's that 0.5% that ruin it for everyone. :P | 13:51 |
| awe | cyphermox, cool | 13:51 |
| pitti | smoser: in practice, our test infra doesn't have any permanent boxes, so this mostly just controls whether or not the testbed is reset for multiple Tests: within one pacakge | 13:51 |
| barry | infinity: okay, it's a regression in xserver-common, xserver-xorg-core, or xvfb (probably not the latter) | 13:52 |
| infinity | barry: All the same source package, so meh. | 13:53 |
| cyphermox | awe: http://paste.ubuntu.com/15650846/ | 13:53 |
| barry | infinity: yep. and oh, nice ubuntu-bug throws an AssertionError ;) | 13:53 |
| infinity | barry: assert('I HATE YOU AND EVERYTHING YOU STAND FOR') seems to be the default mode for apport when I use it. | 13:54 |
| barry | infinity: more like `assert i_like_you, "yeah i really don't"` | 13:55 |
| infinity | pitti: Oh, that reminds me. apport's "you have out of date packages, loser" check. Is that literally just checking for *any* OOD packages? Cause I've had it whine about things that clearly aren't deps or in any way related to the package I'm filing a bug on, which is irritating. | 13:55 |
| awe | cyphermox, kthanks | 13:55 |
| barry | infinity channels barry | 13:55 |
| pitti | smoser: can you try adding "-cpu kvm64,+svm,+lahf_lm" to the qemu command line? | 13:56 |
| pitti | oh wait, this is the outer qemu, not the inner one | 13:56 |
| pitti | infinity: it only checks OOD packages in the transitive depends of the affected package | 13:56 |
| smoser | well, the outer is trying to run a guest and its failing. | 13:56 |
| pitti | right, see above | 13:57 |
| infinity | pitti: Huh. Maybe it's being a little too generous about what constitutes a meaningful dep, then. I was trying to report a bug on something the other day that clearly wasn't linked to libnih and it had a sad because my libnih was OOD. | 13:57 |
| pitti | the outer qemu already ought to have this | 13:57 |
| pitti | Detected KVM capable AMD host CPU, enabling nested KVM | 13:57 |
| infinity | pitti: But if it's using dpkg deps to determine that, I could see how that might happen. | 13:57 |
| pitti | smoser: ^ this adds -cpu kvm64,+svm,+lahf_lm to the outer qemu command line, but apparently that doesn't work? | 13:58 |
| pitti | i. e. no /dev/kvm in the outer QEMU | 13:58 |
| smoser | right. | 13:59 |
| barry | LP: #1566878 | 13:59 |
| ubottu | Launchpad bug 1566878 in xorg (Ubuntu) "Alt-backtick regression" [Undecided,New] https://launchpad.net/bugs/1566878 | 13:59 |
| smoser | so were you asking me to add '-cpu' ? | 13:59 |
| smoser | because i dont know hwere. i think you were realizing that its not the test that is missing that. | 13:59 |
| pitti | smoser: nowhere, I was confused and thought it'd need to go to the inner qemu-system that the test calls, but that's bogus | 13:59 |
| smoser | right. | 13:59 |
| pitti | smoser: so I guess we need to find the magic -cpu flag that makes /dev/kvm appear in qemu on your amd system | 14:00 |
| matsubara | pitti, smoser: amd64 tests passed: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-ppa/xenial/amd64/o/open-iscsi/20160406_135614@/log.gz but it seems i386 tests are stuck | 14:00 |
| pitti | yeah, http://autopkgtest.ubuntu.com/running.shtml#pkg-open-iscsi | 14:01 |
| infinity | barry: You can twiddle those package versions up and down and confirm that's the culprit? That's a weird bug to blame on the xserver. | 14:01 |
| smoser | pitti, is there a reason you '-cpu <something>' at all ? | 14:02 |
| barry | infinity: i did a bisect dist-upgrade with disk snapshots. those are the only three left | 14:02 |
| pitti | smoser: yeah, upstream's and Debian's qemu don't enable nested KVM by default, that's an ubuntu specific patch | 14:02 |
| infinity | barry: And reupgrading them breaks it again? Bizarre. | 14:02 |
| barry | infinity: yep | 14:02 |
| pitti | smoser: does it work if you drop this from virt-subproc/adt-virt-qemu? | 14:02 |
| smoser | pitti, testing with '-cpu host' | 14:05 |
| pitti | smoser: you can use --- qemu --qemu-options '-cpu host' as a local workaround, BTW (if that helps) | 14:06 |
| pitti | an explicit -cpu option overrides the auto-detection | 14:07 |
| smoser | ah. ok. i just hacked the file | 14:07 |
| smoser | http://paste.ubuntu.com/15651151/ | 14:07 |
| smoser | ^-- does that make sense for the depends changs you suggested ? | 14:07 |
| smoser | i guess you were saying we could also drop the 'breaks-testbed' for the first two Tests: | 14:07 |
| pitti | smoser: I thought you wanted ... that, yes | 14:10 |
| smoser | but since debian has the first two tests and it says 'breaks-testbed', i'd just leave those alone and live with it. | 14:10 |
| pitti | smoser: no test depends at all for "install"? | 14:10 |
| doko | barry: mako, paramiko and the py* ftbfs could need some love ... | 14:11 |
| smoser | so we're just appending Tests | 14:11 |
| smoser | that 'Depends' is from debian, pitti | 14:11 |
| pitti | smoser: ah, it presumably calls apt-get install itself | 14:11 |
| smoser | i'm guessing it only does apt-get install ? | 14:11 |
| smoser | yeah | 14:11 |
| barry | doko: i'll take a look | 14:11 |
| pitti | which is a bit pointless, as the other tests test installation of "apt-get install open-isci" by way of making that a test dep | 14:11 |
| pitti | but *shrug* | 14:12 |
| pitti | smoser: yeah, looks ok; perhaps add some newlines before Tests: to make this a bit easier to read | 14:12 |
| smoser | sure. ok. | 14:12 |
| smoser | so specifically i guess the last does not depend on open-iscsi | 14:13 |
| smoser | as it downloads it from the archive and puts in in the to-be-built guest. | 14:13 |
| smoser | no need for it on the host. | 14:13 |
| smoser | pitti, that did seem to work. (-cpu host) | 14:16 |
| pitti | smoser: ok, good; so I need to get access to some amd machine to figure out how to make this work by default | 14:17 |
| smoser | why wouldnt you just use -cpu host ? | 14:17 |
| pitti | that makes test results harder to reproduce | 14:17 |
| pitti | we have a fair number of tests which are rather hw specific, like mesa or llvm | 14:18 |
| smoser | fair. | 14:18 |
| infinity | pitti: Except that llvmpipe is broken specifically because of qemu's craptastic feature masking. :P | 14:19 |
| pitti | and in scalingstack we also don't do that, but some -cpu SandyBridge option | 14:19 |
| pitti | so in production CI we don't use the qemu runner, but let nova do the qemu setup | 14:19 |
| infinity | pitti: We unbreak it by intentionally unmasking, so it's hard to say that '-cpu host' would make the situation worse. | 14:19 |
| pitti | well, it's bad enough with intel vs. amd; using the host CPU introduces even more jitter | 14:20 |
| infinity | (But I understand the urge for homogenous test environments) | 14:20 |
| infinity | pitti: I'm all for masking in theory, I just hate that qemu sucks so hard at actually doing it. | 14:20 |
| === pavlushka is now known as sleeptime | ||
| infinity | (To be fair, it's hard to do properly, since you have to trap and emulate a bunch of instructions to prevent the guest from divining features without looking at advertised flags) | 14:21 |
| infinity | Thanks, Intel. | 14:21 |
| === sleeptime is now known as pavlushka | ||
| matsubara | pitti, did you restart the test for i386? | 14:22 |
| doko | barry, and gdebi needs a b-d on pyflakes3. saw that you are maintaining this in debian | 14:22 |
| pitti | matsubara: no, I didn't; isn't that still the same hang as with the previous few attempts? | 14:23 |
| barry | doko: pyflakes3, yes | 14:23 |
| pitti | matsubara: oh, I figure it auto-restarted due to tmpfail | 14:23 |
| matsubara | pitti, I thought so, but it looks like now that it went further... | 14:23 |
| matsubara | oh, auto-restart | 14:23 |
| pitti | wow, there's some serious mis-formatting on http://autopkgtest.ubuntu.com/running.shtml#pkg-open-iscsi ATM | 14:23 |
| matsubara | pitti, indeed | 14:24 |
| * pitti saves the HTML for later investigation | 14:24 | |
| matsubara | pitti, can you give me access to the testbed running the i386 test? | 14:28 |
| smoser | matsubara http://paste.ubuntu.com/15651617/ | 14:29 |
| smoser | that is my current diff against yours. re-works debian/tests/control for readability and hopefully to re-use a vm on testsuite | 14:29 |
| smoser | and then also should (i hope) have the tgt-boot command log to the console so it will go right through to the adt captured log and we can see it there. | 14:30 |
| GunnarHj | pitti: Did you see my ping at #ubuntu-deskop? | 14:42 |
| pitti | GunnarHj: ah, missed that, will do (after my current meeting) | 14:42 |
| GunnarHj | pitti: Ok. | 14:43 |
| matsubara | smoser, re-running locally with your changes. Just pushed them to my branch | 14:45 |
| smoser | http://paste.ubuntu.com/15652025/ | 14:47 |
| smoser | that is my latest. i added '--progress=dot:mega' but that is all. and it ran to completion and the guest boot console in the log, which is nice. | 14:48 |
| matsubara | smoser, tests passed locally with your changes and I see the nested vm console output in the screen. | 15:08 |
| infinity | gQuigs: This nsf-utils update. The changes to systemd/nfs-client.target don't seem to make sense in the context of the other changes. | 15:08 |
| infinity | gQuigs: I would have expected just the removal of gssproxy.service from After, not the rewrite of Wants/After. | 15:10 |
| smoser | matsubara, awesome | 15:12 |
| gQuigs | infinity: I think I tried that first | 15:14 |
| gQuigs | infinity: but the rpc-svcgssd.service depends on it so that needed cleanup too | 15:14 |
| infinity | gQuigs: Err, yes. And clean it up you did. But systemd/nfs-client.target still looks wrong. :P | 15:16 |
| infinity | gQuigs: The others look fine. | 15:16 |
| gQuigs | infinity: all I did was remove auth-rpcgss-module.service? | 15:20 |
| infinity | +-Wants=auth-rpcgss-module.service | 15:23 |
| infinity | +-After=rpc-gssd.service rpc-svcgssd.service gssproxy.service | 15:23 |
| infinity | ++Wants=rpc-gssd.service | 15:23 |
| infinity | ++After=rpc-gssd.service | 15:23 |
| infinity | gQuigs: The Wants shouldn't have changed at all, and the After should still include rpc-svcgssd.service | 15:24 |
| infinity | gQuigs: At least, that would seem more correct from how I'm reading this. | 15:24 |
| seb128 | slangasek, hey, saw the n-m discussion in the backlog? can we get some of cyphermox's time to help landing 1.2 for xenial? | 15:26 |
| cyphermox | seb128: didn't awe just say he was doing the update to rc1? | 15:28 |
| seb128 | cyphermox, yes, we still need a coredev to sponsor the upload | 15:28 |
| seb128 | and you probably know the vcs setups/packages/etc the best | 15:28 |
| seb128 | would be nice if that was you doing the review/upload? | 15:28 |
| cyphermox | oh, sure | 15:29 |
| slangasek | seb128: hi, if you just need some of his time for review and sponsorship, that should be ok; but why are we trying to land this so late past FF? | 15:29 |
| cyphermox | I can review, that's not typically a problem | 15:29 |
| seb128 | slangasek, because we think that 1.2 is bringing solide improvements that would benefit the LTS | 15:30 |
| awe | cyphermox, don't know if you ever mentioned the thread from kgunn about this? | 15:31 |
| slangasek | seb128: is that belief based on specific bug references? | 15:31 |
| seb128 | slangasek, cyphermox had a ffe filed in early march and we (desktop) though it was on track to land, then I was on holidays and now I'm picking up the discussion because apparently that didn't got pushed through | 15:31 |
| cyphermox | awe: not sure I saw that? | 15:31 |
| awe | pretty sure you did, as we discussed | 15:31 |
| seb128 | slangasek, see https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1552424 | 15:31 |
| awe | I can re-fwd to you if you'd like | 15:31 |
| ubottu | Launchpad bug 1552424 in network-manager-vpnc (Ubuntu) "[FFE] NetworkManager 1.2-beta" [Undecided,Confirmed] | 15:32 |
| cyphermox | awe: remind me? | 15:32 |
| cyphermox | yes, please | 15:32 |
| * awe looking for it | 15:33 | |
| seb128 | slangasek, it doesn't have much specific references but stgraber / cyphermox / awe seem to agree it would be a good one to get, and the phone team wants that update to fix long standing issues (so they are going to get it in the overlay in any case) | 15:33 |
| awe | yea, it's definitely going into the phone overlay. We're continually getting hammered over WiFi behavior, and nm1.2 has heavily re-factored the WiFi logic, partly based on our discussions with upstream | 15:34 |
| cpaelzer | is there a way to query dpdk/apt/? to get any package out of the archive that would install a file into a path /foo/bar? | 15:35 |
| nacc | slangasek: can you help me understand something? rmadison and p.u.c indicate php-pecl-http are at 3.0.1-0ubuntu4; but apt-cache policy (and my local autopkgtest env) are only seeing 3.0.1-0ubuntu3. Is this just a blip in the migration? | 15:36 |
| nacc | cpaelzer: dpgk-query ? | 15:36 |
| nacc | cpaelzer: specifically dpkg-query -L ? | 15:36 |
| cyphermox | awe: have you confirmed 1.2 fixes these issues or is it just hoping? | 15:36 |
| cpaelzer | nacc: thanks nacc, will take a look | 15:36 |
| awe | cyphermox, I'm sick of trying to continually patch 0.9.10x | 15:37 |
| nacc | cpaelzer: ah maybe -S with a pattern | 15:37 |
| cpaelzer | nacc: I thought that would go only on already installed packages, I'll take a look | 15:37 |
| awe | so far testing has been very positive. The big change was getting rid of NM's own AP list, and making wpa_supplicant the true master | 15:37 |
| cyphermox | right | 15:37 |
| cyphermox | ok then | 15:37 |
| awe | and also I plan to upstream the ofono patches after we're done | 15:38 |
| nacc | cpaelzer: for dpkg, -S does what you say, but for dpkg-query i think it looks at all | 15:38 |
| awe | they're probably going to require some re-work for snappy, and I'd like to get assistance from upstream | 15:38 |
| nacc | cpaelzer: based upon the manpage, that is | 15:38 |
| awe | especially the settting plugin which reads ofono conf files directly from the filesystem | 15:38 |
| cpaelzer | nacc: nope, at least without further options it is equivalend to dpkg -S | 15:39 |
| cpaelzer | nacc: at least that is easy to test with containers that have other packages installed | 15:39 |
| gQuigs | infinity: I don't believe rpc-svcgssd.service needs to run on a client | 15:39 |
| gQuigs | it's a server daemon | 15:40 |
| cyphermox | awe: ack. lubko is keen to see the ofono patches and land them in 1.3 or whatever | 15:40 |
| awe | cyphermox, just fwd'd you the email; it was actually from will cooke | 15:40 |
| nacc | cpaelzer: ah annoying; maybe grep-dctrl? | 15:40 |
| cyphermox | that makes more sense :) | 15:40 |
| cpaelzer | nacc: apt-file search /path/to/file | 15:40 |
| awe | yea... sorry for mix up | 15:40 |
| nacc | cpaelzer: yeah, grep-dctrl should be able to get you the same | 15:41 |
| nacc | cpaelzer: just not sure on the syntax | 15:41 |
| awe | cyphermox, so it looks two patches were upstreamed, so I've dropped them; also a bit of re-factoring of the dnsmasq code required some re-work of our dnsmasq dbus patch | 15:43 |
| awe | but otherwise that's it | 15:43 |
| infinity | gQuigs: And auth-rpcgss-module.service is also server-only? | 15:43 |
| awe | I'll keep you posted if/when I have a clean build and have sanity checked | 15:43 |
| gQuigs | infinity: nope, but our auth_rpcgss gets loaded correctly | 15:50 |
| gQuigs | from the comment on rpcgss-module: | 15:50 |
| gQuigs | # We want to start gss-proxy on kernels that support it and rpc.svcgssd | 15:50 |
| gQuigs | # on those that don't. Those services check for support by checking | 15:50 |
| gQuigs | # for existence of the path /proc/net/rpc/use-gss-proxy. Before they | 15:50 |
| gQuigs | # can perform that check, they need this module loaded. (Unless | 15:50 |
| gQuigs | # rpcsec_gss support is built directly into the kernel, in which case this | 15:50 |
| gQuigs | # unit will fail. But that's OK.) | 15:50 |
| infinity | gQuigs: Oh, I guess Before=rpc-gssd.service picks it up. The previous units were just a bit more redundant. Alright. | 15:54 |
| gQuigs | yea, they were trying to do a conditional on gss-proxy that isn't relevant to us | 15:59 |
| doko | rbasak, I noticed that apache2 can be built with lua5.2 instead of 5.1. not the only 5.1 based package in main, but that would be one less | 16:06 |
| nacc | slangasek: did you ignore the failure for php-horde-http? i think we don't want to do that ... it's a version mismatch that's hiding a real problem (debugging it now) | 16:09 |
| slangasek | nacc: no, pitti did | 16:10 |
| nacc | slangasek: ah ok | 16:10 |
| nacc | slangasek: something is off with php-horde-http & the new php-pecl-http, which is why the other horde tests are failing | 16:10 |
| nacc | still debugging | 16:10 |
| slangasek | ok | 16:11 |
| nacc | and php-monolog failed because something is trying to install php5-mongo, but not sure what yet | 16:11 |
| slangasek | nacc: this covers the php-horde-crypt, php-horde-feed, php-horde-service-gravatar failures then? | 16:11 |
| nacc | slangasek: yep | 16:12 |
| gQuigs | infinity: happy to give you access to my test setup if you want it | 16:12 |
| nacc | slangasek: they are all failing to find the http\Client class | 16:12 |
| infinity | gQuigs: I'll pass. :) | 16:13 |
| slangasek | nacc: php-monolog has an explicit test dep on php5-mongo | 16:14 |
| nacc | slangasek: ah it's a testdep! ok, will fix that | 16:15 |
| slangasek | nacc: I'm halfway through it here fwiw | 16:15 |
| slangasek | nacc: do you know if the new php-mongodb provides the 'MongoDate' class? | 16:17 |
| nacc | slangasek: looking at the source, it does not | 16:17 |
| slangasek | ok then it suffices to drop the test dep | 16:17 |
| slangasek | nacc: ok, dropping the test dep lets the tests run but then there are failures; can I punt this back to you for investigation? http://paste.ubuntu.com/15654907/ | 16:28 |
| slangasek | nacc: errrrm or, it could be that these tests are e,b,w when run as root | 16:28 |
| slangasek | turns out that when you write a test that tries to create /foo/bar and expects it to fail, this doesn't work if you actually have permissions to create /foo/bar | 16:29 |
| ginggs | Unit193: are you around? | 16:30 |
| infinity | slangasek: Hahaha. | 16:30 |
| nacc | slangasek: yeah i've seen a few things like that | 16:31 |
| infinity | One would assume you shouldn't be running those tests as root, then. :P | 16:31 |
| nacc | slangasek: i can look into it; fwiw just s/php5-mongo/php-mongodb/ here, autopkgtest passed | 16:31 |
| Saviq | xnox, hey, a lil' bump - bug #1552914 | 16:31 |
| ubottu | bug 1552914 in boost-defaults (Ubuntu) "Can't install libboost-dev:armhf in a cross-build environment" [Undecided,Confirmed] https://launchpad.net/bugs/1552914 | 16:31 |
| slangasek | infinity: then the test harness should declare this, and/or skip them when you are root ;) | 16:31 |
| nacc | slangasek: and yeah, i've seen those exact issues when running as root | 16:31 |
| infinity | slangasek: The latter, likely, but that's expecting a lot from PHP people. | 16:32 |
| xnox | Sabah | 16:32 |
| xnox | Saviq, bah | 16:32 |
| rbasak | doko: that's bug 1324062. If it works against 5.2, I'm happy with it being switched. | 16:32 |
| ubottu | bug 1324062 in nginx (Ubuntu) "No lua 5.2 support" [High,Triaged] https://launchpad.net/bugs/1324062 | 16:32 |
| slangasek | infinity: unixtojd() is all I have to say. | 16:32 |
| slangasek | doko, rbasak: heh, yes it would be great to not have three copies of lua in main | 16:33 |
| rbasak | kirkland: ^^ I presume you have no objection to apache2 building with lua 5.2 instead of 5.1? AIUI, it's as different as Python 2->3. | 16:33 |
| rbasak | (but a much smaller proportion of users will actually care probably) | 16:33 |
| infinity | slangasek: Pretty much everything in http://php.net/manual/en/ref.calendar.php is crack. | 16:34 |
| pitti | slangasek, nacc: ah, I did because http://autopkgtest.ubuntu.com/packages/p/php-horde-http/xenial/amd64/ is mostly fail with a few sporadic passes; but happy to un-ignore if you have a proper fix | 16:34 |
| doko | slangasek, won't yet work. nginx is 5.1 only, and dh-lua pulls in all three | 16:35 |
| pitti | nacc: so if you upload a new version, the hint doesn't apply any more; if it passes, I'll gladly drop the hint | 16:35 |
| nacc | pitti: ok, still debugging why it's failing, thanks! | 16:35 |
| * pitti waves good bye, time for dinner & basketball | 16:36 | |
| slangasek | doko: dh-lua is a build-dep only and will drop out of main shortly ;) | 16:36 |
| slangasek | doko: but I looked, and all three luae have runtime revdeps in main :P | 16:36 |
| slangasek | infinity: do you remember the unixtojd() bug I'm talking about? Where it returned wrong values depending on which side of UTC you were on, and when someone started hitting this bug because their server's clock left BST, instead of fixing the code they added a +1h to the test case? | 16:38 |
| infinity | doko: Given nginx is stuck anyway, I'm not sure I see the point in bumping apache2 if it might break users on upgrade. | 16:38 |
| infinity | (If we could get 5.1 out of main, I'd say go for it, but we can't) | 16:39 |
| infinity | slangasek: That sounds familiar. | 16:39 |
| infinity | slangasek: The comments on the function in the docs aren't kind either. :P | 16:39 |
| rbasak | Yeah, maybe better to break users on X+1 instead? | 16:43 |
| nacc | slangasek: ha! i think php-pecl-http was being built w/o curl support! :) | 16:44 |
| nacc | slangasek: the whole file that defines the failing constants is wrapped in an #ifdef :) | 16:44 |
| slangasek | well ok then | 16:44 |
| nacc | it should be comign from the core, though, not sure why it's not yet | 16:45 |
| nacc | but i think that's the root-cause, at least | 16:45 |
| cpaelzer | hi, is subscribing to a bug accounted as "activity" that avoids the expiration of incomplete bugs? | 16:46 |
| cjwatson | cpaelzer: I don't believe so | 16:50 |
| cjwatson | Doesn't change any fields of the bug | 16:50 |
| nacc | slangasek: yeah, i think that fixed it, will post a debdiff in a new bug | 16:58 |
| cpaelzer | cjwatson: thanks | 16:58 |
| nacc | slangasek: did you still want me to look into php-monolog? | 17:02 |
| slangasek | nacc: php-monolog uploaded, should be no need | 17:19 |
| kirkland | rbasak: I don't think I even know that that means | 17:20 |
| kirkland | rbasak: but, newer is better | 17:21 |
| rbasak | OK, that's fine by me. I think we just decided not to do it though as it's quite late to be making that change and it won't help drop the dependency from main. | 17:21 |
| nacc | slangasek: thanks! | 17:23 |
| nacc | slangasek: lol, i think i figured out the php-email-validator failure | 17:23 |
| nacc | between the previous run and the current, is it possible that example.co.uk became valid? :) | 17:23 |
| nacc | slangasek: changing it to example3.co.uk, e.g., all the tests pass as expected | 17:24 |
| slangasek | nacc: oh dear | 17:24 |
| nacc | slangasek: yeah | 17:24 |
| nacc | it's failing in debian too | 17:24 |
| nacc | we can ignore the failures safely, afaict, if you want -- it's tech. a false positive | 17:25 |
| nacc | and i'll notify upstream | 17:25 |
| slangasek | nacc: yeah, will mark it badtest, thanks | 17:25 |
| nacc | slangasek: i think that clears up the remaining excuses, i'll check | 17:25 |
| slangasek | nacc: btw, how did php-pecl-http regress? was it built against libcurl previously? | 17:31 |
| nacc | slangasek: that's a good question, it doesn't seem like it, but possible eitehr the the old php-pecl-http faked the namespace, rather than just not compiling it in | 17:33 |
| slangasek | nacc: doesn't look like it faked the namespace, fwiw | 17:36 |
| slangasek | so, more likely something changed to start depending on this interface | 17:37 |
| slangasek | (anyway, uploaded) | 17:37 |
| nacc | slangasek: yeah, i'm not seeing why in an obvious sense, tbh; i've pinged ondrej on it in case he knows | 17:38 |
| nacc | and so debian fixes it similarly | 17:38 |
| nacc | slangasek: fwiw, php-horde-http (which is the actual breakage here) isn't passing in wily either | 17:40 |
| nacc | and hasn't | 17:40 |
| slangasek | nacc: so at this point, we have 4 packages blocked by mysql (mythtv, netmrg, yate, zabbix); 3 packages that are going to be left broken for now (drupal7, libvirt-php, php-horde-mongo); 2 packages to be removed (php5, php-json); 3 false-positives due to alternate deps (cakephp, musica, pictor); php-radius, which is blocked by php-defaults which we're cleaning up; and 1 proposed-only package | 17:41 |
| slangasek | I think that's sufficiently manageable that I'm going to pull the trigger on removing php5 | 17:42 |
| nacc | slangasek: that sounds correct to me | 17:42 |
| nacc | slangasek: awesome! | 17:42 |
| jgrimm | \o/ | 17:44 |
| slangasek | nacc: oh, squirrelmail-decode Recommends: php5-recode | 17:45 |
| nacc | slangasek: i can send a debdiff in a moment | 17:46 |
| * xnox wishes we had more autopkgtest runners | 18:02 | |
| bdmurray | darkxst: re bug 1566141 - when was org.freedesktop.PowerManagement deprecated? We'd need to inhibit sleep on Trusty systems upgrading to Xenial. | 18:03 |
| ubottu | bug 1566141 in ubuntu-release-upgrader (Ubuntu) "sleep inhibitor uses deprecated interface" [High,New] https://launchpad.net/bugs/1566141 | 18:04 |
| gQuigs | thanks! | 20:31 |
| stgraber | TheMuso: hey there | 20:32 |
| stgraber | TheMuso: so that ubuntu-meta upload adds ubuntu-snappy-cli to a whole bunch of things, including a bunch of architectures which AFAIK are not supported by snappy (thought current snappy was just armhf and amd64) | 20:33 |
| slangasek | stgraber: ubuntu-snappy-cli is built for all archs, and snappy either has been or should soon be building for 4 archs AIUI (arm and x86, 32 and 64bit) | 20:38 |
| slangasek | and since the package exists, including it in the seeds allows for Future Expansion on the store side | 20:39 |
| slangasek | stgraber: also, not sure TheMuso was the one who changed the seed, as opposed to the lucky winner of the next ubuntu-meta upload following the change :) | 20:40 |
| slangasek | (Laney seeded it, mvo adjusted the seed) | 20:40 |
| stgraber | indeed looks that way | 20:45 |
| stgraber | ok, still seem like a giant waste of space on the architectures where this thing won't work at all, Go binaries aren't usually small :) | 20:45 |
| stgraber | 4.4MB compressed, that's not nearly as bad as I thought | 20:46 |
| slangasek | stgraber: let me run that question to people who might have an opinion; and yeah, I think these go binaries are actually getting stripped now | 20:46 |
| stgraber | slangasek: I already did ask in the secret e-mail thread | 20:47 |
| slangasek | mmk then | 20:47 |
| stgraber | I'll accept the upload for now, it does match the seeds and if we want to fix any of that we'll just change the seeds and do another meta package update | 20:47 |
| slangasek | yep, sounds good to me | 20:48 |
| slangasek | nacc: php-defaults, php-radius cleared now; php-horde-http still has autopkgtest failures, even with latest php-pecl-http | 20:50 |
| nacc | slangasek: hrm, let me look | 20:51 |
| doko | stgraber, any idea about http://autopkgtest.ubuntu.com/packages/g/golang-gopkg-lxc-go-lxc.v2/xenial/amd64/ ? | 20:51 |
| stgraber | doko: yeah, that thing is racy, just hit retry | 20:52 |
| stgraber | doko: I think it sends SIGPWR to the container before the container's init has set a signal handler, so the container never shuts down | 20:52 |
| slangasek | sounds like the definition of a force-badtest hint | 20:52 |
| stgraber | doko: (that's a testsuite problem) | 20:52 |
| doko | slangasek, how can I do these permanently? | 20:56 |
| slangasek | doko: a) you can't because that's owned by the release team; b) a 'badtest' hint applies permanently to any given version of a package, and a newer version of the package will be blocked in -proposed (and thus is not supposed to interfere with other packages) until the tests are fixed or the hint is updated | 20:57 |
| slangasek | doko: though I guess if the current practice is to retry the tests instead of fixing the race, that would cause the next version of the broken package to get into the release and make the hint out of date; the solution is for people to not do that ;P | 20:58 |
| TheMuso | slangasek, stgraber, no, I made a desktop seed change, and uploaded the meta. | 21:04 |
| TheMuso | Had nothign to do with me. :) | 21:04 |
| doko | rbasak, slangasek: it's only apache2 and nginx which *use* lua5.1. All other deps are from lua modules which are built for all lua versions. But then we would need to prove that no /usr/bin/lua5.1 shebang is used in main | 21:08 |
| Unit193 | ginggs: I am now. | 21:16 |
| ginggs | Unit193: Hi! LP: #1406825 has been fixed 5.34-2 in Debian, do you want to update your merge? I'm sure we don't want that "easter egg" in an LTS | 21:18 |
| ubottu | Launchpad bug 1406825 in xscreensaver (Ubuntu) "xscreensaver complains "This version of xscreensaver is VERY OLD!"" [Medium,Confirmed] https://launchpad.net/bugs/1406825 | 21:18 |
| Unit193 | Yeah, saw that one scroll past in Debian, wasn't going to push too hard on it because I needed some pull for other pending stuff too. :P | 21:20 |
| slangasek | doko: why would we need to prove this? You mean packages that use /usr/bin/lua5.1 as shebang don't have a dependency on lua5.1? | 21:20 |
| doko | no, I was arguing that we only had two real lua5.1 use cases, not more | 21:21 |
| rbasak | I'm a little confused. What are we discussing? I thought we couldn't pull lua 5.1 becuase of nginx anyway? | 21:21 |
| slangasek | that was my understanding | 21:22 |
| doko | yes, nginx is blocking, but I'm still missing the connection to apache2 | 21:22 |
| nacc | slangasek: i'm super-confused, i just ran against both proposed and release and the test passed in both, if I build the package or not | 21:23 |
| nacc | slangasek: so 4 PASS runs :) | 21:23 |
| === salem_ is now known as _salem | ||
| slangasek | doko: you said "it's only apache2 and nginx that use it". Changing apache2 leaves us with 1 revdep, not 0; so doesn't appear to be worth changing anything for 16.04 | 21:24 |
| doko | slangasek, anyway, filed a debian issue to change this | 21:27 |
| slangasek | doko: great | 21:27 |
| Unit193 | Bah, those hashsum mismatches.. | 21:41 |
| Unit193 | ginggs: dget https://sigma.unit193.net/source/xscreensaver_5.34-2ubuntu1.dsc with a buildlog: https://sigma.unit193.net/source/xscreensaver_5.34-2ubuntu1_i386.build | 22:01 |
| Unit193 | And a free debdiff too. | 22:03 |
| ginggs | Unit193: dgetting... | 22:03 |
| ginggs | Unit193: uploaded | 22:29 |
| GunnarHj | ScottK, yofel: Hi, pinging about https://code.launchpad.net/~gunnarhj/ubuntu-seeds/kubuntu.xenial_chinese-fonts/+merge/288192 | 22:45 |
| Unit193 | ginggs: Great! And thanks for poking. | 22:55 |
| ginggs | no worries, thanks for the merge! | 22:55 |
| === mnepton is now known as mneptok | ||
| darkxst | bdmurray, I don't know exactly, but a *long* time ago, possibly as long ago as GNOME 3.0 | 23:31 |
| darkxst | bdmurray, trusty supports logind inhibitors | 23:31 |
| bdmurray | darkxst: okay, I just wanted to make sure we took care of trusty too | 23:33 |
| darkxst | I tested it on trusty | 23:33 |
| bdmurray | darkxst: cool, I'll look at merging it soon then | 23:34 |
| darkxst | and the PowerManagement code wouldnt even work if the interface was still there, dbus session calls fail without extra hackery as you will see in my other bug | 23:35 |
| darkxst | bug 1565177 | 23:37 |
| ubottu | bug 1565177 in ubuntu-release-upgrader (Ubuntu) "screensaver is not disabled during release upgrade" [High,In progress] https://launchpad.net/bugs/1565177 | 23:37 |
| rbasak | Am I right in thinking that if I need a dh_autoreconf, I can replace an existing dh_autotools-dev_updateconfig. That is, that the former completely supersedes the latter if the former is necessary? | 23:45 |
| rbasak | Except that a dh_autoreconf fails. Lovely. A patch to configure it is. | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!