Artix Linux Forum

That's what package managers exist for: they workaround shit like this, put files into temporary archives and then make it possible to install it (usually) without problems. So yes, you should either use pacman-based solution (AUR included) or pip.
Also, never install custom programs to /usr, only to /usr/lib. Do not mixed managed files with unmanaged ones.

Quote from: ####### – on Yesterday at 14:22:33

You meant /usr/local not /usr/lib I guess? 

Yup, mistyped

Quote

Also, never install custom programs to /usr, only to /usr/lib. Do not mixed managed files with unmanaged ones.

You meant /usr/local not /usr/lib I guess? 

I git cloned the source for pydns you used, and the phrase "bin" doesn't appear anywhere in there when I searched it, and from a quick look at some of the build files I couldn't see anything obvious which would delete /usr/bin.  So I don't know where that came from, perhaps it's something to do with some python config on your system elsewhere which became relevant when you ran setup.py, but I don't know much about this python build process either. It might not be pydns that caused the issue though, but some other unconfigured or poorly configured python related package.

On 3/28/25 1:01 PM, Ian B wrote:
> So, a few bits to check....(what distro is this on?)
>
it is on artix

> do an 'updatedb' as root/sudo, to rebuild your file search db
find?
pacman -Ss imlib2
world/feh 3.10.3-1 [installed]
    Fast and light imlib2-based image viewer
world/imlib2 1.12.4-1 [installed]

[www3 ~]# find / -mount -iname "libim*" -print
/usr/lib/libImlib2.so.1.12.4
/usr/lib/libImath-3_1.so.29.11.0
/usr/lib/libImath.so
/usr/lib/libImath-3_1.so.29
/usr/lib/libImlib2.so.1
/usr/lib/libImlib2.so
/usr/lib/libImath-3_1.so


there is also - FWIW
find / -mount -iname "imlib*" -print
....

/usr/bin/imlib2_test
/usr/bin/imlib2_bumpmap
/usr/bin/imlib2_conv
/usr/bin/imlib2_view
/usr/bin/imlib2_grab
/usr/bin/imlib2_colorspace
/usr/bin/imlib2_poly
/usr/bin/imlib2_load
/usr/bin/imlib2_show
/usr/lib/pkgconfig/imlib2.pc
/usr/lib/imlib2
/usr/share/imlib2
/usr/share/imlib2/data/images/imlib2.png
/usr/share/licenses/imlib2


and here is the image trnaslators that are used in load
ls -al /usr/lib/imlib2
[www3 ~]# ls -al /usr/lib/imlib2/loaders/
total 432
drwxr-xr-x 2 root root  4096 Mar 28 08:19 .
drwxr-xr-x 4 root root  4096 Oct  9  2017 ..
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 ani.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 argb.so
-rwxr-xr-x 1 root root 18328 Mar 17 20:36 bmp.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 bz2.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 ff.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 gif.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 heif.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 ico.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 id3.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 j2k.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 jpeg.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 jxl.so
-rwxr-xr-x 1 root root 18328 Mar 17 20:36 lbm.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 lzma.so
-rwxr-xr-x 1 root root 18328 Mar 17 20:36 png.so
-rwxr-xr-x 1 root root 18328 Mar 17 20:36 pnm.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 ps.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 qoi.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 svg.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 tga.so
-rwxr-xr-x 1 root root 18328 Mar 17 20:36 tiff.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 webp.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 xbm.so
-rwxr-xr-x 1 root root 18328 Mar 17 20:36 xpm.so
-rwxr-xr-x 1 root root 14232 Mar 17 20:36 zlib.so

>
> locate loaders | grep imlib2
>
> Does it show the jpeg.so file ? Eg /usr/lib64/imlib2/loaders/jpeg.so
>
See above

> If you do ldd /usr/lib64/imlib2/loaders/jpeg.so (or whatever from previous
> output)   any errors ?
[www3 ~]# ldd /usr/lib/imlib2/loaders/jpeg.so
 linux-vdso.so.1 (0x00007bef70eb4000)
 libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007bef70def000)
 libc.so.6 => /usr/lib/libc.so.6 (0x00007bef70c01000)
 /usr/lib64/ld-linux-x86-64.so.2 (0x00007bef70eb6000)
[www3 ~]#

don't look like an error


[www3 ~]# ls -al /usr/lib/libjpeg.so.8
lrwxrwxrwx 1 root root 16 Dec 28 11:39 /usr/lib/libjpeg.so.8 -> libjpeg.so.8.3.2

Don't know what this is

[www3 ~]# ldd /usr/lib/imlib2/loaders/jpeg.so
 linux-vdso.so.1 (0x00007bef70eb4000)

find / -mount -iname "linux-vdso.so.1" -print comes blank


>
> Does it show a lib for jpeg, eg
>
> libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007f47fc6e2000)
>
> On Fri, Mar 28, 2025 at 3:55 PM Ruben Safir <ruben@mrbrklyn.com> wrote:
>
>> On 3/28/25 10:46 AM, Ian B wrote:
>>> and maybe just check the obvious, if you do "file
>>> /home/ruben/20130303_133505.jpg" does it say its a JPEG ? (assuming on
>>> Linux)
>>>
>> yes
>>
>>
>> --
>> So many immigrant groups have swept through our town
>> that Brooklyn, like Atlantis, reaches mythological
>> proportions in the mind of the world - RI Safir 1998
>> http://www.mrbrklyn.com
>> DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
>>
>> http://www.nylxs.com - Leadership Development in Free Software
>> http://www.brooklyn-living.com
>>
>> Being so tracked is for FARM ANIMALS and extermination camps,
>> but incompatible with living as a free human being. -RI Safir 2013
>>
>

This is the 3rd report (the 1st 2 not in this forum) I noticed in the past 10 days about this issue.
It might very well be related to a kernel change.

This could very well be related to https://bugzilla.kernel.org/show_bug.cgi?id=118721

Comments 9 and 10 show workarounds:

Quote

Disabling TSO seems to have fixed the problem for me. (I needed to set it after a fresh boot, *before* the interface starts bailing out continually.)

Quote

Also hit this issue - might be helpful to others, reloading the module with the parameter Node=0 (The NUMA node my NIC is on - modprobe e1000e Node=0) appears to have worked around the issue.

I suggest to try these, also to clarify if it indeed is the same problem as reported here.

artist