Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dot in Installed-Size when syncing RaspberryPi OS 12 packages #9613

Open
basdakkenhorst opened this issue Jan 10, 2025 · 4 comments
Open

Dot in Installed-Size when syncing RaspberryPi OS 12 packages #9613

basdakkenhorst opened this issue Jan 10, 2025 · 4 comments
Assignees
Labels
question Further information is requested

Comments

@basdakkenhorst
Copy link

Question

Allthough, not (or at least not yet) officially supported, I use Uyuni to sync Raspberry Pi OS 12 packages. I therefor make this a question, instead of a bug report.

Since at least a couple of months this fails with the following error:

2025/01/10 13:11:14 -00:00 Sync of channel started.
2025/01/10 13:11:14 -00:00 Repo URL: https://archive.raspberrypi.org/debian/dists/bookworm/main/binary-arm64
.....
2025/01/10 13:12:20 -00:00 Error during processing package wolframscript-14.1.0+20240822262-X:.arm64-deb.
invalid literal for int() with base 10: '6635.2451171875'
2025/01/10 13:12:20 -00:00 Exception: invalid literal for int() with base 10: '6635.2451171875'
2025/01/10 13:12:20 -00:00   Package batch #7 of 35 completed...
2025/01/10 13:12:26 -00:00 Error during processing package wolfram-engine-14.1.0+202408191410-X:.arm64-deb.
invalid literal for int() with base 10: '4341190.494140625'
2025/01/10 13:12:26 -00:00 Exception: invalid literal for int() with base 10: '4341190.494140625'

I found out that has something todo with a dot in the Installed-Size value of both packages.

In: http://archive.raspberrypi.org/debian/dists/bookworm/main/binary-arm64/Packages both packages are defined as follows:

Package: wolfram-engine
Version: 14.1.0+202408191410
Architecture: arm64
Installed-Size: 4341190.494140625
.....

Package: wolframscript
Version: 14.1.0+20240822262
Architecture: arm64
Installed-Size: 6635.2451171875

Workaround

I added the following to python/spacewalk/server/importlib/debPackage.py

import re
....
# pylint: disable-next=missing-class-docstring
class debBinaryPackage(headerSource.rpmBinaryPackage):
    # pylint: disable-next=dangerous-default-value
    def __init__(
        self, header, size, checksum_type, checksum, path=None, org_id=None, channels=[]
    ):
    .....
        # Fix some of the information up
        vendor = self["vendor"]
        if vendor is None:
            self["vendor"] = "Debian"
        payloadFormat = self["payload_format"]
        if payloadFormat is None:
            self["payload_format"] = "ar"
        if self["payload_size"] is None:
            self["payload_size"] = 0
        #
        # Ugly fix for . in payload_size when syncing/importing wolfram packages for RaspberryPi OS 12
        #
        if re.search("\.", self["payload_size"]):
            self["payload_size"] = 0

Since I applied above change the synchronization works again. Obviously, one could just as easily replace the dot, I do not use the wolfram packages myself, so all I really care about is that it doesn't break syncing.

What I do not know:

  • Why there is a dot in the Installed-Size of these 2 packages only in the first place? (Not Uyuni's problem, I'd say?)
  • Whether or not this should be handled by Uyuni (or perhaps: when Uyuni starts supporting RaspberryPi 12 as OS?)
  • If there are any other places in Uyuni's codebase where this should be handled / fixed or if my "fix" breaks other stuff

I figured I'd just share my "fix" as an FYI. Might save someone else a headache or maybe the base for a fix.

Last but not least:

Thanks for the great work, I really appreciate Uyuni!

Version of Uyuni Server and Proxy (if used)

Information for package Uyuni-Server-release:
---------------------------------------------
Repository     : @System
Name           : Uyuni-Server-release
Version        : 2024.12-241000.225.1.uyuni5
Arch           : x86_64
Vendor         : obs://build.opensuse.org/systemsmanagement:Uyuni
Support Level  : unknown
Installed Size : 1.4 KiB
Installed      : Yes (automatically)
Status         : up-to-date
Source package : Uyuni-Server-release-2024.12-241000.225.1.uyuni5.src
Upstream URL   : https://www.uyuni-project.org/
Summary        : Uyuni Server
@basdakkenhorst basdakkenhorst added the question Further information is requested label Jan 10, 2025
@m-czernek
Copy link
Contributor

