[06:29] <ricotz> good morning desktopers
[06:29] <ricotz> mdeslaur, https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/1796625
[06:30] <duflu> Hi ricotz
[06:47] <seb128> good morning desktopers
[06:55] <duflu> Hi seb128
[06:58] <seb128> hey duflu, how are you? had a good w.e,
[06:59] <duflu> seb128, Hi. Felt good about getting up early but now it hurts. Although that's probably all the gardening I did. How are you?
[07:00] <duflu> seb128, also do you know what package owns/creates /etc/default/grub?
[07:03] <jibel> good morning
[07:04] <jibel> duflu, grub2
[07:05] <duflu> jibel, thanks, I should have checked the source since that's the most likely answer
[07:05] <duflu> Hi ji
[07:05] <duflu> Hi jibel
[07:19] <didrocks> good morning
[07:21] <duflu> Morning didrocks
[07:21] <didrocks> hey duflu
[07:58] <willcooke> morning
[07:58] <willcooke> brrrrrr
[07:58] <willcooke> cold today :(
[07:58] <didrocks> hey brrrrrrring willcooke
[08:00] <oSoMoN> good morning desktoppers
[08:00] <duflu> Morning willcooke (now brought?), oSoMoN
[08:02] <Laney> hey ho
[08:03] <willcooke> Could someone help with a version of gdm which includes Ray's fix: https://gitlab.gnome.org/GNOME/gdm/merge_requests/37#note_340480
[08:03] <willcooke> for testing
[08:03] <gitbot> GNOME issue (Merge request) 37 in gdm "WIP! local-display-factory: defer initialization for CanGraphical=no seats" [Opened]
[08:04] <didrocks> salut oSoMoN, hey Laney!
[08:06] <didrocks> willcooke: I have another gdm fix, so if people getting that bug can confirm this fixes for them, I'm happy afterwards to see if as a side-effects, it solves my issue (I had to revert gdm to previous version, as I can't even keep my session running with that gdm issue)
[08:09] <willcooke> didrocks, ack
[08:13] <seb128> duflu, I see you got your reply for grub :)
[08:13] <seb128> hey Laney didrocks willcooke
[08:13] <seb128> how is everyone?
[08:13] <seb128> duflu, I'm ok, did end up getting the baby stomach bug though, started being sick on friday evening :/
[08:13] <seb128> I'm better today though
[08:14] <duflu> seb128, sorry to hear, and now good to hear
[08:14] <willcooke> :(
[08:14] <seb128> didrocks, you got a fix from your gdm bug? nice!
[08:15] <duflu> seb128, I would like to propose a drop in the default grub timeout since it's an easy win of up to 10 seconds faster boots. However I'm confused as to whether 1 second is really any better than 0. Both seem to be OK with quickly pressing Escape
[08:16] <duflu> so recovery still works
[08:16] <seb128> duflu, we do wait for 10s by default? that's only when other OSes are available though?
[08:17] <duflu> seb128, yes all machines. And no none of my machines have other OSes. They all start with wiped disks
[08:17] <seb128> my machines don't stuck at grub for 10s for pretty sure
[08:18] <didrocks> hey seb128! not for my bug, for will's one
[08:18] <duflu> Do they take more than 10s to boot from off to login screen? If so they might be
[08:18] <didrocks> seb128: I'll see if that fixes mine once they confirm it fixes for them (seems quite unrelated, but you never know)
[08:18] <didrocks> seb128: hope that you will stay strong vs stomach bug ;)
[08:19] <seb128> thx
[08:19] <seb128> ah, so it's not another fix
[08:19] <seb128> I parsed wrong what you wrong
[08:19] <seb128> let's see yeah
[08:23] <Laney> hey didrocks seb128 duflu willcooke
[08:23] <willcooke> hihihi all
[08:23] <duflu> Hi Laney
[08:23] <Laney> sup
[08:29] <seb128> it's cold this morning, like 3°C during the night, brrr
[08:34] <seb128> duflu, I would be pretty surprised if all Ubuntu machines were stucked by default in grub for 10s. Mine take longer than that to get to gdm but it goes to plymouth before those 10s afaik, also I've looked at bootcharts and there is no such gap ... or is that recent cosmic regression?
[08:34] <willcooke> I havent seen any 10s waits on my testing
[08:35] <duflu> willcooke, how long is your blank purple screen?
[08:35] <duflu> seb128, I have tried 3-4 laptops with cosmic and they all have the problem
[08:35] <willcooke> duflu, will test
[08:35] <duflu> and all benefit from the fix
[08:35] <seb128> that's a new issue in cosmic?
[08:35] <duflu> Also it seems someone said it is in bionic
[08:35] <duflu> haven't verified
[08:35] <seb128> that doesn't make any sense to me
[08:35] <willcooke> hm
[08:35] <duflu> Maybe so, but still true
[08:36] <seb128> on bionic I would be verify surprised
[08:36] <willcooke> now I come to look at it, there is about 13 seconds of purple
[08:36] <seb128> I didn't pay attention enough to cosmic boot, maybe it's true there
[08:36] <duflu> willcooke, and 3 seconds of kernel, remember :)
[08:37] <duflu> seb128, also note that the grub delay probably doesn't show up in the boot chart. It preceeds the kernel
[08:37] <duflu> Anyway, my laptops were around 20 seconds before and now more like 10 seconds or less
[08:37] <seb128> please open a bug and rls-cc-incoming it so foundations can have a look
[08:38] <willcooke> duflu, can I make a change to the grub config and retest easily
[08:38] <willcooke> ?
[08:38] <duflu> willcooke, /etc/default/grub GRUB_TIMEOUT = 0 and then sudo update-grub
[08:39] <duflu> it will knock your socks off
[08:39] <willcooke> duflu,  I can just put that right at the end of the cfg file right?
[08:39] <willcooke> oh
[08:39] <willcooke> wrong file
[08:39] <willcooke> ignore m,e
[08:39] <willcooke> me
[08:39] <duflu> willcooke, probably edit the line
[08:40] <willcooke> hm, I think it *is* a bit quicker
[08:40] <willcooke> not 10 seconds
[08:40] <willcooke> but maybe 3 or 4
[08:40] <duflu> willcooke, did you remember 'sudo update-grub' ?
[08:41] <willcooke> I did
[08:41] <willcooke> I'll do some better tests
[08:44]  * didrocks starts his laptop and goes to make coffee, so I didn't pay that much attention to the purple screen before plymouth starts
[08:44] <duflu> The blank purple screen mostly indicates the kernel isn't started yet, so that's a performance bug if it lingers
[08:52] <willcooke> Timeout 10: 19,18,24s.  Timeout 0: 9,10,15,9
[08:52] <willcooke> That 15 in the timeout zero was when gdm actually started
[08:52] <willcooke> so yes, it does rather look like there is a 10s wait
[08:52] <willcooke> nice find duflu
[08:53] <duflu> Woo. Although it sounds like someone already found it in bionic
[08:53] <duflu> bug 1784363
[08:53] <duflu> I've never looked at boot charts but would guess they only start when the kernel does
[08:57] <seb128> duflu, that bug claims it's a regression from https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.2 so it wouldn't have been in bionic but due to a SRU
[08:58] <duflu> seb128, maybe. That user doesn't sound completely clear so we would need to check the facts
[08:58] <duflu> Although it doesn't change whether the issue is in cosmic
[08:58] <seb128> http://launchpadlibrarian.net/378957376/grub2_2.02-2ubuntu8.1_2.02-2ubuntu8.2.diff.gz
[08:58] <seb128> -DEFAULT_HIDDEN_TIMEOUT := 0
[08:58] <seb128> that tweaks around those parameters
[08:59] <seb128> so it's possible
[08:59] <seb128> well, it's even more important if it's a SRU regression in bionic
[08:59] <duflu> It looks like there are multiple variables allowing you to change the same thing
[08:59] <seb128> anyway it's tagged, let's wait for foundations to reply
[08:59] <seb128> right
[09:00] <seb128> but if the change made it hit a timeout it wasn't hitting before, then maybe there is a bug in the new variables use
[09:00] <seb128> or a misuse
[09:00] <didrocks> do any of you have a bionic machine with GNOME Boxes installed?
[09:00] <duflu> Yeah sounds like the "timeout" was always 10 seconds. We just accidentally started using that variable recently
[09:01] <didrocks> duflu: this timeout is (IIRC) triggered if you have grub menu displayed and didn't press anything
[09:01] <didrocks> like previous boot failing
[09:01] <didrocks> (but yeah, shouldn't be used if you didn't touch anything ofc)
[09:03] <seb128> what didrocks says
[09:03] <willcooke> duflu, seb128 I've pinged Pat and Steve to see what they say
[09:03] <seb128> willcooke, thx, I was pondering emailing them, good that you beat me to it :)
[09:03] <willcooke> :)
[09:05] <willcooke> I'm an email machine this morning 💪💪
[09:07]  * didrocks boots a live on his secondary laptop to check Boxes on 18.04 thus
[09:07] <seb128> didrocks, I'm not using boxes sorry
[09:07] <didrocks> no worry
[09:07] <seb128> virtualbox here :)
[09:07] <seb128> what's the bug you are looking at?
[09:08] <didrocks> but I think Boxes changed the default for ubuntu to be 1GB
[09:08] <didrocks> the one I added to the iso tracker: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1796037
[09:09] <duflu> Laney, my gjs fix landed already B) If you were still considering an update then maybe also cherry pick?
[09:13] <Laney> duflu: did you want to propose it for cherry picking to the stable branch upstream?
[09:13] <duflu> Laney, yes I can
[09:13] <duflu> it needs to be in cosmic before we finish the gnome-shell leak fix SRU to bionic anyway
[09:25] <duflu> Laney, https://gitlab.gnome.org/GNOME/gjs/merge_requests/238
[09:25] <gitbot> GNOME issue (Merge request) 238 in gjs "context: Defer and therefore batch forced GC runs [performance]" [Opened]
[09:25] <Laney> 👍
[09:26] <didrocks> confirmed, Boxes changed between bionic and cosmic the default RAM size for ubuntu iso
[09:26] <didrocks> (from 2Gb to 1Gb)
[09:27] <Laney> 👎
[09:28] <didrocks> emoji day for Laney ;)
[09:28] <didrocks> I'm going to have a look if this is per-distro, global…
[09:33] <didrocks> ok, it's not BOXES deciding the RAM size, maybe libvirt?
[09:39] <didrocks> hum, can't revert easily libvirt…
[09:41] <seb128> didrocks, it's coming from libvirt?
[09:41] <didrocks> seb128: don't know, it's not coming from Boxes as least…
[09:42] <seb128> didrocks, https://gitlab.gnome.org/GNOME/gnome-boxes/commit/aaef956f6733df30ecf9ab860afc4bda244c4225
[09:42] <seb128> that's old though, maybe changed since
[09:43] <didrocks> seb128: I have installed bionic version on my cosmic install, and it was still 1Gb, let me see if the current code base is similar to what you saw
[09:43] <didrocks> (it might come as well from libosinfo?)
[09:43] <didrocks>     private const int64 DEFAULT_RAM = 2 * (int64) GIBIBYTES;
[09:44] <didrocks> so, something overrides that
[09:44] <seb128> ask teuf?
[09:45] <didrocks> ah, and osinfo-db as well
[09:45] <didrocks> yeah, if reverting those 2 doesn't work, that's my plan ^
[09:47] <didrocks> found!
[09:47] <didrocks> so, it's osinfo-db
[09:47] <didrocks> let's see why now…
[09:50] <didrocks> ok, the regression is in this diff: http://launchpadlibrarian.net/390925704/osinfo-db_0.20180917-1_0.20180929-1.diff.gz
[09:50] <didrocks> between the 17/09 and 29/09
[09:50] <didrocks> should be easy enough :)
[09:50] <willcooke> Nice detective skills didrocks
[09:51] <didrocks> heh, /me takes his magnifying glass to inspect the culpurit :p
[09:51] <didrocks> +        <ram>1073741824</ram>
[09:51] <didrocks> ok, they added support for 18.10 (it was fallbacking to default before I think) and mistyped the ram usage
[09:52] <didrocks> so basically, it's only if starting a cosmic image with very recent osinfo-db
[09:53] <didrocks> hum, 18.04 had the same property, let's try a 18.04 with this version (need to download an iso first)
[09:56] <didrocks> ok, GNOME Boxes on 18.04 hadn't a 18.04 definition, so fallbacked to what seb128 wrote (2Gb)
[09:56] <didrocks> but now, is has one to 1Gb as well
[09:57] <didrocks> so, I wonder, should we bump them to 2Gb? (1.5 is our official minimum, unsure it's tested with this though)
[09:57] <andyrock> anyone willing to take a look at this MR: https://code.launchpad.net/~azzar1/update-manager/lp-1787553-bionic/+merge/354455 ?
[09:57] <didrocks> as before, they were starting with 2Gb
[09:57] <didrocks> and what about 16.04, now that they have snapd, should we change them to 2Gb as well?
[09:57] <didrocks> (as the issue we are seeing in snapd spiking in CPU when going OOM)
[09:58] <didrocks> jibel: seb128: willcooke: Laney ^
[10:00] <jibel> didrocks, 2G is safer. Higher memory consumption started with preseeding of snaps, it made all our automated tests fail. I increased to 1.5 IIRC
[10:00] <willcooke> sounds like a good idea
[10:00] <didrocks> so, fixing 16.04 / 18.04 / 18.10 ?
[10:00] <jibel> yes
[10:00] <didrocks> let me PR that on upstream gitlab
[10:01] <didrocks> I will let until Wednesday and distro-patch if we don't have it merged (but we are currently in sync with debian)
[10:02] <seb128> =pç⁾$
[10:02] <seb128> sorry
[10:02] <seb128> andyrock, I can add to my backlog for a bit later/tomorrow
[10:03] <andyrock> thx!
[10:03] <andyrock> and hey!
[10:03] <seb128> didrocks, yeah, bumping seems fine to me
[10:03] <didrocks> ok, we have aggreement, let's modify our bug, and fix it upstream ;)
[10:04] <didrocks> if this is merged quickly, I'll request a new snapshot in debian + sync
[10:17] <didrocks> any idea why I can't create a MR against libosinfo/osinfo-db on gitlab? I have the list of all other fork, but not the main repo…
[10:19] <Laney> it looks like the project has turned those off (that's an option)
[10:20] <Laney> the readme says to use https://www.redhat.com/mailman/listinfo/libosinfo
[10:20] <didrocks> ah…
[10:20] <didrocks> thanks Laney!
[10:20] <Laney> retro
[10:20] <didrocks> yep
[10:20] <didrocks> I was looking for a CONTRIBUTING.md
[10:21] <didrocks> didn't think about reading the README for this :p
[10:21] <didrocks> thanks ;)
[10:54] <willcooke> tjaalton, hiya - is there any update on the virtualbox issue atm?
[10:55] <tjaalton> willcooke: nope
[10:55] <CarlenWhite> Really wished we had more laptops with extra HDD slots. Wouldn't mind dedicating one to Windows and one to Ubuntu instead of the current tight-ship setup on a 256GB SSD.
[10:55] <tjaalton> filed it upstream, the new patch has been dropped from xserver 1.20.2 queue for now until it's known where the bug is
[10:56] <willcooke> tjaalton, ack.  So we're back to where we were, needing nomodeset for vbox?
[10:56] <tjaalton> if that's the route yes
[10:57] <willcooke> tjaalton, ok.  And is "getting it fixed for release" something which you're actively working on? Like, do I need to formally ask for it to be a priority?
[10:58] <tjaalton> I'd like to know why plymouth starts "too early" now, showing ugly "server splash" instead of the proper thing on these
[10:58] <tjaalton> fixing that race would solve most of the issues
[11:00] <willcooke> tjaalton, is there a bug open for that?
[11:01] <tjaalton> no, all the bugs are for x
[11:01] <willcooke> tjaalton, would you mind opening one, and I can chase up with Foundations?
[11:01] <tjaalton> sure
[11:01] <willcooke> thank you!
[12:05] <Laney> willcooke: did you want to test https://people.canonical.com/~laney/package-junkyard/ ?
[12:21] <willcooke> Laney, word
[12:22] <Laney> brap
[12:30] <willcooke> anyone interested in sponsoring this fix for SRUing to Bionic?  https://bugs.launchpad.net/ubuntu/+source/guake/+bug/1760621
[12:30] <willcooke> patch attached by all accounts
[12:33] <willcooke> nope, there isnt,
[12:33] <willcooke> but I could make one if anyone cares
[12:33] <willcooke> https://github.com/Guake/guake/commit/f8699b4be6c058fd58a33a1d783cd404e9076b0e
[12:34] <willcooke> Laney, hrm.  Installed those packages, but I can't even get a text tty up anymore.  Investigating
[12:53] <willcooke> Laney, Feels the same to me, still getting  a black screeen with the text cursor just as often as gdm
[12:53] <willcooke> will make logs
[12:54] <Laney> k, post them on the MR, you should at least see debugging output from the new stuff
[12:54] <willcooke> ack
[12:54] <willcooke> and yeah, sometimes I dont even get a text tty anymore (probably related)
[13:02] <willcooke> Laney, just to confirm - I only needed to install the debs and not the ddebs too?
[13:02] <Laney> right
[13:02] <willcooke> ta
[13:02] <Laney> you don't need them but if you had them already you'll probably get an error from dpkg if you don't install those too
[13:03] <Laney> I usually do dpkg -iO *deb
[13:03] <willcooke> I'll redo that, just in case
[13:04] <willcooke> I did -dpkg -i * (having only downloaded the debs, but maybe I did someting daft)
[13:35] <Laney> Oct 08 13:55:33 test-Inspiron-3137 gnome-shell[739]: Failed to create backend: Could not find a primary drm kms device
[13:45] <willcooke> Laney, looking at Ray's most recent comment (just a moment ago) - could this be related to Plymouth?  Where something goes from suitable  -> unsuitable -> suitable again?
[13:49] <Laney> willcooke: I dunno, maybe? You could remove it from the kernel cmdline if you wanted to play with that theory
[13:50] <willcooke> Laney, is it the "splash" option?
[13:50] <Laney> quiet splach
[13:51] <Laney> s
[13:51] <willcooke> ack
[13:51] <Laney> but probably get what he's asking for first
[13:51] <willcooke> roger
[13:53] <tjaalton> willcooke: on an uptodate cosmic I see that vboxvideo is loaded early enough after install, there's no race and things work fine
[13:53] <willcooke> tjaalton, oki, lemme try that again
[13:53] <tjaalton> bionic host
[13:54] <willcooke> ack
[13:56] <didrocks> jibel: willcooke: so, on libosinfo, they would like to match the recommended to what we say (4Gb). The issue is that GNOME Boxes will use this by default instead of the minimal
[13:56] <didrocks> I think it's fine, just want another opinion before changing it
[14:03] <jbicha> didrocks: osinfo-db is a bit complicated
[14:04] <didrocks> yeah, it's not only for VM I guess
[14:07] <jbicha> I'm not aware of it being used outsides vms
[14:07] <didrocks> so, I wonder, but seems like they really want the recommended to be set to our wiki page that willcooke edited https://help.ubuntu.com/community/Installation/SystemRequirements?action=diff&rev2=108&rev1=107
[14:07] <jbicha> I think generally the people who maintained Boxes and the osinfo stuff all these years don't really use Ubuntu
[14:08] <jbicha> currently, the same RAM value is used for both the server and desktop editions of Ubuntu
[14:08] <didrocks> willcooke: either we changed on the wiki the recommended Mem to be 4Gb or I change in libosinfo-db, but that means that VM will request 4Gb by default
[14:08] <didrocks> yeah
[14:08] <jbicha> I agree that 4 GB is a ridiculous default for a VM
[14:09] <didrocks> jbicha: want to chat on the ML?
[14:09] <didrocks> maybe having a second opinion will help there
[14:09] <jbicha> yeah I'll comment there
[14:10] <didrocks> thx! still waiting for willcooke/jibel though when they are aroudn
[14:10] <didrocks> around*
[14:12] <jbicha> Boxes/osinfo-db have several papercut issues for Ubuntu
[14:12] <willcooke> meeting
[14:12] <willcooke> reading
[14:13] <jbicha> I'm glad that osinfo-db is a separate package now since it makes it easier to SRU it. we should do an SRU after 18.10's release to include 18.10's info
[14:13] <willcooke> I think it's totally fine to have a difference between "What we recommend for everyone" and "What the default is for a VM"
[14:14] <willcooke> but I might be wrong
[14:14] <willcooke> 4GB for a VM feels to high to me, 2GB seems OK
[14:14] <willcooke> whereas 4GB for a hardware install as a recommendation seems OK to me
[14:15] <didrocks> willcooke: the issue right now is that Boxes is using the "recommended" field and upstream seems to think that they want to align the recommended with what we have in our wiki page
[14:15] <didrocks> willcooke: or… what we could do… Have 4Gb recommended for a daily usage
[14:15] <didrocks> and recommend 2Gb for a VM
[14:15] <willcooke> didrocks, cunning!
[14:15] <didrocks> (like with few browser activity)
[14:15] <willcooke> I like it
[14:15] <didrocks> willcooke: do you mind editing the wiki page with those info?
[14:15] <didrocks> so that it's official :)
[14:15] <willcooke> stand by
[14:16] <didrocks> and I can link by on the mailing list as a reference point :)
[14:18] <willcooke> didrocks, done
[14:19] <didrocks> willcooke: perfect! :)
[14:19] <didrocks> thx, forwarding :)
[14:20] <willcooke> thanks didrocks
[14:20] <willcooke> Laney, 10 out of 10 working boots when removing quiet splash :/
[14:22] <Laney> fun
[14:22] <Laney> that last journal has permission errors in it
[14:22] <Laney> e.g. Oct 08 14:53:19 test-Inspiron-3137 gdm-launch-environment][805]: GdmSessionWorker: could not take control of tty: Operation not permitted
[14:22]  * ricotz hopes this bug gets some real attention https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/1795901
[14:22] <Laney> ricotz: #ubuntu-hardened
[14:23] <ricotz> ok
[14:26] <ricotz> Laney, I assume there was some discussion there already?
[14:26] <Laney> I don't know, sorry, I'm not in that one
[14:26] <ricotz> I see, I am making more noise then ;)
[14:37] <willcooke> Laney, pasted a new one with sudo
[14:55] <Laney> willcooke: want to come to #gdm?
[14:55] <Laney> might be faster
[15:57] <seb128> good afternoon desktopers
[15:57] <didrocks> wb seb128
[15:57] <seb128> thx
[15:57] <Laney> yo
[15:58] <Laney> good trip?
[16:00] <oSoMoN> hey seb128
[16:00] <seb128> yeah, pretty fine, a bit of traffic because we left a bit late
[16:04] <willcooke> hey seb128
[16:04] <seb128> ricotz, did you mention the webkitgtk issue on the security channel (they don't have irclogs so I can't look there)?
[16:06] <ricotz> seb128, I did and marc answered
[16:06] <seb128> good
[16:06] <seb128> thx
[16:07] <oSoMoN> anyone fancy reviewing https://code.launchpad.net/~osomon/ubiquity-slideshow-ubuntu/libreoffice-icons-update/+merge/356186 ?
[16:07] <ricotz> seb128, still a bit problematic that this went through without testing
[16:08] <ricotz> or at least insufficient testing
[16:13] <seb128> ricotz, did he comment about that? I expect they do test runtime but not rdepends builds (which they probably should)
[16:15] <didrocks> didrocks@casanier:/tmp$ mkdir foo
[16:15] <didrocks> mkdir: impossible de créer le répertoire «foo»: Le fichier existe
[16:15] <didrocks> didrocks@casanier:/tmp$ mkdir bar
[16:15] <didrocks> mkdir: impossible de créer le répertoire «bar»: Le fichier existe
[16:15] <didrocks> seriously… :p
[16:15]  * didrocks will stop using /tmp and temp names :p
[16:15] <ricotz> seb128, no, he just asked the report
[16:16] <ricotz> *ack'ed
[16:16] <seb128> didrocks, :)
[16:16] <seb128> ricotz, k
[16:16] <seb128> oSoMoN, I can have a look if noone picks it up
[16:16] <seb128> but let me deal with some other backlog first
[16:17] <didrocks> oSoMoN: merged
[16:18] <didrocks> seb128: FYI ^
[16:18] <seb128> didrocks, thx, can you handle the upload as well?
[16:18] <didrocks> seb128: not today, but tomorrow, sure
[16:18] <seb128> k, I might do it today
[16:18] <seb128> check the queue tomorrow before doing it :p
[16:18] <didrocks> hum, actually it's the only change
[16:19] <didrocks> so easy enough to upload, let me do it
[16:19] <seb128> right
[16:19] <seb128> thx!
[16:20] <didrocks> yw
[16:23] <oSoMoN> thanks didrocks
[16:24] <didrocks> (done)
[16:24] <oSoMoN> cheers
[16:24] <Laney> oSoMoN: are you handling thunderbird or just firefox atm?
[16:24] <oSoMoN> didrocks, have you tried /tmp/baz ?
[16:25] <oSoMoN> Laney, just firefox, one step at a time!
[16:25] <Laney> ok
[16:25] <Laney> in that case
[16:25] <Laney> chrisccoulson: is xnox's sync of thunderbird from bionic to cosmic something you approve of?
[16:26] <chrisccoulson> Laney, it doesn't matter, because it's about to get replaced by 60.2.1
[16:26] <Laney> presumably that's a sync with binaries, not sure I like it on those grounds anyway
[16:26] <Laney> oho
[16:26] <seb128> chrisccoulson, including cosmic? ;)
[16:26] <chrisccoulson> yeah
[16:26] <Laney> if that includes cosmic then I can just reject this one pasting that message
[16:26] <seb128> \o/
[16:27] <Laney> happy days
[16:27]  * Laney is being forcefully moved on from this room :(
[16:27] <Laney> brb :(
[16:30] <seb128> :(
[16:32] <didrocks> oSoMoN: I was mkdiring it, but ended up with ba2 :p
[16:36] <jbicha> ricotz: could you look into https://launchpad.net/ubuntu/+source/vala/0.42.2-1/+latestbuild/ppc64el ?
[16:37] <jbicha> previously, debian/rules was setting -O1 for vala so that's why this just started failing now (Ubuntu's ppc64el uses -O3 by default)
[16:43] <xnox> Laney, chrisccoulson - my copy-package request was with binaries.
[16:44] <xnox> which got rejected
[16:44] <Laney> 😈
[16:44] <xnox> interesting that i got no email about that
[16:44]  * xnox ponders if rejects of syncs go to /dev/null
[16:44] <xnox> or maybe to the actual uploader, rather than the sync requestor?
[16:45] <Laney> I remember that emailing around copies is weird in some way or other
[16:45] <Laney> probably that the copier just doesn't get them in some cases
[16:45] <Laney> like when you sync something into a queue, no email
[16:48] <ricotz> jbicha, noted
[17:11] <jbicha> seb128: there are a bunch of apps that we opted into language packs (so the translations are stripped) but aren't actually marked for translation
[17:11] <jbicha> one example is swell-foop https://translations.launchpad.net/ubuntu/cosmic/+imports?field.filter_extension=all&field.filter_status=NEEDS_REVIEW&batch=75&direction=backwards&memo=21000&start=21000
[17:11] <jbicha> https://translations.launchpad.net/ubuntu/+source/swell-foop
[17:12] <seb128> jbicha, do you have a full list? I tried to reviewed the .pot queue and accept them but it was noisy
[17:13] <jbicha> I don't have a list but I guess I could make one
[17:14] <jbicha> when are lang packs supposed to be generated this week?
[17:15] <seb128> not sure but the date on the cycle schedule is 11th
[17:16] <seb128> so I guess on friday
[17:16] <jbicha> do you know when the automatic langpack update is supposed to happen?
[17:20] <seb128> https://dev.launchpad.net/Translations/LanguagePackSchedule has been updated for cosmic
[17:20] <seb128> let me check on the machine
[17:21] <seb128> Wednesday
[17:21] <seb128> that's day 3 in cron right?
[17:23] <jbicha> yes
[17:27] <willcooke> night all
[17:33] <jbicha> seb128: ok, it's just a few: https://paste.debian.net/1046391/
[19:03] <ricotz> jbicha, could you test a patch for the -O3 failure on ppc64?
[19:08] <ricotz> jbicha, https://paste.debian.net/plain/1046407
[19:33] <jbicha> ricotz: I guess I didn't handle the bootstrap stuff right
[19:33] <jbicha> https://launchpadlibrarian.net/392324819/buildlog_ubuntu-cosmic-amd64.vala_0.42.2-1ubuntu0.1_BUILDING.txt.gz
[19:43] <ricotz> jbicha, yeah, still not that easy
[19:46] <jbicha> ricotz: why don't we just set -O2 since that's the default everywhere else? that gives you more time to work on it without the 18.10 release so soon
[19:48] <ricotz> jbicha, that would be fine
[19:49] <ricotz> I am wondering if there are ppc64 failure of rdepends caused by that already
[19:50] <jbicha> it's not built on Ubuntu's ppc64el yet so I wouldn't think so
[19:51] <ricotz> make check is what is failing, so if any vala based application is built on ppc64 it would fail if it used an specific syntax
[19:51] <seb128> jbicha, thanks, I review/approved gnome-robots, the other ones didn't build a template
[19:52] <seb128> jbicha,    dh_translations
[19:52] <seb128> dh_translations: more than one meson translation domain found (polari,help-org.gnome.Polari), don't know which one to use
[19:52] <seb128> same for gnome-recipies
[19:52] <seb128> unsure what's the issue with gnome-contacts, the log has no error/success output
[19:58] <jbicha> never mind about gnome-contacts. It was only done in Debian not Ubuntu yet because of bug 1791489
[19:59] <jbicha> I'll go ahead and fix up gnome-robots and polari packaging so we can try those again tomorrow
[19:59] <jbicha> currently, those 2 have their translations stripped so they need to be fixed one way or another
[20:11] <seb128> jbicha, gnome-recipies not gnome-robots
[20:12] <seb128> jbicha, seems like gnome-contacts got stalled missing a reply/is going to miss this cycle?
[20:14] <jbicha> Release Team wanted us to add symlinks to the faenza icon themes
[20:21] <seb128> that looked like a minor point/easy to workaround
[20:22] <seb128> that seems a weird request though
[20:24] <jbicha> that's why it's nicer to get new versions in before Feature Freeze, less paperwork and such :)
[21:35] <GunnarHj> Hey jbicha, saw your bug comment about polari. Isn't that a case where the --domain option would help?
[21:40] <jbicha> I guess so but I think upstream may take my patch
[21:41] <jbicha> GunnarHj: is this still the best way to handle things? https://salsa.debian.org/gnome-team/libgweather/blob/debian/master/debian/rules#L35-40
[21:43] <jbicha> I found another project with 2 pots today (gnome-recipes)
[21:45] <GunnarHj> jbicha: I think this makes more sense in the libgweather case:
[21:45] <GunnarHj> override_dh_translations:
[21:45] <GunnarHj> 	dh_translations --domain=libgweather-3.0
[21:45] <GunnarHj> 	ninja -C obj-$(DEB_HOST_GNU_TYPE) libgweather-locations-pot
[21:56] <GunnarHj> jbicha: That way it would deal with possible .desktop, .policy, etc. files correctly (I don't know if there are any, though).
[21:58] <jbicha> well recipes definitely has a .desktop :)
[21:58] <GunnarHj> Ok.
[22:04] <GunnarHj> jbicha: On another topic: Were you aware off this yelp translation issue?
[22:05] <GunnarHj> https://bugs.launchpad.net/ubuntu-translations/+bug/1796747/comments/1
[22:07] <jbicha> I saw it, I was hoping Seb would see it tomorrow
[22:07] <jbicha> (I'm still subscribed to yelp bugs but not ubuntu-translations bugs)
[22:08] <GunnarHj> jbicha: Ok. I suspect that he may already have edited the LP template; let's see tomorrow.
[22:12] <jbicha> kenvandine: I broke your gnome-calculator snap auto build, master wants libgtksourceview-4-dev
[22:23] <jbicha> hmm, gnome-recipes is tricky too :)
[22:36] <GunnarHj> jbicha: Looks similar to libgweather. Using --domain=gnome-recipes and a separate ninja() call for gnome-recipes-data-pot ought to work. But it's a universe package, and there are no LP templates yet..
[22:38] <jbicha> yeah, different problem
[22:42] <GunnarHj> jbicha: I think that the first step is to upload with translation stripping. Then, when the POTs are in the import queue, someone has to approve manually and with that create the templates.
[22:51] <jbicha> GunnarHj: https://paste.debian.net/1046427/
[22:52] <jbicha> src/ingredients.inc is a generated file (that's pretty unusual for translating)
[22:53] <jbicha> I tried a few different things but I think I'm just doing to turn off langpacks for gnome-recipes for cosmic
[22:56] <maddawg2> question...  i have a service that is failing to start preventing me from booting my machine... is there like a "safe mode" equivalent for ubuntu that would allow me to start without running any of the autostart services at boot and then allow me to remove the package in question
[23:11] <GunnarHj> jbicha: Yeah, that looks messy. Probably wise to wait til next cycle.
[23:14] <jbicha> I opened https://github.com/mesonbuild/meson/issues/4353
[23:14] <gitbot> mesonbuild issue 4353 in meson "pot command can't find generated file" [Open]
[23:14] <jbicha> https://l10n.gnome.org/module/recipes/ has a .pot but maybe they don't use meson to build it
[23:20] <GunnarHj> jbicha: That's a plausible assumption.
[23:22] <GunnarHj> maddawg2: Yes there is. I think it's possible to edit the grub entry, but I don't remember how. Please note that this is not a support forum; I'd recommend that you try e.g. https://askubuntu.com