[00:23] <Unit193> For the sake of py3, https://packages.qa.debian.org/c/calibre/news/20191025T011934Z.html might be great to grab, no?
[06:25] <cpaelzer> rafaeldtinoco: rbasak: I've had two MPs of which I said they are not important since they wait on Focal, now that it is open I'd appreciate a timely review if one of you could take a look
[06:25] <cpaelzer> https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374446
[06:25] <cpaelzer> https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374447
[06:27] <cpaelzer> well, now that we know Focal is open and no other fixes will be stacked let me combine them into one ...
[06:42] <cpaelzer> rbasak: rafaeldtinoco: https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374770 would be better
[06:42] <cpaelzer> and in a few minutes we also have proper up to date Focal test build builds in a PPA to try if you want
[06:53] <cpaelzer> also I'm still waiting for all 4  haproxy MPs reachable from https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1841936
[06:53] <cpaelzer> Those are enough MPs to also tag you ahasenack :-)
[06:54] <cpaelzer> ^^
[07:11] <cpaelzer> rafaeldtinoco: the second and third chapter have a lot of overlap
[07:11] <cpaelzer> not sure if you'd want to merge that into one
[07:11] <cpaelzer> rafaeldtinoco: you also have to add a huge disclaimer at the manual qemu-cmdline that this disables everything that libvirt would do in terms of feature control
[07:12] <cpaelzer> it is a (very) last resort effort to do it that way
[07:12] <cpaelzer> also e.g. mds-no can be set normally, I ask you to only use those in the cmdline examples which really don't work any other way
[07:13] <cpaelzer> page breaks before new chapters would also help readability
[07:14] <cpaelzer> Oh you meant this to be for bionic, that is why you consider mds missing
[07:14] <cpaelzer> still ahuge disclaimer please
[07:17] <cpaelzer> IIRC while mds-no was one of the complex arch_capability ones
[07:17] <cpaelzer> md-clear was a normal bit and can be used in Bionic
[07:18] <cpaelzer> TBH I'd not even tell people to use qemu commandline from libvirt xml, it just leads to so many bugs later on all too often
[07:18] <cpaelzer> but with a big disclaimer it might be ok
[07:19] <cpaelzer> overll the doc surely will help people, so I hope you get not only mine but also other feedback and then can publish it somewhere
[09:46] <rafaeldtinoco> thx. yep I need to split what can be done on each version, like the msd-no. and will sure look for feedbacks. Greg's presentation today was all about that, impressive..
[09:48] <rafaeldtinoco> I'll start doing merges today, and code reviews as the doc is finished and repo is opened.
[10:17] <rbasak> cpaelzer: I'm still cloning qemu :-/
[10:17] <cpaelzer> hehe
[10:17] <cpaelzer> rbasak: rafaeldtinoco: glad to see you both, please coordinate that not both of you clean qemu for too long :-)
[10:18] <rbasak> I'm getting an eventual 503 Service Unavailable trying to fetch your branch
[10:18] <rbasak> So I might move on and see if it's working later
[10:19] <cpaelzer> rbasak: maybe do haproxy and let qemu for rafaeldtinoco ?
[10:19] <cpaelzer> that is smaller
[10:19] <cpaelzer> and you are involved from a second POV of the SRU team
[10:19] <rbasak> haproxy isn't cloning either right now
[10:19] <cpaelzer> oh, so it is LP in general
[10:20] <rbasak> I wonder if it's related to the archive opening
[10:20] <rbasak> The git-ubuntu importer is presumably very busy
[10:20] <rafaeldtinoco> I'm starting little later today, will catch up and sync with what's left (leave some reviews for me :)
[10:42] <cjwatson> rbasak: The git-ubuntu importer presumably always uses SSH though?
[10:42] <cjwatson> Or does it use HTTPS to pull?
[10:45] <rbasak> I'm not sure. I can look it up if you need?
[10:45] <cjwatson> Not especially
[10:46] <cjwatson> I should unpack what I said though: the 503s are because there's a lowish limit on concurrent HTTPS connections at the moment because there are some frequent events that amount to DDoS by HTTPS
[10:46] <cjwatson> And limiting concurrent connections makes it easier for the service to recover somewhat naturally most of the time without just faceplanting
[10:47] <rbasak> That makes sense, thanks
[10:51] <rbasak> cpaelzer: looks like haproxy for Focal needs rebasing onto proposed :-/
[10:51] <rbasak> Does that change anything?
[10:51] <cpaelzer> no
[10:51] <cpaelzer> rbasak: I already abandoned the focal MP
[10:51] <rbasak> Ah
[10:51] <cpaelzer> and updated the  bug
[10:52] <cpaelzer> the sync relaces the Focal MP, but SRU MPs stay as-is
[10:52] <cpaelzer> +p
[10:52] <rbasak> Sorry I shouldn't have jumped straight to your branches
[10:57] <rbasak> cpaelzer: I don't see the fix in 2.0.8-1? src/ssl_sock.c appears unchanged.
[10:57] <cpaelzer> I was relying on what I found it tagged in the upstream branch - let me check the actual upload that we got synced
[10:58] <cpaelzer> $ git tag --contains d6de151248603b357565ae52fe92440e66c1177c
[10:58] <cpaelzer> v2.0.8
[10:59] <cpaelzer> just to confirm why I have assumed it would be in there
[10:59] <rbasak> Suddenly I get the opposite answer to my query
[10:59] <rbasak> git diff pkg/ubuntu/eoan-devel pkg/ubuntu/focal-proposed -- src/ssl_sock.c
[10:59] <rbasak> This was previously giving me nothing, but now I see it
[10:59]  * rbasak is puzzled
[11:00] <rbasak> Ah
[11:00] <cpaelzer> the fixes are in on my check to focal-proposed that I just did
[11:00] <rbasak> Apparently working directory matters for that
[11:00] <rbasak> My mistake, osrry
[11:00] <cpaelzer> np
[11:51] <rbasak> cpaelzer: haproxy (three branches) looks good. What's the plan with the bug reference and SRU information?
[11:51] <rbasak> Right now the bug reference doesn't trigger a Launchpad-Bugs-Fixed
[11:51] <rbasak> And the SRU information is for the previous no-change rebuild I think?
[11:52] <cpaelzer> SRU information is for both
[11:52] <cpaelzer> if you read the bug it has two templates now
[11:52] <cpaelzer> and the upload will be done with an -v to the last released version
[11:52] <rbasak> Ah
[11:52] <cpaelzer> that way it will trigger the updates excactly once
[11:52] <rbasak> OK
[11:53] <cpaelzer> but atm autopkgtest has so much to do, I'm not sure when the 2.0.8 sync will release anyway
[11:54] <cpaelzer> but then -proposed is enough (in terms of prereq) to get the SRUs uploaded
[11:54] <cpaelzer> so if you approved them I can go on
[11:55] <cpaelzer> rbasak: I agree that the later ones which already had openssl need updated bug links
[11:55] <cpaelzer> consider that done
[11:56] <rbasak> Well you just convinced me that with a -v in the upload you don't need them? :-P
[11:56] <cpaelzer> which is correct for Bionic
[11:56] <cpaelzer> but D/E never had the openssl upload
[11:56] <rbasak> Ah
[11:56] <cpaelzer> there your feedback was correct
[11:57] <cpaelzer> I'm just proactively fixing your way to be green
[11:59] <cpaelzer> and the 2.0.8 would already be released if the opening of the sync wouldn't put that much pressure on autopkgtest
[11:59] <cpaelzer> things might need a while to settle there
[11:59] <rbasak> I think it's OK for you to mark Fix Committed for Focal and for me to then accept the SRUs.
[12:00] <cpaelzer> done
[12:00] <cpaelzer> now uploading
[12:03] <cpaelzer> rbasak: all tagged and uplaoded, the MPs are marked approved and the bug on Focal "Fix Committed"
[12:03] <cpaelzer> thanks for the review
[12:14] <cpaelzer> thanks for the accept rbasak, that way I can do the tests right away later today
[12:15] <cpaelzer> giving it an hour or two to build and show up in proposed
[12:17] <TJ-> Is the expected output of "dpkg --verify" mostly made up of '?' aside from the MD5 check? Docs say it is using RPM format which would normally be '.' for a pass - can I assume that '?' means "this check not done on Debian" ?
[12:39] <ddstreet> xnox you mind if i merge mdadm, or are you working on it
[13:25] <rafaeldtinoco> xnox: mind taking a look at the following MR whenever you have some time (https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/systemd/+git/systemd/+merge/374027), pls ? systemd-networkd related.
[14:21] <ubuking> Hey!
[15:37] <cpaelzer> ahasenack: postgresql-common 208 showed up, but needs a while to be syncable
[15:37] <cpaelzer> as I said in my mail, maybe you could kick the sync at your EOD
[15:37] <cpaelzer> then it should be available for a sync I'd hope
[15:45] <marcustomlinson> slashd: hey, have I been granted PPU for LibreOffice yet? I noticed I'm still not allowed to trigger autopkgtests against LibreOffice in a PPA
[15:45] <marcustomlinson> "You submitted an invalid request: You are not allowed to upload libreoffice or libreoffice to Ubuntu, thus you are not allowed to use this service."
[15:47] <cpaelzer> marcustomlinson: IIRC that is an action that only core-dev's can do atm
[15:47] <cpaelzer> I think it lacks an ACL finer than that
[15:47] <marcustomlinson> :(
[15:49] <cjwatson> marcustomlinson: I think cpaelzer is mistaken
[15:49] <cjwatson> bileto uses archive.checkUpload to determine whether the requester can upload
[15:50] <marcustomlinson> sounds promising cjwatson thanks
[15:50] <seb128> if you can upload I think you should be able to trigger tests
[15:51] <cjwatson> Indeed.  I checked and marcustomlinson hasn't yet been granted any kind of PPU
[15:51] <marcustomlinson> cjwatson: that would make sense yeah. slashd was gonna do that for me, I just suspect he hasn't gotten around to it yet.
[15:52] <slashd> marcustomlinson, I thought it was sil2100 task, I'll get back to you soon. Sorry for the delay.
[15:52] <seb128> marcustomlinson, just share retry urls on #ubuntu-desktop meanwhile if needed (or sent in query, I'm happy to click on those for you)
[15:52] <Laney> It needs to be done by a member of the TB
[15:53] <marcustomlinson> slashd: ah sorry, you did the team additions, cyphermox was gonna do the PPU
[15:54] <marcustomlinson> thanks seb128, I don't actually need one at this moment, was just giving it a test
[15:54] <slashd> marcustomlinson, I'll figure this out with the other member of the dmb and get back to you soon.
[15:54] <marcustomlinson> thanks slashd, sorry for bugging you (the wrong person)
[15:55] <slashd> marcustomlinson, not problem at all, it's dmb matter so all good
[15:55] <Laney> Not really happy with testing access by trying to create unnecessary jobs
[15:55] <Laney> We are slammed at the minute and libreoffice isn't exactly trivial
[15:56] <marcustomlinson> Laney: well I don't NEED to test is what I'm saying, as I can for amd64 locally first
[16:00] <Laney> Great, that's what everyone should be doing :>
[16:02] <cjwatson> Also you can test for access using edit-acl (lp:ubuntu-archive-tools)
[16:02] <cjwatson> edit-acl -p marcustomlinson query
[16:04] <marcustomlinson> cjwatson: useful thanks :)
[16:24] <sil2100> slashd: I thought only the PPU package addition for Gunnar was my action item?
[16:24] <sil2100> Did I forget something?
[16:24] <sil2100> uh!
[16:27] <slashd> sil2100, it's cyphermox's action
[17:24] <rbasak> bryce: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+ref/importer-add-tests
[17:25] <rbasak> More refactoring and cleanups to come, but that should give you an idea of what's coming.
[17:25] <rbasak> You'll want to spend some time understanding the structure
[17:25] <rbasak> Diff against master please - the individual commits probably won't be helpful
[20:12] <cyphermox> marcustomlinson: PPU is done.
[20:39] <sdk> <jbicha "sdk: there are alternate depende"> That's what I tought but what would be the rationale behing installing the whole ubuntu desktop when apt installing xorg on a netinst? I mean wouldn't it be better to move those dependencies in "suggested packages" insteand of "recommended"?
[20:40] <sdk> <JanC "you can also use --no-install-re"> Thanks but that's exactly what I tried to avoid since I'll need to install each packages I need individually.
[22:32] <RAOF> <sdk "That's what I tought but what wo"> There's no difference in the dependencies between netinst and other install methods; they're backed by the same archive. The solution suggested - `apt install xorg gnome-shell-` should get you xorg without gnome-shell. Check if that set of packages is what you're after. If not, repeat, excluding another likely-looking package with `$PACKAGE-` on the end, until the set of packages is
[22:32] <RAOF> to your liking.
[22:45] <sdk> RAOF: Well, I'll try that solution even if there's a wall of packages to check. I guess I'll have some fun --dry-run'ing a few times until I find all the packages I need to exclude XD.