[00:03] <jbicha> nacc: this late in ubuntu's release cycle I suggest to go ahead and upload to Ubuntu now
[00:04] <nacc> coreycb: would your team be able to look at the ftbfs for python-eventlet and python-taskflow? I think both are openstack umbrella and seem to be test failures
[00:04] <nacc> jbicha: yep, that makes sense, that's what i was trying to figure out, on the balance, thanks!
[00:42] <jgrimm> nacc, ah, good to know. thanks
[01:01] <tsimonq2> thanks sarnold ;)
[01:01]  * tsimonq2 is testing that it installs cleanly atm
[01:05] <sarnold> tsimonq2: btw, your patch had dos-style crlf line endings.. I'm curious how you managed to do that :)
[01:06]  * tsimonq2 looks at .vimrc
[01:06] <sarnold> patch claimed to strip them all; I haven't verified that by hand yet..
[01:07] <tsimonq2> for some reason this is enabled... https://github.com/vim-scripts/PreserveNoEOL
[01:07] <tsimonq2> could that do it maybe?
[01:07] <tsimonq2> otherwise I'm not seeing what could be doing that
[01:14] <sarnold> tsimonq2: hrm. could be..
[01:14]  * tsimonq2 remove it
[01:14] <tsimonq2> *removes
[03:56] <tsimonq2> sarnold: thank you
[03:56] <sarnold> tsimonq2: and also thank you :)
[03:57] <tsimonq2> :)
[03:57] <tsimonq2> sarnold: have a good evening
[05:08] <ventrical> cq , cq goodmorning
[06:48] <Kinder-Pingvi> Hi guys! What is the difference between ubuntu 16.10 beta 2 and daily builds?
[06:48] <Kinder-Pingvi> Does daily changes are not included to beta 2?
[06:55] <ventrical> a beta 2 is like a relase candidate
[07:35] <Kinder-Pingvi> ventrical, what about new updates from daily? Does it will be included into release candidate?
[08:19] <ventrical> 4:30 am here in Canada .. I gotta get some rest :)
[08:27] <smb> Is there any preference whether a Vcs-Git line should become XS-Original-Vcs-Git or XS-Debian-Vcs-Git when I add a Vcs-Git line that points to Ubuntu? The former seems more in line with what is done with maintainer. Lintian does not seem to acknowledge any of those...
[09:47] <Unit193> pitti: You ever tried usrmerge on Ubuntu?
[09:53] <Unit193> FWIW, Debian #839046 / #839162.
[10:52] <cjwatson> Kinder-Pingvi: betas / release candidates are snapshots.  new updates aren't included in those snapshots, though if you install from the snapshot and apply all network-available updates you'll generally get a similar result.
[10:53] <cjwatson> smb: We settled on XS-Debian-Vcs-Git many years ago.
[10:53] <cjwatson> smb: (and yes, different from Maintainer for some reason I forget)
[10:55] <smb> cjwatson, Ok, thanks.
[11:12] <Kinder-Pingvi> cjwatson, thanks for answer! So, if I do 'apt full-upgrade' on ubuntu 16.10 I will receive that updated included into daily builds, right?
[11:12] <cjwatson> Kinder-Pingvi: yep, should do
[11:13] <Kinder-Pingvi> cjwatson, thank you!
[11:24] <coreycb> nacc, yep will look at those
[11:35] <pitti> Unit193: not tried directly on ubuntu, no; but looking forward to it anyway :)
[11:36] <jbicha> cjwatson: are you aware of any tools that use Xs-Debian-Vcs ?
[11:36] <pitti> Unit193: this makes the whole thing simpler, more robust, and finally puts a lid on these "but I want to have separate /usr without initramfs, and on NFS" kind of quarrels :)
[11:37] <cjwatson> jbicha: not off the top of my head
[11:37] <Unit193> pitti: Heh, as long as nothing breaks I don't really mind it either. :D  (Tempted to try it in a VM.)
[11:38] <jbicha> for most of the ubuntu-desktop packages, we just dropped the Vcs-Svn (pointing to pkg-gnome) and added Vcs-Bzr
[11:38] <pitti> Unit193: I think there's 4 packages left that break
[11:39] <pitti> Unit193: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=usrmerge;users=md@linux.it
[11:39] <pitti> Unit193: so that's a case of throwing them out of testing / demoting to -proposed IMHO; the rest is fine
[11:41] <coreycb> pitti, if you have a chance can you take a look at the xenial python-pylxd upload again please?
[11:42] <pitti> coreycb: I'm at a conference, just quickly checking IRC; so not today, sorry
[11:42] <coreycb> pitti, ok
[11:43] <coreycb> tjaalton, would you be able to review the python-pylxd sru upload to xenial?
[11:45] <tjaalton> coreycb: sure
[11:45] <coreycb> tjaalton, thanks
[12:43] <caribou> what is the best way to be sure that a main package will build w/o Universe dependancies ?
[12:44] <caribou> I'm using sbuild-launchpad-chroot with only updates+main so it will bomb on me if Universe dependancies exist
[12:44] <caribou> but that covers both build-only dependancies and binary ones, right ?
[12:45] <tumbleweed> that's a pretty good way
[12:47] <caribou> yes, but I need to differentiate b/w build-only & binary, that's what I'm missing
[12:48] <tumbleweed> I don't understand that question
[12:48] <caribou> tumbleweed: that's because it's a dump one ;-)
[12:49] <tumbleweed> build-only dependencise are presumably Build-Depends, which answers the "will build w/o universe" question
[12:49] <caribou> tumbleweed: all I need to do is check the control file
[12:50] <jbicha> caribou: are you concerned about runtime dependencies or build dependencies for universe?
[12:50] <caribou> jbicha: runtime deps; I uploaded clamav w/o noticing that I had added a runtime dep
[12:51] <caribou> jbicha: just want to trace back what I missed so I don't do it again & get chased by doko to MIR the runtime dep :)
[12:51] <tumbleweed> caribou: you could run the autopkgtests to tell you that
[12:51] <tumbleweed> or just manually eyeball the diff for changes in Depends
[12:51] <caribou> tumbleweed: hmm, good idea
[12:52] <jbicha> trying to build with only main will cause problems since some things like documentation build dependencies are in universe now since they don't add universe binary depenencies
[12:52] <tumbleweed> reading diffs is always a goo didea
[12:53] <Laney> binary debdiffs are quite nice
[12:53] <Laney> any kind of reading is not foolproof though
[12:53]  * Laney is a big enough fool
[12:53] <tumbleweed> sometimes they are too big to read, thoguh. Then filterdiff -i '*/debian/*' is handy
[12:53] <xnox> caribou, why do you care? universe is always enabled, and one can build-depend on universe packages.
[12:53] <Laney> xnox: you need to know if runtime universe deps are generated
[12:53] <xnox> the restriction is no Depends, Recommends, Built-Using in the resultant packages
[12:54] <caribou> xnox: Laney is right, this  is what happened to me with clamav
[12:54] <xnox> caribou, use $ check-mir ?
[12:56] <xnox> however, i wonder if check-mir is still correct
[12:56] <Laney> it only looks at debian/control IIRC
[12:56] <xnox> it would be nice to look at debian/$PKG/DEBIAN/control
[12:58] <caribou> xnox: Laney: yeah, looks like it only checks debian/control
[13:01] <caribou> ok,  I think I know now why I missed it the first time :
[13:02] <caribou> libclamav7 has Depends: ${misc:Depends}, ${shlibs:Depends} only
[13:02] <caribou> that got resolved as a runtime dependancy to libtfm-dev
[13:03] <caribou> This is not a problem on Debian but it becomes one for us
[13:03] <caribou> (libtfm-dev is the one in Universe)
[13:42] <jgrimm> hallyn, are you still looking after https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209 ?
[13:50] <hallyn> jgrimm: no?   i delete all libvirt related emails automatically
[13:52] <hallyn> jgrimm: as this is sysvinit and upstart only i doubt you care too much?
[13:53] <hallyn> and in fact the current solution isn't bad, just not perfect.
[13:54] <hallyn> (on mine it appears to be doing the 'sleep 2', which is fine.  o fcourse i also have mine overrided to not start to save battery :)
[14:02] <jgrimm> hallyn, no worries. I was just doing some housekeeping this morning and noticed that one just lingering out there
[14:02] <hallyn> jgrimm: but that one is 'fix released' right?
[14:02] <hallyn> it just has a 'maybe we should do it better one day' comment at theend,
[14:02] <hallyn> but really the 'do it better' should be to use socket activation in upstart
[14:03] <jgrimm> and your last comment was about planning to sru to trusty
[14:04] <hallyn> oh
[14:04] <jgrimm> hallyn, right, reporter was on trusty and hoping to get it SRU'd back.  that's what i was noting
[14:07] <hallyn> should be a trivial SRU fwiw
[14:07]  * hallyn bbl
[14:07] <jgrimm> hallyn, no worries.. that's what i was checking on, whether you'd lost interest or still interesting in seeing it through
[15:38] <hallyn> jgrimm: it'll be very simple, and would be a good one for a new contributor.  if you find one feel free to have them ping me to sponsor
[15:39] <jgrimm> hallyn, ack. thanks!
[15:45] <jgrimm> hallyn, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1285850   is there a SRU required to Xenial or just open task in case there is still an issue?
[15:46] <hallyn> jgrimm: i'm 99% sure that's fixed in xenial as stgraber has sru'd newer pkgs
[15:46] <nacc> to trigger a rebuild of python-docutils (which should not ftbfs now that there is a new xml-core), do I just upload a new version -- or will the next test rebuild just automatically pick up the fix?
[15:47] <jgrimm> hallyn, that's what it sort of sounded like. maybe we mark xenial/yakkety as Fix Released (with comment of please open a new bug if <blah, blah, blah>
[15:48] <hallyn> yup
[15:48] <jgrimm> tx
[15:48] <hallyn> thx - ttyl
[16:35] <nacc> jgrimm: i think you saw my update on heimdal last night -- how did you want to proceed?
[16:38] <jgrimm> nacc, which part? that debian is investigating dropping? or the current upload's failures?
[16:39] <nacc> jgrimm: yeah, that debian is dropping it -- and that the failures aren't resolved yet (and i'm not knowledgeable enough to know why ... yet). The debian patch leads to a different failure and i've updated hte upstream bug, but there hasn't been any response yet (afaict)
[16:40] <jgrimm> oh let me go look at the different failure
[16:41] <nacc> https://github.com/heimdal/heimdal/issues/175]
[16:41] <nacc> bah, without the ]
[16:41] <nacc> jgrimm: so the debian patch does fix something, but the tests still fail for me
[16:41] <nacc> right at the very end of the test
[16:43] <nacc> jgrimm: ha! ok, so i did a quick re-run manually and it passed
[16:43] <nacc> jgrimm: then ran `make check` manually and it passed as well
[16:44] <nacc> jgrimm: let me see if i can reproduce that, i wonder if the tests are running in parallel again
[16:44] <jgrimm> nacc, ah .. k
[17:43] <nacc> so i'm trying to help migrate heimdal along from proposed. I've got a build fix for it that fixes the current issue, but it still fails to sbuild due to a test failure. However, if i drop to the schroot after failure and run the test manually (eitehr `./debian/rules dh_override_auto_test` or `make check`), it passes. Any suggestions on how to debug that?
[17:45] <nacc> jgrimm: i can upload the fixed version, but i'm not sure what do about the above --^
[17:50] <jgrimm> nacc, ack
[18:14] <dobey> hmm, how can i get sbuild to run a script from the host system, inside the builddir
[18:15] <nacc> dobey: i think setup-hook does that, but it says its deprecated :)
[18:17] <dobey> and it just adds that to --chroot-setup-commands; which afaik are not executed within the builddir, and not sure it copies scripts into the chroot first
[18:18] <dobey> and pwd for --pre-build-commands is the wrong place too
[18:18] <nacc> dobey: yeah, reading https://wiki.debian.org/sbuild external commands
[18:18] <nacc> the implication is that it can run in the chroot
[18:19] <nacc> but not obvious which one
[18:19] <nacc> and not sure it's copied automatically as opposed to you need to copy it in first?
[18:19] <nacc> man sbuild implies at elast pre-build-commands and chroot-setup-commands are run in the chroot
[18:20] <nacc> although
[18:20] <nacc> 'EXTERNAL COMMANDS' contradicts that
[18:20] <dobey> pre-build-commands is run outside the chroot
[18:20] <nacc> chroot-setup/cleanup- are run in the chroot
[18:22] <nacc> dobey: man sbuild implies the wdir for the chroot-setup-command should be the BUILDDIR
[18:24] <nacc> dobey: but taht doesn't really help with your script question, i wonder if you coud in pre-build-commands copy the script in and then in the chroot-setup-command execute the script?
[18:25] <dobey> well pwd is nowhere near the chroot with pre-build-commands, so it doesn't help at all afaict
[18:25] <nacc> dobey: you can use %b
[18:26] <nacc> mabye?
[18:26] <dobey> ?
[18:26] <nacc> to get to the build-dir in the command definition
[18:26] <nacc> sbuild has some special escapes
[18:26] <dobey> hmm
[18:26] <nacc>   %b, %SBUILD_BUILD_DIR
[18:26] <nacc> and %p, %SBUILD_PKGBUILD_DIR
[18:27] <nacc> which can be used for these external commands and i guess sbuild substitutes them for you
[18:28]  * nacc is thinking something like `sbuild --pre-build-commands='cp /path/to/script/ %b/...'
[18:28] <nacc> dobey: %e might also work
[18:28] <nacc> dobey: and might be the fastest way, although i don't see any example :)
[18:29] <dobey> what's difference beetwee BUILD and PKGBUILD though?
[18:29] <dobey> latter is destinatio nfor binaries?
[18:29] <nacc> e.g., in my sbuild of heimdal
[18:30] <nacc> build/heimdal-yPecJ8 is BUILDDIR
[18:30] <nacc> build/heimdal-yPecJ8/heimdal-1.7~git20160703+dfsg
[18:30] <nacc> is PKGBUILDDIR
[18:30] <dobey> hmm ok
[18:30] <nacc> based upon the log output
[18:31] <nacc> %e's description implies it's the best way to copy data in/out from the host to the chroot
[18:31] <nacc> ah i see
[18:32] <nacc> what that does is something like schroot -c {id} --run-session -q -u root -p -- ....
[18:32] <nacc> so it runs a script defined in the host system but in the chroot
[18:32] <dobey> i don't see %e in the man page
[18:33] <nacc> oh im on 16.10 and it's new :)
[18:33] <nacc> dobey: sorry about that
[18:36] <dobey> no worries
[18:37] <nacc> dobey: so it seems like ther are some options for 16.04's sbuild ... 16.10's makes it a bit easier :)
[18:38] <dobey> oh nice. %p doesn't exist yet in --pre-build-commands
[18:39] <nacc> bah
[18:39] <dobey> but that might be ok
[18:39] <nacc> dobey: any cahnce you want to run 16.10 :)
[18:39] <dobey> no
[18:39] <dobey> i think this is actually running on a 14.04 host
[18:41] <nacc> ah
[19:00] <doko_> nacc: were there still some outstanding merges / ftbfs from your side?
[19:08] <nacc> doko_: i think the ones i've figured out are all uploaded
[19:08] <nacc> doko_: the openstack ones are all in -proposed per coreycb
[19:08] <doko_> ok, will be mostly offline until Oct 04
[19:08] <nacc> doko_: ok, i'll try and get the others figured out soon
[19:11] <nacc> doko_: http://qa.ubuntuwire.com/ftbfs/ only is for packages in -proposed, or is it the archive but using proposed?
[19:16] <dobey> 19:14:50 W: The %SBUILD_CHROOT_DIR and %r percentage escapes are deprecated and should not be used anymore. Please use %SBUILD_CHROOT_EXEC or %e instead.
[19:16] <doko_> nacc: everything is built using -proposed. however the test rebuilds find stuff which gets broken by some changes in the build dependencies
[19:16] <dobey> ah, hrmm
[19:16] <nacc> dobey: heh
[19:17] <nacc> doko_: got it
[19:17] <nacc> dobey: seems weird if the manpage didn't mention %e ...
[19:18] <dobey> nacc: i can't run man on the machine where the sbuild actually runs
[19:18] <dobey> nacc: it has sbuild 0.71 though
[19:19] <nacc> dobey: oh ok that's whats in 16.10
[19:20] <nacc> dobey: and afaict only in 16.10
[19:20] <nacc> yeah, they got rid of SBUILD_CHROOT_DIR when they added SBUILD_CHROOT_EXEC, i think
[19:20] <dobey> nacc: and whatever PPA it was installed from. this server is definitely not running 16.10 :)
[19:21] <nacc> dobey: ah true, that could be it
[19:21] <dobey> well, it's deprecated, but not gone yet
[19:21] <nacc> dobey: err, right, sorry, meant deprecated (one of the options at the time was to just outright remove it)
[19:21] <dobey> 'cat blub.txt | %SBUILD_CHROOT_EXEC sh -c "cat > blub.txt"'
[19:21] <dobey> ewww
[19:22] <nacc> it doesn't seem lik eyou should need to do that though
[19:22] <nacc> mabye you do, but that's not how i read the %e bits
[19:22] <dobey> that's the example in the man page
[19:24] <nacc> ah
[19:24] <dobey> and yeah, the description of %e suggests one must funnel data through STDIN/STDOUT of one process in the host and the proccess being run in the chroot
[19:25] <dobey> which is kind of nasty
[19:26] <nacc> it seems like if you just need to run a script in the chroot, you could do 'cat script | %e sh -c -s' ?
[19:26] <nacc> if you just needed to run a script
[19:26] <dobey> well i need to run a script at start up. but then i need to find files and copy them back out after the build
[19:27] <dobey> if i could just dumpt them in %SBUILD_BUILD_DIR and sbuild magically copies them back out, that'd work fine, but i'm not sure that's what it does
[19:28] <nacc> yeah, not obvious to me either ... i guess you could reverse the above command to extract from the chroot, if you konw what they are in post-build-commands
[19:29] <dobey> hmm, i'll try --finished-build-commands to see if dumping files in build dir just works
[19:34] <dobey> nope. sbuild doesn't just copy everything out. only the binaries/changes from debuild it seems :-/
[19:53] <nacc> dobey: hrm :?
[19:53] <nacc> *:/
[21:06] <tjaalton> anyone bumped into an issue with autopkgtest on lxd failing with "tar: ./control: Cannot change ownership to uid 12345, gid 12345, invalid argument"?
[21:08] <dobey> bah, dpkg-source doesn't get run until after --starting-build-commands :(
[21:17] <tjaalton> ah, needed to use sudo with autopkgtest
[21:51] <nacc> dobey: you mean the xtract step?
[22:20] <nacc> jgrimm: did you have a srcpkg handy that needed the vcs field change?
[22:20]  * jgrimm looks. been a while since I filed that bug
[22:22] <jgrimm> nacc, it was nspr
[22:22] <nacc> jgrimm: thanks
[22:22] <jgrimm> np
[22:27] <nacc> jgrimm: reproduced the python-cffi ftbfs on diamond, will debug there
[22:28] <nacc> i'm guessing it's an arch assumption
[22:28] <nacc> but not sure yet what
[23:04] <nacc> balloons: fyi, juju-core ftbfs on yakkety-proposed (http://qa.ubuntuwire.com/ftbfs/#ubuntu-server)
[23:05] <nacc> stgraber: fyi, lxc also ftbfs there
[23:15] <stgraber> nacc: yeah, doko_ is looking at it. We'll just revert his change if we can't get this resolved soon.