[01:27] <sarnold> is there a process in place for doing updates to broken translations? I opened tasks for both ubuntu translations and the language-pack-de and language-pack-de-base packages: https://bugs.launchpad.net/ubuntu/+source/language-pack-de/+bug/1824724
[01:27] <ubottu> Launchpad bug 1824724 in language-pack-de-base (Ubuntu) "aa-logprof: german translation: ERROR: PromptUser: Ungültiges Tastenkürzel für V: Änderungen ansehen" [Undecided,New]
[01:27] <sarnold> the ubuntu german translators launchpad group page asked to subscribe them to a new bug .. so I've done that, but now I'm second guessing if that's how these are usually handled
[01:28] <tsimonq2> sarnold: I'd ask Gunnar but he isn't around, hmm...
[01:29] <sarnold> normally the translations Just Work so it took me a while to even figure out this much :)
[01:29] <tsimonq2> sarnold: My best guess is, get a debdiff to sponsor and I can upload.
[01:29] <sarnold> it's amazing the things that are easy to take for granted
[01:29] <tsimonq2> Translation updates are suitable for SRUs, last time I checked.
[01:29] <tsimonq2> Right heh :)
[01:30] <sarnold> on eg https://translations.launchpad.net/ubuntu/bionic/+source/apparmor/+pots/apparmor-utils/de/205/+translate there's a handy field for "new suggestion" -- it might be easier to go this route than a debdiff, which might lose the changes on the next update
[01:31] <sarnold> but if that would only ever make it into the devel release, then ..
[01:32] <tsimonq2> https://translations.launchpad.net/ubuntu/bionic/+source/apparmor/+pots/apparmor-utils says
[01:32] <tsimonq2> Owner: Adam Conrad
[01:32] <tsimonq2> infinity could know. ;)
[01:33] <sarnold> it's fun watching all his little badges load on his launchpad page
[01:34] <tsimonq2> haha :)
[01:34] <sarnold> https://launchpad.net/~disgusting-and-terrible-development
[01:34] <tsimonq2> TIL Adam likes pie. I would be curious to see which flavor is his favorite.
[01:34] <tsimonq2> :P
[01:34] <tsimonq2> sarnold: hahahaha
[01:35] <Unit193> Pumpkin, obviously.
[01:36] <tsimonq2> I really like apple.
[01:36] <tsimonq2> Pumpkin is a close second.
[01:39] <tsimonq2> Oh, and it reminds me of this, from like a decade ago: https://youtu.be/tKB4h9gvmm0?t=8s
[01:41] <sarnold> and my phone is now playing a song titled Mykola Ne Pie! coincidence? I think not!
[02:20] <sarnold> tsimonq2: ha! did you perform a gunnar summoning dance? :) https://bugs.launchpad.net/bugs/1824724
[02:20] <ubottu> Launchpad bug 1824724 in language-pack-de-base (Ubuntu) "aa-logprof: german translation: ERROR: PromptUser: Ungültiges Tastenkürzel für V: Änderungen ansehen" [Undecided,New]
[02:21] <Unit193> > 0 popcon vote, not worth a SRU hassle. \o/
[02:26] <Unit193> <Unit193> https://github.com/insanum/gcalcli/issues/440
[02:26] <Unit193> <ubot93> Issue 440 in insanum/gcalcli "quick --details [shorturl|url] broken because of Google shortener shutdown?" [Closed]
[02:36] <tsimonq2> LOL
[02:36] <tsimonq2> Nice :)
[02:41] <wxl> i bet you adam likes humble pie
[02:42] <wxl> i prefer rhubarb. and not cut with strawberry.
[02:42] <tsimonq2> Good choice.
[02:42] <wxl> a very close second is sour cream lemon
[02:44] <tsimonq2> What's the difference between sour cream lemon and regular lemon? :P
[02:44] <wxl> more sourness
[02:44] <wxl> you might sense a theme here
[02:45] <tsimonq2> Are you one of those people who drinks coffee and tea with no sugar? XD
[02:45] <wxl> DUH
[02:45] <wxl> (for a chain that serves food on par with denny's) this is surprisingly good https://sharis.com/portfolio-item/lemon-sour-cream/?lpw=12228
[02:52] <tsimonq2> wxl: Maybe you should come to LFNW and we can have some pie :D
[02:53] <tsimonq2> cjwatson: Would you object to a conversion of MoM to Git? I would assume it only needs a re-clone on prod, correct?
[02:53] <wxl> maybe.....
[07:44] <cjwatson> tsimonq2: not especially and I think it was already somewhere on my to-do list.  I'll sort it out this week
[09:09] <Laney> bdmurray: Any thoughts on ~canonical-desktop-team joining bug control? I see server and kernel already have that.
[10:12] <rbasak> Laney: sounds like a good idea. Do you know about https://wiki.ubuntu.com/UbuntuBugControl#Requirements_for_Teams ?
[10:52] <Laney> rbasak: Yeah. I was hoping to get the nod before writing an email. :P
[10:53] <rbasak> Fair enough :)
[13:11] <ddstreet> rbasak seems git-ubuntu imports still aren't fixed?  i assume it might take a while and i should switch back to good-old pull-lp-source for now...?
[13:12] <rbasak> ddstreet: I have a local not-ready-to-land fix, but have been pulled in various directions so haven't had a chance to get it polished yet.
[13:12] <rbasak> I can give you a patch if you want to import locally to get by.
[13:13] <ddstreet> nah i can just use pull-lp for now, thnx tho
[13:18] <ahasenack> rbasak: a restart doesn't fix it temporarily?
[13:21] <rbasak> ahasenack: I tried a manual import and that didn't seem to complete in any reasonable time
[13:21] <rbasak> I'm still puzzled as to what changed to make this a problem.
[13:21] <ahasenack> rbasak: is it a specific package perhaps?
[13:21] <ahasenack> or any
[13:21] <rbasak> But reducing the excessive number of API calls made seems to be the answer.
[13:21] <rbasak> I don't believe it's a specific package but I haven't tested.
[13:22] <rbasak> (I reproduced on casper, which somebody reported as broken, which wasn't in the set it was stuck on AFAIK)
[14:17] <bdmurray> Laney: its fine with me but iirc there is a process for teams joining it
[14:18] <Laney> bdmurray: right, it's documented on https://wiki.ubuntu.com/UbuntuBugControl#Requirements_for_Teams
[14:18] <Laney> can't see how it should be a problem for that team so I'll send a mail now
[14:21] <Laney> didrocks: seb128: kenvandine: any of you want to be a representative for this process? (not sure what it involves - being told off by bdmurray if team members triage bugs wrong? :>)
[14:22] <rbasak> AIUI, the representative is supposed to ensure that o ther team members (eg. newcomers) triage bugs correctly.
[14:22] <rbasak> That's how I treat it for ~canonical-server anyway.
[14:23] <bdmurray> Laney: also explaining educating other team members
[14:23] <bdmurray> explaining or educating?
[14:23] <Laney> ah right, well I suspect in practice it'll be for onboarding new team members and various people will do that
[14:23] <seb128> Laney, fine with me
[14:23] <Laney> e.g. oSoMoN is doing such for marcustomlinson atm
[14:23] <seb128> btw do we require our new members to sign the code of conduct?
[14:24] <Laney> dunno, but we'll need to to be compliant with this process :-)
[14:24] <bdmurray> I'd hope so ;-)
[14:24] <seb128> right, I was just reading it and wondering if we do so
[14:24] <seb128> is that on the new staff thing?
[14:24] <seb128> because we don't hint about that in particular in desktop afaik
[14:25] <Laney> right, also not sure that (e.g.) the DMB rigorously enforce that either
[14:25] <marcustomlinson> seb128: we should be signing the code of conduct yes
[14:26] <seb128> marcustomlinson, you mean it was part of the onboard steps you got from HR?
[14:26] <marcustomlinson> yes
[14:26] <seb128> k, good
[14:26] <seb128> thx
[14:26] <seb128> I don't even know where to check if everyone in the team signed
[14:27] <marcustomlinson> https://sites.google.com/a/canonical.com/about-canonical/home/new-starter-tasks
[14:27] <seb128> nothing obvious on https://launchpad.net/codeofconduct
[14:27] <marcustomlinson> sorry that link was not the answer to your last question
[14:27] <Laney> there's person.is_ubuntu_coc_signer on the LP API
[14:28] <didrocks> Laney: fine with giving a help when needed
[14:29] <Laney> https://paste.ubuntu.com/p/xwQCFhStFG/
[14:30]  * Laney sees a missing person in that list ;-)
[14:30] <Laney> s/crap grammar/good grammar/
[14:31] <seb128> Laney, thx for checking :)
[14:32] <marcustomlinson> Laney: https://launchpad.net/~marcustomlinson
[14:32] <marcustomlinson> I have signed
[14:33] <marcustomlinson> ah I'm not even a member of canonical-desktop-team
[14:34] <Laney> yep, that's what I pointed out
[14:34] <Laney> fixed
[14:34] <marcustomlinson> yay
[14:38] <seb128> we have quite some staff that didn't sign apparently...
[14:38] <Laney> you checked a different team?
[14:38] <seb128> ~canonical
[14:40] <seb128> but most of them probably don't do direct distro work
[14:42] <Laney> ubuntu-dev is actually all good, impressively
[14:42] <seb128> woot :)
[14:45] <Laney> bdmurray: ok, sent (I don't think I'm a member of that list so it may need to be moderated)
[14:48] <bdmurray> Laney: I'll keep an eye out
[14:49] <bdmurray> where should bug 1826196 go?
[14:49] <ubottu> bug 1826196 in ubuntu-release-upgrader (Ubuntu) "The Dock cannot scroll without a mouse when multiple programs are open " [Undecided,New] https://launchpad.net/bugs/1826196
[14:49] <Laney> gnome-shell-extension-ubuntu-dock
[15:31] <tsimonq2> cjwatson: Thanks!
=== transfusion2 is now known as transfusion
=== southey is now known as foxtrot
[17:58] <ddstreet> xnox so what's the deal with ubuntu-core-dev/systemd git repo, all the hashes are different from git-ubuntu imported repo; what's the coredev repo used for?  why not do merge proposals against the git-ubuntu repo instead?
[18:02] <xnox> ddstreet, git-ubuntu one is kind of useless. it's read only and is exact copy of the archive. one can make merge proposals against it, but nobody can actually merge or push things into it.
[18:02] <ddstreet> xnox right, but you can keep a copy of it and update your copy, then rebase or force-push once git-ubuntu repo is updated
[18:03] <xnox> ddstreet, the ubuntu-core-dev one shares history with the debian's packaging on salsa, and uses the same packaging as they do (gbp pq). And is thus used to merge with debian.
[18:03] <xnox> i find it easier to merge with debian, using the same history as they do.
[18:04] <xnox> because merges usually involve ~100 differences in debian/patches/series + changes in the rest of the debian/ tree
[18:04] <xnox> and i try to forward ubuntu delta to debian / upstream to minimize differences but we keep on growing changes due to Ubuntu decisions to do things with resolved, netplan, etc.
[18:05] <xnox> plus there are scripts for easier cherrypicking upstream commits into the ubuntu-core-dev tree
[18:05] <vorlon> yes, until git-ubuntu can handle rich history from Debian and from maintainers, it's never going to be more than read-only
[18:05] <xnox> ./debian/git-cherry-pick automates majority of "take that commit from upstream" without needing to manually twiddle with anything.
[18:06] <vorlon> (and when I say "handle", I mean "handle in a way that doesn't require a small set of developers on the ubuntu-server team to approve your merges")
[18:06] <ddstreet> xnox why can't you use normal git cherry-pick to get something from debian's repo?
[18:07] <xnox> ddstreet, i don't need anything from debian's repo. that scripts cherrypicks from upstream, and generates patch into the upstream cherrypicks patch stack of gbp-pq before debian & ubuntu sauce. and injects it in the right place in debian/patches/series
[18:08] <xnox> ddstreet, from debian i just do $ git merge
[18:08] <ddstreet> ok
[18:09] <ddstreet> welp for me, working on the git-ubuntu repo seems much easier than working on the coredev repo, so i'll keep doing that; the difficulty there is if i wanted to open a MP to the coredev repo, i'd have to rebase the patches
[18:09] <ddstreet> basically create a whole new branch just for the coredev repo, cherry-pick my changes
[18:09] <xnox> vorlon, dgit kind of does it well. the rich history is merged, and the special tags are used for bit-to-bit identical uploads to the archive. And if your rich history is not bit-to-bit identical, it is used to merge with prestine one.
[18:10] <xnox> ddstreet, i don't care about merge proposals to the coredev repo.
[18:10] <xnox> ddstreet, if and when it is out of date w.r.t. the archive i just do $ gbp import-dsc to bring it up to speed, and fix thing up if needed.
[18:11] <xnox> ddstreet, and i have been asked to like automate updating the coredev repo with import-dsc commits, such that it always matches the archive.
[18:11] <ddstreet> yeah keeping it up to date would be nice, but the hash difference still is a pain for me
[18:11] <xnox> ddstreet, what do you like about git-ubuntu tree? or is it simply the fact that you don't (want to) use git-buildpackage patch-queue tooling?
[18:11] <xnox> ddstreet, or why do feel the need to use both repos, instead of just one of them?
[18:11] <ddstreet> i use git-ubuntu for all other pkgs (that are imported) so this special-cases things
[18:12] <ddstreet> no, if you don't care about mp to the coredev repo, i have no need to use it
[18:12] <ddstreet> just wondering
[18:12] <xnox> just use git-ubuntu for systemd too.... and don't special case anything, and never look at the coredev one?!
[18:12] <ddstreet> yep that's what i'll do :)
[18:13] <ddstreet> and why i was asking what is was for ;-)
[18:14] <xnox> there is no "great" way to handle the beast. and the coredev repo is mostly best suited for uploads to devel series and merges from debian. it's usefulness drops off a lot in case of stable series & security uploads because hardly any commits are cherrypickable across the ever diverging series - cause systemd codebase is so different.
[18:14] <xnox> the inverse is true for git-ubuntu. i find it very hard to use for merges from debian, without access to full debian's packaging per-commit history.
[18:14] <xnox> to see if that's upstream crazy, debian crazy, ubuntu crazy, or reverts of one of the above....
[18:14] <xnox> etc.
[18:15] <ahasenack> it sounds reasonable to have git-ubuntu parse d/control, look for the cvs fields, and add a remote for that
[18:15] <ahasenack> er, vcs
[18:38] <nacc> https://bugs.launchpad.net/usd-importer/+bug/1673710
[18:38] <ubottu> Launchpad bug 1673710 in usd-importer "Auto add "the upstream" repo as another remote" [Wishlist,Confirmed]
[18:38] <nacc> i think
[18:38] <nacc> there's also https://bugs.launchpad.net/usd-importer/+bug/1719709
[18:38] <ubottu> Launchpad bug 1719709 in usd-importer "add/use metadata in packaging that contains upstream vcs info" [Wishlist,New]
[18:38] <nacc> its not like we didn't think about this at all :)
[18:42] <Odd_Bloke> doko: Are we expecting Python 3.8 in eoan, or will it go in to Frolicking Fawn?
[20:09] <xnox> Odd_Bloke, good question. I do want to chat with doko about his expectations for transitions this cycle.
[20:10] <xnox> we have it available, but it's neither supported, nor default yet. i wonder if it's too optiministic to have it as default, with debian being frozen at the moment.
[20:11] <Odd_Bloke> It's not vital for me to know, just curious as to how much we should be looking at 3.8 in our CI over this cycle.
[23:20] <ginggs> vorlon: are you aware of LP: #1713615 ?  users report installing the package from Debian solves the problem, should we sync next time?
[23:20] <ubottu> Launchpad bug 1713615 in msttcorefonts (Ubuntu) "ttf-mscorefonts-installer fails because Redirection from https to http is forbidden" [High,Confirmed] https://launchpad.net/bugs/1713615