incorrect kde desktop behavior after update

intord · n00b Joined: 12 Aug 2017 Posts: 33

after installing these packages yesterday kde desktop was seriously broken:

wrc1944 · Posted: Fri Sep 28, 2018 8:52 pm Post subject:

Maybe try: https://wiki.gentoo.org/wiki/Project:Perl/perl-cleaner
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

intord · n00b Joined: 12 Aug 2017 Posts: 33

I am interested how soon it will be identified and fixed. all perl packages in that install were N so new not update. Technically if i understand correct, i can even avoid installing them

wrc1944 · Posted: Fri Sep 28, 2018 11:08 pm Post subject:

Did you run the following to see what it reports?

intord · n00b Joined: 12 Aug 2017 Posts: 33

well revdep-rebuild was always fine. i ran perl-cleaner and logged out however same thing.
sounds like legitimate bug, nothing else.

Perfect Gentleman · Veteran Joined: 18 May 2014 Posts: 1249

intord · n00b Joined: 12 Aug 2017 Posts: 33

Hu · Moderator Joined: 06 Mar 2007 Posts: 21619

As I interpret the perl-cleaner documentation, --reallyall tells it to find and rebuild every package that is connected to Perl in certain ways, regardless of whether the package is currently considered broken. If so, then it would be a bug if it failed to rebuild a package that is linked to Perl. It would not be a bug that it tries to do a useless rebuild, because that is what you told it to do. If you still think this is a bug in perl-cleaner, please describe it according to the typical conventions for bug reports: versions involved, expected results, actual results, etc.

intord · n00b Joined: 12 Aug 2017 Posts: 33

I never said its a perl-cleaner bug, i said (see post #1) that after those packages are installed, incorrect behavior started in KDE. For me it simply means that developer who did that did not do integration tests and pushed packages as long as it worked fine in his environment only. And if this is a case, its very bad. Unfortunately i do not code on Perl so i cannot open up those files and figure out what the problem might be. But i definitely know if a developer does something like that in any of the projects i worked on, he will be fired next day. Well, in a paid software world.

Now about the issue. I even do not know where to start to investigate a problem here. Is it a config problem? Well i followed everything accordingly to the upstream instructions. Is it a new functionality breaking the old one? Looks like for me (as all packages are new in that set), but in this case developers typically provide a set of instructions/notes etc for steps. Otherwise how do you know where to look for a core problem? Unless you are a gentoo developer only

asturm · Developer Joined: 05 Apr 2007 Posts: 8935

None of those packages would influence KDE Plasma runtime behavior...

Hu · Moderator Joined: 06 Mar 2007 Posts: 21619

You said it was clearly a bug, after the topic veered into discussing perl-cleaner. It looked to me like you were alleging that perl-cleaner had a bug for it to pick the set of packages that it did.

In the paid software world, packages go through internal testing before they go out to demanding users. If the developer broke things as badly as you say, and no one in the test department caught it, there would be plenty of blame to go around.

intord · n00b Joined: 12 Aug 2017 Posts: 33

Ok guys thanks for your useless help. Moving out of this shit. Unfortunately I cannot afford to spend hours and days on fixing unknown things. Need a working system but not a system which should be continuously fixed.

Marlo · Veteran Joined: 26 Jul 2003 Posts: 1591

Hu · Moderator Joined: 06 Mar 2007 Posts: 21619

We also cannot afford to spend hours fixing problems that don't even affect us. If you need help, post a good problem report. Linking to Google drive and asking us to watch videos to see the problem is not a good problem report. Dumping a long list of suspect packages, the vast majority of which cannot actually be at fault, is not a good problem report. I suggest you start by isolating which package(s) directly contribute to the problem. If reverting a package to an older version has no impact on the problem, then that reverted package does not contribute to the problem. Once you have identified the guilty packages, then you or we can narrow in on what specifically in that package is at fault.