| slangasek | 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 |
|---|---|---|
| slangasek | autopkgtest regression with the expectation that this is fixed in 0.96.20.7. what do you think? | 00:00 |
| bdmurray | To avoid confusion with releasing 0.96.20.7 I'd say accept 0.96.20.6 into -updates now. | 00:03 |
| solarce | is there an ETA for when precise will show up old-releases and stop showing up on archive? | 00:04 |
| nacc | 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 |
| nacc | slangasek: will debug first thing tmrw | 00:06 |
| rbasak | nacc: not much to debug I think. git doesn't track empty directories. There's no representation for that. | 00:08 |
| rbasak | We definitely need a bug on it. | 00:08 |
| rbasak | https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F | 00:08 |
| rbasak | And figure out how we can manage this. | 00:09 |
| rbasak | Perhaps we need to add that support to git. Their FAQ suggests it's doable (just difficult). | 00:09 |
| nacc | ah i see, you add a .gitignore in the empty dir to make it not empty | 00:09 |
| bdmurray | you add a .gitignore so its not ignored? | 00:12 |
| nacc | bdmurray: yeah, it basically makes it non-empty any longer | 00:12 |
| nacc | bdmurray: it's a bit of a kludge | 00:12 |
| bdmurray | yes | 00:13 |
| nacc | 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 |
| nacc | it might have been just a warning, but wouldn't it have said something? | 00:13 |
| solarce | .gitkeep is also common http://www.ryanwright.me/cookbook/git/gitkeep | 00:13 |
| nacc | solarce: ah interesting, thanks! | 00:14 |
| rbasak | software-properties is a native package | 00:14 |
| nacc | rbasak: oh right | 00:14 |
| solarce | nacc: np! | 00:14 |
| rbasak | But the same bug could occur in debian/ in a non-native package. Or in a non-native < 3.0 package. | 00:14 |
| nacc | rbasak: yep | 00:14 |
| nacc | rbasak: should we have the importer at least fail for now on packages containing empty directories? | 00:15 |
| nacc | rbasak: rather than falsely successfully import them | 00:15 |
| rbasak | Agreed | 00:15 |
| rbasak | If the problem is the index, we may be able to work around in the importer by manually constructing the tree object | 00:15 |
| rbasak | 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 |
| nacc | rbasak: would `find . -type d -empty` as we import be sufficient? | 00:16 |
| rbasak | I think so, yes. | 00:16 |
| nacc | rbasak: ok, i'll play with it tmrw | 00:16 |
| nacc | slangasek: thanks for finding the bug! :) | 00:16 |
| nacc | rbasak: probably something like: http://paste.ubuntu.com/24469989/ | 00:26 |
| slangasek | nacc: cool, thank you! | 00:28 |
| slangasek | bdmurray: ok, sru-releasing 0.96.20.6 now if you haven't already | 00:29 |
| nacc | rbasak: yeah with that, the import spits out an error immediately (with --no-fetch) | 00:29 |
| nacc | i wonder what dgit does with that srcpkg | 00:29 |
| cyphermox | 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 |
| slangasek | 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:30 |
| slangasek | cyphermox: ok, so currently not actually signed-off-by :) | 00:31 |
| solarce | slangasek: oh nice, we (Travis CI) assumed the "usual" move to old-releases, that means less work for us, thanks! | 00:32 |
| cyphermox | not totally | 00:32 |
| nacc | slangasek: yeah, i think it's a bug in dgit too :) | 00:32 |
| nacc | so we're not worse, at least! | 00:32 |
| rbasak | nacc: yeah that's fine for now. | 00:33 |
| rbasak | Meanwhile, I've been testing. | 00:33 |
| tsimonq2 | 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 |
| tsimonq2 | ? | 00:33 |
| rbasak | git _can_ represent an empty directory internally. | 00:33 |
| rbasak | If I construct the tree object manually. | 00:33 |
| rbasak | 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 |
| slangasek | solarce: it will /also/ be available from old-releases fairly soon | 00:34 |
| slangasek | so you'll have a nice long transition window | 00:34 |
| nacc | rbasak: i see | 00:34 |
| rbasak | 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:34 |
| slangasek | 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 |
| rbasak | And then we could move the warning client side for now. | 00:35 |
| solarce | slangasek: stellar, thank you for the updates | 00:35 |
| rbasak | "usd clone" could look for these, create the empty directories and leave .gitignore files inside them for example. | 00:35 |
| solarce | and all the hard work, we definitely benefit from it <3 | 00:35 |
| rbasak | And "usd build" could reconstruct it. | 00:35 |
| nacc | rbasak: right, i see that | 00:35 |
| rbasak | (in case git has lost them) | 00:35 |
| slangasek | 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 |
| rbasak | Oh. | 00:36 |
| rbasak | 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 |
| solarce | slangasek: that was Carmen from my team, no worries, timezones and being busy is the usual | 00:37 |
| rbasak | 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 |
| nacc | rbasak: yeah, it feels like a bit of a mess | 00:37 |
| nacc | rbasak: ian might have some ideas | 00:37 |
| nacc | i'll file a bug against dgit to let him know tmrw | 00:38 |
| rbasak | Good idea, thanks. | 00:38 |
| solarce | 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 |
| solarce | anywho, thanks again, headed out for now | 00:38 |
| slangasek | 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:51 |
| slangasek | juju-mongodb3.2, another good example of where using p-m for SRUs would help... ignored because FTBFS but the FTBFS aren't regressions | 00:58 |
| tsimonq2 | slangasek: ack | 01:08 |
| infinity | nacc: Can you subscribe ~ubuntu-server to php7.1 bugs as was the case for php7.0? | 01:10 |
| slangasek | infinity, nacc: oops, let me do that, since I did the maining | 01:11 |
| infinity | slangasek: If you can? | 01:11 |
| slangasek | (done) | 01:11 |
| slangasek | infinity: you don't know about bdmurray's LP backdoor? | 01:11 |
| infinity | slangasek: Apparently not. | 01:12 |
| slangasek | turns out the api doesn't block you from subscribing teams you're not part of to package bugmail ;) | 01:12 |
| infinity | Fun. | 01:12 |
| infinity | The UI requires you to be an admin. I didn't realise that constraint was UI level. :P | 01:13 |
| infinity | (I'm a member... The longest member on the team, in fact) | 01:13 |
| slangasek | :-) | 01:13 |
| -queuebot:#ubuntu-release- Unapproved: openssl (yakkety-proposed/main) [1.0.2g-1ubuntu9.1 => 1.0.2g-1ubuntu9.2] (core) | 02:14 | |
| -queuebot:#ubuntu-release- Unapproved: openssl (zesty-proposed/main) [1.0.2g-1ubuntu11 => 1.0.2g-1ubuntu11.1] (core) | 02:20 | |
| -queuebot:#ubuntu-release- Unapproved: openssl (xenial-proposed/main) [1.0.2g-1ubuntu4.6 => 1.0.2g-1ubuntu4.7] (core) | 02:23 | |
| -queuebot:#ubuntu-release- New binary: gzip [amd64] (artful-proposed/main) [1.6-5ubuntu1] (core) | 04:02 | |
| -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:26 | |
| slangasek | nacc: looks like the usual sorts of autopkgtest failures to unwind for php-defaults | 05:29 |
| -queuebot:#ubuntu-release- New binary: freebayes [amd64] (artful-proposed/none) [1.0.2-1] (no packageset) | 05:31 | |
| caribou | bdmurray: yes, I sent a slightly adapted debdiff to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809669 | 07:11 |
| ubot5` | Debian bug 809669 in unattended-upgrades "unattended-upgrades: files got created under /var/ mountpoint" [Critical,Open] | 07:11 |
| -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:53 | |
| -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.24.1~14.04 => 2.25~14.04] (no packageset) | 07:55 | |
| * apw reviews ^ | 08:09 | |
| Laney | anyone waiting for anything pre-autosync? | 08:42 |
| * Laney stares at cron | 08:42 | |
| * rbasak believes cron is probably waiting for _something_ :-P | 08:55 | |
| apw | it is waiting till you look away, so it can run whatever you are waiting for | 09:03 |
| Laney | it's waiting for someone to remove --dry-run :P | 09:03 |
| infinity | Laney: I'm going to remove it after I wake up and refresh the chroots. | 10:16 |
| === klebers_ is now known as klebers | ||
| smoser | slangasek, i possibly did. but not sure. https://code.launchpad.net/~smoser/software-properties/trunk.lp1532855/+merge/318132 | 12:57 |
| smoser | where is the error you were pointing at (/me realizes both slangasek and nacc are west coast) | 12:57 |
| rbasak | o/ | 13:00 |
| rbasak | smoser: it was in your upload to Ubuntu rather than in upstream. Did you use the git importer stuff to prepare that? | 13:01 |
| rbasak | In any case I'm pretty certain it's a bug in our git stuff. | 13:01 |
| rbasak | git cannot represent empty directories. So the importer will have dropped it, not you. | 13:01 |
| rbasak | s/cannot represent/cannot manage/ | 13:02 |
| smoser | its more than likely. | 13:02 |
| smoser | in that i use usd anywhere i can, and i suspect i had nacc import that so i could use it :) | 13:02 |
| smoser | what was the regression though ? is there a bug for that ? | 13:03 |
| smoser | and is there a bug against usd-importer ? | 13:03 |
| rbasak | The regression was that it broke a dep8 test. I believe slangasek fixed it up already with a fixed upload/accept. | 13:03 |
| rbasak | nacc was going to file a bug against usd-importer, but I don't see one yet. | 13:04 |
| rbasak | He said he'd do it today. | 13:04 |
| rbasak | 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:04 |
| rbasak | 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 |
| rbasak | Then we'd have to have "usd clone" detect and warn or break if it spots any empty directories. | 13:05 |
| rbasak | 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:06 |
| smoser | i dont see the upload though for software properties | 13:07 |
| rbasak | https://launchpad.net/ubuntu/+source/software-properties/0.96.20.6 | 13:08 |
| rbasak | IIRC, .5 was the broken upload, which slangasek replaced with .6. | 13:08 |
| smoser | "uploaded by Scott Moser" ? | 13:08 |
| rbasak | Though .6 is supposedly signed by you? That's odd. | 13:08 |
| rbasak | Oh. | 13:09 |
| rbasak | .6 is the broken one. | 13:09 |
| rbasak | 0.96.20.7 is in unapproved. | 13:09 |
| rbasak | <bdmurray> To avoid confusion with releasing 0.96.20.7 I'd say accept 0.96.20.6 into -updates now. | 13:09 |
| rbasak | bdmurray, slangasek: so are we reviewing/accepting 0.96.20.7 without an SRU bug? | 13:10 |
| rbasak | (I mean that's fine, if that's the plan, just checking if it is) | 13:10 |
| Odd_Bloke | 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 |
| Odd_Bloke | (Thanks in advance!) | 13:29 |
| tjaalton | Odd_Bloke: the debdiff doesn't look complete? | 13:35 |
| tjaalton | or, were some of the changes already in 0ubuntu3~14.04.2? | 13:36 |
| bdmurray | caribou: Okay, I looked in github for it. | 13:36 |
| tjaalton | looks like it | 13:36 |
| caribou | bdmurray: ah, sorry I thought you meant debian | 13:37 |
| tjaalton | Odd_Bloke: there's no SRU bug in the changelog entry | 13:37 |
| caribou | bdmurray: I'll prepare a PR for it next week | 13:37 |
| bdmurray | rbasak: 0.96.20.7 dos have an SRU bug. | 13:37 |
| bdmurray | rbasak: http://launchpadlibrarian.net/317339072/software-properties_0.96.20.6_0.96.20.7.diff.gz | 13:38 |
| rbasak | Oh, OK. And we're restoring the directory in it as well? | 13:38 |
| rbasak | IMHO, that should be changelog noted, but never mind. | 13:38 |
| Odd_Bloke | 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 |
| ubot5` | Ubuntu bug 1664949 in gce-compute-image-packages (Ubuntu Trusty) "Daemons do not log output to serial console" [Undecided,In progress] | 13:39 |
| Odd_Bloke | I guess my assumption is very opaque to the user. | 13:39 |
| Odd_Bloke | tjaalton: Could you reject it and I'll re-upload? | 13:39 |
| tjaalton | Odd_Bloke: yep | 13:40 |
| tjaalton | at least the tools complain about this | 13:40 |
| rbasak | Odd_Bloke: note that the rich history adoption by the importer currently races the SRU queue. Quite suboptimal right now, sorry :-/ | 13:40 |
| tjaalton | so I think it wouldn't add the template entry to the bug | 13:40 |
| rbasak | 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:40 |
| rbasak | nacc or I have to manually do it. | 13:41 |
| rbasak | 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:41 |
| -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20160930-0ubuntu3~14.04.2 => 20160930-0ubuntu6~14.04.0] (ubuntu-cloud) | 13:44 | |
| -queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu6~14.04.0] | 13:49 | |
| tjaalton | Odd_Bloke: I need to run out now :/ | 13:49 |
| Odd_Bloke | tjaalton: No worries; just pushed up the fixed package. | 13:49 |
| Odd_Bloke | Get to it when you can. | 13:49 |
| slangasek | how often is MoM supposed to refresh? | 14:09 |
| * apw is seeing build failures caused by dpkg-genbuildinfo trying to read _all packages on not amd64 | 14:12 | |
| cjwatson | slangasek: half-hourly or so, but it was crashing on something, I've been trying to hit it over the head today | 14:17 |
| slangasek | cjwatson: ok, cheers | 14:17 |
| cjwatson | it has some hateful failure modes | 14:17 |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.25+17.04] | 14:18 | |
| slangasek | alas, poor yorick, your autopkgtests fail | 14:34 |
| slangasek | so... runs under xvfb-run, sometimes creates X windows, sometimes fails. ok then | 14:36 |
| Laney | worked pretty well in zesty | 14:37 |
| === jgrimm is now known as jgrimm-away | ||
| jdstrand | 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 |
| jdstrand | 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:55 |
| slangasek | I wouldn't expect a .buildinfo file in a source upload | 14:57 |
| slangasek | maybe that's a broken dpkg/ | 14:58 |
| mapreri | dpkg-buildpackage always produces .buildinfo, by design. also in source builds. | 14:58 |
| jdstrand | slangasek: so source.changes shouldn't have .buildinfo in it? | 14:58 |
| slangasek | jdstrand: well, see what mapreri says | 14:58 |
| mapreri | another question is how you got one from a zesty host? | 14:58 |
| slangasek | I don't understand that as a 'design' | 14:58 |
| jdstrand | mapreri: I built in an artful schroot. upload from a zesty host | 14:59 |
| mdeslaur | jdstrand: you need to install devtools from artful to get .buildinfo signing | 14:59 |
| jdstrand | ah | 14:59 |
| mapreri | 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. | 14:59 |
| mdeslaur | err, not devtools | 15:00 |
| mapreri | devscripts* | 15:00 |
| mapreri | i.e. debsign, if you are using that to sign. | 15:00 |
| mdeslaur | yeah, devscripts | 15:00 |
| mdeslaur | sorry, brainfrat | 15:01 |
| mdeslaur | brainfart | 15:01 |
| mapreri | but so launchpad forces .buildinfo to be signed correctly? | 15:01 |
| mapreri | (dak doesn't…) | 15:01 |
| cjwatson | it does at the moment yet | 15:05 |
| cjwatson | *yes | 15:05 |
| mapreri | well, keep it that way :) | 15:05 |
| cjwatson | from the discussion yesterday I thought that we should probably SRU the devscripts changes to sign buildinfo if present | 15:05 |
| mapreri | possibly | 15:06 |
| mapreri | it would make senes | 15:06 |
| mapreri | also dscverify | 15:06 |
| rbasak | 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 |
| mapreri | what are you thinking about? | 15:07 |
| mapreri | installed packages and their versions? | 15:07 |
| rbasak | dpkg-buildpackage -S, followed by dput? | 15:07 |
| rbasak | installed packages and their versions> right. | 15:08 |
| mapreri | well, you should be building also the sources in a clean environment, imho, not just the binaries… | 15:08 |
| rbasak | 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 |
| rbasak | mapreri: why? I use git to make sure my source tree is clean. | 15:09 |
| mapreri | I found git trees containing files that should not be uploaded, correctly cleaned by `debian/rules build`. | 15:10 |
| rbasak | "Buliding" the sources shouldn't be a thing. | 15:10 |
| mapreri | err | 15:10 |
| mapreri | `debian/rules clean` | 15:10 |
| jdstrand | mdeslaur: that seemed to work. thanks! :) | 15:11 |
| jdstrand | infinity: nm | 15:11 |
| rbasak | "debian/rules clean" is superseded by "git clean" IMHO | 15:11 |
| rbasak | I know it isn't by policy. | 15:11 |
| rbasak | But "debian/rules clean" may be buggy on a per-package basis. | 15:11 |
| rbasak | "git clean" should always work. | 15:11 |
| rbasak | (unless the package is buggy, in which case at least "git clean" is and will remain consistent) | 15:11 |
| mapreri | then it's a reason to fix it, not ignoring it and just use git :) | 15:12 |
| rbasak | Sure I'll fix it if I know about it. | 15:12 |
| rbasak | But only because policy says that "debian/rules clean" must exist. I'd advocate dropping it. Tooling/client issue. | 15:13 |
| mapreri | 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:13 |
| mapreri | (and there are several followup fixups) | 15:14 |
| cjwatson | yeah, I know it went wrong a couple of time | 15:14 |
| cjwatson | s | 15:14 |
| cjwatson | 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:15 |
| cjwatson | to understand how useful requiring a signature on it is | 15:16 |
| nacc | slangasek: ack, on my todo today to clean up | 15:19 |
| cjwatson | though speaking of buildinfo I guess I should tackle slangasek's https://bugs.launchpad.net/launchpad/+bug/1686242 | 15:23 |
| ubot5` | Ubuntu bug 1686242 in Launchpad itself ".changes files reference .buildinfo files that aren't exposed" [Undecided,New] | 15:23 |
| mapreri | debian #846164 is the relevant bug. | 15:23 |
| ubot5` | 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:23 |
| mapreri | but indeed I can't see any reason to generate a .buildinfo out of a source-only build without any binary artifact generated. | 15:24 |
| cjwatson | 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 |
| mapreri | exactly | 15:25 |
| mapreri | 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 |
| rbasak | That use case certainly does make sense and seems entirely reasonable. | 15:26 |
| mapreri | that's the final dream, anyway. We are still quite far from that goal. | 15:26 |
| rbalint | mapreri: dpkg-buildpackage can fail if build-dependencies in clean target change | 15:28 |
| rbalint | mapreri: dpkg-buildpackage -S | 15:29 |
| mapreri | rbalint: -eparse | 15:29 |
| rbalint | mapreri: dpkg-buildpackage -S can fail if build-dependencies used in d/rules clean target change | 15:29 |
| mapreri | rbalint: what do you mean here by "change"? | 15:30 |
| rbalint | mapreri: broke :-) | 15:30 |
| mapreri | that the clean target modifies the Build-Dependencies list? | 15:30 |
| mapreri | or what | 15:30 |
| rbalint | mapreri: not the list of build dependencies, but the dependencies themselves | 15:31 |
| cjwatson | 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 |
| rbalint | mapreri: like there is an incompatible change in dh-r | 15:32 |
| mapreri | 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:32 |
| cjwatson | 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:33 |
| mapreri | 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 |
| rbasak | Understood, thanks. The annoying thing about not using -nc is that then you technically need build dependencies installed :-/ | 15:34 |
| rbasak | Though in that case, perhaps "usd build-source" must necessarily use a chroot? nacc ^ | 15:34 |
| mapreri | rbasak: I just run -S -d, and install the things only needed for clean, which are usually very few. | 15:35 |
| rbasak | mapreri: sure, but I think tooling for general use needs to dtrt even for the edge cases. | 15:35 |
| rbasak | So what should our git-based workflow recommend/do by default? | 15:36 |
| rbasak | I was hoping to avoid making new contributors set up a chroot. | 15:36 |
| rbasak | (by using PPAs for test builds, etc) | 15:36 |
| cjwatson | If you can guarantee that the source tree has never been built, then I think -nc is safe | 15:36 |
| apw | it now is only safe if you haven't also changed the version number | 15:37 |
| cjwatson | why? | 15:37 |
| mapreri | rbasak: are you sure you can do anything relevant without having a local chroot for test builds? :| | 15:37 |
| apw | (ie don't build -S -nc both sides of it) | 15:37 |
| apw | because the new buildinfo leave mess in the tree in debian/files | 15:37 |
| rbasak | mapreri: yes, by having Launchpad build it for me. | 15:37 |
| cjwatson | ah sure but that's just a bug | 15:37 |
| cjwatson | 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 |
| rbasak | I'm trying to make it as easy for drive-by contributors as possible. | 15:37 |
| mapreri | rbasak: possibly I'm too grumpy and old-style for that idea :) | 15:38 |
| cjwatson | I kind of feel a bit grumpy about encouraging people to regard Launchpad as a test-build service | 15:38 |
| cjwatson | 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 |
| rbasak | One alternative might be to get local building with lxd working better. | 15:39 |
| rbasak | My main gripe with sbuild is that it's a massive pain for a new contributor to set up. | 15:39 |
| cjwatson | An sbuild lxd session mode would be lovely | 15:39 |
| cjwatson | It already has multiple session modes (albeit that one of them is very weird), so it shouldn't be too hard | 15:41 |
| mapreri | isn't lxd too painful to set up for drive-by contributions? | 15:41 |
| rbasak | "I'm after a one command "here, take this git commit (or even work tree) and give me debs)" with no setup | 15:41 |
| rbasak | lxd is trivial to set up, no? | 15:41 |
| mapreri | i find pbuilder way way easier to set up | 15:41 |
| rbasak | 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 | |
| mapreri | then, I'm biased as i'm its maintainer :P | 15:41 |
| cjwatson | ("chroot mode" is the jargon I'm looking for in sbuild) | 15:41 |
| cjwatson | I'd much rather people be directed towards something that is as close as possible to the software stack used in LP | 15:42 |
| cjwatson | lxd is generally pretty easy to set up since it has default image-based workflows | 15:42 |
| rbasak | 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:42 | |
| xnox | slangasek, ^^^^^^ | 15:43 |
| xnox | both ubuntu-meta and ubuntu-advantage-script are in. | 15:43 |
| rbasak | 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:43 |
| slangasek | 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:45 |
| xnox | 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 |
| dpb1 | slangasek: ubuntu-advantage-scripts ? | 15:48 |
| dpb1 | is that better? | 15:49 |
| xnox | slangasek, i object to -scripts because there is only one script so far; if one doesn't count motd snippet =) | 15:50 |
| cjwatson | My rule of thumb is to try to explain what it does rather than what it is | 15:50 |
| xnox | cjwatson, yeah, but i was not sure if ubuntu-esm would be good enough name or not. | 15:50 |
| cjwatson | 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 |
| xnox | slangasek, ubuntu-advantage-esm ? | 15:51 |
| nacc | rbasak: could be, yes -- it should be on our roadmap i guess | 15:51 |
| rbasak | ubuntu-esm-tools? ubuntu-advantage-tools? | 15:51 |
| rbasak | ubuntu-advantage would be fine too, as a package that provides ubuntu-advantage -specific functionality, IMHO. | 15:52 |
| xnox | 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 |
| rbasak | "You have ubuntu-advantage installed" makes sense. | 15:52 |
| nacc | smoser: rbasak: LP: #1687057 | 15:52 |
| ubot5` | Launchpad bug 1687057 in usd-importer "git cannot represent empty directories by default" [Undecided,New] https://launchpad.net/bugs/1687057 | 15:52 |
| nacc | rbasak: since you have a handle on a 'fix', can you assign to yourself? | 15:52 |
| rbasak | ack | 15:53 |
| slangasek | 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 |
| xnox | rbasak, but ubuntu-advantage imho is landscapish functionality to install. | 15:53 |
| rbasak | nacc: "could be, yes" - in response to what please? | 15:53 |
| rbasak | slangasek, xnox: fair, so ubuntu-esm-tools then? | 15:53 |
| dpb1 | xnox: well, it's like naming a list variable. even with one item, plural is better | 15:53 |
| slangasek | xnox: 'ubuntu-advantage' was the guidance from dpb1. I think either 'ubuntu-advantage-tools' or 'ubuntu-advantage-scripts' here. | 15:53 |
| slangasek | I don't care between them | 15:53 |
| * xnox is going away to have starbucks | 15:53 | |
| dpb1 | +1 to either | 15:53 |
| * xnox wants a definitive name | 15:54 | |
| dpb1 | tools or scripts | 15:54 |
| slangasek | xnox: ubuntu-advantage-tools | 15:54 |
| slangasek | done | 15:54 |
| rbasak | One day you'll be shipping a go binary instead of a script. | 15:54 |
| xnox | preferably elected using a condorcet voting method. | 15:54 |
| nacc | rbasak: sorry, in response to modifyin build-source to use lxd or chroot or something else | 15:54 |
| rbasak | nacc: OK, thanks. I'll file a bug against usd build-source then. | 15:54 |
| xnox | slangasek, ok. i will reupload things as tools. | 15:54 |
| nacc | rbasak: thanks | 15:54 |
| -queuebot:#ubuntu-release- New: rejected ubuntu-advantage-script [source] (precise-proposed) [1] | 15:56 | |
| rbasak | nacc: bug 1687059 | 15:59 |
| ubot5` | bug 1687059 in usd-importer ""usd build-source" does not run debian/clean" [High,New] https://launchpad.net/bugs/1687059 | 15:59 |
| nacc | 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:02 | |
| nacc | 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 |
| nacc | 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:11 |
| rbasak | Nice. | 16:12 |
| rbasak | That'll build binaries though right? | 16:12 |
| cjwatson | won't that also do a bunch of adtish things? | 16:12 |
| rbasak | I do see --no-arch-any and --no-arch-all, which together with --source might work. | 16:13 |
| rbasak | cjwatson: how so? I'm not sure I follow. It's just the adt backend we're invoking, right? | 16:13 |
| cjwatson | I haven't looked - is it invoking something other than adt-run? | 16:14 |
| rbasak | I believe so, yes. | 16:14 |
| nacc | cjwatson: testing still so not sure :) | 16:14 |
| cjwatson | I guess that's weird but workable then | 16:14 |
| nacc | 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 | |
| rbasak | cjwatson: I would too. But that's not written :) | 16:15 |
| nacc | oh i think i see what i did wrong | 16:16 |
| nacc | rbasak: this will ... be tricky for the snap though | 16:19 |
| nacc | nope, that wasn't it (i thought maybe because i hadn't done an explicit autopkgtest-build-lxd it was failing | 16:21 |
| nacc | i will note that technically sbuild doesn't mention lxd only lxc | 16:21 |
| rbasak | nacc: snap> yeah :-/ | 16:22 |
| rbasak | Yeah sbuild doesn't currently directly support lxd at all. | 16:22 |
| nacc | 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:24 |
| -queuebot:#ubuntu-release- New source: ubuntu-advantage-tools (precise-proposed/primary) [1] | 16:45 | |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (precise-proposed/main) [1.267.1 => 1.267.2] (core) | 16:48 | |
| nacc | 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:03 |
| nacc | slangasek: that seems to be the source of the failure(s), though, php7.0-cli but php7.1-xml installed | 17:04 |
| slangasek | bdmurray: follow-up comment on https://code.launchpad.net/~vorlon/update-manager/ubuntu-support-optimize/+merge/323363 , further input requested | 17:06 |
| slangasek | nacc: looking | 17:06 |
| nacc | slangasek: thanks | 17:06 |
| slangasek | 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 |
| nacc | oh! it depends on that symbolic phpapi | 17:15 |
| nacc | slangasek: thanks! | 17:15 |
| slangasek | nacc: maybe other revdeps, you'd want to look | 17:18 |
| nacc | slangasek: great, grep-dctrl-packages found a few more | 17:18 |
| nacc | slangasek: thanks again for the pointer | 17:18 |
| slangasek | 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:29 |
| xnox | slangasek, new stuff is in the queue. | 17:34 |
| Odd_Bloke | 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:38 |
| slangasek | Odd_Bloke: done | 17:49 |
| -queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu6~14.04.0] | 17:50 | |
| Odd_Bloke | slangasek: Thanks! | 17:50 |
| fossfreedom | quick question all - ubuntu budgie dailies appear to being built with the zesty seeds. When do the dailies switch to the artful seeds? | 18:04 |
| jbicha | fossfreedom: why do you think it is using the zesty seed? | 18:08 |
| fossfreedom | 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:09 |
| jbicha | fossfreedom: you need to update ubuntu-budgie-desktop | 18:11 |
| fossfreedom | ah - wilco roger | 18:11 |
| jbicha | gnome-documents also has a hard depends on tracker | 18:11 |
| fossfreedom | yep - that has gone as well | 18:12 |
| slangasek | bdmurray: https://code.launchpad.net/~vorlon/update-manager/ubuntu-support-optimize/+merge/323363 - pushed, ready for re-review | 18:18 |
| bdmurray | 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:24 |
| fossfreedom | lol | 18:25 |
| bdmurray | slangasek: no change to the changelog version? | 18:26 |
| slangasek | bdmurray: oops, fixing | 18:29 |
| slangasek | bdmurray: fixed | 18:29 |
| slangasek | bdmurray: except lp was slower than my typing; /now/ fixed | 18:30 |
| bdmurray | slangasek: also all the other prints are "print(" <- no space | 18:31 |
| slangasek | wah | 18:31 |
| slangasek | bdmurray: should I also localize it? :) | 18:31 |
| slangasek | I can't see where the pot update happens | 18:33 |
| slangasek | heh; open-iscsi autopkgtest takes 18m to succeed, 11h 18m to fail | 18:39 |
| nacc | 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 |
| nacc | slangasek: stacks of timeouts, i guess? | 18:39 |
| slangasek | 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 |
| slangasek | nacc: yeah, probably. would be nice if it would fail sooner | 18:40 |
| nacc | slangasek: not sure :) and i'm not sure what is calling it yet | 18:41 |
| nacc | slangasek: yeah, those tests are ... not great on some lvel | 18:41 |
| slangasek | nacc: does the dpkg-divert call happen in build or during build-dep install? | 18:42 |
| infinity | - Remove update-alternatives, dpkg-divert and dpkg-statoverride | 18:42 |
| infinity | compatibility symlinks, again. | 18:42 |
| infinity | dpkg (1.18.11) unstable; urgency=medium | 18:42 |
| nacc | slangasek: looks to be during the build itself | 18:43 |
| nacc | from somethig called supermin? | 18:43 |
| slangasek | 'tool for building supermin appliances' | 18:44 |
| slangasek | which I guess are like supermax appliances but with fewer guards | 18:44 |
| nacc | slangasek: might get fixed witha merge | 18:44 |
| nacc | i'll check | 18:44 |
| infinity | nacc: Probably, given that supermin and libguestfs have both built on Debian long after that dpkg change. | 18:45 |
| nacc | infinity: yeah | 18:45 |
| infinity | Though I see no mention of it in either changelog. | 18:45 |
| infinity | Oh, found it. | 18:45 |
| nacc | 5.1.17-2 ? | 18:45 |
| infinity | supermin (5.1.17-2) unstable; urgency=medium | 18:45 |
| infinity | * Add patch so that we do not look for dpkg* in the wrong places | 18:45 |
| nacc | yeah | 18:45 |
| infinity | Yeah. | 18:45 |
| nacc | ok, i'll merge that | 18:45 |
| slangasek | nacc: actually I just finished a merge here that I can upload if you like | 18:48 |
| nacc | slangasek: oh that'd be great | 18:48 |
| nacc | slangasek: fwiw, i think we just have a pile of rebuilds that i just have to do in the right order for php7.1. I've got the full list now (about 45 packages) and am working through it now | 18:49 |
| * slangasek nods | 18:49 | |
| infinity | I feel like I see some variation of this quote far too often: | 18:51 |
| infinity | "On amd64 and x86 architecture it works only by sheer luck." | 18:51 |
| nacc | heh | 18:52 |
| -queuebot:#ubuntu-release- New source: ubuntu-advantage-tools (precise-proposed/primary) [1] | 18:59 | |
| * infinity glances up. | 19:00 | |
| infinity | slangasek: ^-- Did people decide against the base-files thing after all, or is that something else? | 19:00 |
| slangasek | infinity: yeah, non-base-files | 19:01 |
| slangasek | infinity: I think xnox won an argument I didn't care about ;) | 19:01 |
| infinity | And is someone going to make this get pulled in on upgrade, or will the instructions be "apt-get install ubuntu-thingee && do-enable-thing"? | 19:01 |
| infinity | (I'm totally fine with the latter) | 19:02 |
| slangasek | infinity: ubuntu-minimal incoming | 19:02 |
| infinity | Oh. :P | 19:02 |
| infinity | It's entirely possible to remove minimal from a server by "accident", and I've done it repeatedly. | 19:02 |
| slangasek | well, adding it as a new package in the transitive essential set would be a bit much | 19:03 |
| infinity | I tihnk the last time I removed minimal, it was because of ureadahead messing with me. | 19:03 |
| xnox | infinity, people who remove less don't need a shell script to enable esm repository =) | 19:04 |
| -queuebot:#ubuntu-release- New: rejected ubuntu-advantage-tools [source] (precise-proposed) [1] | 19:05 | |
| xnox | and can download https://esm.ubuntu.com/key.asc using your basic token. | 19:05 |
| -queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [source] (precise-proposed) [1] | 19:05 | |
| infinity | slangasek: Did no one also argue that a tool with a generic name like "ubuntu-advantage" (a product name that refers to a lot more than ESM) might be the wrong name for the binary? :P | 19:05 |
| xnox | we have | 19:05 |
| infinity | xnox: Yeah, I'm not particularly fussed if people need to install it manually. | 19:05 |
| infinity | xnox: The argument for the binary name being wrong fell on deaf ears, I guess? | 19:06 |
| infinity | (ubuntu-esm(1) would have made more sense) | 19:06 |
| xnox | slangasek, infinity - now shall we refresh the data for the command-not-found to include ubuntu-advantage? | 19:06 |
| slangasek | xnox: pass | 19:06 |
| infinity | xnox: Ick, no. | 19:06 |
| * xnox was kidding | 19:06 | |
| -queuebot:#ubuntu-release- New binary: ubuntu-advantage-tools [i386] (precise-proposed/none) [1] (no packageset) | 19:07 | |
| infinity | Though, it's trivial to add a single binary to c-n-f-data without rescanning the archive. | 19:07 |
| slangasek | infinity: in theory the command may be extended later with other subcommands | 19:07 |
| infinity | slangasek: Yeah, I figured that was the counter argument. | 19:07 |
| infinity | slangasek: But a package called "foo-tools" implies multiple tools, so u-a-esm would be a good start. :P | 19:07 |
| * infinity shrugs. | 19:08 | |
| infinity | Also, a manpage that says "this must be run as root" in Section 1 is a bit lolz. | 19:08 |
| infinity | Ditto for it installing to /usr/bin instead of /usr/sbin | 19:08 |
| infinity | But I see you'd accepted anyway. :P | 19:09 |
| slangasek | infinity: go ahead and argue for keeping the release open longer in order to fix these issues? :) | 19:09 |
| slangasek | it does have subcommands that work as non-root | 19:09 |
| infinity | "I'm EOLing today" isn't really the best argument for giving people a free pass on NEW review. | 19:09 |
| xnox | infinity, /usr/bin because usr-merge | 19:09 |
| infinity | xnox: Eh? | 19:09 |
| infinity | xnox: usr-merge isn't bin-sbin merge. | 19:09 |
| xnox | infinity, we are working with people who use github web-ui to edit and commit source code | 19:10 |
| xnox | infinity, oh, on my books it is =) | 19:10 |
| -queuebot:#ubuntu-release- New: accepted ubuntu-advantage-tools [i386] (precise-proposed) [1] | 19:10 | |
| xnox | so choice of /usr/bin was deliberate. | 19:10 |
| xnox | by me | 19:10 |
| infinity | slangasek: But fair on the "some bits work as non-root". | 19:10 |
| slangasek | infinity: it's not a free pass, I'm reviewing it to my usual standards | 19:10 |
| infinity | Well, one bit. | 19:10 |
| xnox | infinity, the plural instead of singular was debated too. '-script' was weird, and '-tool' is weird too, 'ubuntu-advantage' as package name is weird, as it is paid subscription, rather than something one simply installs. | 19:11 |
| slangasek | yes, I didn't want a package name that needs a migration when they add the second tool | 19:12 |
| xnox | infinity, i hate that things are in sbin that have informational parts that work as non-root. | 19:12 |
| infinity | xnox: Yeah, I like the future-proofiness of "u-a-tools" for the package name. Just seems silly to not keep said future-proofiness by having the binary clearly purpose-named. | 19:12 |
| slangasek | and Ubuntu puts /usr/sbin on the non-root path so the distinction is mostly historic in either direction | 19:12 |
| xnox | infinity, to be fair it has *2* scripts, with 4 functions. | 19:12 |
| xnox | enable / disable esm | 19:12 |
| infinity | Right, bin versus sbin, I'm over. It does a thing as non-root. | 19:12 |
| xnox | you are safe / you need ESM motd generation | 19:13 |
| slangasek | so there's another package in NEW for precise-proposed. anyone want nvidia-prime? :P | 19:13 |
| infinity | No. Reject it. | 19:13 |
| slangasek | 151 weeks old, how many years is that | 19:13 |
| infinity | If no one bugged us about needing it in 151 weeks, I suspect they don't need it on EOL day. ;) | 19:14 |
| infinity | Just shy of 3 years. | 19:14 |
| -queuebot:#ubuntu-release- New: rejected nvidia-prime [source] (precise-proposed) [0.5~hybrid0.0.4] | 19:14 | |
| nacc | slangasek: were you mentioning open-iscsi re: src:debconf? | 19:19 |
| slangasek | nacc: yeah | 19:19 |
| nacc | slangasek: it does seem like a real failure (the iscsi root disk logged in and then tried to start a second session) | 19:20 |
| nacc | slangasek: but i can't imagine that's debconf's fault :) | 19:20 |
| slangasek | how rude | 19:20 |
| xnox | slangasek, was the uploader fired before able to nag about that? | 19:22 |
| nacc | slangasek: http://autopkgtest.ubuntu.com/packages/open-iscsi/artful/amd64 sort of implies it's still a bad test :) | 19:22 |
| slangasek | nacc: yes, flaky at least | 19:22 |
| slangasek | it's been running again for 44m, so... | 19:23 |
| nacc | slangasek: yeah | 19:23 |
| xnox | slangasek, so what about meta accept? =) | 19:28 |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (precise-proposed) [1.267.2] | 19:31 | |
| slangasek | xnox: why does xserver-xorg-lts-trusty get added where it wasn't before? | 19:34 |
| xnox | slangasek, i ran update, and that's what is missing. | 19:35 |
| xnox | ... maybe i should not run update. | 19:35 |
| slangasek | xnox: right; I'm concerned whether it's actually correct and very wary of making that change right before we close the archive | 19:35 |
| xnox | slangasek, shall i back that out? | 19:36 |
| slangasek | xnox: maybe we can get infinity to clarify the expected behavior, they were his commits | 19:36 |
| infinity | I think what was expected was that meta wouldn't get updated. | 19:37 |
| slangasek | well geez | 19:37 |
| xnox | i am dputing a meta without -trusty | 19:37 |
| infinity | Yeah, well-thought-out, I know. | 19:37 |
| xnox | because i want to go afk and drink teah | 19:37 |
| slangasek | xnox: thanks | 19:37 |
| slangasek | infinity: next you're going to tell me we shouldn't assume the Date in the Releases file will never change | 19:37 |
| slangasek | xnox: thanks | 19:38 |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (precise-proposed/main) [1.267.1 => 1.267.2] (core) | 19:38 | |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (precise-proposed) [1.267.2] | 19:39 | |
| infinity | I could back out those commits so ./update works as expected, but easy enough to just do it by hand this one time. | 19:39 |
| slangasek | yes | 19:39 |
| infinity | trusty will have similar issues. I'm trying to remember the hysterical raisin for this. Might have had to do with trying to make point release ISO builds behave sensibly. | 19:39 |
| infinity | Though, by xenial, I think I gave up the practice and did it gooder. | 19:40 |
| slangasek | hmmmm | 19:40 |
| infinity | Well, more differenter. | 19:40 |
| slangasek | cyphermox: so the 24-week-old secureboot stack in the precise unapproved queue, that's the old and busted one | 19:40 |
| slangasek | I guess we're not getting a new hot one | 19:41 |
| slangasek | so we should jettison it | 19:41 |
| infinity | It's EOL day, the queues should just be mass rejected. | 19:41 |
| -queuebot:#ubuntu-release- New sync: kreport (artful-proposed/primary) [3.0.0-2] | 19:41 | |
| infinity | (except for this ubuntu-advantage thing) | 19:41 |
| cyphermox | slangasek: correct. | 19:41 |
| slangasek | and the cgroup-lite currently in -proposed? | 19:41 |
| -queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (precise-proposed) [1.9~ubuntu12.04.11] | 19:42 | |
| -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (precise-proposed) [1.19~12.04.1] | 19:42 | |
| -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (precise-proposed) [1.99-21ubuntu3.21] | 19:42 | |
| -queuebot:#ubuntu-release- New sync: kproperty (artful-proposed/primary) [3.0.0-2] | 19:42 | |
| slangasek | and the two packages in NEW for partner | 19:42 |
| -queuebot:#ubuntu-release- Unapproved: rejected shim [sync] (precise-proposed) [0.9+1474479173.6c180c6-0ubuntu1] | 19:42 | |
| infinity | slangasek: Historically, I leave the unverified junk in proposed alone. It can be archived for posterity as-is. | 19:42 |
| slangasek | infinity: and you wouldn't suggest that we, say, get it verified now and promote it and possibly introduce a regression | 19:43 |
| infinity | slangasek: Yeah, let's not do that. | 19:43 |
| slangasek | just checkin' | 19:43 |
| infinity | I mean, I love breaking everyone the day we close the archive and make it impossible to unbreak them, but I'm less in love with being chased by townsfolk with pitchforks. | 19:44 |
| infinity | I have sensitive skin. Pointy things hurt. | 19:44 |
| slangasek | infinity: you're looking at it all wrong, think of your commission on the new ESM signups | 19:44 |
| xnox | lol | 19:45 |
| infinity | slangasek: The S in ESM stands for Security, not Stupidity. Not sure we're signing up to fix the latter. | 19:45 |
| slangasek | huh I thought it was Spaghetti | 19:45 |
| infinity | And there's nothing more secure than a system that won't boot. | 19:45 |
| dpb1 | yummmmm, extended spaghetti | 19:46 |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (precise-proposed) [1.267.2] | 19:49 | |
| cyphermox | infinity: we rely on that amount of security-through-unbootability | 19:52 |
| -queuebot:#ubuntu-release- New: rejected navicli [source] (precise-proposed) [7.33.2.0.51-0ubuntu0.12.04.1] | 19:56 | |
| -queuebot:#ubuntu-release- New: rejected vchs-cloudimage [source] (precise-proposed) [0.1.1ubuntu1~12.04.0] | 19:56 | |
| -queuebot:#ubuntu-release- Unapproved: gnome-documents (zesty-proposed/universe) [3.24.0-0ubuntu1 => 3.24.0-0ubuntu1.1] (desktop-extra, ubuntugnome) | 20:30 | |
| slangasek | hahaha dput refusing to let me upload to an unsupported release | 20:35 |
| -queuebot:#ubuntu-release- Unapproved: update-manager (precise-proposed/main) [1:0.156.14.21 => 1:0.156.14.22] (core) | 20:42 | |
| jbicha | please reject gnome-documents/zesty, I might as well update it to 3.24.1 instead | 20:43 |
| slangasek | infinity: ^^ update-manager for your consideration; text of new message identical to that shown in motd | 20:44 |
| slangasek | jbicha: done | 20:44 |
| -queuebot:#ubuntu-release- Unapproved: rejected gnome-documents [source] (zesty-proposed) [3.24.0-0ubuntu1.1] | 20:45 | |
| infinity | slangasek: Tested? | 20:56 |
| slangasek | infinity: y | 20:56 |
| infinity | slangasek: In 7 locales? | 20:56 |
| slangasek | 7? | 20:56 |
| infinity | slangasek: With one hand tied behind your back? | 20:56 |
| slangasek | my precise chroot has no extra locales, but I could set that up and test (but no translations included I was just being anal in marking it translatable) | 20:57 |
| slangasek | I did have to fix a unicode bug when copying from update-motd because smartquote | 20:57 |
| infinity | slangasek: Yeah, I guess that was my way of saying "why bother marking it translatable", but if it works, it works, and my carefactor for how is low. | 20:58 |
| infinity | slangasek: So, accepting that as the quick hack it is. To not conflate bugs, we should probably just clsoe the one this references with this upload. | 21:01 |
| -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (precise-proposed) [1:0.156.14.22] | 21:01 | |
| * slangasek nods | 21:01 | |
| infinity | slangasek: But if this is The Right Thing going forward, I suspect you want something maintainable, that inserts version numbers into the strings, and actually divines support status based on something other than when you uploaded the patch. ;) | 21:01 |
| slangasek | yep | 21:01 |
| slangasek | http://paste.ubuntu.com/24475235/ | 21:02 |
| slangasek | there, two locales tested ;) | 21:02 |
| Ukikie | I'm presuming PPA builds will fail for precise now? | 21:09 |
| infinity | Ukikie: They will when I mark precise OBSOLETE. I might not do that today, but I will Soon(tm). | 21:10 |
| infinity | We might want to revisit that with an LP twiddle to make ESM releases "sort of obsolete", so PPAs can still target them. I dunno. | 21:11 |
| Ukikie | OK, wondered due to the extended part. Thanks. | 21:11 |
| infinity | That is, indeed, the one open question that is why I won't be closing the archive today. Needs a discussion. And possibly code, depending on the outcome of said discussion. | 21:12 |
| cjwatson | Yeah maybe we should verify that ESM can actually be enabled by users of it before closing | 22:39 |
| cjwatson | (assuming you haven't yet?) | 22:40 |
| infinity | cjwatson: I won't be closing it until next week. | 22:46 |
| infinity | cjwatson: But hi! | 22:46 |
| infinity | cjwatson: Do you have any feelings about if people should or shouldn't be allowed to build PPAs for precise, given that it'll be in a "sort of supported" state? | 22:46 |
| infinity | cjwatson: (If so, I imagine we need a new OBSOLETE-ESM status that would do all the same things as obsolete, but allow PPAs to build against it without the "build for obsolete series" flag set) | 22:47 |
| infinity | wgrant: ^-- Or you can have opinions when you wake up. | 22:52 |
| wgrant | I've been at the airport for two hours... | 22:53 |
| wgrant | infinity: I think we should leave PPAs buildable, though problems arise if they need packages from the private ESM archive... | 22:54 |
| infinity | wgrant: If PPA users are depending on the ESM archive, I think they get to keep both pieces. | 22:55 |
| wgrant | Quite. | 22:55 |
| infinity | wgrant: But "leaving them buildable" implies either not closing the archive, or some twiddling to make closing and PPA-buildability not mutually exclusive. | 22:55 |
| wgrant | infinity: And the value of closing the archive is? | 22:56 |
| wgrant | Beisdes cosmetics, which we've already violated for vivid forever... | 22:56 |
| infinity | wgrant: Tells people to GTFO when they attempt to upload to it. I guess that's about it. | 22:57 |
| wgrant | It's a little unfortunate, but doesn't seem functionally problematic AFAICT | 22:57 |
| infinity | wgrant: Cosmetically, I actually prefer is precise stays listed, as people might use https://launchpad.net/ubuntu/+source/<package> to look up what's published in their still-sort-of-supported release. | 22:58 |
| infinity | I just don't like that it's listed as "SUPPORTED", nor that it allows uploads. | 22:58 |
| infinity | wgrant: But those issues are hardly urgent either, so we can just keep it open. | 22:59 |
| infinity | And maybe decide later if there's some better way to represent the true state. | 22:59 |
| wgrant | That would be my recommendation. | 23:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!