| jbicha | nacc: this late in ubuntu's release cycle I suggest to go ahead and upload to Ubuntu now | 00:03 |
|---|---|---|
| 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:04 |
| jgrimm | nacc, ah, good to know. thanks | 00:42 |
| tsimonq2 | thanks sarnold ;) | 01:01 |
| * tsimonq2 is testing that it installs cleanly atm | 01:01 | |
| sarnold | tsimonq2: btw, your patch had dos-style crlf line endings.. I'm curious how you managed to do that :) | 01:05 |
| * tsimonq2 looks at .vimrc | 01:06 | |
| sarnold | patch claimed to strip them all; I haven't verified that by hand yet.. | 01:06 |
| 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:07 |
| sarnold | tsimonq2: hrm. could be.. | 01:14 |
| * tsimonq2 remove it | 01:14 | |
| tsimonq2 | *removes | 01:14 |
| === juliank_ is now known as juliank | ||
| tsimonq2 | sarnold: thank you | 03:56 |
| sarnold | tsimonq2: and also thank you :) | 03:56 |
| tsimonq2 | :) | 03:57 |
| tsimonq2 | sarnold: have a good evening | 03:57 |
| === hikiko_ is now known as hikiko | ||
| ventrical | cq , cq goodmorning | 05:08 |
| 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:48 |
| ventrical | a beta 2 is like a relase candidate | 06:55 |
| Kinder-Pingvi | ventrical, what about new updates from daily? Does it will be included into release candidate? | 07:35 |
| ventrical | 4:30 am here in Canada .. I gotta get some rest :) | 08:19 |
| 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... | 08:27 |
| Unit193 | pitti: You ever tried usrmerge on Ubuntu? | 09:47 |
| Unit193 | FWIW, Debian #839046 / #839162. | 09:53 |
| ubottu | Debian bug 839046 in debootstrap "debootstrap: enable --merged-usr by default" [Normal,Open] http://bugs.debian.org/839046 | 09:53 |
| 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:52 |
| 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:53 |
| smb | cjwatson, Ok, thanks. | 10:55 |
| === hikiko is now known as hikiko|ln | ||
| 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:12 |
| Kinder-Pingvi | cjwatson, thank you! | 11:13 |
| coreycb | nacc, yep will look at those | 11:24 |
| pitti | Unit193: not tried directly on ubuntu, no; but looking forward to it anyway :) | 11:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| coreycb | pitti, if you have a chance can you take a look at the xenial python-pylxd upload again please? | 11:41 |
| pitti | coreycb: I'm at a conference, just quickly checking IRC; so not today, sorry | 11:42 |
| coreycb | pitti, ok | 11:42 |
| coreycb | tjaalton, would you be able to review the python-pylxd sru upload to xenial? | 11:43 |
| tjaalton | coreycb: sure | 11:45 |
| coreycb | tjaalton, thanks | 11:45 |
| === hikiko|ln is now known as hikiko | ||
| === marcusto_ is now known as marcustomlinson_ | ||
| caribou | what is the best way to be sure that a main package will build w/o Universe dependancies ? | 12:43 |
| 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:44 |
| tumbleweed | that's a pretty good way | 12:45 |
| caribou | yes, but I need to differentiate b/w build-only & binary, that's what I'm missing | 12:47 |
| tumbleweed | I don't understand that question | 12:48 |
| caribou | tumbleweed: that's because it's a dump one ;-) | 12:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| caribou | xnox: Laney is right, this is what happened to me with clamav | 12:54 |
| xnox | caribou, use $ check-mir ? | 12:54 |
| 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:56 |
| caribou | xnox: Laney: yeah, looks like it only checks debian/control | 12:58 |
| caribou | ok, I think I know now why I missed it the first time : | 13:01 |
| caribou | libclamav7 has Depends: ${misc:Depends}, ${shlibs:Depends} only | 13:02 |
| caribou | that got resolved as a runtime dependancy to libtfm-dev | 13:02 |
| 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:03 |
| === _salem is now known as salem_ | ||
| jgrimm | hallyn, are you still looking after https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209 ? | 13:42 |
| ubottu | Launchpad bug 1571209 in libvirt (Ubuntu Xenial) "Sockfile check retries too short for a busy system boot" [High,New] | 13:42 |
| hallyn | jgrimm: no? i delete all libvirt related emails automatically | 13:50 |
| hallyn | jgrimm: as this is sysvinit and upstart only i doubt you care too much? | 13:52 |
| hallyn | and in fact the current solution isn't bad, just not perfect. | 13:53 |
| 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 :) | 13:54 |
| 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:02 |
| jgrimm | and your last comment was about planning to sru to trusty | 14:03 |
| 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:04 |
| 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 | 14:07 |
| 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:38 |
| jgrimm | hallyn, ack. thanks! | 15:39 |
| 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:45 |
| ubottu | Launchpad bug 1285850 in lxc (Ubuntu Xenial) "interuppting lxc-clone can destroy source container" [High,Confirmed] | 15:45 |
| 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:46 |
| 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:47 |
| hallyn | yup | 15:48 |
| jgrimm | tx | 15:48 |
| hallyn | thx - ttyl | 15:48 |
| === victorp_ is now known as victorp | ||
| === dpm is now known as dpm-afk | ||
| nacc | jgrimm: i think you saw my update on heimdal last night -- how did you want to proceed? | 16:35 |
| jgrimm | nacc, which part? that debian is investigating dropping? or the current upload's failures? | 16:38 |
| 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:39 |
| jgrimm | oh let me go look at the different failure | 16:40 |
| 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:41 |
| 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:43 |
| 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 | 16:44 |
| === alexisb is now known as alexisb-afk | ||
| 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:43 |
| nacc | jgrimm: i can upload the fixed version, but i'm not sure what do about the above --^ | 17:45 |
| jgrimm | nacc, ack | 17:50 |
| dobey | hmm, how can i get sbuild to run a script from the host system, inside the builddir | 18:14 |
| nacc | dobey: i think setup-hook does that, but it says its deprecated :) | 18:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| nacc | dobey: man sbuild implies the wdir for the chroot-setup-command should be the BUILDDIR | 18:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| nacc | which can be used for these external commands and i guess sbuild substitutes them for you | 18:27 |
| * 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| nacc | oh im on 16.10 and it's new :) | 18:33 |
| nacc | dobey: sorry about that | 18:33 |
| dobey | no worries | 18:36 |
| nacc | dobey: so it seems like ther are some options for 16.04's sbuild ... 16.10's makes it a bit easier :) | 18:37 |
| dobey | oh nice. %p doesn't exist yet in --pre-build-commands | 18:38 |
| 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:39 |
| nacc | ah | 18:41 |
| === alexisb-afk is now known as alexisb | ||
| doko_ | nacc: were there still some outstanding merges / ftbfs from your side? | 19:00 |
| 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:08 |
| nacc | doko_: http://qa.ubuntuwire.com/ftbfs/ only is for packages in -proposed, or is it the archive but using proposed? | 19:11 |
| 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:16 |
| nacc | doko_: got it | 19:17 |
| nacc | dobey: seems weird if the manpage didn't mention %e ... | 19:17 |
| 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:18 |
| nacc | dobey: oh ok that's whats in 16.10 | 19:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:24 |
| dobey | which is kind of nasty | 19:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| dobey | hmm, i'll try --finished-build-commands to see if dumping files in build dir just works | 19:29 |
| dobey | nope. sbuild doesn't just copy everything out. only the binaries/changes from debuild it seems :-/ | 19:34 |
| nacc | dobey: hrm :? | 19:53 |
| nacc | *:/ | 19:53 |
| 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:06 |
| dobey | bah, dpkg-source doesn't get run until after --starting-build-commands :( | 21:08 |
| tjaalton | ah, needed to use sudo with autopkgtest | 21:17 |
| nacc | dobey: you mean the xtract step? | 21:51 |
| 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:20 | |
| jgrimm | nacc, it was nspr | 22:22 |
| nacc | jgrimm: thanks | 22:22 |
| jgrimm | np | 22:22 |
| nacc | jgrimm: reproduced the python-cffi ftbfs on diamond, will debug there | 22:27 |
| nacc | i'm guessing it's an arch assumption | 22:28 |
| nacc | but not sure yet what | 22:28 |
| nacc | balloons: fyi, juju-core ftbfs on yakkety-proposed (http://qa.ubuntuwire.com/ftbfs/#ubuntu-server) | 23:04 |
| nacc | stgraber: fyi, lxc also ftbfs there | 23:05 |
| stgraber | nacc: yeah, doko_ is looking at it. We'll just revert his change if we can't get this resolved soon. | 23:15 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!