[00:00] bdmurray: the above means that AFAICS software-properties currently in xenial-proposed has a legit autopkgtest regression, which *should* be fixed in my new upload of software-properties 0.96.20.7 just now. I would suggest either accepting 0.96.20.7 over 0.96.20.6 and shepherding it through without requiring reverification of the other SRU bugs, or else releasing 0.96.20.6 with a known [00:00] autopkgtest regression with the expectation that this is fixed in 0.96.20.7. what do you think? [00:03] To avoid confusion with releasing 0.96.20.7 I'd say accept 0.96.20.6 into -updates now. [00:04] is there an ETA for when precise will show up old-releases and stop showing up on archive? [00:06] slangasek: ack, i can confirm the importer for lpusip/import/0.96.20.5 does not show any tests/aptroot/etc/apt/apt.conf.d but `pull-lp-source` of the same does [00:06] slangasek: will debug first thing tmrw [00:08] nacc: not much to debug I think. git doesn't track empty directories. There's no representation for that. [00:08] We definitely need a bug on it. [00:08] https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F [00:09] And figure out how we can manage this. [00:09] Perhaps we need to add that support to git. Their FAQ suggests it's doable (just difficult). [00:09] ah i see, you add a .gitignore in the empty dir to make it not empty [00:12] you add a .gitignore so its not ignored? [00:12] bdmurray: yeah, it basically makes it non-empty any longer [00:12] bdmurray: it's a bit of a kludge [00:13] yes [00:13] rbasak: you're right, and we don't want to contentfully hcange the srcpkg; but wouldn'thave dpkg-buildpackage have complined about the deletion? [00:13] it might have been just a warning, but wouldn't it have said something? [00:13] .gitkeep is also common http://www.ryanwright.me/cookbook/git/gitkeep [00:14] solarce: ah interesting, thanks! [00:14] software-properties is a native package [00:14] rbasak: oh right [00:14] nacc: np! [00:14] But the same bug could occur in debian/ in a non-native package. Or in a non-native < 3.0 package. [00:14] rbasak: yep [00:15] rbasak: should we have the importer at least fail for now on packages containing empty directories? [00:15] rbasak: rather than falsely successfully import them [00:15] Agreed [00:15] If the problem is the index, we may be able to work around in the importer by manually constructing the tree object [00:16] Oh, but usually that goes through the index. Hmm. In any case, that might still break user tooling when working with the repository. [00:16] rbasak: would `find . -type d -empty` as we import be sufficient? [00:16] I think so, yes. [00:16] rbasak: ok, i'll play with it tmrw [00:16] slangasek: thanks for finding the bug! :) [00:26] rbasak: probably something like: http://paste.ubuntu.com/24469989/ [00:28] nacc: cool, thank you! [00:29] bdmurray: ok, sru-releasing 0.96.20.6 now if you haven't already [00:29] rbasak: yeah with that, the import spits out an error immediately (with --no-fetch) [00:29] i wonder what dgit does with that srcpkg [00:30] slangasek: he did the most part of the original code, I just shuffled things around a bit (and did send him a copy for review, but I got no response yet) [00:30] solarce: precise is not being removed from archive, since Canonical is continuing to provide (paid) security support for it: https://insights.ubuntu.com/2017/03/14/introducing-ubuntu-12-04-esm-extended-security-maintenance/ [00:31] cyphermox: ok, so currently not actually signed-off-by :) [00:32] slangasek: oh nice, we (Travis CI) assumed the "usual" move to old-releases, that means less work for us, thanks! [00:32] not totally [00:32] slangasek: yeah, i think it's a bug in dgit too :) [00:32] so we're not worse, at least! [00:33] nacc: yeah that's fine for now. [00:33] Meanwhile, I've been testing. [00:33] slangasek: My understanding was that it would just continue to be updated in a private repository, but it would continue to exist just as any other EOL release does/ [00:33] ? [00:33] git _can_ represent an empty directory internally. [00:33] If I construct the tree object manually. [00:34] However, the index cannot represent it, and thus it doesn't get checked out as empty, nor does git status see anything about it, nor does stuff like "git reset --hard" see it. [00:34] solarce: it will /also/ be available from old-releases fairly soon [00:34] so you'll have a nice long transition window [00:34] rbasak: i see [00:34] So we could fix the importer and call it a "client problem" bug for now. Then at least the imported trees will be correct, awaiting a future client-side tooling fix. [00:35] tsimonq2: updates in a private repository; existing packages kept on archive.u.c (at least for right now) so that no rejiggering of other sources.list entries required [00:35] And then we could move the warning client side for now. [00:35] slangasek: stellar, thank you for the updates [00:35] "usd clone" could look for these, create the empty directories and leave .gitignore files inside them for example. [00:35] and all the hard work, we definitely benefit from it <3 [00:35] And "usd build" could reconstruct it. [00:35] rbasak: right, i see that [00:35] (in case git has lost them) [00:36] solarce: sure thing. sorry, someone (maybe you?) pinged me directly on irc a couple of weeks ago but was gone before I came online in the morning [00:36] Oh. [00:37] But when a new tree is constructed from the index (ie. when you commit), that new tree object will have lost the empty directory again. [00:37] slangasek: that was Carmen from my team, no worries, timezones and being busy is the usual [00:37] So this really is quite broken at the client side end and I don't see an easy workaround that allows a developer to use git and not lose the empties. [00:37] rbasak: yeah, it feels like a bit of a mess [00:37] rbasak: ian might have some ideas [00:38] i'll file a bug against dgit to let him know tmrw [00:38] Good idea, thanks. [00:38] slangasek: we're putting our precise stuff into maintenance mode and getting full steam ahead on finishing trusty and hopefully xenial by the end of the year [00:38] anywho, thanks again, headed out for now [00:51] I like component-mismatches reports much better now that I've trimmed down duplicate data points in the svg and it no longer takes 100MB to render them [00:58] juju-mongodb3.2, another good example of where using p-m for SRUs would help... ignored because FTBFS but the FTBFS aren't regressions [01:08] slangasek: ack [01:10] nacc: Can you subscribe ~ubuntu-server to php7.1 bugs as was the case for php7.0? [01:11] infinity, nacc: oops, let me do that, since I did the maining [01:11] slangasek: If you can? [01:11] (done) [01:11] infinity: you don't know about bdmurray's LP backdoor? [01:12] slangasek: Apparently not. [01:12] turns out the api doesn't block you from subscribing teams you're not part of to package bugmail ;) [01:12] Fun. [01:13] The UI requires you to be an admin. I didn't realise that constraint was UI level. :P [01:13] (I'm a member... The longest member on the team, in fact) [01:13] :-) [02:14] -queuebot:#ubuntu-release- Unapproved: openssl (yakkety-proposed/main) [1.0.2g-1ubuntu9.1 => 1.0.2g-1ubuntu9.2] (core) [02:20] -queuebot:#ubuntu-release- Unapproved: openssl (zesty-proposed/main) [1.0.2g-1ubuntu11 => 1.0.2g-1ubuntu11.1] (core) [02:23] -queuebot:#ubuntu-release- Unapproved: openssl (xenial-proposed/main) [1.0.2g-1ubuntu4.6 => 1.0.2g-1ubuntu4.7] (core) [04:02] -queuebot:#ubuntu-release- New binary: gzip [amd64] (artful-proposed/main) [1.6-5ubuntu1] (core) [05:26] -queuebot:#ubuntu-release- New: accepted freebayes [sync] (artful-proposed) [1.0.2-1] [05:26] -queuebot:#ubuntu-release- New: accepted gzip [amd64] (artful-proposed) [1.6-5ubuntu1] [05:29] nacc: looks like the usual sorts of autopkgtest failures to unwind for php-defaults [05:31] -queuebot:#ubuntu-release- New binary: freebayes [amd64] (artful-proposed/none) [1.0.2-1] (no packageset) [07:11] bdmurray: yes, I sent a slightly adapted debdiff to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809669 [07:11] Debian bug 809669 in unattended-upgrades "unattended-upgrades: files got created under /var/ mountpoint" [Critical,Open] [07:53] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.24.1 => 2.25] (desktop-core, ubuntu-server) [07:53] -queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.24.1+17.04 => 2.25+17.04] (desktop-core, ubuntu-server) [07:53] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.24.1+16.10 => 2.25+16.10] (desktop-core, ubuntu-server) [07:55] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.24.1~14.04 => 2.25~14.04] (no packageset) [08:09] * apw reviews ^ [08:42] anyone waiting for anything pre-autosync? [08:42] * Laney stares at cron [08:55] * rbasak believes cron is probably waiting for _something_ :-P [09:03] it is waiting till you look away, so it can run whatever you are waiting for [09:03] it's waiting for someone to remove --dry-run :P [10:16] Laney: I'm going to remove it after I wake up and refresh the chroots. === klebers_ is now known as klebers [12:57] slangasek, i possibly did. but not sure. https://code.launchpad.net/~smoser/software-properties/trunk.lp1532855/+merge/318132 [12:57] where is the error you were pointing at (/me realizes both slangasek and nacc are west coast) [13:00] o/ [13:01] smoser: it was in your upload to Ubuntu rather than in upstream. Did you use the git importer stuff to prepare that? [13:01] In any case I'm pretty certain it's a bug in our git stuff. [13:01] git cannot represent empty directories. So the importer will have dropped it, not you. [13:02] s/cannot represent/cannot manage/ [13:02] its more than likely. [13:02] in that i use usd anywhere i can, and i suspect i had nacc import that so i could use it :) [13:03] what was the regression though ? is there a bug for that ? [13:03] and is there a bug against usd-importer ? [13:03] The regression was that it broke a dep8 test. I believe slangasek fixed it up already with a fixed upload/accept. [13:04] nacc was going to file a bug against usd-importer, but I don't see one yet. [13:04] He said he'd do it today. [13:04] In the short term we'll just have the importer break if it sees an empty directory. So at least we won't be importing bad data. [13:05] Medium term we can have the importer import the right thing, since internally git can represent an empty directory. The problem is at the porcelain/index level only. So then the importer would continue, but client-side devs would still drop it without realising. [13:05] Then we'd have to have "usd clone" detect and warn or break if it spots any empty directories. [13:06] Long term I think the only sensible way to fix this is to fix git. It does sound like upstream will accept the fix; it just needs the work done. [13:07] i dont see the upload though for software properties [13:08] https://launchpad.net/ubuntu/+source/software-properties/0.96.20.6 [13:08] IIRC, .5 was the broken upload, which slangasek replaced with .6. [13:08] "uploaded by Scott Moser" ? [13:08] Though .6 is supposedly signed by you? That's odd. [13:09] Oh. [13:09] .6 is the broken one. [13:09] 0.96.20.7 is in unapproved. [13:09] To avoid confusion with releasing 0.96.20.7 I'd say accept 0.96.20.6 into -updates now. [13:10] bdmurray, slangasek: so are we reviewing/accepting 0.96.20.7 without an SRU bug? [13:10] (I mean that's fine, if that's the plan, just checking if it is) [13:29] tjaalton: slangasek: You're the two people on the SRU rota for today, would you be able to take a look at gce-compute-image-packages in the trusty queue? [13:29] (Thanks in advance!) [13:35] Odd_Bloke: the debdiff doesn't look complete? [13:36] or, were some of the changes already in 0ubuntu3~14.04.2? [13:36] caribou: Okay, I looked in github for it. [13:36] looks like it [13:37] bdmurray: ah, sorry I thought you meant debian [13:37] Odd_Bloke: there's no SRU bug in the changelog entry [13:37] bdmurray: I'll prepare a PR for it next week [13:37] rbasak: 0.96.20.7 dos have an SRU bug. [13:38] rbasak: http://launchpadlibrarian.net/317339072/software-properties_0.96.20.6_0.96.20.7.diff.gz [13:38] Oh, OK. And we're restoring the directory in it as well? [13:38] IMHO, that should be changelog noted, but never mind. [13:39] tjaalton: My assumption was that a bug's presence in the new entries would be sufficient; does it also need to be in the backport-specific stanza? (https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/1664949 is in the backported changelog entries.) [13:39] Ubuntu bug 1664949 in gce-compute-image-packages (Ubuntu Trusty) "Daemons do not log output to serial console" [Undecided,In progress] [13:39] I guess my assumption is very opaque to the user. [13:39] tjaalton: Could you reject it and I'll re-upload? [13:40] Odd_Bloke: yep [13:40] at least the tools complain about this [13:40] Odd_Bloke: note that the rich history adoption by the importer currently races the SRU queue. Quite suboptimal right now, sorry :-/ [13:40] so I think it wouldn't add the template entry to the bug [13:40] Odd_Bloke: the importer will look for an upload tag in its repository at import time, which will be shortly after queue accept time. But currently there's no way for uploaders to push there directly :-/ [13:41] nacc or I have to manually do it. [13:41] If the upload tag arrives late, then IIRC it'll currently be ignored. In the future we want it to be noted (with git-notes) but it won't be accepted into the DAG. [13:44] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20160930-0ubuntu3~14.04.2 => 20160930-0ubuntu6~14.04.0] (ubuntu-cloud) [13:49] -queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu6~14.04.0] [13:49] Odd_Bloke: I need to run out now :/ [13:49] tjaalton: No worries; just pushed up the fixed package. [13:49] Get to it when you can. [14:09] how often is MoM supposed to refresh? [14:12] * apw is seeing build failures caused by dpkg-genbuildinfo trying to read _all packages on not amd64 [14:17] slangasek: half-hourly or so, but it was crashing on something, I've been trying to hit it over the head today [14:17] cjwatson: ok, cheers [14:17] it has some hateful failure modes [14:18] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.25+17.04] [14:34] alas, poor yorick, your autopkgtests fail [14:36] so... runs under xvfb-run, sometimes creates X windows, sometimes fails. ok then [14:37] worked pretty well in zesty === jgrimm is now known as jgrimm-away [14:55] infinity: hey, does dput need updates for .buildinfo? I see .buildinfo is in my source.changes file, but I tried an upload to artful (from zesty host) and got: [14:55] GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20170427-181152-004277/ubuntu/apparmor_2.11.0-2ubuntu5_source.buildinfo failed: Verification failed 3 times: ["(7, 58, u'No data')", "(7, 58, u'No data')", "(7, 58, u'No data')"] [14:57] I wouldn't expect a .buildinfo file in a source upload [14:58] maybe that's a broken dpkg/ [14:58] dpkg-buildpackage always produces .buildinfo, by design. also in source builds. [14:58] slangasek: so source.changes shouldn't have .buildinfo in it? [14:58] jdstrand: well, see what mapreri says [14:58] another question is how you got one from a zesty host? [14:58] I don't understand that as a 'design' [14:59] mapreri: I built in an artful schroot. upload from a zesty host [14:59] jdstrand: you need to install devtools from artful to get .buildinfo signing [14:59] ah [14:59] the idea is that you produce always a .buildinfo, and then do a source-only build including a .buildinfo produced by a binary build. but why in a source-only build with a source-only .changes a buildinfo can be useful, it escapes me too. [15:00] err, not devtools [15:00] devscripts* [15:00] i.e. debsign, if you are using that to sign. [15:00] yeah, devscripts [15:01] sorry, brainfrat [15:01] brainfart [15:01] but so launchpad forces .buildinfo to be signed correctly? [15:01] (dak doesn't…) [15:05] it does at the moment yet [15:05] *yes [15:05] well, keep it that way :) [15:05] from the discussion yesterday I thought that we should probably SRU the devscripts changes to sign buildinfo if present [15:06] possibly [15:06] it would make senes [15:06] also dscverify [15:07] It alarms me a little to hear that by default a source only upload will also leak details of my local environment. That isn't something I'd expect. [15:07] what are you thinking about? [15:07] installed packages and their versions? [15:07] dpkg-buildpackage -S, followed by dput? [15:08] installed packages and their versions> right. [15:08] well, you should be building also the sources in a clean environment, imho, not just the binaries… [15:09] Also from an engineering perspective, I'd expect that uploading the same source tree should result in the same upload and behaviour in Launchpad (or dak I guess) regardless of my environment. [15:09] mapreri: why? I use git to make sure my source tree is clean. [15:10] I found git trees containing files that should not be uploaded, correctly cleaned by `debian/rules build`. [15:10] "Buliding" the sources shouldn't be a thing. [15:10] err [15:10] `debian/rules clean` [15:11] mdeslaur: that seemed to work. thanks! :) [15:11] infinity: nm [15:11] "debian/rules clean" is superseded by "git clean" IMHO [15:11] I know it isn't by policy. [15:11] But "debian/rules clean" may be buggy on a per-package basis. [15:11] "git clean" should always work. [15:11] (unless the package is buggy, in which case at least "git clean" is and will remain consistent) [15:12] then it's a reason to fix it, not ignoring it and just use git :) [15:12] Sure I'll fix it if I know about it. [15:13] But only because policy says that "debian/rules clean" must exist. I'd advocate dropping it. Tooling/client issue. [15:13] cjwatson: btw, debsign underwent quite a lot of changes to support buildinfo, see one of the commits: https://anonscm.debian.org/git/collab-maint/devscripts.git/commit/?id=0b4258b893617d69d0a840da4bf2341299d5afb4 [15:14] (and there are several followup fixups) [15:14] yeah, I know it went wrong a couple of time [15:14] s [15:15] I'm not sure what the motivation for buildinfo in source-only uploads was; it feels like there probably was one and that it would be useful for somebody to dig it up [15:16] to understand how useful requiring a signature on it is [15:19] slangasek: ack, on my todo today to clean up [15:23] though speaking of buildinfo I guess I should tackle slangasek's https://bugs.launchpad.net/launchpad/+bug/1686242 [15:23] Ubuntu bug 1686242 in Launchpad itself ".changes files reference .buildinfo files that aren't exposed" [Undecided,New] [15:23] debian #846164 is the relevant bug. [15:23] Debian bug 846164 in dpkg-dev "dpkg-dev: Have dpkg-genchanges support a source+buildinfo-only upload after a binary build" [Wishlist,Fixed] http://bugs.debian.org/846164 [15:24] but indeed I can't see any reason to generate a .buildinfo out of a source-only build without any binary artifact generated. [15:25] so that sort of implies that the point of source+buildinfo is that it's describing the binaries you built but didn't upload ... [15:25] exactly [15:26] the whole goal is that "i build this and I claim those are the hashes. you now try to build it again yourself, and accept it only if you get the same hashes" [15:26] That use case certainly does make sense and seems entirely reasonable. [15:26] that's the final dream, anyway. We are still quite far from that goal. [15:28] mapreri: dpkg-buildpackage can fail if build-dependencies in clean target change [15:29] mapreri: dpkg-buildpackage -S [15:29] rbalint: -eparse [15:29] mapreri: dpkg-buildpackage -S can fail if build-dependencies used in d/rules clean target change [15:30] rbalint: what do you mean here by "change"? [15:30] mapreri: broke :-) [15:30] that the clean target modifies the Build-Dependencies list? [15:30] or what [15:31] mapreri: not the list of build dependencies, but the dependencies themselves [15:32] rbasak: FWIW I've been known to use debian/rules clean to generate bits of the source package; if you must generate debian/control, it's just about the only correct way to do it. I don't think that part is superseded. [15:32] mapreri: like there is an incompatible change in dh-r [15:32] rbalint: like a running dpkg process doing stuff at the same time you are running a source build, and happening to be messing with the packages involved? [15:33] rbasak: (not saying that's normally a good idea, but certainly in the past I've felt that it was the least bad answer to the problem at hand) [15:34] cjwatson: in those cases I generate that stuff once, and keep it around, and only call the relevant method in d/rules clean only to be sure nothing has changed. [15:34] Understood, thanks. The annoying thing about not using -nc is that then you technically need build dependencies installed :-/ [15:34] Though in that case, perhaps "usd build-source" must necessarily use a chroot? nacc ^ [15:35] rbasak: I just run -S -d, and install the things only needed for clean, which are usually very few. [15:35] mapreri: sure, but I think tooling for general use needs to dtrt even for the edge cases. [15:36] So what should our git-based workflow recommend/do by default? [15:36] I was hoping to avoid making new contributors set up a chroot. [15:36] (by using PPAs for test builds, etc) [15:36] If you can guarantee that the source tree has never been built, then I think -nc is safe [15:37] it now is only safe if you haven't also changed the version number [15:37] why? [15:37] rbasak: are you sure you can do anything relevant without having a local chroot for test builds? :| [15:37] (ie don't build -S -nc both sides of it) [15:37] because the new buildinfo leave mess in the tree in debian/files [15:37] mapreri: yes, by having Launchpad build it for me. [15:37] ah sure but that's just a bug [15:37] You could pass -nc if the build-dependencies *aren't* satisfied, on the grounds that the user can't then have built it (well, they could have built it in a chroot with the tree bind-mounted, I guess) [15:37] I'm trying to make it as easy for drive-by contributors as possible. [15:38] rbasak: possibly I'm too grumpy and old-style for that idea :) [15:38] I kind of feel a bit grumpy about encouraging people to regard Launchpad as a test-build service [15:39] Sometimes it's appropriate and sometimes it's abused; it still needs to be easy for people to do test builds locally rather than using a shared and therefore limited resource [15:39] One alternative might be to get local building with lxd working better. [15:39] My main gripe with sbuild is that it's a massive pain for a new contributor to set up. [15:39] An sbuild lxd session mode would be lovely [15:41] It already has multiple session modes (albeit that one of them is very weird), so it shouldn't be too hard [15:41] isn't lxd too painful to set up for drive-by contributions? [15:41] "I'm after a one command "here, take this git commit (or even work tree) and give me debs)" with no setup [15:41] lxd is trivial to set up, no? [15:41] i find pbuilder way way easier to set up [15:41] It pretty much Just Works. [15:41] -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (precise-proposed/main) [1.267.1 => 1.267.2] (core) [15:41] then, I'm biased as i'm its maintainer :P [15:41] ("chroot mode" is the jargon I'm looking for in sbuild) [15:42] I'd much rather people be directed towards something that is as close as possible to the software stack used in LP [15:42] lxd is generally pretty easy to set up since it has default image-based workflows [15:42] So sbuild has an adt chroot mode now. And adt has a lxd backend. I haven't tried this trickery though. [15:42] -queuebot:#ubuntu-release- New source: ubuntu-advantage-script (precise-proposed/primary) [1] [15:43] slangasek, ^^^^^^ [15:43] both ubuntu-meta and ubuntu-advantage-script are in. [15:43] Yeah and lxd also has automatic and sensible by default image management, so we don't have to teach new contributors on keeping chroots up to date, etc. [15:45] xnox: as I said, I don't like -script as a package name; even if there happens to only be one script, -script is bad for a name [15:48] slangasek, i am happy to adjust and fix things; as long as there is authoritative request for a name. I am just a minion, and other minions also did not feel what the right name should be. Hence minions uploaded status quo =) [15:48] slangasek: ubuntu-advantage-scripts ? [15:49] is that better? [15:50] slangasek, i object to -scripts because there is only one script so far; if one doesn't count motd snippet =) [15:50] My rule of thumb is to try to explain what it does rather than what it is [15:50] cjwatson, yeah, but i was not sure if ubuntu-esm would be good enough name or not. [15:51] Just as I don't put language-specific file extensions in program names on the PATH, because nobody cares what language it's in when they're just trying to run it; similarly, nobody cares that it's a script, they care that it enables ESM (or whatever) [15:51] slangasek, ubuntu-advantage-esm ? [15:51] rbasak: could be, yes -- it should be on our roadmap i guess [15:51] ubuntu-esm-tools? ubuntu-advantage-tools? [15:52] ubuntu-advantage would be fine too, as a package that provides ubuntu-advantage -specific functionality, IMHO. [15:52] rbasak, it's only one script so far that only can enable/disable esm; and should be in add-apt-repository imho, but that's too high level. [15:52] "You have ubuntu-advantage installed" makes sense. [15:52] smoser: rbasak: LP: #1687057 [15:52] Launchpad bug 1687057 in usd-importer "git cannot represent empty directories by default" [Undecided,New] https://launchpad.net/bugs/1687057 [15:52] rbasak: since you have a handle on a 'fix', can you assign to yourself? [15:53] ack [15:53] rbasak: except for the part where UA is also the name of a product and one has this package installed without necessarily being subscribed to the product [15:53] rbasak, but ubuntu-advantage imho is landscapish functionality to install. [15:53] nacc: "could be, yes" - in response to what please? [15:53] slangasek, xnox: fair, so ubuntu-esm-tools then? [15:53] xnox: well, it's like naming a list variable. even with one item, plural is better [15:53] xnox: 'ubuntu-advantage' was the guidance from dpb1. I think either 'ubuntu-advantage-tools' or 'ubuntu-advantage-scripts' here. [15:53] I don't care between them [15:53] * xnox is going away to have starbucks [15:53] +1 to either [15:54] * xnox wants a definitive name [15:54] tools or scripts [15:54] xnox: ubuntu-advantage-tools [15:54] done [15:54] One day you'll be shipping a go binary instead of a script. [15:54] preferably elected using a condorcet voting method. [15:54] rbasak: sorry, in response to modifyin build-source to use lxd or chroot or something else [15:54] nacc: OK, thanks. I'll file a bug against usd build-source then. [15:54] slangasek, ok. i will reupload things as tools. [15:54] rbasak: thanks [15:56] -queuebot:#ubuntu-release- New: rejected ubuntu-advantage-script [source] (precise-proposed) [1] [15:59] nacc: bug 1687059 [15:59] bug 1687059 in usd-importer ""usd build-source" does not run debian/clean" [High,New] https://launchpad.net/bugs/1687059 [16:02] rbasak: ack, so i think that's what --clean=dpkg-source (dgit's default) is meant to reflect [16:02] * nacc is just reading the manpage a bit more [16:11] rbasak: i think something like: sbuild -s --no-clean-source --chroot-mode=adt --adt-virt-server=lxd --chroot ubuntu:zesty for a zesty build will work [16:11] the --no-clean-source seems to be required or it tries to clean the source in the host which will fail without the deps [16:12] Nice. [16:12] That'll build binaries though right? [16:12] won't that also do a bunch of adtish things? [16:13] I do see --no-arch-any and --no-arch-all, which together with --source might work. [16:13] cjwatson: how so? I'm not sure I follow. It's just the adt backend we're invoking, right? [16:14] I haven't looked - is it invoking something other than adt-run? [16:14] I believe so, yes. [16:14] cjwatson: testing still so not sure :) [16:14] I guess that's weird but workable then [16:15] well that failed http://paste.ubuntu.com/24473829/ [16:15] * cjwatson would prefer sbuild --chroot-mode=lxd and have it have a reasonable default base image name ... [16:15] cjwatson: I would too. But that's not written :) [16:16] oh i think i see what i did wrong [16:19] rbasak: this will ... be tricky for the snap though [16:21] nope, that wasn't it (i thought maybe because i hadn't done an explicit autopkgtest-build-lxd it was failing [16:21] i will note that technically sbuild doesn't mention lxd only lxc [16:22] nacc: snap> yeah :-/ [16:22] Yeah sbuild doesn't currently directly support lxd at all. [16:24] well it appears to invoke it (or something) if you tell it to use lxd :) -- but then it errors out because i think it assumes it's able to write somewhere that doesn't exist? [16:45] -queuebot:#ubuntu-release- New source: ubuntu-advantage-tools (precise-proposed/primary) [1] [16:48] -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (precise-proposed/main) [1.267.1 => 1.267.2] (core) [17:03] slangasek: looking at src:php-defaults in a-p, i think i'm getting confused, the autopkgtests are running with --apt-pocket=proposed=src:php-defaults, which should only depend on php7.1 versions. reverse-depends shows that src:php7.0 only has rdeps from php-defaults (which get replaced in a-p). So i'm not sure how php7.0* are getting pulled in [17:04] slangasek: that seems to be the source of the failure(s), though, php7.0-cli but php7.1-xml installed [17:06] bdmurray: follow-up comment on https://code.launchpad.net/~vorlon/update-manager/ubuntu-support-optimize/+merge/323363 , further input requested [17:06] nacc: looking [17:06] slangasek: thanks [17:15] nacc: manually installing test deps of php-codecoverage as 'sudo apt install php-codecoverage php-xdebug phpunit php7.1-cli php7.0-cli-' shows that php-xdebug needs a rebuild [17:15] oh! it depends on that symbolic phpapi [17:15] slangasek: thanks! [17:18] nacc: maybe other revdeps, you'd want to look [17:18] slangasek: great, grep-dctrl-packages found a few more [17:18] slangasek: thanks again for the pointer [17:29] bdmurray: yeah I think fwiw pep8 wants imports sorted alphabetically, but as we're not enforcing that on the project overall I wasn't fussed :) [17:34] slangasek, new stuff is in the queue. [17:38] I'm guessing tjaalton isn't going to get to it today, so slangasek do you have a minute to accept the gce-compute-image-packages waiting in the trusty queue? [17:49] Odd_Bloke: done [17:50] -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu6~14.04.0] [17:50] slangasek: Thanks! [18:04] quick question all - ubuntu budgie dailies appear to being built with the zesty seeds. When do the dailies switch to the artful seeds? [18:08] fossfreedom: why do you think it is using the zesty seed? [18:09] I removed tracker, gnome photos and added gthumb to our artful seeds a couple of days ago. today's build still has gnome photos, tracker and doesnt have gthumb [18:11] fossfreedom: you need to update ubuntu-budgie-desktop [18:11] ah - wilco roger [18:11] gnome-documents also has a hard depends on tracker [18:12] yep - that has gone as well [18:18] bdmurray: https://code.launchpad.net/~vorlon/update-manager/ubuntu-support-optimize/+merge/323363 - pushed, ready for re-review [18:24] fossfreedom: It'd actually be roger wilco but wikipedia says that's redundant. https://en.wikipedia.org/wiki/Voice_procedure#Words_in_voice_procedure [18:25] lol [18:26] slangasek: no change to the changelog version? [18:29] bdmurray: oops, fixing [18:29] bdmurray: fixed [18:30] bdmurray: except lp was slower than my typing; /now/ fixed [18:31] slangasek: also all the other prints are "print(" <- no space [18:31] wah [18:31] bdmurray: should I also localize it? :) [18:33] I can't see where the pot update happens [18:39] heh; open-iscsi autopkgtest takes 18m to succeed, 11h 18m to fail [18:39] slangasek: hrm, i tried to rebuild src:libguestfs (php7.1 transition) and i get: /bin/sh: 1: /usr/sbin/dpkg-divert: not found. It's in dpkg, though, afaict, and that seems installed in the build. I tried building the current artful version in artful and it also fails. I'm testing locally if the ubuntu4 version succeeds in zesty. [18:39] slangasek: stacks of timeouts, i guess? [18:40] nacc: in zesty, /usr/sbin/dpkg-divert is a symlink to /usr/bin/dpkg-divert. Possibly a dropped compat symlink. Why is it calling it with a full path? [18:40] nacc: yeah, probably. would be nice if it would fail sooner [18:41] slangasek: not sure :) and i'm not sure what is calling it yet [18:41] slangasek: yeah, those tests are ... not great on some lvel [18:42] nacc: does the dpkg-divert call happen in build or during build-dep install? [18:42] - Remove update-alternatives, dpkg-divert and dpkg-statoverride [18:42] compatibility symlinks, again. [18:42] dpkg (1.18.11) unstable; urgency=medium [18:43] slangasek: looks to be during the build itself [18:43] from somethig called supermin? [18:44] 'tool for building supermin appliances' [18:44] which I guess are like supermax appliances but with fewer guards [18:44] slangasek: might get fixed witha merge [18:44] i'll check [18:45] nacc: Probably, given that supermin and libguestfs have both built on Debian long after that dpkg change. [18:45] infinity: yeah [18:45] Though I see no mention of it in either changelog. [18:45] Oh, found it. [18:45] 5.1.17-2 ? [18:45] supermin (5.1.17-2) unstable; urgency=medium [18:45] * Add patch so that we do not look for dpkg* in the wrong places [18:45] yeah [18:45] Yeah. [18:45] ok, i'll merge that [18:48] nacc: actually I just finished a merge here that I can upload if you like [18:48] slangasek: oh that'd be great [18:49]