[00:04] hm, running do-release-upgrade under a screen i created worked fine [00:36] hm the next question is how do i do lts to lts testing of a package change i want to make? [01:01] mwhudson: bypass do-release-upgrade and just use apt-get dist-upgrade [01:01] oh ok [01:01] nacc: so your rebuild.3 list includes php-hamcrest, which I know I just did a non-no-change upload of... [01:01] that's not supported but actually works in practice? [01:04] mwhudson: depends on the lts-to-lts in question, sometimes, as was the case with multiarch, the source apt isn't capable of understanding some package relationships in the target series, in which case the upgrade will blow up [01:04] mwhudson: that's why we don't support dist-upgrade officially [01:04] ok [01:04] mwhudson: do-release-upgrade downloads an upgrader tarball which contains the apt and dpkg of the target series [01:04] that shouldn't be a problem trusty->xenial? [01:05] yeah, I'm not aware of any big archive change which would be a problem [01:05] however if you do find an apt bug, then you'll be stuck :) === chuck_ is now known as zu === zu is now known as zul [01:32] oh no i might break a container! [01:32] this happened to an upgrade again: http://paste.ubuntu.com/15548112/ [01:32] is there some idle timeout somewhere? [01:33] could be logind or something killing your session [01:34] no details of any sort printed? how annoying [01:36] i also get this when i log back in: http://paste.ubuntu.com/15548150/ [01:36] should i file a bug for this? [01:36] (and if so, which project?) [01:38] mwhudson: there's not enough to know there, you'd want to look at /var/log/dist-upgrade if it mentions anything to clue you in which package has an issue, otherwise it might be ubuntu-release-upgrader [01:39] the ssh session seems to die too early to be because of stuff being upgraded, though [01:40] there's nothing much odd looking in /var/log/dist-upgrade [01:51] slangasek: argh, sorry! just forgot to update the list [01:51] slangasek: that's the only one that should be cross-listed === juliank is now known as Guest77434 === juliank_ is now known as juliank [02:22] well that odd session killing behaviour doesn't happen when you just run dist-upgrade [02:22] so i guess that's a ubuntu-release-upgrader bug [02:25] err, we don't do stuff to the session in u-r-u [02:25] or at least, not that I can think of would make sense, or that I've noticed in the code so far [02:25] I also already did an upgrade successfully not that long ago, a few days maybe [02:28] hmm [02:28] it could also point to a problem in lxd i guess? [02:29] cyphermox: did you do your upgrade in lxd or a real system? [02:29] file a bug against ubuntu-release-upgrader, and make sure the logs are included (whatever is in /var/lib/dist-upgrade, as well as the apt-clone tarball if possible) [02:29] it was a VM, but not lxd [02:30] I may be wrong about the upgrade being successful. that would be a good data point for the desktop upgrade issues too [02:30] ah i've killed the lxd [02:31] will reproduce in a moment [02:41] * mwhudson gets ready to use his new superpowers for the first time [02:41] * sarnold stands back [02:43] no regular expressions are involved [03:13] filed https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1563168 fwiw [03:13] Launchpad bug 1563168 in ubuntu-release-upgrader (Ubuntu) "14.04 -> 16.04 upgrade in lxd container dies most of the way through" [Undecided,New] [06:25] good morning [06:43] good morning [07:06] my first upload to ubuntu appears to have migrated fine without exploding the universe, i guess that's good :) [07:06] mwhudson: Alternately, whatever you screwed up is something our infrastructure doesn't catch. ;) [07:06] infinity: yeah, probably [07:07] haha [07:08] i was thinking of making some joke along the lines of "given that there is a lxd upload every 10 minutes or so we'll find out soon" [07:08] and it turns out that lxd was published in -proposed *3 minutes ago* [07:09] :) [07:10] mwhudson: If lxd is your testcase, I'm assuming the implication is that you've finished the go-default migration and all should be good? [07:10] lxd built everywhere, so that's a good sign. [07:11] infinity: yeah, that's all done, it was just some tweaking today [07:11] and a new patch from IBM [07:12] mwhudson: Well, congrats on getting your upload on. Sorry I wasn't there to give another +1, but clearly I wasn't needed. :P [07:12] thanks! [07:59] jamespage: that dpdk upload of last wednesday still doesn't show up but also isn't in update_excuses [08:00] cpaelzer: It's sitting in the unapproved queue, awaiting review. [08:00] (long weekends hurt) [08:00] infinity: oh thanks, at least I found it now [08:01] infinity: is there anything I can do to help? [08:01] Other than "not upload 26k diffs"? [08:02] infinity: yeah other than packaging bleeding edge stuff that feels like it could take 25k patches every day :-/ [08:02] just trying to get things stable and working til release [08:02] Understood. If no one beats me to it tonight, I'll review it in the morning. [08:03] infinity: thanks, and double thanks for identifying where it currently resides [08:26] infinity, lovely, but what is that? [08:27] xnox: systemctl status [08:28] hahahahaha [08:30] Failed to initialize libzfs [08:30] fun === marcusto_ is now known as marcustomlinson [09:14] jdstrand: Yep, thanks, will sort out ASAP. Feeling very stupid about that one, I swear I tested but obviously not quite the final thing I uploaded. I'll also add a syntax check to the build process so that sort of thing can't happen again. [09:28] slangasek ping === hikiko is now known as hikiko|ln [10:45] ok I managed to find out that new glibc is the cause for bug #1560528. so I'll leave the bug to be against glibc while commenting out the test on 32-bit archs in order to get forward with new Qt upload. [10:45] bug 1560528 in qtbase-opensource-src (Ubuntu) "tst_LargeFile::mapOffsetOverflow started failing on 32-bit xenial" [Undecided,Incomplete] https://launchpad.net/bugs/1560528 === hikiko|ln is now known as hikiko [12:06] smoser, pingaling ... seems cloud-init messes up a lot more on snappy (like creating a duplicated /e/n/i config now) [12:07] (snappy creates that itself on first boot from snappy config) [12:15] smoser, bug 1563296 for you [12:15] bug 1563296 in cloud-init (Ubuntu) "cloud-init 0.7.7~bzr1189-0ubuntu1 adds duplicated network config in /etc/network/interfaces.d/ in snappy leaving the boot completely network-less " [Undecided,New] https://launchpad.net/bugs/1563296 [12:22] tumbleweed, are you asking for a FFe for pypy 5.0? === inaddy_ is now known as inaddy [13:47] cyphermox: hello [13:47] cyphermox: I commented on your tpm2-tools bug, https://bugs.launchpad.net/ubuntu/+bug/1561834/ [13:47] Launchpad bug 1561834 in Ubuntu "[FFE] [needs-packaging] tpm2-tss and tpm2-tools" [Wishlist,Confirmed] [13:48] cyphermox: I've started to use the TSS tpmtest tool [13:49] cyphermox: you also could consider adding it to one of the existing binaries [13:50] cyphermox: it's not super verbose about the errors when it fails but it can certainly help developers/testers [13:51] ok [13:53] cyphermox: I looked at it this morning and upstream commits quite often to this tool, so I guess it's useful at least for them :) [13:53] cyphermox: sorry to jump quite late in the review though [13:54] hi folks, can anybody please retry https://launchpad.net/ubuntu/+source/libvirt/1.3.1-1ubuntu8/+build/9336238 https://launchpad.net/ubuntu/+source/libvirt/1.3.1-1ubuntu8/+build/9336239 https://launchpad.net/ubuntu/+source/libvirt/1.3.1-1ubuntu8/+build/9336243 [13:55] they should build now and make libvirt migrate [13:56] @core-devs ^^ [13:56] Error: "core-devs" is not a valid command. [13:57] LocutusOfBorg: ok, will do [13:58] thanks [14:00] how is it possible? [14:00] damn [14:00] universe-main? [14:04] thanks, but LP: 1532198 needs to be sorted out before [14:04] Launchpad bug 1532198 in zfs-linux (Ubuntu) "[MIR] zfs-linux" [High,Incomplete] https://launchpad.net/bugs/1532198 [14:06] martinst-: hi === kickinz1|eod is now known as kickinz1 [14:24] Anyone here familiar with dbconfig-common? I've been looking into LP: 1563274, but I can't find a simple solution [14:24] Launchpad bug 1563274 in mysql-5.7 (Ubuntu) "dbconfig-mysql sets blank port in config" [Undecided,New] https://launchpad.net/bugs/1563274 [14:36] infinity, did you get the time to dig into lp: 1562480? [14:36] Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [Undecided,New] https://launchpad.net/bugs/1562480 [14:37] I'm trying to read the code, but without real hw is impossible I think [15:05] Laney: hey === shuduo-afk is now known as shuduo [16:07] slangasek, stgraber, kees, mdeslaur: Tee Bee? [16:07] infinity: ah! yes === marcusto_ is now known as marcustomlinson === kickinz1 is now known as kickinz1|eod === Spads_ is now known as Spads === ubott2 is now known as ubottu === mfisch is now known as Guest28049 === adam_g` is now known as adam_g === FourDollars_ is now known as FourDollars === attente_ is now known as attente === tlyu_ is now known as tlyu === lfaraone_ is now known as lfaraone === Pici` is now known as Pici [17:23] can someone please confirm ? i'm [17:25] in xenial, nothing from udev will write /etc/udev/rules.d/70-persistent-net.rules [17:26] previously it would get written with a header like: [17:26] # This file was automatically generated by the /lib/udev/write_net_rules [17:26] # program, run by the persistent-net-generator.rules rules file. [17:26] but '/lib/udev/write_net_rules' is gone now. as is 'persistent-net-generator.rules' [17:37] jdstrand: do my debmirror fixes supersede RT#89946, or is that an independent problem? [17:37] let me check. I think it is a different problem [17:40] smoser: pit ti sent this around a while ago https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html [17:41] smoser: I'm not sure it was 100% done, but it looks like ifnames uses /lib/udev/rules.d/80-net-setup-link.rules instead [17:41] cjwatson: rt is still an issue [17:42] sarnold, thank you [17:51] doko: do you want me to? :) [17:51] I've spent the last two weeks fighting with it [17:53] doko: do you have access to a big endian porterbox with lots of RAM? I want to find if a patchset I'm proposing makes a significant difference on big endian. And it'll take me another couple of days on debian's porterboxes [17:56] nacc: so, I've got a port of libvirt-php that is *supposed* to work on php7, which I'm getting some folks at my workplace to help complete so that I can submit it back upstream [17:57] nacc: it's available here in the php7 branch: https://gitlab.com/Conan_Kudo/libvirt-php7 [17:58] nacc: do you know what the latest date it can be, before we'd have to make a decision on dropping a package? [17:58] because I'm trying to get the timelines worked out so that I can get everything done and submitted upstream in time [18:00] Pharaoh_Atem: depending on the importance, we might be able to leave it as uninstallable [18:00] Pharaoh_Atem: it's good, in some sense, that it's in universe [18:01] because there's not much in the way of guarantees there? [18:03] well, if it was in main, that wouldn't be an option [18:03] there's always kicking it out of main, too :) [18:03] Pharaoh_Atem: what's your tentative eta? [18:04] nacc: I'm trying to pull together the finishing work within the next week or two, and try to get it reviewed and upstream a week afterward [18:04] I'd like to pull the timelines in more, but it's getting really hard to get resources [18:05] from what Remi said, the current tree should be buildable, but I have no idea how well it works because the test coverage is abysmal [18:07] Pharaoh_Atem: yeah so that'd be outside of getting into 16.04 if it's not available upstream yet, but let's sync up again tmrw (i'm trying to get as much of the list that can be done completed) [18:07] okay [18:08] nacc: do you know what the cutoff date would be to get it into 16.04? [18:08] I can try to get things prioritized to make it in, or at least provide a squashed patchset to apply while it sits in review [18:12] https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule [18:12] so would the April 14th date be the correct one? [18:13] ls [18:13] >_> [18:14] final freeze implies bugfixes only, so really it should be sooner than that, afaqict [18:14] but since it's in universe ... [18:14] and it's not seeded, is it? [18:15] how would I know if it's seeded? [18:15] it's not [18:15] `seeded-in-ubuntu libvirt-php` [18:15] ah [18:15] yeah, it's not [18:33] Skuggen: /me received the bug about dbconfig-common, thanks [18:34] I will need to think about it [18:34] and indeed, probably not a trivial solution === juliank_ is now known as juliank [18:42] nacc: somewhat curious why all of these php-horde packages that are being changed now only to adjust test deps didn't show up as regressions when stuff was migrating earlier [18:42] nacc: e.g. maybe things that only have test deps on php5 should be left to the end? [18:42] or I guess these also have runtime deps for which they need no-change rebuilds, hmm [18:43] slangasek: right, they really need no-change rebuilds, but then their test will forcibly use php5 [18:43] gotcha [18:43] (afaict) [18:43] nacc: sorry, ignore my vain attempt to reduce the number of uploads I'll be sponsoring today ;) [18:44] slangasek: :) yeah it's a bit ugly; i'm going to go and try to clean up excuses again now and respond to the bugs from over the weekend [18:44] Skuggen: do you know if /etc/mysql/debian.cnf is already fixed in mysql-server-5.7? Because dbconfig-common takes its defaults from there... [18:45] Hang on, let me take a look at it. [18:45] Skuggen: ignore my last comment [18:45] 25 [18:46] slangasek: fyi, the php-pear failures (only on amd64) might be transient autopkgtest issues? [18:46] elbrus: Ah :D [18:46] slangasek: can you check and possibly resubmit those? [18:46] If you want to look at it, though, it's here: https://anonscm.debian.org/cgit/pkg-mysql/mysql-5.7.git/tree/debian/mysql-server-5.7.postinst#n160 [18:46] nacc: let me get through this sponsorship queue first and I'll look [18:47] slangasek: sounds good, thanks [18:47] Skuggen: so indeed debian-sys-maint logs in via the socket so doesn't have this issue [18:47] elbrus: We did actually find a bug in the 5.7 postinst when investigating the dbconfig issue; The debian-sys-maint user doesn't have access to grant other users access, which will cause installation of redmine/phpmyadmin to fail if mysql-server-5.7 is already installed [18:47] Yeah, it shouldn't be affected by this issue [18:48] Skuggen: you are coordinating/working as Debian mysql team as well, right? [18:48] Yeah [18:48] * elbrus is more a Debian guy than an Ubuntu guy [18:48] neat, did not know syncpackage had a -V option [18:49] slangasek: ah that's handy! [18:49] nacc: especially since php-horde-mapi 1.0.8-1 is now available [18:49] slangasek: syncpackage has a -V option. [18:49] The packaging I linked to is actually primarily for Debian, but we just apply a couple of changes for Ubuntu, like removing the libmecab-dev build-dep [18:49] i was just looking for that and had given up for php-horde-mapi bug [18:49] Skuggen: mariadb-server is/was setting the password to the empty string.. is that also going to fail? [18:49] slangasek: yeah, i should see if i can patch requestsync to take one too :) [18:50] infinity: that's super neat! now tell me something I don't know [18:50] elbrus: Both mariadb and mysql have changed to set root access through unix socket only if the password supplied is empty [18:50] Er, nevermind, that only affects the root user during installation of the server [18:50] But no, string options can be blank [18:51] Skuggen: and dbconfig-common during any database operation [18:51] slangasek: Emus can sprint at 30mph. [18:51] because that runs as root [18:51] infinity: actual thought process: "darn, there's a newer version of php-horde-mapi that invalidates this sync request. But wait, a sync is just an LP API call, and LP has imported the older versions too... I wonder if there's an option..." [18:51] and takes the password from /etc/mysql/debian.cnf [18:52] elbrus: Ah, right, so if dbconfig installs the server it will set an empty root password? [18:52] (as agreed with Otto Kel...) [18:52] slangasek: But yes, syncpackage is just (yet another) wrapper around copy-package, so if it didn't take a -V, it would have been trivial to add one. [18:52] Skuggen: eh... dbconfig doesn't install the server [18:53] slangasek: I feel like half our tools are friendly wrappers around copyPackage(), which doesn't say much for the friendliness of copy-package(1) itself. :P [18:53] elbrus: I'm a bit confused. Does dbconfig use the root user or debian-sys-maint (which is the one in debian.cnf)? [18:53] it just uses the credentials in /etc/mysql/debian.cnf to log into the local server to create the database and users [18:53] infinity: syncpackage does a copy-package plus other things (bug closures) [18:53] elbrus: Then it's using debian-sys-maint, and that's fine [18:53] Skuggen: debian-sys-maint if the server is mysql-server and root if it is mariadb server [18:54] slangasek: Fair. Other wrappers are also a bit more interesting (like sru-release). [18:54] dbconfig just takes it from /etc/mysql/debian.cnf, so I don't care what is there [18:54] I'm not 100% sure about mariadb, but that should be fine for mysql [18:54] slangasek: Of course, then there's copy-proposed-kernel, which other than filtering *-signed, is pretty much JUST a wrapper so we don't have to remember copy-package args. [18:54] slangasek: But whatever works. :P [18:54] I talked to the maintainer of mariadb at FOSDEM and we agreed that this was the best [18:55] the autopkgtests of dbconfig-common also test both mariadb and mysql [18:55] elbrus: Yeah, using debian.cnf will work fine. Mysql still uses that in the same way in the maintenance scripts. Only difference in 5.7 is that we removed a deprecated option from it (basedir) [18:55] do you know why the previous test used mysql-server-5.7 and the latest test mysql-server-5.6? [18:55] Which latest test? [18:56] autopkgtest of dbconfig-common [18:56] elbrus: If mysql-5.7 is still in -proposed (I assume it is), the default is to test against the release pocket. [18:56] nacc: I beat you to php-horde-kolab-storage already (it was blocking migrations over the weekend) [18:56] that is how I already knew that it was broken, but the latest test appeared to be fixed [18:56] slangasek: ah ok, thanks! [18:56] infinity: but it tests once against proposed to check? [18:57] elbrus: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-5.7 is what I've been looking at [18:57] nacc: I've noticed a few times that your patches are out-of-date wrt the archive; are you using pull-lp-source to make sure you always get the latest version when you start working? Or is it just a delay between when you grab the package and when you submit the bug? [18:57] Uploading of 5.7 to proposed would trigger it to test against it [18:57] elbrus: When a dep is uploaded, we test rdeps against it, and that's what we record as the current state for that pair of packages. [18:57] Skuggen: than I am sooooo glad that I have those tests... I would have been a pain if we discovered afterwards [18:58] elbrus: So, what you're seeing in http://autopkgtest.ubuntu.com/packages/d/dbconfig-common/xenial/amd64/ is, essentially, a statement that "updating ucf doesn't break dbconfig-common, but updating mysql does". [18:58] elbrus: Same here. For instance I know this will also break phpmyadmin, but that didn't show up there :) [18:58] slangasek: i think it's just the latter, i'll try to be more diligent about checking that going forward [18:58] that is because phpmyadmin uses dbconfig-common [18:58] or something else? [18:59] It can also use mysql as a backend, in which case it'll break with the same blank port option error [18:59] elbrus: So, the outcome of that is that we'd let ucf migrate, but we won't let mysql migrate until both mysql and dbconfig-common get along. [18:59] elbrus: If that makes sense? [18:59] sure [19:00] so that puts presure on the solution as I expect that Ubuntu 16.04 wants to ship with 5.7 [19:00] Indeed, that's the goal, though time is certainly running out on realizing it. [19:00] elbrus: There is a potential stop-gap solution we could do on the mysql end if this is too big a task [19:00] * elbrus is also involved with php7.0 transition... [19:01] * elbrus would like it that these things happen earlier in the cycle [19:01] Yeah :| === Guest28049 is now known as mfisch [19:01] We could patch the mysql client to allow the empty port option as it was in 5.6, but that really shouldn't be a lasting solution === mfisch is now known as Guest82454 [19:02] Skuggen: agree, but it would buy us time to find a proper solution [19:02] without rushing [19:02] Yeah. I'm going to test it tomorrow. [19:02] elbrus: It seems that everyone's best work happens right after you announce a freeze; the obvious solution is for me to open a new cycle with "we will be frozen for the next six months, no major changes allowed" and watch the uploads roll in. === Guest82454 is now known as mfisch [19:03] nacc: php-horde-javascriptminify-jsmin was also done already [19:03] :) [19:04] infinity: But you'd have to keep adding freeze cycles as people get wise to it :) [19:04] elbrus: I just wanted to get some feedback on whether this was simple to fix in dbconfig and I was just too confused by it to spot it :) [19:04] * elbrus always tries to not rush things in, but indeed we also did it for lazarus (which now fails on powerpc because of glibc update) [19:04] Skuggen: Yup, it's like the alarm clock rewing arms race. [19:04] s/rewing/rewind/ [19:05] elbrus: Yeah, I was looking into the fpc/ppc thing over the weekend a bit. Still not solved, but I got... Somewhere. I think. Ish. [19:05] Skuggen: I don't think it is trivial as it requires careful thinking about corner cases [19:06] infinity: I heard from ginggs [19:06] Ok. I'll test the client patch tomorrow then. We really need to get these test issues cleared up :) [19:06] This should fix the redmine failures as well [19:06] Skuggen: redmine is using dbconfig-common as well... [19:06] Yeah [19:07] Both redmine and phpmyadmin get database config files from dbconfig, so the issue propagates to them [19:07] indeed [19:07] but redmine probably got tested seperately because it does not require mysql (it can work with other dbs) [19:11] I'll post an update to the bug once I've tested the patch [19:46] nacc: I think I'm keeping up with all of the patches you're attaching, but you might want to make sure when you're adding a patch to a bug for an already-uploaded bug that you reopen the bug [19:47] slangasek: similarly, the php-crypt-gpg failure with ubuntu2 is a infra issue (internal timeout) [19:47] slangasek: yep, duly notied [19:52] nacc: yeah, the php-pear failures are marked 'tmpfail' on ci.u.c, unfortunately these just show up as 'regression' on update_excuses and there's no autoretry [19:52] (retried now) [19:53] slangasek: ah ok, thanks! [19:54] slangasek: it seems like php-fdomdocument should go through, as the version of phpdox actually in the archive now did pass its tests? [19:54] same for php-fxsl [19:55] nacc: usual process, we retry those tests now that the new version is in xenial so that we confirm that the cross-configuration works and there really aren't any regressions. I'll retry those now [19:55] slangasek: ok, thanks [19:55] slangasek: make sense, i'm just not allowed to resubmit [19:56] yep [19:56] nacc: have you started your Ubuntu developer application yet? [19:56] slangasek: no, that's on my todo for this week [19:56] ;) [19:56] nacc: oh and php-apigen FTBFS again [19:57] slangasek: i believe it needs the patch from LP: #1563098 [19:57] Launchpad bug 1563098 in php-apigen (Ubuntu) "Update d/rules UPSTREAM regex" [Undecided,Fix committed] https://launchpad.net/bugs/1563098 [19:57] does it still fail with that? [19:58] nacc: pretty sure that's the one I just uploaded [19:58] yeah it is [19:58] heh, https://launchpadlibrarian.net/250345806/buildlog_ubuntu-xenial-amd64.php-apigen_4.1.2-1ubuntu1_BUILDING.txt.gz [20:01] nacc: did you build-test this, or blindly trust my regexp? ;) [20:01] nacc: I think my regexp is right but that it's not properly escaped for makefile [20:01] slangasek: blind trust :) my own fault will fix it locally and update [20:02] slangasek: given that the build has failed, can i submit an update to the existing version? [20:02] slangasek: or does it need to be an ubuntu2? [20:02] nacc: must be ubuntu2. once the source is accepted by Launchpad, the version is burnt [20:03] ok, thanks [20:05] slangasek: is there any reason the regex couldn't just be: 's/.*(//;s/-.*).*//' ? === jgrimm is now known as jgrimm-afk [20:27] nacc: it's less generally correct for Debian versioning; the Debian part of the version number is always the part after the /last/ - [20:31] slangasek: so, sed 's/.*(//;s/-[^-]*).*//' [20:31] ? [20:32] slangasek ping [20:32] nacc: try and see, I think [20:46] nacc: Are you trying to split debian versions? [20:46] echo 2:1.2.3-5-09-0ubuntu1 | sed -e 's/$[0-9]*$:$.*$-$.*$/Epoch: \1, Upstream: \2, Debian: \3/' [20:46] Something like that works. [20:47] Though less friendly when all the components aren't there... [20:58] infinity: he just needs the upstream version, and is trying to adjust the existing Debian packages' buggy regexp [20:58] infinity: and he's parsing dpkg-parsechangelog output in one step [20:58] jdstrand: Thanks for checking [20:58] slangasek, hey, I've a feeling new cmake will cause us a lot of trouble: bug #1563548 [20:58] bug 1563548 in cmake (Ubuntu) "CMake 3.5's pkg-config support broken" [Undecided,New] https://launchpad.net/bugs/1563548 [20:59] mterry, FYI ↑ [21:01] Saviq: [21:01] slangasek: Right. Well, my above crap regex lays out the components, but obviously fails if some aren't present. Needs to be a bit more complex to adjust for the fact that all but the middle one are optional. [21:01] WHO put cmake 3.5.0 into the archive past the freeze? [21:01] slangasek: I find it's easier (or, easier to read), if one just does it in three steps instead of one scary one. [21:03] slangasek, LP: 1534263 [21:03] Launchpad bug 1534263 in cmake (Ubuntu) "[FFe] [merge request] Import cmake-3.5 series to Ubuntu Xenial 16.04LTS" [High,Fix released] https://launchpad.net/bugs/1534263 [21:06] ok so maybe not *that* much headache, but at least unity8 doesn't build, and I can find a few more projects relying on those variables that are suddenly empty in cmake 3.5 for no good reason [21:06] tumbleweed, well, it's in main, but as a b-d, so with the archive-reorg on the horizon, it still could be demoted [21:06] they should be there as far as I can read https://cmake.org/cmake/help/v3.5/module/FindPkgConfig.html [21:07] Saviq: cross-build for unity? or native build? [21:07] slangasek, native unity8 build [21:07] LocutusOfBorg: ^^ please figure out why Saviq's build isn't working [21:08] LocutusOfBorg, we rely on the _INCLUDEDIR variable to find some shared .h files, that var (and LIBDIR and VERSION) are now empty [21:09] LocutusOfBorg, Saviq: I give this until my end of day to get sorted, and then I am uploading a revert of the cmake merge [21:09] slangasek, probably that path cross stuff in ubuntu2 might be the clue [21:09] LocutusOfBorg, that's a diff between 3.2 and 3.5's cache for pkg_check_modules(GLIB2 glib-2.0) http://pastebin.ubuntu.com/15555106/ [21:10] Saviq, can you please try with the shiny just uploaded cmake 3.5ubuntu2? [21:10] LocutusOfBorg, sure, trying [21:10] slangasek, infinity, nacc: if you are doing things to debian versions with regexes, consider just given up and writing perl instead [21:11] twitch no [21:11] Dpkg::Version is more readable than a regex... [21:13] LocutusOfBorg, FWIW this is native build, not cross, so I'd be surprised [21:14] Saviq, I saw your bug report as soon as you opened it, and I liked it already in the 1534263 bug [21:15] Saviq, building cmake on my wily, lets see [21:19] Saviq, I have not confirmed [21:19] slangasek, (please read) [21:19] but your issue is the following code [21:20] include(FindPkgConfig) [21:20] if you read that FindPkgConfig file [21:20] if(EXISTS "/etc/debian_version") [21:20] include(${CMAKE_ROOT}/Modules/MultiArchCross.cmake OPTIONAL RESULT_VARIABLE _INCLUDED_MULTIARCH_TOOLCHAIN_FILE) [21:20] endif() [21:20] ah so maybe it is the missing bit after all [21:20] that'd be good [21:20] so probably this is defined in many other places, and somewhere it is blowing up stuff [21:21] it might seem not related, but cmake does rely on it in other places [21:21] ok [21:21] * LocutusOfBorg tried to remove it once ago, when he did some merge work [21:21] anyhow, 90% of the build completed, let me test [21:21] * LocutusOfBorg was traveling on train, otherwise he could have restored the block tag quickly [21:27] * Saviq sad nobody tried a cross-build when uploading new cmake :/ [21:27] we're really not treating our cross story with the attention it deserves [21:28] Saviq, some autopkgtestsuite might be good [21:29] anyway, I have been to busy and sick today to help as I wished [21:29] and I did my contribution a little bit late [21:29] I hope to fix everything in the next few hours, fever permitting [21:33] Saviq: sorry, I was aware of the request to include a new cmake in xenial and that the cross-support might not have been handled, but I had not seen the FFe request or that pitti had granted it [21:38] infinity: yeah, what slangasek said; i wonder if there should just be some DEBHELPER option for doing it for you, but I've noted down your example; I think we've got the buggy regexs fixed for now [21:39] LocutusOfBorg, afraid it doesn't help [21:46] Saviq, I saw [21:52] debugging [21:53] in file FindPkgConfig.cmake:111 the variables are correctly filled === jgrimm-afk is now known as jgrimm [22:17] Saviq, I got it [22:17] probably [22:23] Saviq, please test [22:23] in FindPkgConfig.cmake [22:23] - _pkgconfig_set("${_pkg_check_modules_pkg}_${variable}" "${${_pkg_check_modules_pkg}_${variable}}") [22:23] + _pkgconfig_set("${_pkg_check_prefix}_${variable}" "${${_pkg_check_prefix}_${variable}}") === AndyTechGuy_ is now known as AndyTechGuy [22:31] slangasek: i'm not able to reproduce the php-horde-http failure from autopkgtest, and the error doesn't make a lot of sense to me, as i only changed the running to be php-cli (so it'd be the php7 runner) ... could that be a transient issue? [22:33] slangasek: php-horde-mapi is a real failure and i'm trying to figure out how best to deal with it, might be a bit convoluted :/ [22:34] nacc: perhaps it's because php-horde-exception was uploaded in parallel, which means php-horde-http is being tested against the old version of php-horde-exception, which was still set up for php5? [22:35] nacc: so not "transient", but ordering; can be given a straight retry once php-horde-exception is resolved, which is bound up with php-horde-mapi that you just mentioned [22:35] slangasek: yep, that does look likely, thanks for clarifying [22:35] slangasek, can you please sponsor the debdiff? [22:36] LocutusOfBorg: link? [22:36] https://launchpadlibrarian.net/250356853/debdiff [22:36] just attached to the bug [22:36] upstream messed up the parameters of the macro [22:37] this patch is *so much* conservative, I keep both variables in the CMakeCache.txt file [22:37] even if one seems rather useless [22:37] you can also drop that line, I honestly think it was just a typo [22:38] slangasek: ok, so I need some guidance here: there are two packages, src:php-seclib and src:php-phpseclib, v1.0 and v2.0 of the same library. Debian has repackaged the latter so they are coinstallable, because the former is backwards compatible to PHP5 (which they still support). Upstream seclib is not updating 1.0 to PHP7 compliance because upstream 1.0 is BC to PHP4 :) There was a point in the Debian [22:39] package where they had broken BC and we probably woudl have passed the php-horde-mapi tests, but it broke BC and they reverted in Debian. [22:39] slangasek: i see two ways forward: 1) we diverge from debian's php-seclib and put the php7 patch back in [22:39] 2) we migrate the dependencies on php-seclib to php-phpseclib and remove php-seclib [22:40] but the debian packaging for php-phpseclib allows for both to be installed, so the php files in php-phpseclib get put in /usr/share/php/phpseclib ... which in turn makes them not in the usual place for callers [22:40] LocutusOfBorg: uploading. You've tested that this fixes Saviq's problem? [22:41] I'm updating the bug report with V=1 [22:41] slangasek: so either way we'd diverge from debian, and i'm not sure which is better; debian's chagnelog (in git) also mentions not all users will be php-seclib 2.0 ready, although I'm not 100% on what the means [22:42] slangasek, that was the testcase I used to dig into the issue [22:42] nacc: it sounds to me like re-patching php-seclib would be the quickest fix and require the least amount of chasing loose ends [22:42] so, yes, I confirm the variables are correctly filled on a xenial amd64 pbuilder clean chroot [22:43] and it seems a stupid upstream typo I'm going to report [22:43] slangasek: yeah, let me see if we can do that easily [22:45] damn damn damn [22:45] my holy glories about contributing to cmake codebase vanished [22:45] https://anonscm.debian.org/cgit/pkg-cmake/cmake.git/commit/?id=b71943bca4ed372568050d460960764ca2b3d4aa [22:45] two hours ago, version 3.5.1 landed in Debian [22:45] *exactly* the same fix [22:45] awww [22:45] better luck next bug :) [22:45] slangasek: would you be ok with a sync to a version that's not current in Debian (1.0.1-3 vs. 1.0.1-4; we currently have 1.0.1-1) or would you rather we take 1.0.1-4 and revert the revert? I'm not sure which is clearer [22:46] sarnold, I already had one bug in kernel codebase, already fixed but not merged because of 4.6 window not yet open blah [22:46] LocutusOfBorg: \o/ [22:46]