[00:13] <lubot> [telegram] <teward001> Forwarded from Eickmeyer: So, RE: the merge request: experimental Lintian tags are shaky ground to go on to begin with because they may or may not become policy. We cannot assume they will become policy, so unless they become policy, they should not be addressed.
[00:13] <lubot> [telegram] <teward001> 
[00:13] <lubot> [telegram] <teward001> The other issue is that, unless liblxqt becomes a dependency, this is a non-issue, as it's not a dependency for everything currently, from what I understand, or at least it doesn't need that variable just yet.
[00:13] <lubot> [telegram] <teward001> 
[00:13] <lubot> [telegram] <teward001> Therefore, this does look like a wishlist item at best, out-of-scope at worst.
[00:13] <lubot> [telegram] <teward001> cc arraybolt3 and tismonq2
[00:13] <lubot> [telegram] <teward001> basically i just forwarded this straight from Erick's messages to me here
[00:13] <lubot> [telegram] <teward001> he can vouch for it
[00:13] <lubot> [matrix] <arraybolt3> *tsimonq2
[00:13] <lubot> [telegram] <teward001> oh wow the prosecco is already kicking in xD
[00:13] <lubot> [telegram] <teward001> (poor person's champagne)
[00:14]  * lubot [matrix] <eickmeyer> cue political ad
[00:14]  * lubot [matrix] <eickmeyer> My name is Erich Eickmeyer and I approve this message.
[00:14] <lubot> [matrix] <arraybolt3> If you can change Simon's mind, go right ahead and I'll go along with it. :P Otherwise I'll wait for his input (unless the Council overrides him), or if that is impractical, I'll use the fallback plan of "chuck the Debian symbols and maintain them in Ubuntu instead". At least I *think* that's the plan.
[00:15] <lubot> [matrix] <arraybolt3> (Personally I think ChangZhuo's logic is solid, and I'd be convinced to drop the symbols at this point, between his logic and my research. I'm just not about to overrule a seasoned Core Dev when I'm a newbie.)
[00:17] <lubot> [telegram] <teward001> i mean
[00:17] <lubot> [telegram] <teward001> I don't care what is done in Ubuntu
[00:17] <lubot> [telegram] <teward001> it's outside my purview
[00:17] <lubot> [telegram] <teward001> and though I don't care what is done in Debian either, my original thought is "Debian policy recommends not including UNLESS it's needed for something" but if it's not needed yet then the policy is clear to not include it
[00:17] <lubot> [telegram] <teward001> esp. if the team is following policy *recommendations*
[00:18] <lubot> [telegram] <teward001> so unless Simon is planning packages in Debian in the next few months that require symbols files for interdependency and stuff for building/running i would err on the side of caution and support the team and policy's recommendations currently
[00:19] <lubot> [telegram] <teward001> and since SImon hasn't justified himself there yet... :P
[00:19] <lubot> [telegram] <teward001> (my core dev recommendations don't have jack of an impact on Debian)
[00:21] <lubot> [matrix] <arraybolt3> I mean that's my feel from it too. ABI-breaking changes can be easily detected with a symbols file, but the symbols can be generated by the end user if they need them for that purpose, and that's probably less work than maintaining them. And all the other reasons for keeping them are hypothetical and currently not practical.
[00:22] <lubot> [matrix] <arraybolt3> And sure, Simon would like them maintained in Ubuntu, but we can just maintain them in Ubuntu for our own use and be happy.
[00:22] <lubot> [telegram] <teward001> i don't disagree, but i think that's the logic in their opinion - avoid the issues of also maintaining the file themselves to prevent 'oopsies' again.
[00:22] <lubot> [telegram] <teward001> but if Simon wants to take on maintaining the symbols in Ubuntu separately and the Release Team / etc. don't argue that's his option
[00:23] <lubot> [matrix] <eickmeyer> So, are we talking debug symbols or.... because those *should* be automatically generated as dbgsym.ddeb when the package is generated.
[00:23] <lubot> [matrix] <arraybolt3> Eickmeyer: Library symbols. You know, those miserably tricky thingies that require you to build on seven different arches to get right.
[00:23] <lubot> [matrix] <eickmeyer> Oh, those piles of.... {expletive removed}
[00:23] <lubot> [telegram] <teward001> eickmeyer: thanks for loaning your opinion too ;)
[00:25] <lubot> [matrix] <eickmeyer> @teward001 glad to help. :)
[00:25] <lubot> [matrix] <arraybolt3> My only reason for now going forward would be the lack of the Lubuntu Council's agreement. I think if Dan Simmons  and guiverc (and also Leo K and lynorian) would like to pitch in with their opinion, that would make me personally more comfortable with going forward from here. And I already know that Simon will accept the solution we're discussing (dropping the symbols in Debian).
[00:25] <lubot> [matrix] <arraybolt3> My only reason for not going forward would be the lack of the Lubuntu Council's agreement. I think if Dan Simmons  and guiverc (and also Leo K and lynorian) would like to pitch in with their opinion, that would make me personally more comfortable with going forward from here. And I already know that Simon will accept the solution we're discussing (dropping the symbols in Debian).
[00:25] <lubot> [matrix] <arraybolt3> (wow that was a typo)
[00:25] <lubot> [telegram] <teward001> arraybolt3: That'd be a Development Lead/Team decision for Lubuntu
[00:25] <lubot> [telegram] <teward001> not a Council decision
[00:26] <lubot> [telegram] <teward001> i'm in both teams ;)
[00:26] <lubot> [telegram] <teward001> so basically you just need kc2bez and guiverc's blessings
[00:26] <lubot> [matrix] <arraybolt3> Ah.
[00:26] <lubot> [telegram] <teward001> (technically speaking before I was on the COuncil I was an ancillary member of the devel team)
[00:26] <lubot> [matrix] <arraybolt3> 👍️
[01:01]  * guiverc is not a developer; thus would likely follow both kc2bez & teward advice with regards packaging/policy (I may try and understand everything, but not having used.... my understanding is less than ideal.. and far less than teward's)
[02:12] <arraybolt3> In the mean time, I think I'll try to work on picom and see how that goes, while also fighting with my Pentium III in the background.
[03:30] <lubot> [matrix] <arraybolt3> If we were to enable picom by default (which I hope we do as it has improved my experience with Lubuntu quite a bit), how would we do that? My first thought is a systemd unit. What would that be added to? lubuntu-default-settings perhaps? The picom package itself?
[03:53] <lubot> [matrix] <arraybolt3> Also, I'm realizing that things like how the "enable by default" is set up and what a "sane picom config" looks like may be opinion-based. If nobody minds, I'd like to just do it in a way that I think everyone will like, and we can tweak it after the fact, so that we can move ahead more quickly and easily. Is that acceptable?
[03:53] <lubot> [matrix] <arraybolt3> guiverc: ^
[03:56] <guiverc> I'd prefer advice come from kc2bez, teward or tsimonq2 .   If you don't get a response in time, do it how you think best applies, at worst you'll need to redo it.
[03:57] <lubot> [matrix] <arraybolt3> OK. I'll do the work I know I can do, and for the stuff I'm not sure on, I'll work on it but not upload it anywhere official (if I upload it to Git it will be to its own branch).
[04:04] <lubot> [matrix] <arraybolt3> We currently don't have a compton configuration file at all...
[04:51] <lubot> [matrix] <arraybolt3> From fiddling around with the config, I've come to the (somewhat sad) conclusion that we would probably be best off with no configuration file for picom at all. The bare defaults are actually what looks the most sane. The main features I noticed working with the config file, and why I think they aren't necessary:
[04:52] <lubot> [matrix] <arraybolt3> 
[04:52] <lubot> [matrix] <arraybolt3> * Opacity. Picom allows windows to be made semi-transparent when inactive, and this is specified in the sample configuration file. This sounds cool, but looks disastrous, as it's tricky for the user to know why their windows are seethrough sometimes, and aren't other times. For instance, a fullscreen Chrome window with Thunderbird behind it will appear opaque, but if a non-fullscreen terminal is given focus, Chrome will go transp
[04:52] <lubot> [matrix] <arraybolt3> * Fade in/out. This feature is actually really fancy, especially with the LXQt menu - it looked *so nice* at first. Sadly, the problem here is that LXQt is not really designed to work well with this feature - new parts of the menu that show up fade in and out, but then when the menu changes size (for instance, if the user searches for an app), it simply "snaps" to the new size, probably due to how LXQt works. This looks non-unifo
[04:52] <lubot> [matrix] <arraybolt3> * Rounded corners. This is something that GNOME has, but I don't remember Lubuntu ever having this (if it did have it, it was back in the LXDE days). This might look nice (though I haven't tested it), but from what I know of users' reactions to Microsoft's constant changing of the Windows UI, people don't like UI tweaks like that unless they make them themselves. I don't think it's worth risking users being like "you rounded my c
[04:52] <lubot> [matrix] <arraybolt3> * Window shadows. This is barely perceptible to the user, didn't add any aesthetic value for me even when I went out of my way to see them, and may needlessly consume resources (if only a tiny bit). I don't see the point.
[04:52] <lubot> [matrix] <arraybolt3> 
[04:52] <lubot> [matrix] <arraybolt3> This isn't to say that picom is useless - compositing may help with screen tearing, and it also enables transparency in panels (a feature I personally use and like very much). But those are things that I beileve picom can do without needing a configuration file at all (I know that the panel transparency is something that needs no configuration file). For these reasons, I believe the most sane configuration file we can use for pic
[04:53] <lubot> [matrix] <arraybolt3> Pinging Dan Simmons , @teward001, and Simon Quigley for their opinions on this.
[04:54] <guiverc> arraybolt3, given the length of the text in your opinions; I wonder if discourse (development section) would be a better place for your view/post; more readable than irc/matrix/telegram etc..  (also gives an easy place to find it in the future too)
[04:55] <arraybolt3> guiverc: Good point. I don't know if Dan or Simon (or Thomas) monitor Discourse that closely though.
[04:56] <guiverc> you still point them here to it.. (no reason you can't use both or multiple places..)... Discourse also allows end-users of Lubuntu to see the reasoning why Lubuntu doesn't come with a config as well.. not just for 'us' now...  (part of my thinking)
[04:56] <arraybolt3> +1, will copypaste into Discourse in the Development section.
[05:09] <lubot> [matrix] <kc2bez> Picom - from my testing we don't need our own config file. We need to examine the dependencies closely. We should be able to substitute Picom for Compton in the seed and be all set I think.
[05:09] <lubot> [matrix] <arraybolt3> Currently Picom is being pulled in by Compton itself :P
[05:10] <lubot> [matrix] <arraybolt3> ```
[05:10] <lubot> [matrix] <arraybolt3> arraybolt3@kf-XE:~$ apt-cache show compton
[05:10] <lubot> [matrix] <arraybolt3> Package: compton
[05:10] <lubot> [matrix] <arraybolt3> Architecture: amd64
[05:10] <lubot> [matrix] <arraybolt3> Version: 1-1
[05:10] <lubot> [matrix] <arraybolt3> Priority: extra
[05:10] <lubot> [matrix] <arraybolt3> Section: universe/x11
[05:10] <lubot> [matrix] <arraybolt3> Origin: Ubuntu
[05:10] <lubot> [matrix] <arraybolt3> Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[05:10] <lubot> [matrix] <arraybolt3> Original-Maintainer: Debian QA Group <packages@qa.debian.org>
[05:10] <lubot> [matrix] <arraybolt3> Bugs: https://bugs.launchpad.net/ubuntu/+filebug
[05:10] <lubot> [matrix] <arraybolt3> Installed-Size: 275
[05:10] <lubot> [matrix] <arraybolt3> Depends: libc6 (>= 2.29), libconfig9, libdbus-1-3 (>= 1.9.14), libgl1, libpcre3, libx11-6, libxcomposite1 (>= 1:0.4.5), libxdamage1 (>= 1:1.1), libxext6 (>= 2:1.3.0), libxfixes3, libxinerama1, libxrandr2 (>= 4.3), libxrender1
[05:10] <lubot> [matrix] <arraybolt3> 
[05:10] <lubot> [matrix] <arraybolt3> 
[05:10] <lubot> [matrix] <arraybolt3> >>>>>> Recommends: picom <<<<<<
[05:10] <lubot> [matrix] <arraybolt3> 
[05:10] <lubot> [matrix] <arraybolt3> 
[05:10] <lubot> [matrix] <arraybolt3> Filename: pool/universe/c/compton/compton_1-1_amd64.deb
[05:10] <lubot> [matrix] <arraybolt3> Size: 99664
[05:10] <lubot> [matrix] <arraybolt3> MD5sum: 97aa57c030ecd08e2f0436718f629e86
[05:10] <lubot> [matrix] <arraybolt3> SHA1: 156ff47ef933403e8b5348dc4e809bc2d4808f16
[05:10] <lubot> [matrix] <arraybolt3> SHA256: 1d8dbae0cad379259c27d68eb2ef4c7ce8a239aacab1d49b1a9fa791b5a0d59c
[05:10] <lubot> [matrix] <arraybolt3> SHA512: b809e7f3261b32f76454bac115aa179fb0c85894bb65b63b39c3f437e1cdd37319340c86d88f48bb2649404fa08a66f90cec9ec9530b55e6e73a4e0aea3b2853
[05:10] <lubot> [matrix] <arraybolt3> Homepage: https://github.com/chjj/compton
[05:10] <lubot> [matrix] <arraybolt3> Description-en: compositor for X11, based on xcompmgr
[05:10] <lubot> [matrix] <arraybolt3>  compton is a compositor for X11, based on xcompmgr. In addition to shadows,
[05:10] <lubot> [matrix] <arraybolt3>  fading and translucency, compton implements window frame opacity control,
[05:10] <lubot> [matrix] <arraybolt3>  inactive window transparency, and shadows on argb windows.
[05:11] <lubot> [matrix] <arraybolt3>  .
[05:11] <lubot> [matrix] <arraybolt3>  This package is deprecated and will soon be removed, please switch to picom.
[05:11] <lubot> [matrix] <kc2bez> Right, which is weird
[05:11] <lubot> [matrix] <arraybolt3> So I think we can just get rid of compton-conf (which gets rid of compton) and then swap in Picom and be set.
[05:11] <lubot> [matrix] <kc2bez> I think you are correct
[05:11] <lubot> [matrix] <arraybolt3> OK. Well then your testing and my testing line up.
[05:15] <lubot> [matrix] <kc2bez> Not sure about the symbols situation. I don't feel like I have enough reasoning to go further than you did. I guess if they want to drop them as a team I don't know that we have much choice.
[05:19] <lubot> [matrix] <kc2bez> Back to Picom. If we want to start it we could create a `.desktop` file and put it in the autostart folder. The `.desktop` file could be part of default-settings.
[05:20] <lubot> [matrix] <kc2bez> We probably have an example of that from something else somewhere.
[05:20] <lubot> [matrix] <arraybolt3> Interestingly, we already do that with compton and I have never seen it running by default.
[05:21] <lubot> [matrix] <arraybolt3> I also don't see anything about compton in the LXQt Session Settings.
[05:21] <lubot> [matrix] <arraybolt3> Oh wait maybe it's disabled in the desktop file, I see something now.
[05:22] <lubot> [matrix] <arraybolt3> Yep. Hidden=true. Alright, that explains it.
[05:22] <lubot> [matrix] <kc2bez> You found the right thing
[05:22] <lubot> [matrix] <arraybolt3> OK. That's super easy to do then.
[05:22] <lubot> [matrix] <kc2bez> Yup
[05:22] <lubot> [matrix] <arraybolt3> Alright, I guess I'll hammer that out tonight (so long as nothing gets me hung up), and it should roll out by tomorrow if all goes well.
[05:23] <lubot> [matrix] <kc2bez> I won't be around my normal early tomorrow ;)
[05:23] <lubot> [matrix] <arraybolt3> No problem :) Happy New Year!
[05:24] <lubot> [matrix] <kc2bez> Happy new year to you too. 🎉
=== guiverc2 is now known as guiverc
[14:49] <lubot> [matrix] <arraybolt3> Managed to finish the seed and the meta last night, just pushed a lubuntu-default-settings change that does some packaging updates and also enables Picom by default.
[16:23] <lubot> [matrix] <kc2bez> Very nice! Thanks @arraybolt3
[23:47] <lubot> [telegram] <lynorian> Compositing by default means the manual will need some changes