Packaging discussion

[pallaswept]

Hi Luis,

Some time ago we discussed my packaging up your projects, over in #79. I'm terribly sorry, I somehow dropped the ball on this but when I saw a notification from you this morning I got right on it and finished it off in a few spare moments (lots of them hahaha) today... Well, I think I have finished it off, but perhaps you'd like to take a look.

https://build.opensuse.org/project/monitor/home:pallaswept:branches:home:luisbocanegra

Have I missed any?

I've tried to make all the packages uniform, similar to each other, so it'll be easy if you want to make a new one based on what you see there (basically just copypaste the wallpaper-effects spec file, change the name and version, and add any package-specific dependencies). I've tried to keep the conditional statements to a minimum as well, but a couple were unavoidable.

One of those conditional statements is to disable debuginfo builds on fedora (that line breaks them on opensuse). Debuginfo builds are now working, at least they are on opensuse, so perhaps those statements could be removed from the spec files if you'd like to have debug packages available there, too.

The old fedora builds fail because the Qt version they provide is older than the one required by spacer-extended. I could probably make that work for the other packages, but I wasn't sure if it's worth making the packages more complex just to accommodate the old fedoras. Correct me if I'm wrong, I am not a fedora user so I wouldn't know.

I've installed them all, and tested the ones that don't involve a desktop wallpaper. I can't really test the others since I don't really use a wallpaper, it's just boring old solid black here. I'm quite confident that they will work but it would be nice if someone could confirm that they really do.

It would also be great if someone could try installing them on fedora, to confirm that the runtime dependencies are all found. I did check via pkgs.org, and I could spin up a VM here to be more sure, but I figure there are probably lots of fedora users who might be able to help and would have a better idea if it's really working, and maybe be able to test the wallpaper magic as well.

I will submit these packages to your repo now, and we can discuss any details in the requests (similar to a PR on github) but I thought it might be handy to make an issue here to discuss the general stuff.

Many thanks for these awesome addons and I hope this is helpful.

[luisbocanegra]

Hi, this is awesome!

Have I missed any?

One of those conditional statements is to disable debuginfo builds on fedora (that line breaks them on opensuse). Debuginfo builds are now working, at least they are on opensuse, so perhaps those statements could be removed from the spec files if you'd like to have debug packages available there, too.

I think for the stuff that is QML only is fine, but if it's for simplicity and future proofing is okay to have debug symbols on all I think.

There are couple more but way less popular, I think you already did more than enough 🙂

The old fedora builds fail because the Qt version they provide is older than the one required by spacer-extended. I could probably make that work for the other packages, but I wasn't sure if it's worth making the packages more complex just to accommodate the old fedoras. Correct me if I'm wrong, I am not a fedora user so I wouldn't know.

Hmm given that Fedora 41 is already EOL and 42 will be in May 2026 I think it that is fine, after all I can only test my projects in the latest version of Plasma

It would also be great if someone could try installing them on fedora, to confirm that the runtime dependencies are all found.

I can install try all in a VM later but yes we will need more people testing them fully.

Many thanks for these awesome addons and I hope this is helpful.

It is! I am sure these packages will make many people happy specially with the ones that include C++.

Thank you for working on this ❤️

[pallaswept]

Hi Luis,

I spent a little time trying to get the kde-material-you-colors widget to install on fedora today, and I did resolve the problems you saw with the dependencies, but then I hit a bit of a tricky spot. I should ask you what direction to take here.

The pyproject.toml specifies python-magic as a requirement. The RPM build automatically detects this, and adds it to the package requirements, so the requirements I can set in the spec file can't override it. And there is already python-file-magic installed in fedora 43 (I ran up a VM with today's ISO), which conflicts with python-magic, so we can't install your widget package unless we allow dnf to remove the stock 'file-magic' package and replace it with the 'python-magic' package.

Maybe that is the simple path forward, I am not a fedora user or much of a python user so I hope you'll have some idea. Maybe the dependency could be changed in your project, or we could patch the .toml in the package build, or something like that... I'm sure I could make it work according to your suggestion.

Thanks!

