[06:13] <doko> jamespage, coreycb: https://tracker.debian.org/news/977343/accepted-glance-21601-7-source-all-into-unstable/ please could you address this upstream as well?
[08:08] <cpaelzer> LocutusOfBorg: hi, I found you hit retry for mrbayes a few times recently
[08:09] <cpaelzer> I found openssh migration breaking on it as well and wanted to ask if you know anything about the background of this
[08:09] <cpaelzer> is the mrbayes package just flaky or is there more to it?
[08:58] <LocutusOfBorg> cpaelzer, no idea sorry
[08:59] <ginggs> cpaelzer: you need to trigger with openmpi/3.1.1.real-4 as well
[08:59] <ginggs> openmpi/3.1.1.real-1 in release is broken
[09:01] <cpaelzer> thanks ginggs, maybe that is the problem
[09:01] <cpaelzer> will try that
=== seb128_ is now known as seb128
[09:40] <cpaelzer> LocutusOfBorg: ginggs: the trigger with the new openmpi did it
[09:40] <cpaelzer> thanks
[09:41] <ginggs> cpaelzer: yw!
[11:58] <cjwatson> smoser: Looking, but I hadn't QAed the LP branch myself before it was deployed owing to being on holiday, and the response from the new endpoint isn't quite what I want it to be (JSON rather than just an octet-stream), so I'd like to work on that a bit more before you deploy anything that uses it.
[12:00] <cjwatson> (it's possible I can't do anything about that aspect of the response due to how lazr.restful works, but I want to at least look into it)
[12:11] <cjwatson> smoser: ... OK, decided I can't do much about the above except to clarify things a bit.  Reviewed your branch now
[13:36] <slashd> seb128: dgadomski and I will work on both SRUs (our and yours). For the SRU is there anything we need to do at the vcs level ? Just make to make sure we don't add extra work again for you.
[13:37] <slashd> re: gdm3 ^
[13:37] <smoser> cjwatson: around ?
[13:37] <seb128> slashd, there is a vcs on https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gdm3/log/?h=ubuntu/bionic if you want to mp against that
[13:37] <smoser> http://paste.ubuntu.com/p/xjQcHrgBr9/
[13:38] <slashd> dgadomski, ^
[13:38] <seb128> slashd, but if you want to avoid the work let me just know when you update and I can gbp import-dsc the upload
[13:38] <dgadomski> hey seb128, is xenial also handled via vcs?
[13:38] <smoser> expected ^ ? they payload is surrounded by double quotes
[13:38] <seb128> dgadomski, no, you can see the branches on https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gdm3/?h=ubuntu/bionic
[13:38] <seb128> we started using git recently and bionic is the only serie where we do enough work to justify it
[13:41] <cjwatson> smoser: ?
[13:41] <smoser> cjwatson: in that paste. the first and last character are a "
[13:42] <dgadomski> seb128: thanks, I've seen the branches, but was wondering if there's e.g. a legacy bzr branch for xenial, I think now I get it
[13:42] <smoser> seems not expected to me. if it is expected, then i have to adjust the branch for softwareproperties to remove to return data[1:-1]
[13:42] <seb128> dgadomski, check debian/control from the current SRU, if there is no such info there is probably no vcs
[13:43] <seb128> dgadomski, but yeah, for gdm no vcs to care about outside of bionic
[13:45] <cjwatson> smoser: Yes, that's what I was talking about when I mentioned JSON above.  You must not do data[1:-1]; instead, just parse the response as JSON (notice that it has Content-Type: application/json)
[13:45] <cjwatson> (see also https://code.launchpad.net/~cjwatson/launchpad/archive-get-signing-key-data-text/+merge/352298 which clarifies the docs)
[13:45] <smoser> oh. right. ok.
[13:46] <smoser> i thought you were saying you *wanted* a json blob to be returned (as in {"key_data": "blob here"})
[13:46] <cjwatson> Due to the way the API infrastructure works it isn't practical to have a method that returns a non-JSON response
[13:46] <cjwatson> I'd have preferred to have it just be Content-Type: application/octet-stream, but that would be a whole ton of hacking
[13:46] <cjwatson> smoser: You should probably just do accept_json=True
[13:48] <smoser> yeah. i'll push that. it does work.
[13:48] <cjwatson> Sorry, I did actually notice that in your branch but apparently completely forgot to write it in my review
[13:49] <smoser> well, at least we caught it before i uploaded . :)
[13:49] <smoser> i'll give it a full spin and install and use before uploading.
[13:49] <smoser> but could you give it one more lok ?
[13:52] <cjwatson> smoser: LGTM
[13:55] <smoser> bugger.
[13:55] <smoser> cjwatson: so... my change to use the devel api encdpiont seems to have broken python2
[13:55] <smoser> does that make any sense to you?
[13:56] <smoser>  python -m softwareproperties.ppa ppa:~smoser/ppa
[13:56] <smoser> that does not work.
[13:56] <smoser> but python3 same thing does
[13:56] <cjwatson> smoser: what's the error?
[13:56] <smoser> and if i change the 'devel/' to '1.0/' we're good. i'll get
[13:57] <smoser> The user named '~smoser' has no PPA named 'ppa'
[13:57] <smoser> http://paste.ubuntu.com/p/qXT7KVQfb8/
[13:57] <cjwatson> It may just need you to not use the obsolete PPA path syntax.  Let me see
[13:58] <cjwatson> (The canonical URL path for a PPA has been /~OWNER/+archive/DISTRIBUTION/ARCHIVENAME for a while, but I think s-p still uses the deprecated /~OWNER/+archive/ARCHIVENAME form)
[13:58] <cjwatson> Weird that it would be version-dependent though
[14:04] <smoser> cjwatson: its getting a 301
[14:04] <smoser> and the python curl path isn't handling that.
[14:04] <smoser> python2 curl path. but the python3 libvrary does the right hting.
[14:04] <cjwatson> Oh, right, there's that weird urllib.request / pycurl thing
[14:05] <smoser> cjwatson: shall i
[14:05] <smoser>  crl.setopt(pycurl.FOLLOWLOCATION, 1)
[14:05] <cjwatson> hang on a sec, I'm looking into this
[14:05] <smoser> or shall i modify it to do the other url ?
[14:05] <smoser> ok.
[14:11] <smoser> cjwatson: i'm sure you're on it. but the differnce seems to me to be that in 1.0, a request for ~smoser/+archive/ppa will return the data directly.
[14:11] <cjwatson> smoser: So there's already code to handle this, sort of, although it's a bit strange and not used consistently.  How about https://paste.ubuntu.com/p/JnKhm7QMrh/ (only lightly tested) to tighten things up a bit?
[14:12] <cjwatson> smoser: Note that I fixed a bug in passing in how _recv_key is being called
[14:12] <smoser> but in devel, it will return a redirect to ~smoser/+archive/ubuntu/ppa
[14:12] <cjwatson> Yep, I know
[14:13] <smoser> looking
[14:15] <cjwatson> http://bazaar.launchpad.net/+branch/launchpad/view/head:/lib/lp/registry/browser/person.py#L489 is the code responsible for this special case
[14:17] <cjwatson> You want to do this kind of thing rather than adding an 'ubuntu' segment to the LAUNCHPAD_PPA_API URL, because otherwise you're going to run into trouble with existing handling of ppa:~smoser/ppa vs. ppa:~smoser/ubuntu/ppa, I think
[14:17] <cjwatson> Maybe not in precisely this code path but in other ones
[14:18] <smoser> yeah.
[14:18] <cjwatson> All very twisty
[14:18] <smoser> do you tihnk we should add follow_redirct just for good measure ?
[14:18] <cjwatson> No opinion
[14:18] <cjwatson> I guess it shouldn't hurt
[14:19] <cjwatson> And it would probably be better if it dealt with redirects consistently
[14:19] <cjwatson> So I guess I do have an opinion, please do :)
[14:19] <smoser> yeah. ok. i will add.
[14:20] <cjwatson> Ta
[15:24] <rbasak> Why is src:squid not autosyncing from Debian? Not that I'm sure I want it right now, but I'd like to understand what's going on first.
[15:24] <rbasak> Is it because src:squid in Ubuntu last had a delta, even though it has since been deleted?
[15:37] <ginggs> rbasak: squid is in the sync blacklist https://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[15:44] <rbasak> Ah, thanks.
[15:50] <rbasak> slangasek: could you look at https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863 please? As I understand that statement, the risk of regressing existing users by changing the ABI doesn't exist, and so your primary justification might be moot.
[15:50] <ubottu> Launchpad bug 1779863 in nodejs (Ubuntu Cosmic) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Medium,In progress]
[15:50] <rbasak> ddstreet: ^
[15:58] <cjwatson> rbasak: Even if it weren't in the blacklist, it'd require manual attention due to having previously been removed from Ubuntu
[16:00] <cjwatson> rbasak: https://people.canonical.com/~ubuntu-archive/auto-sync/current.log is a not-super-friendly log of auto-sync's decisions there (though doesn't include blacklisted packages)
[16:19] <jbicha> speaking of the blacklist, there's bug 1770792 if an AA has some extra time
[16:19] <ubottu> bug 1770792 in ubuntu-meta (Ubuntu) "Clean up sync blacklist" [Wishlist,New] https://launchpad.net/bugs/1770792
[16:44] <slangasek> rbasak, ddstreet: ah interesting, if true then that satisfies me and I would accept the nodejs SRU.  But can we be sure that all modules someone might build would be affected by this node-gyp bug?  Are there no other ways people build node modules?
=== abeato is now known as abeato-away
[18:28] <slangasek> kees: you had to be difficult; now I'm lost inside the rsync protocol :P
[19:12] <kees> slangasek: lol
[20:48] <raidensnake> sorry to bother you but I need to know if it's possible for someone to make a bionic version of the intel hda fix
[20:49] <raidensnake> it's the package on this link.
[20:49] <raidensnake> https://code.launchpad.net/~ubuntu-audio-dev/+archive/ubuntu/alsa-daily/+packages
=== ads20000_ is now known as ads20000