[03:01] <Unit193> sarnold: Poooke.
=== Guest74533_ is now known as braderhart
[10:35] <didrocks> bdmurray: hey! So, I expanded a little bit on https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1774597/comments/9, I would like to know in particular what do you think about the way to fix the first bug, promoting as a SRU apport-noui to main and seed it or moving the unit files?
[10:35] <ubottu> Launchpad bug 1774597 in gnome-control-center (Ubuntu Bionic) "G-C-C privacy option don't allow sending manual report" [Low,Fix committed]
=== giraffe is now known as Guest34814
[11:26] <bluesabre> Any core devs interested in sponsoring this gvfs upload? https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1762595
[11:26] <ubottu> Launchpad bug 1762595 in gvfs (Ubuntu) "Thunar incorrectly thinks USB storage device hasn't finished ejecting" [Undecided,New]
[11:28] <bluesabre> infinity: would you be interested in reviewing our merges for Xubuntu Base/Core? https://code.launchpad.net/~xubuntu-dev/debian-cd/xubuntu-base/+merge/347414, https://code.launchpad.net/~xubuntu-dev/livecd-rootfs/xubuntu-base/+merge/347319, https://code.launchpad.net/~xubuntu-dev/ubuntu-cdimage/xubuntu-base/+merge/347320
[13:31] <GunnarHj> Hi mvo, I'd like to call your attention to bug #1758684. First I thought that LP was broken somehow, but - as wgrant explained - the problem is that the number of strings in the POT varies between the builds for respective architecture. So the POT build when uploading is simply not reliable; it fails more often than not.
[13:31] <ubottu> bug 1758684 in Ubuntu Translations "LP only imported a fraction of the snappy translation template" [High,In progress] https://launchpad.net/bugs/1758684
[13:51] <cpaelzer> Skuggen: hi a question - https://github.com/mysql/mysql-server/blob/8.0/scripts/mysqldumpslow.sh#L66 needs https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/819535/comments/6
[13:51] <ubottu> Launchpad bug 819535 in mysql-5.7 (Ubuntu) "mysqldumpslow looking for slow.log file on an incorrect directory" [Low,Confirmed]
[13:52] <cpaelzer> Skuggen: I wonder what the best path is to submit that, and rbasak recommended to ping you
[13:52] <cpaelzer> should I do a PR for it on github, or a report in their bugzilla (need Oracle id :-/) or ... ?
[14:26] <mvo> GunnarHj: aha, thank you! let me look at this
[14:52] <GunnarHj> mvo: Yeah, please do. ;) I have tried to fix it manually a few times, but that's not a sustainable model.. And the with the latest bionic upload none of the architectures seems to have produced a complete POT.
[14:56] <mvo> GunnarHj: aha, so the problem is that this is not properly sorted? the pot?
[15:13] <GunnarHj> mvo: Don't think it is about sorting. Every upload results in multiple build, one for each architecture, and each build generates a POT. AFAIU those POTs ought to be identical, but they are not. You may want to take a look at the latest tarballs with stripped translations:
[15:13] <GunnarHj> https://launchpad.net/ubuntu/bionic/+queue?queue_state=3&queue_text=snapd_2.33.1
[15:17] <nacc> bluesabre: i can try and look today
[15:18] <mvo> GunnarHj: aha, I see, it looks like the i386 version is very short for some reason
[15:19] <mvo> GunnarHj: thanks again, I see that one set of files in ~40k and the other 9kb so something is wrong, I dig into it
[15:22] <GunnarHj> mvo: Right, that's it. And furthermore, unless you dropped dozens of translatable strings in 2.33, I don't think that any of those tarballs contains a complete POT with all strings which ought to be there.
[15:23] <mvo> GunnarHj: yeah, its strange when I run this locally it seems to be fine
[15:24] <mvo> GunnarHj: I need to dig a bit harder. I also wonder if its always the same architecture that has not enough data
[15:24] <mvo> GunnarHj: or if it is random
[15:25] <GunnarHj> mvo: It's certainly random. (I thoght otherwise first.)
[15:29] <GunnarHj> mvo: So I withdraw my suggestion in comment #19 in the bug report.
[15:30] <mvo> GunnarHj: yeah, I think we need to get to the bototm of this, is it only happening on 18.04+?
[15:36] <GunnarHj> mvo: Don't know. Have only looked at 18.04, but I suppose we have reasons to fear that it's not limited to that.
[16:02] <mvo> GunnarHj: I added two snapd PRs to attack the issue #5404 and 5402
[16:48] <tsimonq2> smoser: What's your UTC offset, out of curiosity?
[16:48] <tsimonq2> Because if you have the time right now, I'd like to talk about ssh-import-id.
[16:52] <smoser> ah. tsimonq2 i am US/Eastern (-0400)
[16:52] <smoser> sure. we can chat now.
[16:53] <tsimonq2> smoser: Ah, nice, I'm US/Central.
[16:55] <tsimonq2> smoser: So to get this straight, doesn't Launchpad 404 even when you're trying to get team SSH keys?
[16:55] <ubottu> Launchpad bug 404 in Launchpad itself "PyGettextPO is not able to handle Unicode strings" [High,Fix released] https://launchpad.net/bugs/404
[16:57] <tsimonq2> Ah, no, I'm wrong.
[16:58] <tsimonq2> smoser: Your implementation in fetch_keys_lp LGTM. I'm just wondering about the best way to recursively do teams.
[16:58] <mnaumann> hi. would you say it is expected that gnupg2 crashes when you try to encrypt to an ecdsa key on 16.04.4?
[16:59] <smoser> tsimonq2: http://paste.ubuntu.com/p/vYmCHSFXZM/
[16:59] <tsimonq2> smoser: Right.
[16:59] <smoser> the one thing i'm not sure of ... don't have a user without ssh keys, is if you can tell the difference between valid-group and user-with-no-keys
[17:00] <tsimonq2> Perhaps from there we could fall back to launchpadlib.
[17:00] <tsimonq2> But, iff there's no keys fetchable via the way already implemented.
[17:01] <tsimonq2> (So existing users wouldn't have the overhead.)
[17:01] <smoser> well, thats what i had originally suggested. that we could do that.
[17:01] <smoser> but will your MP do recursive groups ?
[17:02] <tsimonq2> Mine doesn't. In order to do that, we would need to implement a system to continue down the recursive chain and avoid duplicates (and eliminate duplicate LP usernames).
[17:03] <tsimonq2> We could probably use a set or something like that for the individual usernames... then when we scan a group, put it in a list.
[17:03] <tsimonq2> The only question would be how to correctly avoid duplicate group scans.
[17:05] <smoser> well, one level of groups is not terribly useful, right?
[17:05] <tsimonq2> Right.
[17:06] <smoser> and yeah, duplicate group membership is kind of a pain. and my 'path' suggestion is overly simplistic in that regard
[17:06] <smoser> the reason i was thinking that way was
[17:06] <smoser> a.) there is a bug open for "trimming" removed entries .. in order to do that we have to know how an entry got in there.
[17:07] <tsimonq2> (Got a link for that ooc?)
[17:07] <smoser> b.) if you import a group and all you got was the group name as a marker there, it isn't that useful
[17:08] <tsimonq2> Oh, right.
[17:08] <smoser> https://bugs.launchpad.net/ssh-import-id/+bug/1745541
[17:08] <ubottu> Launchpad bug 1745541 in ssh-import-id "Delete SSH key on remote removal" [Wishlist,Triaged]
[17:10] <tsimonq2> For the comment aspect of this... maybe the comment could contain every way the key was added (how the person was pulled in), and on calling remove, if removing all comment listings for that entry, delete the whole key, otherwise keep the key and the remaining references.
[17:11] <tsimonq2> For example, let's say I added my key to a server, I add ~lubuntu-dev, but I then want to remove ~lubuntu-dev. It shouldn't pull my key with it in the removal command.
[17:13] <tsimonq2> This seems a bit hacky, but when recursively scanning teams we could keep two variables: a set for the teams searched (and searching of the set before adding a team) and a dictionary of people with the teams that correspond to each person.
[17:13] <tsimonq2> When the scanning is done, we could take the latter variable and add the keys with the appropriate references.
[17:14] <tsimonq2> smoser: How does that sound?
[17:14] <smoser> i'd thought of that, but it will get long possibly.
[17:16] <smoser> i think your suggestion is sane.
[17:16] <smoser> i'm ok though to first blush justput the group/user name there and improve on it later
[17:16] <smoser> but i really want to have the user name that it came from
[17:18] <tsimonq2> So the case where I add ~ubuntu-core-dev, add ~lubuntu-dev, then want to remove ~lubuntu-dev without it removing ~ubuntu-core-dev with it?
[17:18] <tsimonq2> That's a good point.
[17:18] <tsimonq2> Let's some up with some comment syntax...
[17:20] <tsimonq2> Maybe something like this: # ssh-import-id lp:tsimonq2;~ubuntu-dev;~motu (this is in the case that somebody added ~ubuntu-dev)
[17:20] <tsimonq2> So, username, original username added, then what team it's pulled in as a part of...
[17:22] <smoser> that just gets long though. i'm willing to sovle that at the po int where we attempt to do removal
[17:22] <smoser> you dont have to bite all that off now
[17:23] <tsimonq2> I think once we add support for adding them, there should be support for removing them, right?
[17:25] <tsimonq2> (And if anything though, I don't know if the reason for pulling it in even matters... maybe something like # ssh-import-id lp:tsimonq2 ~ubuntu-dev;~lubuntu-dev;etc. would work better.)
[17:25] <smoser> tsimonq2: well there is no support for removing anything right now
[17:26] <tsimonq2> Yes there is. `ssh-import-id -r tsimonq2` works fine for me.
[17:26] <smoser> oh. i didnt remembre that ;)
[17:27] <tsimonq2> np :D
[17:29] <smoser> it seems reasonably defensible for '-r' to apply only to the way the user was added i think
[17:29] <smoser> ie, ssh-import-id lubuntu-dev
[17:29] <tsimonq2> Right, which is why I proposed the second scheme
[17:29] <smoser> adds tsimonq, so -r lubuntu-dev would remove all of those
[17:30] <tsimonq2> It would remove all keys explicitly added by lubuntu-dev.
[17:30] <tsimonq2> However, if I add my own key, then add lubuntu-dev, but then remove lubuntu-dev, my key should stay.
[17:30] <smoser> yeah
[17:31] <tsimonq2> (One thing I'd like to implement after this is merged is refresh support, so someone could do e.g. ssh-import-id --refresh lubuntu-dev and if I add/remove a key from my LP profile, or if a user is added or removed from the team, it would automatically update the client. It would be a very similar thing to this to implement, I think.)
[17:33] <tsimonq2> smoser: Either way, I can come up with an updated MP (or you can, whatever you'd like to do) soon which implements A) the changes you've already made B) support for adding teams, recursively C) properly manipulating the comment (and updating existing entries for consistency).
[17:33] <tsimonq2> Does that sound good to you?
[17:38] <sarnold> Unit193: poke!
[17:38] <sarnold> (finally the best part of facebook, now ported to IRC!)
[17:44] <smoser> tsimonq2: i wont have much time to look at it, but im' happy to review
[17:46] <cjwatson> tsimonq2,smoser: Remember also that if you're iterating over .../members yourself then you're going to need to handle collection batching yourself too, following the next_collection_link URLs.
[17:47] <cjwatson> Assuming that's still your intent.
[17:48] <cjwatson> Try a decent-sized team like ~ubuntumembers as a test case.
[17:48] <tsimonq2> smoser: Thanks!
[17:49] <tsimonq2> cjwatson: I'll look into it, thanks for the pointer.