=== RAOF_ is now known as RAOF
[05:00] <lissyx> bandali, I see glean-sdk failure but it does not look to be really problematic
[05:01] <lissyx> bandali, but the SIGABRT leading to 
[05:01] <lissyx> :: 15:43.99 terminate called after throwing an instance of 'std::bad_alloc'
[05:01] <lissyx> :: 15:43.99   what():  std::bad_alloc
[05:01] <lissyx> :: 15:44.38 error: could not compile `style`
[05:01] <lissyx> this does sound like OOM condition
[05:23] <lissyx> bandali, btw current aarch64 works via our sysroot, I'm asking myself whether that's a good idea or not
[05:23] <lissyx> (I dont think it is)
[07:18] <lissyx> nteodosio, I need your opinion: when cross compiling shouldn't dependant snap be installed with the correct arch? right now I see gnome-42-2204-sdk with x86_64 libs ;(
[07:20] <nteodosio> lissyx, yeah I'd say so... Worth poking on the forum about the problem?
[07:21] <nteodosio> I don't think one can otherwise override that in snapcraft.yaml.
[07:21] <lissyx> I'd first love to find some issue / document about the ongoing work around cross-compilation
[07:21] <lissyx> I'm a bit skeptical about the current status now ..
[07:22] <lissyx> (and most of the cross-compilation thread on the forum ends up with mostly no activity)
[07:22] <nteodosio> I see. I myself have never tried it.
[07:23] <seb128> goood morning desktopers
[07:23] <seb128> nteodosio, hey, how are you doing?
[07:24] <nteodosio> Good morning, hey Seb! I'm doing fine, thanks, and you?
[07:24] <lissyx> https://forum.snapcraft.io/t/armhf-snap-on-arm64-system/27609/2 "mark the arm64 snap as compatible with armhf" :(
[07:29] <nteodosio> lissyx, is that article related to your issue?
[07:30] <lissyx> somehow
[07:30] <lissyx> since it suggests one cannot install arm64 snap on amd64 system
[07:30] <nteodosio> That's probably https://forum.snapcraft.io/t/architectures?
[07:31] <lissyx> probably
[07:32] <lissyx> but even "snap download" does not allow to select arch ...
[07:34] <lissyx> I could use our sysroot of course, but given I want to add testing to avoid isues like the one we had with arm64 116 release, it's probably the kind of changes that would make us miss the issue
[07:49] <seb128> lissyx, ls
[07:49] <seb128> ups
[07:49] <seb128> lissyx, snap download takes a revision
[07:49] <seb128> builds on different architectures have different revision
[07:50] <lissyx> even using the API: curl -H 'X-Ubuntu-Series: 16' "https://api.snapcraft.io/api/v1/snaps/details/gnome-42-2204-sdk?channel=stable"
[07:50] <lissyx> it returns amd64 arch on my arm64 system :)
[07:50] <seb128> so there isn't an arch argument but you can download e.F firefox 3137 which is the current arm64 build
[07:50] <seb128> $ snap download --revision=3137 firefox
[07:51] <lissyx> indeed
[07:51] <lissyx> API returns revision 185 for the gnome-sdk, but the download gets revision 187
[07:51] <lissyx> except it looks like the API does not allow me to search for that?
[07:52] <seb128> you can't download non published revision unless you are contributor to the snap
[07:52] <lissyx> it's a published revision
[07:52] <seb128> I don't understand your problem then
[07:52] <lissyx> the problem is simple
[07:53] <lissyx> trying to cross-compile with snapcraft, the gnome-sdk snap installed is x86-64 version and not aarch64
[07:53] <ricotz> good morning desktopers
[07:53] <seb128> that part I understand, it's the download not working which I don't
[07:53] <seb128> ricotz, hey, how are you?
[07:53] <ricotz> seb128, hi, please upload https://people.ubuntu.com/~ricotz/thunderbird/
[07:54] <seb128> ricotz, ack
[07:54] <ricotz> seb128, this 115.2.3 build2 includes the 115.3.0 security fixes - https://hg.mozilla.org/releases/comm-esr115
[07:54] <lissyx> seb128, if I want to download manually, I need to get the revision, and the API does not allows me it looks
[07:54] <seb128> which did they do another build instead of rolling out 115.3.0?
[07:55] <seb128> lissyx, 
[07:55] <seb128> $ snap download --revision=185 gnome-42-2204-sdk
[07:55] <seb128> Récupération du paquet Snap "gnome-42-2204-sdk"
[07:55] <seb128> Récupération des assertions pour "gnome-42-2204-sdk"
[07:55] <seb128> Installer le paquet Snap avec :
[07:55] <seb128>    snap ack gnome-42-2204-sdk_185.assert
[07:55] <lissyx> yes
[07:55] <seb128>    snap install gnome-42-2204-sdk_185.snap
[07:55] <ricotz> seb128, I am good, thanks, hoping you are too!
[07:55] <seb128> that seems to download the revision specified?
[07:55] <seb128> ricotz, I am, thanks!
[07:55] <lissyx> seb128, but I need to find the revision
[07:55] <lissyx> and i dont know it for arm64 for example
[07:55] <ricotz> seb128, don't ask me, they done it like that for whatever reason :\
[07:55] <seb128> ricotz, ack
[07:55] <ricotz> seb128, of course bumping the thunderbird version to 115.3.0 would be more fitting
[07:57] <ricotz> builds are running at https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+packages?field.name_filter=thunderbird&field.status_filter=published&field.series_filter=
[07:57] <seb128> lissyx, $ curl -s -H 'Content-Type: application/json' -H 'Snap-Device-Series: 16' -H 'Snap-Device-Architecture: arm64' 'http://api.snapcraft.io/v2/snaps/info/gnome-42-2204-sdk'  | jq .
[07:57] <seb128> lissyx, seems to work for me?
[07:57] <lissyx> ok so v1/snaps/details  does not
[07:58] <lissyx> and I was looking at v2/snaps docs but failed to see arch mentionned
[07:58] <seb128> k, I'm not familar enough with snaps to know about that
[07:58] <seb128> I mean I've that cmd in my historical notes and I know it works so copy paste when needed :p
[07:59] <seb128> I wish we had more active snap people around :/
[07:59] <seb128> it's hard to get replies or information on their channel or forum
[07:59] <lissyx> :)
[08:07] <lissyx> seb128, do you know if it's the right doc? https://dashboard.snapcraft.io/docs/reference/v2/en/snaps.html
[08:09] <seb128> lissyx, not sure, https://api.snapcraft.io/docs/info.html seems better?
[08:10] <lissyx> I can't get ?channel=stable to work on the endpoint you shared
[08:42] <seb128> lissyx, the documentation doesn't suggest it's a parameter? 
[08:42] <lissyx> nope
[08:42] <seb128> it seems you can only specify the arch and the information to include in the response
[08:42] <lissyx> I filter on JQ
[08:43] <lissyx> (it's mostly working)
[08:43] <seb128> I guess you just need to iterate over the result to pick 
[08:43] <seb128> ack
[08:43] <seb128> ricotz, uploaded (but blocked in the queue due to beta freeze), you can push to the vcs
[08:45] <ricotz> seb128, thanks and pushed
[08:46] <seb128> ricotz, thanks
[09:09] <lissyx> seb128, curl -s -H 'Content-Type: application/json' -H 'Snap-Device-Series: 16' 'http://api.snapcraft.io/v2/snaps/info/gnome-42-2204-sdk' | jq --arg arch arm64 -r '."channel-map" | . [] | select(.channel.name == "stable") | select (.channel.architecture == $arch)'
[09:10] <lissyx> nice hack, once I put unsquashfs into the loop.
[09:10] <lissyx> nasty but hey.
[09:14] <seb128> ;-)
[09:15] <nteodosio> Hideous!, but absolutely saving that for the future.
[10:18] <lissyx> :(
[10:18] <lissyx> pkg-config hardcodes current in its .pc files
[10:30] <juliank> fwiw, geoclue starts but connections just time out for me and I now force deleted my modem devices and stuff
[10:32] <juliank> after disabling apparmor
[10:32] <juliank> it's all funny
=== guiverc2 is now known as guiverc
[10:52] <lissyx> maybe prefix= should target actual revision in .pc files?
[11:45] <seb128> lissyx, what's the issue with the .pc using 'current'? Also the revision is a store concept so we don't have that information available at the time of the build
[12:04] <lissyx> seb128, well current is pointing to the x86-64 snap
[12:04] <lissyx> so you end up having the wrong definitions
[12:07] <lissyx> so I end up doing a bit of sed then
[12:07] <lissyx> (and we do need the x86-64 one for running e.g., pkg-config or gmake)
[12:10] <lissyx> example of error:
[12:10] <lissyx> ::  0:17.54 In file included from /root/parts/firefox/build/obj-aarch64-unknown-linux-gnu/dist/system_wrappers/dbus/dbus.h:3:
[12:10] <lissyx> ::  0:17.54 /snap/gnome-42-2204-sdk/current/usr/include/dbus-1.0/dbus/dbus.h:29:10: fatal error: 'dbus/dbus-arch-deps.h' file not found
[12:10] <lissyx> ::  0:17.54 #include <dbus/dbus-arch-deps.h>
[12:10] <lissyx> ::  0:17.54          ^~~~~~~~~~~~~~~~~~~~~~~
[12:34] <lissyx> nice
[12:34] <lissyx> a new sdk was published
[12:35] <lissyx> my build took it :p
[12:35] <seb128> :)
[12:36] <lissyx> ok it's not super super perfect
[12:36] <lissyx> but.
[12:36] <lissyx> I should be out of the woods for aarch64 now and thus armhf as well
[12:37] <lissyx> seb128, bandali, and this WIP: https://treeherder.mozilla.org/logviewer?job_id=429918524&repo=try&lineNumber=291-292
[12:37] <lissyx> taskcluster-built snap (like we do since a few weeks now) *
[12:37] <lissyx> but then, installing, running and testing about:support
[12:41] <KGB-0> gdm tags 587679b Simon McVittie upstream/45.0.1 * Upstream version 45.0.1 * https://deb.li/3UYHy
[12:41] <KGB-0> gdm upstream/latest 28362e8 Simon McVittie * pushed 10 commits (first 5 follow) * https://deb.li/3SJil
[12:41] <KGB-0> gdm upstream/latest 903b68f Gwan-gyeong Mun po/ko.po * Update Korean translation * https://deb.li/3JrM
[12:41] <KGB-0> gdm upstream/latest 429d732 Bruce Cowan po/en_GB.po * Update British English translation * https://deb.li/3Ou0j
[12:42] <KGB-0> gdm upstream/latest 8f5ce2b Anders Jonsson po/sv.po * Update Swedish translation * https://deb.li/z8e4
[12:42] <KGB-0> gdm upstream/latest d20ca3f Ray Strode daemon/gdm-session.c * session: Unexport worker interface if session is disposed early * https://deb.li/38x2D
[12:42] <KGB-0> gdm upstream/latest ee157cd Ray Strode daemon/gdm-session.c * Merge branch 'fix-early-session-disposal' into 'main' * https://deb.li/HxIg
=== ahasenack_ is now known as ahasenack
[13:37] <lissyx> seb128, do we expect that e.g. libasound2-dev is provided by the host and not by a snap ?
[13:52] <seb128> lissyx, nothing is provided by the host in snaps
[13:52] <seb128> at least not in confined snaps
[13:52] <seb128> libasound is part of the sdk though
[13:52] <lissyx> is it?
[13:53] <seb128> I mean the runtime sorry
[13:53] <lissyx> ok but there's not the header/pkg-config
[13:53] <seb128> there should
[13:54] <lissyx> user@user-rpi4:~/tmp$ find squashfs-root/ |grep "alsa\.pc"
[13:54] <lissyx> user@user-rpi4:~/tmp$
[13:56] <lissyx> seb128, I've failed to find some doc regarding the expected status of cross-compilation
[13:56] <lissyx> especially to know if some of the issues I hit should be filed as bugs or not
[13:56] <lissyx> (and missing "alsa.pc" would be one imho)
[13:56] <seb128> lissyx, I would post about it on forum.snapcraft.io
[13:56] <seb128> so at least I can nag people from Canonical to go and give a reply
[13:57] <seb128> IRC is harder to tz difference, no persistent backlog, etc
[13:57] <seb128> I've asked Ken about the alsa.pc
[13:57] <lissyx> yeah but posting in the blue while not knowing what I should expect to be working is not the best solution
[13:57] <lissyx> I'd prefer posting on the forum when I know more instead of nagging people that would end up as "yeah well it's not supported [...]"
[13:57] <seb128> well I think the forum is an ok place to ask those questions and try to figure out the status of things
[13:58] <seb128> if you get a reply saying it's not supported at least the next person who wonders the same thing can find a reply
[13:58] <lissyx> of course
[14:01] <lissyx> for what it is worth, mozilla's sysroot includes libasound and its pkg-config, so I would suspect a bug
[14:28] <lissyx> (I need to go and I wont be back online tonight)
[17:47] <KGB-2> gnome-shell signed tags 86139db Jeremy Bicha ubuntu/44.3-0ubuntu2 * gnome-shell Debian release 44.3-0ubuntu2 * https://deb.li/Addj
[17:50] <KGB-0> gnome-shell signed tags 1f59516 Jeremy Bicha ubuntu/44.3-0ubuntu1.1 * gnome-shell Debian release 44.3-0ubuntu1.1 * https://deb.li/30TgR
[17:50] <KGB-0> gnome-shell ubuntu/lunar 59012e9 Jeremy Bícha debian/changelog * releasing package gnome-shell version 44.3-0ubuntu1.1 * https://deb.li/dTFx