[06:56] seb128, thanks for rebuilding [07:34] lissyx, np, unsure what's going on with the build though, if that's a connectivity error or a server problem somehow [07:35] what was the rror? [07:35] https://github.com/canonical/firefox-snap/actions/workflows/nightly-build.yml [07:35] the most recent builds failed on [07:35] + hg clone https://hg.mozilla.org/mozilla-central -u 1432959f9b860ab850c2709877ec53acb6e2333a . [07:35] transaction abort! [07:36] ... [07:36] abort: stream ended unexpectedly (got 32606 bytes, expected 32768) [07:37] 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] i got a bunch of error 500 earlier on redash (tool for telemetry) so maybe there's some spotty incident [07:45] Can we kill update-manager and move it into flutter snap-store? [07:46] no [07:46] snap store is for snaps [07:46] hmm [07:47] I thought it also shows you debs? [07:47] 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] So is there a new separate deb "store"? [07:48] 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] like current snap store installs snaps, debs, upgrades snaps, upgrades firmware [07:50] 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] juliank, that's what gnome-software is doing and not a great experience [07:51] it certainly is miles above the update-manager experience [07:52] update-manager and software-properties and release upgrader all are stuck in GTK2 designs barely upgraded to GTK3 backends [07:53] I'm not saying that those are nice softwares or that they don't need to be improved/rewritten [07:53] but not everything fits under the store [07:57] the main problem I see is a lot of user confusion if you present them with multiple places to see available updates [07:57] needs like on "Updates Hub" application [07:58] I guess updates hub could aggregrate update sources and redirect you to domain-specific updating apps [08:00] and software-properties ng if you will really should probably be pages in the control center [08:00] the settings app [08:02] it all very much depends on the new deb822 model for managing sources and their keys [08:04] when I think about that, I think "sleek and concise" is my mantra [08:06] I just can't picture it yet [08:08] Once I have written the apt-key list replacement stuff will become clearer :D [08:22] seb128, I also have hiccups locally doing hg clone ... [08:32] lissyx, :-( [08:32] looks like the build on github finally runs ? [08:33] yes, it has managed to go past the checkout this time [08:36] seb128, that being said, build is not idempotent here: re-runing a failed attempt breaks because of "quilt push -a" [08:36] seb128, shouldn't be patch applied during the "override-pull" phase? [08:36] same as setting $MOZCONFIG content [08:41] 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] lissyx, bandali, https://github.com/canonical/firefox-snap/actions/runs/5386525782 , nightly build worked! [11:45] seb128, is it on the store yet? [11:46] rev 2834 dated today 1255 [11:46] looks like yes [13:05] awesome! [13:06] 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] (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] bandali, we dont collect armhf/aarch64 at all for the moment [13:07] ah okay great, thanks [13:07] so we'd need to enable it first [13:08] ack. i'll ping you know when it's in place for arm64 [13:08] s/know// [13:08] do you already have arm64 builds on launchpad with those symbols ? [13:08] not yet, but hopefully starting today or tomorrow [13:46] seb128, quickly measured [13:46] seb128, I just killed a bare hg clone [13:46] after 15m [13:46] seb128, all my previous attempts using --stream were cloned in < 2m [13:46] lissyx, great! could you do a PR for it? [13:47] or maybe I got unlucky [13:47] well stream is designed to reduce the volume anyway [13:52] killed it, restarted, it's already running for too long [13:59] 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] lissyx, thanks [14:10] hm that's not what I expected [14:10] I killed a build, restarted it [14:10] + env -u LD_LIBRARY_PATH -u PYTHONPATH /usr/bin/python3 ./mach configure --prefix=/root/parts/firefox/install/usr [14:14] ? [14:15] it's complainig it does not find mach [14:15] maybe I should move the rm ... ? [14:21] weird [14:24] seb128, yeah my mistake [14:24] seb128, the PR should be uptodate and good to go [14:29] 👍 === cpaelzer_ is now known as cpaelzer [14:35] seb128, now that hg clone is separated, rebuild in 8 mins :) [14:37] great! [18:26] 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] (Ubuntu 23.04, kisak's mesa PPA) [18:27] 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] kenvandine, ^^^ [23:04] gnome-settings-daemon Gunnar Hjalmarsson 408115 * commented merge request !15 * https://deb.li/lyNv [23:09] gnome-settings-daemon Jeremy Bicha 408116 * commented merge request !15 * https://deb.li/3PWEn [23:21] gnome-settings-daemon Gunnar Hjalmarsson 408117 * commented merge request !15 * https://deb.li/3nPmU