[05:04] <slangasek> pitti: morning! looks like autopkgtest runners are stalled on amd64,i386,ppc64el; the juju node seems to show some sort of image mastering job running for the past couple of hours; is this expected maintenance?
[05:30] <cpaelzer> good morning
[06:02]  * Son_Goku sighs
[06:02] <Son_Goku> I was really hoping that my patches to ondrej for php7.0 would have been merged in by now
[07:10] <Mirv> @pilot in
[07:32] <pitti> Good morning
[07:34] <pitti> slangasek: php-* migrated, so I suppose this got sorted out with my infra cleanups yesterday evening
[07:34] <pitti> slangasek: runners stalled> yeah, I got tons of worker failures over the weekend, apparently some neworking cloud trouble again
[07:34] <pitti> slangasek: but all good now
[08:03] <cpaelzer> pitti: I didn't realise that was the difference between autopkgtest and auto-package-testing - thanks for fixing the tagging in the bug
[08:04] <pitti> cpaelzer: no worries, that's a bit subtle indeed :)
[08:19] <dholbach> good morning
[08:36] <slangasek> pitti: right, lots of things being rebooted for the security update, wonder if these systems should recover more automatically
[08:36] <pitti> slangasek: well, apparently they did
[08:36] <slangasek> ah, ok
[08:36] <pitti> slangasek: I didn't do anything this morning
[08:36] <slangasek> :)
[08:37] <pitti> well, I'm reviewing failures on excuses.html, but no manual infra work
[08:37] <pitti> slangasek: every six hours there is a cronjob which deletes orphaned instances and restarts all workers
[08:38] <pitti> slangasek: that usually cleans up after networking or other scalingstack issues which happen and get fixed within a few hours
[08:40] <slangasek> pitti: as far as php-* migrating, it still looks buggy to me that britney triggered tests against the -proposed version and then this didn't get dispatched... I think I wound up manually retriggering those tests I mentioned
[08:40] <pitti> slangasek: ah, that's only a display bug -- britney does not trigger a particular version of a test
[08:40] <slangasek> hmm, ok
[08:40] <pitti> slangasek: it just says "run tests for package foo against the proposed version of bar"
[08:41] <pitti> i. e. the trigger is versioned, but not the test
[08:41] <pitti> and once the test actually ran, britney shows the "real" version
[08:41] <pitti> but for the "in progress" it apparently currently shows the -proposed version, which is wrong more often than not
[08:41] <pitti> I guess I should just not show it at all
[08:41]  * pitti adds a WI
[08:42] <pitti> ah well, that's not actually that easy UI wise, as all arches are grouped on one line as long as the version matches
[08:42] <pitti> so maybe -- if there is a line with *only* "in progress", don't show a version
[08:55] <doko> pitti, slangasek: dns problems on Sunday
[09:36] <Mirv> @pilot out
[09:36]  * dholbach hugs Mirv 
[09:36] <Mirv> pitti: hmm I guess you're not pilotting anymore since you did on Friday?
[09:36] <pitti> @pilot out
[09:37]  * Mirv hugs dholbach 
[09:37] <pitti> Mirv: indeed, thanks
[09:50] <doko> LocutusOfBorg, is the powerpc ftbfs in insighttoolkit4 fixed in your last upload?
[09:52] <LocutusOfBorg> doko, I don't think so
[09:52] <LocutusOfBorg> specially because seems more a compiler ICE
[09:52] <doko> and the i386 test failures?
[09:53] <LocutusOfBorg> should be
[09:56] <infinity> That's not an ICE.
[09:57] <infinity> But it probably means some large function needs splitting.
[09:58] <LocutusOfBorg> I don't remember the reason, I'm trying to get the package migrate, and i386 is the blocker AFAICS
[09:58] <doko> LocutusOfBorg, any reason why you build with 8 cpu's in parallel on amd64?
[09:59] <LocutusOfBorg> you disabled the parallel build on amd64, and the build was taking something like a week. I did a parallel=2 and it worked, I did a parallel=4 and it worked, today I did a parallel=8. I'm not sure why you disabled it
[10:00] <infinity> LocutusOfBorg: Don't set an explicit parallel= unless you're trying to set it *lower* than the buildds do.
[10:00] <LocutusOfBorg> infinity, do the amd64 builds defaults to 8?
[10:00] <infinity> (pretty please)
[10:00] <doko> the build now takes 16h, the machine swapping ...
[10:00] <infinity> LocutusOfBorg: They default to 4 these days, probably.
[10:00] <LocutusOfBorg> ough, sorry, I thought it was 16
[10:00] <infinity> LocutusOfBorg: (They default to $(nproc))
[10:01] <LocutusOfBorg> for some reasons I had 16 in my mind, probably because DebOMatic is defaulting to that
[10:01] <infinity> "Initiating build PACKAGEBUILD-9048365 with 4 jobs across 4 processor cores."
[10:01] <LocutusOfBorg> bad monday
[10:01] <LocutusOfBorg> I can cancel it if needed and reupload
[10:03] <infinity> +  * Drop intrinsics patch: upstream.
[10:03] <infinity> LocutusOfBorg: You also don't need to mention that in every upload. ;)
[10:05] <LocutusOfBorg> that was a copy-paste error, I thought about removing, but probably forgot that :)
[10:13] <pitti> cjwatson, infinity: did we disable autosyncs? (we should as we are in FF, but last Friday during my sponsoring shift it appeared as if they were still on)
[10:15] <pitti> cyphermox: can you please have a look at bug 1548252? I'm fairly sure that this used to work at some point, as I often do that to investigate handling of cryptsetup devices during boot
[10:16] <doko> pitti, they are disabled
[10:16] <pitti> doko: thanks
[10:20] <doko> The following packages have unmet dependencies:
[10:20] <doko>  php-symfony-proxy-manager-bridge : Depends: php-proxy-manager (< 2~~) but 2.0.0-1ubuntu1 is to be installed
[10:21] <doko> slangasek: according to the changelog you fixed the tests to work with php-proxy-manager 2
[10:38] <cjwatson> pitti: I disabled them last thing Thu / early Fri morning, so it would've depended on your criteria :-)
[10:39] <pitti> cjwatson: ack, thanks for confirming
[11:08] <Kryczek> Hi! I do not know much about the Ubuntu project apart from being a very happy user of it since 5.04, and I apologize if this has been mentioned to you already several times, but as far as I understand the Ubuntu live media are made using live-build which is now sadly orphaned: https://packages.qa.debian.org/l/live-build.html . I offered my help of course but I have neither the knowledge nor the time
[11:08] <Kryczek> to contribute much so I am wondering if by any chance the Ubuntu community with all its might could perhaps save this crucial software?
[11:17] <LocutusOfBorg> fixed and reuploaded itk4
[11:21] <doko> cjwatson, https://launchpadlibrarian.net/241356698/buildlog_ubuntu-xenial-amd64.haskell-bindings-sane_0.0.1-7build1_BUILDING.txt.gz (showed up in the ghc transition tracker). any idea about the ftbfs?
[11:57] <doko> apw, any idea when the linux block-proposed issue gets removed?
[11:59] <cjwatson> doko: yes, I know about that, it's because of IIRC libsane's pkg-config version having a ~ in it or some such, need to figure out how to work around that in cabal
[12:35] <doko> LocutusOfBorg, please could you use the -v<last ubuntu version> option when merging packages?
[12:41] <LocutusOfBorg> ok, I wasn't aware of this
[12:41] <LocutusOfBorg> ok
[12:59] <xnox> bdmurray, could you please subscribe foundations bugs to libica package for the MIR 1546987 ? it's an s390x specific thing.
[13:08] <rbasak> doko: btw, I don't think we have any process of telling new uploaders how to do such things. People get upload rights but no instructions on dput, etc, and of course before direct uploading, sponsorees don't need to know.
[13:08]  * rbasak bets that caribou doesn't know either
[13:09] <rbasak> The wiki could do with a "Congratulations, so you're a new uploader!" page with instructions on dput, -v<last ubuntu version> for merges, etc, and get the DMB to point to that.
[13:11] <Laney> Like https://wiki.ubuntu.com/MOTU/New ?
[13:11] <ginggs> it is mentioned here: https://wiki.ubuntu.com/UbuntuDevelopment/Merging#Get_your_work_uploaded
[13:12] <doko> xnox, bdmurray: done
[13:12] <doko> rbasak, like Laney said
[13:13] <rbasak> Ah, great!
[13:13] <rbasak> Nobody pointed me to that page when I became an uploader/MOTU though. Maybe that's the only missing link then.
[13:13] <xnox> doko, thanks.
[13:13] <doko> rbasak, please could you address https://launchpad.net/bugs/1546957 ? now blocking another transition (or you might want to fight with Laney about the bug subscription ;)
[13:13] <caribou> rbasak: doko: I found out by reading your merge doc; I used it for clamav
[13:14] <Laney> boring troll
[13:14] <caribou> rbasak: oh, I didn't know about dput, I thought you meant dpkg-buildpackage
[13:18] <rbasak> doko: tons of !server stuff depends on lua. So why should this be a server bug subscription? I accept the nmap rdep, but this seems pretty generic. I'll defer to jgrimm I think.
[13:18] <rbasak> (why uses nmap with lua anyway?)
[13:18] <rbasak> who
[13:18] <doko> rbasak, fix it to rmove the dependency
[13:22] <rbasak> doko: I'll add it to our queue to look at.
[13:46] <flexiondotorg_> I have a package update I'd like beg gets sponsored.
[13:46] <flexiondotorg_> Anyone able to help? - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1548133
[13:50] <pitti> doko: I'm looking at the tomcat7 → tomcat8 change on component-mismatches, unless you already did
[13:51] <pitti> it seems some packages need to be updated for libservlet3.0-java → libservlet3.1-java
[13:51] <doko> pitti, sure, please make sure to revert seb128's change for hsqld1.8
[13:51] <pitti> doko: right, that's another step
[13:52] <seb128> it's not "my changes", I only merged that package because nobody else was doing it
[13:52] <pitti> seb128: yeah, it was entirely right at the time, that wasn't a blame
[13:52] <seb128> good :-)
[13:53]  * doko never blames
[13:54] <pitti> Debian's dependency is also wrong
[13:54] <pitti> Depends: libservlet2.5-java, ${misc:Depends}
[13:54] <pitti> <pathelement location="/usr/share/java/servlet-api-3.1.jar"/>
[13:54]  * pitti will file a b gu
[13:54] <pitti> bug too
[13:54] <pitti> l
[14:03] <jamespage> please could an archive admin promote python-openvswitch to main; its source is already in main and its needed for neutron
[14:04] <jamespage> looks like it popped into main for a bit and then when back to universe?
[14:06] <pitti> jamespage: done
[14:07] <jamespage> pitti, ta
[14:20] <pitti> jamespage: just FYI, I'm tracking the tomcat7 → 8 changes on bug 1539903
[14:21] <pitti> there might be some temporary hiccups, but I'm tracking component-mismatches etc.
[14:23] <abeato_> pitti, hi, I have a patch for ntp (bug #1526264), who should be best to take a look?
[14:23] <pitti> abeato_: please subscribe ubuntu-sponsors
[14:24] <abeato_> pitti, ok, and then should I send an e-mail to the list?
[14:26] <doko> I'm planning to start an archive test-rebuild this week, maybe tomorrow, once the current linux/bind9/gcc-5 migrate. Is there anything which should be included? If yes, what?
[14:27] <doko> pitti, jamespage, rbasak, Laney, seb128, smoser, apw: ^^^
[14:27] <xnox> infinity, glibc 2.23? ^
[14:27] <seb128> doko, nothing special on the desktop side
[14:28] <Md> I am testing the 16.04 installer, but I have noticed that my custom partman recipe now creates an extended partition instead of a primary one. has something changed?
[14:29] <xnox> Md, better ask on #ubuntu-installer. and/or highlight cyphermox. Loads of things have changed in 16.04 installer, as a lot of d-i components got upgraded.
[14:30] <Md> I have not tested debian/unstable, but the same recipe works as expected with the debian/stable installer
[14:32] <ben__> hi, could someone from the archive team please have a look at the binary removal request (bug #1542398)? the old armhf binary is blocking the new version from migrating to release for two weeks now
[15:03] <doko> rbasak, please subscribe to tomcat8 bug reports (like for tomcat7), so that pitti's uploads can build
[15:06] <pitti> doko: nothing that needs squeezing in from my side
[15:08] <seb128> doko, we might have a poppler soname change, better before or after?
[15:09] <doko> seb128, well, upload today and start the transition today
[15:09] <rbasak> doko: tomcat8> done. I'm not sure I understand why it would be a problem for pitti, but it needs doing anyway.
[15:09] <seb128> doko, ok
[15:09] <pitti> rbasak: it's just for completing the demotion of tomcat7 and promotion of tomcat8
[15:09] <doko> rbasak, he already promoted; or else he would only see dep-waits
[15:10] <pitti> stuff is building now
[15:25] <rharper> I've a bug that's now fixed in xenial, but not fixed in trusty;  how do I add task entry for say Trusty ?  I see the Also affects project, distro/package and nominate; not sure which one of those (or something else) I'd use to indicate it's also broken in trusty (so I can propose an SRU)
[15:29] <rbasak> rharper: nominate Trusty
[15:35] <rharper> rbasak: thanks!
[16:01] <doko> rbasak, fyi, https://launchpad.net/ubuntu/+source/nmap/7.01-2ubuntu1  but some features are disabled
[16:04] <doko> pitti, does virtualbox need testing against proposed (kernel)?
[16:10] <pitti> doko: you mean -7 regresses virtualbox and that holds back the proposed virtualbox?
[16:11] <pitti> doko: that's a special case for the kernel team indeed, they want to test DKMS stuff against the proposed kernel always
[16:11] <pitti> so we don't do apt pinning for the kernel
[16:12] <pitti> doko: but it's clearly not a regression of that rebuild itself, so I'm fine with allowing that rebuild to unblock the transition
[16:13] <pitti> it's a glaring red regression on http://people.canonical.com/~kernel/status/adt-matrix/xenial-linux-meta.html, so it should be on apw's radar
[16:14] <apw> pitti, regressions on virtualbox and spl-linux are almost always not regressions, as we have the same version in the kernel and that errors, but i hint them on manual review
[16:42] <marlinc> cking, you around?
[16:43] <marlinc> Anyway, the default ZFS compression algorithm is lz4 not gzip-6
[16:47] <cking> marlinc, ok, i'll correct that in the wiki
[16:47] <sarnold> I thought the default was lzjb? and that folks -should- change it to lz4?
[16:51] <cking> bah, I can't recall now, I need to double check that
[16:55] <Son_Goku> wasn’t it lzo for speed?
[17:01] <pepee> sarnold, did I talk with you about this bug a few days ago?  https://bugs.launchpad.net/ubuntu/+source/linux-lts-wily/+bug/1545401
[17:03] <sarnold> pepee: I think before you filed it, yes; I hadn't seen the report thuogh. nice.
[17:05] <sarnold> pepee: jeeze, good thing your reproducer is a thuosand times easier than "just install mosix and migrate a process". sheesh.
[17:07] <sarnold> pepee: interesting, looks like the rhat bug was filed via a vmware guest.. yours has vbox modules linked in; can you reproduce it with a kernel that doesn't have vbox loaded? (best if it -never- had vbox modules loaded..)
[17:07] <marlinc> sarnold, The  current default compression algorthm is either lzjb or, if the lz4_compress feature is enabled, lz4.
[17:07] <marlinc> lz4_compress is enabled by default :)
[17:07] <marlinc> Thanks cking!
[17:08] <cking> lz4 is by default, had to check that for sure
[17:08] <marlinc> cking, is it possible for others to work on that document?
[17:08] <pepee> sarnold, mine isn't a VM, though
[17:08] <marlinc> sudo zpool create example raidz /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg
[17:08] <cking> marlinc, it should be editable by anyone with wiki acess
[17:08] <marlinc> That should be raidz3 :)
[17:08] <sarnold> pepee: yeah; still, those modules are .. iffy.
[17:09] <marlinc> '3 parity bits, allowing for 3 disk failures before losing data with performance like RAIDZ2 and RAIDZ. Example, create a 3 parity 6 VDEV pool:'
[17:09] <doko> barry, did you omit the python-pip merge by intent?
[17:09] <pepee> sarnold, I linked to the sources, I guess (wild guess...) that there is a problem with some API
[17:09]  * cking fixes that too, thanks for spotting that marlinc
[17:09] <sarnold> marlinc: ah! good. lz4 is a much better default. is that something speicific to zfsonlinux implementatio or is that common to all openzfs now?
[17:09] <marlinc> I don't think I have that cking
[17:09] <pepee> sarnold, true... I'd have to test later, I'm not using 4.2 anymore, too risky :(
[17:09] <sarnold> pepee: heh, the source is what made me wonder -- why was your memory allocation going through a numa-aware code-path. seemed funny on a laptop. ;)
[17:10] <marlinc> Not sure sarnold, I looked it up in the ZFS man pages on my Ubuntu install
[17:10] <sarnold> marlinc: woo :)
[17:10] <cking> bah, wiki timeouts
[17:10] <pepee> sarnold, my laptop is loading numa stuff, not sure why... I think I installed some packages and that came as dependency
[17:11] <marlinc> :)
[17:11] <pepee> in fact, my laptop doesn't even support iommu and other things being loaded, heh
[17:12] <barry> doko: yes, i think we can drop the ubuntu deltas.  i merged --user by default to the debian version and i believe the shebang should be correct now too.  i'll double check the proposed version and look at excuses
[17:12] <marlinc> What should I do if I find something else cking?
[17:12] <pepee> anyway, thanks sarnold, I'll do some testing later
[17:12] <cking> marlinc, if you can't edit it, ping me, or email me colin.king@ubuntu.com
[17:13] <sarnold> pepee: ha! click around on that a bit -- the _one_ caller checks to _ensure_ that the page is PROT_NONE before calling do_numa_page
[17:13] <sarnold> pepee: .. but do_numa_page BUGs on that specific condition
[17:16] <marlinc> Okay cking :p
[17:19] <pepee> sarnold, the caller is follow_page_pte()?
[17:20] <sarnold> pepee: handle_pte_fault()
[17:21] <sarnold> apw: the kernel team's demotativation bug bot hasn't commented on 1545401 yet -- is it hooked up to look for bugs in the linux-lts-* packages too?
[17:25] <pepee> sarnold, oh, I see... I think, you mean   3265  if (pte_protnone(entry))      3266  return do_numa_page(mm, vma, address, entry, pte, pmd);  ?
[17:26] <pepee> shouldn't the dev that made the patch have also change the other functions/files?
[17:26] <apw> sarnold, quite possibly not ... bjf ^
[17:27] <apw> sarnold, i would hope they would get retargeted to linux as things need to be fixed in the primaries first in the main
[17:28] <sarnold> apw: yeah, that'd make sense, but e.g. linux-lts-utopic is a bit strange, as linux in utopic is eol ..
[17:29] <bjf> sarnold, apw, i haven't looked but no the bot most likely isn't looking at those
[17:29] <sarnold> pepee: yeah, some time with git blame to figure out what happened to the code might help figure out if that's just missing a ! before the call or if this is going to be a huge change..
[17:30] <pepee> sarnold, https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-December/123285.html
[17:30] <apw> sarnold, yep, that one is a strange one for sure, and that one filing direct does make sense, so that isn't confusing at all
[17:32] <sarnold> pepee: heh, he's one of the few who I might have expected to understand this code :) haha
[17:34] <pepee> sarnold, the earliest one I could find:  http://lkml.iu.edu/hypermail/linux/kernel/1411.1/05082.html   ,  patchset is  http://lkml.iu.edu/hypermail/linux/kernel/1411.1/05086.html
[18:00] <pepee> sarnold, apw: what does invalid means?
[18:01] <apw> pepee, invalid where?  in a bug it normally means that the bug is not applicable to a specific task (series/package combination)
[18:02] <pepee> apw, ah, ok. I submitted bug # 1545401
[18:03] <apw> bug: #154401
[18:04] <apw> bug: #1545401
[18:04] <apw> pepee, right in that one the bug is reported against linux-lts-wily in xenial, which makes no sense
[18:04] <apw> pepee, so you are seeing me targetting it to trusty where that kernel exists and adding linux tasks as we
[18:05] <pepee> ah, heh
[18:05] <apw> pepee, have to fix it there first, the invalid ones are mostly non-existant combinations
[18:05] <pepee> I hadn't noticed, sorry
[18:07] <pepee> I had no idea this was a security bug
[18:14] <ginggs> doko: dpkg: error processing archive /var/cache/apt/archives/libtesseract4_3.04.01-2_amd64.deb (--unpack):
[18:14] <ginggs>  trying to overwrite '/usr/lib/libtesseract.so.3.0.4', which is also in package libtesseract3v5 3.04.00-5ubuntu1
[18:16] <doko> Laney, ^^^
[18:16] <Laney> Someone synced it
[18:17] <Laney> and that person was doko
[18:17] <doko> ahh, crap, we need the Breaks/Replaces ... will fix
[18:20] <doko> ginggs, hmm, can you file a Debian issue? that should show up for unstable as well, it has the conflict, but misses the replaces?
[18:21] <ginggs> doko: ok
[18:24] <doko> and the somebody not merging was Laney
[18:25] <ginggs> doko: looks like it is already filed, debian #815056
[18:26] <doko> argh
[18:27] <infinity> Uhh, why does a package named libtesseract4 contain libtesseract.so.3?
[18:28] <infinity> Someone doesn't know how SONAMEs work.
[18:29] <sarnold> pepee: I hit the 'security' flag because a series of user-space operations appeared to put the kernel in a state that it certainly didn't expect
[18:30] <pepee> sarnold, ah
[18:30] <pepee> you are right... I'm a bit slow
[18:32] <pepee> sarnold, wondering if it's exploitable :P
[18:34] <sarnold> pepee: my first guess is that it's not exploitable for privilege escalation but it may have other surprising effects
[18:38] <pepee> I just noticed, http://lxr.free-electrons.com/ident?v=4.2;i=do_numa_page says do_numa_page() is referenced in its own definition and in the bugged line... what's the point of that function, then?
[18:39] <pepee> bah, I wish I knew more about kernel dev'ing
[18:42] <sarnold> the function is defined on the first (3133) and called on the second (3266)
[18:43] <sarnold> because it's only called from one place it -could- have been written inline in the handle_pte_fault() function and avoid the function call, but that kind of programming leads to thousand-line functions that are impossible to think about :)
[18:49] <pepee> ah, ok
[20:07] <doko> barry, did you omit the python-pip merge by intent?
[20:07] <barry> doko: did you see my previous response?
 doko: yes, i think we can drop the ubuntu deltas.  i merged --user by
