[01:25] <callmepk> good morning
[01:58] <duflu> Morning callmepk 
[01:59] <callmepk> morning duflu 
[05:48] <jibel> Good morning
[05:48] <duflu> Morning jibel 
[05:49] <jibel> Hi duflu, how are you?
[05:49] <duflu> jibel, pretty average but at least not locked down. Just had lunch by the beach. How are you?
[05:55] <jibel> pretty well actually despite these boring lockdown days
[05:55] <jibel> "lunch by the beach" I dream of it
[05:55] <seb128> goood morning desktopers
[05:55] <jibel> salut seb128 
[05:55] <jibel> comment ça va ce matin?
[05:56] <seb128> lut jibel, ça va bien ! et toi ?
[05:58] <jibel> seb128, très bien mis à part les jours qui commencent à être longs
[05:59] <seb128> le déconfinement c'est pour bientôt, un peu de patience n'est-ce pas? 😬
[06:00] <jibel> je n'y crois pas trop
[06:05] <duflu> Morning seb128 
[06:05] <seb128> hey duflu , how are you today?
[06:06] <duflu> seb128, tired and now unwell but at least I got out of the house today. How are you?
[06:06] <seb128> oh :-( get some rest and get better!
[06:06] <seb128> I'm alright thanks
[07:17] <oSoMoN> good morning desktoppers
[07:18] <duflu> Morning oSoMoN 
[07:30] <oSoMoN> good afternoon duflu 
[07:56] <didrocks> good morning
[07:57] <duflu> Morning didrocks 
[07:57] <didrocks> hey duflu 
[09:02] <Laney> \o\o\o\
[09:07] <didrocks> hey Laney 
[09:20] <jamesh> hi didrocks, Laney 
[09:22] <jamesh> didrocks: fyi: I've been working on some improvements for the "github.com/snapcore/go-gettext" package, which I believe you've been using in zsys/adsys.
[09:22] <jamesh> didrocks: everything should be API compatible with what was already there, but it should let you remove some code for configuring locales
[09:23] <cpaelzer> didrocks: seb128: have you seen that https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1802533 looks sort of ready now?
[09:24] <cpaelzer> this was coming up so long ago that it was not yet MIR-checked very formally, it seems in https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1802533/comments/6 that it was going directly to seucrity
[09:24] <cpaelzer> but IIUC desktop wants this, so maybe didrocks can give it a re-look (btw it still misses a bug subscriber) and if ok it seems ready for promotion
[09:26] <Laney> hey didrocks jamesh 
[09:29] <didrocks> jamesh: ah excellent! Indeed, I’m using it, maybe you can steal some part of adsys if that makes sense as well (everything I wrapped around should be covered by tests)
[09:30] <didrocks> cpaelzer: happy to give a relook if we want it, seb128 would know better than I on that front anyway, let’s see
[09:30] <jamesh> didrocks: the main improvement is a UserLocale() method that will pick a locale based on the environment, rather than you having to consult LANGUAGE/LC_ALL/LC_MESSAGES/LANG yourself
[09:31] <jamesh> didrocks: it should also do a lot less work on startup (the old implementation was doing a lot of seeks and reads, while the new version just memory maps the catalog)
[09:36] <didrocks> jamesh: nice! Can’t wait to use it now :)
[09:37] <didrocks> jamesh: I wonder if we should include there the go:generate functions to create the pot, refresh po and output mos
[09:39] <jamesh> didrocks: I'm looking at copying over the xgettext-go tool from the snapd tree.  This is basically an xgettext workalike that understands Go syntax
[09:39] <didrocks> jamesh: I’m using the msgfmt and other things wrapping
[09:39] <jamesh> hadn't really thought about more complex scripts
[09:40] <didrocks> I wasn’t satisfied with xgettext-go, but don’t remember the details
[09:40] <jamesh> didrocks: the xgettext-go script was mostly there because xgettext doesn't understand Go's backtick raw strings
[09:40] <didrocks> jamesh: https://github.com/ubuntu/adsys/blob/main/internal/i18n/generate-locales.go for reference
[09:40] <didrocks> yeah
[09:40] <jamesh> if you've got a combination of Go and other sources, you probably need to use both
[09:40] <luna_> morning
[09:40] <didrocks> indeed
[09:41] <luna_> the wesnoth package in the Hippo is broken, where do i report?
[09:41] <didrocks> hey Laney 
[09:41] <jamesh> didrocks: this is what snapd is using: https://github.com/snapcore/snapd/blob/master/update-pot
[09:41] <didrocks> ah, it slightly changed
[09:42] <luna_> works to install via steam but not apt 
[09:42] <jamesh> didrocks: is the msgmerge on po files as part of your update-po action desirable?  I seem to remember translators hating that for merge conflicts
[09:43] <luna_> https://paste.ubuntu.com/p/rR4qm8pVHw/
[09:43] <luna_> and steam has v1.14.14
[09:43] <didrocks> jamesh: yeah, it’s the part I wasn’t sure about, but didn’t receive any complain (yet :p)
[09:45] <luna_> or is it better to report this upstream to the people who package Wesnoth for Ubuntu?
[09:45] <didrocks> jamesh: oh, and are you going to check in locale-langpack/ (which is a distro-patch normally in ubuntu) as well?
[09:46] <didrocks> jamesh: basically to remove the need for https://github.com/ubuntu/adsys/blob/main/internal/i18n/i18n.go#L58
[09:46] <jamesh> didrocks: I remember it was the default behaviour for gettext's default po/Makefile script, and got disabled.  It basically meant non-translators were constantly changing the catalogs behind their backs.
[09:48] <didrocks> jamesh: ack, if you come with a generator which can indepently regenerate pot and po files, and with an arg, create mo files (so that we don’t create them on CI), I’m happy to switch to it
[09:48] <jamesh> didrocks: including something like that probably makes sense.  You could probably remove the for loop in your version, fwiw
[09:48] <jamesh> just look up the catalog for the locale string presented to you
[09:49] <didrocks> sounds good, keep me posted once the changes are in and I’ll try it
[09:50] <luna_> https://github.com/wesnoth/wesnoth/issues/5291
[09:50] <gitbot> wesnoth issue 5291 in wesnoth "wesnoth package broken in Ubuntu 21.04 (Alpha)" [Open]
[09:50] <jamesh> didrocks: go-gettext now automatically looks for locale fallbacks (i.e. if you ask for fr_FR it will consult an fr_FR catalog catalog followed by fr for any missing strings)
[09:52] <didrocks> ah nice, less code needed for this, then. (and removing some tests along the way :)) Just need to ensure we have the langpack fallback
[09:53] <jamesh> I'll make sure we add it.  Thanks for the suggestion
[09:54] <didrocks> yw! Thanks for you work there
[09:55] <jamesh> didrocks: one other long term plan is to try and get some Github actions set up to automate getting translations in and out of Launchpad.  I don't suppose you've done anything there that I can steal? :-)
[09:56] <jamesh> for getting things out of Launchpad, the plan was to set up a bare Bazaar branch, and configure Launchpad to export translations there.
[09:57] <jamesh> Then have a scheduled GH Actions workflow that would check out the Bazaar branch and copy the translations into git, possibly presenting it as a pull request
[09:57] <didrocks> jamesh: no, I only autogenerate pot and refresh po files when any new translations is added/removed/modified, but nothing linked to launchpad (which is a good idea): https://github.com/ubuntu/adsys/blob/main/.github/workflows/auto-updates.yaml#L11
[09:57] <didrocks> so, once anything is pushed to main, this checks is running
[09:58] <didrocks> and if any changes to po files is needed (apart from date changes) -> PR is automatically created and branch pushed (for tracking, with associated tag)
[09:58] <didrocks> but scheduled GH Actions workflow to do the same with input from LP is a great idea
[09:59] <didrocks> wondering about credentials though
[09:59] <jamesh> I was thinking an ssh private key for a bot account as a secret
[10:00] <didrocks> yeah, no really other way around
[10:00] <jamesh> I don't think there's any need for Launchpad API access
[10:00] <didrocks> depends, if we can push the "upstream" new pot file automatically as well, this will be great
[10:00] <didrocks> (and will void the need for msmerge)
[10:01] <didrocks> but basically, you merge something which has i18n strings changes -> refresh pot file -> push to launchpad
[10:01] <jamesh> for pushing pots, my idea was to have a branch owned by the bot account, and set that as the default branch for the project's trunk series
[10:01] <didrocks> and another Action, as you told, which regularly pull from launchpad
[10:01] <jamesh> have another workflow generate the PO template and commit it to that Bazaar branch if anything has changed
[10:01] <didrocks> ah, using really bzr as a proxy
[10:02] <didrocks> sounds good, happy to give some help if you need it
[10:02] <jamesh> Bazaar import seems to be the only way to do automated template upload at present.
[10:02] <didrocks> ok, I don’t remember the LP API by heart, but trusting you :)
[10:03] <jamesh> relying on a Bazaar import of the git repo could work, but LP's vcs-import found a revision it didn't like in 2018
[10:03] <jamesh> for snapd, that is
[10:03] <didrocks> and this blocks the whole import?
[10:05] <jamesh> Maybe deleting the whole branch might help, but https://code.launchpad.net/~snappy-dev/snapd/master definitely seems stuck
[10:06] <jamesh> It seems to disagree about what the SHA of a commit is, so bails
[10:07] <didrocks> yeah, I would delete it if possible and try an new import
[10:08] <jamesh> I remember that code being a bit hairy back when it was only doing CVS and SVN.
[10:10] <didrocks> I’m more than eager to believe the import LP code being hairy, having to deal with different CVS… converting to Bzr :)
[10:10] <jamesh> looking at that backtrace again, it looks to be using bzr-git, which is a fair bit newer than the cscvs codebase
[12:19] <cpaelzer> Hi Desktop people o/ - given the high number of long-duration-often-manually-retried that https://autopkgtest.ubuntu.com/packages/libr/libreoffice/hirsute/arm64 and https://autopkgtest.ubuntu.com/packages/libr/libreoffice/hirsute/armhf are causing I wondered if that could be improved
[12:19] <cpaelzer> Laney: correctly suggested that I should ask here
[12:19] <cpaelzer> it feels that this must have been discussed before - is there a bug for it already that I should comment/subscribe to?
[12:21] <Laney> cpaelzer: I know it's been discussed a few times and is basically known, but not sure if there's a bug, hellsworth can probably tell you later unless someone does some LP archaeology for you in the meantime
[12:21] <Laney> if there isn't one, filing one would be welcome, agreed that should be worked on
[12:21] <cpaelzer> ok
[12:22] <Laney> e.g. skipping some tests on arm* to get them to be more stable would probably be better than having flakes like this
[12:22] <cpaelzer> I can easily file one and if another one exists "mark as duplicate" is easy enough
[12:22] <Laney> sure
[12:23] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1785262
[12:25] <Laney> neat
[12:25] <KGB-2> glib pristine-tar 980e60d Simon McVittie glib2.0_2.66.3.orig.tar.xz.delta glib2.0_2.66.3.orig.tar.xz.id * pristine-tar data for glib2.0_2.66.3.orig.tar.xz * https://deb.li/VzxI
[12:25] <KGB-2> glib upstream/latest 32c9765 Simon McVittie * pushed 13 commits * https://deb.li/3NneA
[12:25] <KGB-2> glib tags 3045883 Simon McVittie upstream/2.66.3 * Upstream version 2.66.3 * https://deb.li/R6gR
[12:31] <Laney> there, added a comment
[12:32]  * Laney beat cpaelzer by microseconds :-)
[12:32] <cpaelzer> Laney: heh - me as well
[12:32] <cpaelzer> now let us check which one is better :-P
[12:32] <cpaelzer> fairly equal - glad that we didn't contradict :-)
[12:33] <Laney> nice script!
[12:33] <cpaelzer> not product level for sure, but helpful - the repo exists for re-use so if you like it feel free
[12:34] <Laney> except it says no failures for armhf? http://autopkgtest.ubuntu.com/packages/libreoffice/hirsute/armhf
[12:34] <cpaelzer> bugs :-)
[12:34] <Laney> :>
[12:45] <seb128> I know how that one is going to end :p
[12:45] <seb128> (we discussed that a few times, including in team meetings)
[12:45] <seb128> but basically there is agreement that removing the flackyness would be nice, just not resources to work on that, if anyone would want to contribute a patch that would probably help
[12:47] <Laney> what are you saying, you're going to veto accepting the nomination?
[12:48] <seb128> no, I don't think I've veto power
[12:48] <Laney> In the bug there I suggested skipping those tests, and provided a link to a commit where we did that in the past, so hopefully doing that wouldn't fail because of resources
[12:48] <Laney> fixing them properly does seem unlikely
[12:50] <Laney> but hopefully reducing the coverage and getting stable green tests is easy/pragmatic enough
[12:50] <Laney> !
[12:50] <seb128> let's see :)
[15:19] <seb128> jibel, hey, do you think you could add reviewing of https://code.launchpad.net/~mfo/ubiquity/+git/ubiquity/+merge/390637 in your backlog? sustaining engineering asked if we could help there
[15:22] <seb128> they also asked about https://code.launchpad.net/~mfo/ubiquity/+git/ubiquity/+merge/391767 but I'm trying to make us and foundations review one each
[15:22] <seb128> they are not really complicated and from the comments they seem to have done testing
[15:26] <hellsworth> good morning desktopers
[15:26] <jibel> seb128, sure, I'll have a look.
[15:27] <seb128> jibel, thanks!
[15:27] <seb128> hey Heather, how are you?
[15:28] <oSoMoN> good morning hellsworth 
[15:28] <seb128> jibel, do you want a trello card about it as a reminder or is that not needed?
[15:28] <hellsworth> hi guys i'm good. tired but good :)
[15:29] <jibel> seb128, you can add a card to remind me to do it but I've it in my list of MPs to review
[15:30] <jibel> Good morning hellsworth 
[15:30] <hellsworth> hi jibel 
[15:32] <jibel> seb128, although I'm wondering why they need another debconf variable to run this page while they could preseed the conf varialbe to install 3rd party drivers if it's the sole purpose. Anyway I'll see with mfo
[15:34] <seb128> jibel, thanks, and card done in https://trello.com/c/foK9wisV/227-review-ubiquity-changes-from-sustaining-engineering
[18:01] <KGB-2> gnome-control-center ubuntu/master Marco Trevisan * [close] merge request !18: account-fingerprint: Don't make flowbox children selectable * https://deb.li/3Gjuh
[18:55] <seb128> xnox, thanks for the reviews! I tried to setup/tear mounts but that wasn't working great, I don't remember the details, maybe needs more refactoring that the simple patch proposed. I will try again
[18:55] <seb128> also good tip for the snap handling
[18:55] <seb128> xnox, could you also review https://code.launchpad.net/~seb128/debian-cd/layerfs-canary-option/+merge/394137 ? that's one thing that you broke previous cycle with a refactoring :-)
[20:44] <xnox> seb128:  not broken, but somewhat intentially removed. I did ping people at the time, canary images were off, and no owner either =(
[20:45] <seb128> xnox, the ISO fails to start ubiquity without that option so arguably broken
[20:46] <xnox> seb128:  there is no way to detect if that should be specified, and what it should point at, right?
[20:46] <xnox> seb128:  oh, yeah, it totally would fail without it =)
[20:46] <seb128> no way that I know, but I'm still new and wrapping my head around that multilayer ISO thing
[20:46] <xnox> somewhat would want to just set the "layeredopt" and then have it as $layeredopt
[20:47] <xnox> then again there are so many copy pastes of the boot options for each project, it's not funny.
[20:47] <seb128> what's wrong with my patch meanwhile?
[20:47] <xnox> the patch is fine.
[20:47] <seb128> ah, good :-)
[20:47] <xnox> seb128:  however, i'm not ~ubuntu-cdimage =(
[20:47] <xnox> seb128:  only like you? laney? vorlon? etc. can merge it.
[20:48] <seb128> it's annoying how coredev doesn't have access to some of the things that are building block for Ubuntu
[20:49] <seb128> I'm not in that team either, I will try to get Laney to merge it tomorrow
[20:53] <xnox> seb128:  oh, i thought you said you were. nevermind.
[20:54] <seb128> I'm not in that team either, I will try to get Laney to merge it tomorrow
[20:54] <seb128> ups, sorry, wrong focus and key combo