[00:08] <slangasek> barry: for extra fun, I see that lua5.3 includes both /usr/bin/luac5.3 - supposedly built with gcc - and /usr/bin/lua5.3 - supposedly built with g++.  Both segfault.
[00:28] <slangasek> barry: oh, n/m, one of those is lua 'compiler'.  but anyway, both in terrible shape...
[00:35] <nacc> elbrus: ping, re: cacti, when you get a chance
[01:07] <Pwnna> how do i make openjdk7 not depend on tzdata-jaava?
[01:07] <Pwnna> is that even possible?
[01:07] <Pwnna> i'm trying to.. forward port openjdk7 into xenial for my own use.
[01:10] <Pwnna> i guess my question is if i just go into the rules file and put with_tzdata=no, what will happen?
[01:13] <nacc> Pwnna: not sure i fillow, xenial has openjdk-7-jdk, no?
[01:13] <Pwnna> nope
[01:13] <Pwnna> it's removed
[01:14] <slangasek> well, I don't see why you would try to "forward port" openjdk7 instead of just installing both openjdk-7 and tzdata-java from 14.04
[01:14] <Pwnna> i want to ppa it
[01:14] <Pwnna> because installing a debian package raw is kinda meh.
[01:15] <Pwnna> what's the impact of switching tzdata to no?
[01:15] <Pwnna> i could also create a package in the ppa that just has the files from tzdata-java
[01:16] <sarnold> what's wrong with openjdk-8 or openjdk-9 (-9 is in universe..)
[01:16] <Pwnna> unfortunately, i'm trying to build android and CyanogenMod requires 7
[01:17] <nacc> Pwnna: why not just run trusty in a container or vm then?
[01:17] <Pwnna> nacc: so slow.
[01:17] <sarnold> aha. eww. :)
[01:17] <Pwnna> VM is slow.
[01:17] <Pwnna> haven't tried container yet
[01:17] <nacc> Pwnna: containers aren't slow? try using lxd ;)
[01:17] <Pwnna> i could debootstrap into a chroot even
[01:18] <Pwnna> is true
[01:18] <Pwnna> but that setup will not play nicely with my automated setup for now
[05:06] <cpaelzer> good morning
[06:01] <darkxst> bdmurray, cyphermox: we still need the gnome-session inhibitor to block screensaver, logind does not block user session idle monitors!
[06:03] <darkxst> bug 1565177 ^
[06:16] <showaz> dovecot: auth: Error: LDAP: binding failed … Strong(er) authentication required, BindSimple: Transport encryption required
[06:16] <showaz> how can fixed samba-4.3.8?
[06:17] <showaz> ......
[06:32] <pitti> Good morning
[08:35] <mwhudson> aaargh dh-golang in trusty is impossibly ancient
[08:51] <pitti> mwhudson: -backports?
[08:51] <mwhudson> probably a good idea
[08:51] <pitti> mwhudson: if it's backwards compatible and you have some good arguments it could even be SRUed, but this depends on what you need to do
[08:52] <mwhudson> also i was exaggerating a bit, i can cope in this case by not running the tests :-)
[08:52] <mwhudson> pitti: yeah, i'll think about SRU, if we want to keep lxd etc up to date in trusty it'll help
[08:52] <pitti>  lxd | 2.0.0-0ubuntu1~ubuntu14.04.1 | trusty-backports/universe | source, amd64, arm64, armhf, i386, ppc64el
[08:52] <pitti> mwhudson: it couldn't be much more up to date
[08:53] <mwhudson> it _should_ be compatible, and there are hardly any go-built things in trusty anyway
[08:53] <Laney> stgraber is already doing lxd backports
[08:53] <pitti> these are done mostly automatically
[08:53] <pitti> trusty-backports followed xenial with pretty much every lxd upload
[08:54] <mwhudson> i guess this means lxd avoids using new dh-golang features
[08:54] <mwhudson> which is perhaps fine
[08:58] <showaz> DisplayLink support ubuntu http://www.displaylink.com/downloads/ubuntu
[09:58] <dholbach> pitti, HAPPY BIRTHDAY! :-D
[09:58] <pitti> \o/ thanks!
[10:18] <doko> slangase`, is there a reason you uploaded lua 5.1 and 5.2 but not 5.3?
[10:26] <pitti> doko: btw, did you see? http://people.canonical.com/~ubuntu-archive/nbs.html
[10:28] <doko> pitti, yes. what was the solution for smc?
[10:30] <pitti> doko: removed from xenial with "FTBFS (Debian bug #812096), needs porting to CEGUI 0.8.4, removed from Debian testing, no rdepends"
[10:30] <pitti> doko: it's still in -proposed if it ever gets fixed
[10:31] <pitti> doko: at least cegui itself got fixed along the way
[10:31] <pitti> ♩ 23 bottles of FTBFS on the ♪ ♫
[10:32] <pitti> ... wall
[10:52] <pitti> doko: are you looking at cross-toolchain-base? (ubuntu patch that patches debian/ does not apply) or should I take a look?
[10:52] <pitti> and I still can't reproduce the gnupg-doc FTBFS
[10:52] <pitti> looking at vigraimpex ATM
[11:01] <doko> pitti, yes, waiting for one last glibc upload
[11:11] <pitti> doko: ok, ignoring that one
[11:20] <pitti> barry, doko: python-configglue> latest upstream version 1.1.3.post0 is just as broken; but python3-configglue has no reverse dependencies, so we could just remove the binary and keep python-configglue (one rdepends); WDYT?
[11:20] <pitti> not much point shipping a module with syntax errors
[11:25] <pitti> doko, barry: I uploaded this to unapproved now; feel free to reject if you have a better idea
[11:28] <pitti> I followed up to bug 1504288
[11:30] <showaz> apt install php5-cli -> However the following packages replace it: php7.0-cli:i386 php7.0-cli (E: Package 'php5-cli' has no installation candidate)
[11:30] <showaz> ubuntu server 16.04
[11:30] <showaz> why php5 err?
[11:34] <pitti> showaz: php5 is gone from xenial, as the error message says; use php7
[11:34] <showaz> backport ?
[11:35] <showaz> pitti: php7 broken compatibility, now 16.04 only use HHVM/PHP-LiteSpeed-SAPI
[11:36] <showaz> 5.6+
[11:36] <cjwatson> showaz: http://dark-net.net/?p=128
[11:36] <pitti> showaz: sorry, I don't know much about php other than that we moved to 7.0
[11:36] <cjwatson> showaz: or http://blog.dustinkirkland.com/2016/04/php7-in-ubuntu-16.04-lts.html
[11:36] <showaz> thanks but php7 no need, support software 25%
[11:37] <cjwatson> showaz: did you actually read the first link at all?
[11:37] <showaz> pitti: thanks!
[11:37] <cjwatson> (I don't care about PHP at all, I just saw these go past on planet and thought they might be of use to you.)
[11:49] <pitti> cjwatson: I'd like to add another 6 month's worth of 16.XX milestones to https://launchpad.net/ubuntu/+milestones -- where can I do that/
[11:49] <pitti> ?
[11:50] <pitti> (using my TB credentials while I still have them)
[11:50] <pitti> oh, https://launchpad.net/ubuntu/y-series/+addmilestone apparently
[11:51] <cjwatson> er no
[11:51] <cjwatson> pitti: https://launchpad.net/ubuntu/xenial/+addmilestone surely
[11:51] <cjwatson> pitti: unless you mean 16.10?
[11:51] <pitti> cjwatson: oh, why xenial? 16.05, 16.06 etc. are Y surely?
[11:51] <cjwatson> oh, right, I thought you meant 16.04.X
[11:51] <cjwatson> as you were
[11:52] <pitti> cjwatson: ah, I guess at some point we want those as well, but for now just the next six months of targetting blueprints or bugs
[11:53] <cjwatson> sure
[11:55] <pitti> ok, done
[13:12] <mterry> @pilot in
[13:26] <cyphermox> darkxst: right, that's what I was saying :)
[14:24] <tseliot> pitti: I have just uploaded nvidia-361 and nvidia-340 with transitional packages, so that we can get rid of the -updates flavours
[14:24] <tseliot> tjaalton: ^
[14:28] <pitti> tseliot: ah great, thanks! (don't see them in unapproved yet)
[14:30] <tjaalton> tseliot: thanks
[14:32] <tseliot> pitti: yes, I haven't received an email about the uploads either
[14:33] <cjwatson> tseliot: one of our haproxies fell over, will need to recover the upload
[14:33] <cjwatson> tseliot: just leave it for now
[14:34] <tseliot> cjwatson: oh, ok, thanks
[14:34] <pitti> ah, I suppose that's also the reason why launchpad.net feels like a pit of tar right now
[14:34] <cjwatson> yes
[14:35] <sil2100> bdmurray: hey! I got in touch with the two remaining people on our list and confirmed their readiness to apply on the next meeting - I updated the agenda with regards to that
[14:35] <sil2100> bdmurray: thanks for clearing out the list!
[14:35] <sil2100> bdmurray: (the DMB applicant list of course)
[14:41] <stgraber> Laney, mwhudson: I do remember testing our initial packaging with trusty's dh-golang and finding some issues which had me avoid some specific bits in the xenial packaging
[14:41] <stgraber> can't remember the details though, that was over 6 months ago
[14:45] <LocutusOfBorg> can anybody please ignore ruby-saml testsuite? the same issues are on debian-ci, and I think they aren't important, at least seems that packaged depending on it works anyway
[14:47] <pitti> LocutusOfBorg: hm, would be interesting if the failure started with the -proposed version or due to some other changes
[14:47] <pitti> http://autopkgtest.ubuntu.com/packages/r/ruby-saml/xenial/amd64/ sure does look like the former
[14:48] <pitti> as there was a pass in between for a different trigger
[14:48] <pitti> same for http://autopkgtest.ubuntu.com/packages/r/ruby-omniauth-saml/xenial/amd64/
[14:49] <LocutusOfBorg> I guess ignoring is fine then?
[14:50] <pitti> well, no, I'm saying the opposite
[14:50] <pitti> the current version in xenial passes, the one in -proposed doesn't
[14:50] <LocutusOfBorg> damn ruby clueless
[14:50] <pitti> ignoring would be fine if xenial's would now fail as well as it got broken due to some other changes
[14:50] <LocutusOfBorg> I don't know how to fix them
[14:50] <pitti> ruby cluelessness> make that two :)
[14:55] <slangasek> doko: I uploaded lua5.3 several hours /before/ the other two
[15:12] <LocutusOfBorg> pitti, the testsuite from the old and the new saml are completely different
[15:12] <LocutusOfBorg> and there seems to be  lot of new tests added
[15:13] <LocutusOfBorg> and somewhere at the begin gem2deb-test-runner is doing a mv of the library, so the chdir doesn't work anymore
[15:14] <gQuigs> pitti: I can't think of any other tests to do on https://bugs.launchpad.net/ubuntu/+source/telepathy-qt5/+bug/1538772 (except if some one wants to test it on the phone)
[15:15] <gQuigs> btw, with that change, and screenlets removal 1566635, the rest of the gstreamer0.10 packages should be removable
[15:19] <Pici> @5
[15:19] <udevbot> Error: "5" is not a valid command.
[15:19] <Pici> oopw.
[15:22] <pitti> gQuigs: ah, thanks; I think it needs to be looked at more closely -- I noticed (later on) that our -qt5 package has a ton of touch patches, not sure if they are all upstream now
[15:23] <gQuigs> ah ok
[15:57] <LocutusOfBorg> pitti, I think I fixed saml, thanks
[15:57] <LocutusOfBorg> it was just a testsuite error
[16:19] <mterry> @pilot out
[16:28] <LocutusOfBorg> pitti, can you please make ruby-saml testsuite against proposed ruby-omniauth-saml?
[16:29] <LocutusOfBorg> BTW ruby-saml 1.1.2-1ubuntu1 is dinstalling I guess
[16:29] <nacc> mterry: thanks for your uploads!
[16:29] <mterry> nacc, yw!  thanks for the patches  :)
[16:31] <nacc> mterry: i'm presuming you might have permission to do so (I do not) can you mark the task for wordpress as invalid as well in LP: #1315888 ?
[16:31] <mterry> nacc, naw, I don't have permission.   Not a dev for that project  :-/
[16:32] <teward> nacc: should be pointed out that they don't use Launchpad
[16:32] <nacc> mterry: oh i see that's how it works, ok, i wasn't sure :)
[16:32] <teward> their tracker appears to be upstream trac, is there an upstream ticket?
[16:33] <mterry> nacc, but doesn't hurt to have it there -- bug won't appear open to ubuntu tracker even though there are other tasks.  All I generally care about is the ubuntu tasks  :)
[16:33] <nacc> mterry: ack
[16:33] <nacc> teward: well, there shouldn't be -- in that there is no wordpress bug?
[16:34] <teward> nacc: different issue - release notes on php7.0, do you want me to update the link to my dark-net.net post on the nginx-side with the pretty url?
[16:34] <nacc> teward: sure, that'd be great
[16:34] <teward> nacc: not sure, though the evil thing would be to remove the WordPress task where possible - or just leave it.  as mterry said, more important the Ubuntu task is addressed ;)
[16:41] <teward> nacc: updated that link
[16:41] <nacc> teward: thanks!
[16:43] <Son_Goku> nacc: the patches are IN! https://libvirt.org/git/?p=libvirt-php.git;a=summary
[16:43] <Son_Goku> nacc: I’ve been requested to do some testing before he marks it as 0.5.2 and releases it to wild
[16:44] <nacc> Son_Goku: sweet, if it gets tagged soon, i'll file the SRU bug :)
[16:55] <nacc> Son_Goku: well, i'll file hte bug regardless, but mean i'll work it :)
[16:55] <Son_Goku> welp, he broke the build
[16:55] <Son_Goku> it doesn’t work on php7 anymore :(
[16:56] <Son_Goku> nacc: he changed the zend_ulong to zend_ulong64, which doesn’t exist
[16:56] <nacc> :)
[16:57] <nacc> Son_Goku: glad you're testing!
[16:57] <Son_Goku> I need to find an equivalent to unsigned long long in php
[16:57] <nacc> Son_Goku: was it a documented change?
[16:57] <Son_Goku> he changed the patch mid-flight
[16:58] <Son_Goku> my version uses zend_ulong, but he switched it during the review
[16:58] <nacc> ah
[17:02] <tseliot> pitti: hey, can you approve nvidia-graphics-drivers-340 too , please?
[17:11] <tseliot> or cjwatson ^
[17:16] <Son_Goku> nacc: easy enough to fix
[17:16] <Son_Goku> nacc: I need to head into the office though, otherwise I’ll catch hell :P
[17:16] <Son_Goku> bbs as Pharaoh_Atem
[17:16] <nacc> Son_Goku: np, thanks!
[17:17] <Son_Goku> nacc: go ahead and file the request, so that you can get the wheels greased
[17:23] <nacc> slangasek: for SRU'ing (presuming that's the case for libvirt-php + php7 support), is it appropriate to have one large patch that backports the upstream php7 support in d/patches? or should it be 1:1 with the upstream commits?
[17:25] <slangasek> nacc: I don't have a particularly strong preference, there are pros and cons of both representations given that source package uploads are not git repos
[17:27] <nacc> slangasek: ack, i think there are a lot of commits in this case, so one is a bit easier :)
[17:27] <slangasek> nacc: right, for "lots of commits" a unified diff is usually easier to review too
[17:28] <nacc> slangasek: yep, thanks!
[17:35] <LocutusOfBorg> please run ruby-saml 1.1.2-1ubuntu1 testsuite against ruby-omniauth-saml in proposed thanks
[18:11] <Pharaoh_Atem> nacc: so git HEAD + https://www.redhat.com/archives/libvir-list/2016-April/msg00929.html makes it work on php7
[18:36] <nacc> Pharaoh_Atem: yeah, the tricky part is we need to backport :)
[18:36] <nacc> Pharaoh_Atem: i can start doing that today, will probably need your help to test via PPA?
[18:44] <Pharaoh_Atem> nacc: certainly
[18:45] <nacc> Pharaoh_Atem: thanks, will try to get something to you after lunch
[18:45] <Pharaoh_Atem> okay, cool
[18:46] <nacc> Pharaoh_Atem: what's the first commit in the git series that adds php7 support? don't have the ML post handy
[18:47] <Pharaoh_Atem> nacc: a71cb51dd9bb8805ae1b0e7e29f79e57164655bb
[18:47] <nacc> Pharaoh_Atem: ack, thanks!
[18:48] <Pharaoh_Atem> nacc: gitweb: http://libvirt.org/git/?p=libvirt-php.git
[18:48] <Pharaoh_Atem> nacc: git url:  git://libvirt.org/libvirt-php
[18:49] <nacc> Pharaoh_Atem: thanks!
[18:49] <Pharaoh_Atem> nacc: here's the patch: http://paste.fedoraproject.org/355585/46065977/
[18:49] <Pharaoh_Atem> that goes on top of the git HEAD
[18:52] <Pharaoh_Atem> nacc: I suspect you'll have to roll up all the patches from 0.5.1 release, though
[18:53] <nacc> Pharaoh_Atem: we're probably going to have to find a better alternative, given that we're on 0.4.8 :)
[18:53] <Pharaoh_Atem> O.o
[18:53] <Pharaoh_Atem> how the hell did that happen!?
[18:53] <nacc> debian only recnelty moved up, if i had to guess
[18:54] <Pharaoh_Atem> aww geez
[18:55] <nacc> slangasek: for something broken like libvirt-php, is it possible to sync with debian at this point? or should i just pursue what i was originally planning which was a backport?
[18:56] <nacc> slangasek: not that syncing alone will fix the issue, but willmake the backport far more reliable (I think)
[18:58] <Pharaoh_Atem> nacc: apparently... Ondrej pulled in the first version of my patches?
[19:00] <nacc> 0.5.1-31-ga005c2d with PHP 7.0 support
[19:00] <nacc> but that's from mar 25
[19:00] <nacc> how's that possible?
[19:01] <Pharaoh_Atem> I have... no idea
[19:01] <nacc> and that's not a defined hash?
[19:01] <Pharaoh_Atem> I didn't even submit the patches until April 8
[19:01] <Pharaoh_Atem> I'm confused :(
[19:02] <slangasek> nacc: still possible to sync; non-broken package that someone else maintains > broken package in the archive
[19:02] <nacc> slangasek: ack, will verify this bit and then file the bug then
[19:02] <Pharaoh_Atem> nacc: I have *no idea* where that comes from
[19:03] <nacc> Pharaoh_Atem: e-mailing ondrej, will cc you
[19:03] <Pharaoh_Atem> because none of my branches have that commit object hash
[19:18] <Pharaoh_Atem> nacc: okay
[19:26] <doko> lifeless, uploaded https://launchpad.net/ubuntu/+source/pyjunitxml/0.6-1.1ubuntu1  debian doesn't have your 0.7 release
[19:31] <dstufft> doko: Just to let you know, I'm poking at setuptools in Ubuntu 16.04. I see that it's version 20.3.1 and there was a string of releases trying to restore backwards compatability when it got broken in version 20.2. I see you do have packaging 16.6 and I know at least some of the fixes were actually in that lib and just pulled into a newer setuptools, double checking to make sure _all_ the fixes were like that.
[19:36] <dstufft> Ok yea, python3-pkg-resources on Ubuntu 16.04 still has the regression. (Can test it using python3 -c "import pkg_resources; pkg_resources.Requirement.parse('multiprocessing; python_version == \'2.5\' and platform.python_implementation != \'Jython\'')")
[19:38] <doko> dstufft, setuptools has way too many regressions in it's way too many releases ;p  maybe start working with release candidates, and have longer stabilization periods?
[19:38] <doko> at this point, I'd just like to pull in fixes
[19:38] <dstufft> doko: I don't actually work on setuptools itself, I think it needs to slow down myself (this is why pip is still fast, but not nearly as quick as setuptools does)
[19:38] <dstufft> I just happened to notice the version number
[19:39] <dstufft> and knew of the issues
[19:39] <doko> barry, ^^^
[19:40] <dstufft> doko: So, I *tihnk* and I'm still verifying, that the fixes were contained within the packaging library, but y'all didn't unvendor the packaging lib from inside of pkg_resources in setuptools
[19:40] <dstufft> so you have the right version of the packaging lib in the archives, but python3-pkg-resources isn't using it atm
[19:45] <dstufft> doko: for whatever it's worth, the delta between the version you have (20.3.1) and the latest version (20.7.0) is mostly adding more tests, fixing the regressions caused by 20.2 and some misc erata from switching from hg to git (updating links, etc). It's probably roughly about six of one, half a dozen of the other for backporting specific fixes and backporting a new version - https://github.com/pypa/setuptools/compare/20.3.1...v20.7.0
[19:45] <dstufft> but either way is OK with me
[19:46] <dstufft> I just know that this caused a bunch of packages to not be installable (the regression that is) and I really want 16.04 + python packaging to be in a good state :]
[19:48] <dstufft> (anything in pkg_resources/_vendor/packaging is just changes that came from pulling in packaging 16.6)
[19:49] <doko> dstufft, can you file a FFe?
[19:49] <dstufft> What is a FFe
[19:50] <dstufft> I'm happy to do it though :]
[19:50] <doko> https://wiki.ubuntu.com/FreezeExceptionProcess
[19:56] <dstufft> doko: Ok, it says I need to have a package ready to go and stuff. I have to pick up my daughter from the bus in ~5 minutes so I don't have time right this minute to try and figure out how to update a package. I'll see if I can figure that out when I get back
[19:56] <doko> dstufft, I'm uploading to debian, so you can reference it
[19:56] <dstufft> okay
[19:56] <barry> dstufft: let me know if you need any help with that
[19:56] <barry> (the ffe)
[19:58] <doko> dstufft, setuptools stopped distributing the CHANGES.txt ?
[19:58] <dstufft> I think they just renamed it to CHANGES.rst
[19:58] <dstufft> so that it renders on GitHub
[19:59] <dstufft> If it's not in the tarball maybe they forgot to update a reference
[19:59] <doko> no, not in the tarball
[19:59] <doko> next regression :-/ 	Rename CHANGES and README files for nicer rendering on Github.
[20:00] <dstufft> $10 says they forgot to update MANIFEST.in
[20:00] <dstufft> is that important? I don't know if y'all use that file or not. I can see if Jason can do a 20.7.1 that fixes that if it is
[20:00] <doko> renamed files produce a diff ...
[20:02] <dstufft> Ok, gotta go get Alyssa from the bus stop, will be back in 20-30 and I'll see if I can figure out how to file a FFe (unless barry or someone feels like doing it instead, either way is fine with me). Let me know if you want a 20.7.1 with CHANGES.rst inside of it and I'll poke jaraco or someone who can release setuptools and ask them
[20:02] <dstufft> bbs
[20:03] <barry> dstufft: ping me when you get back.  i'm working on another ffe atm
[20:13] <barry> pitti: still around?
[20:15] <doko> dstufft, barry: despite this version inflation, the changes look pretty small if you ignore the renaming noise
[20:16] <barry> doko: cool.  still want an ffe?
[20:18] <doko> well, I'll upload so that people can have a look at the diff
[20:19] <barry> doko: sounds good.  while you're at it, are you able to reject the webob sync?  on further testing, i think it's not worth syncing it now
[20:19] <dstufft> barry: ok I'm back now :]
[20:20] <barry> dstufft: cool.  see scrollback
[20:21] <doko> barry, dstufft: http://launchpadlibrarian.net/253841863/python-setuptools_20.3.1-1_20.7.0-1.diff.gz
[20:23] <barry> doko, dstufft yeah, minus rename, docs, and tests it's not so much stuff
[20:24] <doko> barry, so please check with infinity
[20:24] <dstufft> I think the only actual code changes which aren't required are A) Some small refactoring and B) changing an exception handler from catching ImportError to just an Exception
[20:24] <barry> doko: ack
[20:25] <dstufft> (B) shouldn't affect Ubuntu at all b/c it's in Windows code
[20:25] <barry> infinity: hi!
[20:25] <dstufft> barry: so I just file a bug against python-setuptools asking for a FFe and explaining why?
[20:27] <barry> dstufft: the bug wants a stylized description: https://wiki.ubuntu.com/FreezeExceptionProcess
[20:28] <barry> dstufft: anything you don't know, just ping me
[20:39] <dstufft> barry: https://bugs.launchpad.net/ubuntu/+source/python-setuptools/+bug/1570587
[20:39] <dstufft> maybe I did that wrong, I Tried to copy other bugs I found in https://bugs.launchpad.net/~ubuntu-release/+subscribedbugs
[20:41] <infinity> It's fine.
[20:41] <doko> dstufft, please subscribe ubuntu-release
[20:41] <barry> dstufft: that looks good.  i've subscribed ~ubuntu-release
[20:41] <barry> heh
[20:42] <dstufft> oh yea, I was gonna do that once someone told me I didn't totally screw it up since i don't know if that is going to cause someone to get an email or not
[20:42] <dstufft> Thanks a lot!
[20:44] <mwhudson> i think the people on ~ubuntu-release get enough mail that one more isn't really noticeable :-)
[20:53] <lifeless> doko: ack; I need to get on that
[20:54] <bdmurray> seb128: I just upgraded a vm from W to X and keep getting a dialog that says "An update is needed ... to show all installable apps." Clicking Yes just shows the dialog again.  Is that known?
[20:55] <slangasek> Backtrace:
[20:55] <slangasek> /lib/i386-linux-gnu/libSegFault.so(+0x2671)[0xf7769671]
[20:55] <slangasek> I dunno, I think that might be your problem right there
[20:56] <slangasek> at least you didn't load libKernelPanic?
[20:56] <nacc> heh
[20:57] <seb128> bdmurray, I mentioned it to attente earlier but he doesn't get it ... could you report against gnome-software?
[20:58] <attente> seb128: bdmurray: do either of you have a /var/lib/app-info directory?
[20:58] <seb128> I don't
[20:59] <attente> ok.. so that explains the dialog, but i'm not sure why it's reprompting for it
[21:01] <attente> hold on. let me try something here
[21:01] <bdmurray> attente: I have no app-info directory
[21:04] <tsimonq2> is there documentation for what release pockets are used for the release assigned to the devel alias (currently Xenial)?
[21:07] <cjwatson> tsimonq2: I don't really understand the question.  The release pocket is a singular thing; maybe you mean something else?
[21:07] <attente> bdmurray: seb128: does gnome-software launch when you click on yes?
[21:07] <seb128> yes
[21:08] <cjwatson> (and "pocket" is terrible terminology we were lumbered with years back, but anyway)
[21:08] <bdmurray> attente: the first time it did, now it just stays open
[21:08] <seb128> attente, it starts, displays the refresh icon, then displays the dialog again
[21:08] <tsimonq2> cjwatson: for example, xenial-proposed, xenial-updates, etc. I am talking about the xenial-* portion
[21:08] <tsimonq2> get what I mean?
[21:08] <cjwatson> tsimonq2: OK, so the reason I was confused is that when people say "the release pocket" [of xenial] that means specifically xenial, not xenial-anything
[21:09] <attente> probably the easy fix is to make sure it only asks when the g-s is actually launched explicitly by the user
[21:09] <attente> but it's really weird that it asks more than once
[21:09] <tsimonq2> cjwatson: yeah, I get what you mean. Do you have an answer to my question?
[21:09] <cjwatson> tsimonq2: Launchpad has a rather hardcoded set of five pockets: release, security, proposed, updates, and backports
[21:10] <cjwatson> tsimonq2: the suites (series + pocket) that those turn into for the xenial series are xenial, xenial-security, xenial-proposed, xenial-updates, and xenial-backports
[21:10] <cjwatson> you can see that in http://archive.ubuntu.com/ubuntu/dists/
[21:10] <tsimonq2> cjwatson: which ones are used in development?
[21:10] <tsimonq2> s/development/development releases/
[21:11] <tsimonq2> cjwatson: like, are backports and updates really used?
[21:11] <cjwatson> tsimonq2: the model for the last few years has been that, when a series is in active development, all uploads go to -proposed and are migrated to release by proposed-migration; after the series is marked stable, -proposed switches to being a staging area for SRUs awaiting verification, and -{security,updates,backports} come into use
[21:12] <cjwatson> tsimonq2: the post-release suites (-security, -updates, -backports) aren't used before release because there's no point - things should just be uploaded to -proposed.  (there is a slight fudge factor here in the few days before release.)
[21:13] <tsimonq2> cjwatson: that's what I needed to know, thank you
[21:13] <cjwatson> I'm sure this is documented somewhere, but it was quicker to explain it than to find the link
[21:51] <doko> mesa-opencl-icd/amd64 unsatisfiable Depends: libclc-r600 (>= 0.2.0+git20150813)
[21:51] <doko> mesa-opencl-icd/amd64 unsatisfiable Depends: libclc-amdgcn
[21:51] <doko> tjaalton, ^^^
[21:51] <tjaalton> doko: universe
[21:51] <tjaalton> demote it
[21:52] <doko> tjaalton, mesa-opencl-icd?
[21:52] <tjaalton> yes
[21:53] <doko> done
[22:25] <doko> slangasek, stokachu: are you aware of the juju-core autopkg test failures? or should mgz join this channel too if he uploads?
[22:25] <slangasek> doko: they are documented in the FFe bug. mgz has said he is working on them.
[22:26] <slangasek> and afaik mgz was not the uploader
[22:26] <doko> ta
[22:26] <slangasek> (but he is in #ubuntu-release)
[22:26] <doko> he's mentioned as uploader
[22:27] <stokachu> i ve been doing the upload for them
[22:27] <stokachu> I want aware of the test failures though
[22:27] <stokachu> wasn't*
[22:28] <slangasek> stokachu: the tests are upside-down and broken.  Hopefully there are fixed versions coming soon.
[22:28] <stokachu> so they just did a release today I need to verify that then
[22:29] <doko> just seeing that openstack is now entangled with juju
[22:29] <stokachu> slangasek: one sec getting balloons in here
[22:31] <stokachu> slangasek: they are telling me beta4 and 1.25.5 should have fixed them
[22:32] <stokachu> which im about to upload
[22:35] <slangasek> stokachu: "beta4 and 1.25.5" - this was only ever broken in juju-core 2.0; so hopefully they're telling you the right thing ;)
[22:36] <stokachu> slangasek: looks like 2.0~beta4 has the fixes
[22:40] <stokachu> slangasek: juju 2.0 beta4 looks to have autopkgtests in the relevant debian/tests directory
[22:40] <stokachu> and contains the fixes for the lxd dependency
[22:40] <slangasek> stokachu: so did the last upload.  they were just untested and broken.
[22:40] <slangasek> ok
[22:41] <slangasek> and the sudo dependency, and the needs-root declaration
[22:41] <slangasek> ?
[22:41] <stokachu> lemme find out.. ive asked them to join here
[22:42] <stokachu> mgz_: hey slangasek had some questiosn wrt sudo dep and needs-root declaration
[22:42] <stokachu> and making sure that the autopkgtests were passing
[22:42] <mgz_> slangasek: wotcha. fixed the autopackagetests for 1.25.5, have the 2.0-beta4 ones... very likely fixed
[22:43] <mgz_> needs-root is mostly needed for test setup, we drop privs with the normal-user.sh script
[22:43] <doko> likely?
[22:43] <mgz_> I'm running again with a fix for the last issue I saw
[22:44] <slangasek> mgz_: yes; so the updated package now includes both the needs-root declaration, and the sudo dependency so that normal-user.sh is able to drop privs?
[22:44] <mgz_> slangasek: yup
[22:44] <slangasek> ok
[22:45] <balloons> mgz_, and you are adding jujutest to lxd in normal_user.sh yes?
[22:45] <mgz_> yeah, done that
[22:45] <mgz_> currently wondering if this is going to work in nested lxc
[22:45] <mgz_> it's... a bit to quiet and hung atm
[22:48] <mgz_> wonder if it's hung not being able to get base lxd image
[23:03] <mgz_> just hung inside an lxc command doing who knows what
[23:03] <mgz_> I love lxd.
[23:04] <balloons> my xenial image is complaining about locales, and adt won't use a persistent image so . . .
[23:04] <stgraber> mgz_: is it the first time you're using nested lxd?
[23:04] <Odd_Bloke> balloons: Are you using a daily xenial image, or a release one?
[23:05] <stgraber> mgz_: if so, did you set security.nesting=true on the container, if you don't lxd will keep crashing, with systemd helpfuly respawning it, leading to the client being stuck
[23:05] <Odd_Bloke> balloons: (release will be beta, which is known to have a locale problem which has been fixed in dailies for a couple of weeks)
[23:05] <mgz_> stgraber: this is an adt test
[23:05] <balloons> I believe I've tried both, but that might not be true
[23:05] <mgz_> it's a totally fresh environment
[23:05] <balloons> Odd_Bloke, sounds like indeed I'm not getting a daily
[23:05] <balloons> i'm trying lxc launch ubuntu-daily:16.04 xenial-daily
[23:06] <stgraber> mgz_: oh, yeah, lxd isn't going to work inside the lxc based adt environment
[23:06] <balloons> but it matters not, as adt won't take a persitent image
[23:06] <mgz_> okay, so I upload what I've got and hope it works then I guess
[23:06] <balloons> stgraber, I built an image with adt-build-lxd.. seemed ok
[23:06] <balloons> lol, other than the xenial issues. trusty works fine
[23:06] <mgz_> the 1.25 local provider is happy, the lxd provider tests... not so
[23:06] <stgraber> balloons: yeah but that's not what the adt runners are using yet
[23:07] <balloons> stgraber, oh. So having it work for me using that isn't a good test then?
[23:08] <balloons> mgz_, I agree, if everyone else is on board then. Sounds like a proper local test isn't going to be easy to come by.
[23:08] <stgraber> balloons: right, amd64, i386 and ppc64el are VM based, the rest (maybe with the exception of arm64) is using good-old lxc with a custom profile which isn't compatible with running lxd
[23:08] <stgraber> and IIRC the lxd based adt runners don't have nesting support enabled yet
[23:09] <mgz_> okay, so changing the lxd tests back to isolation-machine and going with that
[23:09] <stgraber> so usually for container stuff we just look at the results on amd64, i386 and ppc64el and consider every other failures as expected
[23:09] <balloons> ahh.. I had thought those all got moved over. I remember pitti talking about support for this in Jan
[23:09] <slangasek> balloons, mgz_, stgraber: and juju-core already passed its tests on armhf+s390x, which implies they've been deliberately skipped; whereas amd64,i386,ppc64el, the VM-based ones where the tests should run, were failing because of the test bugs
[23:10] <stgraber> balloons: he added lxd support to autopkgtest upstream, yes, that code just isn't used in production yet :)
[23:10] <mgz_> slangasek: there's a difference between the last branch failing, and getting the next upload actually running good tests
[23:11] <mgz_> even with this rollback the coverage on armhf/s390 should be a little better
[23:11] <mgz_> but I have less confidence lxd will actually work as I can't get it to locall
[23:11] <mgz_> y
[23:11] <slangasek> mgz_: I'm saying, armhf and s390x with their lxd-based runners are already doing "the right thing" (approximately), you just need the lxd tests running on the VM-based runners, for which a local test with nested lxd is probably a waste of time
[23:11] <mgz_> (in the adt environment)
[23:19] <balloons> so perhaps a schroot with lxd?
[23:19] <balloons> still the same perhaps
[23:23] <xnox> slangasek, some have argued that we should run autopkgtests in multiple environments e.g. in qemu, in lxd, and bare-metal.
[23:23]  * xnox guesses lxd qualifies as bare metal.
[23:50] <slangasek> xnox: I think that would be testing something other than the packages...
[23:56] <seb128> bdmurray, does your apt-get update displays some error due to repos with errors (like the google talk one)? that was the issue for me why it was asking again to refresh