[01:56] <sergiusens> robert_ancell_: common-id is used as the index to find the right appstream components, so using appstream to find common-ids and set them seems like going the other way around from the original design
[01:56] <sergiusens> snaps can have multiple apps, thus multiple common-id's thus multiple appstream files within
[01:57] <robert_ancell> sergiusens, and the appstream components are used to populate the .desktop file information in the snapcraft YAML?
[02:53] <sergiusens> robert_ancell: the desktop file referenced in appstream is used to set meta/gui/<snap-name>.<app-name>.desktop
[02:54] <robert_ancell> sergiusens, I see why it would be weird to do it the other way.
[05:37] <jibel> hi everyone
[06:24] <fidencio> jibel: morning! :-)
[06:26] <jibel> hi fidencio
[06:26] <jibel> fidencio, thanks for digging
[06:26] <jibel> the compression method would explain why I didn't have the issue
[06:30] <fidencio> jibel: what I don't understand is which component may have regressed
[06:31] <fidencio> jibel: as kernel still has support for GZIP
[06:50] <oSoMoN> good morning desktoppers
[07:11] <didrocks> good morning
[07:22] <oSoMoN> salut didrocks
[07:25] <didrocks> ça va oSoMoN ?
[07:34] <marcustomlinson> morning jibel fidencio oSoMoN and didrocks
[07:37] <didrocks> hey marcustomlinson
[07:48] <fidencio> marcustomlinson: morning!
[07:49] <didrocks> morning fidencio
[08:06] <tjaalton> jbicha: will you package new libepoxy? I'm wondering if it should be moved under xorg-team at salsa
[08:20] <jibel> fidencio, how to you unpack the initrd?
[08:25] <didrocks> salut jibel
[08:26] <jibel> salut didrocks, ça va?
[08:26] <seb128> lut didrocks jibel
[08:26] <seb128> hey tjaalton
[08:27] <seb128> good morning desktopers
[08:27] <tjaalton> yo
[08:27] <jibel> fidencio, so in summary your preseed is still good with eoan and focal, it works when injected on the iso or initrd. The compression method must be lz4
[08:28] <jibel> fidencio, also I realized that unmkinitramfs strips / from symlinks and the initrd rebuilt directly from main/ doesn't work. I'll have a look at it.
[08:29] <fidencio> jibel: I'm not sure how virt-manager does the unpack. But yes, the summary is right. The thing to keep in mind is that it seems to be a regression, as net-install and server install work without any issue when using gzip
[08:30] <didrocks> salut seb128
[08:30] <didrocks> jibel: les sinus bien pris, mais sinon ça va
[08:33] <jibel> salut seb128
[08:45] <oSoMoN> didrocks, bien mieux dormi que la nuit précédente, donc ça va bien, et toi?
[08:45] <oSoMoN> good morning marcustomlinson
[08:45] <oSoMoN> salut seb128
[08:45] <oSoMoN> hey tjaalton
[08:46] <didrocks> oSoMoN: bien pris des sinus, vivement que ça s'améliore :) cool que tu ais pu récupérer
[08:47] <oSoMoN> vivement le printemps :)
[08:47] <seb128> lut oSoMoN, en forme ? la nuit a été meilleure ?
[08:47] <seb128> ah, tu viens de le dire :)
[08:47] <oSoMoN> bien meilleure, en effet!
[08:48] <seb128> vivement le printemps et vivement que les gosses aient 18 ans et arrête de ramener des rhumes de la crèche ? ;)
[08:48] <oSoMoN> oui, ça aussi
[08:49] <oSoMoN> why do people use PPAs that are advertised for testing purposes only and then send me rude e-mails to complain about broken packages and to demand a fix?
[08:50] <didrocks> because they don't read the warnings?
[08:50] <oSoMoN> well they should learn to read then
[08:50] <jibel> seb128, à 18 ans ils ramèneront des trucs bien pires que des rhumes ;)
[08:50] <seb128> :-(
[09:03] <Laney> yo
[09:17] <seb128> hey Laney marcustomlinson Wimpress, how are you today?
[09:24] <Laney> hey seb128
[09:24] <Laney> doing ok!
[09:25] <Laney> hoping it stops raining though :(
[09:25] <Laney> you?
[09:25] <didrocks> hey Laney!
[09:26] <seb128> I'm good, got rained on while dropping the kid to the childcare earlier but it stopped now
[09:26] <seb128> I've wet feet now though :(
[09:27] <seb128> marcustomlinson, I see that libreoffice is building still on some archs, looks like it go retried? what was the error?
[09:31] <marcustomlinson> seb128: there was line after line of "waiting for proxy" for 9 hours or somthing so I cancelled
[09:32] <marcustomlinson> also hey :)
[09:32] <marcustomlinson> and hey Wimpress and Laney
[09:34] <seb128> Laney, tweaking the board :)
[09:35] <Laney> haha
[09:35] <Laney> I forgot again that those are shared
[09:35] <Laney> because it was on the default colour
[09:35] <Laney> hey marcustomlinson
[09:59] <oSoMoN> morning Laney
[10:03] <seb128> Laney, feel free to pick a background, I tried a few but that was not great to I went back to picking a color yesterday
[10:03] <Laney> ok, next time I'm on there ;-)
[10:03] <Laney> o/ oSoMoN
[10:10] <oSoMoN> seb128, jsunit 0.2.2-1~ubuntu0.18.04.1 is still lingering in bionic-proposed while all the related deps (thunderbird 68 and enigmail) have migrated, I guess because it's new in bionic, is this something you can help with?
[10:12] <seb128> oSoMoN, I think you need a SRU team member, according to the wiki it's rbasak's day today so try pinging him (well, I just did for you now ;)
[10:12] <oSoMoN> :)
[10:21] <seb128> oSoMoN, sorry, more work for you, but firefox 71/focal made autopkgtest sad
[10:22] <seb128> oSoMoN, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/f/firefox/20191127_082713_a9c66@/log.gz
[10:22] <tjaalton> jbicha: I filed an ITA bug to move libepoxy under xorg-team
[10:22] <seb128> (same on other archs, so at least it's not a weird non-standard-arch issue)
[10:33] <oSoMoN> seb128, I know, the html5test script needs to be updated, I'll do that today
[12:04] <Laney> http://people.ubuntu.com/~laney/segv.webm
[12:04] <Laney> we came up with a cool way to fix that bug
[12:05] <seb128> Laney, wooot :)
[12:05] <seb128> going to make didrocks (& probably others) happy :)
[12:07] <seb128> Laney, just curious, what's the cool way?
[12:09] <Laney> moving them out of the gnome-shell scope to a dedicated one
[12:09] <Laney> mainly benzea's idea
[12:09] <Laney> need to make sure there isn't any weird corner case here
[12:10] <didrocks> \o/
[12:11] <seb128> ah, nice
[12:11]  * seb128 reads the systemd.scope documentation just to learn a bit more about it :-)
[12:14] <Laney> if you do systemd-run --user --scope firefox
[12:14] <Laney> that's basically the same thing
[12:16] <seb128> I see, cool :)
[12:17] <seb128> nothing to do with that, and maybe a stupid question, but how does gbp import-orig knows which remote/branch to use to update the upstream branch?
[12:20] <Laney> it gets the version number from the tarball
[12:20] <Laney> and then finds a tag for that version
[12:22] <Laney> you can configure the mapping using upstream-vcs-tag in the gbp.conf, some pkgs do that already
[12:22] <seb128> ah, right, tag!
[12:22] <seb128> right, I had to do that when they use a non standard naming
[12:22] <seb128> I was just wondering if the naming of my upstream remote matters
[12:23] <Laney> nah
[12:23] <seb128> it doesn't, the question just show I still struggle at time to understand how git works being the curtain :p
[12:23] <seb128> thx for the reply, makes sense now that you pointed out that it matches the tag
[12:26] <Laney> 👍
[12:32] <seb128> Laney, yet another topic ... :p when you have some slot, can you make cards as you see fit for the oem ubiquity/kernel work we should own?
[12:32] <Laney> yeah, but in my head we need to nail down who is doing what first
[12:33] <seb128> right, that's fine
[12:33] <seb128> thx
[14:36] <seb128> mdeslaur, hey, thanks for merging dbus!
[14:36] <mdeslaur> seb128: np!
[15:08] <Laney> ah yeah
[15:08] <Laney> we should schedule getting rid of GetConnectionAppArmorSecurityContext
[15:13] <Laney> wonder where I can store such ideas to be put on future cycle plans
[15:14] <Laney> proposed column?
[15:14] <Laney> then triage that at start of each cycle?
[15:15] <seb128> Laney, or a card in the proposed column of trello?
[15:15] <Laney> indeed
[16:26] <seb128> what's going on with that libreoffice/amd64 build
[16:26] <seb128> the build log is stucked on "cleaning up" for a while now
[16:26] <seb128> https://launchpad.net/ubuntu/+source/libreoffice/1:6.3.3-0ubuntu2/+build/18164526
[16:27] <seb128> marcustomlinson, don't kill/restart it in any case please
[16:28] <seb128> or it's still in the packaging, is that step taking a while?
[16:28] <marcustomlinson> I think you just happened to look at it at a slow point
[16:28] <marcustomlinson> watched pot you know ;)
[16:28] <seb128> k, good :)
[18:00]  * ricotz waves goodbye to i386
[18:06] <oSoMoN> heh, I was looking at https://launchpad.net/ubuntu/+source/firefox/71.0+build2-0ubuntu2, and at first I thought "there's something missing", only to realize it was the i386 build :)
[18:08] <ricotz> same here ;)
[18:09] <marcustomlinson> oh that happened today?
[18:20] <oSoMoN> I noticed today, but I suppose focal never included i386 builds
[18:21] <oSoMoN> actually I'm wrong, it must have happened today, as https://launchpad.net/ubuntu/+source/firefox/71.0+build2-0ubuntu1 has an i386 build
[18:26] <marcustomlinson> RIP
[18:30] <ppd1990> oSoMoN: Hi. A quick question, if I may: The chromium vaapi track is gone for good, isn't it?
[18:32] <oSoMoN> ppd1990, you may :) it's gone, but I have an item on my to-do list to resurrect it, test it and merge the patch in the stable branch
[18:35] <ppd1990> ah, great to hear. I'm looking forward to it!
[21:12] <marcustomlinson> seb128: libreoffice finally finished building
[21:17] <robert_ancell> kenvandine, feaneron is asking about the gnome-calendar snap showing "Canonical" as the in the store page. And also it not being the latest version. What's the state on that?
[21:23] <robert_ancell> hellsworth, actually, not sure if you know anything about the gnome-calendar snap?
[21:23] <robert_ancell> It looks like it was one of the older snaps that was made and hasn't been updated to automatically build.
[21:31] <marcustomlinson> robert_ancell: well it looks like it has been built recently (I assume for security reasons), just not updated to build the latest version
[21:32] <marcustomlinson> the snapcraft.yaml is specifically pointing at source-tag: 3.30.0
[21:34] <feaneron> does ubuntu ship GNOME Calendar through snap by default?
[21:35] <robert_ancell> feaneron, no
[21:36] <feaneron> does Ubuntu Store prefer the snap version of Calendar when installing or searching?
[21:37] <robert_ancell> feaneron, the snap version shows earlier in the searches.
[21:38] <feaneron> :(
[21:39] <feaneron> it's not as terrible as it could be, but it's not ideal either
[21:40] <robert_ancell> I don't see any reason why it shouldn't be 3.34, other than it was probably one of the test case snaps and hasn't been updated.
[21:41] <robert_ancell> marcustomlinson, was it using the current platform snap stuff?
[21:41] <marcustomlinson> It's currently using the gnome-3-28 platform
[21:42] <kenvandine> EDS versions, I think
[21:42] <robert_ancell> aha
[21:43] <kenvandine> We're working on getting GNOME as a publisher in the store as well
[21:44] <kenvandine> The problem is compatibility with the host version of EDS for bionic and other supported releases
[21:44] <kenvandine> I'll make sure we get it updated over the next few weeks
[21:45] <robert_ancell> feaneron, what does the calendar flatpak do for eds compatibility? Just not work on older releases?
[21:45] <kenvandine> And if we can get the yaml merged upstream we can get an autobuild setup as well
[21:45] <kenvandine> It runs it's own daemon in the sandbox
[21:46] <feaneron> Right now, nothing; this EDS transition is being really painful
[21:46] <kenvandine> That's our holdup
[21:46] <feaneron> I would like to add a runtime check to see if the newer EDS D-Bus interfaces are available, but that would require a string freeze exception
[21:47] <kenvandine> We want it to work with EDS in 18.04
[21:47] <marcustomlinson> that's quite a doozy
[21:47] <feaneron> kenvandine: running the daemon inside the sandbox turns out to be... bad. Sandbox EDS doesn't communicate Host EDS, and it looses all platform integration
[21:48] <feaneron> that's what the development Flatpak of Calendar used to do, and it's really annoying
[21:48] <kenvandine> Right
[21:48] <kenvandine> Which is why I stopped updating the snap
[21:49] <kenvandine> feaneron: I'm open to suggestions :-)
[21:50] <feaneron> Me too. I just can't find a solution where we win this fight.
[21:50] <kenvandine> :-\
[21:50] <feaneron> Beyond, of course, make Calendar not use EDS at all
[21:50] <feaneron> which also means loosing all platform integration
[21:50] <kenvandine> feaneron:  I'll see if jamesh might have ideas
[21:51] <kenvandine> Losing platform integration would suck
[22:23] <seb128> marcustomlinson, thx, seems like it picked the slowest buildd or something!
[22:24] <marcustomlinson> yeah crazy slow
[22:37] <ahayzen> if EDS could talk multiple versions of it's api/protocol then the client and server could meet at a common level, but i guess this would be tricky to implement.  This seems like a major problem that snaps/flatpak need to figure out as the same appears to happen for other things like tracker and online accounts etc ?
[22:46] <robert_ancell> ahayzen, the traditional distribution model has meant that user services have trended to having very dynamic APIs. That has to change in the sandboxed app future.
[22:46] <robert_ancell> System services are generally better done.
[22:50] <ahayzen> robert_ancell, but if the system service supported version 2 of the API, and then the client supported version 1,2,3 they could meet with version 2, and the same the other way around.  But yeah services need a more stable interface, i wonder if some of these things almost warrant a portal to exchange the data in a common way to/from the system
[22:51] <robert_ancell> ahayzen, I guess portals will abstract away some of the simpler cases, but the more complex stuff like EDS will be harder.
[22:57] <ahayzen> robert_ancell, hey, random other question, i was trying to hack on the gnome software snap plugin earlier, and i tried building gnome software master on fedora 31. But whenever i tried to open a snap in the store it would crash, is this expected that things are broken on master, as i know ubuntu has an old gnome software or maybe i built it wrong?
[22:58] <robert_ancell> ahayzen, no, that's not expected - do you have a backtrace?
[22:58] <robert_ancell> I'll spin up my F31 VM and try building it there.
[23:01] <ahayzen> robert_ancell, i can get one :-)
[23:01]  * ahayzen spins up VM
[23:08] <ahayzen> robert_ancell, if i click on Ardour from the start page, this happens https://pastebin.ubuntu.com/p/YSCHgxNHgk/  ... but if i click on some others it doesn't crash (like Kotlin)
[23:08] <robert_ancell> Interesting (in a bad way)
[23:09] <ahayzen> :-)
[23:09] <robert_ancell> It might be a threading issue, but if I can easily reproduce that is useful.
[23:09] <robert_ancell> I've seen similar issues before in crash reports, but not been able to reproduce.
[23:10]  * robert_ancell is dnf installing dependencies...
[23:10] <ahayzen> this is a KVM VM with 2 CPUs and 3096 MB RAM for reference
[23:11] <robert_ancell> ah, good. We're both on VMs.
[23:13] <robert_ancell> ahayzen, I only give my VMs 2048 MB :)
[23:14] <ahayzen> hehe i usually do as well, but as i was building stuff i thought i'd give it more :-)
[23:14] <robert_ancell> Though I just updated my laptop from 8GB to 16GB, so I now have some more RAM for hungry VMs
[23:59] <robert_ancell> ahayzen, https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/372
[23:59] <gitbot> GNOME issue (Merge request) 372 in gnome-software "snap: Don't try to get alternatives for non-snaps" [Opened]
[23:59] <robert_ancell> Thanks for letting me know!