You are not logged in.

#1 Re: Pacman / Pacman Upgrades » libglvnd: conflicting files to mesa » Yesterday 05:47:53

I think it's a new bug of a similar kind. :-)
Because I'm pretty sure I fixed the old duplicate files (3 files or so).

#2 Re: Pacman / Pacman Upgrades » libglvnd: conflicting files to mesa » 2019-10-20 17:09:49

Every version of libglvnd seems to swallow more and more files from mesa..

#3 Pacman / Pacman Upgrades » libglvnd: conflicting files to mesa » 2019-10-20 17:08:50

andreas_baumann
Replies: 7

error: failed to commit transaction (conflicting files)
libglvnd: /usr/include/EGL/egl.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/EGL/eglext.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/EGL/eglplatform.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GL/gl.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GL/glcorearb.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GL/glext.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GL/glx.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GL/glxext.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GLES2/gl2.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GLES2/gl2ext.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GLES2/gl2platform.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GLES3/gl3.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GLES3/gl31.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GLES3/gl32.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/GLES3/gl3platform.h exists in filesystem (owned by mesa)
libglvnd: /usr/include/KHR/khrplatform.h exists in filesystem (owned by mesa)
Errors occurred, no packages were upgraded.

experiences on pentium4/stable.

#4 Re: Building » Building AUR package with only x86_64 support » 2019-10-12 16:04:32

As Scimmia pointed out nicely on the AUR, the last version supporting 32-bit is masterpdfeditor 4, there is no version 5 anymore supporting 32-bit.
So forget my comment above.

#5 Re: Building » Building AUR package with only x86_64 support » 2019-10-12 06:31:47

On https://code-industry.net/free-pdf-editor/#get I saw:

32 bit - For CentOS/RedHat 6.x, Ubuntu 12.x - 14.x
Requirements: Qt 4.6.2 or later

master-pdf-editor-5.4.38.i386.tar.gz

so:

arch=('x86_64' 'pentium4')
source_pentium4=("https://code-industry.net/public/master-pdf-editor-${pkgver}.i386.tar.gz")
sha1sums_pentium4=('1017c28438d6f2946a52af0afa9c150c7e24d106')

does the trick.

#6 Pacman / Pacman Upgrades » akregator: linking error » 2019-10-09 08:29:59

andreas_baumann
Replies: 0

[guest@arch32-stable-pentium4 ~]$ akregator: symbol lookup error: /usr/lib/libKF5AkonadiContact.so.5: undefined symbol: _ZN9KContacts13AddresseeListC1ERKS0_
akregator: symbol lookup error: /usr/lib/libKF5AkonadiContact.so.5: undefined symbol: _ZN9KContacts13AddresseeListC1ERKS0_

#8 Re: Installation » [SOLVED] xfce4-screenshooter not working » 2019-09-29 17:52:48

Aha, now I understand: glib2-patched-thumbnailer is a AUR package providing glib2.
As you can see on https://aur.archlinux.org/cgit/aur.git/ … humbnailer
it got updated somewhere in early September to version 2.62.

So, as long as you installed this AUR replacement for glib2, pacman didn't replace it
with a newer one from 'core'. So if you replace a core package with an AUR one, and
that one doesn't get updated the same time as the core one, you are in for trouble.

I personally don't find it a smart idea to replace something in core with something
self-built, but I don't know the case here exactly. My feeling is, that those AUR packages
should try to get into the core PKGBUILD, by providing patches and start the discussion
in bugreports, otherwise they are basically forking from the main Archlinux distro.

#10 Re: Installation » [SOLVED] xfce4-screenshooter not working » 2019-09-29 08:28:44

I have libsoup 2.68.1-1.1, that's where there reference to the symbol g_file_info_get_modification_date_time is referenced.
This function is new in GLib 2.62 (package glib2-2.62.0-1.1).

I cannot reproduce this on by Archlinux32/i686/stable test machine.

Can you please post also the version numbers of your libsoup and glib2?

What I can think of:
- libsoup is not installed (but should be a dependency of xfce4-screenshooter, so it should get
  installed along with it)
- glib2 or libsoup are installed, but are an old version
- you have done some partial updates (which are not supporter, neither in Archlinux32 nor
  Archlinux itself)

#11 Re: Installation » [SOLVED] xfce4-screenshooter not working » 2019-09-28 07:19:56

Works fine on the pentium4/stable and i686/stable, I cannot reproduce this.
I have xfce4-screenshooter 1.9.6-1.1, what's your version?

#12 Re: Creating/Maintaining Packages » [FIXED] 32-bit Chromium no longer stuck on old version? » 2019-09-28 06:43:46

"The bigger the company, the worse the build enviroment" (personal 25 year experience in IT)

#13 Re: Creating/Maintaining Packages » [FIXED] 32-bit Chromium no longer stuck on old version? » 2019-09-28 06:34:09

