[05:23] <teward> LocutusOfBorg: i think you broke nginx builds for the forseeable future with the latest upload in Debian from the 25th-27thish which was autosynced to Bionic
[05:34] <teward> because luajit isn't detected in amd64, armhf, or i386 for Bionic (relevant excerpt from build logs is this: http://paste.ubuntu.com/25972405/)
[05:50] <teward> confirmed: it's broken.
[05:51] <Unit193> \o/
[05:57] <teward> and now I have to make a decision for nginx-extras: drop Lua module, or switch to the much less fun full Lua libraries instead of libluajit, and further diverge from Debian.  Again.
[06:04] <rbasak> Does nginx-extras have to be in main?
[06:04] <teward> rbasak: it's not.
[06:04] <teward> it's in Universe.
[06:05] <teward> but an FTBFS on nginx-extras means nginx-core never lands
[06:05] <teward> because the source package has a component FTBFS
[06:05] <rbasak> I see
[06:05] <teward> refer to #u-release
[06:05] <teward> because i have a small minirant there
[06:06] <teward> rbasak: and I just confirmed this happens with 1.12.x that's in bionic now, if someone triggered a rebuild it'd explode in all our faces
[06:06] <teward> and the only thing that is failing is luajit currently, and only on amd64, armhf, and i386
[06:06] <teward> works *fine* on arm64 and ppc64el
[06:06] <teward> but not the three big ones.
[06:06] <teward> confirmed in local schroots and PPA builds
[06:07] <rbasak> Do you know what luajit upload caused the regression?
[06:07] <teward> rbasak: debian autosync
[06:07] <rbasak> OK, but what Debian upload caused the regression?
[06:08] <tsimonq2> rbasak: I'm asking the same questions in #u-r ;)
[06:09] <teward> which is why we should specifically pick one channel or the other
[10:53] <doko> jbicha: who synced that? ;p
[11:19] <jamespage> coreycb: ok content of PPA published to bionic-proposed; os-service-types is in the NEW queue.
[11:19] <jamespage> coreycb: the issue I'm hitting in neutron is todo with eventlet - https://github.com/eventlet/eventlet/issues/147
[12:20] <m_tadeu> hi...I'm trying to use SIGUNUSED by #include <signal.h>....this works ok in 16.04 but not on 17.10...any ideas?
[12:21] <LocutusOfBorg> m_tadeu, the idea is to stop using it I guess
[12:21] <LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875927
[12:21] <LocutusOfBorg> here you have some references to its removal
[12:22] <m_tadeu> LocutusOfBorg: thanks for the info
[12:22] <LocutusOfBorg> yw
[13:35] <coreycb> jamespage: ack
[13:45] <TJ-> advice request for 1710 re: nsswitch - got a user with valid /etc/hostname and /etc/hosts where sudo hangs (trying to resolve hostname when not network connected) Narrowed it down to nsswitch preferring IPv6 and no separate entry in /etc/hosts for the hostname. That's fixed, but in investigating noticed that "getent ahosts $(hostname)" returns IPv4 localhost IP addresses but not the hostname, where as
[13:45] <TJ-> the IPv4 specific "getent ahostsv4 $(hostname)" returns the hostname - is this expected or a bug?
[13:48] <coreycb> jamespage: are you planning to upload remaining packages directly to bionic or still use the ci-train ppa/
[13:48] <coreycb> ?
[14:28] <jamespage> coreycb: hmm
[14:28] <jamespage> coreycb: I might do the neutron ones together once we have the unit testing issues sorted
[14:29] <jamespage> coreycb: but the other leaf packages could go direct
[14:29] <coreycb> jamespage: that would make sense
[14:29] <jamespage> coreycb: I started on swift but need to fix eventlet
[14:29] <coreycb> jamespage: ok
[14:31] <jamespage> coreycb: zigo is hitting the same issue with neutron@pike into debian unstable; something in the dep chain is causing the problem
[14:31] <jamespage> coreycb: we're still ok in artful so I'm trying to bisect exactly what's going on
[14:32] <coreycb> jamespage: ack
[14:32] <jamespage> coreycb: the stacktrace is misleading - its a bug, but not the direct cause of the problem
[14:41] <doko> coreycb: who usually cares about mysql?
[14:41] <coreycb> jamespage: i think the server team usually manages that
[14:41] <coreycb> jamespage: sorry that was meant for doko
[14:41] <jamespage> hehe
[14:42] <jamespage> doko: rbasak
[14:44] <doko> rbasak: please could you have a look at ruby-mysql2? the debian/start_mysqld_and_run.sh needs some modernization
[14:57] <rbasak> doko: Skuggen (Oracle; not here) should be able to look at that I think. I filed https://bugs.launchpad.net/ubuntu/+source/ruby-mysql2/+bug/1732710.
[15:03] <doko> ta
[15:04] <rbasak> doko: hang on
[15:04] <rbasak> doko: looks like you dropped the patch that was already there that fixes this.
[15:04] <rbasak> doko: what were you trying to do?
[15:06] <doko> wait ...
[15:07] <doko> rbasak: ahh, my bad. will reapply
[15:07] <rbasak> Thanks.
[15:07] <rbasak> OOI, why are you jumping ahead of Debian on this package? Is it needed for Ruby maybe?
[15:10] <doko> rbasak: seeing bus errors in the autopkg tests on armhf
[15:10] <doko> so nothing what debian will see ... and fix
[15:11] <rbasak> I see. Thanks.
[15:33] <juliank> cjwatson: katie/archive robot synced gsmartcontrol 1.1.1-1 from debian, updating from 1.0.2-1. There was an 1.1.0-1 in debian in between those two. It then closed bug 1713311 as that was fixed in the skipped release, but only had the top-entry in the comment.
[15:34] <juliank> Sounds a bit weird
[15:34]  * juliank thinks that's kind of your thing
[15:37] <cjwatson> juliank: sounds deliberate - in at least some situations LP deliberately reconstructs things from the changelog
[15:37] <cjwatson> juliank: oh, the comment in the bug is non-ideal I suppose
[15:38] <juliank> yeah, the comment was confusing
[15:41] <sladen> madigens: ping
[15:41] <sladen> madigens: emailed a few hours ago.  Probably too late for me to leave now
[15:41] <cjwatson> juliank: Looks like https://bugs.launchpad.net/launchpad/+bug/1385660
[15:41] <cjwatson> juliank: Bit much for me to tackle just at the moment though, I'm afraid
[15:42] <juliank> cjwatson: Well, at least you found a bug report :)
[15:42]  * juliank subscribed
[15:43] <cjwatson> If anyone wants to dig, lib/lp/soyuz/model/processacceptedbugsjob.py is probably the place to start
[15:44] <cjwatson> The problem is probably something like that close_bugs_for_sourcepackagerelease does a since_version check for bug_ids but doesn't then pass that information down to close_bug_ids_for_sourcepackagerelease
[15:45]  * cjwatson braindumps briefly into the bug
[15:49] <madigens> sladen: just came back from work
[16:26] <elopio> infinity: hey, do you know who can release this? https://code.launchpad.net/~elopio/ubuntu-motd/appreciation/+merge/333552
[16:27] <infinity> elopio: kirkland
[16:28] <elopio> kirkland: ping :)
[16:41] <scientes> I can't get my program which calls gettext() to look for translations
[16:41] <scientes> checking via strace
[16:43] <coreycb> jamespage: https://github.com/openstack/requirements/commit/daa2bedb1ed5ff48c6d95cdc0c6f02fcf68d9089
[16:43] <coreycb> jamespage: i'd like to see if we can reject python-oslo.serialization 2.21.2-0ubuntu1 from bionic-proposed and upload 2.21.1 instead
[16:44] <coreycb> jamespage: or, we could just hold off on glance uploads
[16:46] <scientes> I read the gettext manual
[16:46] <bdmurray> niedbalski: Do you agree with cpaelzer about bug 1729858?
[17:03] <jamespage> coreycb: neutron bits going to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3043/+packages first
[17:07] <jamespage> coreycb: hmm - alot of the networking-* projects have missing release tarballs?
[17:07] <jamespage> does that ring bells? I see you did some already
[17:18] <coreycb> jamespage: i noticed some missing tarballs but didn't look into it
[17:18] <coreycb> jamespage: just skipped for now
[17:18] <coreycb> jamespage: so i think we can just hold off on uploading glance until a fixed oslo.serialization comes out, since all the other pkgs were build with 2.21.2
[17:19] <jamespage> coreycb: ok sounds sensible
[17:19] <sil2100> bdmurray: hey, doing SRU reviews now?
[17:22] <sil2100> bdmurray: I'd like to tackle some queue reviews later today as well - if you have a moment, could you take a look at the zesty and xenial livecd-rootfs SRUs in the queues? Those are now good for review as we got the old zesty one released finally (thanks to Tribaal!)
[17:22] <bdmurray> sil2100: I've made a note of it
[17:23] <acheronuk> oSoMoN: hi. I notice you upload Libreoffice. do you anticipate Libreoffice 6 getting into Bionic if it's out on schedule?
[17:25] <sil2100> bdmurray: thanks
[17:30] <jbicha> acheronuk: we've always taken the Libreoffice releases since LibreOffice's release schedule is based on making it easy for Ubuntu
[17:30] <acheronuk> jbicha: didn't know that. thanks
[17:35] <oSoMoN> acheronuk, yes, according to libreoffice's release plan, 6.0 should be in bionic
[17:37] <acheronuk> oSoMoN: great. I ask as that should have the first release of the Qt5 VCL plugin, meaning we (Kubuntu) can get rid of the old KDE4 one, and maybe have all KDE4 stuff off our iso
[17:37] <acheronuk> thx
[18:06] <kirkland> elopio: done
[18:06] <kirkland> infinity: actually, anyone on ~ubuntu-motd can commit/push
[18:07] <elopio> kirkland: thank you! You have my appreciation :)
[18:08] <elopio> wait, I
[18:08] <kirkland> elopio: ;-)  np
[18:08] <elopio> 'm confused. The MR is still open.
[18:15] <elopio> I see it now, great!
[18:51] <bdmurray> sil2100: How is bug 1731492 fixed in more current releases?
[18:51] <bdmurray> or Tribaal ^^
[18:52] <Tribaal> bdmurray: it isn't AFAIK
[18:52] <Tribaal> bdmurray: you mean for zesty and artful?
[18:53] <bdmurray> Tribaal: and that bionic release too.
[18:54] <Tribaal> bdmurray: I think bionic was covered by https://code.launchpad.net/~vorlon/livecd-rootfs/minimize-round-two/+merge/332529 ?
[18:56] <Tribaal> bdmurray: there is no incentive to add those minimization changes to z and a AFAIC - so I backported only to Xenial (since that's where the changes were actually needed). Is that the wrong approach?
[18:58] <slangasek> yes, it landed in livecd-rootfs 2.482; closing the trunk bug task with this explanation saves questions
[18:59] <nacc> Tribaal: i think it's more what slangasek just said -- the bug does not indicate it's fixed in the development release -- and there could be tasks for a and z that say won't fix, perhaps (with a bug comment)?
[18:59] <slangasek> he doesn't have privs to open the tasks to mark them wontfix
[18:59] <Tribaal> right, I was going to say just that :)
[18:59] <nacc> slangasek: ah
[18:59] <nacc> can still nominate, though, right?
[19:00] <bdmurray> Isn't Tribaal an upstream developer of livecd-rootfs?
[19:00] <nacc> (or put in a comment, i guess, that's what i've asked other contributors to do inn the past)
[19:02] <Tribaal> I guess I should apply for the bug squad
[19:03] <bdmurray> Tribaal: If you are an upstream developer there is a way to join the Ubuntu Bug Control team.
[19:05] <Tribaal> well, I applied for the bug squad anyway :)
[19:06] <nacc> heh
[19:18] <jbicha> bdmurray: hi, did you see the software-properties autopkgtest failures on artful and bionic?
[19:18] <jbicha> it doesn't look like it's gtk3's fault so it would be nice to get the gtk3 update in to artful to fix LP: #1720400
[19:29] <bdmurray> Tribaal: bug squad won't give you any permissions though
[19:32] <Tribaal> bdmurray: well, I'll just have another badge then :) SO nominating for ubuntu releases stems from what? either per-project "upstream" status or Ubuntu Developer for "accross the board" nominations?
[19:33] <bdmurray> Tribaal: members of Ubuntu Bug Control can nominate a bug for fixing in a release. Ubuntu Developers can accept or directly add those tasks if they can upload the package.
[19:34] <Tribaal> bdmurray: ahh that clears it up some, thanks.
[19:35] <Tribaal> bdmurray: then the bug squad still seems to be a good place where I can help in the grant scheme of things - just not for this particular case :)
[20:17] <doko> jbicha: gtk-doc ftbfs in bionic, otoh I see build failures because gtk-doc is not recent enough. could you have a look?
[20:19] <doko> hmm, builds locally
[20:19] <jbicha> I was confused by it too
[20:19] <jbicha> what fails to build because of older gtk-doc?
[20:23] <doko> hmm, closed the tab in the browser
[20:28] <doko> jbicha: hmm, failed again on the buildd
[20:35] <jbicha> bdmurray: thanks again :)