[00:00] <rbasak> I see http://cdimage.ubuntu.com/ubuntu-server/daily/current/
[00:02] <rbasak> That's full ISOs though, not netboot.
[00:02] <rbasak> Though not deprecated, we moved on from that stuff for development purposes years ago.
[00:02] <rbasak> uvtool gives you pretty much instant VM boot. No need to run an installer first.
[00:02] <cjwatson> http://cdimage.ubuntu.com/netboot/ should have links, let me fix that
[00:03] <sarnold> uvtool does cloud-init tihngs automatically?
[00:03] <rbasak> Yes
[00:03] <rbasak> It just glues cloud images through simplestreams to cloud-init to libvirt.
[00:03] <sarnold> neat. I've never looked into doing cloud-init by hand but it always seemed a bit of work, hehe
[00:04] <sarnold> I wanted a "hey stupid type these commands to make it work" sort of guide to cloud-init, and never found one..
[00:05] <rbasak> sarnold: https://help.ubuntu.com/lts/serverguide/cloud-images-and-uvtool.html
[00:05] <cjwatson> http://cdimage.ubuntu.com/netboot/ has links for xenial netboot images now
[00:05] <cjwatson> Pharaoh_Atem: ^-
[00:05] <sarnold> cjwatson: \o/
[00:05] <rbasak> sarnold: the uvtool CLI could do with some polish, but the basic functionality has been there a while. I hope the docs haven't rotted.
[00:05] <rbasak> Thanks cjwatson!
[00:06] <sarnold> rbasak: thanks :) looks nice and easy
[00:09] <rbasak> sarnold: np. Looking now, one thing undocumented is how to get a xenial daily image. This involves a wart. You need to run uvt-simplestreams-libvirt with --source to point to http://cloud-images.ubuntu.com/daily (IIRC)
[00:09] <rbasak> Otherwise you only see "released", which are alphas and betas during development, which is normally not what you want.
[00:11] <sarnold> it's not necessarily a bad thing to aim users to released releases :)
[00:11] <sarnold> but a simple --include-devel might be kind
[00:11] <sarnold> and defaulting to most-recent-LTS is very polite :)
[00:13] <rbasak> Yeah I'd like a --daily option to the sync command. But sync shouldn't even be necessary. It should pull images on demand.
[00:13] <rbasak> (sync only exists because I thought Juju would want to use it. But it doesn't)
[00:14] <rbasak> (Juju uses uvtool internally to provision its KVM submachines)
[00:14] <sarnold> not having used it myself.. I'm inclined to think a sync is better; it manages expectations of which operations will take two seconds vs two minutes, and helps manage storage..
[00:17] <bdmurray> seb128, pitti: I manually retraced one and updated bug 1532722 with the Stacktrace let me know if you need more.
[00:27] <rbasak> sarnold: that's what I thought originally, but I've changed my mind. While I think I need to be careful to avoid user surprise, I find myself always syncing immediately before firing up a VM. So on demand would save me keystrokes.
[00:27] <hallyn> pitti: stgraber: so for pam-cgm.  we do not support xenial/systemd container without writeable cgroups (i.e. lxcfs);  i dont' want to complicate pam-cgm;
[00:27] <rbasak> The entire point of the tool is to save keystrokes, so I think that's an important consideration.
[00:27] <hallyn> pitti: stgraber: so my thought is i'll write a new pam_lxcfs.so, which conflicts: pam-cgm, and only does lxcfs.   keep the two cleanly separated
[00:29] <sarnold> rbasak: heh, well, I can see that then :) if you're always running sync beforehand, that might be a logical conclusion to draw
[00:32] <Pharaoh_Atem> rbasak: it doesn't look like uvtool is packaged for Fedora, so I guess I might as well do that too while I'm at it :P
[00:32] <Pharaoh_Atem> rbasak: can you point me to the sources for it?
[00:32] <Pharaoh_Atem> actually, nvm
[00:33] <Pharaoh_Atem> looks like it's never had a release, and it's a bzr snapshot
[05:31] <momken> Hello
[05:32] <momken> I am making the package of GNU Hello for myself to learn how to build a package from scratch
[05:33] <momken> I followed up to section 6.3 of this tutorial: http://packaging.ubuntu.com/html/packaging-new-software.html
[05:35] <momken> but after running "$ bzr builddeb -- -us -uc" I get these errors: http://dpaste.com/3K91XEJ
[05:35] <momken> Please help
[05:58] <momken> Ooops. the debian/rules file is very tricky. It's making me nuts, especially that I have no idea what to do
[06:08] <pitti> Good morning
[06:11] <pitti> bdmurray: thanks for the stacktrace, this is helpful! that pinpoints the strncpy() call and shows that its second argument current_state = 0x1 is bogus
[06:12] <pitti> hallyn: would it help if systemd itself chowns its own name=systemd controller,  i. e. downsize the current patch? and the other controllers are then handled by pam-cgm?
[06:17] <pitti> bdmurray: I think I see it
[06:52] <pitti> bdmurray: nailed it
[06:58] <hallyn> pitti: that would take care of one case, but it's still possible (right?) that systemd config tell is to create, say, a memory cgroup for the logged-in user
[06:58] <hallyn> pitti: if that's not something we need to support, then heck yeah thta simplifies it a lot
[07:02] <pitti> hallyn: I wouldn't know how this would be configured
[07:02] <pitti> hallyn: and either way, if it would be possible our current patch completely stomps over it, so there's little to regress
[07:03] <hallyn> pitti: ok, cool.  seems like a plan then
[07:19] <hallyn> ok, pushed some untested uncompiled test pkgs to ppa:serge-hallyn/systemd to test that out.  (it's late here :)
[07:24] <seb128> bdmurray, thanks for retracing that ifupdown bug manually, do you know why the retracers didn't work on it?
[07:24] <seb128> pitti, thanks for fixing it
[07:33] <dholbach> good morning
[08:11] <stgraber> hallyn: sounds good. With us getting rid of cgmanager, that's needed anyway.
[08:45] <dgadomski> hey pitti, thanks for updating bug 1337873
[08:46] <pitti> dgadomski: I have the fix now, should be trivial to backport
[08:46] <dgadomski> pitti: do you want me to wait with updating the SRUs until it gets to xenial?
[08:47] <pitti> dgadomski: no, please go ahead
[08:47] <dgadomski> pitti: alright, thanks
[09:10] <pitti> Noskcaj_: hey, how are you?
[09:11] <pitti> Noskcaj_: backuppc needs a merge to unblock perl; I was looking into it, but there are a loooot of direct changes to the code which aren't documented in the changelog :/
[09:11] <pitti> Noskcaj_: do you know what's up with them?
[09:46] <dgadomski> pitti: uploaded new debdiffs to bug 1337873
[10:02] <pitti> dgadomski: can you please attach debdiffs to what's currently in -proposed? the debdiffs you did are against -release/-updates, i. e. they contain the already uploaded changes
[10:03] <dgadomski> pitti: oh, got it, I will fix that soon
[10:14] <dgadomski> pitti: done
[10:19] <LocutusOfBorg> good morning people!
[10:43] <rbasak> mvo: around? I think apt's HTTP pipelining support is buggy.
[10:43] <rbasak> mvo: and that is causing my failure.
[10:43] <rbasak> I have a pcap of apt fetching stuff, complete with its console output of Hash Sum mismatch.
[10:43] <rbasak> For one, it is pipelining on the first request, and apt cannot know that the server supports HTTP/1.1
[10:43] <rbasak> And the requests all respond with 1.0 only, so that's probably why it's broken.
[11:13] <mvo> rbasak: oh? that sounds like its a very likely cause indeed
[11:14] <rbasak> mvo: I'm writing up a bug. I don't think I can really attach my pcap publicly, but I can share with you if needed.
[11:14] <rbasak> mvo: oh, and disabling pipelining worked around the issue.
[11:15] <pitti> dgadomski: uploaded, thanks
[11:15] <mvo> rbasak: cool, I think we don't need the pcap file, your description sounds good
[11:26] <sil2100> Hey guys! Does anyone know where the ppp-modules package comes from?
[11:27] <LocutusOfBorg> sil2100, http://packages.ubuntu.com/xenial/ppp-modules
[11:27] <LocutusOfBorg> I looked at that yesterday
[11:27] <LocutusOfBorg> ppp is stuck :(
[12:01] <rbasak> mvo: FYI, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810796. The workaround is to disable pipelining.
[12:02] <ricotz> doko, hi, I hope you like to take a look at this -- https://launchpad.net/~ricotz/+archive/ubuntu/red/+sourcepub/5955037/+listing-archive-extra -- (the upstream maintainer might do a 2.4.7 in one or two weeks)
[12:06] <rbasak> tdaitx, kickinz1: looks like the freeipmi upload triggered a mini transition of libfreeipmi12 -> libfreeipmi16. Can you decide between you which of you will drive this, please?
[12:08] <mvo> thanks rbasak!
[12:09] <rbasak> mvo: not a problem. "HTTP pipelining is used against HTTP/1.0 servers where it is not permitted, causing download failures" might be a better title.
[12:31] <rbasak> tdaitx: also, what's the status of the squid3 merge? It's been months!
[12:42] <rbasak> kickinz1: I guess tdaitx hasn't started his day yet? Can you make sure to check up with him on who will drive the transition please?
[12:43] <kickinz1> rbasak, yes, I will
[12:47] <tdaitx> kickinz1, feel free to tackle that, I'm working on a openjdk update right now
[12:47] <kickinz1> tdaitx; OK
[12:48] <kickinz1> rbasak, it will be me.
[13:06] <dgadomski> hi, a user is experiencing crashes while trying to launch Unity in rather unusual configuration: in a VM under PowerKVM on ppc64le. I'm guessing the problem is lack of graphics acceleration. Is Unity supported in such configuration? Is it possible to launch Unity without acceleration?
[13:15] <xnox> dgadomski, i would expect such users to contact ubuntu advantage support =)
[13:15] <xnox> dgadomski, unity is launchable without acceleration on some architectures. I cannot comment about ppc64le on powerkvm however.
[13:15] <xnox> it does launch on e.g. Ubuntu KVM on x86_64 without acceleration.
[13:15] <xnox> dgadomski, oh, unless you are ubuntu advantage support yourself....
[13:15] <xnox> =)
[13:15] <dgadomski> xnox: ;) I was hoping somebody here is able to give an official statement
[13:15] <kickinz1> rbasak, what has to be done to 'drive a mini transition of libfreeipmi12 -> libfreeipmi16' ?
[13:15] <kickinz1> rbasak, just asking some pointers while finishing some work before tackling this.
[13:15] <rbasak> kickinz1: follow http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt, documentation in https://wiki.ubuntu.com/ProposedMigration. Right now that says that the following packages become uninstallable: ceilometer-agent-ipmi, ipmitool, nut-ipmi, slurm-client, slurm-client-dbg, slurm-llnl, slurm-llnl-slurmdbd, slurm-wlm, slurm-wlm-basic-plugins, slurm-wlm-basic-plugins-dbg, sl
[13:15] <rbasak> urm-wlm-basic-plugins-dev, slurm-wlm-torque, slurmctld, slurmctld-dbg, slurmd, slurmd-dbg, slurmdbd, slurmdbd-dbg, sview
[13:15] <kickinz1> rbasak: thanks!
[13:15] <rbasak> kickinz1: so find the sources for those binary packages, and see what you need to do to get them to build and depend on libfreeipmi16 instead of libfreeipmi12.
[13:15] <rbasak> kickinz1: in many cases just rebuilding will suffice.
[13:15] <kickinz1> rbasak, OK, thanks.
[13:15] <rbasak> (since it'll build-depend on libfreeipmi-dev or something, and end up linking to the new soname)
[13:15] <rbasak> kickinz1: to generate a source package for a rebuild, the version number gets bumped. You can use "dch -R" to help with that, including to help script it if needed. Probably this one is small enough that it isn't necessary.
[13:16] <rbasak> kickinz1: then in the end you should end up with some debdiffs or source packages to sponsor. Perhaps just plain rebuilds, or perhaps with some other changes necessary to make the build work. This may include sending patches to upstream or Debian etc, but in this case Debian have probably done all the necessary bits so you just need to find it.
[13:16] <rbasak> nacc: ^^ this might be useful for you to follow too, since it'll soon be needed for PHP.
[13:16] <rbasak> Pharaoh_Atem: ^^ you too, maybe?
[13:17] <rbasak> Except with PHP it is 800 source packages or something :-/
[14:49] <gQuigs> is a reverse-recommends enough to keep a package from being autoremoved?   specifically looking at gnome-media package
[14:51] <cjwatson> gQuigs: what kind of autoremoval?
[14:52] <gQuigs> cjwatson: it was removed from debian,  the only previous package that was holding it via depends was gnome, but that's fixed now
[14:52] <cjwatson> gQuigs: it's enough to make us go and look, not necessarily enough to stop us removing it
[14:53] <cjwatson> let's see what process-removals thinks
[14:56] <gQuigs> also curious if swac-get comes up on that list
[14:56] <gQuigs> thanks!
[14:57] <cjwatson> gQuigs: for autoremoval?  it's still in unstable ...
[14:59] <gQuigs> well.. oops
[15:00] <gQuigs> nvm on that
[15:15] <ondrej> rbasak: I uploaded a share of PECL extensions updated to PHP 7.0 to Debian unstable; but I guess they'll sit in NEW now since I changed s/php5/php/ in binary package names
[15:15] <ondrej> rbasak: git repos for those should have been updated as well, if you want to start poking before NEW is processed
[15:17] <rbasak> ondrej: thanks!
[15:18] <rbasak> nacc: ^^
[15:18] <rbasak> ondrej: I'm struggling to coordinate with nacc and Pharaoh_Atem a little.
[15:18] <rbasak> ondrej: but we have able and willing people to help now. Just need to help them along.
[15:23] <Son_Goku> rbasak & ondrej: hopefully the list from Remi Collet should help some in identifying upgrades to most extensions for php7 compliance
[15:34] <seb128> cyphermox, did you see bug  #1531779?
[15:35] <cyphermox> oops
[15:36] <hallyn> stgraber: could everyone stop celebrating getting rid of cgmanager? :)  you're going to miss 'cgm create'
[15:40] <cjwatson> gQuigs: ok, it's gone now, thanks for the heads-up
[15:40] <gQuigs> cjwatson: thanks!
[15:44] <nacc> rbasak: ondrej: thanks!
[15:56] <seb128> Laney, do you know how to debug things like https://errors.ubuntu.com/problem/a3dac922f46ca43928d3a96970531c1678cdf316 ?
[15:57] <seb128> "Setting up libxrandr2 (amd64 (2) 1.5.0-1) ... dpkg → dependency problems prevent configuration of libgtk-3-bin → libgtk-3-bin depends on libgtk-3-0 (>= 3.18.6-1ubuntu1); however → Package libgtk-3-0 → amd64 is not configured yet. libgtk-3-bin depends on libgtk-3-common (>= 3.18.6-1ubuntu1); however → Package libgtk-3-common is not configured yet. dpkg → error processing package libgtk-3-bin (--configure) → dependency
[15:57] <seb128>  problems - leaving unconfigured"
[15:58] <nacc> rbasak: have time to chat today?
[15:58] <Laney> seb128: more log would be better
[15:59] <seb128> Laney, unsure how to get those :/
[15:59] <Laney> turn launchpad apport bugs back on and wait for one :/
[15:59] <Laney> otherwise it seems to happen in a dist-upgrade so maybe try that
[16:00] <seb128> https://errors.ubuntu.com/problem/477ffe82ea6059aa20b022e13890b6e0abea7d94 is another similar one on adwaita/h-i-t
[16:01] <rbasak> nacc: yes please. How about after the IRC meeting?
[16:02] <Son_Goku> rbasak: are we going to have a hangout sometime today?
[16:02] <bdmurray> seb128: I'll look into that today.
[16:02] <nacc> rbasak: sounds good
[16:04] <seb128> bdmurray, thanks
[16:09] <rbasak> Son_Goku: yes, we should try to do that today.
[16:10] <rbasak> Son_Goku: what happened to Pharaoh_Atem?
[16:10]  * rbasak is confused
[16:10] <rbasak> Are you the same person?
[16:10] <Son_Goku> yes
[16:10] <Son_Goku> I’m on my laptop atm
[16:10] <Son_Goku> c.f.: https://launchpad.net/~ngompa13
[16:10] <dobey> rbasak: he went sayan
[16:10] <Son_Goku> :)
[16:10] <Son_Goku> Pharaoh_Atem is my workstation at my office
[16:11] <Son_Goku> Son_Goku is my personal laptop
[16:11] <rbasak> Ah, OK
[16:11] <Son_Goku> all of my nicks are listed on my launchpad profile
[16:11] <Son_Goku> so, you’ll always know who I am :)
[16:12] <LocutusOfBorg> Son_Goku, I want to see your karma increase, and then say "it is over 9000!!!"
[16:12] <Son_Goku> haha
[16:13] <Son_Goku> I tried to make it go up years and years ago
[16:13] <Son_Goku> but it stubbornly stuck at 5
[16:13] <Son_Goku> so I gave up on it
[16:13] <Son_Goku> I suppose it doesn’t help that most of my work involved actually working in upstream projects
[16:13] <Son_Goku> those don’t count in launchpad karma :(
[16:14] <Son_Goku> even if you add references to things like rhbz, etc.
[16:20] <LocutusOfBorg> hi, anybody there for a qt question?
[16:20] <LocutusOfBorg> I think we have a big problem on emulated powerpc machines
[16:20] <cjwatson> emulated in what way?
[16:21] <LocutusOfBorg> http://paste.ubuntu.com/14478746/
[16:21] <LocutusOfBorg> this was a mail private
[16:21] <LocutusOfBorg> the package is dspdfviewer
[16:21] <cjwatson> is that qemu-user or qemu-system?
[16:21] <LocutusOfBorg> maybe trying the powerpc build in a real machine might help
[16:21] <LocutusOfBorg> cjwatson, it is also the powerpc ubuntu build
[16:21] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/dspdfviewer/1.14-1/+build/8407197
[16:22] <cjwatson> fisher* and denneed* are qemu-based, yes.  I'm pretty sceptical, but I'll try it on sagari just in case
[16:22] <cjwatson> It seems more likely to be due to being POWER7-based, though
[16:22] <cjwatson> sagari is err POWER5 or POWER6?  I forget
[16:22] <LocutusOfBorg> what does it matter? I mean, why qt4-demos are showing bad colours?
[16:23] <LocutusOfBorg> isn't this an endianess issue? and how can endianess change on powerpc?
[16:23]  * LocutusOfBorg has always headaches when it comes to understand endianness
[16:23] <cjwatson> powerpc is always big-endian
[16:23] <LocutusOfBorg> exactly, so how it can be a problem in ubuntu and not in debian?
[16:24] <cjwatson> you have not proven that it is an endianness issue though
[16:24] <LocutusOfBorg> "ff000000 (as in, opaque black) becomes 000000ff (as in, transparent"
[16:24] <cjwatson> sure, it certainly looks like it
[16:24] <LocutusOfBorg> quoting the email
[16:24] <cjwatson> but until you've actually done a root cause analysis you don't know
[16:24] <LocutusOfBorg> and also the qt4-demos issue, at least I can say the end user application seems to be correct
[16:25] <cjwatson> it could be for instance that Ubuntu's Qt has an endianness bug that Debian's doesn't
[16:25] <cjwatson> or all kinds of things like that
[16:25] <LocutusOfBorg> exactly, I was thinking something like that
[16:25] <LocutusOfBorg> for sure seems that the testsuite was correct at the end
[16:25] <LocutusOfBorg> now I'm setting up some pbuilder powerpc environment
[16:25] <cjwatson> I wouldn't waste your time trying with something based on qemu-user-static
[16:26] <LocutusOfBorg> oh ok
[16:26] <cjwatson> qemu-user can't deal with threads at all reliably so it tends to be a hopeless pile of failure with anything Qt-related
[16:26] <cjwatson> (fisher* and denneed* are qemu-system on POWER7 hardware)
[16:34] <cjwatson> LocutusOfBorg: I'm assuming that the pbuilder business from the email you quoted was running on x86; in that case there's necessarily an endian-flip going on with qemu-user, and certainly room for error there.  But we're not emulating powerpc on x86
[16:34] <cjwatson> This is why I was asking whether you were talking about qemu-user or qemu-system
[16:35] <cjwatson> LocutusOfBorg: Anyway, it fails on sagari (bare metal) too: https://launchpad.net/ubuntu/+source/dspdfviewer/1.14-1/+build/8407197
[16:35] <cjwatson> Or indeed https://launchpadlibrarian.net/233933347/buildlog_ubuntu-xenial-powerpc.dspdfviewer_1.14-1_BUILDING.txt.gz
[16:35] <cjwatson> LocutusOfBorg: So that rules out qemu IMO
[16:36] <LocutusOfBorg> ok it leaves a qt4 issue?
[16:37] <cjwatson> LocutusOfBorg: Or anything else in the build-dependency chain (perhaps even including the kernel).
[16:37] <rbasak> Son_Goku, nacc: shall we try for a Hangout in about twenty minutes (on the hour, 1700 UTC)?
[16:37] <cjwatson> LocutusOfBorg: Needs direct debugging, I expect.
[16:37] <Son_Goku> rbasak: sure
[16:37] <rbasak> Son_Goku: shall I send an invite to your work address?
[16:37] <rbasak> ondrej: would you like to join us?
[16:37] <cjwatson> LocutusOfBorg: That said, now that I've noticed that the person you were talking to said they could reproduce it in pbuilder, maybe this particular case doesn't run into the usual qemu-user threading bugs and you can attack it that way after all.
[16:37] <Son_Goku> I’m about to head to work, so I should be available as Pharaoh_Atem by then
[16:37] <Son_Goku> I’ll ping you when I get there
[16:37] <Son_Goku> send to my personal one
[16:38] <rbasak> OK
[16:38] <rbasak> Son_Goku: uh,
[16:38] <rbasak> Son_Goku: which is your personal one?
[16:38] <Son_Goku> rbasak: ngompa13@gmail.com
[16:38] <rbasak> OK
[16:39] <nacc> rbasak: sounds good
[16:39] <rbasak> Son_Goku, ondrej: invites sent. You should have an email with a link.
[16:40] <LocutusOfBorg> thanks cjwatson we will continue investigating
[16:40] <rbasak> (nacc too but I assume he knows the drill)
[17:22] <Son_Goku> rbasak: https://git.launchpad.net/~nacc/+git/php7tracking/tree/package-list.rdepends.src.split.working
[17:26] <rbasak> Son_Goku: http://packages.ubuntu.com/wily/mythtv
[17:36] <rbasak> Son_Goku: https://launchpad.net/ubuntu/+source/php-pecl-http
[17:37] <rbasak> https://sources.debian.net/src/php-pecl-http/2.0.4-1/
[17:37] <rbasak> https://sources.debian.net/src/php-pecl-http/2.0.4-1/debian/control/
[17:41] <smoser> jibel, https://code.launchpad.net/~canonical-platform-qa/ubuntu-test-cases/server-preseed/+merge/282346
[17:41] <smoser> did you test the change? does it actually fix ?
[17:43] <bdmurray> seb128, pitti: it was considered failed b/c the retraced report had no SAS.
[17:45] <seb128> bdmurray, because not enough functions in the bt?
[17:48] <bdmurray> seb128: it has more than 2 lines in the StacktraceTop ... still digging
[17:49] <seb128> k
[17:52] <jibel> smoser, Max tested it and said it fixed the issue. But reading your comment and bug 1355845, I'll ask him to confirm.
[17:53] <smoser> we should open a bug on d-i too
[17:53] <smoser> that is a questionable behavior.
[17:54] <jibel> smoser, I opened bug 1533243, not sure if the behaviour is expected or not
[17:54] <cjwatson> smoser: partman-base is a d-i component; it's not necessary or helpful to open additional bugs against d-i itself
[17:54] <rbasak> ondrej: do you know if we need to care about swig at all? Is there anything packaged in the PHP world that uses swig?
[17:54] <smoser> thanks.
[17:55] <cjwatson> (at least assuming that 1355845 describes the same behaviour)
[17:56] <smoser> so move https://launchpad.net/bugs/1533243 to partman ?
[17:56] <rbasak> Son_Goku: nacc: http://pad.ubuntu.com/php-transition
[17:56] <cjwatson> reassigned
[17:58] <rbasak> Son_Goku: https://launchpad.net/~ubuntu-etherpad
[18:03] <infinity> cjwatson: I'd say the dspdfviewer thing is almost certainly an endian bug, given identical test failures on s390x.
[18:04] <infinity> (Where the bug lies is an entirely different question)
[18:04] <Son_Goku> rbasak: https://github.com/swig/swig/issues/571
[18:05] <infinity> Well, could also be ibm long double, I suppose.  But they're definitely some Bad Math at play.
[18:05] <infinity> s/they're/there's/ ...
[18:05]  * infinity stares at his fingers.
[18:06] <cjwatson> infinity: Yeah, doesn't really help establish where it is given that Debian apparently doesn't do it, but I guess just a bug in some dep
[18:06]  * infinity nods.
[18:08] <seb128> Noskcaj_, could you look at the blueman issues on top of e.u.c/xenial since you did the update?
[18:26] <ondrej> rbasak: don't remember anything that uses swig (but my memory is limited to children night time stories these days...)
[18:27] <rbasak> ondrej: we found owfs, but nothing else. We haven't looked exhausively.
[18:28] <rbasak> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810084
[18:30] <Unit193> Pity.
[18:32] <ondrej> rbasak: I guess a lot of unmaintained software will habe to go
[18:32] <rbasak> ondrej: yes, I think so.
[18:39] <rbasak> ondrej: what's your timezone? Europe?
[18:41] <rbasak> ondrej: nacc is in UTC-8, so what's the latest you'd be happy to do a hangout?
[18:42] <rbasak> I think it would be useful to coordinate. We've more or less understood each other now I think, but would like some input from the Debian perspective so we don't end up just duplicating everything in Ubuntu instead of getting things into Debian and syncing.
[18:44] <nacc> ondrej: would appreciate your guidance on what all is changing (or already changed) in pkg-php-tools in Debian to be php7.0 compatible; and if/how I can help
[18:44] <rbasak> Son_Goku: http://anonscm.debian.org/cgit/pkg-php/php.git/tree/tests
[18:47] <rbasak> Son_Goku: http://anonscm.debian.org/cgit/pkg-php/php.git/tree/debian/tests?h=master-7.0
[19:10] <rbasak> https://wiki.debian.org/PackageTransition
[19:13] <sarnold> that's awesome
[19:14] <sarnold> that kind of distilled knowledge used to take hours of policy reading before getting started and even then it was too easy to make mistakes :)
[19:17] <nacc> sarnold: that's what we're discussing currently on our hangout
[19:17] <sarnold> heya nacc :)
[19:18] <nacc> sarnold: hey :)
[19:18] <infinity> rbasak: As for swig and php, I see a lot more than just one package...
[19:18] <nacc> infinity: we found one so far that actually lists the dep in the control file ... but not done exhaustively searching
[19:18] <rbasak> infinity: how are you seeing? We haven't really looked yet.
[19:19] <nacc> infinity: which ones did you find/how did you search?
[19:19] <infinity> http://paste.ubuntu.com/14480022/
[19:19] <infinity> rbasak, nacc: ^
[19:20] <nacc> infinity: thanks, will look into those/append to our php7 list
[20:05] <jtaylor> infinity: do you know if glibc 2.22 will still make it into xenial?
[20:07] <infinity> jtaylor: Yes, it'll be in this week, probably, and 2.23 a month or so later.
[20:07] <jtaylor> ah great :D
[20:08] <infinity> pitti: Thanks for the ifquery crash fix!
[20:08] <infinity> pitti: I was seeing that on the s390x buildds on boot and couldn't decide if it was s390-specific or what (and didn't have time to investigate).
[20:42] <infinity> stgraber: You know what's up with lxc adt tests?  Need an RT to poke some firewall holes?
[20:42] <infinity> stgraber: (or some proxy magic)
[23:39] <bdrung> cjwatson, can you merge the new devscripts version?