Forgot to regenerate gn.

Sweet new build systems: instead of 'LDFLAGS=xxx make' you have to regenerate the generator, so
it can generate ninja files with LDFLAGS in them. I don't know what they are smoking at Google, but... :-)

#14 Re: Creating/Maintaining Packages » [FIXED] 32-bit Chromium no longer stuck on old version? » 2019-09-27 16:15:41

Ok, local patching h264 failed, the -DPIC doesn't do much in the yasm code, so the only way is allowing text segment fiddling in the linker
(as Slackware is doing it). Testing.. :-)

#15 Re: Creating/Maintaining Packages » [FIXED] 32-bit Chromium no longer stuck on old version? » 2019-09-27 13:19:53

Yeah, I saw this

             SLKLDFLAGS="-Wl,-z,notext"; LIBDIRSUFFIX=""

also Gentoo does the same.

But this is a little bit brutal, I would like to patch openh264 to add -DPIC here:

build/linux/unbundle/yasm.gn
if (current_cpu == "x86") {
  _yasm_flags = [
    "-DPIC",
    "-felf32",
    "-m",
    "x86",
  ]

#16 Re: Pacman / Pacman Upgrades » [solved] pcmanfm-qt mount problem ------------------------- fuse » 2019-09-26 17:45:20

Yeah, more Gnome stuff breaking. I don't event get mutter to start. gnome-shell segfaults now (this is on testing).
On stable gnome-session and quite some Gnome apps are broken.
We try to rebuild things, but the current status of Gnome makes it hard.

#18 Re: Creating/Maintaining Packages » [FIXED] 32-bit Chromium no longer stuck on old version? » 2019-09-26 08:55:48

Ok. wrongly put. Not the fact they are struggling is nice, the fact they care to build 32-bit chromiums.. :-)

#19 Re: Creating/Maintaining Packages » [FIXED] 32-bit Chromium no longer stuck on old version? » 2019-09-26 07:26:18

Ok. We have completly different problems, but thanks for the blog post, nice to see also other people are struggling with 32-bit builds. :-)

#20 Re: Creating/Maintaining Packages » [FIXED] 32-bit Chromium no longer stuck on old version? » 2019-09-25 18:57:52

Sorry for the really late answer. Archlinux32 chromium is stuck in some hand-crafted code:

>>> referenced by ../../third_party/openh264/src/codec/common/x86/dct.asm
>>>               openh264_common_yasm/dct.o:(.text+0x520) in archive obj/third_party/openh264/libopenh264_common_yasm.a

and in linking issues like:

ld.lld: error: can't create dynamic relocation R_386_32 against local symbol in readonly segment; recomp
ile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output

Thanks for link, I'll have a look at it..

#21 Re: System Administration » mate-panel segfault » 2019-09-25 17:21:54

Yes, sorry about Gnome, but it will re-emerge. Just needs some work.. :-)

#22 Re: System Administration » mate-panel segfault » 2019-09-25 05:21:31

Then yes, librsvg2 needs a rebuild with a rust which doesn't produce SSE2 opcodes, the problem is currently rust refuses to rebuild
on i686, see https://bugs.archlinux32.org/index.php? … task_id=71

I'm currently testing on my Pentium3 without SSE2 and it shows problems in various places:
- firefox
- thunderbird
- librsvg2
- libbabl/libgegl (used by gimp)

Though the latest one could also pe micro-optimized in the package itself or SSE2 is produced
by the gcc/binutils toolchain.

Also Gnome has some many broken packages currently, that it's a major effort to even do a
rebuild on pentium4 or x86_64.

#23 Re: Installation » [SOLVED] Cannot start outdated gimp » 2019-09-24 18:38:02

gimp uses mypaint-brushes1 apparently (and the dependency is in gimps PKGBUILD).
https://www.archlinux.org/packages/extr … t-brushes/
so mypain-brushes 2 is not used by anything? Well, not yet most likely. :-)

#24 Re: Installation » [SOLVED] Cannot start outdated gimp » 2019-09-24 18:34:04

Thaks cx for testing that, should be fixed now. I personally never use gimp, so I didn't know you have to install paint brushes separately..

#25 Re: Installation » [SOLVED] Cannot start outdated gimp » 2019-09-24 18:30:30

Cannot reproduce conflicting files for both gimp mypaint-brushes1 on pentium4 nor on x86_64 upstream. Are you on stable
for all packages? Do you have a stable mirror? Maybe mypaint-brushes and mypaint-brushes1 are in conflict (but not
marked as sich in the corresponding PKGBUILDs)?

Aha: mypaint-brushes is in fact a mypaint-brushes1, so mypaint-brushes (2) is not built or not published. Let me check..

Board footer

Powered by FluxBB