[00:14] rbasak: one of the big transitions is from php-config5 to php-config ... and i just realized that command-not-found would also need updating for all the php5 commands [00:15] rbasak: for those, would we be leaving in php7.0 (replacing php5) or just putting in php as appropriate? [01:09] rbasak: also, haven't seen any invite for a hangout tmrw; even if ondrej isn't available, could we do a quick sync on some questions I have? [01:32] does anyone why know apparmor-dbgsym doesn't appear in http://ddebs.ubuntu.com/dists/trusty/main/binary-i386/Packages ? the packages appear to exist just fine: http://ddebs.ubuntu.com/pool/main/a/apparmor/ [01:32] (also not in binary-amd64/, the first place I looked) [01:34] how odd, there's apparmor-2.8.98 packages there, but no apparmor-2.8.95~... versions [02:07] ondrej: where does php-pear come from in php7? I see that in php5 it's created by the php5 src pkg. But not in PHP7 -- and so when I try to build, e.g., php-pkg-tools from your git tree, it fails to find a2~2~2~ [02:07] err, ignore the tail of that, clearly ... fails to find php-pear [02:07] it == sbuild [02:10] ondrej: i also noticed in my xenial VM, after install php7.0, that I can't install php-pear (it depends on php5-common and php5-cli). I saw in your e-mail that you mentioned "php-pear is not built from independent source package", which made me think it came from php7.0? [02:17] ondrej: oh! was that a typo, perhaps .. i found http://anonscm.debian.org/cgit/pkg-php/php-pear.git/ [02:17] ondrej: and i'm guessing, since it's so new, it might not yet be packaged? === TheMuso` is now known as TheMuso === cpaelzer is now known as cpaelzer_afk === cpaelzer_afk is now known as cpaelzer [07:52] Good morning [07:53] good morning pitti, ça va ? [07:54] didrocks: j'ai des muscles dolores de basketball, mais je vais bien, merci ! et toi ? [07:55] pitti: ça va bien :) [07:55] Saviq: I forced it now [07:55] bdmurray: I saw the MP, will do, thanks! [07:57] hallyn: will respond in the bug; this should probably get told to not restart the service on package upgrade then (dh_installinit --no-restart-on-upgrade), but I'll read the details and confirm [07:57] hallyn: pam-cgm> ah, did the other changes land in xenial? or do I still need the PPA for testing? [07:57] pitti: everything should now be in xenial except the systemd change [07:58] note, libvirt-guests.service is already installed in debian/rules with --no-restart-on-upgrade [07:58] that's why i'm confused [07:58] hallyn: great, thanks; I'll merge some fixes from Debian while I'm at it, and trim the patch [07:58] it appears libvirt-bin's restart is forcing libvirt-guest's restart. which i assume is due to an error in how i relate them, [07:58] though i swear when i did this back in october of something it worked, [08:04] jamespage: hey, how are you? [08:05] jamespage: can you please have a look at debian bug 810702? They have a question about our Ubuntu delta, and I'm afraid I can't answer that [08:05] Debian bug 810702 in open-iscsi "Generate initiator name on install, not first boot" [Normal,Open] http://bugs.debian.org/810702 === ara is now known as Guest95629 [08:57] hallyn: hm, I see that you now have two patches in scope.c, both of which do a chown [08:58] hallyn: oh, nevermind, the other patch is commented out [09:00] thought i removed the other before my final debdiff [09:01] hallyn: still, core-Chown-systemd-cgroup-to-users.patch looks a lot nicer and smaller, didn't that one work? [09:01] pitti: it did not. [09:02] i didn't dig very deep; don't know if i needed to mkdir it first or of something else was going on [09:02] hallyn: ack; anyway, I'll work on that, and also adjust the autopkgtest (as that will now fail with the reduced patch) [09:03] pitti: thanks [09:03] hallyn: thanks to you! nice to get this into xenial, so that the CPU hotplugging people get happy again :) [09:23] nacc: php-pear is src:php-pear now [09:24] nacc: Matthieu probably didn't upload it yet to Debian unstable, I'll poke him === henrix_ is now known as henrix [09:29] hallyn: oh yes -- "chown(u->cgroup_path," doesn't work, that's not the full path, just something like /user/user-1000.slice [09:31] hallyn: with libpam-cgm installed, is it normal that this only does stuff for "freezer", not for any other cgroup? [09:31] sessionoptionalpam_cgm.so -c freezer [09:32] hallyn: ^ I suppose it is (that's from /etc/pam.d/common-session, sorry about the broken tabs) [09:32] ah, changing it to "freezer,memory" does work === cpaelzer is now known as cpaelzer_afk [10:35] hallyn: works nicely, I tested in a fresh VM, lxc-start works, and cgroups look good; nice work! [10:36] * pitti goes to adjust the autopkgtest, will upload then === cpaelzer_afk is now known as cpaelzer [11:43] caribou-: hm, I found a crash with xenial's rsyslog; installing juju-local triggers that (reproducer is in the bug); bug 1534106 [11:43] bug 1534106 in juju-core (Ubuntu) "rsyslogd crashed with SIGSEGV with juju-local configuration" [Medium,New] https://launchpad.net/bugs/1534106 [11:43] caribou-: mind having a look? [11:43] reproduces perfectly in a VM [11:44] pitti: sure, will look at it === _salem is now known as salem_ [11:48] Is there someone working on ntp merge already? [12:00] odd, why isn't that on merges.u.c. [12:01] kickinz1: anyway, Laney is TIL, so it just needs to be cleared with him [12:01] * pitti would assume Laney is fine with losing that [12:01] he already emailed me and I said okay [12:04] Laney, thanks again. Just to be sure noone else is working on it here (as I already had a pb wrt previous merge work) [12:04] nacc: are you happy for me to upload your logwatch merge or did you want to check with Debian/upstream on the snapshot question first? === jincreator is now known as jincreator_ [12:11] pitti, Darn. Sorry it seems the more I look at plumbing the more I get confused. Is it intentional that in Xenial the numbers to "dh_installinit ... -- defaults SS KK" seem to be ignored. Maybe I should just close my eyes and move ahead to units/services... [12:12] smb: SS and KK have been history for many many years, since insserv came along :) [12:12] smb: they should not be used any more (and are ignored), instead insserv will compute dependencies from the LSB headers in init.d scripts [12:16] pitti, *sigh* I am too old for that sh.. :-P Just glad that I think with "Before=" I have a better chance of modelling a "if thats there then start before" condition [12:17] smb: right, the equivalent of that is X-Start-Before: in the LSB header [12:23] pitti, ah ok... that was never used. looks like pure luck this ever worked [12:37] Laney: would you be able to apply the patch from Debian bug #808842 to glib2.0 in experimental please? otherwise I can apply it to Ubuntu for now [12:37] Debian bug 808842 in src:glib2.0 "glib2.0: FTBFS with PCRE 8.38: regex (?(? ginggs: Don't diverge. [12:40] I'll fix it. === kickinz1 is now known as kickinz1|lunch [12:45] Laney: thanks! [13:11] pitti, python3.5 tests pass, now blocked on postgresql-multicorn === kickinz1|lunch is now known as kickinz1 [13:23] doko: no, multicorn has an override [13:23] pitti, blimey I had to go re-read the original bug report for that one [13:23] doko: ah, it's the pyqt5/s390x regression, I'll look/retry [13:23] (iscsi patch/debian bug) [13:26] jamespage: yeah, that delta is pretty old, and the logic changed in Debian several times; I'm not even sure if it's still needed, but when building an image in a chroot with policy-rc. the init script wouldn't run and generate the id [13:27] barry, yeah - fedora people got FTBFS in cython too now, and came out about it on my cython devel thread =) === sergiusens_ is now known as sergiusens [14:10] ondrej: around? Can we arrange a time to sync with nacc, Pharaoh_Atem and myself please? [14:14] rbasak, di dyou get a chance to look at amavisd-new merge ? [14:15] kickinz1: not yet, sorry. I intend to review caribou's merge next, and then yours. Hopefully this afternoon. [14:18] rbasak, ok I understand. [14:18] doko: ah, it landed now [14:20] I've splitted the ntp delta to my git repo on launchpad. If you want to look at it (there is a 'space' typo in debian/apparmor-profile, which appear at all diffs :( ). [14:24] rbasak, ^this typo would imply 2 rebase and 9 re-tags, and the new merge will be on a major version bump; tell me if you think it is better to remove it. [14:30] hi, i'd like to pay back to ubuntu by becoming a dev :) I know it says anyone can contribute, but i would like to be part of the main team [14:33] i'm familiar with C/C++ and Assembly [14:33] where should i start? [15:28] rbasak: hey Robbie, how are you? [15:28] rbasak: not sure who/whether someone cares in the server team, but I'm currently moving xenial to postgresql-9.5 (only) [15:29] rbasak: for an LTS we are pretty much required to ship the latest major upstream release [15:34] pitti: o/ [15:35] pitti: postgres has been pretty painless for us. Go ahead! [15:35] ondrej: ah ok! thanks -- yes, that'll get autosync'd and I can verify it in ubuntu that way, at least, too === smoser` is now known as smoser [15:45] rbasak: on the git merge stuff, I want to import the new/debian dsc; does the state of the repo matter (should I be at reconstruct/xxx ) ? [15:46] rharper: I would be at old/debian when importing new/debian. Then the history makes sense. [15:46] ok [15:46] I'm not sure how much this matters though. [15:47] It seems wrong to be anywhere else. [15:47] agreed [15:49] pitti: Do you use the armhf cloud images for autopkgtest stuff? [15:49] Odd_Bloke: not at the moment, no; I use the "ubuntu" template with debootstrap [15:50] Odd_Bloke: I was going to use them by moving to lxd, but we have some problems on arm64 which currently prevent that [15:50] pitti: Would you be comfortable with us dropping them for xenial? [15:50] pitti: (We're not really seeing any downloads for them ATM) [15:50] Odd_Bloke: fine with me, as long as we keep LXC/LXD images [15:51] Odd_Bloke: well, hang on; there is a chance that we can soon boot armhf images in Scalingstack [15:51] (wgrant was looking into some blockers there) [15:51] pitti: Right, I'm waiting to hear back from wgrant on that. [15:51] pitti: (But I asked that in [15:51] #launchpad, just to make following the conversation harder :p) [15:51] Odd_Bloke: if/once that works, having images would be nice, but I think that an lxd image would suffice for that as we need to specify kernel and initrd separately anyway [15:54] pitti: for Launchpad, our plan is to boot arm64 images with a kernel option apw added to make them emulate armhf more accurately [15:54] pitti: mostly because that fits better into the way we do multi-architecture-capable builders [15:54] cjwatson: ah, ok; with that appraoch I'm currently blocked by bug 1531768 :/ [15:54] bug 1531768 in linux (Ubuntu) "arm64 kernel and multiple CPUs is unusably slow" [Medium,Confirmed] https://launchpad.net/bugs/1531768 [15:57] pitti, hey, I'm working on adding autopkgtest runs to our Jenkaas, got a few minutes for questions? [15:58] Saviq: we have team meeting in 2 mins, but just ask [16:02] pitti, I've used autopkgtest from trusty-backports (was it a good idea? maybe there's a better source?), any idea why artifacts would not get copied over from the testbed? I can see the tests writing to ADT_ARTIFACTS but they didn't show up in --output-dir https://unity8-jenkins.ubuntu.com/job/run-commands/376/ [16:02] Saviq: trsuty-backports is fine (I shoudl update it, though) [16:03] pitti, a different question is now how to restrict tests to a certain testbed (I'd like to put autopilot tests, meant to run on a phone, into a autopkgtest) [16:03] Saviq: perhaps your didn't tell your jenkins job to copy the artifacts/ subdir? [16:03] I know I could just pass --testname, but maybe there's a better way, one that would work/not break britney, too? [16:04] pitti, d'oh, ** [16:04] most likel [16:04] y [16:04] Saviq: why can't the autopilot tests run with britney tests? we have quite a number of packages who do that [16:05] Saviq: there's some autopilot-sandbox-run convenience script to set up Xvfb, dbus etc. [16:05] Saviq: otherwise, make the test check for an expected environment and exit with 0 and some message like "SKIP: not on an ubuntu phone" [16:05] pitti, they need a phone, a full Unity8/Mir session, at least until we get virtual output from Mir [16:06] pitti, ack, that works, thanks [16:08] barry, just gave back cython, still ftbfs [16:08] :( [16:09] pitti, ah, last thing, parallelizing builds, that's fixed in latest adt-run, right? probably just not in the trusty-backports one? [16:10] Saviq: should be in trusty-backports, hang on [16:10] doko: there's been a little more discussion on that cython thread xnox started. maybe the cython devs will fix that bug [16:10] Saviq: that was in 3.17.3 [16:12] barry, xnox: reference? [16:12] pitti, hmm if I didn't pass DEB_BUILD_OPTIONS="parallel=4" it went and built on a single core [16:13] DEB_BUILD_OPTIONS=parallel=$(grep -c ^processor /proc/cpuinfo | sed 's/^0$/1/'); [16:13] doko: https://mail.python.org/pipermail/cython-devel/2016-January/004639.html [16:13] Saviq: it uses that; what target are you running this on? perhaps /proc/cpuinfo is wedged there? [16:14] doko, barry: https://github.com/python/asyncio/issues/308 https://mail.python.org/pipermail/cython-devel/2015-December/004630.html https://mail.python.org/pipermail/cython-devel/2016-January/004639.html [16:14] pitti, looks fine, gave out "4" [16:14] as "nproc" does [16:15] Saviq: oh, nproc, I learned something new! [16:15] :) [16:15] that uses sched_getaffinity() [16:16] Saviq: but either way, it works locally, so I'm afraid I need some more info to reproduce; can you please file a bug for that? [16:16] pitti, will do when I confirm [16:25] xnox, but no real feedback from the cython side? [16:25] doko, radio silence [16:27] rbasak, so I did some rework on my ubuntu delta for ntp, but now it doesn't get pushed correctly to launchpad [16:28] kickinz1: what happens? [16:28] my current local git is: http://paste.ubuntu.com/14496958/ [16:29] rbasak: rharper: it will matter a bit, for the current branch you are on, but in theory that can be fixed later with rebases/renames [16:29] and in my launchpad tree it is like I have a duplicate master branch instead of the deltas: https://git.launchpad.net/~kick-d/ubuntu/+source/ntp/log/?h=reconstruct/4.2.6.p5%2bdfsg-3ubuntu9 [16:29] kickinz1: what branches do you have locally and how are you pushing? [16:30] kickinz1: so it looks like you pushed your local master (or reconstruct) to the remote's master [16:31] I pushed both of them. [16:31] if you look at your local tree, it seems like tag: new/debian, tag: 1_4.2.8p4+dfsg-3, reconstruct/4.2.6.p5+dfsg-3ubuntu9, master are all 04b751c [16:32] nacc, thanks. [16:32] kickinz1: on what branch is e.g., cfdd2ee [16:32] you want to push that to the remote, so that it updates ... remotely :) [16:34] rbasak: Pharaoh_Atem: either of you around? [16:36] nacc, thanks again [16:37] kickinz1: np, i actually find the 'pretty' log you pastebin'd much harder to parse than it needs to be ... but that's because I want the names (tags, brances) to be first in my head ... would have been a lot more obvious what was going on if that was the case (rather than a parenthized suffix) [16:38] nacc, OK, I'll rewrite my gitconfig, thanks for the tip. [16:40] kickinz1: yeah, whatever works best for you, though, for sure. I also use git enough that I would rather call the commands how I want rather than change the defaults :) [16:41] nacc :) [16:41] nacc: o/ [16:42] rbasak: heya! do you have a few minutes to chat? I know it's getting late for you [16:44] nacc: just got in [16:46] Pharaoh_Atem: cool, let's see if rbasak is also free, and if not, maybe we can chat a bit [16:54] nacc: cool [17:07] ondrej: how are you dealing with SWIG breakage with PHP7? Seems not yet fixed upstream, so certain src packages that use SWIG to rebuild simply won't work with PHP7.0? [17:09] nacc: yes I'm free. === kickinz1 is now known as kickinz1|eod [17:09] I don't be tomorrow evening, but today is OK-ish. I have some bits to do but am around and can rearrange to find whatever time. [17:09] rbasak: great, thanks -- i'll set up a hangout, if that's ok with you and Pharaoh_Atem? [17:10] nacc: sure. How soon? Now is fine, I just need to reboot into Chrome OS etc. [17:10] Pharaoh_Atem might want more notice though! [17:10] Not heard from ondrej yet. [17:10] rbasak: I got a couple responses from ondrej ... tbh, let me just ask my questions here, and we'll see how far that gets us [17:10] rbasak: I mean, I'm here [17:11] nacc: I can certainly do the hangout thing [17:11] just let me know when and I'll find somewhere to go do this [17:11] so it looks like swig isn't getting fixed necessarily anytime soon; I have the build in my PPA to disable the PHP bindings [17:12] but that will break e.g., graphviz for a while [17:12] Only graphviz's PHP bindings? [17:12] well, any package that tries to use swig [17:12] Or do we need to add a graphviz delta for that? [17:12] graphviz happens to be in main [17:12] so I was considering it first :) [17:13] rbasak: right, so i figured we'd modify graphviz ... but wanted to understand how best to do that? just disable the binary package that contains the php bindings? [17:13] Good question. That would certainly work. [17:14] I think we might be best getting wider consensus on this. [17:15] Good job on identifying graphviz. Do you have a way of generating a complete list? [17:15] rbasak: i think the pad is now pretty current [17:15] i've not yet broken it down by swig/pear/pecl [17:15] that was going to be my next step [17:15] Can we publish that and see who objects to disabling those bindings? It'll come down to either doing that or not shipping PHP 7.0 I think, so I assume it'll be OK to do that, but I want to make sure other devs are happy with that. [17:15] Before we go mass uploading those disablements. [17:16] rbasak: yeah, where's a good place to publish it? I can clean it up a bit and put it somewhere "official" [17:16] nacc: ubuntu-devel ML please. [17:16] I guess I should be on that ml, shouldn't I? [17:16] given the two are coninstallalbe, surely a bunch of swig based bindings can stay at 5.0... [17:16] rbasak: also, i noticed that the package in graphviz is 'libgv-php5' ... so would we create a libgv-php? or libgv-php7.0 [17:16] xnox: they won't be coinstallable :) [17:16] xnox: except that swig is in main. [17:16] or for example, build everything for both. [17:17] Also, I want php 5.6 gone. Not in main, not in universe. [17:17] kill it with FIRE! :D [17:17] I think we agreed on that previously, although we can always change that based on new information of course. [17:17] rbasak, we should just have archive reorg and thus have everything able to build-dep on anything =) no more package splits \o/ [17:17] xnox: yeah, how are you progressing with that? :-) [17:17] rbasak, we moved cjwatson into launchpad for exactly that reason! [17:18] Anyway, it won't matter if we're losing 5.6 entirely. [17:18] rbasak, when will swig be 7.0 ready? [17:18] rbasak: ok, i'll send an e-mail by EOD [17:18] xnox: no ETA [17:18] =/ [17:18] xnox: not imminently, if ever. [17:18] xnox: as in no upstream progress yet in that regard [17:18] xnox: https://github.com/swig/swig/issues/571 [17:19] nacc: thanks! [17:19] nacc: I suggest that you propose to drop the bindings, point out that not doing so blocks php 7.0, and invite objections. [17:19] (with a list of affected packages) [17:20] rbasak: yep, that makes sense [17:20] * xnox ponders if porting swig is easier than disable all the things [17:20] Pharaoh_Atem: join the ML if you like. Though posts are moderated for non-uploaders anyway, and an archive is available, so it probably makes little difference. You can participate the same either way :) [17:20] (I'm sure the moderators will pass all your emails regarding this transition through) [17:21] xnox: i was going to look at what was needed, but that was a lower priority for me in the short-term [17:21] rbasak: ok, next question, I noticed with the move of some commands, tools, the API version is now obtained by php-config --phpapi rather than php5-config --phpapi ... and I noticed that if you run `php-config` from a Xenial prompt [17:21] c-n-f doesn't know where to find it :) [17:21] I think c-n-f is autogenerated periodically [17:21] rbasak: so ... does c-n-f need updating manually? or is there some voodoo to make it look up new packages? [17:21] I'm not really familiar with how it works. [17:22] rbasak: yeah, i started looking at doing it manually (as we'd want to remove references to the php5 commands in the PPA) ... it didn't seem to like my changes, but it was late when i was doing that [17:22] pitti: yup, freezer only by default. i suppose we could have systemd do that one and Lennart may even be ok with it - but we need pam-cgm for users who want memory cgroup etc - this makes it trivial to add that [17:22] mvo knows I think. [17:22] rbasak: also, the php-pear move is going to be annoying until debian merges it [17:22] rbasak: that is, w/ PHP5.0, php-pear was generated by the php5 src pkg [17:22] err, PHP5 [17:23] * xnox ponders if i confused php5+7 coninstallability with perl5+6 coinstallability [17:23] with PHP7.0, it is its own src pkg, which doesn't seem to exist anywhere yet [17:23] xnox: i think Debian will have coinstallability, but it's kinda messy [17:23] xnox: and they will move to 7.0 only in the next release, I think [17:23] and we want 7.0 because....? [17:23] * rbasak wonders why php-pear didn't autosync [17:24] rbasak: it hasn't been pushed to debian either yet, i don't think [17:24] rbasak: based upon ondrej's comment earlier [17:24] i'd say until things in main are fixed to work with php7 we don't want it, as default, or only php. (and that includes swig) [17:25] rbasak: I've subscribed regardless [17:25] rbasak: but we're kind of stuck on pear fixes until that happens, it seems like [17:25] usually that's the criteria for every other major upgrade. [17:26] rbasak: $ rmadison -udebian -asource php-pear [17:26] php-pear | 1:1.10.1+submodules+notgz-1 | new | source [17:27] right, so i think this is a workflow I didn't understand (and applies to a few other packages that are getting updated to 7.0) -- "new" means that debian is aware of a new revision, but hasn't actually packaged them yet? [17:29] cjwatson: ah, thanks. [17:30] nacc: ondrej can give us a copy of what he uploaded to Debian NEW if necessary, and we can upload that to Ubuntu in the meantime if necessary. We'll need an Ubuntu Archive Admin to review it if we do that, but it can be done if we're blocked on a Debian ftpmaster processing it at the Debian end. [17:30] In fact ondrej's upload is probably in git. [17:30] rbasak: ok, there was at least one other package that i hit that with in my review [17:30] rbasak: yes it is [17:30] rbasak: so i was going to ask that next [17:30] rbasak: as i go through these pacakges [17:30] some have been up dated in git with the master-7.0 branches [17:30] nacc, new means there are brand new binaries intoroduced, and are awaiting manual review before being included. But e.g. maintainer did package and upload it. It's just being held up. [17:30] binaries or sources [17:30] nacc, mostly legal review. === cpaelzer is now known as cpaelzer_afk [17:31] where "brand new" == "a binary/source name not currently in the archive", not new version [17:31] is it appropriate for me to merge them in the ubuntu git tree i'm using to build out a new dsc with an appropriate changelog (referring to the SHA1) entry? [17:31] xnox: cjwatson: ah ok, thanks! [17:32] rbasak: so it looks like the debian package doesn't include working fpm configs [17:32] so I'm working on that for the tests and stuff [17:35] rbasak: the package i was most considering that for was pkg-php-tools, which does have some changes in git that i can merge into my local tree and build out a new package from, i think ... but since it's not yet in a debian package, i wasn't sure if that made sense, or how to changelog it properly (I guess it's a one-off for testing still, so that doesn't matter too much) but basically without the right [17:35] phpapi-YYYYMMDD value at build time, the rebuilds don't trigger properly, etc. [17:39] nacc: if it's going into Debian as version foo, you can upload to a PPA foo~ppa1. Then foo is higher, so it will supersede it when it appears. [17:42] xnox: i think the rationale, also, was that if you needed SWIG, then you can stay on 14.04 LTS ... similar to if you needed PHP5 at all. I'm not saying it's perfect, but I think that was the reasoning. Also, PHP5.6 support ends aug. 2017, which is prompting some of the consideration of how to support that package in the LTS, I think [17:42] rbasak: ah interesting! more nuance, thanks! [17:46] nacc, and rhel will support 5.4 into 2024 [17:46] xnox: not sure rhel should be anyone's model citizen :-P [17:46] xnox: but yes, there is that [17:47] i think pulling off php7 now, will make it a crap 16.04, for the two years that it matters, vs having a good 5.6 for two years. [17:47] xnox: i'm really not trying to argue the point, sorry -- i agree with you, we should not break *anything* in main, and otherwise not do it [17:47] xnox: do you mean crap because too much will break? or because PHP7.0 is bad? [17:49] nacc, not enough critical mass. E.g. not everyone needs it, not everyone can use it, not all dependencies available. [17:50] people who want php7.0 will be able to use e.g. 16.10 [17:50] xnox: fair points -- I think rbasak was getting quite a bit of PR-work from people that disagree (based upon twitter) [17:51] but well, it's up to rbasak and server team to decide what they want to have. but e.g. security support for 5.6 over the next 5 years, is easy, given that everyone else is stuck on 5.x series. [17:53] rbasak: ok, another practical question, just for my own edification. in PHP5, php-json src pkg provides php-json and php5-json bin packages. Now php7.0-json is generated by php7.0 src pkg. So do we remove php-json src pkg and have php7.0-json produce a php-json bin package? Or remove php5-json bin package from the php-json package and have it refer/depend on php7.0-json for now? I guess the latter is mo [17:53] re sensible [17:53] xnox: yeah, i'm on that team :) trying to help figure it out as best I can [17:59] nacc: we'll need to check the php-json situation. In 5 we (Debian, Ubuntu, Fedora, maybe others) had to diverge from upstream because the bundled json module wasn't Free Software. I don't know if that has changed now. [17:59] As a result we had a third party external source (which I think Remi from Fedora put together). [18:00] That built php5-json instead of src:php5 [18:00] It did lead to a circular build dependency that needed to be resolved manually to break the loop. [18:01] rbasak: ah i see [18:02] Now if the licensing is now resolved upstream and we can ship it, then src:php7.0 can build php7.0-json and maybe a php-json alias and we should be fine. [18:03] rbasak: right, that makes sense; and if not, we'd need a php7.0-json or something? [18:03] nacc: if you mean a src:php7.0-json if not, then yes that's right. I suspect it probably is resolved though as I presume that's why ondrej didn't create one? [18:04] rbasak: do you have a reference I can read as to the prior licensing concern? [18:04] rbasak: right, sorry, yes that's what i meant [18:04] nacc: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692613 and also https://bugs.launchpad.net/ubuntu/+source/php-json/+bug/1287726 is relevant. [18:04] Debian bug 692613 in src:php5 "php5: non-free files in upstream tarball ("The Software shall be used for Good, not Evil")" [Serious,Fixed] [18:04] Launchpad bug 1287726 in php-json (Ubuntu) "Wrong evaluation whether json is valid or not" [Medium,Triaged] [18:06] rbasak: right, looks like src:php7.0's php-json is under the PHP 3.01 license [18:07] Lovely! [18:07] I'm glad they fixed that. [18:08] hrm, i wonder if something didn't get updated, though, README.REDIST.BINS still referes to the JSON license for ext/json/json_parser, but the files in taht directory refer to the PHP 3.01 license [18:12] rbasak: cjwatson: xnox: thanks for your patience and helpful education! learning a lot quickly... [18:19] hey folks! so lp:ubuntu/checkbox is at a point where we can transition it to being a non-native package. The branch would only contain the ubuntu-specific debian/ directory. It will build a single ubuntu-specific package since all its deps are now pulled from Debian. [18:21] we're wondering if it's bad practice to "reset" the branch for xenial. The (long and colorful) history for older releases would still be kept in the per-release branches... [18:30] Pici, , mbiebl_ nice talk [18:30] pitti, ^^^ [18:30] * LocutusOfBorg wrt debugging and dissecting systemd boot issues :) [18:30] thanks! [18:36] doko, barry - i wonder if those tests should be skipped for now, to get us going... However i think there is now more test failures, than before. [18:36] it used to be just the generator on s390x. [18:37] xnox: more failures w/3.5.1? [18:37] one sec, fiddling with logs. [18:37] xnox: don't forget, i fixed the pickling issue and doko cherry picked that [18:38] barry, ah, right. so right, wonderful =) so it's just the generator error. [18:38] anybody using asyncio, with generators, on python3.5.1, on xenial, and can figure out what's wrong are welcome to complain upstream =) [18:39] well, "fixed" maybe :) in any case, reverted the regression for stable releases [18:39] cause asyncio changes do look cryptic, and have a bug report attached. [18:40] xnox: i'm not asyncio expert, but i've done some projects using it. e.g. aiosmtpd still passes all its tests [18:40] i can't judge those asyncio changes tho [18:43] barry, well, it's not just 3.5.1 but with a co-routie too [18:43] ginggs: uploaded to exp, feel free to test/sync when it becomes available [18:43] ginggs: could be up to 8 hours though, so I'll look tomorrow if necessary [18:44] * Laney waves [18:49] rbasak: cnf unfortuntaely does need manual updating, its pretty trivial, there is a cron job collecting the update and a bzr-buildpackage hook to get it. I can do an update now [18:50] anyone know if in a buildd (for livefs build) i'd be able to do overlayfs mount ? [18:50] smoser, i think Odd_Bloke does do loop mount / losetup. i would think overlayfs would be allowed too. [18:51] ubuntu-desktop is overlayfs, but i guess on boot only. [18:51] right. i know that loop mounts work. [18:51] and even asked cjwatson for nbd to work [18:52] nacc: when I'm done with my logical branch, Im somewhat confused (though it may be because strongswan is special in that we never really had an old/debian that was debian's, rather we have an older ubuntu we're using as old/debian); when I'm replaying my logical branch onto the new/debian; there's not much overlap since the new/debian is a lot different; that is, I don't see much of any of the logical changes being [18:52] able to apply to a new/debian tag because they're so divergent [18:54] rharper, well, they may not apply, but the logical intent you need to maintain. or decide if you can drop. [18:54] right [19:11] pitti: doh, should have checked the bug earlier - when you're back and have some time, i would very much appreciate some guidance in bug 1533839 [19:11] bug 1533839 in libvirt (Ubuntu) "vms shutting down on libvirt upgrade" [Critical,Triaged] https://launchpad.net/bugs/1533839 [19:12] mbiebl_: ^ actually i suspect you can guide me there. basically, i need help figuring what in libvirt's debian/rules, debian/libvirt-bin.preinst, or debian/libvirt-bin.libvirt-bin.service and debian/libvirt-bin.libvirt-guests.service is causing libvirt-guests.service restart on pkg upgrade [19:17] rharper: yeah, i think if the underlying source changes a lot the rebase may lead to very different commits (in terms of the code), but the changelog should be applicable still (with the new code) -- or the changes are no longer needed [19:24] yeah, I'm just going to grind through a rebase and see what I end up with; [19:25] nacc: there are something like 50 changes I've got in my logical; it wasn't clear to me that I could drop any of these as we've diverged quite a bit w.r.t how things are packaged (subpackage per plugin versus two packages with all plugins) and aa profiles and other things we're bringing along [19:25] rharper: yeah, that's probably the simplest thing to do ... it's trivial to roll stuff back, now that you've got tags for the old/new stuff, etc. and you can make throwaway branches of course [19:25] nacc: also, wasn't quite clear to me how much to drop from the logical branch or whether it should be dropped during the rebase [19:26] yeah, doing this rebase on a branch [19:26] rharper: yeah, i think you want to drop as little as possible ... or as you said, do it as late as possible [19:26] yeah [19:27] rharper: so will new/ubuntu follow new/debian's system (subpackages etc.) or will you maintain old/ubuntu's (two packages with all plugins?) (or v.v., depending on which way you meant it)? [19:27] rharper: i guess those are the decisions you kind of have to make in the rebase/merge :) [19:28] not sure yet [19:28] I've neen discussing this with one of our users [19:28] I'll probably write up an email to ubuntu-devel to discuss [19:29] it certainly would be nice for merging to not have to keep 40 odd plugin install files; but that's a change from current ubuntu meaning we need to handle upgrades in a sane way [19:30] yeah, that seems tricky [19:31] rharper: would something like that be specified in the debian/ dir somewhere? that is, if a certain conf file is here in now, when you upgrade to this version, it goes *here* now? [19:31] there are two things [19:32] not really [19:33] rharper: how is that handled then? i mean, generally speaking when a program changes where it looks for config files, or the structure of its runtime loaded data? symlinks? [19:33] the new "plugin-standard" and plugin-extras packages would obsolete (I think) the per-plugin packages; so on upgrade, we'd know that if you had plugin-foo, then to install plugins-standard package [19:33] depends [19:34] in some cases if enough movement happens, then new versions of the package conflict and break old packages [19:34] othertimes, configs can be migrated in pre/post scripts; I'm weak on they policy, so we'd need to read the guides for sure [19:36] rharper: interesting -- yeah, rbasak pointed me at some docs yesterday, i'm sure it's covered in there somewhere [19:44] rharper: i'm going to be biking downtown and then i'll be back online -- good luck, let me know if i can help at all [20:34] rharper: my intent for the logical tag was to eliminate any churn in old/ubuntu. That is, make old/ubuntu exactly what was intended before in the cleanest and most minimal way. However, retain mistakes, since that helps with verification. Then the logical tag should still be identical to old/ubuntu, but "git log -p" should also be very clear and make sense. [20:34] rharper: so quite heavy rebasing, but without actually changing any code. [20:35] rharper: then you're in the best possible position to decide how to apply that to new/debian, and you can do it one commit at a time, and not worry about losing anything. [20:36] And you can have confidence that there are no mistakes up to that stage, since "git diff old/ubuntu" should be empty except for meta changes. [20:38] rbasak: I probably need to suffer this rebase and get to the end before I'll really understand this [20:39] rbasak: that said, I do think strongswan is unique at this point given the large delta between ubuntu strongswan and debian strongswan w.r.t debian/* [20:39] as an example, I have a conflict during rebase now because new/debian has a subpackage called strongswan-charon, and we don't have that package name at all (rather we package that in a different subpackage) [20:44] rbasak: am I doing something wrong here? I can't seem to get the php-fpm config to work: http://fpaste.org/310968/14528042/ [20:45] rharper: yeah sorry, the strongswan merge turned out to be even more painful than I expected, and you've ended up stuck with it. I think this git workflow shines when it comes to this complexity though. I don't know how I could manage it any other way. [20:46] rbasak: err, php-fpm apache config [20:46] rbasak: no worries; I figured if I can get this one to work then the rest will be easy (ha! tomcat is next I'm told) [20:47] Pharaoh_Atem: I'm not sure. This an area I don't know off the top of my head. I'd have to wade through the Apache config docs to understand, sorry. [20:47] it's fine [20:47] oh, geez [20:47] I think I know why now [20:47] :/ [20:47] Great! Glad to have helped :-P [20:48] the socket path for php-fpm in deb/ubuntu doesn't match what the upstream doc said it would be at [20:48] so... a tweak here should do it [20:48] X_X [20:49] nope [20:49] hmm [20:52] rbasak: so, given the divergence, would you expect that after I've rebased old/debian onto new/debian that I'd need to apply some new patches ? for example, in debian/control debian has different packages (plugin-standard, plugin-extras) [20:53] rharper: absolutely. Rebasing old/ubuntu onto new/debian is just the start. That's the automatic way of doing it, and then you have to fix up as needed to make the delta apply correctly, drop unneeded bits, etc. [20:54] rbasak: Ok [20:54] mterry: I forget did you have some experience with software-center? [20:54] that helps me make some sense [20:54] rharper: you don't even need to rebase if it's too complicated. You could cherry-pick each one instead, fixing up as you go, and just not cherry-pick where not relevant (or write yourself instead of cherry-pick) [20:54] bdmurray, no not really [20:54] rharper: the importance of logical is to make sure that you understand the previous delta, and do the appropriate thing for each item. Even if that's re-write, or drop. [20:55] rbasak: right, that makes sense [21:02] rbasak: so, strongswan-5.3.5 % ls debian/*.install | wc -l [21:02] 9 [21:02] % ls debian/*.install | wc -l [21:02] 67 [21:02] in general, debian puts all plugins into two packages; we've got them split out package per plugin; [21:03] so, using anything from debian w.r.t packaging is *hard* [21:03] unless, we want to go down the path of switching back to fewer packages [21:03] rharper: any path of reducing our delta against Debian is a good one. [21:03]