[01:54] <pieq> Hi!
[02:55] <callmepk> good morning
[04:45] <jibel> Good morning all
[05:15] <duflu> Hi jibel, and pieq and callmepk 
[05:15] <callmepk> hey duflu jibel pieq 
[05:58] <didrocks> good morning
[06:13] <luna_> hey
[07:09] <didrocks> Laney: hey! can you update oem-qemu-meta so that the diff between what the oem team wants to sponsor and the reference package is smaller? For instance, on https://bugs.launchpad.net/oem-priority/+bug/1888764, there is a bunch of stuff (gbp.conf and so on) which introduces noise, but also some of the things you are more appropriate than us to see if this relevant like
[07:09] <ubot5> Ubuntu bug 1888764 in OEM Priority Project "[MIR] oem-sutton.simon-baird-meta" [High,Confirmed]
[07:10] <didrocks> XB-Ubuntu-OEM-Kernel-Flavour: oem that they now add
[07:10] <didrocks> also, they remove debian/tests/meta and such
[07:10] <didrocks> if I keep strict, I would just reject so that we have a smaller diff :p
[07:20] <didrocks> also, even the main reference package has Public License version 2 can be found in "/usr/share/common-licenses/GPL-3".
[07:20] <didrocks> some new ones are fixed, some not
[07:21] <didrocks> quite painful :/ I wonder if a better approach would be to only have one source package, and generates all of them via a reference file at build-time
[07:21] <didrocks> this way, no source to NEW each time, just binary NEW
[07:21] <didrocks> I guess there was a reason to not do that? (but then, have a lot of differences between packages, which was my initial fear and seems to happen)
[07:28] <RikMills> what is the planned gnome-shell version for groovy?
[07:29] <didrocks> RikMills: should be latest GNOME once released, so 3.38
[07:30] <RikMills> didrocks: thanks!
[07:31] <RikMills> just pondering whether to FFe the new pipewire in unstable, which would make gnome-remote-desktop need 3.38
[07:32] <didrocks> I don’t see https://bugs.launchpad.net/oem-priority/+bug/1882347 in focal though… /me puzzled
[07:32] <ubot5> Ubuntu bug 1882347 in Ubuntu Focal "[needs-packaging] [MIR] oem-stella.cmit-abra-meta" [High,In progress]
[07:33] <RikMills> plasma developers are starting to do things that require pipewire >= 0.3
[07:36] <marcustomlinson> morning desktoppers
[07:37] <didrocks> hey marcustomlinson 
[07:37] <marcustomlinson> hi didrocks
[07:42] <duflu> Morning didrocks, luna_, marcustomlinson, Europe
[07:42] <duflu> and UK
[07:42] <didrocks> hey duflu 
[07:46] <marcustomlinson> hey duflu
[07:47] <didrocks> (in some, also, oem just rename tests/meta and some others, they don’t)
[08:04] <Laney> morning
[08:05] <didrocks> hey Laney 
[08:05] <Laney> didrocks: they have a script to generate these, I gave some "helpful" "feedback" on all of these deltas already, should be better in future when they fix that ...
[08:05] <Laney> the test renaming is the most annoying one
[08:06] <Laney> and unnecessary
[08:06] <didrocks> should I reject the packages then until they fix the deltas ?
[08:06] <didrocks> where there anything against having a single source package and generating them at build time?
[08:07] <Laney> yes, that was discussed, pretty much everything possible was :p
[08:07] <Laney> it means all of the packages get updated when you update any of them
[08:07] <Laney> I'd rather they got accepted and fixed next time
[08:08] <didrocks> well, a small no-op update (we already have so many updates in term of packages) rather than hundreds of diffs everywhere
[08:08] <didrocks> I don’t think we can ensure "next time" will be better and that the diff will magically disappear
[08:08] <Laney> ok
[08:08] <Laney> thanks for the help anyway
[08:09] <Laney> I'll just do all 30 myself
[08:09] <didrocks> I think it’s still time to reevaluate and help so that we don’t have the pain on us in the future
[08:09] <didrocks> as we have possibilities for this
[08:10] <didrocks> which is my suggestion, but if you don’t take it, *g*
[08:10] <Laney> Come to the next meeting we have if you want to re-open all this stuff
[08:10] <didrocks> happy to
[08:10] <Laney> fine
[08:10] <Laney> I'll invite you
[08:10] <didrocks> thanks
[08:11] <Laney> will you help now or is it all back on me?
[08:11] <didrocks> if we go to one single source package, happy to help
[08:11] <Laney> no then, ok, thanks
[08:11] <didrocks> *shrugh* that’s not helpful and positive discussion trying to find solution
[08:12] <Laney> We can change things for *future*, but these are updates that need to happen now, they represent enablements that the OEM team has done and need to get out there
[08:12] <Laney> we can't block on finding a different solution
[08:13] <Laney> so they have to be done, so I will do it
[08:13] <didrocks> so, let’s approve everything and not looking at the annoying diff, this is what you suggest?
[08:13] <didrocks> let’s not update the qemu meta package which reference in the same file GPL-2 AND GPL-3?
[08:14] <didrocks> I don’t even know if XB-Ubuntu-OEM-Kernel-Flavour: oem is desirable or not as the reference package doesn’t have it
[08:15] <Laney> I'm happy to address that kind of comment if it helps you to do the review you want to do
[08:16] <Laney> but I'm not happy to stop, chuck everything out, go back to the drawing board - I just don't think we can do it this way around
[08:17] <didrocks> I don’t want to stop, but it seems that getter things easier to deal with is even off the table with this attitude
[08:17] <didrocks> so, in the end, I warned about this situation already, it was dismissed, we are now in, and the pain is on everyone
[08:17] <didrocks> which is why I think it’s important to at least acknowledge there is something to fix
[08:17] <didrocks> then, we can unblock painfully those
[08:18] <didrocks> and reevaluate what to do
[08:18] <didrocks> but certainly a "ok, thanks for the help anyway, I’ll just do all 30 myself" seems to point to not wanting getting things in a better position in the future nor wanting to ack there is a pb
[08:19] <Laney> We've already been working on the process so that the distro team is out of the loop of this completely, except for an AA (me) accepting the packages
[08:19] <Laney> It's just not quite there with the DMB having the packageset ready and stuff yet
[08:20] <didrocks> I don’t see how the pakageset ready will help avoiding differences in packages, the same issue will happen again in the MIR review with the diff anyway
[08:20] <Laney> They get accepted straight to main, there is no separate MIR review
[08:21] <Laney> So, get the team uploading with a sensible diff (I have fed back already), accepting AA runs the script and accepts to main
[08:21] <didrocks> what is blocking them regenerating sensible diff right now?
[08:22] <didrocks> we will always have diverges if from the first set of package, we already have some
[08:23] <Laney> I guess that was probably me giving that indication that it was OK to fix for next time
[08:23] <Laney> but we can go round again I guess, maybe that's not too bad to do
[08:23] <Laney> it would avoid a negative diff between the two updates next time
[08:24] <didrocks> indeed
[08:26] <Laney> Yeah that sounds sensible to me, I have asked!
[08:26] <Laney> OK hold for a bit until we get feedback on that
[08:26] <didrocks> thanks Laney, keep me posted :)
[08:27] <didrocks> and please invite me to next meeting, happy to push for a single source package and work on automating the generation of those (and as we already have a bunch of example packages, we can have it working in the different cases like foo.bar, foo-bar-baz and such)
[08:29] <Laney> I'm happy for you to discuss it, but the current situation is what was agreed after many MANY meetings on all this stuff before, so don't get your heart set on changing it
[08:29] <Laney> my focus has been on getting the distro team out of it all completely except for the SRU approvals
[08:29] <Laney> with the idea that they handle it in the way they prefer
[08:30] <Laney> *opens window* *sound of chainsaw* *closes window completely*
[08:30] <didrocks> but we see that it’s not really scalable
[08:31] <didrocks> or at least, they should ensure the diff is small and we bindly reject otherwise
[08:31] <Laney> yeah that's why we had that script, maybe I should have been more strict in enforcing it
[08:32] <didrocks> I think there is no incentive in updating the reference package, which we should work on (hence the idea of a single source one), but if they don’t want it, they should help us then in easing our side as well
[08:33] <didrocks> and ensure what they file is scalable
[08:34] <Laney> I guess a couple of rejections will help with that :p
=== guiverc2 is now known as guiverc
[08:35] <didrocks> yep :)
[08:35] <Laney> what's the GPL-2 thing with the metapackage?
[08:38] <Laney> don't see it, but it should be fixed, so a pointer is welcome
[08:39] <didrocks> Laney: http://launchpadlibrarian.net/490676356/oem-qemu-meta_20.04~ubuntu4_20.04~ubuntu5.diff.gz is fixed in groovy (see d/copyright), but not in focal. It seems *some* (not all) oem metapackage are generated from 20.04~ubuntu3 package in focal, and some other have it fixed, but the diff was made on focal…
[08:40] <Laney> ah, I made oem-qemu-metapackage-check use pull-lp-source so it always comes from the dev series
[08:40] <didrocks> the diff should always be done against latest devel I think that was your intention? 
[08:40] <Laney> fml
[08:40] <didrocks> unsure why some of the diff have the previous version, maybe they came before the fix, I didn’t check
[08:40] <Laney> oem-metapackage-mir-check
[08:59] <cpaelzer> do we ahve any video edit alternative in main - I looked at kdenlive, openshot, pitivi but none is. I could go on checking but maybe someone just knows?
[09:36] <Laney> cpaelzer: not afaik
[09:51] <cpaelzer> ok, thanks
[09:55] <KGB-2> mutter tags 46f3af6 Simon McVittie upstream/3.36.6 * Upstream version 3.36.6 * https://deb.li/31UWh
[09:56] <duflu> \o/
[10:04] <Laney> didrocks: Rex says they will re-generate those packages using the script, so wait for that, I will let you know when that's done
[10:04] <Laney> thanks for that bit of push back, I think it was a good idea ;-)
[10:07] <didrocks> Laney: happy to have contribued, keep me posted once we can do the rereview :)
[10:29] <GunnarHj> Hi all!
[10:29] <GunnarHj> A few days ago "Ubuntu Software" became "Software Install" in groovy, but last night it seemed to be back to "Ubuntu Software". Is there a name change in pipeline? Asking since I'm about to take a look at the install part of the desktop guide.
[10:43] <jibel> I used latest groovy image installed the updates which included ubuntu-dock, after reboot, no dock
[10:43] <jibel> can someone have a look?
[10:43] <jibel> Trevinho, ^ 
[10:44] <Laney> was going to say, suggest pinging the uploader ;-)
[10:44] <Laney> GunnarHj: Not that I know of
[10:46] <jibel> Trevinho, from the journal
[10:46] <jibel> sept. 11 12:42:50 mp390185 gnome-shell[1309]: JS ERROR: TypeError: method Clutter.Actor.set_allocation: At least 2 arguments required, but only 1 passed
[10:46] <jibel>                                               vfunc_allocate@/usr/share/gnome-shell/extensions/ubuntu-dock@ubuntu.com/docking.js:83:14
[10:47] <duflu> Ugh, we fixed that in desktop-icons. Didn't check ubuntu-dock
[10:53] <Laney> I assume it works with 3.37?
[10:54] <Laney> if we're ready, I could kick out those broken extensions
[10:54] <Laney> migrating gnome-shell/3.37.91-1ubuntu1/amd64 to testing makes gnome-shell-extension-bluetooth-quick-connect/13-1/amd64 uninstallable
[10:54] <Laney> migrating gnome-shell/3.37.91-1ubuntu1/amd64 to testing makes gnome-shell-extension-caffeine/35-2/amd64 uninstallable
[10:54] <Laney> migrating gnome-shell/3.37.91-1ubuntu1/amd64 to testing makes gnome-shell-extension-easyscreencast/1.1.0-2/amd64 uninstallable
[10:54] <Laney> that will presumably make gnome-shell migrate
[10:54] <Laney> migrating gnome-shell/3.37.91-1ubuntu1/amd64 to testing makes gnome-shell-extension-top-icons-plus/27-1/amd64 uninstallable 
[10:56] <Laney> Trevinho: let me know !
[10:57] <duflu> Instead of looking I will try to EOW :)
[10:59] <duflu> I assume Marco has it sorted already since he mentioned ubuntu-dock and 3.37
[10:59] <duflu> So good night...
[11:03] <GunnarHj> Laney: Good. You ought to know I suppose. Unless some equivalent to bug #1570479 happens...
[11:03] <ubot5> bug 1570479 in gnome-software (Ubuntu) "[UIFe][FFe] Change application Name etc to Ubuntu Software" [Critical,Fix released] https://launchpad.net/bugs/1570479
[11:03] <Laney> dunno, plenty happens that I don't hear about until later on :p
[11:03] <GunnarHj> ;)
[12:40] <Trevinho> jibel: so, I apparently didn't backport the commit I did to support 3.36 as well in the groovy branch... I did it on purpose not to include uneeded changes there, but... Well apparently I forgot when changing the control file.
[12:40] <Trevinho> jibel: however newer shell can be unblocked now
[12:45] <Laney> ok, done, hopefully it goes in a couple of hours
[12:46] <Trevinho> Laney: so yeah... I didn't see the question sorry.. Those can be kicked out
[13:07] <Laney> Trevinho: there's a new gjs to sync
[13:07] <Trevinho> oh good, yeah... that's green.
[13:09] <Trevinho> done
[13:15] <Laney> 👍
[14:23] <Laney> argh
[14:23] <Laney> I didn't block the packages and they migrated straight back in, in front of gnome-shell
[14:23]  * Laney sucks
[14:48] <hellsworth> good morning desktopers
[14:50] <didrocks999> hey hellsworth 
[14:51] <luna_> heya
[14:54] <marcustomlinson> hey hellsworth
[14:55] <hellsworth> hi folks!
[15:05] <waveform> hellsworth, figured out the login mystery on the pi4; sent an e-mail with the solution!
[15:09] <hellsworth> hey i saw that thank you! about to try it actually
[15:14] <hellsworth> waveform: i can ssh to the pi4 now! Thanks :)
[15:14] <waveform> \o/
[15:15] <hellsworth> 🎉
[15:45] <Laney> shell 3.37 is going to go in now
[15:45] <Laney> for your dist-upgrade enjoyment
[15:45] <Laney> Trevinho: 
[15:46] <luna_> gnome ?
[15:59] <Trevinho> Laney: lovely! 
[15:59] <Trevinho> ... and jibel new bugs! 😊
[16:20] <jibel> I'll assume it's well tested and bug free :P
[16:38] <KGB-0> gnome-settings-daemon signed tags 767dc23 Iain Lane ubuntu/3.37.92-1ubuntu1 * gnome-settings-daemon Debian release 3.37.92-1ubuntu1 * https://deb.li/S7tV
[16:38] <KGB-0> gnome-settings-daemon ubuntu/master b3f73c7 Iain Lane * pushed 65 commits (first 5 follow) * https://deb.li/3b1Ag
[16:38] <KGB-0> gnome-settings-daemon ubuntu/master faedcdd Aurimas Černius po/lt.po * Updated Lithuanian translation * https://deb.li/3gCfN
[16:38] <KGB-0> gnome-settings-daemon ubuntu/master 3569ddd Jordi Mas i Hernandez po/ca.po * Update Catalan translation * https://deb.li/ix5ix
[16:39] <KGB-0> gnome-settings-daemon ubuntu/master 21014d5 Goran Vidović po/hr.po * Update Croatian translation * https://deb.li/k7Z2
[16:39] <KGB-0> gnome-settings-daemon ubuntu/master 58da95b Thibault Martin po/fr.po * Update French translation * https://deb.li/3W1oC
[16:39] <KGB-0> gnome-settings-daemon ubuntu/master 0c3875f Fran Dieguez po/gl.po * Update Galician translation * https://deb.li/eCqh
[17:09] <KGB-0> glib pristine-tar cbfa0bf Simon McVittie glib2.0_2.66.0.orig.tar.xz.delta glib2.0_2.66.0.orig.tar.xz.id * pristine-tar data for glib2.0_2.66.0.orig.tar.xz * https://deb.li/3V18h
[17:09] <KGB-0> glib upstream/latest a715f47 Simon McVittie * pushed 17 commits * https://deb.li/DY4n
[17:09] <KGB-0> glib tags 9092bb7 Simon McVittie upstream/2.66.0 * Upstream version 2.66.0 * https://deb.li/3L3q7
[17:17] <KGB-0> orca tags e04f148 Samuel Thibault upstream/3.38.0 * Upstream version 3.38.0 * https://deb.li/LCeg