[00:13] <nacc_> Pharaoh_Atem: i found an open bug about it, i think
[00:13] <nacc_> slangasek: sorry, was working through my backlog, will look at that now
[00:19] <Pharaoh_Atem> nacc_: oh?
[00:19] <nacc_> slangasek: right and then we'll need to fix php-imagick :) which i have a diff for but am still working w/ debian on ... i'll test now with that patch backported and update the bug
[00:20] <nacc_> Pharaoh_Atem: yeah ... php-general post, actually
[00:20] <nacc_> Pharaoh_Atem: http://grokbase.com/t/php/php-general/15bgdvqds0/any-roadmap-for-php-with-pcre2-version-support
[00:20] <nacc_> Pharaoh_Atem: but it will require "porting" as I don't think they are API compatible
[02:48] <smoser> anyone able to help.
[02:48] <smoser> having an issue with tox and setuptools on xenial
[02:48] <smoser> http://paste.ubuntu.com/15249068/
[02:48] <smoser> the same thing works fine on trusty
[02:54] <smoser> hm..
[02:55] <smoser> well sort of good news. only fails on my development environment. not in a fresh container
[03:00] <nacc_> slangasek: php-imagick is at least running the tests now, trying to get it to pass them, then will post debdiff
[03:07] <smoser> wonder what could have done that .
[04:16] <smoser> bah. thank you for fixing my problem before i came upon it barry.
[04:16] <smoser> python-virtualenv: d/patches/use-wheels.patch: Also install _markerlib in the virtual environment.
[05:02] <sarnold> infinity: 1551522 is yet-another-dpkg "already installed and configured" bug, but the logs show some ~40 packages with this error -- I point this one out because I'm hopelessly naive and wonder if _this_ is the bug report that will explain all the others :)
[05:38] <infinity> sarnold: If you see anything attempting to configure more than once in the log, it's an apt bug, not a dpkg bug.  And some day, maybe we'll figure out how to unwind it.  It's Hard(tm).
[05:39] <sarnold> infinity: hmm does that mean the thousand-odd dpkg bugs on this should be retargeted? :) (not volunteering to do it :)
[05:39] <infinity> sarnold: Probably, yes.
[05:40] <infinity> sarnold: I suppose one could consider a dpkg workaround, where it ignores requests to configure already-configured packages, but the bug is definitely that apt is asking it to do that when it shouldn't.
[05:40] <sarnold> that might be a good idea even if it is somewhat unsatisfying
[05:43] <infinity> sarnold: Yeah, I'm trying to decide if that would potentially break anything.
[05:43] <sarnold> if only we had some kind of reproducer that we could test with .. :)
[05:43]  * sarnold wishful thinks his way to dinner
[05:43] <infinity> sarnold: Should certainly not be silent, at any rate, you still want to know that your higher level package manager is being stupid, but perhaps turning the error into a warning with a 0 exit code would be acceptable.
[05:44] <sarnold> infinity: *nod* agreed on both counts
[05:44] <sarnold> thanks infinity :) have a good night
[05:46] <infinity> sarnold: If you can ever create a rootfs with an actual reproducer for the apt issue, I'd love to see it.  I've literally never seen this in wild, nor been able to reproduce it locally.  The bugs are, indeed, real, but by the time they've been filed, the systems no longer are in a reproduction state, so...
[05:47] <infinity> Obviously, reproducing the dpkg behaviour is simple (dpkg --configure libc6), but tracing the stupid apt decisions that get there without manual intervention is tough.
[06:01] <juliank> sarnold: That looks like an aptdaemon bug. It apparently calculated the transaction while the other transaction (the apt install) was still ongoing.
[06:02] <juliank> So, it saw those packages as unconfigured at that point and thus scheduled configure calls
[06:07] <infinity> juliank: Feel free to reassign if you understand it.  I *think* we've seen logs with just pure apt tripping on the same thing too (ie: in N dpkg runs, where N > 1, apt seems to sometimes try to --configure something it already configured in a previous run)
[06:09] <pitti> Good morning
[06:19] <cpaelzer> good Morning
[06:31] <pitti> infinity: what's the usual  buildd timeout? https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu21 ppc64el and s390x have been building for 15 hours and did not make any progress
[06:32] <pitti> I already cancelled a stuck s390x yesterday and restarted it, but it got stuck at the same place again
[06:42] <pitti> ppc64el is stuck at 'dpkg-buildpackage: binary-only upload (no source included)', hmm
[06:42]  * pitti cancels them
[07:24] <infinity> pitti: It's got a hung dbus from the failed testsuite that hasn't cleaned up.  I'll just kill it so the build can fail gracefully.
[07:25] <pitti> infinity: ah thanks, ppc64el built now
[07:26] <pitti> s390x still failed, but is also hung
[07:26] <infinity> pitti: Yeah, that's the one I cleaned up just now.
[07:26] <infinity> pitti: Good thing the s390x maintainer also happens to be an upstart hacker. :P
[07:26] <infinity> xnox: ^
[07:26] <pitti> ah, so ppc64 built by itself this time
[07:49] <dholbach> good morning
[08:44] <cpaelzer> Hi, I didn't find an explicit statement about it in the Debian policy or on Ubuntu pages - but I guess for init scripts and such we prefer spaces before tabs right?
[08:44] <cpaelzer> because the files I have here are mixed and I want to unify it to one or the other
[09:05] <rbanffy> Good morning. What would it take to update http://packages.ubuntu.com/xenial/fonts/fonts-3270 to the same release as upstream (v1.2.11)?
[09:19] <seb128> hallyn, arges, jamespage, hey, you have your names on the libvirt package, do you know why we divert from Debian on binary names? like why we don't have a libvirt-daemon?
[09:20] <seb128> other packages depwait on libvirt-daemon(-system)
[09:27] <infinity> cpaelzer: There's no Debian or Ubuntu coding policy, generally you want to match the style of your upstream project.  Or, if writing init scripts from scratch, perhaps match /etc/init.d/skeleton
[09:33] <smb> seb128, because we did in the past when there was no such thing and now we did not want to change just before a stable release (libvirt)
[09:35] <seb128> smb, should we maybe have libvirt-bin to Provides the new names?
[09:35] <seb128> or we can delete the few things depwaiting in proposed, since it seems the updates are mostly Depends libvirt-bin -> libvirt-daemon
[09:35] <smb> seb128, I might add that in parallel for the next upload
[09:35] <seb128> e.g https://launchpad.net/ubuntu/+source/gnome-boxes/3.18.1-1.1
[09:36] <seb128> smb, thanks for the replies!
[09:37] <cpaelzer> infinity: thank you the  /etc/init.d/skeleton hint will be the one I chose
[09:37] <smb> seb128, yw. Thanks for bringing it up. I guess for the transition phase it will be good to have both. Do you know whether there is already a bug report filed about it that I should refer to?
[09:38] <seb128> smb, not afaik, but I can open on if you want
[09:39] <smb> seb128, Oh I can do that myself, just in case there already were one open. Not strictly require one but given the interrupt driven workflow I better have some reminder. :)
[09:40] <seb128> right, no bug open that know about then :-)
[09:54] <tjaalton> hmm, upgraded to xenial and now can't run sudo inside schroots: "sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?"
[10:39] <xnox> infinity, all i did last year for upstart is try to push ChromeOS & Ubuntu Touch to stop using upstart.... =)
[10:59] <xnox> infinity, would you like a glibc bug for s390x? =) https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1549850
[11:06] <xnox> infinity, however probably not glibc bug
[11:48] <xnox> infinity, nope not a bug.
[12:48] <Saviq> pitti, hey, we've come upon a problem with britney - we can't locally reproduce a test failure that happens there reliably, is there a way we could get access to a node similar to what britney uses?
[12:50] <pitti> Saviq: yes, should be; which arch?
[12:50] <Saviq> pitti, amd64
[12:51] <pitti> Saviq: I can run the test manually with --shell, let it fail, and give you ssh to that instance
[12:51] <pitti> Saviq: which package/trigger?
[12:51] <Saviq> pitti, that would be great, sec
[12:51] <Saviq> pitti, the unity8 one in https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-064/excuses.html
[12:53] <pitti> Saviq: ah, so that might be hardware/mir specific?
[12:53] <Saviq> pitti, no
[12:54] <Saviq> pitti, it's all under xvfb
[12:54] <Saviq> pitti, but let's hold on, we might've just thought of a solution
[12:54]  * pitti has some difficulty finding the actual failure in the log
[12:54] <Saviq> pitti, grep for fail!
[12:55] <pitti> ah, thanks
[17:34] <smoser> pitti, if you want to review https://code.launchpad.net/~smoser/cloud-init/trunk.lp1543025/+merge/287682
[17:34] <smoser> it seems to work for me.
[17:38] <infinity> "The copy was due to an old bug in Ubuntu" <-- revisionist history by Lennart? :P
[17:38] <infinity> (it wasn't a bug, it was intentional)
[17:40] <dobey> is there something wrong with module-init-tools in xenial (or trusty)? i keep having do-release-upgrade -d failing with a complaint that module-init-tools can't be authenticated
[17:40] <infinity> dobey: It doesn't exist.
[17:40] <infinity> Oh, it does exist still, but it's NBS and needs removing.
[17:41] <infinity> Once nothing depends on it anymore.
[17:42] <dobey> oh
[18:10] <xnox> smoser, infinity: huh?! symlink from /etc -> usr. That clearly is a good idea(tm).
[18:10] <smoser> pitti told me to do it.
[18:11] <xnox> ok
[18:11] <smoser> if thats not right i can change it.
[18:11] <xnox> pitti, do we have tzdata shipping in /lib with compat symlinks from /usr/share -> /lib ?
[18:14] <smoser> that is what timedatectl does. and also dpkg-reconfigure tzdata
[18:14] <smoser> so cloud-init is not any worse than anything else.  which is always what i strive for :)
[18:15] <sarnold> :)
[18:29] <pitti> right, so this makes the localtime handling consistent
[18:29] <pitti> xnox: no, tzdata ships stuff in /usr
[18:29] <pitti> smoser: thanks
[18:30] <xnox> smoser, fair enough.
[18:30] <pitti> and more importantly, we don't overwrite tzdata's files in /usr :)
[18:31] <pitti> (which was what this bug was about originally)
[18:31] <pitti> ah, already merged
[18:32] <pitti> LGTM, I just suggested clarifying the commit mesage, but no biggie
[18:32] <pitti> xnox: systems with a separate /usr but no initrd have never really worked well, and we shouldn't claim that we support them
[18:32] <pitti> "/usr merge!" *cough*
[18:39] <Skuggen> pitti: I was wondering if you had some input about the use of deb-systemd-helper in maintainer scripts i.e. is it a bad idea?
[18:39] <pitti> Skuggen: not necessarily a bad idea, as long as you know what you are doing
[18:39] <Skuggen> I'm working on the mysql 5.7 packaging with rbasak, and we run into an issue when trying to upgrade from old 5.5 installs, since the service is masked and disabled
[18:39] <pitti> Skuggen: it's generally easier/better/more robust to use dh_installinit or dh_systemd_{enable,start}, though
[18:39] <pitti> as some operations are not at all trivial
[18:39] <Skuggen> https://github.com/ltangvald/mysql-5.7/blob/fixes/debian/mysql-server-5.7.postinst#L80
[18:40] <Skuggen> That's the problem; I don't feel I know what I'm doing. I just saw that the system would run those commands after postinst, and that they fixed the specific problem :)
[18:41] <pitti> Skuggen: e. g. dh_systemd_enable already creates unmask/was-enabled/enable code (plus the necessary bits in postrm, etc.)
[18:43] <Skuggen> pitti: But it adds it at the end?
[18:43] <pitti> Skuggen: it adds it wherever you put #DEBHELPER#
[18:44] <Skuggen> Right, which is at the end of the postinst script
[18:44] <Skuggen> (I got it from there when enabling debug output)
[19:15] <rbasak> pitti, Skuggen: essentially I don't really understand exactly what's going on there, so I'd appreciate pitti's review.
[19:15] <rbasak> If pitti thinks it looks OK then I'm happy to upload it.
[20:15] <Pharaoh_Atem> nacc_: I'm baffled by this pcre thing
[20:16] <nacc_> Pharaoh_Atem: yeah, it's ugly ... i have a good start on debugging it, but am trying to fix php-imagick still
[20:16] <Pharaoh_Atem> I'm going to go take a look at the fpm bugs for now
[20:16] <nacc_> Pharaoh_Atem: ok
[20:16] <Pharaoh_Atem> as this bug makes me want to cry
[20:24] <Pharaoh_Atem> nacc_: is there a policy for closing long standing bugs that no one has responded to?
[20:24] <Pharaoh_Atem> most of the bugs here seem to be for really old versions of php5 and ubuntu
[20:25] <sarnold> bugs in Incomplete state get closed after N days
[20:25] <sarnold> and community members tend to close the others in other states when they refer to releases that are no longer supported
[20:32] <nacc_> Pharaoh_Atem: ideally, we'll trawl those and figure out if its still reproducible with supported php5 (in precise/trusty/wily)
[20:36] <Pharaoh_Atem> sarnold: so I could go ahead and close some of these years-old "Incomplete" bugs?
[20:36] <sarnold> Pharaoh_Atem: probably :)
[20:37] <Pharaoh_Atem> what status should I set it to?
[20:37] <Pharaoh_Atem> Invalid?
[20:38] <Pharaoh_Atem> I don't see another way to close it
[20:38] <sarnold> hmm, I think that's fair, maybe wont-fix.. Inever pay too close attention to those floods of mails when they arrive :)
[20:38] <Pharaoh_Atem> there's no wontfix option, so I'll just use invalid
[20:38] <rbasak> I'd use Incomplete. Or are they Incomplete already?
[20:38] <rbasak> Especially if the bug has languished due to no developer input.
[20:39] <Pharaoh_Atem> incomplete status for four years
[20:39] <rbasak> Together with a comment explaining that you're sweeping through fpm bugs. Tends to upset people less.
[20:39] <rbasak> Incomplete status but didn't go to Expired automatically? That's odd.
[20:39] <Pharaoh_Atem> okay
[20:39] <Pharaoh_Atem> there's quite a few of those :/
[20:39] <rbasak> (also instructions on what to do to get attention if they still want it)
[20:40] <rbasak> I usually subscribe to the bug too, to catch any replies.
[20:40] <rbasak> Unfortunately some proportion of reporters still get upset by that :-/
[20:44] <Pharaoh_Atem> there's just no winning
[20:45] <Pharaoh_Atem> I'm surprised there's no just plain "closed" status
[20:47] <rbasak> We consider Fix Released, Invalid, Expired and Won't Fix to all be closed.
[20:47] <rbasak> I think it's nicer this way. You can't close without a reason.
[20:55] <barry> mterry: ping re: deja-dup
[20:55] <mterry> barry, heyo
[20:56] <barry> mterry: hi.  not sure if you still work on this package, but i'm wondering if it makes sense to treat deja-dup-backend-gvfs and gvfs-backends the same way deja is treating dpulicity and pytho-gi?
[20:58] <mterry> barry, it could, sure.  The code would be a little less generic though, to look for a specific ubuntu-specific package name (debian doesn't even hame them)
[21:02] <barry> mterry: cool.  let me see if i can figure something out.  i guess d-d-gvfs-backends doesn't do anything except pull in some dependencies when installed (it has effectively no contents)
[21:02] <mterry> barry, I was trying to be discouraging.  :)  Why would you prefer it that way?
[21:02] <mterry> barry, it's not a change that could be upstreamed
[21:03] <barry> mterry: maybe i don't ;)  i'm trying to tackle the last few py2 hold outs, but i guess it all comes down to samba-libs :(
[21:03] <mterry> barry, is deja-dup still pulling anything in?
[21:04] <barry> mterry: deja-dup-backend-gvfs and gvfs-backends afaict
[21:04] <mterry> barry, but those don't have python deps anymore, right?
[21:04] <barry> mterry: transitively they do though, through samba-libs
[21:04] <mterry> barry, ah....
[21:04] <mterry> barry, ok, I see.
[21:05] <mterry> barry, well whatever is easiest for you there.  I'd be happy to review something that uses the package names instead
[21:06] <Pharaoh_Atem> rbasak: jeez, some of these FPM issues are from Ubuntu 9.04?!
[21:06] <barry> mterry: porting samba is a big hairy mess, and upstream isn't too psyched to help afaict.  i've talked to the fedora guy, and even they are not making much progress on it.  my thinking is if i can install on demand the deja deps and system-config-printer-{common,gnome} then i can get py2 off the iso
[21:07] <mterry> barry, ok, makes sense
[21:07] <Pharaoh_Atem> barry: yeah, samba has been... thorny
[21:07] <barry> Pharaoh_Atem: hi.  indeed
[21:08] <Pharaoh_Atem> I don't know if you guys know about this, but it might come in handy for Py2->Py3 stuff: http://fedora.portingdb.xyz/
[21:08] <barry> mterry: ok thanks.  will ping if review is needed.
[21:08] <barry> Pharaoh_Atem: yep, and at some point we'll get a tracker for debian/ubuntu.  just haven't had time to put that up yet
[21:09] <Pharaoh_Atem> barry: it'd be great if it could be part of the same portingdb
[21:09] <Pharaoh_Atem> that would make the cross-distro efforts much easier
[21:09] <barry> Pharaoh_Atem: yep!  that's the plan
[21:10] <Pharaoh_Atem> barry: have you hooked up with Petr (encukou) on it?
[21:10] <barry> Pharaoh_Atem: yep, on both the portingdb and samba
[21:11] <Pharaoh_Atem> awesomeness
[21:11]  * Pharaoh_Atem likes hearing about stuff like that
[21:11] <barry> \o/
[21:11] <Pharaoh_Atem> barry: I'm a member of the Fedora Python SIG, so I like hearing about stuff like this
[21:12] <barry> Pharaoh_Atem: oh cool.  i lurk on the gmane group.  we pythonistas gotta stick together, right? :)
[21:13] <Pharaoh_Atem> indeed
[21:14] <Pharaoh_Atem> I live and breathe on IRC :)
[21:14] <Pharaoh_Atem> I've personally been shepherding a few small projects over to py3 land
[21:14] <Pharaoh_Atem> and I've recently pushed updates in Fedora for pika and mgarepo to enable py3 versions
[21:16] <Pharaoh_Atem> and it looks like Xenial already has pika updated
[21:16] <Pharaoh_Atem> woohoo
[21:27] <Pharaoh_Atem> rbasak: it looks like a patch was forgotten for php5 in precise: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1352617
[21:31] <Pharaoh_Atem> rbasak: I think the Launchpad Janitor is broken
[21:35] <Pharaoh_Atem> rbasak: also, what do I do with these bugs reported by apport, they give me nothing useful for reproducing it :/
[21:43] <teward> oh hey that's my bug
[21:43] <teward> Pharaoh_Atem: that bug didn't have enough testers at the time of my filing to confirm the issue
[21:44] <teward> that, and nobody bothered to look at it after my filing (looks like security changes introduced regressions)
[21:45] <teward> Pharaoh_Atem: TBH I would rather forward that to the Security team for consideration first - as my comment with the attached patch said
[21:45] <teward> (it's also why I never subbed sponsors - i wanted a security team review first)
[21:47] <teward> rbasak: ^ just to keep you in the loop (re: 1352617, which was just poked up at 16:27)
[21:47] <Pharaoh_Atem> teward: I see
[21:48]  * Pharaoh_Atem is trying to just triage through the bugs so that rbasak will feel more comfortable about switching php-fpm to main
[21:48] <teward> right
[21:48] <teward> Pharaoh_Atem: though, refer to https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1334337 for the 'related' bug
[21:48] <teward> which was Saucy, Trusty, and Utopic
[21:49] <teward> it's the same regression, I believe, though I didn't poke the patch any further because Precise went out of my radar
[21:49] <teward> Pretty certain that one doesn't exist anymore
[21:49] <teward> in any php*-fpm
[21:50] <Pharaoh_Atem> yeah, it's not a problem in trusty, vivid, wily, and xenial from my checking
[21:54] <teward> Pharaoh_Atem: it's not, pretty certain it's an extended case of that regression as documented in 1334337 - esp. given mdeslaur's comments on the irc logs on that bug
[21:54] <teward> Pharaoh_Atem: it'd be wonderful if I had the ability to approve the Precise nomination on that bug
[21:54] <teward> because then we can actually mark it as affecting *precise* :P
[21:54] <Pharaoh_Atem> I have zero powers here
[21:55] <teward> right
[21:55] <Pharaoh_Atem> afaik, only rbasak can do anything of value
[21:55] <teward> :P
[21:55] <Pharaoh_Atem> all I'm doing is trying to win him over so that I can have php7.0-fpm in main
[21:55] <teward> yep :)
[21:55] <teward> Pharaoh_Atem: well, you can confirm with me especially that 1352617 is not going to impact the MIR
[21:55] <teward> :)
[21:55] <Pharaoh_Atem> frankly, I don't expect any of these bugs to really apply to php7.0-fpm, because the internals were completely rewritten
[21:57] <Pharaoh_Atem> the internal codebase for php7.0 is wildly different from php5, so the bugs for php5 don't actually apply to php7
[21:57] <Pharaoh_Atem> unless they are distro specific config things
[21:58] <nacc_> slangasek: question about php-imagick for you ... i think debian (and we) will want to undo the change to move to phpunit (it's a divergence from upstream and doesn't really work). But the run-tests.php script that was used before isn't packaged. WOuld it make sense to package it? Or should I do a temporary build in debian/tests/control just to get the script ?
[21:58] <Pharaoh_Atem> basically all the bugs I see here don't apply to php7.0 in its entirety
[22:29] <rbasak> Pharaoh_Atem: for main inclusion of fpm, that would only affect Xenial onwards. I only want the bugs resolved for Xenial. If the conclusion is that they don't affect php7.0, then that's resolved for Xenial in my book.
[22:30] <rbasak> Pharaoh_Atem: but we should sort out the bug statuses accordingly, so that everybody understands what we think of each bug and has the opportunity to tell us otherwise.
[22:31] <rbasak> I'm not suggesting that we mass close bugs, but actually consider each on their own merits.
[22:31] <rbasak> If we have reason to believe that a bug probably doesn't affect Xenial, then we can explain that in a comment and mark Incomplete (or Fix Released or Invalid as appropriate).
[22:36] <barry> mterry: LP: #1551989
[22:37] <mterry> barry, noted.  Will look tomorrow
[22:37] <barry> mterry: thanks!
[22:41] <Pharaoh_Atem> rbasak: I have not yet seen a bug that affects php7.0/Xenial
[22:41] <Pharaoh_Atem> given that it's in a separate package name, wouldn't it be obvious they don't carry over to php7.0?
[22:43] <Pharaoh_Atem> brb
[22:44] <Pharaoh_Atem> rebooting
[22:50] <Pharaoh_Atem> back
[23:16] <mwhudson> hm, https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda looks a little out of date
[23:16] <mwhudson> are the next meetings going to be 2016-03-14Z15:00 and 2016-03-28Z19:00 ?
[23:18] <mwhudson> 2016-03-28 is easter monday but i don't know if that matters
[23:21] <sarnold> mwhudson: given that five of the seven members have terms expire before the next meeting, it may be moot :) https://launchpad.net/~developer-membership-board/+members
[23:22] <mwhudson> sarnold: i see https://launchpad.net/~techboard/+members is similarly humourous
[23:22] <sarnold> mwhudson: hehe