[05:17] <mitya57> Trevinho: thank you!
[05:21] <mitya57> 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] <didrocks> good morning
[07:42] <oSoMoN> good morning desktoppers
[07:44] <didrocks> salut oSoMoN
[08:00] <oSoMoN> salut didrocks
[08:41] <ricotz> good morning :)
[08:41] <ricotz> oSoMoN, see pm
[08:50] <didrocks> hey ricotz
[09:01] <Laney> b0b0b0
[09:02] <didrocks> hey Laney
[09:09]  * Laney pats didrocks 
[09:10] <Wimpress> Morning desktoppers o/
[09:14] <didrocks> hey Wimpress
[09:14]  * Laney nods gravely towards Wimpress 
[09:14] <Wimpress> :-)
[09:14] <Laney> ("take him away")
[10:11] <seb128> good morning desktopers
[10:16] <didrocks> salut seb128
[10:16] <seb128> lut didrocks, en forme ?
[10:17] <talx> morning folks
[10:17] <talx> I'm looking for assitance with preseed installation
[10:17] <didrocks> seb128: ça va, et toi ?
[10:18] <talx> trying to figure out what I'm doing wrong for the third way in a raw
[10:18] <seb128> ça va :)
[12:57] <jbicha> 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] <jbicha> 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:36] <seb128> jbicha, can do for n-d
[13:39] <seb128> 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] <jbicha> they claim to be releasing a "stable" 0.1.0 next month: https://source.puri.sm/Librem5/libhandy/wikis/home
[13:40] <seb128> 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] <jbicha> because it might not be practical to merge those improvement in until gtk4
[13:40] <seb128> other experimentals widget libs like egg are usually included as copies
[13:40] <seb128> and?
[13:41] <seb128> egg has been around for years
[13:41] <seb128> still it doesn't need to be an external lib
[13:41] <seb128> what's GNOME r-t position on libhandy?
[13:41] <seb128> do they plan to add it to the core set?
[13:43] <jbicha> 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] <jbicha> 🤷 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] <seb128> 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] <seb128> I'm not sure how they decide to accept or not new depends as part of their platform though
[13:46] <seb128> 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] <seb128> if some wonder why retracing are failing recently in disco, bug #1815774
[15:23] <seb128> (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] <seb128> we are going to need to rebuild $things once binutils is fixed
[15:25] <Laney> good find
[15:25] <seb128> thx
[15:25] <seb128> doookooooo
[15:25] <Laney> binutils is crazy stuff
[15:26] <seb128> 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] <Laney> using libunwind or something?
[15:32] <seb128> 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] <seb128> but looks like libunwind would be good in that scenario, thx for the hint!
[15:43] <Laney> :>
[15:45] <seb128> does anyone know an example of a package that rebuild itself in an autopkgtest?
[15:46] <seb128> d_idrocks suggests doing that for rygel as part of the MIR to ensure that vala updates don't break it
[15:48] <Laney> that's a weird requirement, autopkgtests usually test runtime breakage really and archive rebuilds are used to detect ftbfs
[15:48] <Laney> you can do it with Restrictions: build-needed and a no-op test but like I say I wouldn't advise that
[15:48] <seb128> well, I can see the value of blocking vala updates is they break things
[15:49] <Laney> why doesn't it apply to any library?
[15:49] <seb128> but maybe that should be done fromt he vala side
[15:49] <Laney> autopktest isn't meant to be a general keep-the-archive-buildable service
[15:49] <seb128> you have a point there
[15:50] <seb128> we also don't fully archive rebuild to validate gcc updates :p
[15:50] <Laney> right, and these almost always do introduce a few failures
[15:50] <seb128> that was an optional suggestion on the MIR, I'm going to skip that for now
[15:51] <Laney> now a test in vala itself which builds a few programs (Restrictions: superficial probably) would be a nice thing
[15:51] <Laney> same for all libraries/compliers
[15:52] <seb128> right
[15:52] <seb128> Laney, thx for the input
[15:52] <Laney> you're welcome
[17:16] <andyrock> jbicha: https://code.launchpad.net/~azzar1/ubuntu/+source/gnome-online-accounts/+git/gnome-online-accounts/+merge/363144
[18:42] <mdeslaur> seb128: do you have a curl merge planned?
[18:42] <seb128> mdeslaur, no, but I can look at it tomorrow
[18:42] <mdeslaur> seb128: awesome, thanks
[18:42] <seb128> yw!