Edit: since it was a live VM, I took the risk to overwrite the stock package. Everything worked. That's a very very pretty widget!!! I don't know if that package being removed would have any negative effects later but it sure looked nice :D

[luisbocanegra]

Hi, thanks again for working on this, seems to be a well known problem https://discussion.fedoraproject.org/t/is-it-possible-to-unravel-the-python-magic-packaging-clusterfsck/136792

or we could patch the .toml in the package build

And switch to python-file-magic as dependency for fedora, right?

I don't like the idea of replacing a default package, so that seems to be the way forward, I think.

The API of both projects is somewhat similar so it is a matter of checking which module to use, like this:

import magic
file_path = "/home/luis/file.py"

def main():
    if hasattr(magic, "from_file") and callable(getattr(magic, "from_file")):
        print("using python-magic")
        try:
            return magic.from_file(file_path, mime=True) == "text/plain"
        except Exception as e:
            print(f"Error:\n{e}")

    if hasattr(magic, "detect_from_filename") and callable(getattr(magic, "detect_from_filename")
    ):
        print("using python-file-magic")
        try:
            return magic.detect_from_filename(file_path).mime_type == "text/plain"
        except Exception as e:
            print(f"Error:\n{e}")

    return False

if __name__ == "__main__":
    print(main())

[pallaswept]

And switch to python-file-magic as dependency for fedora, right?

That's what I was thinking... but I confess, I've made a mistake and you've helped me catch it early so thank you! Turns out that not only does suse also have python-file-magic, but it's also installed by default and required by other installed packages. I hadn't tested suse yet, I went straight to fedora to try and fix the problem you reported, but we would have had it here, too. So I guess I'd just make that patch applicable to both distros.

It seems like the packages would need to patch the .toml file and also https://github.com/luisbocanegra/kde-material-you-colors/blob/79f3bcb7e96d04fab71f797ed9ebb047a90d52d8/src/kde_material_you_colors/utils/file_utils.py#L81 as you described above, is that right? Is this something we should keep in the package, or should I file a PR for it if I can make it work? I really don't know a lot of python, enough to make it work, but not enough to keep something else from being broken :D

[luisbocanegra]

And switch to python-file-magic as dependency for fedora, right?

That's what I was thinking... but I confess, I've made a mistake and you've helped me catch it early so thank you! Turns out that not only does suse also have python-file-magic, but it's also installed by default and required by other installed packages. I hadn't tested suse yet, I went straight to fedora to try and fix the problem you reported, but we would have had it here, too. So I guess I'd just make that patch applicable to both distros.

It seems like the packages would need to patch the .toml file and also https://github.com/luisbocanegra/kde-material-you-colors/blob/79f3bcb7e96d04fab71f797ed9ebb047a90d52d8/src/kde_material_you_colors/utils/file_utils.py#L81 as you described above, is that right? Is this something we should keep in the package, or should I file a PR for it if I can make it work? I really don't know a lot of python, enough to make it work, but not enough to keep something else from being broken :D

I think keeping it in the package feels more appropriate, but it's two places to keep in sync if I ever change that code, so I am more inclined to make the script able to work with the both implementations like the code above.

What do you think?

[pallaswept]

I wondered if the compatibility layer in python-magic take care of this, but the dependency hell was especially bad here, even for a mixed-python package (they're always rough!) so I have not tried it just yet. I ended up doing something like what you suggested above:

diff -urN kde-material-you-colors-2.0.0/pyproject.toml kde-material-you-colors-2.0.0b/pyproject.toml
--- kde-material-you-colors-2.0.0/pyproject.toml	2025-11-08 08:50:43.000000000 +1100
+++ kde-material-you-colors-2.0.0b/pyproject.toml	2025-11-30 06:22:32.235089810 +1100
@@ -23,7 +23,7 @@
     "numpy>=1.20",
     "pillow>=9.2.0",
     "materialyoucolor>=2.0.8",
-    "python-magic>=0.4.27",
+    "file-magic",
 ]
 
 [project.scripts]
