/srv/irclogs.ubuntu.com/2018/06/26/#ubuntu-devel.txt

Unit193sarnold: Poooke.03:01
=== Guest74533_ is now known as braderhart
didrocksbdmurray: 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
ubottuLaunchpad bug 1774597 in gnome-control-center (Ubuntu Bionic) "G-C-C privacy option don't allow sending manual report" [Low,Fix committed]10:35
=== giraffe is now known as Guest34814
bluesabreAny core devs interested in sponsoring this gvfs upload? https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/176259511:26
ubottuLaunchpad bug 1762595 in gvfs (Ubuntu) "Thunar incorrectly thinks USB storage device hasn't finished ejecting" [Undecided,New]11:26
bluesabreinfinity: 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/34732011:28
GunnarHjHi 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
ubottubug 1758684 in Ubuntu Translations "LP only imported a fraction of the snappy translation template" [High,In progress] https://launchpad.net/bugs/175868413:31
cpaelzerSkuggen: 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/613:51
ubottuLaunchpad bug 819535 in mysql-5.7 (Ubuntu) "mysqldumpslow looking for slow.log file on an incorrect directory" [Low,Confirmed]13:51
cpaelzerSkuggen: I wonder what the best path is to submit that, and rbasak recommended to ping you13:52
cpaelzershould I do a PR for it on github, or a report in their bugzilla (need Oracle id :-/) or ... ?13:52
mvoGunnarHj: aha, thank you! let me look at this14:26
GunnarHjmvo: 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:52
mvoGunnarHj: aha, so the problem is that this is not properly sorted? the pot?14:56
GunnarHjmvo: 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
GunnarHjhttps://launchpad.net/ubuntu/bionic/+queue?queue_state=3&queue_text=snapd_2.33.115:13
naccbluesabre: i can try and look today15:17
mvoGunnarHj: aha, I see, it looks like the i386 version is very short for some reason15:18
mvoGunnarHj: thanks again, I see that one set of files in ~40k and the other 9kb so something is wrong, I dig into it15:19
GunnarHjmvo: 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:22
mvoGunnarHj: yeah, its strange when I run this locally it seems to be fine15:23
mvoGunnarHj: I need to dig a bit harder. I also wonder if its always the same architecture that has not enough data15:24
mvoGunnarHj: or if it is random15:24
GunnarHjmvo: It's certainly random. (I thoght otherwise first.)15:25
GunnarHjmvo: So I withdraw my suggestion in comment #19 in the bug report.15:29
mvoGunnarHj: yeah, I think we need to get to the bototm of this, is it only happening on 18.04+?15:30
GunnarHjmvo: Don't know. Have only looked at 18.04, but I suppose we have reasons to fear that it's not limited to that.15:36
mvoGunnarHj: I added two snapd PRs to attack the issue #5404 and 540216:02
tsimonq2smoser: What's your UTC offset, out of curiosity?16:48
tsimonq2Because if you have the time right now, I'd like to talk about ssh-import-id.16:48
smoserah. tsimonq2 i am US/Eastern (-0400)16:52
smosersure. we can chat now.16:52
tsimonq2smoser: Ah, nice, I'm US/Central.16:53
tsimonq2smoser: So to get this straight, doesn't Launchpad 404 even when you're trying to get team SSH keys?16:55
ubottuLaunchpad bug 404 in Launchpad itself "PyGettextPO is not able to handle Unicode strings" [High,Fix released] https://launchpad.net/bugs/40416:55
tsimonq2Ah, no, I'm wrong.16:57
tsimonq2smoser: Your implementation in fetch_keys_lp LGTM. I'm just wondering about the best way to recursively do teams.16:58
mnaumannhi. would you say it is expected that gnupg2 crashes when you try to encrypt to an ecdsa key on 16.04.4?16:58
smosertsimonq2: http://paste.ubuntu.com/p/vYmCHSFXZM/16:59
tsimonq2smoser: Right.16:59
smoserthe 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-keys16:59
tsimonq2Perhaps from there we could fall back to launchpadlib.17:00
tsimonq2But, iff there's no keys fetchable via the way already implemented.17:00
tsimonq2(So existing users wouldn't have the overhead.)17:01
smoserwell, thats what i had originally suggested. that we could do that.17:01
smoserbut will your MP do recursive groups ?17:01
tsimonq2Mine 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:02
tsimonq2We 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
tsimonq2The only question would be how to correctly avoid duplicate group scans.17:03
smoserwell, one level of groups is not terribly useful, right?17:05
tsimonq2Right.17:05
smoserand yeah, duplicate group membership is kind of a pain. and my 'path' suggestion is overly simplistic in that regard17:06
smoserthe reason i was thinking that way was17:06
smosera.) 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:06
tsimonq2(Got a link for that ooc?)17:07
smoserb.) if you import a group and all you got was the group name as a marker there, it isn't that useful17:07
tsimonq2Oh, right.17:08
smoserhttps://bugs.launchpad.net/ssh-import-id/+bug/174554117:08
ubottuLaunchpad bug 1745541 in ssh-import-id "Delete SSH key on remote removal" [Wishlist,Triaged]17:08
tsimonq2For 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:10
tsimonq2For 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:11
tsimonq2This 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
tsimonq2When the scanning is done, we could take the latter variable and add the keys with the appropriate references.17:13
tsimonq2smoser: How does that sound?17:14
smoseri'd thought of that, but it will get long possibly.17:14
smoseri think your suggestion is sane.17:16
smoseri'm ok though to first blush justput the group/user name there and improve on it later17:16
smoserbut i really want to have the user name that it came from17:16
tsimonq2So 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
tsimonq2That's a good point.17:18
tsimonq2Let's some up with some comment syntax...17:18
tsimonq2Maybe something like this: # ssh-import-id lp:tsimonq2;~ubuntu-dev;~motu (this is in the case that somebody added ~ubuntu-dev)17:20
tsimonq2So, username, original username added, then what team it's pulled in as a part of...17:20
smoserthat just gets long though. i'm willing to sovle that at the po int where we attempt to do removal17:22
smoseryou dont have to bite all that off now17:22
tsimonq2I think once we add support for adding them, there should be support for removing them, right?17:23
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
smosertsimonq2: well there is no support for removing anything right now17:25
tsimonq2Yes there is. `ssh-import-id -r tsimonq2` works fine for me.17:26
smoseroh. i didnt remembre that ;)17:26
tsimonq2np :D17:27
smoserit seems reasonably defensible for '-r' to apply only to the way the user was added i think17:29
smoserie, ssh-import-id lubuntu-dev17:29
tsimonq2Right, which is why I proposed the second scheme17:29
smoseradds tsimonq, so -r lubuntu-dev would remove all of those17:29
tsimonq2It would remove all keys explicitly added by lubuntu-dev.17:30
tsimonq2However, if I add my own key, then add lubuntu-dev, but then remove lubuntu-dev, my key should stay.17:30
smoseryeah17:30
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:31
tsimonq2smoser: 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
tsimonq2Does that sound good to you?17:33
sarnoldUnit193: poke!17:38
sarnold(finally the best part of facebook, now ported to IRC!)17:38
smosertsimonq2: i wont have much time to look at it, but im' happy to review17:44
cjwatsontsimonq2,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:46
cjwatsonAssuming that's still your intent.17:47
cjwatsonTry a decent-sized team like ~ubuntumembers as a test case.17:48
tsimonq2smoser: Thanks!17:48
tsimonq2cjwatson: I'll look into it, thanks for the pointer.17:49

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!