[01:26] <callmepk> Good morning
[02:00] <duflu> Hi callmepk 
[02:01] <callmepk> Hi duflu 
[04:25] <duflu> RAOF, looks like the open thread can be closed?... https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4294
[04:38] <RAOF> Yes. I guess I just need to ping whoever can trigger Marge
[05:56] <oSoMoN> good morning desktoppers
[06:18] <jibel> salut oSoMoN 
[06:18] <oSoMoN> salut jibel 
[06:28] <seb128> goood morning desktopers!
[06:29] <callmepk> morning seb128 
[06:29] <seb128> hey callmepk, how are you?
[06:29] <didrocks> hey callmepk 
[06:30] <callmepk> Pretty great, how are you seb128 ?
[06:30] <callmepk> Hi didrocks , how are you
[06:30] <seb128> callmepk, I'm good thanks!
[06:53] <oSoMoN> salut seb128, didrocks 
[06:53] <oSoMoN> hey callmepk 
[06:53] <seb128> lut oSoMoN, comment ça va ?
[06:54] <didrocks> ça va oSoMoN  ?
[06:57] <oSoMoN> bien, et vous?
[06:57] <seb128> nickel :)
[07:02] <didrocks> ça va :)
[07:22] <duflu> Morning oSoMoN, jibel, seb128, didrocks
[07:23] <oSoMoN> hey duflu 
[07:24] <didrocks> hey duflu 
[07:24] <jibel> morning duflu 
[07:24] <didrocks> hey jibel 
[07:24] <jibel> Salut didrocks 
[07:24] <didrocks> jibel: FYI: https://github.com/openzfs/zfs/issues/7734 & https://docs.google.com/document/d/1y_zKQZJ8_RGYWwvx4k_QmR-PrFhrJUGAhWV-GT0lZRg/edit#heading=h.m922tj82ezp3
[07:24] <gitbot> openzfs issue 7734 in zfs "Swap deadlock in 0.7.9" [Component: Memory Management, Open]
[07:25] <jibel> didrocks, yeah, that's good and will solve many problems.
[07:25] <didrocks> indeed :)
[07:25] <jibel> didrocks, finally from the logs on ug 1874304
[07:25] <jibel> bug 1874304
[07:26] <jibel> didrocks, it is not our fault :)
[07:26] <jibel> that's the important point 
[07:26] <jibel> didrocks, my guess is a corrupted rpool
[07:26] <jibel> and again docker + zfs
[07:26] <jibel> + some tool that does automated snapshots
[07:27] <didrocks> jibel: 2 tools for automated snapshots even when I see the list of datasets
[07:27] <jibel> didrocks, as I suspected the failure happens in grub-mkconfig
[07:27] <didrocks> provisonning + auto_zfs_something
[07:27] <jibel> yeah
[07:28] <didrocks> yeah, it’s very early, so not something "new"
[07:28] <didrocks> unsure how the pool is corrupted
[07:28] <didrocks> also, notice the non imported bpool
[07:28] <jibel> I don't know, zpool status as root would tell, but the hook ran as user
[07:28] <didrocks> still, the fact that zsysctl times out on 7000 datasets with this structure is annoying
[07:29] <didrocks> I wonder if getting all datasets and property by zfs get all wouldn’t be faster :/
[07:29] <didrocks> but we need to find something rather than fighting go-libzfs
[07:29] <jibel> yup yup
[07:29] <didrocks> $ time zfs get all
[07:30] <didrocks> real 0m0,960s
[07:30] <didrocks> user 0m0,087s
[07:30] <didrocks> sys 0m0,818s
[07:30] <didrocks> $ zfs list -t all | wc -l
[07:30] <didrocks> 461
[07:30] <didrocks> on my machine FYI
[07:30] <didrocks> unsure how long this will be for 7000 datasets
[07:30] <didrocks> ah, but we still need the zhp handler…
[07:31] <didrocks> (at least, we can try experimenting enhancing the timeout handling, see the bug I opened against zsys)
[07:48] <seb128> hey duflu, how are you? did you manage to cut a bit from the work stress with the monday off?
[07:49] <duflu> seb128, I am OK. I switched off mentally and got home/garden maintenance done, a little. Though looking through the bug backlog looks like it will take a couple of days. So I am stressed now. Actually less than I expected though
[07:49] <duflu> How are you, seb128?
[07:50] <seb128> duflu, I'm good! spent my monday doing bug triaging and thinking about SRUs and co, so I know the feeling
[07:52] <seb128> duflu, it's nice to see some of the shell&co bugs fixed in git like the alternative keymap one
[07:54] <duflu> seb128, yeah their priorities are matching the most reported issues in focal
[07:55] <duflu> Just frustrating how many other bugs only affect one person, and stay open for years
[07:56] <seb128> right, little we can do there out of just triaging them low and moving to more important problems
[07:57] <marcustomlinson> morning desktoppers
[07:58] <duflu> marcustomlinson, morning
[07:58] <seb128> hey marcustomlinson, how are you?
[07:58] <duflu> seb128, one issue I think our own developers don't understand is that "Nvidia" bugs typically mean Nvidia-only systems. Not hybrid systems
[07:59] <marcustomlinson> seb128: a little below average today, rough night :/ But alive so there's that
[07:59] <seb128> duflu, I don't think the issue is understanding, it's access to hardware
[07:59] <seb128> marcustomlinson, :-( good luck for today then! 
[07:59] <marcustomlinson> seb128: how are you?
[07:59] <seb128> I'm fine, thanks
[07:59] <duflu> Well, it's a recurring issue. Actually probably more often a user misunderstanding. They have an Nvidia sticker on their laptop and they think they're using Nvidia
[08:01] <seb128> also booting on the nvidia card on an hybrid isn't going to be good enough to trigger those bugs?
[08:02] <duflu> seb128, there's no such thing
[08:02] <didrocks> hey marcustomlinson 
[08:02] <duflu> The LCD is always (almost always) only wired to Intel
[08:02] <Laney> hi ho
[08:03] <duflu> So the shell uses Intel and not the Nvidia driver
[08:03] <duflu> Hi Laney
[08:03] <seb128> jbicha, I would appreciate if you asked here before switching the team tools to new series
[08:03] <marcustomlinson> hey didrocks and Laney
[08:03] <seb128> duflu, so it means there is a nvidia gpu but it can't real be used?
[08:03] <seb128> hey Laney, how are you?
[08:03] <duflu> seb128, only as a child of the Intel GPU which owns the real screen
[08:04] <duflu> Nvidia is allowed to own a window
[08:04] <seb128> I see
[08:04] <duflu> or the HDMI port if it's wired to that
[08:04] <seb128> I didn't know that, useful
[08:04] <seb128> I will stop trying to borrow my gf hybrid's laptop to try to reproduce nvidia reported issues then
[08:05] <seb128> Trevinho, hey, do you have an nvidia only system to use for debugging? 
[09:00] <ricotz> good morning desktopers!
[09:06] <seb128> hey ricotz, how are you?
[09:07] <Laney> hey duflu marcustomlinson seb128, doing ok!
[09:07] <Laney> huh looks like I forgot to press enter on that
[09:07] <Laney> /o\
[09:07] <seb128> :-)
[09:07] <duflu> And I keep forgetting to scroll down, for hours at a time and miss IRC
[09:08] <duflu> So we're even, in a way
[09:08] <Laney> there's like 12000 pending tests per arch on autopkgtest at the minute
[09:08] <Laney> don't think I've ever seen it that high
[09:08] <seb128> fun
[09:09] <seb128> nice to see that the new serie started without too much delay this time
[09:09] <Laney> dok_o didn't want to push any toolchain stuff pre-opening
[09:09] <seb128> :)
[09:09] <Laney> so we just got it mostly done on friday, was quite smooth
[09:13] <seb128> git question of the day
[09:13] <seb128> is there an easy way than this command to update e.g debian/master when being on another branch?
[09:13] <seb128> $ git fetch origin debian/master:debian/master
[09:14] <seb128> (typically I'm on ubuntu/master and want to fetch the update Debian in debian/mater)
[09:14] <seb128> it's a bit tedious to type but googling failed me to give me something easier
[09:14] <seb128> (before I was do checkout; pull; checkout)
[09:16] <Laney> that's the best that I know
[09:16] <Laney> you could probably set up an alias
[09:20] <Laney> git config --global alias.pb fetch origin $0:$0 or something
[09:20] <seb128> thx, I will give it a try
[09:22] <Laney> ah no, you can't have paremeters like that
[09:22] <Laney> probably more like !sh -c 'git fetch origin "$0:$0"'
[09:23] <jibel> didrocks, for disks > 2TB booted in legacy; I force the size of rpool to 2TB - bpool - swap - ESP
[09:24] <jibel> didrocks, are you okay with that or you prefer to error out?
[09:25] <didrocks> jibel: will we be able to boot it? I mean, we may not be able to have grub finding the start of the rpool partition, no?
[09:25] <didrocks> bpool being 2G. swap being 2G potentially…
[09:29] <seb128> Laney, 
[09:29] <seb128> $ git du debian/master
[09:29] <seb128> Depuis salsa.debian.org:gnome-team/nautilus
[09:29] <seb128>    a3a8353..8a38037  debian/master -> debian/master
[09:29] <seb128> Laney, thx :)
[09:29] <Laney> nice
[09:29] <Laney> that's Trevinho level
[09:29] <seb128> lol
[09:52] <jibel> didrocks, it'll work but that's a waste. I'm pondering whether a warning in ubiquity wouldn't be better rather than silently working around the limitation by reducing the amount of allocatable disk space
[09:57] <Trevinho> seb128: hey... I've only a prime system. 
[09:57] <seb128> Trevinho, hey, we should get you a proper nvidia config...
[09:57] <seb128> Wimpress, ^ do you think that's something we can get and how?
[10:08] <didrocks> jibel: yeah, a warning sounds better, because then, we’ll get bugs about "I have 10Tb of HDD, how come my rpool is only 1.blopTB?"
[10:14] <jibel> yes
[10:15] <didrocks> jibel: reading what docker is doing on ZFS, I wonder if she shouldn’t add a patch there (unsure how the snap behaves) to create a persistent /var/lib/docker
[10:19] <jibel> right, I was thinking the same and it's something we quickly considered when we decided the layout at the very beginning
[10:19] <didrocks> ok, at least docker rm (but who does docker rm on stopped container?) and docker rmi removes the datasets
[10:20] <didrocks> yeah
[10:20] <didrocks> I really think about a hook in the ubuntu package
[10:20] <didrocks> but I need to look if snap has the same behavior
[10:20] <didrocks> and in this case, you to hook that in snap installation?
[10:20] <jibel> didrocks, we should alos ensure that snaps are on a persistent dataset since it's managing it's own history and the first thing snap will do after a revert is to re-update the packages
[10:22] <didrocks> jibel: the issue is that if you revert, you may expect to have the previous snap version and we would loose this (this is why we put it in system datasets)
[10:22] <didrocks> but correct after the auto-reupdate of boot
[10:26] <jibel> didrocks, with snaps we must also consider the data stored in the home directory. eg you do a system revert to a snapshot that had an old version of a snap and the user data in $home for this version of the snap has been purged
[10:26] <jibel> hardly fixable though
[10:46] <didrocks> indeed
[11:25] <duflu> Trevinho, if you can find an old Macbook Air (2010/2011 ish) then I think that's a fairly pure Nvidia-only system. And portable
[11:26] <Trevinho> ok, will look... not sure I would love to have apples in my flat though xD 
[11:27] <duflu> No one will see you in your skivvy
[11:28] <duflu> or turtleneck
[11:30] <duflu> Trevinho, even the tiny 11 inch one that cimi had is pure Nvidia
[11:30] <duflu> or the old models anyway
[11:31] <duflu> Just an idea
[11:31]  * duflu -> dinner
[11:32] <jbicha> seb128: ok, are you going to change the version tracker back to focal then?
[13:01] <seb128> hey desktopers, would you be ok shifting the meeting to be half an hour later to not conflict with the roadmap sessions?
[13:01] <marcustomlinson> sure
[13:02] <didrocks> sure
[13:02] <seb128> we could skip but it's probably good to at least review the ff incoming candidates
[13:02] <seb128> thx
[13:02] <seb128> I think we should be able to fit in the half hour
[13:09] <jibel> works for me
[13:23] <seb128> jbicha, no, I'm hacking a report for focal, but at this point it's more important than we track stable updates in the LTS
[13:24] <seb128> so it's a bit unfortunatat that you removed that report in favor of something we are not having real use of yet
[13:28] <hellsworth> good morning desktopers
[13:28] <oSoMoN> seb128, works for me
[13:28] <oSoMoN> good morning hellsworth 
[13:29] <hellsworth> hi there oSoMoN 
[13:32] <hellsworth> team meeting?
[13:34] <didrocks> hey hellsworth 
[13:34] <didrocks> hellsworth FYI: 15:01:43          seb128 | hey desktopers, would you be ok shifting the meeting to be half an hour later to not conflict with the roadmap sessions?
[13:34] <didrocks> you can get another cup of tea/coffee :)
[13:34] <hellsworth> ah ok thanks
[13:34] <hellsworth> should have scrolled up :)
[14:00] <seb128> k, let's do it then :)
[14:01] <hellsworth> okey dokey..
[14:01] <seb128> #startmeeting Desktop Team Weekly Meeting - 2020-04-28
[14:01] <meetingology> Meeting started Tue Apr 28 14:01:10 2020 UTC.  The chair is seb128. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:01] <meetingology> Available commands: action commands idea info link nick
[14:01] <seb128> Roll call:  didrocks, duflu (out), heather, jamesh (out), jibel, kenvandine (out?), laney (out?), marcustomlinson (out), oSoMoN, tkamppeter, trevinho, robert_ancell (out)
[14:01] <didrocks> hey
[14:01] <hellsworth> o/
[14:01] <Laney> not out
[14:01] <marcustomlinson> \o
[14:01] <jibel> hola
[14:01] <seb128> congrats on focal, feedback is looking good from what I saw
[14:02] <kenvandine> o/
[14:02] <oSoMoN> o/
[14:02] <seb128> k, let's get started and try to fit in the half an hour
[14:02] <seb128> #topic rls-bb-bug
[14:02] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[14:02] <seb128> no desktop there
[14:03] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html
[14:03] <seb128> bug #1874893
[14:03] <seb128> kenvandine, looks like yours, please get it assigned to someone for bionic and focal
[14:03] <seb128> and that's it for bionic
[14:03] <seb128> #topic rls-ee-bug
[14:04] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-incoming-bug-tasks.html
[14:04] <seb128> no desktop there
[14:04] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-tracking-bug-tasks.html
[14:04] <seb128> bug #1853768 got nominated for 19.10
[14:05] <seb128> Dmitry unassigned himself in fact because focal is out and he has no interest is still SRUing
[14:05] <seb128> I think we should wontfix
[14:05] <Laney> yep
[14:05] <hellsworth> agree
[14:05] <seb128> also we should probably wontfix some other assigned items that didn't move
[14:06] <seb128> I will review the list and talk to people outside the meeting
[14:06] <seb128> probably not worth SRUing for 19.10 at this point
[14:06] <seb128> #topic rls-ff-bug
[14:06] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[14:07] <seb128> skipping the first which is incompelete
[14:07] <seb128> bug #1874047 is fixed in .2 and that's going to be a a security update
[14:08] <seb128> I'm going to rls-ff-notfixing since it's handled by security already
[14:09] <seb128> bug #1874556 is fix commited, just needs triaging
[14:09] <seb128> (and SRU team to wake up)
[14:09] <Laney> nominate/assign it
[14:09] <Laney> wants sru template too no?
[14:09] <seb128> well, the fix is in the queue without bug reference
[14:10] <seb128> https://launchpadlibrarian.net/475819279/libreoffice_6.4.3-0ubuntu0.20.04.1_source.changes
[14:10] <seb128> I don't know if it's worth rejecting/asking for a new upload to add one
[14:10] <hellsworth> there is an open sru about 6.4.3
[14:10] <seb128> right
[14:10] <Laney> the bug referenced doesn't mention testing this scenario
[14:10] <seb128> right, I mean I don't know if it needs to be formally included in the testing, but probably would be good to confirm it's tested
[14:11] <seb128> Heather, can you update the bug to be SRU compliant?
[14:11] <hellsworth> i'll double check that 6.4.3 fixes this
[14:11] <seb128> and mention it in the test plan from 6.4.3
[14:11] <seb128> thx
[14:11] <hellsworth> ok
[14:11] <seb128> I will accept the nomination
[14:11] <seb128> bug #1865824
[14:12] <seb128> Brian raised it up, Marco tagged it so we can discuss as a team
[14:12] <seb128> my opinion was to -1 it as a rls bug
[14:12] <seb128> the format changed and a migration isn't trivial
[14:12] <Trevinho> -1 as well :D
[14:13] <seb128> it could be done but seeing that we had very few hardware supported and that fingerprint shouldn't be the only auth mechanism it seems low return value
[14:13] <Trevinho> but should be actually a 0, while team should decide
[14:13] <seb128> other opinions?
[14:13] <oSoMoN> this should be mentioned in release notes though
[14:13] <seb128> it is, see the bug
[14:14] <Trevinho> also... we were discussing with Ben, that given the image devices will change in future (tm) comparison method, it would probably trigger another incompatibility. And that is for good.
[14:14] <seb128> 'Due to database format changes fprintd will remove all saved fingerprints, please ensure you have another mechanism for logging in (http://launchpad.net/bugs/1865824). ' on https://wiki.ubuntu.com/FocalFossa/ReleaseNotes
[14:14] <Trevinho> so, if not this LTS the next anywyas
[14:14] <didrocks> I think we shouldn’t plan to break it again as it seems we do though :/
[14:15] <Laney> seems a bit unprofessional to do it, especially silently
[14:15] <didrocks> migrating user settings is crucial if we say we are supporting upgrades but that’s just my opinion
[14:15] <seb128> wait
[14:15] <seb128> let's not start with futur potential issue here
[14:15] <seb128> and focus on the current situation
[14:15] <Trevinho> sure sure
[14:15] <seb128> bionic didn't have fprintd pre-installed
[14:15] <Trevinho> nope
[14:16] <Trevinho> so not an LTS regression
[14:16] <seb128> didrocks, Laney, you were speaking about bionic->focal upgrades or responding to Marco's futur plans comment?
[14:16] <didrocks> so on that one, I would -1 on rls bugging it (but reluctantly :p)
[14:16] <Laney> that's a dubious line in my opinion
[14:16] <Laney> like, you can use something before
[14:16] <Trevinho> yeah indeed was easy to install even in bionic
[14:16] <Laney> but as soon as *we* bless it, we can break your previous setup and that's ok
[14:16] <Laney> seems dodgy
[14:16] <didrocks> just responding to "it’s ok to break it this time and btw, we will rebreak it"
[14:17] <seb128> Laney, I don't think it's ok
[14:17] <seb128> I'm just trying to be realistic on the resources we have and how we can spend them 
[14:17] <seb128> ideally I would like to see the bionic configs migrated as well
[14:17] <seb128> anyway
[14:17] <Laney> right, well I don't like the line of justification that's being used
[14:17] <Trevinho> I can look at how time could be needed...
[14:17] <seb128> please +1 0 -1
[14:18] <Trevinho> as per Ben's isn't trivial, but I didn't try with code yet
[14:18] <seb128> I see, sorry I should probably have avoided to give arguments
[14:18] <oSoMoN> -1 but let's make sure we communicate clearly why (lack of resources)
[14:18] <Laney> I would at least try to tell people when they upgrade or reboot after upgrading or something
[14:18] <seb128> ignore those and let's just vote, I'm happy to be overruled
[14:19] <Laney> +1 for doing *something* even if not migrating
[14:19] <seb128> -1 from me for rls nomination
[14:19] <seb128> I would still add it to lts-wishlist
[14:19] <didrocks> as said -1 relunctantly, but given the constraints…
[14:19] <seb128> k, it's a reject then
[14:20] <seb128> Laney, sorry, I agree we should try to fix it and will mention that when I comment and tag it for the lts-wishlist 
[14:21] <Laney> bit of a bad path imho
[14:21] <Laney> but that's the way of voting
[14:21] <seb128> right
[14:21] <seb128> moving on
[14:21] <seb128> bug #1874091
[14:22] <didrocks> l-r-m?
[14:22] <seb128> the item there seems more for ubuntu-release-upgrader, it's not even clean what ubuntu-drivers-common change are expected?
[14:22] <jibel> the report is a bit dry
[14:22] <seb128> linux-restricted-modules I guess?
[14:22] <Laney> yes
[14:22] <didrocks> ah
[14:22] <jibel> adding a rationale would help to have an opinion
[14:22] <seb128> I will ask for details of what they expect from ubuntu-drivers
[14:23] <Laney> I think ubuntu-drivers has all the functionality already
[14:23] <seb128> good :)
[14:23] <seb128> k, moving on
[14:23] <seb128> bug #1874148
[14:23] <seb128> that's a known bug/duplicate
[14:24] <seb128> the quit item on the dock context menu works
[14:24] <jibel> I like the title
[14:24] <marcustomlinson> :D
[14:24] <seb128> would be nice to fix but -1 to rls nominate for me
[14:24] <seb128> indeed, nice title :)
[14:24] <didrocks> well, that was a design decision, no?
[14:25] <seb128> no, it was working in bionic iirc
[14:25] <Laney> that was a bug
[14:25] <seb128> we don't have a quit button on the UI by design
[14:25] <jibel> yes but that was a bug
[14:25] <didrocks> ah, I thought that was on purpose
[14:25] <Laney> but it shouldn't show the non working quit
[14:25] <seb128> but we said the item in the shell should work
[14:25] <Laney> that is the bug here
[14:25] <didrocks> ah ok. it’s only on the right click
[14:25] <Laney> which is probably not rls
[14:25] <didrocks> ack, got it, sorry
[14:25] <didrocks> but yeah, not rls for me -1
[14:26] <seb128> good, notfixing then
[14:26] <seb128> bug #1869747 is incomplete, skipping
[14:26] <seb128> bug #1874207
[14:26] <seb128> Trevinho, one for you?
[14:26] <Trevinho> yep
[14:27] <Laney> champagne wtf
[14:27] <Trevinho> not sure is rls but..
[14:27] <seb128> Daniel commented on some of the other fractional scalling/nvidia tickets that it has consequence on the behaviour of those bugs
[14:27] <seb128> like he said the nvidia loosing signal happening randomly for him and is not random anymore when fixing the warning
[14:27] <seb128> unsure why he just didn't submit a patch though...
[14:28] <Trevinho> not sure about, need to check, I didn't notice, when compiling locally, but will handle those indeed
[14:28] <seb128> Laney, and yeah, I'm going to talk to him about the tag use again I think...
[14:28] <seb128> Trevinho, thx
[14:28] <seb128> k, that's it for the incoming
[14:28] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html
[14:28] <seb128> bug #1856410
[14:29] <Laney> oh we get ubiquity bugs now?
[14:29] <seb128> no, ubuntu-drivers-common ones
[14:30] <seb128> tseliot, could you look at the request from foundations there?
[14:30] <seb128> unsure what to do with this one
[14:30] <seb128> does anyone has an opinion?
[14:31] <didrocks> opinon: the whole Mok enrolling experience is weird, you don’t really know what to do when rebooting
[14:31] <didrocks> so not the most buggy of the experience IMHO
[14:31] <hellsworth> opinion: seems like a real problem that should be fixed sooner than later
[14:32] <hellsworth> nobody should be forced to use secure boot of all things
[14:32] <Laney> it is a good one for .1
[14:32] <Laney> if someone has the time
[14:32] <seb128> I will ask foundations if they plan to work on it
[14:32] <jibel> +1 for .1, many people install 3rsd party for nvidia and it doesn't require enrollment
[14:32] <seb128> and maybe Alberto can do the u-d-c changes
[14:32] <seb128> thx Laney, jibel
[14:32] <seb128> k, that's it for bugs then
[14:33] <seb128> #topic update_excuses_by_team.html#desktop-packages
[14:33] <seb128> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
[14:33] <tseliot> seb128, it makes sense, and I can make those changes to u-d-c
[14:33] <seb128> tseliot, thanks!
[14:33] <seb128> I'm assigning to you then :)
[14:33] <seb128> ^ I'm taking the opportunity to say that the new 'groovy' serie is open and autosync already started
[14:34] <seb128> we are not going to review proposed item today, let's wait for the initial hit to settle down
[14:34] <seb128> #topic AOB
[14:34] <seb128> any other topic?
[14:34] <didrocks> nothing for me
[14:34] <seb128> one note from me
[14:35] <Trevinho> all clear here
[14:35] <seb128> I set up an hackish stripped down focal-versions script mostly for GNOME, to make easier to see what SRU to need to do on the LTS
[14:35] <seb128> https://people.canonical.com/~platform/desktop/focal/desktop-packages.html
[14:35] <seb128> I will probably make it update once a day which is enough for stable
[14:36] <seb128> I do plan to clean up the code and put in a branch at some point but meanwhile if you would like some other package to be added or tweaks feel free to ping me
[14:36] <seb128> I also added cards for GNOME SRU to the common board, they are tagged SRU, help would be welcome if some of you want to grab updates
[14:36] <seb128>  
[14:36] <seb128> that's it from me
[14:36] <seb128> sorry we went slightly over the half hour
[14:36] <seb128> anything else?
[14:38] <seb128> seems not
[14:38] <seb128> thanks!
[14:38] <seb128> #endmeeting
[14:38] <meetingology> Meeting ended Tue Apr 28 14:38:07 2020 UTC.  
[14:38] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2020/ubuntu-desktop.2020-04-28-14.01.moin.txt
[14:38] <hellsworth> thanks!!
[14:39] <marcustomlinson> thanks
[14:39] <oSoMoN> thanks
[14:40] <didrocks> thanks!
[14:40] <jibel> thank you everyone 
[15:16] <Laney> seb128: are you following up with debian / groovy uploads for those srus?
[15:16] <Laney> (I know salsa is down atm)
[15:34] <seb128> Laney, yes, half of those are already synced to groovy, 2 are pending Debian to be back to sync, eog is pending salsa to be back for me to be able to push
[15:35] <Laney> ok good
[15:57] <Laney>  omg
[15:57] <Laney> I finally upgraded my dev container to focal from disco just now
[15:57] <Laney> lintian generates *clickable links*
[16:00] <Laney> looooooooove ittttt
[21:30] <robert_ancell> hellsworth, hi, online?