diff -urN kde-material-you-colors-2.0.0/src/kde_material_you_colors/utils/file_utils.py kde-material-you-colors-2.0.0b/src/kde_material_you_colors/utils/file_utils.py
--- kde-material-you-colors-2.0.0/src/kde_material_you_colors/utils/file_utils.py	2025-11-08 08:50:43.000000000 +1100
+++ kde-material-you-colors-2.0.0b/src/kde_material_you_colors/utils/file_utils.py	2025-11-30 05:29:40.345651412 +1100
@@ -77,8 +77,18 @@
     """
     if file_path is not None:
         if os.path.exists(file_path):
-            try:
-                return magic.from_file(file_path, mime=True) == "text/plain"
-            except Exception as e:
-                print(f"Error:\n{e}")
-                return False
+            if hasattr(magic, "from_file") and callable(getattr(magic, "from_file")):
+                print("using python-magic")
+                try:
+                    return magic.from_file(file_path, mime=True) == "text/plain"
+                except Exception as e:
+                    print(f"Error:\n{e}")
+
+            if hasattr(magic, "detect_from_filename") and callable(getattr(magic, "detect_from_filename")):
+                print("using python-file-magic")
+                try:
+                    return magic.detect_from_filename(file_path).mime_type == "text/plain"
+                except Exception as e:
+                    print(f"Error:\n{e}")
+
+            return False

That does install and work on fedora and opensuse, and also worked if I cut out the rpm for file-magic and put python-magic in its place. The spec file needed a LOT of attention, to stop it from turning into conditional-build-spaghetti, but I think I've got it as clean as it can get. Fedora and opensuse really clashed (with each other and within themselves!) about naming schemas and the function of commonly named macros 😠

It installs and works on both distros, but I did see some errors on opensuse, only with certain wallpapers, I'd get an error like this:

But the colours did work after that message, so the fallback worked. I don't know if that's normal or if it's a problem with the changes I made. Opensuse only comes with one wallpaper, and it does cause this error, but most (not all) of the ones I can download from discover, are fine. Is it normal for a certain type of wallpaper to fail like this?

As for the .toml, I am not python-smart enough to know if it's possible to have a 'this or that' dependency of the python modules?

The spec files do have quite a few small changes, so I will need to push them again, along with either this patch, or perhaps part of it, I'm not sure if you want to put any of the above in your codebase?

Thanks for waiting for me this one was a doozy.

[pallaswept]

I think keeping it in the package feels more appropriate, but it's two places to keep in sync if I ever change that code, so I am more inclined to make the script able to work with the both implementations like the code above.

What do you think?

Sorry, I missed this reply!

I agree, it seems like if it's changed in the project here, then it might create some compatibility problems for existing installs. But then, it would be nice if the script worked with either library, for the same reasons.

I thought perhaps it might be good to put the code changes in file_utils.py in your repo, but leave the [dependencies] in the .toml as they are, and then the package can just use sed to alter the .toml dependency, rather than maintaining a patch, to ensure installing the package which works best on that distro/the script will work if there is a leftover python module by the other name.

Edit: If you want to try it out, this page should work for either distro, just choose the distro and then "Add repository and install manually"

[luisbocanegra]

I thought perhaps it might be good to put the code changes in file_utils.py in your repo, but leave the [dependencies] in the .toml as they are, and then the package can just use sed to alter the .toml dependency, rather than maintaining a patch, to ensure installing the package which works best on that distro/the script will work if there is a leftover python module by the other name.

Let's do that, tagged v2.0.1 with the change

[pallaswept]

I've updated the package, and pushed the submission request. You can test it out with the same link as above if you would like to double-check it before you accept.

[luisbocanegra]

I've updated the package, and pushed the submission request. You can test it out with the same link as above if you would like to double-check it before you accept.

It works 🎉

[luisbocanegra]

But the colours did work after that message, so the fallback worked. I don't know if that's normal or if it's a problem with the changes I made. Opensuse only comes with one wallpaper, and it does cause this error, but most (not all) of the ones I can download from discover, are fine. Is it normal for a certain type of wallpaper to fail like this?

I forgot to reply to this, yes, this is a pretty common behavior, some wallpapers (mostly dynamic ones) don't expose a property I can use to fetch the color, same thing happens if the wallpaper is still the default.

The fallback takes a screenshot of the desktop and uses that for color extraction