| 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? | 06:13 |
|---|---|---|
| cpaelzer | LocutusOfBorg: hi, I found you hit retry for mrbayes a few times recently | 08:08 |
| 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:09 |
| LocutusOfBorg | cpaelzer, no idea sorry | 08:58 |
| 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 | 08:59 |
| cpaelzer | thanks ginggs, maybe that is the problem | 09:01 |
| cpaelzer | will try that | 09:01 |
| === seb128_ is now known as seb128 | ||
| cpaelzer | LocutusOfBorg: ginggs: the trigger with the new openmpi did it | 09:40 |
| cpaelzer | thanks | 09:40 |
| ginggs | cpaelzer: yw! | 09:41 |
| 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. | 11:58 |
| 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:00 |
| cjwatson | smoser: ... OK, decided I can't do much about the above except to clarify things a bit. Reviewed your branch now | 12:11 |
| 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:36 |
| 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:37 |
| 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:38 |
| cjwatson | smoser: ? | 13:41 |
| smoser | cjwatson: in that paste. the first and last character are a " | 13:41 |
| 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:42 |
| seb128 | dgadomski, but yeah, for gdm no vcs to care about outside of bionic | 13:43 |
| 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:45 |
| 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:46 |
| 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:48 |
| 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:49 |
| cjwatson | smoser: LGTM | 13:52 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 13:58 |
| 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:04 |
| 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:05 |
| 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:11 |
| 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:12 |
| smoser | looking | 14:13 |
| 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:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| cjwatson | Ta | 14:20 |
| 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:24 |
| ginggs | rbasak: squid is in the sync blacklist https://people.canonical.com/~ubuntu-archive/sync-blacklist.txt | 15:37 |
| rbasak | Ah, thanks. | 15:44 |
| 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:50 |
| cjwatson | rbasak: Even if it weren't in the blacklist, it'd require manual attention due to having previously been removed from Ubuntu | 15:58 |
| 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:00 |
| 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:19 |
| 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? | 16:44 |
| === abeato is now known as abeato-away | ||
| slangasek | kees: you had to be difficult; now I'm lost inside the rsync protocol :P | 18:28 |
| kees | slangasek: lol | 19:12 |
| 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:48 |
| raidensnake | it's the package on this link. | 20:49 |
| raidensnake | https://code.launchpad.net/~ubuntu-audio-dev/+archive/ubuntu/alsa-daily/+packages | 20:49 |
| === ads20000_ is now known as ads20000 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!