Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#63485 - [mate-control-center] mate-appearance-properties requires .so not provided by marco

Attached to Project: Community Packages
Opened by Prism Tutaj (Prism019) - Saturday, 17 August 2019, 03:53 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 26 August 2019, 18:49 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Brad Fanella (cesura)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 10
Private No

Details

Description:
mate-appearance-properties links to libmarco-private.so.1 but marco provides libmarco-private.so.2
I am unable to change my background due to this.

Additional info:
marco version 1.22.2-1
mate-control-center version 1.22.1-1

Steps to reproduce:
Run mate-appearance-properties
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Monday, 26 August 2019, 18:49 GMT
Reason for closing:  Fixed
Additional comments about closing:  I just moved mate-control-center 1.22.1-2 from [community-testing] to [community]
Comment by Eli Schwartz (eschwartz) - Monday, 19 August 2019, 15:33 GMT
Please don't suggest making incompatible shared libraries pretend to be something they are not.
Comment by Chris Winters (cwinters) - Monday, 19 August 2019, 15:49 GMT
As a workaround, it works. I didn't say it was smart. Temporarily, for the time being until the issue can be fixed and the right library can be added back, it works though.
Comment by Eli Schwartz (eschwartz) - Tuesday, 20 August 2019, 01:07 GMT
Stop that. It superficially seems to work just because you haven't seen it actually crash yet, but you have no idea what it's actually doing.

If it "worked" even as a "workaround", then people wouldn't bother with versions, because it "works". But you're literally asking for corruption, incompatible symbols, and undefined behavior. Data loss is just as likely as crashes. And the whole point of undefined behavior is it is unpredictable.

Don't do it. Don't suggest other people do it.

I did not comment because I was looking for an argument with you. I commented because I was laying down the law.

Thou Shalt Not Advise Others To Break Their System.
Comment by Eli Schwartz (eschwartz) - Tuesday, 20 August 2019, 05:02 GMT
> Until I see an admin or mod tag on your account you're just another keyboard warrior [...] go play god somewhere else please. We're trying to get a bug fixed here.

Flyspray does not add "tags" to user accounts. :) You may, however, click on a username to see which Flyspray group a given user is attached to.

Anyway, official Arch policy on faking the soname of a library remains https://wiki.archlinux.org/index.php/Frequently_asked_questions#If_I_need_an_older_version_of_an_installed_library,_can_I_just_symlink_to_the_newer_version?
We strongly discourage it in the general way of things, and tend to really dislike the idea of such hacks being suggested for broad consumption. There is *always* a better way.

