[02:47] <hellsworth> ricotz, yep it looks like gnome-calculator-master builds with vala 0.40.8 since that's what the valac deb is in 18.04
[02:50] <hellsworth> we're working some kinks out with the extensions newer than gnome-3-28. Once gnome-3-34 extension is ready to be widely used, gnome-calculator will build with 0.46
[03:11] <hellsworth> marcustomlinson: kenvandine , i built the build snap with the invalid-free-crash branch (to test https://gitlab.freedesktop.org/cairo/cairo/issues/382#note_278108), put it in edge, rebuilt the platform snap, put it in stable, and rebuilt evince. it still segfaults when it opens a pdf.
[03:46] <hellsworth> marcustomlinson: kenvandine the build snap in edge and platform snap in stable were built with the invalid-free-crash. i'm going to leave these in the store and it would be interesting if one of you could test evince or drawing or something with them to see if you still see a segfault
[03:47] <hellsworth> afterwards, we can build the build snap with cairo source-tag: 1.16.0, and platform snap, and put those in the store
[03:52] <hellsworth> i didn't comment on https://gitlab.freedesktop.org/cairo/cairo/issues/382#note_278108 because i'm having an issue registering an account on gitlab.freedesktop.org
[06:06] <marcustomlinson> hellsworth: thanks, I’ll give it a try and leave a comment on the bug when I wake up in a couple hours :P
[07:18] <oSoMoN> good morning desktoppers!
[07:24] <duflu> Morning oSoMoN (and marcustomlinson and didrocks?)
[07:25] <oSoMoN> hey duflu
[07:26] <oSoMoN> salut didrocks, hey marcustomlinson
[07:32] <didrocks> good morning duflu, oSoMoN, marcustomlinson!
[07:33] <didrocks> forgot to press "enter" on my good morning ;)
[07:46] <RikMills> morning
[07:47] <RikMills> ah, wrong channel but still valid :P
[07:50] <didrocks> good morning RikMills
[08:08] <marcustomlinson> morning oSoMoN duflu didrocks
[08:09] <seb128> gooood morning desktopers
[08:11] <marcustomlinson> hey seb128
[08:11] <seb128> hey marcustomlinson, how are you today? you are online earlier than usual?
[08:11] <duflu> Hi seb128, how goes?
[08:11] <seb128> hey duflu, good! and you?
[08:12] <seb128> I see you are quite busy with bug triage recently
[08:12] <marcustomlinson> seb128: I'm alright thanks, was eager to test something :) Hw you?
[08:12] <duflu> seb128, OK... Yeah, I'm trying to estimate if it's a busy release or not
[08:12] <seb128> seems low traffice/no much high profile bugs atm from what I saw
[08:12] <seb128> do you have the same impression?
[08:14] <duflu> seb128, yes for sure about the lack of showstoppers
[08:14] <duflu> Bugs like the HDMI audio switching are among the busiest
[08:15] <duflu> Hmm, there's a simple way to check and I haven't yet
[08:15] <seb128> that one is annoying, I wonder if we should just put back the code to ignore HDMI in the dynamic switcher
[08:15] <didrocks> hey seb128
[08:15] <seb128> lut didrocks, en forme ?
[08:16] <duflu> seb128, I was considering reverting the commit that upstream say caused it, but currently am more likely to wait for them to decide
[08:16] <didrocks> seb128: ça va, et toi ?
[08:18] <seb128> duflu, right
[08:18] <duflu> seb128, Ha! Yes my guesses were right - https://bugs.launchpad.net/ubuntu/eoan/+bugs?orderby=-heat&start=0
[08:18] <seb128> didrocks, ça va !
[08:45] <oSoMoN> salut seb128
[08:46] <seb128> oSoMoN, lut, en forme?
[08:47] <oSoMoN> seb128, ça va, et toi?
[08:47] <seb128> oSoMoN, ça va bien !
[09:01] <didrocks> sil2100: RAOF: hey! Just confirmed the 2 use cases are fixed for bug #1850052 (new and previous install) with zsys in -proposed. As previous version prevents people from log in, what do you think about bypassing the retention period?
[09:03] <Laney> sup
[09:03] <RAOF> didrocks: 20:00 here, so I'll let sil2100 take that!
[09:04] <didrocks> RAOF: no worry, have a good evening :)
[09:04] <didrocks> hey Laney
[09:04] <seb128> hey Laney
[09:04] <didrocks> RAOF: and thanks for acking it in -propsoed
[09:05] <RAOF> I'm always happy to deal with SRU pings!
[09:05] <didrocks> :)
[09:08] <sil2100> RAOF: o/
[09:08] <sil2100> didrocks: hey, oh! Ok, let me take a look
[09:09] <didrocks> thx ;)
[09:20] <didrocks> sil2100: thanks a bunch! :)
[09:22] <sil2100> didrocks: yw!
[09:23] <duflu> And I killed gitlab
[09:23] <duflu> or something did
[09:33] <marcustomlinson> sil2100: now that you're here ;) could I please ask you to have a look at libreoffice in the disco queue?
[10:07] <sil2100> marcustomlinson: hey! Will try to get to that, but since today is not my SRU shift I might not be able to find enough cycles
[10:21] <jibel> Laney, how did you update the translations of ubiquity to add new strings?
[10:23] <Laney> I forgot already
[10:23] <Laney> debconf-updatepo was it?
[10:24] <jibel> it does something, not sure it's the right thing
[10:25] <didrocks> I guess that was it, indeed
[10:44] <Wimpress> Monring desktoppers o/
[10:45] <seb128> hey Wimpress, how are you today?
[10:47] <didrocks> hey Wimpress
[11:43] <tseliot> Laney, seb128 can we have somebody with systemd knowledge have a look at LP: #1845801, please? (see my comment in the bug report)
[11:53] <Laney> tseliot: ah, wtf, good find
[12:06] <seb128> tseliot, thx
[12:06] <tseliot> yw
[12:09] <Laney> rbalint: don't suppose you have any idea about the above?
[12:10] <Laney> I don't know what paused for a drm device node means
[12:12] <rbalint> Laney, i took a look but it seems nvidia driver related
[12:12] <Laney> :/
[12:12]  * Laney wibbles
[12:13] <rbalint> Laney, not that i don't have other problems with my nvidia card, but they are not related :-)
[12:16] <Laney> right
[12:16] <Laney> not entirely sure how best to move forward
[12:29] <rbalint> Laney, suggested trying systemd 243 from a ppa i already have, but to triage i need to assemble a system from the nvidia card - or fix gpu passthrough which freezes my systemd atm (bug to be filed)
[12:30] <Laney> :O
[12:30] <Laney> xnox had that working at the release sprint
[12:30] <Laney> thanks for the suggestion there
[12:31] <rbalint> Laney, what worked? gpu passthrough?
[12:31] <Laney> yeah
[12:31] <rbalint> Laney, in my case it is external tb3 gpu case on bionic host and disco guest
[12:32] <rbalint> Laney, i imagine xnox had it working on eoan host
[12:33] <Laney> indeed
[12:33] <rbalint> Laney, and maybe without tb2
[12:33] <rbalint> tb3
[12:33] <Laney> it was prime iirc
[12:35] <rbalint> Laney, that's also cool, but a different way
[12:36] <Laney> nod
[12:53] <Wimpress> seb128 didrocks Head down trying to ctach up on stuff today. Sorry for not replying ealier.
[13:01] <didrocks> nw!
[13:03] <seb128> Wimpress, no worry, busy is good :)
[13:23] <kenvandine> marcustomlinson: i see the same weirdness in the headerbar when using cairo 1.17 with that crash fix
[13:23] <kenvandine> marcustomlinson: in drawing
[13:23] <kenvandine> definately better in 1.16
[13:23] <marcustomlinson> kenvandine: alright, so that's definitely a separate issue then
[13:23] <kenvandine> yeah
[13:23] <marcustomlinson> thanks
[13:24] <kenvandine> that PR does fix the crash though
[13:24] <kenvandine> marcustomlinson: i also don't see the window controls
[13:30] <marcustomlinson> kenvandine: perhaps we call off upgrading to 1.17 until possibly the next sdk pair
[13:30] <kenvandine> yeah
[13:30] <kenvandine> marcustomlinson: i suspect nobody has updated to that yet :)
[13:30] <kenvandine> this bug seems to effect everything!
[13:31] <kenvandine> the crasher that is... and the PR with the fix has been sitting for 8 months
[13:31] <marcustomlinson> yeah that's why I thought that guy could use the help with some confirmation from us
[13:32] <kenvandine> yup
[13:33] <marcustomlinson> kenvandine: it's all bryce's fault ;)
[13:33] <kenvandine> :)
[13:33] <kenvandine> in this case it is :)
[13:35] <kenvandine> marcustomlinson: and looking at that PR, I bet this is the cause for those weird issues in the headerbar
[13:36] <kenvandine> related to clipping boxes
[13:37] <kenvandine> and what i saw on the headerbar looks like boxes that overrun a bit
[13:37] <marcustomlinson> kenvandine: ah so probably not unrelated, I'd not looked at the PR admittedly
[13:38] <kenvandine> marcustomlinson: yeah, it's a code path that wasn't being handled before
[13:38] <kenvandine> so he fixed that
[13:38] <kenvandine> but something's not right
[13:39] <marcustomlinson> well I brought it up, we'll see if he has something to say about it
[13:39] <kenvandine> clobrano: hey, i'm seeing a theme issue in the drawing snap.  Specifically the headerbar when using yaru.  yaru-dark and yaru-light are both fine
[13:39] <kenvandine> marcustomlinson: thanks
[13:39] <kenvandine> clobrano: https://usercontent.irccloud-cdn.com/file/7MHfIVC8/drawing_theme_issue.png
[13:40] <kenvandine> clobrano: the drawing snap is being built with the latest gtk and other bits
[13:40] <kenvandine> clobrano: if you look really close at that screenshot there is a subtle gear in the background of the headerbar towards the right hand side
[13:50] <Laney> that bryce bug is still there?????
[13:52] <Laney> is something actually wanting 1.17?
[13:52] <Laney> the archive still doesn't have it
[13:56] <marcustomlinson> Laney: nobody's requesting it no, we were just giving it a go in the gnome platform snap
[13:57] <Laney> nod
[13:57] <Laney> I think that's why we never bothered upgrading
[14:39] <jibel> didrocks, when you have some time later this week https://code.launchpad.net/~jibel/ubiquity/+git/ubiquity-1/+merge/374920
[14:39] <jibel> it's the new design for advanced features
[14:47] <didrocks> jibel: thx! I'll have a look (probably tomorrow)
[15:33] <hellsworth> morning folks
[15:33] <hellsworth> marcustomlinson: what is the state of the build and platform snaps in the store?
[15:34] <hellsworth> were they built with the invalid-free-crash or 1.16?
[15:34] <hellsworth> oh i can go look up the commits. nvm
[15:34] <marcustomlinson> hellsworth: for 3-32?
[15:34] <hellsworth> oh i meant for 3-34
[15:35] <marcustomlinson> hellsworth: I'm not sure the state of that
[15:35] <hellsworth> marcustomlinson: it looks like gnome-3-34-1804-sdk in edge is built with cairo source-tag: 1.16.0 (based on the commit)
[15:35] <hellsworth> can't tell on the platform snap though
[15:36] <hellsworth> i think the evince crash is different from the drawing/epiphany crash
[15:37] <hellsworth> marcustomlinson: is it worth it for me to build/push the invalid-free-crash to the store to test epiphany? it looks like you and kenvandine have already come to the same conclusion..
[15:38] <marcustomlinson> hellsworth: no don't bother, we've investigated enough there
[15:38] <marcustomlinson> thanks
[15:38] <oSoMoN> good morning hellsworth
[15:38] <hellsworth> ok that's what i thought
[15:38] <hellsworth> good morning oSoMoN !
[15:38] <marcustomlinson> we're gonna hold off upgrading to 1.17 until possibly the next round of sdk snaps
[15:38] <hellsworth> yes that sounds like a solid plan
[15:40] <hellsworth> i'll assume that both gnome-3-34-1804-sdk and gnome-3-34-1804 in the store are built with 1.16, and retry evince in case it's related with cairo. honestly, evince could be crashing due to any of the build snap updates.
[15:44] <Laney> forget 1.17 imho
[15:51] <seb128> Laney, do you know offhand of an easy wait to make gsd displays g_debug entries? hacking the systemd unit to add --debug?
[15:51] <seb128> or is there an easier way?
[15:52] <Laney> if it were me I'd do
[15:52] <Laney> systemctl --user edit gsd-whatever.service
[15:52] <Laney> [Service]
[15:52] <Laney> Envirionment=G_MESSAGES_DEBUG=all
[15:52] <Laney> (with correct spelling)
[15:53] <Laney> (--runtime if you don't want it to persist)
[15:53] <Laney> then restart the unit
[15:55] <seb128> Laney, thx, I didn't know about systemctl edit, handy :)
[15:56] <Laney> yeah, no need to hack units in /usr most of the time
[15:56] <Laney> if you do systemctl --user edit --full whatever.unit then you get the whole thing to edit too
[15:57] <seb128> right, I'm reading about it now, it surprised first because I was expecting edit to give a copy you can edit :)
[15:58] <Laney> :>
[15:58] <Laney> it's like an overlay
[15:58] <Laney> systemd calls them drop-ins
[16:54]  * Laney frowns
[16:55] <Laney> I had an old todo to fix up a merge request
[16:55] <Laney> and now I can't remember what I wanted to fix :(
[16:59] <marcustomlinson> fix it all!
[17:01] <didrocks> unless you didn't even note what MP to fix… ;)
[17:01] <Laney> heh
[17:01] <Laney> nah I have the commits I wrote back then
[17:01] <Laney> but now they look finished to me ...
[17:34] <jdstrand> kenvandine: if you recall I was asking about theming issue with firefox on wayland after eoan upgrade. it wasn't wayland specific. firefox forgot Custom/Title Bar for that profile. so feel free to forget this whole conversation :)
[17:40] <kenvandine> jdstrand: ok :)
[17:41] <hellsworth> kenvandine: glimpse snap support was just merged! so should i put this in the store under my name and then we move it to being from ubuntu-desktop?
[17:41] <kenvandine> hellsworth: sure
[17:41] <kenvandine> hellsworth: even better would be if upstream published it
[17:43] <hellsworth> hmm ok then i'll see about coaching them on that
[17:44] <kenvandine> popey could probably help
[17:44] <kenvandine> hellsworth: since the yaml is upstream they could use build.snapcraft.io
[17:46]  * hellsworth looks for steps on the docs about build.snapcraft.io
[17:46] <popey> Is it on GitHub?
[17:47] <popey> Glimpse that is
[17:47] <hellsworth> yes
[17:47] <hellsworth> https://github.com/glimpse-editor/Glimpse/blob/dev-g210/snap/snapcraft.yaml
[17:47] <popey> Neat
[17:48] <popey> Someone from the upstream team should sign up for a store account and then goto build to hook it all up
[17:49] <popey> diddledan: ^
[17:51] <hellsworth> upstream doesn't want to maintain the snap
[17:51] <hellsworth> they are happy to carry the snap/snapcraft.yaml though
[17:52] <kenvandine> ok, then probably snapcrafters
[17:52] <kenvandine> popey ^^ right?
[17:52] <hellsworth> i'm checking to see if the contributor of the snap packaging would be willing to submit it to the store
[17:52] <hellsworth> if not then we can go with snapcrafters. what is the proces for that?
[17:53] <hellsworth> also if this convo should be moed to #snap-advocacy, we can do that..
[18:08] <diddledan> I imagine the glimpse yaml is largely the same as gimp's which I maintain
[18:09] <hellsworth> yep
[18:09] <hellsworth> minor differences
[18:26] <popey> hellsworth: yes, we can put it under snapcrafters (like gimp is)
[18:39] <hellsworth> popey: should we encourage the contributor to submit it to snapcrafters?
[18:39] <popey> Well, it's a bit tricky now the yaml is in the upstream project
[18:40] <popey> can we discuss this in the desktop call on monday maybe?
[18:40] <hellsworth> yeah i thought the upstream project was willing to support the snap packaging going forward
[18:40] <hellsworth> there's a desktop call on monday?
[18:40] <popey> We might be able to do it with a travis.yml
[18:40] <popey> there was between snap advocacy and will / ken.
[18:41] <popey> maybe it needs to change now the structure has changed a bit
[18:47] <popey> there's another couple of snaps which don't have out-of-tree snapcraft.yamls which I need to work on, may be able to re-use that work for glimpse
[18:49] <hellsworth> sure. what would the result of that work be? moving the glimpse upstream snap/ to snapcrafters?
[18:56] <popey> no, a travis.yaml in a repo in snapcrafters which periodically grabs the glimpse repo and then runs snapcraft on it
[18:56] <popey> effectively
[18:56] <popey> the downside is if we need to fix the snapcraft.yaml we have to wait for upstream to land those fixes
[18:57] <popey> whereas traditional out of tree snapcraft yamls we can ninja (and often do) in snapcrafters repo
[18:57] <popey> but i reckon we can cope
[18:58] <popey> we can from within travis, use the snapcraft remote-build option to fire it over to launchpad to build
[18:58] <popey> travis would just be used to manage the job
[19:05] <hellsworth> popey: if we were to move the glimpse snap packaging info over to snapcrafters (and remove it from upstream source), would a new snap be automatically built on upstream master commit?
[19:06] <popey> hm, we can make that happen
[19:07] <hellsworth> it sounds like if we leave the snap packaging in upstream glimpse, and add a travis.yaml to snapcrafters, then that just periodically builds/pushes a new snap to the store - not based on upstream commit, but rather more of a cron job
[19:07] <hellsworth> which is better?
[19:07] <hellsworth> the glimpse team is pretty fine with whatever we think is best
[19:07] <popey> depends who'd use the edge channel
[19:07] <popey> likely not many people
[19:07] <popey> most people tend to only care about stable releases
[19:09] <popey> its most useful to just build whenever upstream do a release
[19:09] <popey> which can be tested in edge, and then migrated to beta/stable as appropriate
[19:20] <hellsworth> ok glimpse upstream does want to keep snap in the glimpse project, review snapcraft.yaml prs, and maybe maintain the snap in the future. that is nice :)
[19:20] <hellsworth> popey: ^
[19:21] <popey> nice one
[19:21] <hellsworth> but they like the idea of snapcrafters having a yaml that will periodically build the snap and push it to the edge channel in teh store
[19:22] <popey> ok, so i/we need to make a simple travis.yml to do the builds
[19:22] <hellsworth> popey: is there anything i can do with helping out with that?
[19:22] <popey> if you have some time, that'd be awesome
[19:22] <popey> I'll ping you a mail with the details, okay?
[19:22] <hellsworth> i have never worked with travis.yaml before so yeah any details you can give me would help
[19:22] <hellsworth> sounds good. thanks so much :)
[19:22] <hellsworth> way to advocate
[19:25] <hellsworth> ok i'm off for the dentist.. I'll be back (in my best terminator voice)
[19:26] <popey> oooh I have a better idea
[19:27] <popey> glad i typed this mail up, now I can throw it away and give you a better idea :D
[19:31] <sarnold> pity your rubber ducky required a whole email :)
[19:38] <popey> ya
[19:38] <popey> hellsworth: you have mail

[20:47] <diddledan> I maintain and build a synchronised kernel from the Microsoft WSL2 repo on github which is a complete mirror that I've augmented by adding my own .github/workflows/* action definitions to. maybe that would be useful for making an in-tree snapcraft.yaml work?
[20:48] <diddledan> it resynchronises every hour with upstream changes which then get rebuilt if a new tag appears - the build service would take over the equivalent of the build step, but the sync step would be useful
[20:49] <diddledan> here's the workflow/action: https://github.com/diddlesnaps/WSL2-Linux-Kernel/blob/master/.github/workflows/sync-upstream.yml
[21:35] <hellsworth> thanks popey!
[21:35] <hellsworth> diddledan: no idea if yoru workflow could help but it's good to know aobut in case so thanks for the link :)