Hi there,

thank you for reporting the issue. As far as I can tell, per [0], Installed-Size attribute should be rounded to 1KiB, so the root cause is incorrect package attribute. The package maintainers that build the wolfram packages should fix that.

However, I would say that on our side in Uyuni, we can also ensure that we round the installed size attribute to an int before we try to convert to int.

I'm keeping this issue open and will try to find time to fix this.

[0] https://www.debian.org/doc/debian-policy/ch-controlfields.html#installed-size

@m-czernek m-czernek self-assigned this Jan 16, 2025
@basdakkenhorst
Copy link
Author

Hi!

Thanks for your response. Indeed, the wolfram packages are to blame, I'll drop the maintainers an e-mail to make them aware of this.

Also: thanks for being pragmatic on this, input validation is obviously important, but in this case one could also argue that using package attributes in the wrong format is beyond scope and Raspberry Pi OS is not (or not yet) officially supported.

Not really a pressing issue either and the workaround is as simple as ugly.

Thanks again!

@basdakkenhorst
Copy link
Author

FYI:

Wolfram support replied swiftly:

"It does appear that the Installed-Size attribute of Wolfram packages for Raspberry Pi is not behaving properly. I have forwarded an issue report to our developers with the information you provided. I also included your contact information in my report."

I'll keep you posted on any further updates.

@m-czernek
Copy link
Contributor

m-czernek commented Feb 4, 2025

Hello @basdakkenhorst ,

I finally found the time to look into this. I reproduced the error and fixed it with #9726. Would you like to test the changes? If you don't have the time, no worries of course.

If so, before testing the diff, first please undo the changes you made in the workaround part of the issue description.
Then, as a root user, create the /usr/lib/python3.6/site-packages/test.patch file with the following content:

diff --git a/python/spacewalk/server/importlib/backend.py b/python/spacewalk/server/importlib/backend.py
index 644343f979e4..aad247294904 100644
--- a/spacewalk/server/importlib/backend.py
+++ b/spacewalk/server/importlib/backend.py
@@ -3360,16 +3360,21 @@ def _buildDatabaseValue(row, fieldsHash):
 def _buildExternalValue(dict, entry, tableObj):
     # updates dict with values from entry
     # entry is a hash-like object (non-db)
-    for f, datatype in list(tableObj.getFields().items()):
-        if f in dict:
+    for field, datatype in list(tableObj.getFields().items()):
+        if field in dict:
             # initialized somewhere else
             continue
         # Get the attribute's name
-        attr = tableObj.getObjectAttribute(f)
+        attr = tableObj.getObjectAttribute(field)
         # Sanitize the value according to its datatype
         if attr not in entry:
             entry[attr] = None
-        dict[f] = sanitizeValue(entry[attr], datatype)
+        try:
+            dict[field] = sanitizeValue(entry[attr], datatype)
+        except ValueError as e:
+            raise ValueError(
+                f"Cannot sanitize value from {field}={entry[attr]} to {type(datatype)}"
+            ) from e


 # pylint: disable-next=invalid-name
diff --git a/python/spacewalk/server/importlib/backendLib.py b/python/spacewalk/server/importlib/backendLib.py
index 535e82cca437..00ffe62a22d0 100644
--- a/spacewalk/server/importlib/backendLib.py
+++ b/spacewalk/server/importlib/backendLib.py
@@ -518,7 +518,10 @@ def sanitizeValue(value, datatype):
     if isinstance(datatype, DBdate):
         return str(value)[:10]
     if isinstance(datatype, DBint):
-        return int(value)
+        try:
+            return int(float(value))
+        except ValueError as e:
+            raise ValueError(f"Cannot convert {value} to int") from e
     return value

Then, change into the /usr/lib/python3.6/site-packages directory and apply the patch:

# Become root
sudo -i 
# Change into the dir
cd /usr/lib/python3.6/site-packages
# Apply the patch and make backups
patch -p1 -b < test.patch

Now, you can test the patch. In your case, this might mean removing the custom channel and executing the repo-sync again.

Finally, after you're done with the testing, you can undo the patch by using the orig files:

# Execute this still as root
cd /usr/lib/python3.6/site-packages
mv spacewalk/server/importlib/backend.py.orig spacewalk/server/importlib/backend.py
mv  spacewalk/server/importlib/backendLib.py.orig spacewalk/server/importlib/backendLib.py

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants