[01:56] 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] snaps can have multiple apps, thus multiple common-id's thus multiple appstream files within [01:57] sergiusens, and the appstream components are used to populate the .desktop file information in the snapcraft YAML? [02:53] robert_ancell: the desktop file referenced in appstream is used to set meta/gui/..desktop [02:54] sergiusens, I see why it would be weird to do it the other way. [05:37] hi everyone [06:24] jibel: morning! :-) [06:26] hi fidencio [06:26] fidencio, thanks for digging [06:26] the compression method would explain why I didn't have the issue [06:30] jibel: what I don't understand is which component may have regressed [06:31] jibel: as kernel still has support for GZIP [06:50] good morning desktoppers [07:11] good morning [07:22] salut didrocks [07:25] ça va oSoMoN ? [07:34] morning jibel fidencio oSoMoN and didrocks [07:37] hey marcustomlinson [07:48] marcustomlinson: morning! [07:49] morning fidencio === pstolowski|afk is now known as pstolowski [08:06] jbicha: will you package new libepoxy? I'm wondering if it should be moved under xorg-team at salsa [08:20] fidencio, how to you unpack the initrd? [08:25] salut jibel [08:26] salut didrocks, ça va? [08:26] lut didrocks jibel [08:26] hey tjaalton [08:27] good morning desktopers [08:27] yo [08:27] 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] 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] 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] salut seb128 [08:30] jibel: les sinus bien pris, mais sinon ça va [08:33] salut seb128 [08:45] didrocks, bien mieux dormi que la nuit précédente, donc ça va bien, et toi? [08:45] good morning marcustomlinson [08:45] salut seb128 [08:45] hey tjaalton [08:46] oSoMoN: bien pris des sinus, vivement que ça s'améliore :) cool que tu ais pu récupérer [08:47] vivement le printemps :) [08:47] lut oSoMoN, en forme ? la nuit a été meilleure ? [08:47] ah, tu viens de le dire :) [08:47] bien meilleure, en effet! [08:48] vivement le printemps et vivement que les gosses aient 18 ans et arrête de ramener des rhumes de la crèche ? ;) [08:48] oui, ça aussi [08:49] 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] because they don't read the warnings? [08:50] well they should learn to read then [08:50] seb128, à 18 ans ils ramèneront des trucs bien pires que des rhumes ;) [08:50] :-( [09:03] yo [09:17] hey Laney marcustomlinson Wimpress, how are you today? [09:24] hey seb128 [09:24] doing ok! [09:25] hoping it stops raining though :( [09:25] you? [09:25] hey Laney! [09:26] I'm good, got rained on while dropping the kid to the childcare earlier but it stopped now [09:26] I've wet feet now though :( [09:27] marcustomlinson, I see that libreoffice is building still on some archs, looks like it go retried? what was the error? [09:31] seb128: there was line after line of "waiting for proxy" for 9 hours or somthing so I cancelled [09:32] also hey :) [09:32] and hey Wimpress and Laney [09:34] Laney, tweaking the board :) [09:35] haha [09:35] I forgot again that those are shared [09:35] because it was on the default colour [09:35] hey marcustomlinson [09:59] morning Laney [10:03] 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] ok, next time I'm on there ;-) [10:03] o/ oSoMoN [10:10] 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] 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] :) [10:21] oSoMoN, sorry, more work for you, but firefox 71/focal made autopkgtest sad [10:22] oSoMoN, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/f/firefox/20191127_082713_a9c66@/log.gz [10:22] jbicha: I filed an ITA bug to move libepoxy under xorg-team [10:22] (same on other archs, so at least it's not a weird non-standard-arch issue) [10:33] seb128, I know, the html5test script needs to be updated, I'll do that today [12:04] http://people.ubuntu.com/~laney/segv.webm [12:04] we came up with a cool way to fix that bug [12:05] Laney, wooot :) [12:05] going to make didrocks (& probably others) happy :) [12:07] Laney, just curious, what's the cool way? [12:09] moving them out of the gnome-shell scope to a dedicated one [12:09] mainly benzea's idea [12:09] need to make sure there isn't any weird corner case here [12:10] \o/ [12:11] ah, nice [12:11] * seb128 reads the systemd.scope documentation just to learn a bit more about it :-) [12:14] if you do systemd-run --user --scope firefox [12:14] that's basically the same thing [12:16] I see, cool :) [12:17] 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] it gets the version number from the tarball [12:20] and then finds a tag for that version [12:22] you can configure the mapping using upstream-vcs-tag in the gbp.conf, some pkgs do that already [12:22] ah, right, tag! [12:22] right, I had to do that when they use a non standard naming [12:22] I was just wondering if the naming of my upstream remote matters [12:23] nah [12:23] it doesn't, the question just show I still struggle at time to understand how git works being the curtain :p [12:23] thx for the reply, makes sense now that you pointed out that it matches the tag [12:26] 👍 [12:32] 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] yeah, but in my head we need to nail down who is doing what first [12:33] right, that's fine [12:33] thx [14:36] mdeslaur, hey, thanks for merging dbus! [14:36] seb128: np! [15:08] ah yeah [15:08] we should schedule getting rid of GetConnectionAppArmorSecurityContext [15:13] wonder where I can store such ideas to be put on future cycle plans [15:14] proposed column? [15:14] then triage that at start of each cycle? [15:15] Laney, or a card in the proposed column of trello? [15:15] indeed [16:26] what's going on with that libreoffice/amd64 build [16:26] the build log is stucked on "cleaning up" for a while now [16:26] https://launchpad.net/ubuntu/+source/libreoffice/1:6.3.3-0ubuntu2/+build/18164526 [16:27] marcustomlinson, don't kill/restart it in any case please [16:28] or it's still in the packaging, is that step taking a while? [16:28] I think you just happened to look at it at a slow point [16:28] watched pot you know ;) [16:28] k, good :) === pstolowski is now known as pstolowski|afk [18:00] * ricotz waves goodbye to i386 [18:06] 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] same here ;) [18:09] oh that happened today? [18:20] I noticed today, but I suppose focal never included i386 builds [18:21] 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] RIP [18:30] oSoMoN: Hi. A quick question, if I may: The chromium vaapi track is gone for good, isn't it? [18:32] 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] ah, great to hear. I'm looking forward to it! [21:12] seb128: libreoffice finally finished building [21:17] 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] hellsworth, actually, not sure if you know anything about the gnome-calendar snap? [21:23] It looks like it was one of the older snaps that was made and hasn't been updated to automatically build. [21:31] 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] the snapcraft.yaml is specifically pointing at source-tag: 3.30.0 [21:34] does ubuntu ship GNOME Calendar through snap by default? [21:35] feaneron, no [21:36] does Ubuntu Store prefer the snap version of Calendar when installing or searching? [21:37] feaneron, the snap version shows earlier in the searches. [21:38] :( [21:39] it's not as terrible as it could be, but it's not ideal either [21:40] 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] marcustomlinson, was it using the current platform snap stuff? [21:41] It's currently using the gnome-3-28 platform [21:42] EDS versions, I think [21:42] aha [21:43] We're working on getting GNOME as a publisher in the store as well [21:44] The problem is compatibility with the host version of EDS for bionic and other supported releases [21:44] I'll make sure we get it updated over the next few weeks [21:45] feaneron, what does the calendar flatpak do for eds compatibility? Just not work on older releases? [21:45] And if we can get the yaml merged upstream we can get an autobuild setup as well [21:45] It runs it's own daemon in the sandbox [21:46] Right now, nothing; this EDS transition is being really painful [21:46] That's our holdup [21:46] 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] We want it to work with EDS in 18.04 [21:47] that's quite a doozy [21:47] 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] that's what the development Flatpak of Calendar used to do, and it's really annoying [21:48] Right [21:48] Which is why I stopped updating the snap [21:49] feaneron: I'm open to suggestions :-) [21:50] Me too. I just can't find a solution where we win this fight. [21:50] :-\ [21:50] Beyond, of course, make Calendar not use EDS at all [21:50] which also means loosing all platform integration [21:50] feaneron: I'll see if jamesh might have ideas [21:51] Losing platform integration would suck [22:23] marcustomlinson, thx, seems like it picked the slowest buildd or something! [22:24] yeah crazy slow [22:37] 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] 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] System services are generally better done. [22:50] 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] ahayzen, I guess portals will abstract away some of the simpler cases, but the more complex stuff like EDS will be harder. [22:57] 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] ahayzen, no, that's not expected - do you have a backtrace? [22:58] I'll spin up my F31 VM and try building it there. [23:01] robert_ancell, i can get one :-) [23:01] * ahayzen spins up VM [23:08] 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] Interesting (in a bad way) [23:09] :-) [23:09] It might be a threading issue, but if I can easily reproduce that is useful. [23:09] 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] this is a KVM VM with 2 CPUs and 3096 MB RAM for reference [23:11] ah, good. We're both on VMs. [23:13] ahayzen, I only give my VMs 2048 MB :) [23:14] hehe i usually do as well, but as i was building stuff i thought i'd give it more :-) [23:14] Though I just updated my laptop from 8GB to 16GB, so I now have some more RAM for hungry VMs [23:59] ahayzen, https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/372 [23:59] GNOME issue (Merge request) 372 in gnome-software "snap: Don't try to get alternatives for non-snaps" [Opened] [23:59] Thanks for letting me know!