=== JanC is now known as Guest55043 === JanC_ is now known as JanC [10:47] jbicha: Can https://bugs.launchpad.net/ubuntu-gnome/+bug/1575621 be made public? See https://answers.launchpad.net/launchpad/+question/627738 [10:47] Error: launchpad bug 1575621 not found [11:43] cjwatson: I like that he's all irate about the "so-called LTS", but the software crashing is all from a PPA. [11:58] that PPA is now no longer supported for 16.04 LTS [12:00] I'll follow up on the question [12:00] thanks [14:20] xnox: I just released apt 1.4.3 fixing a bug where the timers get restarted/stopped in postinst/rm scripts of all packages. Nothing on the "runs to soon after" resume side, yet. [14:21] I guess we really want some restart handling of the service, with 15 min delay or so [14:21] (and limit that sensibly) [14:22] But I fear this might be too much, I can't really see what issues could arise from that; and if the service even fails at all (update might exit with 0 if network is not up yet) [14:24] Or imagine some hosts failing all the time [14:24] can't run update all the time [14:26] Yep, resolve failure is transient, that would not cause the unit to fail. A 404 (missing repository) would cause it to fail, we would not want to retry that all the time [14:26] Well, maybe once an hour or so [14:28] Leaves us with sleeping a minute or so in a service which we specify Before=apt-daily, After=suspend, WantedBy=suspend. Fairly hacky. [14:31] juliank, ack, can we do sru of these, without addressing resume. [14:32] bdmurray: slangasek: re LP: #1646739 is it actually fix released? seems to have been spam from someone to change a bunch of state? [14:32] Launchpad bug 1646739 in samba (Ubuntu) ""Use of uninitialized value" in debconf via update-manager" [Critical,Confirmed] https://launchpad.net/bugs/1646739 [14:37] xnox: I'll do some new SRUs matching 1.4.3 later today or tomorrow. I guess I might just write a helper that deals with http and https repositories and calls connect() for each of them in order for a minute, and put that in execstartpre or something. [14:37] nacc: No, I thought I fixed it yesterday [14:37] Let the helper exit with a special exit code and set some restart handling for that. [14:37] (well, maybe no restart if I can't figure out implications) [14:39] If I can figure this out early tomorrow, I might just do 1.4.4 and SRU a more complete fix :) [14:48] bdmurray: thanks [15:15] LP no longer requires buildinfo files to be signed in source uploads. [15:30] thanks! [16:37] rbasak: around? === kenvandine_ is now known as kenvandine [16:45] nacc: o/ [16:47] rbasak: do you have a moment to talk snaps for the importer? [16:47] Sure. HO? [16:47] or IRC? [16:47] HO would be great [16:47] OK. Send a link and I'll be two minutes === Skuggen_ is now known as Skuggen [19:10] rbasak: did we agree/decided on the ubuntu/debian remote change? [19:10] rbasak: and if not, what should the spec be for the fetch of the default remote [19:10] rbasak: 'origin' for now? [19:15] nacc: I don't follow the question [19:15] Which is the default remote? [19:15] rbasak: for `git ubuntu clone` [19:15] rbasak: right now the remote is called 'lpusip' [19:15] I think that should set up both a debian remote and an ubuntu remote, and fetch both [19:15] rbasak: ok, i just wasn't sure if we had agreed on the 'debian', 'ubuntu' remote idea or not :) [19:15] rbasak: ack, will do [19:15] nacc: if you're not happy, further discussion welcome. [19:16] rbasak: no, i just didn't see it int he spec [19:16] rbasak: as it says 'crazy idea' still :) [19:16] nacc: lines 48-55 in the pad? [19:16] Oh :) [19:16] I think it turned out less crazy [19:16] rbasak: ack [19:17] Since we have cleared defined specific refspecs, there shouldn't be any confusing overlap [19:17] yep [19:18] rbasak: do we not want to add any push url at all by default? [19:19] rbasak: i know we don't want any push refspec, but not having a push url means that the importer needs to include a bit more knowledge (or push() does) [19:34] nacc: not sure. I think a push url is probably fine if it's inconvenient otherwise, as ACLs should prevent accidents in the end anyway [19:34] nacc: OTOH, perhaps for our safety the importer should require the push URL explicitly? [19:35] rbasak: right, i think i will do it piecewise [19:35] rbasak: as right now we do add pushurls [19:35] We could always change that later [19:35] rbasak: so i'll keep it in the namespace cleanup and have a followon commit that doesn't have the push url [19:35] Sounds good [20:59] rbasak: hrm, also, our fetch refspec won't see import tags or orphan tags [20:59] rbasak: i can't remember if that was intentional? [21:08] bdmurray, now you rejected gnome-software (3.20.1+git20170509.0.8292905-0ubuntu1) can I re-upload with the same version with a corrected version number? [21:08] It was an annoying copy-paste error in the changelog, not sure the best way to correct that. [21:08] that should have read "corrected changelog entry" [21:08] robert_ancell: yes, you can if it never got published (rejected from queue) [21:18] nacc: not intentional. [21:18] rbasak: if you have the time, cna you update the specs? not sure how you want that to look, as they (import, orphan tags) are not namespaced on the remote [21:22] robert_ancell: pretty sure you can, lp will tell you pretty quickly if not :) [21:23] mwhudson: Actually, LP wouldn't tell him for the same reason that he can indeed reuse the same number. Versions in the queue don't "exist", and it's not checked until it's accepted. [21:24] right, that's what i thought [21:24] time to break the archive by adding python3.6 as a supported version i think [21:26] infinity, awesome, I hoped that was the case [21:26] I wish there was an easy way to pull sometime from the queue you've uploaded [21:28] robert_ancell: queue -Q unapproved -s zesty-proposed fetch $source [21:28] robert_ancell: isn't that what the 'queue' tool in ubuntu-dev-tools does? [21:28] Do I have permissions for that? [21:28] The queue is public. [21:28] So, yes, you should be able to. [21:29] I think. [21:29] I don't see any queue command in ubuntu-dev-tools... [21:29] It's in ubuntu-archive-tools [21:29] nacc: ah. import tags aren't specific to Ubuntu or Debian, are they? IIRC, it's whatever the importer saw first, so often Debian but not when there's an Ubuntu delta? [21:29] lp:ubuntu-archive-tools [21:30] oh right, i bungled the name [21:32] rbasak: right, they are just first-seen [21:32] rbasak: it's the first time any version is ever seen [21:33] Perhaps we could pull them into refs/tags/import/* locally. At least they're still separated from the user's own tags. [21:33] * rbasak forgets what orphan tags are [21:33] When a parent could not be found? [21:33] rbasak: orphan tags exist if we cant' find any parents [21:33] fairly rare, but they exist for some old imports [21:33] I get a "401: Unauthorized" if I try and reject my last upload [21:34] Oh yeah, the "must not fail" thing. I remember now :) [21:34] Do I need to add permissions somewhere? [21:34] I think it'd be OK to pull them into refs/tags/orphan/* as well. [21:34] robert_ancell: oh queue manipulation is different than looking at the queue [21:34] The refspec would have to be a little odd - perhaps in the ubuntu remote but not the debian one? [21:35] rbasak: right, because it's technically "in" both remotes (since they are the same underlying repo) [21:35] robert_ancell: oh, i think i misinterpreted how you used the word 'pull' :-) [21:35] Yeah. A little ugly :-/ [21:35] mwhudson, ah, ok [21:35] So not possible? [21:35] robert_ancell: you meant remove something from the queue? [21:35] robert_ancell: you meant "remove"? [21:35] robert_ancell: you need someone with permissions to do that for you, as you did above (i think) [21:35] i don't think that's possible no [21:35] nacc, yeah, if I make a mistake in an upload, it would be really nice to cancel it an do it again. [21:36] robert_ancell: right, it depends on the series [21:36] robert_ancell: for instance, the devel series, not possible, as it's getting auto-accepted [21:36] robert_ancell: sru, the sru team can reject [21:37] nacc: added to the spec [21:38] rbasak: thanks, and then our acl on the backend for the push will be what prevents users from pushing their import/orphan tags (or changing them or whatever) [21:38] in case they do try to push, that is [21:39] Yeah [21:40] That's exactly the same issue as pushing the branch pointers, right? [21:40] yeah i think so [21:44] robert_ancell: yes, you'll just need to use '-f' with dput [22:15] rbasak: and we're not fetching any tags from a user's git repository? [22:27] rbasak: also, `usd clone` currently creates a tracking branch for lpusip/ubuntu/devel and checks it out. Do we want to just checkout ubuntu/devel (remote branch)? As a local tracking branch? with what name? [22:30] mwhudson: did you already start doing no-change uploads for stage1 http://people.canonical.com/~ubuntu-archive/transitions/html/python3.5-6.html ? [22:33] speaking of transitions ... is there a way tot specify that http://people.canonical.com/~ubuntu-archive/transitions/html/postgresql-9.6.html e.g.'s "bad" shoudl not include things that are also good? [22:33] both those entries appear to be |'d already with 9.6 deps [22:43] mwhudson: now promoted the python3.6 packages [22:46] rbasak: oh and i recall a primary reason for a lot of our non-pygit2 calls -- they didnt' support working-directory at all [22:46] rbasak: i believe they fixed that, i need to check [22:55] rbasak: ok, last point, i think we should iether drop support for --lp-owner to `usd import` or we need to rethink the refspec a bit [22:59] rbasak: actually, maybe this fixes it :) [23:37] rbasak: ok, i think i'm nearly there -- need some assistance on ll. 87-92 in the spec, if you have time tmrw [23:43] cyphermox: fyi, i think i got the open-isns tests to run during the build, will update the MIR [23:45] rbasak: http://paste.ubuntu.com/24557476/