[02:07] <tsimonq2> Hey guys.
[02:08] <tsimonq2> If you read backlog from yesterday in this channel, julienk sponsored a fix for ark that we got from upstream in bug 1636655.
[02:08] <tsimonq2> I'd like to start the SRU process to get it in 16.10.
[02:09] <tsimonq2> I think this involves someone uploading it to yakkety-proposed if I'm not mistaken. Otherwise if it just needs a member of the SRU team to notice, well, HAI! :)
[02:09] <tsimonq2> Any help would be appreciated.
[02:10]  * tsimonq2 looks at patch pilot calendar...
[02:11] <tsimonq2> Ah ok nevermind.
[06:38] <cpaelzer> good morning
[07:24] <pitti> Good morning
[08:11] <nildude> hi
[08:12] <tuxinator>  hi everybody, ok, think that #ubuntu was the wrong place,just found out that ubumirror is broken (atleast the cdimage part) https://help.ubuntu.com/community/UEC/Provisioning/Mirror does not work as it always tries to find "current" which does not exist
[08:29] <doko> LocutusOfBorg: libpng1.6 ftbfs
[08:45] <LocutusOfBorg> doko, fix dpkg :)
[08:46] <LocutusOfBorg> I don't plan to have a delta for libpng in Ubuntu, sorry
[08:46] <LocutusOfBorg> dpkg is broken, dpkg needs fix
[08:47] <doko> why is dpkg broken?
[08:48] <LocutusOfBorg> I enabled pie, because libpng was failing in Debian, bug 844429
[08:48] <LocutusOfBorg> debian bug 844429
[08:49] <LocutusOfBorg> this fixed the static library build, but probably Ubuntu has to inject some pie flags too, when pie is not the default?
[08:52] <doko> LocutusOfBorg: it's broken in Debian too, on kfreebsd-amd64 and x32
[08:54] <LocutusOfBorg> yes, because dpkg is not smart enough to inject the flags
[08:54] <LocutusOfBorg> I think it is broken where dpkg is not aware of the pie status
[08:55] <doko> where is the bug report?
[08:56] <LocutusOfBorg> https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=cf7f30aeba89f5bafe5046b7666985b661eaf217
[08:57] <LocutusOfBorg> I think something like that does the job, isn't it better to enable pie everywhere like debian did?
[08:57] <LocutusOfBorg> I remember you mentioning something like that
[08:57] <doko> ahh, great communication. so this is turned on everywhere? without saying so?
[09:01] <LocutusOfBorg> I don't speak dpkg sorry, I just can look at the commits
[09:08] <pitti> Laney: FYI, filed bug 1642192 and putting the looping linuxinfo test out of its misery
[09:09] <Laney> hey pitti
[09:09] <Laney> how did you notice that?
[09:10] <pitti> Laney: doko asked about it
[09:10] <pitti> Laney: I would have noticed when reviewing excuses.html, but I didn't do that today yet
[10:25] <Laney> Meh, I can't really spend more time figuring out asis - if someone understands this ada stuff then help welcomed
[11:54] <cpaelzer> pitti: just FYI I tracked down a recent libvirt FTBFS to be caused by the recent gnutls30 upload
[11:55] <cpaelzer> pitti: just in case someone else comes by and this gets a wider issue you can point them at bug 1641615
[11:55] <cpaelzer> pitti: that is where I track the work against libvirt
[12:38] <cjwatson> Unit193: We need to do a big Twisted upgrade in LP, definitely, but it's especially-complicated because any newer version of Twisted than the old one we're stuck on declares pbr in setup_requires, which REALLY isn't friends with the buildbot infrastructure we use - so we need to switch our build system to pip in order to upgrade it
[13:02] <caribou> pitti: what's the reason why apport does not collect the same files when a crash occurs on the CLI as opposed to when it happens for a GUI application ?
[13:03] <caribou> pitti: i.e If I killall -SEGV on a vi running in an xterm, I get different content from running gvim from the desktop
[13:07] <pitti> caribou: what's the difference in particular? (in principle they should be more or less the same)
[13:08] <caribou> pitti: http://paste.ubuntu.com/23485451/
[13:08] <caribou> pitti: the content of the desktop directory has the result of the kill -SEGV in the CLI
[13:09] <caribou> pitti: ./gtk has the report created by killing gvim
[13:09] <pitti> caribou: oh --
[13:09] <pitti> caribou: in the GTK version you selected "show  details", but in the CLI version you didn't
[13:09] <pitti> caribou: once you either submit or save or show teh contents in the CLI, apport will do the post-mortem data collection
[13:09] <caribou> well, the CLI version never asked anything
[13:10] <pitti> wut?
[13:10] <caribou> let me try again
[13:10] <pitti> apport-cli should ask you to send, show, analyze locally, save, etc.
[13:11] <caribou> still, that's only true on a desktop, wouldn't happen on a server unless you add your snippet in .bashrc
[13:11] <caribou> pitti: ok, I know where to look for, thanks for pointing that out
[13:12] <pitti> caribou: that has nothing to do whether the crashing program is CLI or GUI; it's only related to whether or not you see the details in apport-{cli,gtk}
[13:12] <caribou> pitti: k
[13:15] <caribou> pitti: great, running apport-cli on the report & view does the trick, thanks!
[13:17] <LocutusOfBorg> doko, please python-numpy merge? https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
[13:17] <LocutusOfBorg> I hope it can fix mipp
[13:17] <doko> hope?
[13:18] <LocutusOfBorg> I'm trying right now, as soon as the build finishes
[13:18] <LocutusOfBorg> there is a segfault in testsuite
[13:18] <LocutusOfBorg> look at gdal autpkgtest against mipp
[13:18] <LocutusOfBorg> test_tsx (test_xsar.Test) ... Segmentation fault
[13:19] <LocutusOfBorg> and such test is using numpy, the difference between debian and ubuntu for numpy is the version
[13:19] <LocutusOfBorg> so, can you please merge it anyway? :p
[13:20] <doko> I'll wait for the ppa build to finish
[13:22] <LocutusOfBorg> ack
[13:22] <LocutusOfBorg> if you wait two more minutes I can even say if the test is fixed
[13:22] <LocutusOfBorg> this is blocking gdal
[13:31] <tuxinator> hi, i found out that the config example of ubumirror is broken (atleast the cdimage part) https://help.ubuntu.com/community/UEC/Provisioning/Mirror does not work as it always tries to find "current" which does not exist
[13:39] <doko> xnox: could you merge auctex? last package preventing demotion of emacs24
[13:40] <xnox> doko, ack
[13:49] <LocutusOfBorg> doko, it fails anyway, but it might be nice to merge it anyway
[13:55] <LocutusOfBorg> pitti, why postresql-common is till defaulting to 9.5? this is making a lot of dependencies FTBFS
[13:55] <doko> meh, there were even some 9.3 packages seeded ...
[13:58] <pitti> LocutusOfBorg: ftbfs how?
[13:58] <pitti> (sorry, UOS session now, bbl)
[13:59] <LocutusOfBorg> -Depends: postgresql-9.6, ${shlibs:Depends}, ${misc:Depends}
[13:59] <LocutusOfBorg> +Depends: postgresql-9.5, ${shlibs:Depends}, ${misc:Depends}
[13:59] <LocutusOfBorg>  Description: reorganize tables in PostgreSQL databases with minimal locks
[13:59] <LocutusOfBorg> Error: debian/control needs updating from debian/control.in. Run 'pg_buildext updatecontrol'.
[13:59] <LocutusOfBorg> e.g. pg-repack, but many others
[14:06] <cjwatson> tuxinator: which "current" URL in particular?  current really should exist
[14:07] <cjwatson> (if there's a CI gateway in place for the flavour, it's the latest build to have passed that; otherwise, it's just the latest build)
[14:13] <LocutusOfBorg> how can I fix this code import now that git - git import works?
[14:13] <LocutusOfBorg> https://code.launchpad.net/~blueyed/boinc/pkg-boinc
[14:16] <cjwatson> LocutusOfBorg: Create a new code import per https://help.launchpad.net/Code/Git#Mirroring_repositories_from_other_sites - you can't change the existing one into a git-to-git import
[14:19] <LocutusOfBorg> cjwatson, I think I just did that https://code.launchpad.net/~costamagnagianfranco/boinc-upstream/+git/boinc-upstream
[14:20] <LocutusOfBorg> it was a bzr, I did click somewhere and changed to git
[14:20] <cjwatson> That's a new import
[14:20] <cjwatson> Why is the project name "boinc-upstream" rather than just "boinc"?
[14:20] <LocutusOfBorg> because I'm creating a "boinc" that tracks the debian pkg-boinc
[14:21] <LocutusOfBorg> and upstream tracks the upstream  nightly commits
[14:21] <cjwatson> That should probably be an import into /debian/+source/boinc then
[14:21] <cjwatson> Though you'd have to use the API to create that, so whatever
[14:21] <cjwatson> Anyway, was just curious
[14:22] <LocutusOfBorg> thanks!
[14:22] <cjwatson> LocutusOfBorg: Note you don't need the trailing .git on GitHub URLs any more for git-targeted imports
[14:22] <cjwatson> That was a workaround for their User-Agent sniffing
[14:22] <LocutusOfBorg> I know, but I like to have them explicit :)
[14:22] <LocutusOfBorg> and it looks similar to the debian import
[15:14] <LocutusOfBorg> bzr: ERROR: bzrlib.errors.NotBranchError: Not a branch: "http://bazaar.launchpad.net/~costamagnagianfranco/boinc-upstream/boinc/".
[15:14] <LocutusOfBorg> cjwatson, ^^
[15:14] <LocutusOfBorg> it seems trying to use bzr to checkout it on the recipe
[15:14] <LocutusOfBorg> https://code.launchpad.net/~costamagnagianfranco/+recipe/boinc-upstream-daily-1
[15:20] <cjwatson> LocutusOfBorg: see https://bugs.launchpad.net/launchpad/+bug/1623924 for workaround
[15:21] <cjwatson> LocutusOfBorg: also, you can't have a mixed git/bzr recipe
[15:21] <cjwatson> LocutusOfBorg: so you'll need to convert that lp:~costamagnagianfranco/+junk/boinc-upstream-merge branch to git
[15:23] <LocutusOfBorg> ack thanks
[16:41] <pitti> Logan: hm, these deps should be generated during package build from pg_buildext; are they hardcoded in the source?
[16:42] <pitti> sorry Logan, I meant LocutusOfBorg
[17:17] <nacc> rbasak: ping
[17:17] <rbasak> nacc: o/
[17:17] <nacc> rbasak: hey, do you have a few minutes to talk about parenting in the importer?
[17:17] <rbasak> Sure
[17:18] <nacc> rbasak: ho ok?
[17:18] <rbasak> That's fine. Let me move to my desk.
[17:19] <nacc> rbasak: thanks, sent an invite
[18:05] <doko> one less lua version in main \o/
[18:12] <doko> zul: Copyright: Others (See individual files for more details)    debian/copyright has to tell that :-(
[18:13] <doko> who are "Others"?
[18:13] <zul> doko: heh you are killing me here
[18:13] <zul> doko: please reject..there are one or two other things i want to fix
[18:14] <doko> zul: done
[18:14] <zul> doko: thanks
[18:15]  * doko shouldn't do new source reviews ...
[18:34] <doko> nacc: freeradius autopkg tests are failing
[19:00] <nacc> doko: thanks, will investigate
[19:38] <nacc> doko: fwiw, failing in debian too -- let me see if i can figure it out there
[20:11] <bdmurray> pitti: Could the result page of a retry request for autopkgtest include a link to the package page e.g. http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader
[20:12] <bdmurray> or likely more specific with arch and release
[20:17] <LStranger> Could anyone tell me what is exact way to close multiple LP bugs in changelog, please? In Debian I wrote (Closes: #1, #2, #3). Should I add (LP: #1, LP: #2) or what? :)
[20:20] <LStranger> Since most of bugs fixed in coming lxpanel upstream release 0.9.0 are from LP, I would like to mark them for LP on upload into Debian sid (so eventually into Ubuntu as well). :)
[21:05] <doko> slangasek: please merge cdbs: https://launchpad.net/ubuntu/+source/gdb/7.12-0ubuntu2
[21:12] <slangasek> doko: done, though feel free to claim that one from me at any time ;)
[21:13] <doko> maybe we should work on removing cdbs ...
[21:32] <nacc> LStranger: that should be fine (LP: #..., LP: #...) I'm not sure LP: #...,... is supported.
[21:59] <pitti> bdmurray: sure! that should be quick to do (if there is no PPA and no git branch)
[22:10] <bdmurray> nacc, LStranger: LP: #, # works
[22:11] <nacc> bdmurray: ah good to know!
[22:11] <pitti> bdmurray: done; I fully followed the current design (i. e. euphemism for "it looks just as ugly")
[22:12] <bdmurray> nacc: $changes =~ /lp:\s+\#\d+(?:,\s*\#\d+)*/pig is the perl re
[22:16] <nacc> bdmurray: thanks, I should have just checked myself! :)
[22:16] <bdmurray> nacc: Its not the easiest thing to find. ;-)
[22:17] <juliank> If someone else is able to repro bug 1642386 - please let me know.
[22:18] <juliank> I've now added most of the repos listed by sarnold to my xenial chroot, but don't manage to repro it yet
[22:19] <bdmurray> I've been running 1.2.15 w/o issue since you asked for testing.
[22:20] <juliank> I assume it's a corner case somewhere, that's why it's high
[22:22] <juliank> Fixing this will likely require manual interaction on broken machines, as apt not being able to update repos obviously means it can't fetch newer apt versions :/
[22:33] <LStranger> bdmurray: thank you very much!
[22:39] <juliank> bdmurray: Another somewhat annoying thing is that 1.2.16 to fix the ValueErrors in ubiquity and friends is already tagged and in the -proposed queue (but some the bugs have no proper SRU [test case] sections yet...)
[22:39] <juliank> -> If this needs some form of hotfix, it might get weird versioning wise :/
[22:42] <juliank> Actually, I don't have a clue how to test the bug fixed in 1.2.16. I just know that it fixes them with 99% probability :)
[22:43] <juliank> The "install google chrome .deb" in gdebi-gtk thing seems kind of straight-forward though, should probably work in a german locale.
[22:43] <juliank> Testing the instance in the installer is probably tough
[22:47] <bdmurray> juliank: aren't there crashes at errors for most of the fixes? the new version not showing up there, which might require a DB query, is good enough for this SRU team member.
[22:51] <juliank> bdmurray: The two bugs have ValueError tracebacks AFAIK.
[22:51] <juliank> Then again, even once 1.2.16 is in -proposed, who is going to run ubiquity against it?
[22:56] <bdmurray> juliank: we could use a daily build for the xenial iso and it'll end up getting used w/ the next point release
[22:57] <juliank> Well, I don't think I'll hear any news in the next minutes on the new APT bug, so I'm going to sleep for a bit - hopefully there'll be more info tomorrow.
[22:57] <juliank> bdmurray: if you say so :)
[23:16] <LocutusOfBorg> cjwatson, sorry for bothering but this python error seems a bug https://code.launchpad.net/~costamagnagianfranco/+recipe/boinc-daily