[00:56] stgraber, thank you for the analysis. [00:57] stgraber, and yes this is serious. thanks for assignment, i will look into it during day time. === fginther is now known as fginther|away === fginther|away is now known as fginther === cpaelzer_ is now known as cpaelzer [05:56] Good morning [06:29] nacc: oh yeah LP: #1576698 is as much in progress as it can be with the SRU pushed to the approval yesterday [06:29] Launchpad bug 1576698 in ntp (Ubuntu Xenial) "ntpdate-debian not working" [Medium,In progress] https://launchpad.net/bugs/1576698 [06:30] nacc: I updated the status triaged -> in progress - and given nothing breaks on the way in it will go to fix released then [06:30] nacc: it might even be fix committed already given that the SRU is in the queue [07:22] pitti, thanks for the FFe :) [07:31] ginggs: no worries, thanks for working on the wine update! [08:10] I guess there are some very special considerations on removing a binary package to be no more built by a source via an SRU [08:11] rbasak: you discussed that with me a while ago for bug 1524526 [08:11] bug 1524526 in dovecot (Ubuntu Xenial) "Crashes with undefined symbol" [High,Triaged] https://launchpad.net/bugs/1524526 [08:11] but we didn't get to a conclusion back then [08:11] now all the yakkety parts whicih blocke us before are complete [08:11] so we have do discuss (=I have to lean) how that is to be done [08:13] everybody is invited to share experience on this :-) [08:14] cpaelzer: we can SRU something that makes the dovecot-lucene binary package effectively empty [08:14] rbasak: and that is preferred because it avoids the dependency havok it might cause otherwise ? [08:15] cpaelzer: what would be the alternative? [08:15] rbasak: really not building it, but the old bad one would stay around all the time [08:15] Ah. If we didn't build dovecot-lucene, then apt would still see the release pocket version. So users would still have it, and the SRU would be ineffective. [08:16] that is what I expected and wanted confirmed [08:16] rbasak: do you have any example on such an empty package? [08:17] https://launchpad.net/ubuntu/+source/owncloud but I'm not sure that's representative [08:17] https://launchpad.net/ubuntu/+source/bitcoin/0.3.24~dfsg-1ubuntu0.2 is another [08:18] In this case it wouldn't be as severe - just one binary package going rather than all of it. I don't know of a good example of that. [08:19] Just package a README.lucene file? (can't remember the naming format for Maintainer maintained docs) with an explanation of where the contents disappeared to? [08:20] Right, and maybe a NEWS.Debian entry as well as a changelog entry, etc, so people using apt-listchanges will see it. [08:21] thank you all G and rbasak - I'll prep something testbuild and suggest then [08:23] doko: http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html and http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-linaro-yakkety.html exist now. [09:04] any idea why so many arm builders seem stuck in Cleaning? https://launchpad.net/builders/ [09:14] pitti: could you remove the wine-development armhf binaries please? LP: #1612180 [09:14] Launchpad bug 1612180 in wine-development (Ubuntu) "Please remove wine-developement binaries on armhf" [Undecided,Confirmed] https://launchpad.net/bugs/1612180 [09:16] ginggs: done, bug updated [09:17] pitti: danke! [09:24] Mirv: There's an annoying arm64 KVM bug or two. [09:24] * wgrant resets them. [09:25] wgrant: are you also running into these rcu_sched stalls? [09:25] pitti: These tend to mostly be early boot failures. [09:25] Rarely do successfully booted instances later hang. [09:25] wgrant: I've been wondering all the time why cking and I didn't find a way to circumvent them while they seem to not inflict your buildds [09:25] (unless we upgrade them to xenial. then the world burns.) [09:26] pitti: Colin and I have long wondered that too. [09:26] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-5.7 could some kind soul with access hit retry on the failed libreoffice build? :) [09:27] * cking needs to reprioritize on that issue, lemme sync up with leann about this [09:27] thanks [09:28] cking: I thought the status quo was that it doesn't happen any more with xenial on the host, but that then ran into bug 1602577 [09:28] bug 1602577 in linux (Ubuntu Xenial) "[arm64] compute nodes unstable after upgrading from 4.2 to 4.4 kernel" [High,Triaged] https://launchpad.net/bugs/1602577 [09:28] Right, 4.4 on the hosts was a total disaster. [09:30] ugh, even worse than I recalled [09:31] cking: You're at least able to repro outside scalingstack, right? [09:32] Unlike the damned ppc64el memory corruption. [09:32] wgrant, yep, the repro was harder to do though outside of scalingstack [09:33] scalingstack's a better Tempest than Tempest. [09:33] * cking not sure what that refers to [09:34] OpenStack Tempest it their load testing thing. [09:34] stress-ng but for clouds, if you will. [09:34] ah :-) === jamespag` is now known as jamespage === hikiko is now known as hikiko|ln [11:04] xnox: that's not a reason to remove a package that is even maintained. Both debian's and ubuntu's archive contains different programs achieving the sme, that's no different. [11:04] juliank: hey, did you have any more requests for my python-apt change or is it good to merge? [11:11] doko, hey, could you re-review https://bugs.launchpad.net/ubuntu/+source/libphonenumber/+bug/1618178 ? [11:11] Launchpad bug 1618178 in libphonenumber (Ubuntu) "[MIR] libphonenumber" [Undecided,New] [11:18] sitter: Not sure [11:19] I wish CI was working for python-apt [11:19] Let's see if it passes the testsuite [11:21] sitter: merge works for me, so I can push it to the main repo [11:21] * juliank took the HEAD of https://github.com/apachelogger/python-apt - commit 8a619a70251abef6bf93524889a0221a1c2802e9 [11:23] https://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=6ce94b3 [11:25] juliank: You can probably stop trying to sync apt. :P [11:26] juliank: (or read your email) [11:26] infinity: There are no emails [11:26] I thought it got lost somewhere in the databases [11:26] juliank: Oh. Really? You should have gotten an email that it's in the unapproved queue. [11:26] cjwatson: ^-- Does that not work for syncs, or is juliank's MTA hating on him? [11:28] infinity: https://bugs.launchpad.net/launchpad/+bug/830614 [11:28] Launchpad bug 830614 in Launchpad itself "Email not immediately sent for copied packages which end up in NEW" [Low,Triaged] [11:29] s/NEW/queues/ :) [11:29] Oh, now I see it in the launchpad web UI at least [11:29] Laney: Oh, iz just a celery batch delay? [11:29] * infinity reads the bug. [11:30] I think I only looked at the new queue in there, and did not think about switching to the unapproved queue [11:30] juliank: thanks :) [11:30] That's a very uninformative bug. [11:31] It also happens with the stable queues if you sync there, [11:31] Just from the bug, that doesn't look like a celery delay, more that we simply don't send mail to the copier in that case. [11:32] Yes, there is never any email. === hikiko|ln is now known as hikiko [11:35] I sort of wanted to have final 1.3 in the beta, but I guess the beta will also survive without it [11:35] juliank: I can perhaps slip it in. But I assume there are no dire bugs in the current apt that make it necessary to do so, right? Just a nice-to-have? [11:37] juliank: Letting it into proposed, at least. A britney block will keep it from migrating while we decide. [11:37] Yeah. It basically changes the cache generator algorithm in one place a bit when hashing dependency lines to not skip dependency lines larger than 1024 chars (instead always read up to 1024 chars), and two other bugfixes. [11:37] The changes are tiny bugfixes [11:37] * infinity nods. [11:37] And no tiny bugfix has ever gone wrong. :) [11:38] At least my bugfix has full coverage [11:38] the others happened before I added automated coverage testing [11:39] juliank: Careful, you're in danger of turning apt into a professional software project. [11:39] Automated coverage testing is nice, but it is a bit fluctuating +/- 0.5% coverage [11:39] for the same commit in the same CI environmenz [11:40] Because gcov does not handle things very well if we are running multiple programs linked to the same library at the same time (like apt starting acquire methods, all of which are linked against coverage-test-emitting apt-pkg) [11:47] Gah, whose idea was it to redefine scrollbars so that clicking below the active area of the bar now warps the bar to that location rather than doing page-down? [11:47] Makes it very difficult to deal with deep scrolled regions such as the Firefox history pane. [11:52] chrisccoulson, mardy, is that known/being worked on that adding a google account using ucc/uoa in yakkety the google webauth screen goes away/is white when trying to scroll down? is that on track to be fixed before release? (unsure if that's an oxide thing?) [11:55] infinity: One thing I really should look at at some point is test speed - An apt CI run on travis currently takes about 40 minutes. [11:56] I shall probably also move the 1.3.y series CI on shippable to test on yakkety rather than xenial [11:56] And DonKult also runs tests on semaphore. [11:59] Hi everyone [12:00] The Gradle package seems to need a binary upload in Ubuntu [12:00] Gradle fails to launch and it builds with itself [12:00] Well I'm not a Ubuntu Developer, how can I solve this? [12:11] seb128, I believe that's a Qt issue [12:12] seamlik: Ubuntu doesn't have binary uploads. Can you explain the real problem? [12:13] https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1622550 [12:13] Launchpad bug 1622550 in gradle (Ubuntu) "Rebuild 2.13-4 Locally with JSch 0.1.53 and Do A Binary Upload" [High,New] [12:14] An update of JSch caused Gradle fails to launch, and I have fixed the FTBFS. But Gradle builds using Gradle, uploading a new version still FTBFS [12:14] In Debian we did a binary upload [12:14] seb128: the fix was in qt, got backported by Mirv: bug 1613670 [12:14] bug 1613670 in oxide-qt (Ubuntu) "Webview turns white after clicking on it" [High,Confirmed] https://launchpad.net/bugs/1613670 [12:15] seamlik: so a build against gradle 2.13-4 doesn't work, right? How would you fix this locally? [12:15] I locally downgrade JSch to the previous version and built it [12:15] Sorry, I mean a build against gradle 2.13-3, because 2.13-4 isn't available because it FTBFS. [12:16] Which version of JSch works and which doesn't? Why does downgrading it solve the problem? I'm asking because an archive admin can do a bootstrap if required (given the instructions), but I don't really follow why this would be required. [12:17] Once gradle 2.13-4 is successfully built, will building it against gradle 2.13-4 and jsch 0.1.54-1 work? [12:17] jsch_0.1.53-1 works with Gradle, now it is 0.1.54-1 [12:18] Gradle previously included the versioned classpath of jsch. So after it got updated, Gradle couldn't find the JAR to load [12:18] So 0.1.54-1 doesn't work with gradle? [12:19] No, it works with gradle >= 2.13-4 [12:19] I guess what I'm asking is: is this a one-off bootstrapping problem? Or will rebuilding gradle 2.13-4 in Ubuntu once the problem is solved still fail, when building against gradle 2.13-4 and jsch 0.1.54-1? [12:21] Once rebuilding Gradle 2.13-4, jsch 0.1.54-1 would work [12:21] Yeah it's a bootstrap problem [12:21] OK, understood. Thank you for your patience. [12:21] Thanks [12:21] So in that case, I'd amend the bug to include bootstrap instructions for an Ubuntu archive admin. [12:22] How would you do the bootstrap? [12:22] It's done in a privileged PPA, then binary copied to the archive. Only an Ubuntu archive admin has the required permissions. [12:24] I see [12:25] You can subscribe ~ubuntu-archive to the bug once you have instructions ready. And this channel is the right place to ask if you're looking for one. [12:26] Long term, you might want to look into https://wiki.debian.org/BuildProfileSpec for an automated way to solve the bootstrap problem, if you want to implement that. === _salem is now known as salem_ [12:27] Hmm, I'm thinking of writing a bootstrapping script to build Gradle without Gradle, I was afraid if it will excceed Yakkety's freeze date [12:30] jdstrand, do you know why the click-reviewers-tools upload for 16.04 is still in -proposed? [12:30] (http://askubuntu.com/questions/809109 is how I found out) [12:32] DebianImportFreeze passed, it means no more update from Debian? [12:32] seamlik: we can still manually sync if the update meets freeze requirements. [12:33] rbasak: Actually there's not many instructions for rebuilding Gradle. Simply install jsch 0.1.53-1 [12:34] dholbach: the bugs aren't marked verification done. let me do that [12:34] oh, ok [12:35] seamlik: sure. Just make it absolutely clear in the bug what is required and what is going on, and you're likely to get it fixed faster (eliminate the need for an archive admin to ask questions) [12:36] So I can still get an update sync before FinalFreeze? [12:36] It would be very close :( [12:37] As long as you are only fixing bugs and not adding features, and you can find someone to sponsor a sync in time, then yes. [12:38] Thank you :) [12:39] chrisccoulson, mardy, thanks ... need to nag Mirv for landing it then? [12:40] seb128: it was landed already, the qtbase version is in that bug [12:41] Mirv, k, my iso is a week old, need to sync a new one I guess, thanks [12:41] seb128: correct, it's two days old now [12:45] dholbach: ok, I verified them all [12:48] jdstrand, fantastic :) [13:06] cyphermox: hi. I have a new fix for shim/mokutil (bug 1600452) any problems if I upload? I see shim-signed still needs verification too [13:06] bug 1600452 in mokutil (Ubuntu Xenial) ""Failed to set variable: (2) Invalid Parameter" when enrolling MOK" [Medium,Confirmed] https://launchpad.net/bugs/1600452 [13:07] arges: please don't upload shim; I'll do that today or very soon [13:07] it needs to be signed by Microsoft anyway [13:07] cyphermox: yea that's why figured I'd ask since its 'special'. I'll post a new yakkety patch to that bug soon then [13:07] and xenial [13:07] can you apply your changes to lp:~ubuntu-core-dev/shim/trunk? [13:08] pitti: hey, looking at click-reviewers-tools in pending-sru, there are two bugs that are golden but I think they should be green. bug #1584346 and bug #1595184 [13:08] bug 1584346 in click-reviewers-tools (Ubuntu Xenial) "Store reports "package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks"" [Undecided,Fix committed] https://launchpad.net/bugs/1584346 [13:08] bug 1595184 in click-reviewers-tools (Ubuntu Xenial) "tools do not handled abbreviated toplevel slots and plugs syntax correctly" [Undecided,Fix committed] https://launchpad.net/bugs/1595184 [13:08] cyphermox: do a merge request to that branch then? [13:08] arges: that said, I'm due to take a new snapshot so maybe we won't need the patches at all [13:08] cyphermox: its the first three patched on master: https://github.com/rhinstaller/shim/commits/master [13:08] pitti: they look right to me. did I do something wrong? [13:08] patched/patches [13:11] arges: ok [13:23] jdstrand: hm, they actually are green on my version of http://people.canonical.com/~ubuntu-archive/pending-sru.html [13:24] jdstrand: oh, you just set them to v-done recently, that explains it [13:24] jdstrand: yep, so that can be published; are you going to, or want me to? [13:24] pitti: ah, I did very recently, and one went green but two didn't, so I thought I did something wrong [13:24] jdstrand: presumably just lag then [13:25] pitti: I'm not on the sru team but am on the archive team. if you as a member of the archive team say it is ok for me to do so, I'm happy to [13:25] err [13:25] as a member of the sru team [13:26] jdstrand: there are no policy decisions, just a quick spot-check on the bugs that the v-done is reasonable (i. e. not just added without any explanation) [13:26] jdstrand: i. e. it's IMHO fine for archive admins to run sru-release; but if you aren't comfortable with that, I'm happy to run it too [13:27] pitti: I'll do it. thanks! [13:28] cyphermox: should i just push to that trunk branch... or do another branch and do a MP? [13:28] for shim [13:30] done [13:30] dholbach: fyi ^ [13:31] jdstrand, awesome - thanks! [13:32] arges: up to you, but like I said I need some other patches from shim, I'm going to take a snapshot of master today hopefully (waiting for some other code merged) [13:34] cyphermox: k then i'll just leave it [13:56] So I ran into this doing dist-upgrade on yakkety last week... thoughts? [13:56] The following packages have unmet dependencies: [13:56] libubuntugestures5-gles : Conflicts: libubuntugestures5 [13:56] libubuntumetrics5-gles : Conflicts: libubuntumetrics5 [13:56] libubuntutoolkit5-gles : Conflicts: libubuntutoolkit5 [13:57] apt-get install --purge libubuntugestures5 libubuntumetrics5 libubuntutoolkit5 libubuntugestures5-gles- libubuntumetrics5-gles- libubuntutoolkit5-gles- qml-module-ubuntu-components-gles- qml-module-ubuntu-components [13:58] I shouldn't have to do that [13:58] OTOH, developer issue, since it seems to be a mid-yakkety thing [14:00] * lamont notes that apt-get dist-ugprade still results in errors, even after all these years of me trying it. [14:25] rbasak: Not necessarily in a privileged PPA, FWIW; I probably wouldn't bother with that for a smallish bootstrap. [14:26] rbasak: The core mechanism is a highly-privileged API call that adds non-LP sources.list lines to a given build. [14:36] I see, thanks. [14:55] doko, cyphermox: I'm not feeling super great, I may go lie down. Can you two watch the MIR pipeline for any last minute approvals and such? === zyga_ is now known as zyga-ontheroad [15:13] sitter: Your python-apt commit causes a regression in the test suite on Ubuntu, in the PPA: https://launchpadlibrarian.net/285802879/buildlog_ubuntu-xenial-amd64.python-apt_1.1.0~beta5+982~ubuntu16.04.1_BUILDING.txt.gz [15:14] * juliank only verified on Debian and thought sitter checked on Ubuntu... [15:19] mterry: ack [15:20] cpaelzer: ack, thanks, was just reviewing our existing bugs' states [15:28] smoser: apt imported (it's pushing right now), usd-import updated [15:29] nacc, as i've said before, its un-healthy how much i like the importer. [15:29] rbasak: --^ if you'd like to review the usd-import changes when you get a chance -- i've tested them, but it's a bit of hairy code [15:29] or at least how much i like the idea of version control availability of all packages at my finger tips. [15:29] nacc: sure. Where? In git master? [15:30] rbasak: yep [15:30] * rbasak looks [15:33] smoser: apt import just finished/pushed [15:34] smoser: and 100% agree -- it makes it really easy to 'see' a source package and its history (being able to `git blame`/`git annotate` is really handy) [15:35] nacc: minor nitpick. Instead of: [15:35] Would be nicer if it used d/changelog. [15:35] branch[len('%s-%s/' % (owner, pkgname)):] [15:35] I'd do branch.partition('%s-%s/' % (owner, pkgname))[2] if I understand you correctly. Less prone to error. Maybe even an assert to make sure. [15:36] rbasak: hrm, are you sure you updated first? master shouldn't have a variable there [15:36] rbasak: the point is valid [15:36] but just making sure we're looking at the same tree [15:36] I'm looking at https://git.launchpad.net/usd-importer/commit/?id=dc27af24c7abfe9eaf6c51f63f6c47af076a414a [15:36] As I started from the diffs. If that's gone, then sorry :) [15:36] ah ok :) [15:37] yeah, it's gone in master:HEAD [15:37] I see. Sorry! [15:37] local_head_name = branch[len(remote_name):] [15:37] ok, so i see what you are saying, though [15:38] basically, the remote's name will be '/', so i'm pulling off '/' [15:38] ha, but you found a bug, fixing [15:39] :-P [15:40] rbasak: ok, so partition() will treat the whole thing as the separator and return something like (None, input string, suffix) ? [15:41] pitti ... can you take a quick look-see at https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1626166 .... I'm still wrapping my head around systemd... I have a feeling the post-install needs to tell systemd to re-read it's config files and start the lvmetad service, but I'm not sure. [15:41] Launchpad bug 1626166 in lvm2 (Ubuntu) "lvm2 not starting lvm2-lvmetad on package install" [Undecided,New] [15:43] rbasak: http://paste.ubuntu.com/23211888/ [15:43] Unit193: was that referred to me? [15:43] Unit193: it effectively does, but by publish rather than changelog [15:44] nacc: or even: [15:44] Unit193: presuming good uploads, they correlate -- let's just say that's not always the case :) [15:44] prefix = '%s/' % remote_name [15:44] _, prefix, local_head_name = branch.partition(prefix) [15:44] assert prefix == prefix [15:44] I made a mistake there, but YSWIM :) [15:44] yep, good call [15:45] http://paste.ubuntu.com/23211898/ [15:45] Yes, thanks :) [15:47] nacc: in clean_repository_state, I'm not sure about using subprocess.run like that. If stdout is a pipe that isn't connected up, the command could block on writing to stdout, no? [15:48] I would either not set it, or make and use a fileobj pointing to /dev/null if you want that behaviour. [15:48] ack it should be unset, sorry, c&p [15:48] Incidentally, I usually use subprocess.check_call, rather than subprocess.run, check=True. No strong opinon. [15:49] Style-wise, maybe drop the "cp =" if you never use cp? [15:51] chiluk: replied with initial analysis [15:51] rbasak: thanks, all fixed [15:51] rbasak: and now consistent, cp only present if used [15:54] rbasak: pushed and rebuilding the snap [15:54] rbasak: feel free to give me more changes, though :) [15:57] thanks pitti.. sorry I couldn't look more closely yet, but I'm helping vet the training classes right now. [15:57] and it was discovered through that. [15:58] chiluk: same here, not much time right now; but that's an exercise in debugging debian/rules and the debhelper script essentially [15:58] yeah.. [15:58] rbasak: brb, rebooting [15:59] alright well at least the bug is open, and not immediately obvious. [16:06] hrm, i wonder if 'Cannot enable. Maybe the USB cable is bad?' could be ratelimited in 4.8 :) about to fill up my dmesg, i fear [16:06] also, seems to be a regression... [16:10] pitti: hi. doko pointed out that python-virtualenv has been failing autopkgtest, on a gcc problem. he thinks it's a missing test dep on gcc or build-essential, which seems possible though i need to test that. it started failing on 2016-08-26 but passed for long before that. the package didn't change. can you think of anything in the test infra that may have broken this? [16:10] http://autopkgtest.ubuntu.com/packages/p/python-virtualenv/yakkety/amd64 [16:10] nacc: I'm not keen on the double nested FileNotFoundError handling when trying alternate paths. I would maybe make an open_any([path, path...], *args, **kwargs) function that iterates instead. [16:10] pitti: if that's all it is (a missing dep) it should be an easy fix. i'd just like to know *why* it suddenly started failing ;) [16:12] rbasak: ack, was mostly to get it working, i hate that too :) [16:13] rbasak: thansk for the suggestion, i wasn't sure what the pythonic way would be [16:13] Sure, I understand that the initial version is always very hacky :) [16:14] "use separate fetch and push urls" -- I like this. [16:14] yeah, it's cleaner, for sure -- but i also found it to be necessary with pygit2 :) [16:15] What does "squash" in the subject of ec9c102 mean? [16:16] bah!, i did squash (another commit) in, but forgot to change the line [16:16] I appreciate the commit message in 7533678 BTW. Nicely put. [16:16] heh, now it's part of history [16:16] :-) [16:17] nacc: OK, I'm done with a cursory look. I haven't looked deep enough to find bugs or anything, but in principle I think everything looks fine. Thank you :) [16:18] rbasak: cool, thanks for the review, cursory or otherwise! [16:20] mterry, cyphermox: afk now. I'll see if I can do some when I'm back tonight [16:20] rbasak: something like http://paste.ubuntu.com/23212105/ [16:22] nacc: yes. Though you forgot to chain *args and **kwargs. [16:23] rbasak: uh, right! :) [16:23] nacc: and do you need f.close() if in the context manager? [16:24] nacc: and a double indent on 71/72 if I'm reading the patch correctly. [16:24] rbasak: i wasn't sure if it was tied to the context of open() itself -- i'll dig into it and see [16:25] nacc: also I think you used the same (old) pattern in another place that might be worth updating. [16:25] rbasak: yep, doing that too [16:32] $ dpkg -L python-ldb-dev [16:32] /${DEB_PY2_INCDIR}/pyldb.h [16:32] nice ... [16:34] rbasak: http://paste.ubuntu.com/23212139/ [16:40] infinity, cjwatson, wgrant: question regarding a current livecd-rootfs question. I have a build which seems to be looping. [16:40] https://launchpad.net/~cloudware/+livefs/ubuntu/xenial/cpc-development/+build/76111 [16:41] I'm grabbing snippets of the buildlog as it runs [16:46] rcj: I think it must be crashing the builder somehow. [16:47] rcj: All the Launchpad buildd-manager side sees is "twisted.internet.defer.CancelledError" which basically means that it lost communication with the builder [16:47] rcj: We don't have more logs than that, though. [16:48] seamlik: Done. [16:54] nacc: looks good [16:55] cjwatson, is this the end of a build or the beginning of another loop? http://paste.ubuntu.com/23212225/ [16:57] I ask because we've hit the end of our hooks without error if I'm correct that the above paste is at the end of a build [16:58] rcj: near the end, I think [16:58] rcj: it's possible something goes wrong if you cause it to fail to emit a livefs [16:59] not exactly certain, but I think it is likely that hitting the end of your hooks doesn't exonerate your code :-) [16:59] cjwatson, I thought we were at the end. This is our basic cloud build plus an new binary output that I'm developing. So we shouldn't have less than when it was working [16:59] cjwatson, :) [17:00] cjwatson, tips on debugging (or running this locally?) [17:02] barry: hey, how are y ou? [17:02] barry: doko and I are wondering about the python-virtualenv regression (http://autopkgtest.ubuntu.com/packages/python-virtualenv/yakkety/amd64) [17:03] barry: it seems while it passed, it downlaoded some "world" tarball from somewhere: [17:03] Downloading world-3.1.1-py2.py3-none-any.whl [17:03] Successfully installed world-3.1.1 [17:03] it originates from ITALY [17:03] barry: now it says "Downloading world-4.0.tar.gz" ... "Python 3.4.0 or better is required" [17:03] barry: and it apparently falls back to trying to build it itself, but it's missing gcc and python[3]-dev for that [17:04] barry: so it seems some external resource changed -- which is confirmed by the test in xenial now also breaking; does that make sense? [17:04] barry: so IMHO virtualenv should Recommends: gcc, python*-dev, and the test should add needs-recommends; WDYT? [17:04] rcj: It's not quite at the end, since launchpad-buildd has to gather the results of the build and send them back; and there's also some livecd-rootfs stuff that happens after that. [17:05] rcj: This may be fairly laborious to debug. I'd probably start by doing the equivalent of https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html [17:05] (figure out the slight setup differences for building from your PPA) [17:05] cjwatson, thank you for the pointer [17:05] I can do that. [17:06] barry: same on https://ci.debian.net/packages/p/python-virtualenv/unstable/amd64/ [17:12] doko, barry: filed as bug 1626201 so that I have something to refer to for britney overrides; but it's IMHO an actual packaging bug, not (just) a test bug [17:12] bug 1626201 in python-virtualenv (Ubuntu Xenial) "missing python*-dev and gcc dependencies" [Undecided,New] https://launchpad.net/bugs/1626201 [17:35] pitti: hi! doing good modulo nasty jetlag ;) no, it's just a test dep missing since the package builds fine and doesn't need world to run. but i think i know why that's "suddenly" failed though. world 4.0 uses atpublic which does have a C component now. it's an easy fix and i'll upload that to debian today and sync it over to yakkety. for xenial, it probably should either just get ignored or we can do a quick sru. it doesn't [17:35] affect the operation of the package at all [18:03] barry: pythonic question for you -- for the importer, if i invoke it via ./usd-import and then later want to do file-based lookups based upon a set of paths (including the path the importer itself lives in), is there a way for me to access the absolute path? I do some chdir'g now, so what I'm seeing is that './usd-import' gets interpreted according to the 'current' value of '.', which is fully sane, [18:03] but not what I want. Would the pythonic way be to save off the original absolute path? [18:48] pitti, doko https://bugs.launchpad.net/ubuntu/+source/python-virtualenv/+bug/1626201/comments/3 [18:48] Launchpad bug 1626201 in python-virtualenv (Ubuntu) "missing python*-dev and gcc dependencies" [Undecided,In progress] [18:48] nacc: hi. i'm not sure i fully understand the question. what does "file-based lookups" mean? [19:00] barry: so we've got a few files that are used to override some behavior, and then one of those files includes some paths in it (local patches to apply). So if i run without any arguments, i'd like the importer to search for a specific filename in either the current directory or the directory the importer lives in [19:03] nacc: can you point to the code where you do this? (i have an up-to-date checkout of the git repo) [19:03] barry: yeah, one sec [19:04] barry: i'm in the process of cleaning it up right now, but ll. 419-469 currently [19:04] it doesnt' work for ./usd-import as-is, for the reasons mentioned above [19:04] but does work for /path/to/usd-import [19:06] nacc: sorry, more questions :) are those files in the source tree our outside of it? [19:06] *or outside [19:07] barry: np [19:07] barry: i'm realizing the logic is wrong, but this is what i want to do :) [19:07] 1) if specified ont he commandline, use that specific file, or error out [19:08] 2) if not specified on the commandline, search the importer script's dirpath for the appropriately named file (parent_overides.txt, e.g.) else error out [19:10] nacc: gotcha. there's a Right Way, but it'll probably force a bit of a reorg of the importer ;) i can describe that first and then if that's too much, we can talk about workarounds [19:10] barry: great! [19:10] nacc: so, the right way is to use pkg_resources [19:10] i'm reorging this code anyways to consolidate it, so that's fine [19:10] * barry looks for links [19:10] https://setuptools.readthedocs.io/en/latest/pkg_resources.html [19:11] there's a lot there, but you don't need most of it [19:11] nacc: the critical bit to this is that you really want usd-importer to be a stub (more on that in a moment) that does little else than import a main() from a submodule and run it [19:12] nacc: meaning you really want to put all of the python code in usd-import inside a package [19:12] nacc: and inside that package directory you'd put parent_overrides.txt [19:12] (sometimes we have that inside a subpackage like usd_import.data or some such) [19:12] nacc: then it would be totally unambiguous to do this: [19:13] overrides = pkg_resources.resource_filename('usd_importer.data', 'parent_overrides.txt') [19:14] ah ha! [19:14] barry: excellent, that does make sesne [19:14] there are a few other useful apis in pkg_resources, such as resource_string() [19:14] but that actually returns bytes in py3 :0 [19:14] :) [19:14] nacc: cool! if that's enough to go on, excellent. if not, ping me and i'll happily help [19:15] barry: yep, for sure! i'll tool around with this now! [19:15] nacc: \o/ [19:16] nacc: just one other small thing: even though pkg_resources comes in setuptools upstream, in debuntu we split that into separate binary packages [19:16] got it [19:23] barry, what is the "version of world"? [19:30] doko: it's just a package that the dep-8 test suite tries to install in the virtualenv to prove that it works [19:30] *install and invoke [19:30] the change pins it to v3 which doesn't require any C (via dependencies) [20:22] barry: many many thanks! I think i got the reorg done and pkg_resources are dtrt! [20:24] nacc: awesome! yeah, many of us have wanted pkg_resources (or something like it) in the stdlib, but It's Complicated. [20:24] totally understood, but it was pretty easy to use once i reorged [20:24] and it's passed my testing with and without '.', so pusehd to master [20:25] cool [20:50] http://pastebin.com/cBG4UuCx [20:50] [15:50] > libvirtd is getting stuck on creating a network id do you know how to force it on? === salem_ is now known as _salem [21:39] rcj: Your problem may have just been buildd-manager being randomly confused on our side; I got it restarted and another livefs build that had been showing similar weird symptoms now passes [21:39] rcj: So you may want to just retry - hope this hasn't wasted too much of your time :-/ [21:39] cjwatson, thanks for the update. I will retry [21:40] cjwatson, it's not all wasted. I have a script that fires up a VM, imports by private PPA, and prepares the environment to run our livecd-rootfs. That's pretty good. [21:41] Cute. [21:41] No doubt handy at some point. [21:42] image recipe iterations will be much faster as we won't need to wait for a build recipe to publish our funky livecd-rootfs [21:44] fun, spinning up an sbuild on the 4.8 kernel led to a 222 load average for a moment [21:44] even though all my cpus are idle, it seems like [21:45] now i'm up to 330 [21:45] feels like a bug :) [21:46] make -j is fun :) [21:46] it's not even that [21:46] there are no running tasks, but it goes all kinds of laggy and the load calculation is fubar [21:47] it's only using one cpu (afaict) [21:47] well, it's coming back down again now that's done setting up the sbuild [21:47] *schroot [22:23] cjwatson, xenial builds are fine but my yakkety lb build dies in lp_binary_zsync because it can't find zsync to install. That's in universe. Is there a trick to get that in the chroot? [22:23] rcj: It's in universe in xenial as well ... [22:23] rcj: Sounds like maybe your yakkety build is configured to only use main? [22:24] cjwatson, yeah, nm, universe is configured once I looked in /build/chroot/etc/apt/sources.list [22:25] cjwatson, and it's correct that this http://paste.ubuntu.com/23213541/ is running in the context of that apt sources.list, right [22:25] rcj: Err, there might be a few different contexts involved, not entirely sure. It's been ages since I messed with this stuff ... [22:26] rcj: Also, I don't think we normally have lb build zsync control files, so maybe your problem is actually that that's turned on when it shouldn't be? [22:27] rcj: Maybe I'm misremembering though. I'd suggest comparing build logs against the stock ones. [22:28]