[05:17] Trevinho: thank you! [05:21] I am going to make a new official compiz release today or tomorrow, hope you don't mind. It would be useful for other distributions like Arch. [07:29] good morning [07:42] good morning desktoppers [07:44] salut oSoMoN [08:00] salut didrocks === pstolowski|afk is now known as pstolowski [08:41] good morning :) [08:41] oSoMoN, see pm [08:50] hey ricotz [09:01] b0b0b0 [09:02] hey Laney [09:09] * Laney pats didrocks [09:10] Morning desktoppers o/ [09:14] hey Wimpress [09:14] * Laney nods gravely towards Wimpress [09:14] :-) [09:14] ("take him away") [10:11] good morning desktopers [10:16] salut seb128 [10:16] lut didrocks, en forme ? [10:17] morning folks [10:17] I'm looking for assitance with preseed installation [10:17] seb128: ça va, et toi ? [10:18] trying to figure out what I'm doing wrong for the third way in a raw [10:18] ça va :) === alan_g is now known as alan_g_ [12:57] seb128: do you want to try demoting notification-daemon again? I've added some alternate dependencies so maybe it will stick this time [13:19] also, we already got the first review of the libhandy MIR LP: #1815483 (I wasn't expecting that so soon, thanks!). There's a question there about whether we want Glade in main [13:19] Launchpad bug 1815483 in libhandy (Ubuntu) "[MIR] libhandy" [Undecided,New] https://launchpad.net/bugs/1815483 [13:36] jbicha, can do for n-d [13:39] jbicha, @libhandy, we don't want glade in main no, the -dev can stay in universe, also I'm not sure we want that lib at all in main until it's somewhat stable [13:40] they claim to be releasing a "stable" 0.1.0 next month: https://source.puri.sm/Librem5/libhandy/wikis/home [13:40] I'm still not sure why that lib exists/is needed, outside of being a playground with the goal to merge those widgets in gtk [13:40] because it might not be practical to merge those improvement in until gtk4 [13:40] other experimentals widget libs like egg are usually included as copies [13:40] and? [13:41] egg has been around for years [13:41] still it doesn't need to be an external lib [13:41] what's GNOME r-t position on libhandy? [13:41] do they plan to add it to the core set? [13:43] it's already there (gnome-contacts is part of GNOME Core and uses libhandy without embedding it) https://gitlab.gnome.org/GNOME/gnome-build-meta/tree/master/elements/core-deps [13:44] 🤷 some Fedora guys were saying the same thing that they want it to be an embedded library, but that's not really how it's being used right now [13:44] mclasen's comment on #gnome-hackers the other days suggested that he didn't think it should be a core lib for GNOME [13:45] I'm not sure how they decide to accept or not new depends as part of their platform though [13:46] anyway -1 from me to use as a lib until it's somewhat stable, sharing a moving target playground is just asking for problems imho [15:23] if some wonder why retracing are failing recently in disco, bug #1815774 [15:23] bug 1815774 in binutils (Ubuntu) "binutils 2.32 update breaks debug symbols in disco" [High,New] https://launchpad.net/bugs/1815774 [15:23] (I was wondering why the recent report from the g-c-c segfaults failed to retraced and ended up chasing it down to binutils) [15:23] we are going to need to rebuild $things once binutils is fixed [15:25] good find [15:25] thx [15:25] doookooooo [15:25] binutils is crazy stuff [15:26] we should have some autopkgtest testing that dbg still work when a binutils lands [15:26] * seb128 adds to his would-be-nice-to-add part of his todolist [15:28] using libunwind or something? [15:32] good question, I didn't give it much thinking yet, I was thinking maybe building a small package with a buggy .c example, install it/the dbgsym, start the buggy example under gdb and get a bt/check that it's in a debug format [15:33] but looks like libunwind would be good in that scenario, thx for the hint! [15:43] :> [15:45] does anyone know an example of a package that rebuild itself in an autopkgtest? [15:46] d_idrocks suggests doing that for rygel as part of the MIR to ensure that vala updates don't break it [15:48] that's a weird requirement, autopkgtests usually test runtime breakage really and archive rebuilds are used to detect ftbfs [15:48] you can do it with Restrictions: build-needed and a no-op test but like I say I wouldn't advise that [15:48] well, I can see the value of blocking vala updates is they break things [15:49] why doesn't it apply to any library? [15:49] but maybe that should be done fromt he vala side [15:49] autopktest isn't meant to be a general keep-the-archive-buildable service [15:49] you have a point there [15:50] we also don't fully archive rebuild to validate gcc updates :p [15:50] right, and these almost always do introduce a few failures [15:50] that was an optional suggestion on the MIR, I'm going to skip that for now [15:51] now a test in vala itself which builds a few programs (Restrictions: superficial probably) would be a nice thing [15:51] same for all libraries/compliers [15:52] right [15:52] Laney, thx for the input [15:52] you're welcome === alan_g is now known as alan_g_ [17:16] jbicha: https://code.launchpad.net/~azzar1/ubuntu/+source/gnome-online-accounts/+git/gnome-online-accounts/+merge/363144 === pstolowski is now known as pstolowski|afk [18:42] seb128: do you have a curl merge planned? [18:42] mdeslaur, no, but I can look at it tomorrow [18:42] seb128: awesome, thanks [18:42] yw!