And none of that is going to get the package fixed. Changes to the package will get the package fixed. Constructive discussion about fixing the package, is welcomed... discussion about modifying your own system to still execute the program is less welcomed, as it doesn't actually solve the bug, but it is also not against the rules. Advising people to use workarounds widely regarded as an antipattern starts veering into territory that *is* against the rules, and mixed in with insults means I'm likely to just start deleting comments. :(

Hopefully the package maintainer will respond soon. In the meantime, you can try downloading the PKGBUILD for mate-control-center, bumping the pkgrel to 1.1, and rebuilding it to see if that works. It likely will, although I see upstream has released a new mate-control-center 1.23.2 version as well.
Comment by Bassopt (bassopt) - Tuesday, 20 August 2019, 13:38 GMT
I agree with Eli, still it’s a shame that packages take so long to fix in arch. This is why I always end up moving to something else or just use it on secondary machines that I don’t mind things to break,

it's a complete shame that a package of this importance takes this long to fix.
Comment by Marko (Breadland) - Thursday, 22 August 2019, 01:23 GMT
For the time being, downgrading marco to 1.22.1-1 fixes the issue.

Then once mate-control-center gets fixed I can just upgrade both to the latest version have have no issues, right? Since I'm not messing around with any libraries.
Comment by Jonathon (jonathon) - Saturday, 24 August 2019, 14:15 GMT
A rebuild is all that's needed.

There's an upstream 1.23.2 release but that's the odd-numbered development series; the "normal" mate-control-center is still at 1.22.1 .
Comment by Bassopt (bassopt) - Sunday, 25 August 2019, 02:05 GMT
Besides being ridiculous slow fixing / updating things , this maintainer should be more careful updating matching packages (or in this case not updating when it doesn’t exist. )
Comment by Eli Schwartz (eschwartz) - Sunday, 25 August 2019, 02:56 GMT
I'm a bit confused why marco would bump their soname in the middle of a stable release cycle instead of leaving that for the development series, then. :p

I have to say it is a bit surprising to have soname bumps in a semver patchlevel release...
Comment by Eli Schwartz (eschwartz) - Sunday, 25 August 2019, 06:46 GMT
I've taken the liberty of rebuilding the package and uploading it to community-testing. Is anyone interested in enabling the testing repositories in their pacman.conf and verifying that things still work with mate-control-center 1.22.1-2?
Comment by JP Cimalando (jpcima) - Sunday, 25 August 2019, 21:08 GMT
1.22.1-2 from community-testing has fixed it.
Comment by Troy Engel (TE) - Monday, 26 August 2019, 14:07 GMT
+1 for 1.22.1-2 from community-testing
Comment by Bassopt (bassopt) - Monday, 26 August 2019, 18:07 GMT
yes community-testing works.

I had already tried this locally by modifying the PKGBUILD.

Main problem is that when I update my system still asks to update to 1.22.2. And that's what breaks mate-control-center (partially... as far as I noticied only appearence doesn't work)

Main problem is still that maintainer updated the Marco to a newer no a newer version (1.22.2) not only the soname (i think... sorry if im saying something stupid , still learning here!) and didn't notice that the remaining packages and depedencies are all on 1.22.1, still.

Previous version and your version on testing :

libmarco-private.so -> libmarco-private.so.1.0.0
libmarco-private.so.1 -> libmarco-private.so.1.0.0
libmarco-private.so.1.0.0

Version updated on 15-08-2019 by maintainer

libmarco-private.so -> libmarco-private.so.2.0.0
libmarco-private.so.2 -> libmarco-private.so.2.0.0
libmarco-private.so.2.0.0

This is what breaks mate-control center.
Comment by Eli Schwartz (eschwartz) - Monday, 26 August 2019, 18:48 GMT
And one of the mate-desktop developers mentioned on the Linux Mint slack channel that a simple rebuild should be sufficient, which confirms the solution as well.
That plus 3 confirmations seems good enough to me. :)

@bassopt,

For what it's worth, the difference between 1.22.1 and 1.22.2 is supposed to be "a bug fix specific to marco which can be updated on its own", so things like this should not break. I do not maintain mate-desktop, but I do maintain cinnamon, which is developed in a similar manner. Such bugfix releases are fairly common, and different desktop components don't need to match exact versions (one might have an update while others do not).

The issue is, apparently, simply because marco updated its ABI and soname in a bugfix release. My contact did say he didn't like it, but wasn't around to argue against it at the time...

It's unfortunate that that happened at all, and regrettable that we didn't catch it.

@cesura,

I find it helpful to run the `checkpkg` tool every time before I release a package, and if the package reports *any* changed filenames, I try to figure out if that would affect any other packages.

It would in this case have reported:
$ checkpkg
usr/lib/libmarco-private.so.1 | usr/lib/libmarco-private.so.2
usr/lib/libmarco-private.so.1.0.0 | usr/lib/libmarco-private.so.2.0.0
==> Sonames differ in marco!
libmarco-private.so=1-64 | libmarco-private.so=2-64


(plus a new locale, which doesn't matter)

That soname is suspicious in a patchlevel release and should anyway be double-checked for compatibility with other packages (sogrep -v community libmarco-private) in the hope of avoiding mistakes.

Loading...