[00:06] <nacc> bdmurray: re: LP: #1667150 and LP: #1666687, do you want me to add delta that drops those to suggests?
[00:06] <ubottu> Launchpad bug 1667150 in twitter-bootstrap3 (Ubuntu) "[MIR] twitter-bootstrap3" [Undecided,Incomplete] https://launchpad.net/bugs/1667150
[00:06] <ubottu> Launchpad bug 1666687 in jxrlib (Ubuntu) "[MIR] jxrlib" [Undecided,Incomplete] https://launchpad.net/bugs/1666687
[00:07] <bdmurray> nacc: I don't really have an opinion / haven't looked into much.
[00:08] <nacc> bdmurray: ok
[00:25] <nacc> jbicha: hrm, seems like newpid to install failed on armhf; i wonder if it's because of lxd?
[00:26] <nacc> jbicha: yep, it also fails locally on lxd
[00:26] <nacc> slangasek: is it possible to require virtualization of a test runner? otherwise, i think this testcase can't pass on armhf (postgresql-plproxy uses newpid)
[00:28] <slangasek> nacc: I think that's spelled machine-isolation
[00:28] <nacc> slangasek: err, right!
[00:28] <slangasek> nacc: which will cause this test to be skipped for armhf since those are not currently available as runners
[00:28] <nacc> stgraber: --^ were you aware of this issue? newpid (pkg) doesn't install under LXD
[00:28] <nacc> slangasek: ack, will update the restriction
[00:28] <slangasek> nacc: but if you think it's a lxd bug, maybe we should override the failure instead?
[00:29] <nacc> slangasek: i'm not sure if it is or not -- i'll see what stgraber says before uploading
[00:29] <nacc> slangasek: thanks!
[00:39] <stgraber> nacc: it's attempting to set fs capabilities, that's not supported inside user namespaces by the kernel
[00:40] <stgraber> nacc: most other packages fallback to setuid when that happens (ping for example)
[00:40] <stgraber> we also have a kernel fix for this but it's not been merged mainline yet
[00:42] <stgraber> hallyn wrote the patch and has been trying to get it merged upstream for a while now
[00:50] <nacc> stgraber: ok, what would you recommend we do on armhf? it feels like a packaging issue in newpid really?
[00:52] <nacc> but if we are going to rely on newpid and newpid is known to not install in userns, then it seems like machine-isolation is an ok solution for now
[00:52] <stgraber> nacc: why do you rely on newpid in the first place?
[00:53] <nacc> stgraber: this test uses the `newnew` utility
[00:53] <nacc> stgraber: i err, newnet
[00:53] <stgraber> how about just changing the test to use unshare instead which comes from util-linux
[00:53] <nacc> stgraber: i can do that, let me see ... s/netnew/unshare -n/ ?
[00:53] <stgraber> I have no idea why someone even wrote newpid/newnet when util-linux provides a tool which does all of that and has done for years...
[00:54] <stgraber> nacc: yup
[00:55] <nacc> stgraber: thanks, testing
[01:00] <nacc> stgraber: thanks seems to work!
[01:02] <nacc> jbicha: --^ so that will need to build and then run through
[01:06] <nacc> is this a case of just retry on armhf? " unable to install updated status of 'python-minimal': No space left on device"
[01:35] <nacc> yep, it was, succeeded on retry
[02:44] <hallyn> newnet?
[05:41] <memeka> can anyone help with this: https://paste.ubuntu.com/24088463/ ?
[06:48] <Unit193> mvo: Did you ever see LP 643623?
[06:48] <ubottu> Launchpad bug 643623 in ubuntu-keyring (Ubuntu) "Should ubuntu-keyring include the debug archive key?" [Undecided,Confirmed] https://launchpad.net/bugs/643623
[07:22] <mvo> Unit193: I have not seen this bug, no. I think its a valid request
[07:24] <Unit193> mvo: Great, I think with Debian moving more towards dbgsym packages, would be great if apt-setup created that, commented out, in sources.list by defaul too.  I plan to file that bug after this gets closed.
[07:25] <sarnold> Unit193: have you seen clear linux's debug symbol server thing? "all the symbols" sitting there waiting for FUSE to read them.. I fear find and rsnapshot etc but it sure would be convenient..
[07:26] <Unit193> sarnold: No, I have no idea what that is.
[07:26] <Unit193> s/that is/their setup/
[07:26] <sarnold> hrm, a bit short https://clearlinux.org/features/all-debug-information-all-time
[07:29] <Unit193> Not sure I like a fuse mount to a remote server on all the time, but that's certainly pretty cool.
[07:29] <sarnold> yeah it feelsl ike something you'd really want to turn o nwhen you want it
[07:30] <sarnold> maybe with a -t3600 or something so you don't forget to turn it off again :)
[07:30] <Unit193> Wonder how that affects df calls.
[07:33] <sarnold> hopefully the right thing, the fuse filesystem apparently can hook that http://libfuse.github.io/doxygen/fuse__lowlevel_8h.html#aa1d95ec3ca674253baac3639ea10f0ff
[07:40] <Unit193> I have df (with --local, which fuse ignores) in my bashrc, slowdowns are fun.
[08:58] <cpaelzer> Odd_Bloke: smoser: no expectign that the latter is awake, could you take a look at bug 1668876
[08:58] <ubottu> bug 1668876 in simplestreams (Ubuntu) "Yakkety daily image (1st March) sync broken" [Undecided,New] https://launchpad.net/bugs/1668876
[08:59] <cpaelzer> TL;DR assumption daily yakkety images of this night don't match metadata (size/checksums)
[09:04] <cpaelzer> I tried from a lab and from home and both match, but if anyone else could try the wget/sha256 or the sync command I listed in the bug - just to see if there are any proxy/caching things different around the world
=== JanC is now known as Guest86538
=== JanC_ is now known as JanC
[12:08] <javier4> I got this error trying to cross-compile wpa for armhf on a x86_64 host.
[12:08] <javier4> "/usr/include/qt4/QtCore/qatomic_armv5.h:131: Error: no such instruction: `swpb %al,%bpl,[%rbx]'"
[12:09] <javier4> Reading online it seems to be due to an incorrect setup of qmake. In particular it seems to not find the arm toolchain.
[12:10] <javier4> I'm totally ignorant in QT developing. The only file that I think could be a config for qmake is the wpa_gui.pro that qmake should use to generate its makefile.
[12:10] <javier4> https://www.irccloud.com/pastebin/ni0ymJpB/
[12:11] <javier4> Should I modify it someway?
[12:28] <rbasak> jbicha: around? About bug 1571816. Did 1:1.6.2-0ubuntu14.2 actually achieve anything then? If not, I'm not sure we should be releasing it.
[12:28] <ubottu> bug 1571816 in wine-development (Ubuntu Yakkety) "Gnome Software catalog entry missing for Wine" [Medium,Fix committed] https://launchpad.net/bugs/1571816
[12:29] <jbicha> rbasak: before the update, wine1.6 does not show in gnome-software at all, after the update it shows as "Configure Wine" which while odd is still an improvement
[12:30] <jbicha> see also my last comment on bug 1639507
[12:30] <ubottu> bug 1639507 in unity-control-center (Ubuntu Yakkety) "unity-control-center in installed software is listed with wrong icon and title" [Medium,Fix committed] https://launchpad.net/bugs/1639507
[12:31] <rbasak> jbicha: I'm dubious about that as a justification, because users still have to download tons of updates, and I think I'd prefer to know and confirm the full fix. But separately from that, I'm questioning "Set X-AppStream-Ignore=true" specifically between 1:1.6.2-0ubuntu14.1 and 1:1.6.2-0ubuntu14.2, which AFAICT didn't do anything?
[12:31] <jbicha> all the other parts of 1571816 work correctly (wine-development on xenial and yakkety and wine/yakkety)
[12:34] <rbasak> jbicha: so to be clear, 1) I appreciate that it works incrementally after the update, though I'm not sure that's enough so that's one question; and 2) is the update actually minimal, because of the effectively no-op X-AppStream-Ignore change?
[12:34] <jbicha> right, 14.2 had no effect :( it might be needed if we fix gnome-software but I don't know
[12:35] <rbasak> jbicha: I appreciate you driving this. Though IMHO, the bug isn't severe enough to warrant landing a half fix.
[12:35] <rbasak> I appreciate it's subjective though. Other ~ubuntu-sru may disagree and I'm fine with that.
[12:36] <jbicha> the x-appstream-ignore change is probably correct though, it was flagged as an issue on http://appstream.ubuntu.com/xenial-proposed/universe/issues/wine1.6.html
[12:36] <jbicha> that page doesn't exist now because it was fixed in -proposed but this still does
[12:36] <jbicha> http://appstream.ubuntu.com/xenial/universe/issues/wine1.6.html
[12:36] <rbasak> jbicha: sure, but probably correct isn't enough for an SRU.
[12:37] <rbasak> jbicha: I'd prefer to see definitely verified correct with a real user impact confirmed resolved.
[12:37] <rbasak> jbicha: but, I think the Yakkety bits do work, right?
[12:37] <jbicha> yes, the other 3 packages work fine; it's just wine1.6/xenial that's half fixed
[12:38] <jbicha> I think the 2 biggest packages left that people complain about not showing in Software are steam (non-i386) and wine
[12:39]  * rbasak is still sorting out his understanding of which pieces do what
[12:40] <jbicha> until yakkety, Ubuntu had wine1.6 which was fairly separate from Debian's wine packaging
[12:40] <jbicha> Debian has wine and wine-development which are the same except wine-development is a newer ("less stable") version
[12:41] <jbicha> Debian's packaging doesn't have any .desktops so it's not affected by the "gnome-software picking a random .desktop instead" bug
=== hikiko is now known as hikiko|ln
[12:47] <rbasak> jbicha: is "Fix Committed" correct for wine1.6's development task? Or should that be Invalid?
[12:47] <rbasak> Hmm. wine1.6 is still in Zesty?
[12:49] <jbicha> wine1.6 is just a transitional package in 16.10+
[12:49] <rbasak> OK, so Invalid?
[12:50] <jbicha> if you want; I just had it set to the same status as xenial
[12:51] <rbasak> jbicha: OK thanks. wine1.6 for Xenial hasn't aged enough anyway. The others look fine to accept. Personally I'd hold wine1.6 in xenial-proposed until it's properly resolved, and drop the X-AppStream-Ignore change unless it is demonstrably required.
[12:52] <rbasak> (demonstrably required whether for this bug or some other SRU-worthy issue)
[12:54] <jbicha> ok
[13:24] <smoser> cpaelzer, commented in your bug.
[13:25]  * cpaelzer reading
=== hikiko|ln is now known as hikiko
[13:27] <cpaelzer> thanks smoser
[13:27] <cpaelzer> I was kind of waiting you to point me to a user error, thanks for reassigning where it belongs to
[13:28]  * cpaelzer is not sure if broken images are really better than me haning up on a user error
[13:29] <smoser> cpaelzer, diamond is still up
[13:29] <cpaelzer> smoser: sure I didn't kill it
[13:30] <cpaelzer> a bunch of broken guests around
[13:30] <cpaelzer> smoser: but I'd want to wait with a reinstall until the power Devs had a chance to inquire
[13:30] <smoser> what did you want to do about firware there ?
[13:31] <cpaelzer> smoser: keeping as-is in regard to my issue, we can go to 860 if you need that for other reasons
[13:31] <cpaelzer> smoser: I'm pretty convinced it is not a FW issue, but if you want I can up that to 860
[13:31] <cpaelzer> smoser: just the re-deploy of the OS is what I'd postpone atm
[13:45] <smoser> cpaelzer, ok
[13:51] <rbasak> jbicha: regarding https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1662749/comments/4 and https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1662750/comments/4, it'd be useful to state the actual package version strings tested. We've had a severe SRU regression in the past because of confusion due to the lack of that being stated.
[13:51] <ubottu> Launchpad bug 1662749 in gnome-software (Ubuntu Yakkety) "GNOME Software has entry in Startup Applications" [Low,Fix committed]
[13:51] <ubottu> Launchpad bug 1662750 in gnome-software (Ubuntu Yakkety) "Remove 3rd party / non-free license warnings and just show license as Unknown" [Medium,Fix committed]
[13:51] <rbasak> Note though that I'm not releasing it yet due to https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1621971/comments/16.
[13:51] <ubottu> Launchpad bug 1621971 in gnome-software (Ubuntu) "Add handler for snap: URLs" [Wishlist,Triaged]
[14:01] <jbicha> rbasak: good catch, it was fixed in gnome-software 3.23.90 but zesty is still at 3.22.5 so we need to backport that patch
[14:56] <barry> nacc: afaict, pycxx doesn't have any reverse-depends
=== mwsb is now known as Guest70562
[16:31] <tsimonq2> slangasek: :O is patch pilot no longer a thing? Nobody is on the calendar...
[17:41] <nacc> barry: ack, was just wondering as it's been stuck for a while
[17:41] <nacc> tsimonq2: i have it on my calendar periodically, at least
[17:42] <nacc> hallyn: yeah, i guess it's an alternative wrapper just for network namespaces?
[18:24] <nacc> jbicha: do you have a track of what all still requires src:postgresql-9.5 in 17.04?
[18:39] <jbicha> nacc: uh, maybe nothing?
[18:43] <nacc> jbicha: ack, i just updated the bug
[18:43] <nacc> slangasek: would you mind taking a peek at my last comment in LP: #1666566 when you have a moment?
[18:43] <ubottu> Launchpad bug 1666566 in postgresql-9.5 (Ubuntu) "Transition from src:postgresql-9.5 to src:postgresql-9.6" [Undecided,New] https://launchpad.net/bugs/1666566
[18:53] <slangasek> nacc: ugly that repmgr declares that its dep is satisfied by a package that it no longer builds from its own source; but binaries removed now
[18:54] <nacc> slangasek: agreed, and thank you!
[18:56] <slangasek> nacc: and 9.5 removed
[18:56] <nacc> slangasek: great, thanks! I'll have pings about mariadb shortly too, i think :)
[20:06] <jtaylor> barry: re python regression, have you tested turning the computed gotos on and off in xenial, so far I know python2 in xenial has that python3 backport
[20:06] <jtaylor> though that should improve performance in theory, but you never know
=== Pharaoh_Atem is now known as Conan_Kudo
=== Conan_Kudo is now known as Pharaoh_Atem
[20:34] <barry> jtaylor: thanks. caribou has done most of the actual testing ^^.  i'll make sure he knows about that
=== beisner- is now known as beisner
=== iahmad_ is now known as iahmad
=== Pharaoh_Atem is now known as Conan_Kudo
=== Conan_Kudo is now known as Pharaoh_Atem
[21:21] <nacc> jgrimm: figured out the issue with ocfs2-tools; it depends on dlm-controld which ubuntu renamed to dlm
[21:21] <nacc> jgrimm: fixing
[21:21] <jgrimm> ahh. cool
[21:22] <nacc> jgrimm: should make a note somwhere theat uploaders ofdlm will need to fix ocfs2-tools
[21:22] <jgrimm> suggestion on where?
[21:22] <nacc> powersj: --^ fyi
[21:22] <powersj> given I packaged dlm this time around, is there a reason to keep the rename?
[21:23] <nacc> powersj: the changelog only mentions history
[21:23] <powersj> yeah...
[21:23] <jgrimm> i'm trying to remember the history.. was it that debian renamed and we wanted to keep our legacy historic name? or just thought it was cleaner? may have to dig for the reason to answer your question
[21:23] <nacc> jamespage: --^ do you know the history?
[21:27] <nacc> jgrimm: yes, it seems something historical -- that we relied on 'dlm' being the binary package name (it's only source in debian)
[21:27] <nacc> jgrimm: feels like something we should transition in 18.04 so we can sync
[21:27] <jgrimm> nacc, sounds reasonable indeed
[21:27] <nacc> jgrimm: well, we can transition in z+1 and then drop it after 18.04, that is
[21:28] <jgrimm> please add to the whiteboard
[21:28] <nacc> ack
[21:28] <jgrimm> thanks
[21:28] <nacc> yeah, lvm2 carries a delta for this same issue
[21:28] <nacc> so we'd be able to drop a few pieces of delta and sync two packages
[21:29] <jgrimm> cool, yeah seems like busywork that we should drop
[21:30] <jgrimm> nacc, i'd straight out open a bug to track all the packages as well
[21:32] <nacc> jgrimm: LP: #1669133 and bp updated
[21:32] <ubottu> Launchpad bug 1669133 in ocfs2-tools (Ubuntu) "Drop unnecessary rename of dlm -> dlm-controld (binary package)" [Undecided,New] https://launchpad.net/bugs/1669133
[21:32] <jgrimm> nacc, thanks sir!!
[21:33] <nacc> jgrimm: upload ofcs2-tools as well, should go through
[21:33] <jgrimm> ack. thanks
[21:42] <nacc> slangasek: so i think mariadb-10.0 may not be showing up in NBS because of the powerpc binaries leftover? last comment in LP: #1669073
[21:42] <ubottu> Launchpad bug 1669073 in mariadb-10.1 (Ubuntu) "Transition from src:mariadb-10.0 to src:mariadb-10.1" [Undecided,New] https://launchpad.net/bugs/1669073
[21:46] <slangasek> nacc: it's not NBS because the source is still in zesty.  Do you want mariadb-10.0 removed?
[21:46] <slangasek> NBS == not built from source; but there's a source there which builds it
[21:47] <nacc> slangasek: err, yes, sorry!
[21:47] <nacc> slangasek: yes, my eventual goal is removal of src:mariadb-10.0
[21:47] <slangasek> nacc: right - do you want me to delete it now? :)
[21:47] <slangasek> it'll take the binaries with it when it goes
[21:47] <nacc> slangasek: yes please
[21:49] <nacc> slangasek: i would update that bug with a task for mariadb-10.0 but i'm getting LP timeouts
=== bdmurray_ is now known as bdmurray
[21:50] <slangasek> nacc: removal done, and I'll take care of the lp bug update when timeouts relax
[21:50] <nacc> slangasek: thanks
[22:06] <nacc> slangasek: on a different note, i'm not sure what to do about liblog4ada's regressions in z-p. afaict, it's not passed on ppc64el/s390x since september (and unfortunately the passing logs seem to be gone). But it feels like it's not strictly true that it's a regression in any of the packages affected.
[22:21] <nacc> sbeattie: fyi only mariadb-10.1 is now in z
[22:40] <sbeattie> nacc: thank you!
[22:42] <nacc> sbeattie: np
[22:52] <nacc> slangasek: last one :) LP: #1667834
[22:52] <ubottu> Launchpad bug 1667834 in php7.1 (Ubuntu) "[FFe] Please remove php7.1 from zesty" [Undecided,New] https://launchpad.net/bugs/1667834
[22:55] <slangasek> nacc: it shouldn't be in main anyway, so no security committment, right?
[22:55] <slangasek> regardless, demoted to zesty-proposed
[22:55] <slangasek> oh
[22:55] <nacc> slangasek: right, we just don't want to ship two
[22:55] <nacc> slangasek: it's in universe
[22:55] <slangasek> but I shouldn't go and close the bug that I just marked as block-proposed
[22:58] <nacc> slangasek: ah i see, so what happens is php7.1 still gets synced, but stays in proposed becuase of the tag? fancy!
[23:02] <slangasek> nacc: yep
[23:02] <nacc> slangasek: TIL and thanks!
=== Guest27057 is now known as zigo