[06:56] <lissyx> seb128, thanks for rebuilding
[07:34] <seb128> lissyx, np, unsure what's going on with the build though, if that's a connectivity error or a server problem somehow
[07:35] <lissyx> what was the rror?
[07:35] <seb128> https://github.com/canonical/firefox-snap/actions/workflows/nightly-build.yml
[07:35] <seb128> the most recent builds failed on 
[07:35] <seb128>  + hg clone https://hg.mozilla.org/mozilla-central -u 1432959f9b860ab850c2709877ec53acb6e2333a .
[07:35] <seb128> transaction abort!
[07:36] <seb128> ...
[07:36] <seb128> abort: stream ended unexpectedly  (got 32606 bytes, expected 32768)
[07:37] <seb128> I just did a first retry an hour ago that failed the same way so let's see if the new one still has the issue
[07:40] <lissyx> i got a bunch of error 500 earlier on redash (tool for telemetry) so maybe there's some spotty incident
[07:45] <juliank> Can we kill update-manager and move it into flutter snap-store?
[07:46] <seb128> no
[07:46] <seb128> snap store is for snaps
[07:46] <juliank> hmm
[07:47] <juliank> I thought it also shows you debs?
[07:47] <lissyx> seb128, that being said, --stream should be used, I've finally found some benchmark made by glandium: https://glandium.org/blog/?p=3913
[07:47] <juliank> So is there a new separate deb "store"?
[07:48] <seb128> juliank, it's a bit unclear to me what the plans are for deb handling, they will probably still be available in some way but applying system updates is a different flow than installing applications from a store
[07:48] <juliank> like current snap store installs snaps, debs, upgrades snaps, upgrades firmware
[07:50] <juliank> seb128: It really shouldn't be, if you install a deb from a store, you should also be able to upgrade it from it, and then you just need a collection to represent any "OS upgrade" that's not app-associated
[07:50] <seb128> juliank, that's what gnome-software is doing and not a great experience
[07:51] <juliank> it certainly is miles above the update-manager experience
[07:52] <juliank> update-manager and software-properties and release upgrader all are stuck in GTK2 designs barely upgraded to GTK3 backends
[07:53] <seb128> I'm not saying that those are nice softwares or that they don't need to be improved/rewritten
[07:53] <seb128> but not everything fits under the store
[07:57] <juliank> the main problem I see is a lot of user confusion if you present them with multiple places to see available updates
[07:57] <juliank> needs like on "Updates Hub" application
[07:58] <juliank> I guess updates hub could aggregrate update sources and redirect you to domain-specific updating apps
[08:00] <juliank> and software-properties ng if you will really should probably be pages in the control center
[08:00] <juliank> the settings app
[08:02] <juliank> it all very much depends on the new deb822 model for managing sources and their keys
[08:04] <juliank> when I think about that, I think "sleek and concise" is my mantra
[08:06] <juliank> I just can't picture it yet
[08:08] <juliank> Once I have written the apt-key list replacement stuff will become clearer :D
[08:22] <lissyx> seb128, I also have hiccups locally doing hg clone ...
[08:32] <seb128> lissyx, :-(
[08:32] <lissyx> looks like the build on github finally runs ?
[08:33] <seb128> yes, it has managed to go past the checkout this time
[08:36] <lissyx> seb128, that being said, build is not idempotent here: re-runing a failed attempt breaks because of "quilt push -a"
[08:36] <lissyx> seb128, shouldn't be patch applied during the "override-pull" phase?
[08:36] <lissyx> same as setting $MOZCONFIG content
[08:41] <seb128> lissyx, I guess doing it in the pull would make sense in that regard since quilt push returns 2 and not 0 when patches are already applied
[11:14] <seb128> lissyx, bandali, https://github.com/canonical/firefox-snap/actions/runs/5386525782 , nightly build worked!
[11:45] <lissyx> seb128, is it on the store yet?
[11:46] <lissyx> rev 2834 dated today 1255
[11:46] <lissyx> looks like yes
[13:05] <bandali> awesome!
[13:06] <bandali> btw lissyx i plan to push a commit to `stable` to enable debug symbols for arm64; would it be picked up for 115.0-1 on your end, or would it need a version bumping?
[13:06] <bandali> (i'd prefer to not to a bump like that on `stable` because it's an ugly hack and i wouldn't want to carry that in the git history forever..)
[13:07] <lissyx> bandali, we dont collect armhf/aarch64 at all for the moment
[13:07] <bandali> ah okay great, thanks
[13:07] <lissyx> so we'd need to enable it first
[13:08] <bandali> ack. i'll ping you know when it's in place for arm64
[13:08] <bandali> s/know//
[13:08] <lissyx> do you already have arm64 builds on launchpad with those symbols ?
[13:08] <bandali> not yet, but hopefully starting today or tomorrow
[13:46] <lissyx> seb128, quickly measured
[13:46] <lissyx> seb128, I just killed a bare hg clone
[13:46] <lissyx> after 15m
[13:46] <lissyx> seb128, all my previous attempts using --stream were cloned in < 2m
[13:46] <seb128> lissyx, great! could you do a PR for it?
[13:47] <lissyx> or maybe I got unlucky
[13:47] <lissyx> well stream is designed to reduce the volume anyway
[13:52] <lissyx> killed it, restarted, it's already running for too long
[13:59] <lissyx> seb128, https://github.com/canonical/firefox-snap/pull/20
[13:59] -ubottu:#ubuntu-desktop- Pull 20 in canonical/firefox-snap "Improve flow" [Open]
[14:10] <seb128> lissyx, thanks
[14:10] <lissyx> hm that's not what I expected
[14:10] <lissyx> I killed a build, restarted it
[14:10] <lissyx> + env -u LD_LIBRARY_PATH -u PYTHONPATH /usr/bin/python3 ./mach configure --prefix=/root/parts/firefox/install/usr
[14:14] <seb128> ?
[14:15] <lissyx> it's complainig it does not find mach
[14:15] <lissyx> maybe I should move the rm ... ?
[14:21] <seb128> weird
[14:24] <lissyx> seb128, yeah my mistake
[14:24] <lissyx> seb128, the PR should be uptodate and good to go
[14:29] <seb128> 👍
[14:35] <lissyx> seb128, now that hg clone is separated, rebuild in 8 mins :)
[14:37] <seb128> great!
[18:26] <tuxayo> Hi :) does anyone know if using the snap version of steam can cause proton games to fail to launch or is that pretty much a thing of the past?
[18:26] <tuxayo> (Ubuntu 23.04, kisak's mesa PPA)
[18:27] <tuxayo> Maybe I missed an important part of getting proton games to run on Linux but I tried a native game (Veloren) and it works. So vulkan support should be ok
[18:30] <ogra> kenvandine, ^^^
[23:04] <KGB-2> gnome-settings-daemon Gunnar Hjalmarsson 408115 * commented merge request !15 * https://deb.li/lyNv
[23:09] <KGB-0> gnome-settings-daemon Jeremy Bicha 408116 * commented merge request !15 * https://deb.li/3PWEn
[23:21] <KGB-2> gnome-settings-daemon Gunnar Hjalmarsson 408117 * commented merge request !15 * https://deb.li/3nPmU