[20:07] <barry>         default to the debian version and i believe the shebang should be
[20:07] <barry>         correct now too.  i'll double check the proposed version and look at
[20:07] <barry>         excuses  [12:12]
[20:07] <barry>  
[20:08] <barry> doko: the pkg looks good.  i don't know why python-virtualenv is holding it back.  a local adt-run passes and the a.u.c artifact is mysterious
[20:09] <doko> hmm, didn't see the reply.
[20:09] <barry> doko: anyway ^^
[20:09] <doko> barry, it's because python-pip-whl is not installable
[20:10] <barry> doko: seems to be here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160222_195823@/log.gz
[20:13] <doko> barry, python-virtualenv is not considered for migration, because the tox autopkg tests fail
[20:14] <barry> doko: right, but i cannot reproduce that locally in adt-run with -proposed enabled
[20:15] <doko> barry, well, ask pitti to hint it
[20:15] <barry> pitti: ^^ any thoughts?
[20:16] <doko> python-setuptools shows some regressions too, and afail python-pip has a breaks to the version in the release pocket
[20:16] <pitti> barry: local adt-run> did you enable -proposed?
[20:16] <pitti> ah, you did
[20:16] <barry> pitti: i used a xenial-amd64 chroot w/-proposed enabled and verified the python-virtualenv and python-tox versions that got installed there.  passes beautifully for me
[20:17] <pitti> barry: let me first re-run the test against all of -proposed, maybe there's some hidden dependencies there
[20:17] <doko> barry, and setuptools triggers virtualenv failures
[20:17] <barry> pitti: thanks
[20:18] <mdeslaur> cyphermox: any plans on merging sudo?
[20:18] <barry> doko: that looks like it's using the old virtualenv pkg, but that has no tests
[20:18] <doko> plus pbgenomicconsensus and python-pex
[20:19] <doko> barry, pitti: can you retry with -proposed enabled?
[20:19] <pitti> doko: just did
[20:19] <barry> as did i
[20:19] <Noskcaj> Could someone please upload the newest youtube-dl to xenial? I've test built it, but this package needs to be treated almost like a rolling release for it to function properly (A number of it's releases are compatibility fixes)
[20:19] <pitti> retry-autopkgtest-regressions | sed 's/run-autopkgtest/& --all-proposed/' | sh
[20:19] <pitti> err, and a | grep python
[20:19] <barry> pex may be intermittent.  /me retries
[20:20] <pitti> doko, cjwatson, infinity, slangasek: FYI: I added a --all-proposed option to run-autopkgtest the other day that disables apt pinning
[20:20] <cyphermox> mdeslaur: if it's rush, feel free to do it.
[20:20] <cyphermox> I'm assuming you ask because of sudoedit?
[20:20] <doko> pitti, am I allowed to use this as well?
[20:20] <pitti> doko, cjwatson, infinity, slangasek: FYI: easier than cobbling together tons of --trigger options
[20:20] <mdeslaur> cyphermox: yeah, and I'd like to backport the version we're going to ship in xenial into the stable releases after
[20:20] <pitti> doko: sure; I thought you used run-autopkgtest/retry-autopkgtest-regressions yourself before we had the web-clicky stuff?
[20:21] <mdeslaur> cyphermox: and I'd rather do it with 1.8.15
[20:21] <cyphermox> mdeslaur: yeah, I understand
[20:21] <barry> pitti, doko pex failures are reproducible locally
[20:22] <doko> probably a missing build/test dependency,
[20:22] <doko> pitti, is there consensus to ignore pbgenomicconsensus? ;)
[20:22] <pitti> but it has *such* a funny package name!
[20:22] <barry> doko: that's probable, since it shuts off pypi and it's a connection refused.  i need to update pex anyway
[20:23] <pitti> doko: yep, the history is fairly red-heavy, I'll hint it
[20:23] <cyphermox> pitti: up in the top 10 with datefudge and all.
[20:23] <doko> barry, it would be nice to modify pip to print out what it wants to fetch for such cases ...
[20:23] <barry> doko: at least desktop is down to just samba keeping py27
[20:24] <barry> doko: indeed, i've wanted that for a long time.  next time it bugs me too much i'll give it a look
[20:24] <pitti> cyphermox: libcatalyst-authentication-credential-authen-simple-perl absolutely belongs in that list too
[20:25] <pitti> Package: how-to-trigger-buffer-overflows-in-dpkg-parser-codes
[20:25] <pitti> doko: ah, it already has a hint, just needs a version bump
[20:26] <barry> doko: server has nothing keeping python python2.7 on it so i guess it just needs to be deseeded
[20:27] <barry> and i think smoser has a todo for that
[20:27] <smoser> i'm open to someone else doing that.  i dont think it is seeded anywhere is it
[20:28] <smoser> i have a TODO to blacklist it from the images
[20:28] <smoser> https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
[20:28] <pitti> doko: hinted aplpy/s390x too while I'm at it
[20:28] <barry> smoser: i grabbed today's daily and `apt-get purge python2.7 libpython2.7`.  it only purges those, nothing else
[20:29] <barry> smoser: yes.  time to add that blacklist?
[20:29] <pitti> barry: http://autopkgtest.ubuntu.com/running.shtml#pkg-tox doesn't look good, several Fs
[20:29] <infinity> It shouldn't need blacklisting.
[20:29] <smoser> so how'd they get there?
[20:29] <smoser> we wanted blacklist to fail build
[20:29] <infinity> If it's ending up on the images, we should figure out why, not hack around it.
[20:29] <smoser> i agree with infinity, but i thought the intent was to make things fail
[20:30] <barry> pitti: huh.
[20:30] <barry> smoser, infinity that's what i thought too
[20:30] <doko> barry, ahh, should be @builddeps@, not @
[20:30] <infinity> smoser: There are lots of packages we don't want on images, we shouldn't force a failure every time one pops up.  python's not really special here. :P
[20:31] <infinity> But definitely, if there's no clear reason it's showing up in all those tasks still, we might want to investigate.
[20:31] <barry> doko: hmm, maybe so since it's running its own self tests
[20:32] <doko> barry, fixing this, while you prepare a new upstream
[20:32] <barry> doko: in tox, right?
[20:32] <barry> not pex
[20:32] <barry> or did you mean pex?
[20:32] <doko> I thought pex
[20:32] <barry> doko: oh, i was looking in the wrong place, just a sec
[20:33] <barry> doko: hmm, i don't think pex should use builddeps
[20:33] <barry> doko: textwrap comes from stdlib
[20:33] <doko> barry, not even the execute.sh test?
[20:34] <barry> doko: right, not even that.  it's entirely possible something's changed tho
[20:34] <barry> doko: but i'll verify as i prep the new version
[20:34] <infinity> smoser: FWIW, python2.7 isn't in the server livefs manifest anymore.
[20:34] <infinity> barry: How did you install server?
[20:35] <barry> infinity: grabbed xenial-server-amd64.iso from here: http://cdimage.ubuntu.com/ubuntu-server/daily/current/
[20:35] <smoser> that is old.
[20:35] <smoser> due to some failing tests.
[20:35] <barry> infinity: installed in fresh vm, no downloads during install
[20:35] <smoser> :-(
[20:35] <smoser> fudge.
[20:35] <smoser> the change that would have released it went into postfix today
[20:36] <smoser>  https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1538198
[20:36] <doko> smoser, why not installing an image, then trying to remove python2.7-minimal and libpython2.7-minimal?
[20:36] <barry> smoser: ah, okay!  so maybe it'll be gone in the next successful image
[20:36] <smoser> er... it says 20th, but lamont made it sound like today i thought.
[20:36] <smoser> doko, ? i didnt come up with the idea to blacklist.
[20:37] <smoser> i think it is fine to test other ways for sure.
[20:37] <barry> smoser: it came up in the last uos session, but i don't remember who suggested it
[20:37] <barry> smoser: just that you didn't have your finger on your nose :)
[20:37] <infinity> smoser: Anyhow, please don't blacklist.  I'm on VAC today (see how well I'm doing), but if a plain install still pulls in python2, let's fix it tomorrow.
[20:37] <smoser> deal
[20:37] <barry> wfm
[20:37] <infinity> python2.7 is still in the "server" task, so something likely needs a nudge, but let's do it rightish.
[20:38]  * infinity goes back to ignoring IRC for a bit.
[20:41] <doko> coreycb, python-ironicclient wants some MIRs
[20:41] <coreycb> doko, thanks I'll take a look
[20:42] <doko> coreycb, python-restructuredtext-lint and python-doc8
[20:43] <coreycb> doko, ok I think we can drop those
[20:43] <coreycb> I'll work on it
[20:47] <pitti> ah, forgot one last tomcat7 dep apparently
[20:48] <pitti> https://launchpad.net/ubuntu/+source/libcommons-dbcp-java/1.4-5ubuntu2, thanks doko
[20:51] <smoser> i'm sure this is obvious to many of you
[20:51] <smoser> what am i doing wrong here ; http://paste.ubuntu.com/15174005/
[20:52] <smoser> or what am i suppsoed to do to have autoconf re-run
[20:53] <doko> smoser, never use 'configure' as a target
[20:54] <doko> you probably want a cdbs hook
[20:54] <smoser> i read that from https://wiki.debian.org/Autoreconf
[20:55] <doko> hmm, but that's in the autotools-dev section ...
[20:55] <doko> cdbs should die
[20:56] <sarnold> doko: also here https://wiki.debian.org/Autoreconf#debhelper_packages
[20:57] <doko> sarnold, and above that is the cdbs section
[20:58] <sarnold> doko: is your advice to not use 'configure' as a target specific to cdbs? or for all package types?
[20:58] <smoser> ok. so used
[20:58] <smoser>  +include /usr/share/cdbs/1/rules/autoreconf.mk
[20:59] <doko> sarnold, it's used as a dependency on a file, and when it get's regenerated, the time stamp changes, and it's run again during the build or the install
[20:59] <smoser> instead, and it got me back to why i went down that rathole.
[20:59] <smoser> http://paste.ubuntu.com/15174062/
[20:59] <sarnold> doko: it seems like a dangerous thing to do in general :) but there it is, in the wiki, twice :) hehe
[20:59] <smoser> what is pulling CPPFLAGS of -Werror=date-time
[21:01] <doko> sarnold, if you want to read a scary rules file, see ucommon
[21:02] <sarnold> doko: wow, that looks like highly unstable spaghetti.. i'd certainly be afraid of making any changes to that package
[21:03] <doko> smoser, export DEB_CFLAGS_MAINT_STRIP = -Wdate-time before including the dpkg-buildflags.mk
[21:03] <doko> sarnold, yep, took me some time to find something to fix the build :-/
[21:04] <doko> smoser, but the better option would be to use the system libltdl. but that maybe for another time ...
[21:05] <slangasek> LocutusOfBorg: looking for the wrong name, I guess ;)
[21:05] <smoser> doko, yeah, this is really just to test a  newer squid on trusty.  merge with debian is being done by rbasak.
[21:27] <barry> doko, pitti new pex uploaded.  now we just have to wait for sync to xenial
[21:50] <lamont> smoser: it got hung up in autopkgtest
[21:50] <lamont> sadly
[21:50]  * lamont is fighting with that still, 3.0.4-1 is the current "I think it works, adt doesn't" version
[21:52] <infinity> Man, poor NoneType is always being called out for its lack of attributes.
[21:53] <lamont> infinity: we should get it some attributes, yes?
[21:53] <lamont> :*(
[21:53] <lamont> mostly I'm just being sick today
[21:53] <infinity> lamont: testlib and test-postfix just seem to be entirely full of sad.
[21:53] <cjwatson> NoneType totally has attributes.  __class__, __repr__, ...
[21:53] <sarnold> infinity: *cough* vacation *cough* :)
[21:53] <lamont> tbf, I had nothing to do with them
[21:54] <lamont> cjwatson: hah
[21:54] <infinity> cjwatson: But never the attributes people want. ;)
[21:54] <cjwatson> Picky
[21:54] <infinity> sarnold: Oh, right.  That.
[21:58] <infinity> lamont: FWIW, the quick hack (if this is the fault of the py2->py3 porting of tests) could be to just revert all changes to debian/tests/* and then add python to debian/tests/control deps.
[21:59] <infinity> lamont: adt tests don't need dep closure with package deps.
[21:59] <infinity> (Fixing the bugs would be nicer though...)
[22:12] <cyphermox> pitti: have you seen https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1548524 ?
[23:15] <juliank> cyphermox: Sounds similar to http://bugs.debian.org/815590
[23:16] <cyphermox> indeed, I hadn't seen that one
[23:17] <cyphermox> lemme add links
[23:17] <juliank> It looks like something in the dbus-glib -> gdbus transition is messed up
[23:17] <cyphermox> yup
[23:17] <cyphermox> I'm familiar enough with dbus-glib, but not so much gdbus to tell what's wrong there
[23:18] <cyphermox> I looked a bit, seems like maybe device is NULL, but I haven't dug in more to find out why
[23:19] <juliank> It should be easily reproducible though, I just had to run upower -d about 2 to 3 times in a terminal.
[23:20] <juliank> On my Debian side, systemd-coredump lost the coredump ...
[23:24] <tjaalton> so how exactly does one create a git 'project' on the lp user account? simply pushing a branch fails with "project foo does not exist"
[23:25] <cyphermox> juliank: yeah, I got it from running upower -d too
[23:28] <tjaalton> ok, had to rename the project it seems.. 'linux' works, 'ubuntu-xenial' didn't
[23:36] <tjaalton> and still wrong, think I got it now :)