[01:20] infinity, ^ hopefully i did everything we have discussed =) [02:41] can someone reject the above accountsservice, patch was incomplete [02:43] infinity, ^ [02:44] darkxst: done [02:45] slangasek, thanks === agateau_ is now known as agateau === NCommander is now known as mcasadevall [08:32] the ceph upload ^^ I just made is the first RC for the Jewel stable release we're targetting for Xenial [08:33] its had some good testing in PPA prior to upload... [08:33] FFe bug is referenced in the changelog, but not closed... [09:16] pitti, are you ok with me leaving the FFe bug open for ceph? I'd rather close that with the final release upload rather than the RC's [09:16] jamespage: ah, sure [09:16] pitti, awesome [10:10] tjaalton: ^ seems the dep-wait resolved :) [10:15] could a releasy birtney hint the tests for spl-linux 0.6.5.6-0ubuntu1 on amd64 and ppc64el as "ok" as they have fallen foul of the kernel catching up with them before they could escape -proposed [10:17] apw: I'm reading that as "I'd love to fix the tests, Adam, just ask..." [10:21] i would love to fix them, and i will, indeed [10:30] pitti: whee :) [10:56] tjaalton, pitti: not yet: https://bugs.launchpad.net/ubuntu/+source/vdpau-video/+bug/1075783 https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1075780 [10:56] Launchpad bug 1075783 in vdpau-video (Ubuntu) "[MIR] vdpau-video" [Wishlist,Confirmed] [10:56] Launchpad bug 1075780 in intel-vaapi-driver (Ubuntu) "[MIR] intel-vaapi-driver" [Wishlist,Confirmed] [10:57] doko: yes, I'm asking for the new upload so it could be synced.. [10:57] oh [10:57] well [10:57] I thought you meant the Brekas [10:57] -ks [11:02] doko: I'm not sure if those need to go in main for mesa? [11:03] tjaalton, well, libva depends on those [11:03] oh [11:03] ah right [11:03] va-driver-all [11:04] sorry, overlooked this one :/ [11:04] tjaalton, I'm afk for a while. would be nice if you could look what to do [11:04] would s/Depends/Recommends/ fix it? [11:04] for now [11:04] tjaalton, iirc, not good enough, but I can't remember [11:05] ok [11:05] I'll have a look [11:22] doko: quick review done on both [12:10] cyphermox, Can you help with this please? [12:10] https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1565709 [12:10] Launchpad bug 1565709 in ubuntu-mate-meta (Ubuntu) "FFe: Please updated ubuntu-mate-meta to add ubuntu-snappy-cli" [Undecided,Confirmed] [12:10] I've got another ubuntu-mate-meta update coming to fix an a11y issue and the above will need processing first. [12:11] I feel like ubuntu-snappy-cli probably belongs in desktop-common, but we'd need all the flavours to agree that's sane. [12:12] flexiondotorg: FWIW, it's only a Recommends on ubuntu-desktop, and you made it a Depends for yours. Are you sure you want to be that strict? [12:12] infinity, Yes because I can't have Recommends in Ubuntu MATE just yet. [12:13] flexiondotorg: Oh, you still have follow-recommends off? Ick. [12:13] infinity, Yes, there are good reasons for this. [12:13] I tried unpicking it for 16.04, but ran out of time. [12:13] It is on the work sheet for 16.10. [12:13] * infinity nods. [12:13] Running the update. [12:14] I've been discussing the snappy stuff with willcooke. Ubuntu MATE are fully supporting the initiative. [12:14] Well, given the way some leaf packages might go, I suspect we could reach a point where flavours kinda won't have a choice unless they want to maintain their own web browser or whatever. [12:15] But that didn't seem to happen for 16.04, so I guess people are safe for now. [12:15] infinity, Thanks for processing the update. [12:16] infinity, are you still planning a glibc upload? want to do the cross-toolchain-base upload after that [12:16] doko: I'll be doing one or two more before release, I suspect, but I have no urgent reason to do one right now. [12:16] doko: Unless you know of an urgent reason. :P [12:17] ok, then delaying ctb [12:17] doko: Is ctb current right now? [12:17] somehow, ftbfs because of integrated patches [12:18] Oh, it's off by one revision. Close enough. We'll sort it for ubuntu3, which is definitely happening. [12:18] A few things in debian git I want to pick up, and a couple of small bugs to fix in the Ubuntu bits. [12:18] and there's still the britney issue, not allowing gcc-5-cross-ports to migrate [12:19] ... it doesn't even show up in excuses. [12:19] infinity, I see you're in the calendar to pilot today. [12:20] Was it causing britney to crash or something? [12:20] flexiondotorg: Yeah. [12:20] Have you had your stint yet? [12:20] flexiondotorg: The long discussion with darkxst in #-devel was sort of piloty, though I only just not signed in. :P [12:20] infinity, I don't know. if britney would crash, then we wouldn't see any migrations, I assume [12:21] * flexiondotorg goes to #-devel [12:22] doko: It doesn't seem to be lying about the Impossible dependency. [12:23] Or... Yes it is? [12:23] WAT. [12:23] infinity, yes but it doesn't list gcc-5-cross-ports as being ready for migration either [12:23] I'll look at this a bit latrer. [13:21] infinity: any chance I can add an nginx FFe review to your list of things for today? https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1566392 If not, i'll poke again later this week, but this should probably get in before FinalFreeze [13:22] Launchpad bug 1566392 in nginx (Ubuntu) "[FFe Needed] Update nginx to 1.9.14" [Wishlist,New] [13:25] teward: Changelog looks sane to me, go for it. [13:25] infinity: thank you kindly, upload will be done as soon as the apt-get upgrade that Landscape pushed to this system finishes heh [13:27] infinity: just finished the upload, thanks again! [13:33] teward: Oh, do me a favour. Once this builds, install the archive binaries, set up an SSL site, and double-check it seems to DTRT. [13:33] infinity: coffee hasn't been fully metabolized, DTRT = ? [13:33] teward: On the off chance that the "OpenSSL 1.1.0 compat" commit accidentally broke 1.0.0 compat (which we're using). [13:33] ah [13:33] teward: DTRT = Do/Does The Right Thing. [13:34] right, thanks [13:34] actually [13:34] * teward borrows one of his servers' site configs for testing [13:34] if it fails to work with an existing 1.8.1 copy, it's a major regression I report upstream heh [13:34] (the site is live, but i'll be spinning it somewhere not in production) [13:34] * teward has a fairly complexified SSL setup [13:35] Perfect. [13:35] From the diff, it looked like they were just switching from using deprecated OpenSSL 0.9.x symbols to using the new and shiny 1.x versions, but I don't track OpenSSL API/ABI well enough to recall when the new shiny was added. [13:36] infinity: right, though given what sarnold gleaned with regards to testing from upstream, and the fact they spin their own versions of the packages, I'm fairly certain they do some compatibility tests [13:36] at least, now that Chrome has fully dropped NPN HTTP/2 support, they have to thoroughly make sure existing ALPNs don't break [13:36] s/ALPNs/ALPN support in SSL libs/ [13:39] ^^ infinity,pitti - should fix autopkgtest for dbconfig-common 2.0.4 regression as currently blocking mysql-5.7 [13:39] the dbconfig-common upload. [13:39] at least it does for me locally. [13:39] I thought Skuggen and rbasak were working on that. [13:40] Oh, if it's just a missing test dep, oops. [13:41] I was, but have only just this moment reproduced the failure locally. [13:41] If that fixes it, it's fine by me. Thanks! [13:41] Ah, and it would make sense. MySQL 5.7 uses Perl for less things, so no longer pulls in libdbd-mysql-perl. [13:41] Huh. Is listing the same test twice with different deps actually a legal thing to do? [13:42] That feels super weird. [13:42] I can see why it would be useful. [13:42] (in this case) [13:42] rbasak, xnox: Can one of you make sure that gets forwarded to Debian? [13:43] infinity, no idea if it is legal, it does work =) [13:43] (e.g. totally tests one and then the other) [13:43] If it works, it's legal. [13:43] (Isn't that the way of software development?" [13:43] ) [13:43] I'm trying required upstreaming in bug 1566364 as there are quite a few now. [13:43] bug 1566364 in mysql-5.7 (Ubuntu) "Upstreaming tracking bug" [Undecided,Triaged] https://launchpad.net/bugs/1566364 [13:43] tracking [13:43] infinity, if only that was the USA immigration policy.... [13:44] Hah. [13:44] rbasak, have you looked into ruby-mysql? [13:45] xnox: https://bugs.launchpad.net/ubuntu/+source/ruby-mysql2/+bug/1566798 from Skuggen but that results an FTBFS locally still. [13:45] Launchpad bug 1566798 in ruby-mysql2 (Ubuntu) "Fails to build with mysql-5.7" [Undecided,New] [13:45] http://paste.ubuntu.com/15650523/ [13:46] rbasak, ack. well, it indicates the tests are broken in setup against 5.7 [13:46] not that 5.7 is borked, or ruby-mysql itself borked [13:46] Yeah I'm working on it. [13:47] * xnox looks at strongswan on s390x.... [13:48] Looks like I just failed to apply the second patch. [13:49] * rbasak doesn't really know much about non-unified diffs [13:54] Oh hang on. I've been looking at the ruby-mysql2 FTBFS. ruby-mysql dep8 failure is separate. [13:58] rbasak: ERROR 1698 (28000): Access denied for user 'root'@'localhost' (from the dep8 failure) <-- This is what the --insecure option to mysql_install_db should fix [14:01] Skuggen: it doesn't call mysql_install_db. It just depends on mysql-server (the test that is) [14:01] Skuggen: any suggestions? Can we use socket auth or something? [14:01] * rbasak isn't sure how that ever worked [14:02] http://paste.ubuntu.com/15651042/ is where the failure is [14:02] Possibly it worked due to MySQL ending up with an empty root password because the debconf prompt was skipped [14:02] Which is bad if that was it. [14:03] Where's the source for the dep8 tests? [14:04] In debian/tests [14:06] rbasak, https://launchpad.net/ubuntu/+source/ruby-mysql2/0.4.3-2ubuntu1 [14:07] That's an odd selection of arches to fail on. [14:07] Haven't seen that amd64 test failure before, and I've been testing it on amd64 [14:07] I think it's perhaps flaky [14:07] It worked for me locally on amd64. [14:07] I'll retry them. [14:08] Skuggen: are you looking at the ruby-mysql dep8 failure or shall I? [14:09] I'm lost, because none of the sources I find have a tests/ in debian/ [14:09] ruby stuff is "special". [14:09] There's some auto-dep8 magic. [14:09] pitti: How does that work? :P [14:09] So we're dealing with "special" magic? [14:09] Skuggen: it's right there in the ruby-mysql source. Are you using pull-lp-source? [14:10] Like, short-bus special. [14:10] Nothing special that I can see on this one. [14:10] rbasak: Ah, no. I just used apt-get source [14:10] It's failing in shell before it even dives into Ruby. [14:10] Oh, indeed, the ruby-mysql one isn't special. [14:10] Or, is special because it's not. [14:10] Or something. [14:10] pitti: unping. [14:10] apt-get source uses your own system's sources.list, which may not be the one you want. [14:10] Use pull-lp-source :) [14:12] Do you need to specify a version. I'm still not getting a d/tests [14:12] The amd64 retry for ruby-mysql2 worked so I'll do the others. [14:12] Skuggen: By default, you get the tip version. [14:12] Which is 2.9.1-1build6 [14:13] ruby-mysql, right? Not ruby-mysql2. [14:13] (base)adconrad@nosferatu:~/ruby-mysql-2.9.1$ ls -l debian/tests/ [14:13] total 8 [14:13] -rw-rw-r-- 1 adconrad adconrad 59 Oct 6 2014 control [14:13] -rwxrwxr-x 1 adconrad adconrad 117 Oct 6 2014 test-suite [14:13] Check "head debian/changelog" to see if you have the right tree. [14:14] Blargh. I downloaded ruby-mysql2 [14:14] Skuggen, infinity: right, for ruby-*, perl-* and a few others, run "autodep8" to get the control file that it uses (adt-run does that automatically); it's a way to run common tests for thousands of source packages without having to copy them a thousand times [14:16] :q [14:16] Whops [14:16] E37: No write since last change (add ! to override) 1,1 Top [14:17] But yeah, that looks like a "just happened to work before" test [14:18] rbasak: Mysql's own smoketest sets the root password, then reconfigures the server [14:18] Skuggen: ah, good point. We could just do that. [14:18] Could maybe do the same [14:19] Skuggen: good idea. I'll just copy in the bits. No need for you to do it as I'll only need to replicate locally again. [14:19] and edit test/test_mysql.rb to use it [14:20] Ah yes good point, thanks. [14:22] I wouldn't patch test/test_mysql.rb [14:22] I'd just write the password to /root/.my.cnf [14:22] The ruby file is also set to read some env variables, if they're available [14:22] Oh, assuming the ruby client cares at all about my.cnf [14:23] CONFIG.pass = ENV['MYSQL_PASS'] || '' [14:23] But yeah, whatever it can use, I'd do it externally instead of patching. [14:23] env it is. [14:25] Trying env now. [14:26] stgraber: Wat. [14:27] That's...possible? [14:27] rbasak: Which? The lxd thing? [14:28] infinity: hmm, looks like I uploaded the wrong thing :) [14:28] rbasak: unapproved happens before any sanity checks, so yes. It wouldn't accept if I were to try, mind you. [14:28] Same version in queue as in archive. [14:28] I see, OK [14:28] stgraber: Y'think? :) [14:29] infinity: is there typically a delay from it landing in proposed and being available to install from proposed? (Not showing up in apt-cache on Xenial, even when I added xenial-proposed) [14:29] teward: Yeah, it needs to do thinks like build some binaries and the stick them on some disks and then mirror them to the mirrors you actually see on the interwebs. [14:30] s/thinks/things/ [14:30] infinity: ubuntu6 coming up now :) The machine I did that stuff on happens to have broken network to upload.ubuntu.com so had to scp the bits to another box to upload, I misremembered how many times I bumped the packaging already and obviously didn't scp the .upload file so dput didn't tell me as much :) [14:30] infinity: including archive.ubuntu.com (main archive)? [14:30] looks built and published according to LP [14:30] teward: archive.ubuntu.com is a bunch of mirror frontends, it's not the real archive. [14:30] ah, ok [14:30] * teward will wait [14:30] teward: "published" according to LP is what happens when it starts stuffing it on ftpmaster's disk, there's still a delay from there to when you see it. [14:31] ahhhh, okay, i remember cjwatson saying something about that :) [14:31] guess i'll wait then [14:33] stgraber: If I were you, I'd count backward from 10.254 instead of using 10.0.$smallint, but that's just me. [14:33] stgraber: I'd think you're far more likely to conflict with humans and their existing setups using low values. [14:35] infinity: yeah, I could use something weird like 10.255.27.0/24 humans don't like 255 :) [14:35] infinity: feel free to reject and I'll do that [14:37] Well that's annoying dpkg-reconfigure needs root. So now the test needs root. [14:37] stgraber: Well, what's using that 10.0.4 subnet? That should likely change too. Or are those both you? [14:38] Ah, right, yes, the 5.7 smoketest is also tagged needs-root [14:38] stgraber: But, yes, human-ugly is the ideal, IMO, if you don't want people like me tearing my hair out about having to renumber my network to route to your automagic setup. [14:38] Well, either deciding between renumbering my network or preseeding yours. But both suck. [14:38] Though I don't really see a way around it. We've explicitly changed the packaging for 5.7 so you either need to set a password during installation or be root when you try to log in :) [14:39] rbasak: Is there no way to "su - $USER" in an autopkgtest test? So, you can needs-root, setup the DB, then drop privs and run a non-root test? [14:40] rbasak: That seems like what should be happening, if you have a variable to know what the test user is (or if the user is statically specced) [14:40] Well it's just a shell-script, so should be possible? [14:40] hello release team, is anyone available to take a look at https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1562406 and help the Kubuntu team out? [14:40] Launchpad bug 1562406 in muon (Ubuntu) "[FFe] Update to latest upstream version" [Undecided,Confirmed] [14:41] Skuggen: Oh, no, it's possible, obviously, what I meant was that it's awkward unless you know what $user is meant to be. :P [14:41] Is there a default user for dep8 tests? [14:41] That's sort of what I was asking. I assume there's either a default static user that's specced to exist, of an envvar that expands to a user that exists. [14:42] infinity: you can, and I had to do it for Juju. But it's not easy because $USER isn't known. [14:42] If neither is true, that sucks. [14:42] rbasak: Ugh. Really? Lame. [14:42] IIRC [14:42] infinity: what's currently using 10.0.4 is lxcbr0 which does have logic to find an unused subnet on the machine so that's fine [14:43] infinity: now lxdbr0 only suggests a subnet but it turns out people use our suggestions without thinking about it (despite them having to type it in :)) [14:43] Skuggen: got a problem now. Running as root for now, http://paste.ubuntu.com/15651925/ [14:43] Skuggen: need a bit of your MySQL knowledge I think please. [14:44] stgraber: Oh! I didn't notice those were literally all doc strings, not any template defaults. [14:44] stgraber: In that case, I'd stick with the "pretty" versions. If I'm so stupid I don't know that I'm using that IP, I suck. [14:44] stgraber: My internal parser just assumed you were defaulting to those values. [14:45] infinity: http://paste.ubuntu.com/15651969/ is what I had to do for Juju [14:45] rbasak: Looks a bit like tinyint has changed. [14:45] infinity: haha, no, no default for lxdbr0, that's the whole idea behind the thing, no random picking of subnets because we'll always fail at that somehow (especially when we're installed by default in all cloud instances) :) [14:45] infinity: okay, so then tha upload should be good to go [14:46] It's -128-127 or 0-255, so -255 looks like the culprit [14:46] Hm, according to docs it was the same for 5.6 [14:58] rbasak: For the various integer tests I don't see them having worked before either. Datetime makes more sense, since 5.7 defaults to not allowing 0-dates [14:59] infinity: confirmed: SSL works [15:00] running one slightly more stringent test first though [15:03] Skuggen: looks like the test needs significant alterations [15:06] Doesn't look like big changes for each test, but I don't really understand what they're trying to test [15:07] Skuggen: http://paste.ubuntu.com/15652507/ is what I have to fix the test run and root password [15:07] By the way, mysql-workbench-6.3.6+dfsg looks ready to go from the ppa [15:07] Just need to add test fixes to that. [15:09] I'll go through and try to get them sorted out. Might need to get som people to help me here, but everyone's gone home :) [15:11] infinity, so gnupg2.1 went in without fixing critical bugs in gpg-agent [15:11] and breaking mine and Laney's desktops?! [15:11] not good [15:11] infinity: my thorough test (including HTTP/2) shows that it's working even with my complicated SSL cipher strings. So it looks like nginx did not break 1.0.0 compat. [15:11] (for openssl) [15:12] xnox: Should something have stopped that (did someone override some tests or force something?) [15:12] xnox: Or are you just complaining to me to have someone to complain to? :) [15:12] teward: Excellent, thanks. [15:12] you're welcome. [15:12] Skuggen: I created https://bugs.launchpad.net/ubuntu/+source/ruby-mysql/+bug/1566917 to track, thanks. [15:12] Launchpad bug 1566917 in ruby-mysql (Ubuntu) "dep8 test failures" [Undecided,Triaged] [15:13] infinity, Laney and I discussed it and it's RC buggy in debian which totally affects us too. [15:14] infinity: the Feature Freeze should have stopped it, but did not [15:14] infinity, gnupg now uses $GNUPG_HOME for sockets, instead of $TMP. In practice it should use $XDG_RUNTIME_DIR/gpg/$escaped-path-to-GNUPGHOME as otherwise bind-mounting /home, nfs /home, read-only /home cannot use gpg at all [15:14] slangasek: Right, won't argue that, but I'm pretty sure I didn't approve it. Did I? [15:14] and e.g. ssh enabled gpg [15:15] * infinity now wonders if he did. [15:15] rbasak: Did you have a chance to look at the dbconfig-common failure? It's giving a dependency error on libdbd-mysql-perl [15:15] infinity: nope [15:15] Skuggen: xnox fixed it [15:15] Ooh, great [15:15] infinity: but you asked "should something have stopped that" and I'm letting you know what ;) [15:15] infinity: as for whether xnox is complaining to you just to have someone to complain to, well [15:15] superm1, did you know that gpg-agent 2.1 is RC buggy in both debian and ubuntu and breaks the world? =) [15:15] Skuggen: we dropped the libdbd-mysql-perl dependency so it needed adding as a test dependency (assuming it depended on it undeclared). The dep8 test run hasn't finished yet htough. [15:17] xnox: if it's absolutely something that can't be fixed, we can pull it back [15:17] but do you have some bugs filed? [15:18] looking [15:18] it used to be RC in debian [15:18] e.g. upstart session job is broken for those that enable ssh support, so that needs fixing [15:18] GPG_AGENT_INFO is no longer exported so e.g. debsign things there is no gpg-agent available. [15:19] what do you mean it used to be RC in debian? [15:19] we need [15:19] * updated /etc/X11/Xsession.d/90gpg-agent to export $GPG_AGENT_INFO [15:19] about the standard socket. [15:20] but updated for user session upstart [15:20] ditto [15:20] * update gnupg-agent.xsession to export ssh-agent where [15:20] configured. (Closes: #767341) [15:23] superm1, yeah the bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796931#77 and we are missing implementation on the desktop for all of that which we know absolutely must include. [15:23] Debian bug 796931 in gnupg-agent "gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file" [Normal,Open] [15:23] let me sync that into launchpad [15:24] ok thanks [15:24] xnox: I use gpg-agent with ssh and etc., lemme know if I can help testing with my weird setup [15:24] cyphermox, cool =) [15:24] cyphermox, for now i expect it to be broken =) [15:24] xnox: just as a random point, reverting the socket behavior will cause scute to FTBFS again as its testsuite relies on the gnupg2.1 behavior [15:25] xnox: for now, it works for me, but I also always had to script around it to start it just the way I want it to be :/ [15:25] superm1: anyway, all the above is why I said this shouldn't have gone in without an FFe review [15:25] well it should still be a standard socket, but it sounds to me the variable needs to point to the socket [15:26] slangasek: understood, and i agree. it would have been nicer to catch these things at that time. [15:28] cyphermox, well i got upstart user session jobs to the point that it looks at the $GNUPGHOME config files and does the right thing [15:28] xnox: ok [15:28] unreleased code? [15:28] and e.g. it can totally disable gnome-keyring (via startup programs) and the upstart job is sensitive to that and can do everything right [15:28] nice. [15:28] cyphermox, well it was all working until this 2.1 release landed =) [15:29] oh, then it wasn't working for me ;) [15:29] cyphermox, basically google use the same weird yubikey-sshkeys setup i do =) [15:29] right, so do I [15:29] and i fixed it for me. [15:29] ... [15:29] slangasek: ping, I wanted to make sure to reach out. The team's gotten all changes we talked about last week done and in the queue. Is there anything from here that I need to make sure my folks get done? [15:30] rick_h_: hi, I saw the new uploads land in the queue, thanks very much - it's now waiting on me or another release team member to circle back around for review, I will try to get to that this afternoon [15:31] slangasek: <3 ty much. let me know if there's anything we can do. [15:32] superm1, infinity - gnupg bug tracker is at https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/1566928 i shall fix things up, cause i doubt we have any other upstart-usersession-xsession-integration people =) or those willing to fix and test that with an ssh-gnupg-smartcard [15:32] Launchpad bug 1566928 in gnupg2 (Ubuntu Xenial) "gnupg-agent: no longer writes $GNUPGHOME/gpg-agent-info-$(hostname) file" [Critical,Triaged] [15:32] xnox: yes if you've got the cycle to do so, please do [15:33] xnox: If you have a handle on what needs fixing and slangasek doesn't tell you "no", please fix. [15:34] yeah i will [15:34] xnox: If Steve does tell you to keep your hands off, document the bug(s) well enough that we can spread the blame around? :) [15:34] once i get s390x back into installable state [15:34] infinity, i dunno =) we can't really blame superm1 - his people did renew and all that =) [15:35] and you know, superm1 is nice =) [15:35] xnox: That's never stopped me from blaming him. [15:35] hahahahah [15:35] haha [15:38] xnox: like I said, ping if you need a second pair of eyes to test your fix ;) [15:58] Almost all the ruby-mysql tests that fail are just testing that the server isn't running in strict mode (which became a default in 5.7) [16:00] Would it be easier to modify the test so it switches the server out of strict mode for now? [16:00] Then it'd be testing the same thing. [16:00] Given that we're not testing what mode the server is in in the ruby-mysql tests. [16:00] Yeah, I did that and was left with 1 error and 2 failures, and the error is simple [16:01] Well, I just set sql_mode='' to test, so might be more than just strict mode [16:01] I'm open to feedback but I think it's be acceptable this way. I'd object more if they were tests inside mysql or something, but ruby-mysql's tests can require whatever mode they want as far as I'm concerned. [16:02] Given that the server can only be in one mode at once and that'll be a function of the eventual deployment under a sysadmin's control. [16:02] Yeah, it's testing the server configuration, not ruby-mysql or mysql itself [16:02] It doesn't even depend on the server. [16:02] So can't be a function of the package to assume a particular mode. [16:07] rbasak: If you add a «set global sql_mode='NO_ENGINE_SUBSTITUTION';» to the call that creates the test database, you should get the 5.6 default mode [16:22] When does distro-image change to claim xenial as the latest lts? [16:22] is that "once we throw the release switch", or? (what triggers that change) [16:23] The date which is (hopefully) already defined [16:26] lamont: distro-info, you mean? [16:26] there is a desire for a --lts variant that includes an lts under development (as in, it would have started claiming xenial 5+ months ago..) [16:26] infinity: yeah,.. I suck at typing [16:26] lamont: /usr/share/distro-info/ubuntu.csv [16:27] so the csv already knows that xenial is --lts-including-devel, distro-info just needs to learn a new flag... [16:27] lamont: Patches welcome if you want --devel and --lts to work together. [16:27] or to allow --lts --devel [16:27] yeah [16:37] rbasak: Setting the above sql mode and applying this patch should fix it: http://paste.ubuntu.com/15655187/ [16:38] Though I manually ran the tests, since my autopkgtest is borked [16:39] Skuggen: thanks, I'll try it now. [16:39] xnox,infinity: FYI I'm doing that static analysis of build-deps in main that we talked about [16:40] It's not terribly quick but after a bit of work I have something that will spit out resolutions of everything in main for amd64 and i386 before the heat death of the universe [16:40] (Might do the rest later but this is a good start) [16:42] cjwatson, cool! [16:44] python-apt turns out to be fast enough with a bit of care [16:47] infinity: http://paste.ubuntu.com/15655520/ <-- thoughts? still needs a test case or 2, but... [16:48] bah. line 19 += unlikely() [16:49] * rbasak is surprised that distro-info-data needs to be so heavily optimised so as to use likely/unlikely. [16:49] rbasak: /me is just going with what it has everywhere else [16:49] Fair enough! [16:49] but yeah, I suspect it's ignoring the fact that 90% of the run time is startup/exit processing [17:05] infinity: http://paste.ubuntu.com/15656045/ If you are +1, I'll upload 0.14ubuntu1 [17:06] though, tbf, I suppose we should document that --lts and --devel can be used in conjunction, eh? [17:12] bareos vs mysql -> Unable to load any shared library for libbareoscats-mysql.so [17:12] on s390x [17:17] infinity: uploaded it to my ppa, with high hopes that you'll kick it around [17:18] also, I'd just like to say that I'm a fan of unit tests [20:20] doko: do you have a FFe for that vim upload? [20:32] stgraber, I filed https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1566579 [20:32] Launchpad bug 1566579 in vim (Ubuntu) "FFe: merge with the current Debian package" [Undecided,New] [20:35] doko: commented with questions [20:36] stgraber, ugh, launchpad can't expand long comments anymore? [20:37] seriously, I have to *download* this comment? [20:37] hmm, that's special, I thought there used to be a link to see the whole thing [20:40] doko, technically, if it's in the internet and you get a local copy to see it, you are downloading it any way :P [20:40] * knome hides [20:41] stgraber, commented. I won't fight for it [20:51] coreycb: can you give me a changelog for python-concurrent.futures? [20:51] coreycb: the Debian changelog doesn't have one and I can't easily find one upstream [20:51] (you're bumping us from 3.0.3 to 3.0.5 so I'd like to confirm that this is bugfix only) [20:52] stgraber, it's part of the openstack FFE [20:52] stgraber, upstream final release is this week so we should go quiet after this week [20:53] coreycb: link to the FFe please [20:54] stgraber, there's no bug, but there's this: https://lists.ubuntu.com/archives/ubuntu-release/2016-February/003572.html [20:54] coreycb: where can I see that this package is part of upstream openstack? [20:54] stgraber, https://github.com/openstack/requirements/blob/stable/mitaka/upper-constraints.txt [20:54] I've approved the others because they clearly are, but this one I didn't find in any openstack repo [20:55] stgraber, it's a dependency [20:55] ok, right, then get an FFe please [20:55] your exception is for OpenStack and its components itself, not for its dependencies [20:55] stgraber, I don't think so, I think it's for deps no? [20:55] otherwise you could upload a new qemu, linux, python3, libc, ... using the same reasoning [20:56] stgraber, this would get really difficult if we had to open a bug for everything [20:57] well, you don't need FFes for things that are specific to openstack and you don't need FFes for packages which are bugfix only [20:57] but you sure do for the rest [20:58] stgraber, looking at the email I linked above it includes direct dependencies for openstack [20:59] stgraber, openstack re-releases every new bit of the python3 std library [20:59] yes, it's wrong [21:00] coreycb: "and direct dependencies managed under the OpenStack umbrella", from what you're telling me, this dependency is from outside of openstack so not "under the OpenStack umbrella" [21:00] stgraber, I suppose there's a bit of a gray area but it's a direct dependency of openstack as noted in this: https://github.com/openstack/requirements/blob/stable/mitaka/upper-constraints.txt [21:00]