=== jamesh_ is now known as jamesh
[00:59] <callmepk> good morning
[02:28] <pieq> hey callmepk !
[03:12] <duflu> Hi callmepk and pieq 
[03:13] <luna_> hey
[03:21] <duflu> Hi luna_ 
[03:26] <pieq> hi duflu and luna_ :)
[04:25] <jibel> Good morning all
[04:36] <Maik> good morning everyone
[04:49] <duflu> Morning jibel, Maik 
[04:52] <jibel> Hi duflu 
[05:02] <Maik> hey duflu
[05:55] <oSoMoN> good morning desktoppers
[05:57] <Maik> good morning oSoMoN
[06:06] <jibel> Salut oSoMoN 
[06:10] <oSoMoN> hey Maik, salut jibel 
[06:24] <didrocks> good morning
[06:24] <Maik> hi didrocks
[06:25] <didrocks> hey Maik 
[06:30] <oSoMoN> salut didrocks 
[06:35] <didrocks> hey oSoMoN 
[06:56] <marcustomlinson> morning all
[06:57] <duflu> Morning oSoMoN, marcustomlinson 
[06:57] <duflu> Morning didrocks 
[07:01] <ricotz> good morning desktopers
[07:07] <duflu> Hi ricotz 
[07:11] <didrocks> hey duflu, marcustomlinson 
[07:25] <jibel> Hello didrocks and marcustomlinson 
[07:25] <jibel> how is life today?
[07:27] <seb128> goood morning desktopers
[07:32] <jibel> salut seb128 
[07:32] <seb128> lut jibel , comment ça va aujourd'hui ?
[07:35] <jibel> seb128, ça va bien et toi?
[07:40] <seb128> ça va bien!
[07:42] <didrocks> salut jibel, seb128 
[07:43] <didrocks> ça peut aller, mal de crâne, par contre
[07:43] <duflu> Hi seb128 
[07:45] <oSoMoN> good morning marcustomlinson, duflu, ricotz, seb128 
[07:46] <marcustomlinson> jibel: sorry missed that. good thanks :) and you?
[07:48] <seb128> lut didrocks , oSoMoN 
[07:48] <seb128> hey marcustomlinson , duflu 
[07:48] <seb128> didrocks, outch, manque de sommeil?
[07:49] <didrocks> seb128: ouais, nuit difficile
[07:49] <seb128> :-(
[07:50] <seb128> bon courage alors
[07:51] <didrocks> merci !
[08:02] <oSoMoN> Trevinho, hey, when you're around could you please create a groovy branch at https://code.launchpad.net/~unity7maintainers/ubuntu-seeds ?
[08:04] <Laney> yo
[08:05] <oSoMoN> yo Laney 
[08:05] <oSoMoN> handsome_feng, hey, would you mind reviewing https://github.com/ukui/ukui-desktop-environment/pull/26 ?
[08:07] <oSoMoN> handsome_feng, and https://code.launchpad.net/~osomon/ubuntu-seeds/+git/ubuntukylin/+merge/390843, too
[08:25] <oSoMoN> seb128, I submitted https://salsa.debian.org/debian/gedit-latex-plugin/-/merge_requests/1 but got no feedback from the Debian maintainer yet, should I go ahead and prepare an ubuntu debdiff to help gvfs migrate until Debian takes it?
[08:25] <oSoMoN> note that the gedit latex plugin appears to be broken anyway, but that's a separate (and older) problem: bug #1875820
[08:25] <ubot5> bug 1875820 in gedit-latex-plugin (Ubuntu) "LaTeX Plugin not working" [Undecided,Confirmed] https://launchpad.net/bugs/1875820
[08:27] <jibel> an easy one to review. Removal of popcon from the installer https://code.launchpad.net/~jibel/ubiquity/+git/ubiquity-1/+merge/390882
[08:27] <jibel> anyone?
[08:33] <seb128> oSoMoN, yes
[08:33] <seb128> oSoMoN, well, if it's not working we could as well remote it...
[08:35] <seb128> oSoMoN, unless we want to also apply the commits mentioned at the end of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955812
[08:35] <ubot5> Debian bug 955812 in gedit-latex-plugin "gedit-latex-plugin does not work anymore" [Important,Open]
[08:40] <oSoMoN> seb128, the traceback I'm seeing when trying to activate the plugin in a fully up-to-date groovy VM is a different one that wouldn't be addressed by those commits, I think
[08:40] <oSoMoN> so it looks like the plugin needs more work
[08:42] <jibel> xnox, I didn't follow how the live image changed. The iso validation tests have been failing for a while because there is no /EFI/BOOT/* on the ISO. I suppose it's expected. Can I safely remove this check and should I replace it with another one?
[08:46] <seb128> oSoMoN, https://gitlab.gnome.org/GNOME/gedit-latex/-/commit/2b4cbb44 ?
[08:46] <Laney> moin oSoMoN jibel and seb128 
[08:46] <jibel> Good morning Laney 
[08:46] <Laney> that thing could equally be NMUed + synced or removed I'd say
[08:46] <seb128> oSoMoN, anyway I don't think we should waste efforts on an universe plugin
[08:47] <seb128> you have probably higher importance work on your plates
[08:47] <seb128> hey Laney , how are you?
[08:48] <seb128> shrug
[08:48] <seb128> 'tracker search' is broken on Ubuntu and we never noticed
[08:48] <seb128> another -Bsymbolic-functions victim
[08:49] <oSoMoN> seb128, I agree, let's remove it?
[08:49] <oSoMoN> (not tracker, gedit-latex-plugin ;))
[08:49] <seb128> oSoMoN, k, it can come back by autosync if/when Debian fixes it
[08:50] <oSoMoN> yes
[08:50] <seb128> oSoMoN, removed
[08:50] <oSoMoN> thanks
[08:50] <seb128> np!
[08:52] <Laney> hey seb128, yeah I'm OK, did some soldering last night, trying to learn new skills!
[08:52] <Laney> you?
[08:53] <Laney> good find on tracker, sounds like that would be a nice autopkgtest
[08:53] <seb128> right
[08:54] <seb128> Laney, electronic? did you try to fix something?
[08:54] <Laney> nah, I got this kit to make a GPS clock that comes with all the parts but you have to put them together
[08:54] <xnox> jibel:  would it be possible to mark it as xfail or some such? mwhudson and vorlon have been working on ressurecting that.
[08:57] <jibel> xnox, yes, I can do that
[08:58] <jibel> xnox, is it the discussion in bug 1895131 ?
[08:58] <ubot5> bug 1895131 in casper (Ubuntu) "Groovy Desktop *BREAKS* the most common method of creating UEFI bootable drives for Ubuntu installation" [Undecided,Confirmed] https://launchpad.net/bugs/1895131
[08:59] <jibel> how do I type a superscript letter on a French keyboard?
[09:01] <jibel> other than copy-pasting from a unicode table
[09:06] <seb128> jibel, ctrl-shit-U <unicode number>?
[09:07] <seb128> ctrl-shit-U 00B3 ³
[09:07] <seb128> if that's what you are asking?
[09:08] <jibel> yeah, I was looking for something more user friendly, I don't know the code for every letter
[09:09] <oSoMoN> you could define compose key shortcuts, but I suppose you were looking for something that works OOTB
[09:10] <xnox> Is Windwos+L supposed to lock Ubuntu Desktop? I'm sure it used to..... but not anymore?
[09:10] <jibel> like in libreoffice
[09:11] <jibel> which I did in the end open LO, type what I want, copy/paste in TB
[09:11] <jibel> Win+L still locks the desktop here. All updates aplied
[09:11] <jibel> +p
[09:16] <seb128> jibel, if you don't know the symbols then using gnome-characters to browse?
[09:17] <seb128> you can even search there, e.g ctrl-F and type 'fraction' is that's a fraction symbol you are after
[09:19] <jibel> that's what I tried at first. But if I type 'superscript' there are no letters, and if I type the letter I want, there is no superscript
[09:20] <jibel> LO for the win :)
[09:25] <seb128> jibel, weird, it works for me, https://people.canonical.com/~seb128/characters.png
[09:26] <seb128> jibel, but it finds them also on the real name (well I don't know about superscripts just glanced to https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts)
[09:26] <seb128> e.g U+00B9 ¹ SUPERSCRIPT ONE, U+2044 ⁄ FRACTION SLASH, U+2082 ₂ SUBSCRIPT TWO 
[09:26] <jibel> righ,t but there are no letters there
[09:26] <seb128> if you search for 'fraction slash' it finds it
[09:26] <seb128> what letter are you after?
[09:27] <jibel> e
[09:27] <jibel> something like 1er, 2eme, .., but superscript
[09:28] <jibel> superscript e gives me 8 and = in g-characters
[09:30] <seb128> ᵉʳ
[09:30] <seb128> k, learning every day :-)
[09:30] <seb128> jibel, but yeah, gucharmap does the same, it find eight and equal
[09:30] <seb128> but no 'e'
[09:32] <jibel> anti french writers conspiracy :P
[09:32] <seb128> jibel, it's caleed U+1D49 MODIFIER LETTER SMALL E
[09:32] <seb128> so you can filter on modifier letter
[09:33] <jibel> I'll write everything in LO now, the only editor that understands me
[09:33] <seb128> :-)
[09:33] <jibel> echo "export EDITOR=lowriter" >> ~/.bashrc
[09:34] <jibel> seb128, thanks for searching 
[09:34] <seb128> np!
[09:34] <seb128> it was fun to learn what superscripts are :)
[09:37] <oSoMoN> if you start seeing superscript letters all over the place in commit messages, don't ask…
[09:37] <jibel> paride, I'll skip the 2 UEFI tests in iso validation for both server and desktop in utah until it's resolved.
[09:38] <paride> jibel, you mean, bypass them in the code?
[09:38] <jibel> You should be worried I working on Utah tests and talking about superscript >:)
[09:38] <jibel> paride, changing skipunless() to skip() in the testsuite
[09:39] <jibel> in iso_static_validation.py more precisely
[09:40] <paride> I hope that doesn't require superscripts :P 
[09:40] <paride> jibel, anyway OK
[09:40] <jibel> paride, its broken right now because there is no EFI/BOOT
[09:40] <paride> yes, I kind of have a fix in mind
[09:40] <paride> but maybe there's smarter way
[09:40] <jibel> it requires cap letters, not sure it's available on a french keyboard
[09:40] <paride> lol
[09:41] <jibel> paride, vorlon and mwh are working on resurrecting that, so skip() until they come to a conclusion seemed reasonable.
[09:42] <paride> mmh this doesn't match my understanding of the problem
[09:42] <paride> jibel, is there a bug/MP?
[09:43] <jibel> I don't have any
[09:43] <jibel> I think it's related to bug 1895131
[09:43] <ubot5> bug 1895131 in casper (Ubuntu) "Groovy Desktop *BREAKS* the most common method of creating UEFI bootable drives for Ubuntu installation" [Undecided,Confirmed] https://launchpad.net/bugs/1895131
[09:43] <paride> let's see
[09:50] <paride> jibel, yes that's it, but it's not clear if and how it's going to be fixed
[09:51] <paride> I was thinking to make utah check the files in the actual ESP partition instead of checking the copies of the EFI files that are/were present in the main iso9660 filesystem
[09:53] <paride> but well, if we *want* to provide those copies for convenience they they should be validated too
[09:55] <jibel> right, we could do both
[09:56] <Trevinho> marcustomlinson: hey, any news on gnome-terminal 3.38?
[09:57] <paride> jibel, I'll comment to the bug
[09:58] <Laney> Trevinho: did you see oSoMoN's message about the unity seeds?
[09:58] <Laney> & hi :>
[09:58] <Trevinho> :)
[09:58] <oSoMoN> hi Trevinho :)
[09:59] <Trevinho> I saw it now, highmon wasn't efficient
[10:05] <Trevinho> oSoMoN: any change needed for the seed, or can I leave it to you?
[10:10] <paride> jibel, btw venonat went ENOSPC again a few days ago, I did a cleanup and reboot
[10:11] <marcustomlinson> Trevinho: was gonna use my Friday to do that. why?
[10:11] <marcustomlinson> no update sorry
[10:12] <Trevinho> marcustomlinson: ok, just to know if you were still planning that or we could start some work on it
[10:12] <Trevinho> oSoMoN: I've made it at https://code.launchpad.net/~unity7maintainers/ubuntu-seeds/ubuntu-unity.groovy feel free to hack it if needed, let me know if you need approvals
[10:14] <oSoMoN> Trevinho, thanks, I'm going to submit a MR against that branch shortly, I'll need your review/approval
[10:15] <Trevinho> oSoMoN: ok ping me when needed
[10:17] <oSoMoN> Trevinho, there: https://code.launchpad.net/~osomon/ubuntu-seeds/ubuntu-unity.groovy/+merge/390894
[10:17] <jibel> paride, okay, I restarted the upgrade slaves.
[10:17] <paride> jibel, commented to https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1895131 
[10:17] <ubot5> Ubuntu bug 1895131 in casper (Ubuntu) "Groovy Desktop *BREAKS* the most common method of creating UEFI bootable drives for Ubuntu installation" [Undecided,Confirmed]
[10:17] <paride> I hope it makes fully sense for Desktop too
[10:19] <Trevinho> oSoMoN: done
[10:20] <oSoMoN> Trevinho, thanks! now we'll need a MOTU to update ubuntu-unity-meta
[10:30] <Laney> I'll do that
[10:32] <Laney> let's see how much stuff it has picked up since eoan
[10:35] <Laney> yikes
[10:35] <Laney> need to drop i386
[10:36] <jibel> paride, it makes sense. I'll push the 'skip'
[10:36] <paride> ty
[10:40] <jibel> paride, well, I'll skip only for groovy and we can revisit the decision for H
[10:40] <paride> jibel, I agree
[10:48] <ricotz> marcustomlinson, hey, heather wanted to provide you with a libreoffice 7.0.1 package to sponsor, the ppa build passed the autopkgtests already?
[10:51] <marcustomlinson> ricotz: I don't recall running those for her. let me look through her millions of ppas for the right one ;P
[10:51] <ricotz> marcustomlinson, it would have been a run against the libreoffice prereleases ppa
[10:53] <oSoMoN> Laney, thanks!
[10:53] <ricotz> marcustomlinson, given the release schedule, it might make sense to pick up 7.0.2~rc1 building in prereleases now, which also meant to improve the integration of the yaru icon style for ubuntu sessions
[10:54] <ricotz> libreoffice 7.0.2 final will be out after the beta freeze, so it would a minor update if rc1 goes in now
[10:54] <ricotz> marcustomlinson, https://wiki.documentfoundation.org/ReleasePlan/7.0#7.0.2_release
[10:54] <marcustomlinson> ricotz: either way I need to get a thumbs up from heather on manual testing, I'll ping her later
[10:55] <ricotz> marcustomlinson, ok, the delay with 7.0.1 is unfortunate :(
[10:55] <ricotz> (which made it possible to pick up 7.0.2~rc1)
[11:00] <marcustomlinson> ricotz: I myself wouldn't usually bother with the rc's unless it was for a major release to weed out any big update issues
[11:01] <marcustomlinson> ricotz: but I ack your point
[11:06] <ricotz> marcustomlinson, basically the weeding out is happening upstream after the big 7.x release ;)
[11:06] <ricotz> marcustomlinson, was there an autopkgtest run against https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-prereleases/+sourcepub/11572068/+listing-archive-extra
[11:10] <paride> jibel, mp approved
[11:19] <Laney> seb128: did you notice the geary failure?
[11:20] <seb128> Laney, yes, it built in Debian though and I'm a bit puzzled at what component update in groovy is creating those errors
[11:20] <seb128> any clue?
[11:20] <seb128> also it failed on debian/s390x in a similar fashion, to add to the weirdness
[11:21] <Laney> I dunno, didn't look, just wanted to point you to it as syncs don't create ftbfs emails
[11:21] <Laney> not supposed to look at this stuff on +1 :D
[11:21] <seb128> ../test/client/util/util-cache-test.vala:22.9-22.19: error: The type name `Lru' could not be found
[11:21] <seb128> ricotz, ^ any idea about what that could be due to?
[11:23] <seb128> oh, it didn't fail that way on the ubuntu builders, let's wait for -3 to be available and sync that
[11:23] <seb128> though I get that error ^ in a local build
[11:24] <seb128> https://buildd.debian.org/status/fetch.php?pkg=geary&arch=s390x&ver=3.38.0.1-3&stamp=1600333022&raw=0
[11:24]  * ricotz is looking
[11:26] <ricotz> seb128, might be an insufficient build dependency check?
[11:30] <seb128> ricotz, I guess it could, but unsure what it could be
[11:30] <ricotz> eyes on 0.55.3-1
[11:30] <seb128> also what is Lru ?
[11:30] <seb128> ah, meson
[11:31] <ricotz> seb128, it is a class in src/client/util/util-cache.vala:public class Util.Cache.Lru<T> : Geary.BaseObject {
[11:31] <ricotz> I mean, I suspect meson
[11:34] <seb128> ricotz, thanks, still weird, it's failing a groovy chroot but not on the buildds, also failing that way only on s390x in Debian
[11:35] <ricotz> weird indeed
[11:40] <Laney> The specific failure in groovy is just the thing fixed in -2 afaics, but no idea about the Lru thing :(
[11:41] <seb128> Laney, on a local chroot on amd64 I get the lru thing
[11:41] <seb128> go wonder
[11:41] <Laney> for unstable?
[11:42] <seb128> groovy
[11:42] <Laney> wfm
[11:42] <Laney> W E I R D
[11:42] <seb128> indeed
[12:12] <slyon> hmm... My netplan/arm64 test failed again :-/ ... The test creates a /netplan-dummy.service file, reboots, and moves it to /run/systemd/system/ after reboot. This file is missing after reboot (or not created at all?) on arm64, while it works on the other architectures... The other file created during the same test (/etc/systemd/system/cloud-init-dummy.service) works just fine on all architectures.
[12:13] <slyon> Does anybody have an idea what could cause this file to be missing/deleted on the arm64 autopkgtest runner?
[12:15] <seb128> slyon, try asking on #ubuntu-devel rather, the issue isn't really a desktop one, you might have more people knowing about that on the other channel
[12:16] <slyon> oops, wrong channel, sorry
[12:16] <seb128> no worry
[12:25] <jibel> paride, sorry for the spam
[12:26] <jibel> trying to get this static validation test right
[12:35] <ricotz> seb128, jfyi, I would expect such an error with vala 0.48.x if the source relies on a 0.50.0 feature, but this would result an error on every arch
[12:36] <seb128> ricotz, right
[12:43] <jibel> paride, finally got the correct list of files for groovy. There are 2 tests failing for live-server but they should fix themselves once the images are in sync.
[12:44] <jibel> I(ll push the change. Not one I'm happy with, I special cased focal, but that'll do.
[12:45] <paride> jibel, I'll trigger a live-server download, let's see if it passes
[12:46] <jibel> paride, it should the 2 failures are the timestamp and the checksum
[12:46] <paride> jibel, it passed with the latest image
[12:46] <paride> jibel, thanks for this! 
[12:47] <jibel> paride, FYI everything's in git, I didn't do a release from the debs.
[12:48] <paride> jibel, so it's in git + applied locally on venonat?
[12:48] <jibel> paride, yes
[12:49] <paride> ok, we can switch to the .debs after the next daily build
[12:54] <jibel> ohoh 
[12:54] <jibel> Yay Jenkins build is back to normal : ubuntu-groovy-desktop-amd64-smoke-default #41
[12:54] <jibel> finally
[13:20] <seb128> Trevinho, is that pipewire update/ppa needed? did you check with Ken if updating the portals to 1.7 was something we want this cycle?
[13:21] <GunnarHj> Good afternoon!
[13:21] <GunnarHj> The fonts on the login screen and the top bar are strikingly small for me in groovy. Is that an intentional change?
[13:21] <Trevinho> seb128: well, it is not *stricly* needed, but given that it was helping moving on for next cycle we said with Laney to do this
[13:22] <Trevinho> seb128: but no... Do we have breakage by that?
[13:22] <seb128> Trevinho, I don't know, it's rather to know what portal series are supported as stable ones, also need to make sure it doesn't create issues for desktop snaps
[13:23] <Trevinho> seb128: in theory mutter could just go in without any pipewire build-dep in ubuntu, but...
[13:24] <seb128> Trevinho, just ask Ken before landing new portals and make sure it doesn't create issues for snaps
[13:24] <Trevinho> seb128: from what I see 1.7.0 is just about supporting mutter screencasting and few small things https://github.com/flatpak/xdg-desktop-portal-gtk/blob/master/NEWS
[13:24] <Trevinho> we won't use that mutter thingy this cycle, but I assume we will next one
[13:24] <Trevinho> so to make things easier...
[13:25] <seb128> I'm not saying we shouldn't update, just asking that we check with the corresponding stakeholders before landing a new serie
[13:27] <Trevinho> seb128: sure
[13:27] <seb128> thx
[13:27] <Trevinho> will do
[13:32] <Trevinho> seb128: when you've time maybe you can handle harfbuzz? From what I see the ubuntu one is just about rebuilds so we can probably just sync from debian?
[13:33] <Trevinho> also is gst-plugins-good1.0 under our umbrella? as it seems the only thing in gstreamer that isn't in sync
[13:34] <seb128> Trevinho, good/bad needs merging, LocustusofBorg is supposed to do those...
[13:34] <seb128> Trevinho, harfbuzz you can sync if you want I guess yes
[13:35]  * Trevinho missess powers
[13:35] <seb128> do we need it for anything?
[13:35] <seb128> I'm unsure how to properly test that component...
[13:35] <Trevinho> well pango uses it, not a requirement, but..
[13:35] <Trevinho> if you get good text we're good :)
[13:36] <seb128> expect it's rather useful for non latin glyphs
[13:36] <seb128> which I've no clue about
[13:36] <Trevinho> seb128: mostly fixes https://github.com/harfbuzz/harfbuzz/blob/master/NEWS#L50
[13:43] <Trevinho> seb128: in the portals it seems there are only API additions though (https://github.com/flatpak/xdg-desktop-portal/compare/1.6.0...1.8.0#diff-4cabe9d9ee00aececc8de6a19ddc03e0) but those are just "vardict" options so something that can be passed to the DBus API as optional argument, so snaps should be fine with that
[13:44] <Trevinho> not sure also what `better support for snap and toolbox` means
[13:47] <seb128> Trevinho, no need to convince me, just ask Ken for a +1 and so they know we are updating
[13:47] <Trevinho> no wasn't about convincing, just to show what's going on :)
[13:48] <kenvandine> Trevinho: cool, yeah good to grab that
[13:48] <Trevinho> kenvandine: hey... so the idea was to do a transition to pipewire-3 that involves also the portals 1.8
[13:49] <kenvandine> we need to look into pipewire
[13:49] <Trevinho> kenvandine: I don't think it should break anything, but seb128 rightly pointed out to check with you
[13:50] <kenvandine> pipewire isn't in main, is it now a depends?
[13:50] <Trevinho> kenvandine: would be this https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4265.1/+packages
[13:51] <Trevinho> kenvandine: it always been a build-depend not to be a debian diff, we could avoid it, but given we'd have to do this next cycle anyways (very likely), we thought it would be just better to do it earlier
[13:51] <Trevinho> to reduce the various debian/upstream deltas
[13:51] <kenvandine> i agree
[13:51] <kenvandine> we need to do it
[13:53] <Laney> what is this new constraint, which packages do we have to consult with kenvandine about now?
[13:54] <Trevinho> Laney: desktop-portals
[13:56] <Laney> you mean?
[13:57] <Laney> I don't want to get this wrong, and it's a new requirement that I've apparently missed
[14:01] <kenvandine>  Laney he just wanted to make sure it wasn't going to break snap integration
[14:01] <Laney> yeah
[14:01] <Laney> I'm looking for guidance on how to tell if that's likely
[14:04] <seb128> Laney, I guess the question was rather 'did someone try a bunch of snaps that use portals and make sure there is no regression'
[14:04] <seb128> Laney, asking Ken to verify seemed like an easy way to get confirmation since he knows which one do use portals and how to test
[14:05] <Laney> seb128: I don't know how to tell which updates trigger that question
[14:05] <seb128> Laney, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4265.1/+packages did
[14:05] <seb128> which includes xdg-desktop-portal-(gtk) to 1.7
[14:06] <seb128> we discussed 1.6 vs 1.7 some weeks ago here and I asked Ken if we should update and he said he wanted to talk to upstream before taking the new serie
[14:06] <seb128> so I was just trying to make sure we don't overlook an issue with updating
[14:06] <Laney> so any update to xdg-desktop-portal package?
[14:06] <Laney> and -gtk
[14:06] <seb128> unsure what's the problem you try to raise?
[14:07] <seb128> but yes, updating portals to a new serie after ff I would expect we verify that the update has no regression by testing with known snaps
[14:07] <Laney> I want to know how to know when to ask such a question
[14:07] <Laney> because I would have uploaded this,s o I'm looking for guidance
[14:07] <Laney> that's all
[14:07] <seb128> I guess I could change that
[14:07] <seb128> need a ffe
[14:07] <seb128> :-)
[14:08] <Laney> just trying to do the right thing really
[14:08] <seb128> I was just asking if we tested the new portals with some snaps
[14:08] <seb128> sorry if that was a weird question
[14:08] <Laney> it's not weird!
[14:09] <Trevinho> I think it was right to do indeed
[14:09] <Laney> I'm just asking for clarification so I can ask the same questions
[14:09] <seb128> the angle I'm coming from is that I don't think we have solid testing about snaps and portal atm
[14:09] <Laney> trying to get information on what you think is required, and when, so that I can do the same
[14:09] <seb128> other things we probably know how to test better
[14:09] <Laney> it's not a challenge, it's not supposed to come across like that
[14:09] <Laney> trying to help myself do better
[14:09] <seb128> k, sorry
[14:12] <seb128> but yeah, to reply at your question, I think we should test that portals still work correctly when updating the portal or -gtk components
[14:12] <seb128> I'm not sure myself how to do that though, I don't know exactly what integrations bits are working with snaps today and what snaps are good candidate to test
[14:13] <Laney> there's a portal tester app somewhere isn't there
[14:13] <Laney> ?
[14:13] <seb128> which is why I suggested asking to Ken, but we should probably document that or at least share the knowledge
[14:13] <seb128> could be :-)
[14:13] <Laney> portal-test               0+git.0dc8864   jamesh                -      xdg-desktop-portal test application
[14:13] <Laney> 😎
[14:15] <seb128> sounds like a good one indeed, thanks for the pointer
[14:16] <seb128> Trevinho, ^ just confirm with that snap that things still work as expect I guess then :-)
[14:17] <Laney> I wonder if someone would be interested in writing that as e.g. an ISO test case
[14:20] <seb128> kenvandine, ^ you maybe?
[14:22] <Laney> maybe it could be a point in http://iso.qa.ubuntu.com/qatracker/milestones/413/builds/220597/testcases/1303/results ?
[14:22] <Laney> if someone writes the text, me or jibel can get it in there
[14:23] <Trevinho> seb128: soooo... just tested `portal-test` and it does WORK
[14:24] <seb128> great :-)
[14:25] <Trevinho> I think portal is broken in one thing btw... in the snap, if you save something in /tmp it still points to snap's $TMPDIR, which... Isn't what the portal is supposed to do
[14:26] <Trevinho> I think that's also the reason why firefox open download isn't working well?
[14:26] <Trevinho> oSoMoN: maybe you looked at it? ^
[14:26] <kenvandine> we have the portal-test snap that's useful for testing that stuff
[14:27] <kenvandine> Trevinho: the firefox open thing is really caused by browser-support in snapd
[14:27] <kenvandine> that is fixed in snapd, but not released to stable yet
[14:28] <Trevinho> kenvandine: I see
[14:28] <kenvandine> i'll add this PPA in a VM and test the portal integration
[14:32] <Trevinho> kenvandine: nice, thanks
[14:33] <Trevinho> kenvandine: expect the shell to make uninstall you the indicators :)
[14:33] <kenvandine> that's fine :)
[14:41] <hellsworth> good morning desktopers
[14:45] <hellsworth> ricotz: i know you're eager to go for 7.0.2~rc1 but 7.0.1 is ready to go now
[14:46] <oSoMoN> good morning hellsworth 
[14:47] <hellsworth> hi there oSoMoN !
[14:54] <ricotz> hellsworth, ack, the rc would be something for next week
[14:57] <hellsworth> ricotz: i'm rebuilding the artifacts now with seb's changelog entry moved.. 
[15:00] <hellsworth> marcustomlinson: you did run autopkgtests against the prereleases ppa 7.0.1 and they all passed except for arm64 but it looks like a builder failure and nothing more
[15:01] <marcustomlinson> ok sorry I do vaguely recall this from last week yeah
[15:06] <hellsworth> last friday you ran the tests
[15:06] <hellsworth> or maye it was thursday
[15:14] <hellsworth> marcustomlinson: you may be happy to know that i just deleted 9 ppas. so i'm down to only 3 now :)
[15:26] <kenvandine> Trevinho: everything in portal-test that worked in focal works in groovy with the PPA
[15:27] <Trevinho> kenvandine: great
[15:27] <Trevinho> thanks for confirming 
[15:27] <kenvandine> anytime
[15:31] <marcustomlinson> hellsworth: :)
[15:46] <ricotz> hellsworth, package looks good now
[15:46] <hellsworth> \o/
[15:46] <hellsworth> marcustomlinson: can you please upload this to groovy? https://launchpad.net/~hellsworth/+archive/ubuntu/lo-dummy-repo-1/+packages
[16:06] <marcustomlinson> hellsworth: will do in a few
[16:07] <hellsworth> ty
[16:49] <marcustomlinson> ricotz, hellsworth, https://launchpad.net/ubuntu/+source/libreoffice/1:7.0.1-0ubuntu1
[16:49] <hellsworth> thanks!!!!
[17:07] <ricotz> marcustomlinson, \o/
[17:08] <ricotz> hellsworth, please don't forget to update the git branch
[17:20] <hellsworth> ricotz: i pushed the changelog change and pushed a tag
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
[19:03] <seb128> marcustomlinson, I've no idea how close were glibc and poppler to migrate but that upload is resetting the transition until libreoffice is built and its autopkgtest results come back green now :-/
[20:45] <hellsworth> so sorry seb128 for the glibc and poppler migration interruptions :(
[20:56] <seb128> don't worry, it's tricky to know about ongoing transition (and on that note 'night desktopers)