You are not logged in.
Dear arch32 team!
I am writing because after the latest system update I cannot start gimp. It complains we only have BABL 0.1.72 while it needs 0.1.74.
This seems like a simple issue of not having the latest babl in the arch32 repo and a broken dependency to not need it.
I guess this can be easily fixed. Is there any way we arch32 users can fix an issue like this so we can help arch32 people?
I mean... is there a way I can fix this myself and get the fixed package included in arch repos and stuff when things like this happen or all we need to / can do is that we report this?
Best regards,
Richard
Thank you for all your effort! Arch32 is my first arch I used and it is on my main laptop in daily use ;-)
Offline
Confirmed; it brings up a dialogue box alerting me to the dependency when I start it too. Gimp - the package - already has a dependency on babl listed, but it isn't versioned. I'm not sure how often this would need to be updated if it was versioned to be honest.
I'm not sure we can do that much to help with binary drops for example; that would open up the project to the possibility of bad and malicious code drops. Apparently the current version of GIMP is dated from Feb 27th on my systems, so I'm not sure what's slowing up the delivery of a newer babl.
Actually, looking on https://archive.archlinux32.org/packages/b/babl/ it shows me that there was a version 0.1.74 built in January this year. I've no idea why it's there but not on the repos. Some oversight, or is it being held back for some reason?
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Yeah, so I downloaded babl v0.1.74 and ran gimp. It complained about gegl, so I found a newer version of that in the archive (?), and now GIMP runs. It does spit out a few errors during startup, mainly:
GEGL-Message: 05:47:54.414: Module '/usr/lib/gegl-0.4/lens-correct.so' load error: liblensfun.so.2: cannot open shared object file: No such file or directoryBut that doesn't stop it starting. I guess I might have trouble converting my camera's RAW files in it now judging by that error.
On second thoughts, there is a newer lensfun on the archive, so I installed that and it cleared the errors (?!?). The only remaining one is an error from a file-ps plugin called libgl.so.9 but I don't have any libgs.so and I can't guess where that comes from. Traditionally at least, gimp always bawls about something though, so I think I'll leave it. I don't use postscript files which I guess that is about anyway.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
I tried sudo pacman -Syu but it seems this package is not in yet. I see that I can download it as tar.xz and install manually I guess with pacman -U <package>.
If I install it manually for now it will not mess up later updating it with pacman in the usual way I guess.
"It complained about gegl, so I found a newer version of that in the archive (?), and now GIMP runs."
^^Do you mean in order to get updated-enough gegl all you had to do is a normal update (like -Syu)? Or you talk about some archive that I am not sure where is. Can you share its location then? :-)
Offline
Never mind. I have found it here:
https://archive.archlinux32.org/packages/g/gegl/
I do not understand. Isn't this archive the same where pacman looks for things? I mean, when I update from pacman servers they do not have these same packages I see here? I always thought they are the same, but now I see I can look into this archive and sometimes see newer stuff there than what I can update to. Good to know. ;-)
Offline
I spot that these files does not end with tar.xz, but tar.zst - can it be that for some reason "pacman -Syu" only sees the tar.xz ones or servers only serve those? Or maybe servers had some script to mirror the package archive themselves where they do not look for tar.zst?
I am only asking because all "old" packages seem to be tar.xz and new ones seem to be tar.zst - and only really recent ones are zst - all of which I do not see in the regular updates were so far having this extension. Maybe that is why we do not get these updates using a simple -Syu....
I am just guessing, but wanted to share my guess because if that is true, more packages must be affected by this silently.
Last edited by prenex (2020-03-20 13:11:56)
Offline
No, the compression changed to zst rather than xz earlier this year or at the tail end of last year, I forget exactly. That's normal, and all packages we have been receiving recently have been compressed using that.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline