[10:47] <cjwatson> jbicha: Can https://bugs.launchpad.net/ubuntu-gnome/+bug/1575621 be made public?  See https://answers.launchpad.net/launchpad/+question/627738
[11:43] <infinity> cjwatson: I like that he's all irate about the "so-called LTS", but the software crashing is all from a PPA.
[11:58] <jbicha> that PPA is now no longer supported for 16.04 LTS
[12:00] <jbicha> I'll follow up on the question
[12:00] <cjwatson> thanks
[14:20] <juliank> 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] <juliank> I guess we really want some restart handling of the service, with 15 min delay or so
[14:21] <juliank> (and limit that sensibly)
[14:22] <juliank> 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] <juliank> Or imagine some hosts failing all the time
[14:24] <juliank> can't run update all the time
[14:26] <juliank> 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] <juliank> Well, maybe once an hour or so
[14:28] <juliank> 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] <xnox> juliank, ack, can we do sru of these, without addressing resume.
[14:32] <nacc> bdmurray: slangasek: re LP: #1646739 is it actually fix released? seems to have been spam from someone to change a bunch of state?
[14:37] <juliank> 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] <bdmurray> nacc: No, I thought I fixed it yesterday
[14:37] <juliank> Let the helper exit with a special exit code and set some restart handling for that.
[14:37] <juliank> (well, maybe no restart if I can't figure out implications)
[14:39] <juliank> If I can figure this out early tomorrow, I might just do 1.4.4 and SRU a more complete fix :)
[14:48] <nacc> bdmurray: thanks
[15:15] <cjwatson> LP no longer requires buildinfo files to be signed in source uploads.
[15:30] <jbicha> thanks!
[16:37] <nacc> rbasak: around?
[16:45] <rbasak> nacc: o/
[16:47] <nacc> rbasak: do you have a moment to talk snaps for the importer?
[16:47] <rbasak> Sure. HO?
[16:47] <rbasak> or IRC?
[16:47] <nacc> HO would be great
[16:47] <rbasak> OK. Send a link and I'll be two minutes
[19:10] <nacc> rbasak: did we agree/decided on the ubuntu/debian remote change?
[19:10] <nacc> rbasak: and if not, what should the spec be for the fetch of the default remote
[19:10] <nacc> rbasak: 'origin' for now?
[19:15] <rbasak> nacc: I don't follow the question
[19:15] <rbasak> Which is the default remote?
[19:15] <nacc> rbasak: for `git ubuntu clone`
[19:15] <nacc> rbasak: right now the remote is called 'lpusip'
[19:15] <rbasak> I think that should set up both a debian remote and an ubuntu remote, and fetch both
[19:15] <nacc> rbasak: ok, i just wasn't sure if we had agreed on the 'debian', 'ubuntu' remote idea or not :)
[19:15] <nacc> rbasak: ack, will do
[19:15] <rbasak> nacc: if you're not happy, further discussion welcome.
[19:16] <nacc> rbasak: no, i just didn't see it int he spec
[19:16] <nacc> rbasak: as it says 'crazy idea' still :)
[19:16] <rbasak> nacc: lines 48-55 in the pad?
[19:16] <rbasak> Oh :)
[19:16] <rbasak> I think it turned out less crazy
[19:16] <nacc> rbasak: ack
[19:17] <rbasak> Since we have cleared defined specific refspecs, there shouldn't be any confusing overlap
[19:17] <nacc> yep
[19:18] <nacc> rbasak: do we not want to add any push url at all by default?
[19:19] <nacc> 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] <rbasak> 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] <rbasak> nacc: OTOH, perhaps for our safety the importer should require the push URL explicitly?
[19:35] <nacc> rbasak: right, i think i will do it piecewise
[19:35] <nacc> rbasak: as right now we do add pushurls
[19:35] <rbasak> We could always change that later
[19:35] <nacc> rbasak: so i'll keep it in the namespace cleanup and have a followon commit that doesn't have the push url
[19:35] <rbasak> Sounds good
[20:59] <nacc> rbasak: hrm, also, our fetch refspec won't see import tags or orphan tags
[20:59] <nacc> rbasak: i can't remember if that was intentional?
[21:08] <robert_ancell> 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] <robert_ancell> It was an annoying copy-paste error in the changelog, not sure the best way to correct that.
[21:08] <robert_ancell> that should have read "corrected changelog entry"
[21:08] <nacc> robert_ancell: yes, you can if it never got published (rejected from queue)
[21:18] <rbasak> nacc: not intentional.
[21:18] <nacc> 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] <mwhudson> robert_ancell: pretty sure you can, lp will tell you pretty quickly if not :)
[21:23] <infinity> 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] <mwhudson> right, that's what i thought
[21:24] <mwhudson> time to break the archive by adding python3.6 as a supported version i think
[21:26] <robert_ancell> infinity, awesome, I hoped that was the case
[21:26] <robert_ancell> I wish there was an easy way to pull sometime from the queue you've uploaded
[21:28] <infinity> robert_ancell: queue -Q unapproved -s zesty-proposed fetch $source
[21:28] <mwhudson> robert_ancell: isn't that what the 'queue' tool in ubuntu-dev-tools does?
[21:28] <robert_ancell> Do I have permissions for that?
[21:28] <infinity> The queue is public.
[21:28] <infinity> So, yes, you should be able to.
[21:29] <infinity> I think.
[21:29] <robert_ancell> I don't see any queue command in ubuntu-dev-tools...
[21:29] <infinity> It's in ubuntu-archive-tools
[21:29] <rbasak> 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] <infinity> lp:ubuntu-archive-tools
[21:30] <mwhudson> oh right, i bungled the name
[21:32] <nacc> rbasak: right, they are just first-seen
[21:32] <nacc> rbasak: it's the first time any version is ever seen
[21:33] <rbasak> 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] <rbasak> When a parent could not be found?
[21:33] <nacc> rbasak: orphan tags exist if we cant' find any parents
[21:33] <nacc> fairly rare, but they exist for some old imports
[21:33] <robert_ancell> I get a "401: Unauthorized" if I try and reject my last upload
[21:34] <rbasak> Oh yeah, the "must not fail" thing. I remember now :)
[21:34] <robert_ancell> Do I need to add permissions somewhere?
[21:34] <rbasak> I think it'd be OK to pull them into refs/tags/orphan/* as well.
[21:34] <nacc> robert_ancell: oh queue manipulation is different than looking at the queue
[21:34] <rbasak> The refspec would have to be a little odd - perhaps in the ubuntu remote but not the debian one?
[21:35] <nacc> rbasak: right, because it's technically "in" both remotes (since they are the same underlying repo)
[21:35] <mwhudson> robert_ancell: oh, i think i misinterpreted how you used the word 'pull' :-)
[21:35] <rbasak> Yeah. A little ugly :-/
[21:35] <robert_ancell> mwhudson, ah, ok
[21:35] <robert_ancell> So not possible?
[21:35] <nacc> robert_ancell: you meant remove something from the queue?
[21:35] <mwhudson> robert_ancell: you meant "remove"?
[21:35] <nacc> robert_ancell: you need someone with permissions to do that for you, as you did above (i think)
[21:35] <mwhudson> i don't think that's possible no
[21:35] <robert_ancell> nacc, yeah, if I make a mistake in an upload, it would be really nice to cancel it an do it again.
[21:36] <nacc> robert_ancell: right, it depends on the series
[21:36] <nacc> robert_ancell: for instance, the devel series, not possible, as it's getting auto-accepted
[21:36] <nacc> robert_ancell: sru, the sru team can reject
[21:37] <rbasak> nacc: added to the spec
[21:38] <nacc> 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] <nacc> in case they do try to push, that is
[21:39] <rbasak> Yeah
[21:40] <rbasak> That's exactly the same issue as pushing the branch pointers, right?
[21:40] <nacc> yeah i think so
[21:44] <bdmurray> robert_ancell: yes, you'll just need to use '-f' with dput
[22:15] <nacc> rbasak: and we're not fetching any tags from a user's git repository?
[22:27] <nacc> 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] <doko> 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] <nacc> 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] <nacc> both those entries appear to be |'d already with 9.6 deps
[22:43] <doko> mwhudson: now promoted the python3.6 packages
[22:46] <nacc> 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] <nacc> rbasak: i believe they fixed that, i need to check
[22:55] <nacc> 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] <nacc> rbasak: actually, maybe this fixes it :)
[23:37] <nacc> 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] <nacc> cyphermox: fyi, i think i got the open-isns tests to run during the build, will update the MIR
[23:45] <nacc> rbasak: http://paste.ubuntu.com/24557476/