[08:05] <seb128> goood morning IRC
[08:07] <lissyx> so installing packages from build-packages avoid snapcraft trying to install them
[08:07] <lissyx> but packages from stage-packages, snapcraft still tries
[08:10] <nteodosio> Hi seb128, good morning!
[08:10] <nteodosio> Hi lissyx, yes that's true
[08:11] <lissyx> nteodosio, it's really making my life miserable
[08:11] <nteodosio> Even now that you know it?
[08:11] <lissyx> yes?
[08:11] <lissyx> because there's no way I can fix this ?
[08:11] <lissyx> so bassically i've been working since ~2 weeks on getting snap builds on taskcluster for mostly nothing because of this limitation
[08:12] <lissyx> why would stage-packages be handled differently ?
[08:12] <nteodosio> They are defined as "a list of packages required at runtime by a snap." https://snapcraft.io/docs/snapcraft-parts-metadata
[08:13] <nteodosio> So it makes sense that packages there are installed.
[08:13] <lissyx> the package is installed
[08:13] <lissyx> but snapcraft tries to install it again
[08:13] <lissyx> https://firefoxci.taskcluster-artifacts.net/ZwsoSrvdQNCVrS27wn_8ZA/0/public/build/snapcraft-20230619-074003.661062.log
[08:13] <lissyx> https://treeherder.mozilla.org/logviewer?job_id=419814904&repo=try&lineNumber=666
[08:15] <nteodosio> So the problem is that libavcodec58 is installed but snapcraft is trying to install it again?
[08:16] <lissyx> yes
[08:16] <nteodosio> Where is it installed, in the host?
[08:16] <lissyx> I'm using --destructive-mode so yes it's installed on the host
[08:17] <nteodosio> And you don't want it in the snap?
[08:17] <lissyx> ?
[08:17] <lissyx> i dont know what i want
[08:17] <nteodosio> I don't know what is the actual issue you are having.
[08:17] <lissyx> I'm just trying to build the firefox snap
[08:18] <lissyx> the issue is simple: package is installed but snapcraft tries to install it again.
[08:19] <nteodosio> I don't see evidence to that. You said it is installed in the host, but in the snap it seems to be trying to install it only once.
[08:19] <lissyx> nteodosio, please look at the links?
[08:19] <lissyx> [task 2023-06-19T07:40:01.604Z] Setting up libavcodec58:amd64 (7:4.4.2-0ubuntu0.22.04.1) ...
[08:20] <lissyx> so it's installed
[08:20] <lissyx> and I'm using --destructive-mode
[08:20] <nteodosio> I did. Perhaps I'm missing context.
[08:21] <nteodosio> It seems correct that it's trying to install something in stage-packages, even if it is in the host.
[08:21] <lissyx> if it's in destructive mode, where is it going to install it?
[08:21] <nteodosio> I don't know what is destructive mode.
[08:21] <lissyx> snapcraft --destructive-mode
[08:22] <nteodosio> OK, that says "Designed to be used in temporary/short-lived environments, such as on a CI system, because the build could contaminate the host build environment."
[08:23] <nteodosio> Ah OK this describes it better: "Unlike broader snap packages, kernel snaps are typically built within the host environment using snapcraft --destructive-mode."
[08:23] <nteodosio> So yes now I see your problem and I don't have an answer.
[08:29] <lissyx> maybe this? https://github.com/canonical/craft-parts/blob/main/craft_parts/packages/deb.py#L407
[08:31] <lissyx> jbicha, regarding my workspace focus issue: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2909
[08:31] -ubottu:#ubuntu-desktop- Merge 2909 in GNOME/mutter "core/window: Change MRU update behavior for windows on all workspaces" [Merged]
[08:33] <nteodosio> Maybe, but as far as I know it could still try to install it even without updating the packages list.
[08:34] <nteodosio> In that destructive mode you can only build for the same base your host is on, I suppose?
[08:35] <lissyx> yes
[08:36] <lissyx> but I can make an image matching what I want to build
[08:37] <nteodosio> So when you said you didn't want Snapcraft to install the package even though it was in stage, you meant that it should not try to `apt install` it in the snap, but still install the version from the host.
[08:38] <lissyx> I dont want snapcraft to run any "apt-get"
[08:38] <lissyx> the "update" that chocked was from https://github.com/canonical/craft-parts/blob/047a8e55196aeccd77eb01091025971e406ca97c/craft_parts/packages/deb.py#L644
[08:39] <lissyx> any install would seem to only occur from https://github.com/canonical/craft-parts/blob/047a8e55196aeccd77eb01091025971e406ca97c/craft_parts/packages/deb.py#L537
[08:39] <lissyx> and as long as we installed it prior I guess we should be safe wrt https://github.com/canonical/craft-parts/blob/047a8e55196aeccd77eb01091025971e406ca97c/craft_parts/packages/deb.py#L526-L527
[08:59] <lissyx> :( https://treeherder.mozilla.org/logviewer?job_id=419817867&repo=try&lineNumber=559-578
[09:02] <KGB-0> gnome-shell-extension-harddisk-led tags f7d219b Jonathan Carter upstream/34 * https://deb.li/3z0fN
[09:03] <lissyx> grr
[09:03] <lissyx> set to 0 to inhibit ...
[09:09] <KGB-2> gnome-shell-extension-hide-activities tags ef2da15 Jonathan Carter upstream/44 * https://deb.li/370qh
[09:16] <KGB-0> gnome-shell-extension-dash-to-panel tags f436d47 Jonathan Carter upstream/56 * https://deb.li/XHL7
[09:17] <KGB-0> deja-dup tags 25c5fb8 Sebastien Bacher upstream/44.2 * Upstream version 44.2 * https://deb.li/yf0j
[09:17] <KGB-2> deja-dup upstream/latest 18a9d16 Sebastien Bacher * pushed 38 commits (first 5 follow) * https://deb.li/3jvWi
[09:17] <KGB-2> deja-dup upstream/latest bcbaa93 Balázs Úr po/hu.po * Update Hungarian translation * https://deb.li/YfM0
[09:17] <KGB-2> deja-dup upstream/latest 4e1bb85 Kukuh Syafaat po/id.po * Update Indonesian translation * https://deb.li/3B0L2
[09:17] <KGB-2> deja-dup upstream/latest 1a6b1e3 Anders Jonsson po/sv.po * Update Swedish translation * https://deb.li/Z0ys
[09:17] <KGB-2> deja-dup upstream/latest 9c4a58b Michael Terry help/tr/tr.po * chore: add back license marker to tr.po to fix linting * https://deb.li/I0Ax
[09:17] <KGB-2> deja-dup upstream/latest fe353ab Michael Terry libdeja/ (5 files in 3 dirs) * feat: more duplicity 2.0 preparations * https://deb.li/3mHhE
[09:18] <KGB-2> deja-dup pristine-tar 0cd342c Sebastien Bacher deja-dup_44.2.orig.tar.gz.delta deja-dup_44.2.orig.tar.gz.id * pristine-tar data for deja-dup_44.2.orig.tar.gz * https://deb.li/3dHZU
[09:50] <lissyx> seems like it might be doing the trick :p https://treeherder.mozilla.org/jobs?repo=try&revision=192be1f1fff5f21537132d6723bb410e31f34fdc
[12:26] <lissyx> kenvandine, https://launchpad.net/~desktop-snappers/+related-packages gnome-3-38-2004-sdk disappeared?
[12:28] <lissyx> ok weird it's not listed on the main page but I still find it https://launchpad.net/~desktop-snappers/+snap/gnome-3-38-2004-sdk
[13:06] <seb128> lissyx, you want https://launchpad.net/~desktop-snappers/+snaps no ?
[13:07] <lissyx> seb128, maybe
[13:07] <lissyx> either way, we have a few issues on symbols right now :(
[13:07] <lissyx> we miss gnome 42 ones
[13:07] <lissyx> we dont have firefox core22 branch ones
[13:24] <seb128> lissyx, do you know why we are missing the gnome ones?
[13:28] <seb128> lissyx, is that your collector job not fetching those?
[13:28] <seb128> https://git.launchpad.net/gnome-sdk/tree/snapcraft.yaml#n1747 suggests the snapcraft side is there?
[13:45] <lissyx> seb128, both because we collect only gnome-3-38-2004-sdk for now
[13:45] <lissyx> seb128, and because when I test gnome-42-2204-sdk I have issues
[13:46] <lissyx> seb128, much bigger problem for me is that core22 build does not place .debug file next to .snap
[13:46] <lissyx> seb128, this is going to be problematic for upload to the launchpad library?
[13:46] <lissyx> at least it's problematic on my local tests
[13:46] <seb128> lissyx, is that an error in the snapcraft?yaml?
[13:47] <lissyx> I dont know
[13:49] <lissyx> the gnome sdk issue is weird, files are corrupted https://treeherder.mozilla.org/logviewer?job_id=419848480&repo=try&lineNumber=368 but it looks to be a bug on our code
[13:49] <lissyx> the lack of .debug for core22 is different, it's properly generated but not copied at the end
[13:58] <lissyx> o_O I can open it with file-roller correctly
[14:03] <lissyx> and when I download it manually it works as well.
[14:14] <lissyx> seb128, ok I think it's because we end up finding two branches, and the download code we have makes things broken because the file names are identical
[14:15] <lissyx> between gnome-42-2204-sdk-proposed and gnome-42-2204-sdk
[14:16] <seb128> I didn't even know we have a proposed...
[14:38] <lissyx> seb128, is it possible this cp is broken? https://github.com/canonical/firefox-snap/blob/140a377cdf079b799c845457a71e75582dee6c7d/snapcraft.yaml#L591
[14:42] <seb128> lissyx, it could be but I think the issue is earlier, checking a recent build log from core22
[14:42] <seb128> https://launchpadlibrarian.net/671347170/buildlog_snap_ubuntu_jammy_amd64_firefox-snap-core22_BUILDING.txt.gz
[14:42] <seb128> Executing parts lifecycle: pull debug-symbols
[14:42] <seb128> Executing action
[14:42] <seb128> :: ++ find /build/firefox/stage/debug-symbols/ -type f -name 'firefox-*.crashreporter-symbols.zip'
[14:42] <seb128> :: + export SYMBOLS_ARCHIVE=
[14:42] <seb128> :: + SYMBOLS_ARCHIVE=
[14:42] <seb128> :: + '[' -f '' ']'
[14:42] <seb128> Executed: pull debug-symbols
[14:43] <seb128> it seems the pull debug-symbols isn't pulling any?
[14:43] <lissyx> :[
[14:43] <lissyx> mach buildsymbols worked?
[14:43] <seb128> I need to drop from IRC for a bit moving location but I will read the irclog once I reconnect
[14:43] <seb128> bandali, ^ any idea about those issues?
[14:47] <seb128> the log has
[14:47] <seb128> :: + cp obj-x86_64-pc-linux-gnu/dist/firefox-114.0.1.en-US.linux-x86_64.crashreporter-symbols.zip /build/firefox/stage/debug-symbols/
[14:47] <seb128> so at least the .zip seems generated
[14:48] <seb128> but the cp is earlier in the log than the zip creation
[14:48] <seb128> so ordering issue in the rules?
[14:48] <seb128> bbiab
[15:55] <lissyx> nteodosio, since seb128 is not there I hope you can help :p
[15:55] <lissyx> is override-pull a bug here ? https://github.com/canonical/firefox-snap/blob/stable/snapcraft.yaml#L562
[15:56] <lissyx> we want to do this after a firefox build, I believe override-pull will be done at the wrong moment?
[15:58] <lissyx> (but I also think we had to use override-pull because of something network-related
[16:03] <lissyx> from the log shared above https://launchpadlibrarian.net/671347170/buildlog_snap_ubuntu_jammy_amd64_firefox-snap-core22_BUILDING.txt.gz, checking line number it's obvious the debug-symbols override-pull has been done before the build of the symbols
[16:03] <lissyx>   39137 Executed: pull firefox                                                          
[16:03] <lissyx>   39138 Executing parts lifecycle: pull debug-symbols                                   
[16:12] <lissyx> https://github.com/snapcore/snapcraft/issues/4220
[16:12] -ubottu:#ubuntu-desktop- Issue 4220 in snapcore/snapcraft "Using after leads to pull after instead of waiting for complete part" [Open]
[16:29] <nteodosio> lissyx, yes, I think it is. The documentation is not clear. It explicitly mentions "build and stage" but not pull and that is what you observed in the build log.
[16:30] <lissyx> "runs the same lifecycle step of all parts before moving to the next step. However, you can change this behavior using the after keyword"
[16:30] <lissyx> this does not mention build and stage ?
[16:36] <nteodosio> Yes, it mentions all lifecycle steps. And then it goes on to say that changes with the after keyword. But it never really says explicitly _how_, leaving margin for the natural interpretation, namely "all lifecycle steps of X are executed before any lifecycle step of Y".
[20:45] <seb128> lissyx, I will add the firefox core22/debug issue on our active backlog and follow up with the snapcraft team about it