no task description

no task description

Attached to Project: Archlinux32
Opened by Luke Shumaker - 21.09.2018
 FS#52  - Some packages are built by “Unknown Packager”

Some packages have

packager = Unknown Packager

, which is caused by

makepkg.conf:PACKAGER

not being set.

I analyzed every .pkg.tar.xz file in the Arch 32 repos (all architectures). The earliest Unknown Packager package was built on June 9, 2017, and they’ve been intermittent since then. Here’s a listing of how many times each packager appears:

    2  Dave Reisner 
    2  Fabio Castelli (Muflone) 
    2  Giancarlo Razzolini 
    2  Jelle van der Waa 
    2  Laurent Carlier 
    2  S?bastien Luttringer 
    2  schuay 
    3  Florian Pritz 
    3  Johannes L?thberg 
    4  Alexander R?dseth 
    4  Andreas Radke 
    4  Eli Schwartz 
    4  Tobias Powalowski 
    5  Gaetan Bisson 
    5  Jonathan Steel 
    6  Bart?omiej Piotrowski 
    6  Erich Eckner 
    7  Kyle Keen 
    8  Evangelos Foutras 
    8  Maxime Gauduin 
    9  Jaroslav Lichtblau 
    9  Lukas Fleischer 
   18  BlackEagle 
   21  Sergej Pupykin 
   22  Guillaume ALAUX 
   29  Sven-Hendrik Haase 
   32  Levente Polyak 
   35  Jan Alexander Steffens (heftig) 
   39  Felix Yan 
   43  Jan de Groot 
   44  Andreas Baumann 
   75  Ball? Gy?rgy 
   81  Antonio Rojas 
 6592  Unknown Packager
20577  Erich Eckner 
------------------------------------------------------------------
27707  total

This causes a problem for us in Parabola, because we just started applying the usual upload checks from

db-update

to packages that we import.

  Comments (3)
  Related Tasks (0/0)

bill auger commented on 24.09.2018 05:20

i was trying to make sense of this today and my results were pretty strange

i wrote a script to extract ‘Unknown Packager’ from the db caches in /var/lib/pacman/sync/ and i got very different counts then what luke reported - i ran the same script on both parabola i686 and again on arch32 - it did show that all of the packages by ‘Unknown Packager’ are in [extra], [community], and [core]

<pre>
$ wc -l ./unknown-packagers-parabola
1800 ./unknown-packagers-parabola

$ wc -l ./unknown-packagers-arch32
2250 ./unknown-packagers-arch32
</pre>

one thing i noted was that one of the packages (4ti2) that arch32 has by ‘Unknown Packager’ for v1.6.7 shows as v1.6.9 packaged by ‘Erich Eckner’ on parabola and the parabola package has a higher version number and later build date - maybe my mirrorlist is wonky on arch32 but it is the default one that was installed

<pre>
arch32:
package: 4ti2-1.6.7-1
build date: 1497644502
packager: Unknown Packager

parabola:
package: 4ti2-1.6.9-1.0
build date: 1536224793
packager: Erich Eckner
</pre>

the script i used is attached to the corresponding parabola bug report
https://labs.parabola.nu/issues/1652 https://labs.parabola.nu/attachments/444/find-unknown-packagers Admin
Erich Eckner commented on 24.09.2018 08:47

The buildmaster now rejects package built by “Unknown Packager” - what remains is to rebuild all packages, that are already committed.
Admin
Erich Eckner commented on 24.09.2018 08:54

btw: operating on the package database is much faster than extracting every single package:

find . -name ‘*.db.tar.gz’ | \

while read -r repo; do
  tar -Oxzf "${repo}" --wildcards '*/desc' | \
    sed -n '/^%FILENAME%$\|^%PACKAGER%$/{N;s/\n/ /;p;d;}'
done | \
sed '/^%FILENAME% /{N;/\n%PACKAGER% Unknown Packager$/!d;s/\n.*//;s/^%FILENAME% //;}'

Google Cache

icu69.1-1.0 however snapper still links against libicuuc.so.68

Running snapper now gives the following error:

# snapper list /
snapper: error while loading shared libraries: libicuuc.so.68: cannot open shared object file: No such file or directory

When trying to install the package, packman complies about the the key to be of unknown trust. Cheking the keyring the associated key appers to be expired.

ISO segfaults when pacstrapping.

Several (if not all) build slaves show key verification errors.

I don’t think, it’s the keys, but gnupg slowly failing us on 32-bit.

Workaround as always: SigLevel=Never

Trick question (and possibly bonus points): what to do, if gnupg cannot be fixed..

breaks in more SIMD optimizations.

Attached to Project: Archlinux32
Opened by Andreas Baumann - 01.02.2019
Last edited by Andreas Baumann - 12.05.2019
 FS#62  - sddm-greeter aborts

(gdb) bt
#0 0xb7fbea41 in kernel_vsyscall ()
#1 0xb6418746 in raise () from /usr/lib/libc.so.6
#2 0xb64021e3 in abort () from /usr/lib/libc.so.6
#3 0xb6793775 in QMessageLogger::fatal(char const*, …) const () from /usr/lib/libQt5Core.so.5
#4 0xb74da6fc in QV4::Compiler::Codegen::visit(QQmlJS::AST::UiProgram*) () from /usr/lib/libQt5Qml.so.5
#5 0xb756f446 in QJSEngine::QJSEngine(QJSEnginePrivate&amp;, QObject*) () from /usr/lib/libQt5Qml.so.5
#6 0xb76afe1d in QQmlEngine::QQmlEngine(QObject*) () from /usr/lib/libQt5Qml.so.5
#7 0xb7cf93bb in QQuickViewPrivate::init(QQmlEngine*) () from /usr/lib/libQt5Quick.so.5
#8 0x0050c571 in SDDM::GreeterApp::addViewForScreen(QScreen*) ()
#9 0x0050d1a4 in SDDM::GreeterApp::startup() ()
#10 0xb69a6a4e in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#11 0xb697a565 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#12 0xb697d8c6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
from /usr/lib/libQt5Core.so.5
#13 0xb697dcd9 in QCoreApplication::sendPostedEvents(QObject*, int) () from /usr/lib/libQt5Core.so.5
#14 0xb69d4f74 in ?? () from /usr/lib/libQt5Core.so.5
#15 0xb55bca1e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#16 0xb55beafa in ?? () from /usr/lib/libglib-2.0.so.0
#17 0xb55beb46 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#18 0xb69d44bb in QEventDispatcherGlib::processEvents(QFlags) ()
–Type for more, q to quit, c to continue without paging– from /usr/lib/libQt5Core.so.5
#19 0xb6978ff6 in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5
#20 0xb698188b in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#21 0x004ed3d0 in main () There seems to be a problem around Javascript and Qt5 Comments (1)
Related Tasks (0/0) Admin
Andreas Baumann commented on 12.05.2019 18:25 New bug on pentium4:
Stack trace of thread 387:
#0 0x00000000b7fa8841 kernel_vsyscall (linux-gate.so.1)

         #1  0x00000000b63311b6 raise (libc.so.6)
         #2  0x00000000b631b1e3 abort (libc.so.6)
         #3  0x00000000b66b2773 _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5)
         #4  0x00000000b7b98592 _ZN13QSGRenderLoop28handleContextCreationFailureEP12QQuickWindowb (libQt5Quick.so.5)
         #5  0x00000000b7b99a1d n/a (libQt5Quick.so.5)
         #6  0x00000000b7b9a35b n/a (libQt5Quick.so.5)
         #7  0x00000000b6c95427 _ZN7QWindow5eventEP6QEvent (libQt5Gui.so.5)
         #8  0x00000000b7c22c60 _ZN12QQuickWindow5eventEP6QEvent (libQt5Quick.so.5)
         #9  0x00000000b68a8845 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5)
         #10 0x00000000b6c898ab _ZN22QGuiApplicationPrivate18processExposeEventEPN29QWindowSystemInterfacePrivate11ExposeEventE (libQt5Gui.so.5)
         #11 0x00000000b6c89bda _ZN22QGuiApplicationPrivate24processWindowSystemEventEPN29QWindowSystemInterfacePrivate17WindowSystemEventE (libQt5Gui.so.5)
         #12 0x00000000b6c5e085 _ZN22QWindowSystemInterface22sendWindowSystemEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Gui.so.5)
         #13 0x00000000b0b7631d n/a (libQt5XcbQpa.so.5)
         #14 0x00000000b54ddb1e g_main_context_dispatch (libglib-2.0.so.0)
         #15 0x00000000b54dfbfa n/a (libglib-2.0.so.0)
         #16 0x00000000b54dfc46 g_main_context_iteration (libglib-2.0.so.0)
         #17 0x00000000b690172b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
         #18 0x00000000b68a72d6 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
         #19 0x00000000b68af8db _ZN16QCoreApplication4execEv (libQt5Core.so.5)
         #20 0x00000000004a4330 main (sddm-greeter)
         #21 0x00000000b631c669 __libc_start_main (libc.so.6)
         #22 0x00000000004a4635 _start (sddm-greeter)
         
         Stack trace of thread 388:
         #0  0x00000000b7fa8841 __kernel_vsyscall (linux-gate.so.1)
         #1  0x00000000b63e0ed3 __poll (libc.so.6)
         #2  0x00000000b7a236ce n/a (libxcb.so.1)
         #3  0x00000000b7a25864 xcb_wait_for_event (libxcb.so.1)
         #4  0x00000000b0b751ea n/a (libQt5XcbQpa.so.5)
         #5  0x00000000b66f39e0 n/a (libQt5Core.so.5)
         #6  0x00000000b620dab2 start_thread (libpthread.so.0)
         #7  0x00000000b63ea96a __clone (libc.so.6)
         
         Stack trace of thread 389:
         #0  0x00000000b7fa8841 __kernel_vsyscall (linux-gate.so.1)
         #1  0x00000000b63e0ed3 __poll (libc.so.6)
         #2  0x00000000b54dfb55 n/a (libglib-2.0.so.0)
         #3  0x00000000b54dfc46 g_main_context_iteration (libglib-2.0.so.0)
         #4  0x00000000b690172b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
         #5  0x00000000b68a72d6 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
         #6  0x00000000b66f2412 _ZN7QThread4execEv (libQt5Core.so.5)
         #7  0x00000000b0a20cdd n/a (libQt5DBus.so.5)
         #8  0x00000000b66f39e0 n/a (libQt5Core.so.5)
         #9  0x00000000b620dab2 start_thread (libpthread.so.0)
         #10 0x00000000b63ea96a __clone (libc.so.6)
         
         Stack trace of thread 391:
         #0  0x00000000b7fa8841 __kernel_vsyscall (linux-gate.so.1)
         #1  0x00000000b63e0ed3 __poll (libc.so.6)
         #2  0x00000000b54dfb55 n/a (libglib-2.0.so.0)
         #3  0x00000000b54dfc46 g_main_context_iteration (libglib-2.0.so.0)
         #4  0x00000000b690172b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
         #5  0x00000000b68a72d6 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
         #6  0x00000000b66f2412 _ZN7QThread4execEv (libQt5Core.so.5)
         #7  0x00000000b77189c3 n/a (libQt5Qml.so.5)
         #8  0x00000000b66f39e0 n/a (libQt5Core.so.5)
         #9  0x00000000b620dab2 start_thread (libpthread.so.0)
         #10 0x00000000b63ea96a __clone (libc.so.6)

Google Cache

   Compiling same-file v1.0.6
     |                        ^^^
     = note: `-D non-fmt-panic` implied by `-D warnings`
     = note: this is no longer accepted in Rust 2021
help: add a "{}" format string to Display the message
     |
1493 |                 panic!("{}", out);
     |                        ^^^^^
help: or use std::panic::panic_any instead
     |
1493 |                 std::panic::panic_any(out);
     |                 ^^^^^^^^^^^^^^^^^^^^^^

Brilliantly fast changing language..

either building 1.49 via 1.48, via 1.47 or we have to bootstrap from a binary version again.

Attached to Project: Archlinux32
Opened by Levi - 26.07.2018
Last edited by Erich Eckner - 27.07.2018
 FS#47  - rankmirrors $repo guessing broken in i686 only

I usually use rankmirrors on my mirrorlist prior to installing them fully to sort them such that the quickest mirrors are listed first.

I found that when using them to sort my mirrorlist.pacnew, it would claim each server target was unreachable, and reproduce them in their original order, making the tool rather useless.
Workaround

I also discovered that I can work around the problem by passing an argument of ‘-r core’ to the invocation, e.g. ‘$ rankmirrors -r core /etc/pacman.d/mirrorlist.pacnew &gt; mirrorlist.temp’
Steps to reproduce

  rankmirrors -t /etc/pacman.d/mirrorlist.pacnew

This -t option prints out the timings, or unreachable if it failed to create a valid uri.
Investigation

My investigations thus far show that /usr/bin/rankmirrors is a bash script, and it looks like the if statement starting on line 79 in the current version (the first if statement in the getfetchurl function) is designed to replace the $repo string with whatever $TARGETREPO is, else ‘core’ which suggests it should work by default.

The only consistent difference in the format of the mirrorlist file between here and on my x64 machine (where rankmirrors continues to work fine) is that on x64 the repos almost all have /os before /$repo while we often have it at the root of the public filesystem, or under something other than /os.

Unfortunately the vagaries of bash string substitution are something I rarely touch and never touch again provided they continue to work, so I can’t guess why this would have stopped working for us. If I have time to dig further I’ll comment here though, of course.
Closed by Erich Eckner
27.07.2018 04:22
Reason for closing: Fixed
Additional comments about closing:

note, that this deliberately does not work with upstream’s mirror layout

  Comments (2)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 26.07.2018 19:13

ok, I just checked - with my mirrorlist, it works (this is not the default mirrorlist) - so I suspect, it breaks due to our format of the urls ($root/$arch/$repo instead of $root/$repo/os/$arch) - I’ll look into this
Admin
Erich Eckner commented on 26.07.2018 19:38

I think, I fixed it - let’s see if it “compiles” and runs

Google Cache

The quazip-qt5 package for both i686 and pentium4 contains the Qt6 libraries instead of the Qt5 ones.

The quazip package also no longer seems to exist upstream and should probably be removed in Arch32 as well.

Attached to Project: Archlinux32
Opened by Andreas Baumann - 16.06.2018
Last edited by Andreas Baumann - 02.10.2019
 FS#43  - qt5-webengine, firefox, firefox-developer-edition use too much memory

In file included from gen/third_party/WebKit/public/platform/modules/presentation/presentation.mojom-shared.h:24,

               from gen/third_party/WebKit/public/platform/modules/presentation/presentation.mojom.h:37,
               from ../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/content/browser/frame_host/render_frame_host_impl.h:66,
               from ../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/content/browser/frame_host/frame_tree_node.h:18,
               from ../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/content/browser/devtools/browser_devtools_agent_host.cc:21:

gen/third_party/WebKit/public/platform/modules/presentation/presentation.mojom-shared-internal.h:139:35: warning: alignment 1 of ‘blink::mojom::internal::PresentationConnectionMessage_Data’ is less than 8 [-Wpacked-not-aligned]
class MOJOM_SHARED_CONTENT_EXPORT PresentationConnectionMessage_Data {

                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

virtual memory exhausted: Cannot allocate memory
ninja: build stopped: subcommand failed.

Also in firefox:

91:37.06 ../../build/unix/gold/ld: fatal error: libxul.so: mmap: failed to allocate 1703955732 bytes for output file: Cannot allocate memory
91:37.06 collect2: error: ld returned 1 exit status
91:37.06 make[4]: * [/build/firefox/src/mozilla-unified/config/rules.mk:701: libxul.so] Error 1
91:37.06 make[3]: * [/build/firefox/src/mozilla-unified/config/recurse.mk:73: toolkit/library/target] Error 2
91:37.06 make[2]: * [/build/firefox/src/mozilla-unified/config/recurse.mk:33: compile] Error 2
91:37.06 make[1]: * [/build/firefox/src/mozilla-unified/config/rules.mk:434: default] Error 2
91:37.06 make: *** [client.mk:168: build] Error 2

Closed by Andreas Baumann
02.10.2019 19:26
Reason for closing: Fixed
Additional comments about closing:

Currently firefox and qt5-webengine build.
firefox-developer-edition is blacklisted as it causes too much trouble
already as the official released version, so we don’t to beta testing
here..

  Comments (10)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 16.06.2018 05:33

Build slaves should have a 4GB swap space (if they are virtual machines),
and sysctl vm.mmap_min_addr=0 should be set.

For containers I don’t know what’s best becauste systemd-nspawn has
a mind of its own. sysctl vm.mmap_min_addr=0 on the host helped here too.
Admin
Andreas Baumann commented on 16.06.2018 05:37

Another solution could be not to use the gold-ld.
Admin
Andreas Baumann commented on 16.06.2018 06:26

and another one:

CodeCache::InnerPointerToCodeCacheEntry’; use assignment or value-initialization instead [-Wclass-memaccess]

   memset(&cache_[0], 0, sizeof(cache_));
                                       ^

../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/v8/src/frames.h:36:10: note: ‘struct v8::internal::InnerPointerToCodeCache::InnerPointerToCodeCacheEntry’ declared here

 struct InnerPointerToCodeCacheEntry {
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

{standard input}: Assembler messages:
{standard input}:15117: Warning: end of file not at end of a line; newline inserted
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
g++: fatal error: Terminated signal terminated program cc1plus
compilation terminated.
ninja: build stopped: subcommand failed.

This looks like truncated assembly to me. Maybe using tmpfile instead of -pipe?
Admin
Andreas Baumann commented on 17.06.2018 06:24

qt5-webkit fails now much later in a build race in a plugin. removing -pipe could
also help for all other packages running out of virtual memory, so maybe changing
the global build options to ‘-j1’ and not ‘-pipe’ in makepkg.conf is an idea.
Or we patch the affected packages only, but patching away a -pipe might not be as
easy as one may think.
Admin
Andreas Baumann commented on 20.06.2018 05:01

Still trouble with firefox and firefox-developer-edition, -pipe gets added
somewhere even if I change it in the build chroot configuration in makepkg.conf..
Admin
Andreas Baumann commented on 21.06.2018 11:46

-pipe doens’t have a huge impact.

So I’ll try with some special LDFLAGS -Wl,–no-keep-memory, after a hint in:

https://bugzilla.mozilla.org/show_bug.cgi?id=854535 Admin
Andreas Baumann commented on 23.06.2018 07:56

A top on a 64-bit Archlinux shows me the following during a build:

26963 arch 20 0 6336364 1.8g 1468 R 7.0 91.8 1:44.14 dump_syms

0 S arch 26958 26956 0 80 0 - 25355 - 20:29 pts/0 00:00:00 /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /data/firefox/src/mozilla-unified/toolkit/crashreporter/tools/symbolstore.py -c –vcs-info –install-manifest=/data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/_build_manifests/install/dist_include,/data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/include -s /data/firefox/src/mozilla-unified /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/host/bin/dump_syms /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so
0 D arch 26963 26958 7 80 0 - 1146305 - 20:29 pts/0 00:00:34 /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/host/bin/dump_syms /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so

So, this dump_syms program will never work in an 32-bit address room. The question
is, can it be tuned or hacked? The question, why did it work till now and what
changed so it doesn’t work currently?
Admin
Andreas Baumann commented on 02.07.2018 15:58

Another try using the standard linker instead of the gold one.
Admin
Andreas Baumann commented on 02.07.2018 19:43

I think, I’m in the wrong movie:

36:53.02 libxul.so
37:13.26 /usr/bin/ld: out of memory allocating 1000 bytes after a total of 898674688 bytes
37:13.26 collect2: error: ld returned 1 exit status

Admin
Andreas Baumann commented on 02.10.2019 19:24

Rust things also run out of memory (firefox), disabling some debug info
with debug_info=1 makes the builds succeed.

Google Cache

While installing qemu-desktop for Archlinux32 following error appears:

/usr/bin/gtk-query-immodules-3.0: symbol lookup error: /usr/liblibpango-1.0.so.0: undefined symbol: hb_ot_color_has_paint

Pango version pango-1:1.50.14-1.0-pentium4. This is a problem of Archlinux32 only - in Archlinux there is no error.

Came across this after completing a system update two days ago.

I run Radicale and that is refusing to start with the following error:

Traceback (most recent call last):
  File "/usr/bin/radicale", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 84, in <module>
    __import__('packaging.requirements')
  File "/usr/lib/python3.7/site-packages/packaging/requirements.py", line 9, in <module>
    from pyparsing import stringStart, stringEnd, originalTextFor, ParseException
ModuleNotFoundError: No module named 'pyparsing'

When attempting to run pip to see if that might correct the issue, I got the following error:

Traceback (most recent call last):
  File "/usr/bin/pip", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 84, in <module>
    __import__('packaging.requirements')
  File "/usr/lib/python3.7/site-packages/packaging/requirements.py", line 9, in <module>
    from pyparsing import stringStart, stringEnd, originalTextFor, ParseException
ModuleNotFoundError: No module named 'pyparsing'

It looks as though something recently broke pyparsing and that’s had a knockon effect for a few packages.

OK (skipped=10)
Traceback (most recent call last):

File "/usr/lib/python3.9/site-packages/packaging/version.py", line 57, in parse
  return Version(version)
File "/usr/lib/python3.9/site-packages/packaging/version.py", line 298, in __init__
  raise InvalidVersion("Invalid version: '{0}'".format(version))

packaging.version.InvalidVersion: Invalid version: ‘/build/protobuf/src/protobuf’

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File "/build/protobuf/src/protobuf-3.12.4/python/setup.py", line 251, in <module>
  setup(
File "/usr/lib/python3.9/site-packages/setuptools/__init__.py", line 153, in setup
  return distutils.core.setup(**attrs)
File "/usr/lib/python3.9/distutils/core.py", line 148, in setup
  dist.run_commands()
File "/usr/lib/python3.9/distutils/dist.py", line 966, in run_commands
  self.run_command(cmd)
File "/usr/lib/python3.9/distutils/dist.py", line 985, in run_command
  cmd_obj.run()
File "/usr/lib/python3.9/site-packages/setuptools/command/test.py", line 232, in run
  self.run_tests()
File "/usr/lib/python3.9/contextlib.py", line 124, in __exit__
  next(self.gen)
File "/usr/lib/python3.9/site-packages/setuptools/command/test.py", line 169, in project_on_sys_path
  working_set.__init__()
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 552, in __init__
  self.add_entry(entry)
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 608, in add_entry
  for dist in find_distributions(entry, True):
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2059, in find_on_path
  path_item_entries = _by_version_descending(filtered)
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2029, in _by_version_descending
  return sorted(names, key=_by_version, reverse=True)
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2027, in _by_version
  return [packaging.version.parse(part) for part in parts]
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2027, in <listcomp>
  return [packaging.version.parse(part) for part in parts]
File "/usr/lib/python3.9/site-packages/packaging/version.py", line 59, in parse
  return LegacyVersion(version)
File "/usr/lib/python3.9/site-packages/packaging/version.py", line 127, in __init__
  warnings.warn(

DeprecationWarning: Creating a LegacyVersion has been deprecated and will be removed in the next major release
=⇒ ERROR: A failure occurred in check().

  Aborting...

=⇒ ERROR: Build failed, check /var/lib/archbuild/staging-pentium4/abaumann/build

both i686 and pentium4

Running Sphinx v3.5.1
/bin/sh: line 1: git: command not found
making output directory… done
WARNING: html_static_path entry ‘_static’ does not exist

Theme error:
sphinx_rtd_theme is no longer a hard dependency since version 1.4.0. Please install it manually.(pip install sphinx_rtd_theme)
{’code2docs’: {}, ‘docs2code’: {}}
make: *** [Makefile:24: html] Error 2

If I remember correctly, then some Spinx schemes need yarn to build, so they are no longer
buildable.
This means all packages needing that theme for documentation purposes are failing.

Maybe buildable without documentation for now?

The ArchLinux32 mirror at http[s]://mirror.math.princeton.edu/pub/archlinux32/ appears to have stopped syncing properly in October. I contacted web@math.princeton.edu on January 1 to alert them to the problem, and received the following response from a Princeton sysadmin:

Here is the configuration I am using:

archlinux32:
   remotesrc: “rsync://mirror.archlinux32.org/archlinux32/”
   localdest: “/var/www/html/pub/archlinux32”
   extraopts: “–port=22873”

Looks like at some point this stopped working from upstream:

Raw standard error:
rsync: failed to connect to mirror.archlinux32.org (85.10.198.216): Connection refused (111)
rsync: failed to connect to mirror.archlinux32.org (2a01:4f8:a0:5264::2): Network is unreachable (101)
rsync error: error in socket IO (code 10) at clientserver.c(125) [Receiver=3.1.2]

Can you recommend a better upstream target I can use? And if there are additional constraints on checkin time or frequency.

I informed him that I am not an official member of the ArchLinux32 team, but suggested that using the regular rsync port of 873 might work as mirror.archlinux32.org appears to accept connections to that port from the Internet. As of the time of this writing, it appears that the mirror is now again up to date (although it has other issues returning HTTP error 403 for some of its files), but I promised to bring his additional questions to the official team.

So, to iterate, is this the appropriate target to mirror, or should they use some other parameters?

Thank you.

no task description

Gimp
Krita

If possible can u add Julia Lang though its on blacklist but i will try to compile it :)

Arduino is out dated and my teacher said to use the latest arduino version 1.8.x for the robotics class…

:: removing user-manager breaks dependency ‘user-manager’ required by plasma-meta

please update pinta i am facing problems with p.net clone and the closest is pinta so if u look to update it then it would be greatful

In my quest to find a working mirror close to me, I’ve come across another issue with at least a couple of mirrors. Some mirrors respond with a HTTP 403 Forbidden for certain files, notably many of the Pacman database files. At the time of this writing, I’m aware of this problem happening with the princeton.edu and the clarkson.edu mirrors. I’ve been in contact with the admin of one of the mirrors, and they’ve pointed out that the permission bits are set to 0600 at the source. If the primary mirror could have their files be world readable, it would likely fix this problem automatically across more than one mirror.

Is that something we can do?

Steps to verify:

% rsync -av rsync://mirror.archlinux32.org/archlinux32/i686/extra/extra.db.tar.gz .
receiving incremental file list
extra.db.tar.gz

sent 43 bytes  received 2,044,453 bytes  371,726.55 bytes/sec
total size is 2,043,851  speedup is 1.00

% ls -l extra.db.tar.gz
-rw------- 1 user user 2043851 Jan  8 11:51 extra.db.tar.gz

When you have system update there is this warning:

Warn about old perl modules
WARNING: '/usr/lib/perl5/5.34' contains data from at least 1 packages which will NOT be used by the installed perl interpreter.
 -> Run the following command to get a list of affected packages: pacman -Qqo '/usr/lib/perl5/5.34'

After searching you see it’s caused by

$ pacman -Qqo '/usr/lib/perl5/5.34'
perl-term-readline-gnu

So this package should be rebulded, because in repositories is perl 5.36

More info and problem description https://forum.manjaro.pl/t/archlinux32-ostrzezenie-od-perl/2356

# pandoc --version
pandoc: error while loading shared libraries: libHSzip-archive-0.4.1-4yLWnBS0zifKkvfHVbmUo1-ghc8.10.2.so: cannot open shared object file: No such file or directory
<code>

Versions:
<code>
# pacman -Q | grep haskell
haskell-aeson 1.5.4.1-19.0
haskell-aeson-pretty 0.8.8-94.0
haskell-ansi-terminal 0.11-17.0
haskell-asn1-encoding 0.9.6-58.0
haskell-asn1-parse 0.9.5-58.0
haskell-asn1-types 0.3.4-37.0
haskell-assoc 1.0.2-27.0
haskell-async 2.2.2-40.0
haskell-attoparsec 0.13.2.4-36.0
haskell-base-compat 0.11.2-4.2
haskell-base-compat-batteries 0.11.2-11.0
haskell-base-orphans 0.8.3-14.0
haskell-base16-bytestring 0.1.1.7-3.0
haskell-base64-bytestring 1.2.0.1-3.0
haskell-basement 0.0.11-10.1
haskell-bifunctors 5.5.8-13.0
haskell-blaze-builder 0.4.2.1-2.1
haskell-blaze-html 0.9.1.2-57.0
haskell-blaze-markup 0.8.2.7-41.0
haskell-byteable 0.1.1-22.1
haskell-case-insensitive 1.2.1.0-39.0
haskell-cereal 0.5.8.1-9.0
haskell-citeproc 0.3.0.9-9.0
haskell-cmdargs 0.10.21-1.0
haskell-colour 2.3.5-75.0
haskell-commonmark 0.1.1.2-2.0
haskell-commonmark-extensions 0.2.0.3-1.0
haskell-commonmark-pandoc 0.2.0.1-24.0
haskell-comonad 5.0.6-58.0
haskell-conduit 1.3.4-3.0
haskell-conduit-extra 1.3.5-70.0
haskell-connection 0.3.1-99.0
haskell-cookie 0.4.5-9.1
haskell-cryptonite 0.27-32.0
haskell-data-default 0.7.1.1-87.0
haskell-data-default-class 0.1.2.0-21.1
haskell-data-default-instances-containers 0.0.1-33.1
haskell-data-default-instances-dlist 0.0.1-100.0
haskell-data-default-instances-old-locale 0.0.1-33.1
haskell-data-fix 0.3.0-35.0
haskell-digest 0.0.1.2-22.1
haskell-distributive 0.6.2-40.0
haskell-dlist 1.0-23.0
haskell-doclayout 0.3-45.0
haskell-doctemplates 0.9-40.0
haskell-emojis 0.1-47.0
haskell-erf 2.0.0.0-21.0
haskell-errors 2.3.0-59.1
haskell-file-embed 0.0.13.0-3.1
haskell-glob 0.10.1-28.0
haskell-haddock-library 1.9.0-58.0
haskell-hashable 1.3.0.0-36.0
haskell-hourglass 0.2.12-82.0
haskell-hslua 1.3.0-2.0
haskell-hslua-module-system 0.2.2.1-17.0
haskell-hslua-module-text 0.3.0.1-5.0
haskell-hsyaml 0.2.1.0-52.0
haskell-http 4000.3.15-49.0
haskell-http-client 0.7.6-14.0
haskell-http-client-tls 0.3.5.3-359.0
haskell-http-types 0.12.3-100.0
haskell-hxt 9.3.1.18-196.0
haskell-hxt-charproperties 9.5.0.0-1.0
haskell-hxt-regex-xmlschema 9.2.0.7-2.0
haskell-hxt-unicode 9.0.2.4-22.0
haskell-indexed-traversable 0.1.1-3.1
haskell-integer-logarithms 1.0.3.1-3.1
haskell-ipynb 0.1.0.1-192.0
haskell-jira-wiki-markup 1.3.2-27.0
haskell-juicypixels 3.3.5-37.0
haskell-memory 0.15.0-49.0
haskell-mime-types 0.1.0.9-11.1
haskell-mono-traversable 1.0.15.1-74.0
haskell-network 3.1.2.1-1.0
haskell-network-uri 2.6.3.0-217.0
haskell-old-locale 1.0.0.7-27.1
haskell-old-time 1.1.0.3-27.1
haskell-pandoc-types 1.22-13.0
haskell-pem 0.2.4-114.0
haskell-primitive 0.7.1.0-29.0
haskell-quickcheck 2.14.2-11.0
haskell-random 1.2.0-54.0
haskell-resourcet 1.2.4.2-31.0
haskell-safe 0.3.19-5.1
haskell-scientific 0.3.6.2-53.0
haskell-sha 1.6.4.4-16.1
haskell-skylighting 0.10.2-24.0
haskell-skylighting-core 0.10.2-24.0
haskell-socks 0.6.1-90.0
haskell-split 0.2.3.4-88.0
haskell-splitmix 0.1.0.3-5.0
haskell-streaming-commons 0.2.2.1-28.1
haskell-strict 0.4.0.1-1.0
haskell-syb 0.7.1-8.0
haskell-tagged 0.8.6.1-2.2
haskell-tagsoup 0.14.8-75.0
haskell-temporary 1.3-130.0
haskell-texmath 0.12.0.3-40.0
haskell-text-conversions 0.3.1-62.0
haskell-text-icu 0.7.0.1-37.1
haskell-th-abstraction 0.4.2.0-2.2
haskell-th-compat 0.1-12.0
haskell-these 1.1.1.1-28.0
haskell-time-compat 1.9.5-1.0
haskell-tls 1.5.5-3.0
haskell-transformers-compat 0.6.6-3.1
haskell-typed-process 0.2.6.0-63.0
haskell-unicode-transforms 0.3.7.1-42.0
haskell-uniplate 1.6.13-4.0
haskell-unliftio-core 0.2.0.1-6.1
haskell-unordered-containers 0.2.13.0-11.0
haskell-utf8-string 1.0.1.1-20.0
haskell-uuid-types 1.0.3-58.0
haskell-vector 0.12.1.2-64.0
haskell-vector-algorithms 0.8.0.4-1.0
haskell-x509 1.7.5-137.0
haskell-x509-store 1.6.7-136.0
haskell-x509-system 1.6.6-204.0
haskell-x509-validation 1.6.11-136.0
haskell-xml 1.3.14-27.2
haskell-xml-conduit 1.9.0.0-77.0
haskell-xml-types 0.3.8-5.1
haskell-zip-archive 0.4.1-66.0
haskell-zlib 0.6.2.2-4.0

The pactree tool in pacman-contrib 1.10.5 requires libalpm.so.13 which belongs to an older version of pacman. Rebuilding pacman-contrib with the latest version of pacman installed should resolve the issue.

/proc/cpuinfo:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 15
model name : VIA Nano U3400@800MHz
stepping : 10
cpu MHz : 798.016
cache size : 2048 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm syscall nx lm constant_tsc arch_perfmon rep_good cpuid pni monitor vmx est tm2 ssse3 cx16 xtpr sse4_1 popcnt rng rng_en ace ace_en ace2 phe phe_en pmm pmm_en lahf_lm tpr_shadow vnmi vpid ida
vmx flags : vnmi tsc_offset vtpr
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips : 1596.53
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

Other machine, also with via processor:

/proc/cpuinfo:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 13
model name : VIA C7-D Processor 1800MHz
stepping : 0
cpu MHz : 1596.326
cache size : 128 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx cpuid pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips : 3193.67
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 32 bits virtual
power management:

All the __builtin_cpu_supports() and __builtin_cpu_is() tests fail. Thus, pacman thinks, it’s not capable of sse2 and installs i686 packages instead of pentium4 ones.

Should we complain at gcc upstream? How does the kernel compile this line in /proc/cpuinfo? What checks does it perform?

looks, like the new devtools do not strip packages anymore - maybe it was only an intermediate version, that lacked automatic stripping.

After updating my system I found that sshd.service will no longer start.

As a temporary work round I downgraded openssl from 3.2.1-1.0 to 3.1.4-1.0

[keith@Arch32 ~]$ sudo pacman -Syu
:: Synchronising package databases...
 core-testing is up to date
 core is up to date
 extra-testing is up to date
 extra is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Package (1)           Old Version  New Version  Net Change

core-testing/openssl  3.1.4-1.0    3.2.1-1.0      1.03 MiB

Total Installed Size:  10.54 MiB
Net Upgrade Size:       1.03 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                                                 [--------------------------------------------------------] 100%
(1/1) checking package integrity                                                               [--------------------------------------------------------] 100%
(1/1) loading package files                                                                    [--------------------------------------------------------] 100%
(1/1) checking for file conflicts                                                              [--------------------------------------------------------] 100%
(1/1) checking available disk space                                                            [--------------------------------------------------------] 100%
:: Processing package changes...
(1/1) upgrading openssl                                                                        [--------------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
[keith@Arch32 ~]$ systemctl restart sshd.service
[keith@Arch32 ~]$ systemctl status sshd.service
× sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Tue 2024-02-13 05:36:11 GMT; 6s ago
   Duration: 9ms
    Process: 1008 ExecStart=/usr/bin/sshd -D (code=exited, status=255/EXCEPTION)
   Main PID: 1008 (code=exited, status=255/EXCEPTION)
        CPU: 9ms

Feb 13 05:36:11 Arch32 systemd[1]: sshd.service: Scheduled restart job, restart counter is at 5.
Feb 13 05:36:11 Arch32 systemd[1]: Stopped OpenSSH Daemon.
Feb 13 05:36:11 Arch32 systemd[1]: sshd.service: Start request repeated too quickly.
Feb 13 05:36:11 Arch32 systemd[1]: sshd.service: Failed with result 'exit-code'.
Feb 13 05:36:11 Arch32 systemd[1]: Failed to start OpenSSH Daemon.
[keith@Arch32 ~]$ sudo downgrade openssl
loading packages...
warning: downgrading package openssl (3.2.1-1.0 => 3.1.4-1.0)
resolving dependencies...
looking for conflicting packages...

Package (1)  Old Version  New Version  Net Change

openssl      3.2.1-1.0    3.1.4-1.0     -1.03 MiB

Total Installed Size:   9.51 MiB
Net Upgrade Size:      -1.03 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                                                 [--------------------------------------------------------] 100%
(1/1) checking package integrity                                                               [--------------------------------------------------------] 100%
(1/1) loading package files                                                                    [--------------------------------------------------------] 100%
(1/1) checking for file conflicts                                                              [--------------------------------------------------------] 100%
(1/1) checking available disk space                                                            [--------------------------------------------------------] 100%
:: Processing package changes...
(1/1) downgrading openssl                                                                      [--------------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
add openssl to IgnorePkg? [y/N] 
[keith@Arch32 ~]$ systemctl restart sshd.service
[keith@Arch32 ~]$ systemctl status sshd.service
● sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
     Active: active (running) since Tue 2024-02-13 05:37:20 GMT; 5s ago
   Main PID: 1138 (sshd)
      Tasks: 1 (limit: 2293)
     Memory: 772.0K
        CPU: 61ms
     CGroup: /system.slice/sshd.service
             └─1138 "sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups"

Feb 13 05:37:20 Arch32 systemd[1]: Started OpenSSH Daemon.
Feb 13 05:37:20 Arch32 sshd[1138]: Server listening on 0.0.0.0 port 22.
Feb 13 05:37:20 Arch32 sshd[1138]: Server listening on :: port 22.
[keith@Arch32 ~]$ 

Attached to Project: Archlinux32
Opened by Andreas Baumann - 18.05.2019
Last edited by Andreas Baumann - 16.08.2019
 FS#75  - openjdk8/10/11/12 break with march=pentium4 optimization

This blocks ant, needed for building libreoffice.
Closed by Andreas Baumann
16.08.2019 13:55
Reason for closing: Fixed
Additional comments about closing:

fixed for 8, 10, 11 and 12. Not for 7.

  Comments (34)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 18.05.2019 18:18

mmh. java is fine.

java -version
openjdk version “1.8.0_212” OpenJDK Runtime Environment (build 1.8.0_212-b01)
OpenJDK Server VM (build 25.212-b01, mixed mode)

javac
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_x86.cpp:291), pid=124, tid=0xf6dc1b40
# fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution.
#
# JRE version: OpenJDK Runtime Environment (8.0_212-b01) (build 1.8.0_212-b01)
# Java VM: OpenJDK Server VM (25.212-b01 mixed mode linux-x86 )
# Core dump written. Default location: /build/libreoffice-still/core or core.124
#
# An error report file with more information is saved as:
# /build/libreoffice-still/hs_err_pid124.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp #
Aborted (core dumped)

ant
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_x86.cpp:291), pid=155, tid=0xf6d4fb40
# fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution.
#
# JRE version: OpenJDK Runtime Environment (8.0_212-b01) (build 1.8.0_212-b01)
# Java VM: OpenJDK Server VM (25.212-b01 mixed mode linux-x86 )
# Core dump written. Default location: /build/libreoffice-still/core or core.155
#
# An error report file with more information is saved as:
# /build/libreoffice-still/hs_err_pid155.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp #
Aborted (core dumped)

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x897c76]
V [libjvm.so+0x36392a]
V [libjvm.so+0x71341f] JVM_handle_linux_signal+0x6bf
V [libjvm.so+0x70507f]
C [linux-gate.so.1+0×950] __kernel_rt_sigreturn+0×0

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.lang.System.nanoTime()J+0
j java.net.URLClassLoader.defineClass(Ljava/lang/String;Lsun/misc/Resource;)Ljava/lang/Class;+0
j java.net.URLClassLoader.access$100(Ljava/net/URLClassLoader;Ljava/lang/String;Lsun/misc/Resource;)Ljava/lang/Class;+3
j java.net.URLClassLoader$1.run()Ljava/lang/Class;+43
j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1
v ~StubRoutines::call_stub
j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0
j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13
j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70
j sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+81
j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3
v ~StubRoutines::call_stub
j com.sun.tools.javac.main.Main.(Ljava/lang/String;Ljava/io/PrintWriter;)V+5
j com.sun.tools.javac.main.Main.(Ljava/lang/String;)V+13
j com.sun.tools.javac.Main.compile([Ljava/lang/String;)I+6
j com.sun.tools.javac.Main.main([Ljava/lang/String;)V+1
v ~StubRoutines::call_stub
Admin
Andreas Baumann commented on 18.05.2019 18:19

well. Java errors, hard to debug..
Admin
Andreas Baumann commented on 18.05.2019 18:21

Installing the i686 version in the pentium4 chroot also segfaults..
Admin
Andreas Baumann commented on 18.05.2019 18:25

Java 686 doesn’t segfault on a real i686 installed system. So, I fear, some library in pentium4
is causing java to segfault.
Admin
Andreas Baumann commented on 18.05.2019 18:36

Event: 0.057 Thread 0xf6b07c00 Exception <a> (0xd7b86ea0) thrown at [/build/javapenjdk/src/jdk8u-jdk8u212-b01/hotspot/src/share/vm/prims/jni.cp
Event: 0.057 Thread 0xf6b07c00 Exception </a><a> (0xd7b87170) thrown at [/build/javapenjdk/src/jdk8u-jdk8u212-b01/hotspot/src/share/vm/prims/jni.cpp, line 4012]
Event: 0.231 Thread 0xf6b07c00 Exception </a><a> (0xd7cc0498) thrown at [/build/javapenjdk/src/jdk8u-jdk8u212-b01/hotspot/src/share/vm/prims/jvm.cpp, line 1502]

mmh. this sounds quite internal..
</a>
Admin
Andreas Baumann commented on 18.05.2019 18:50

pentium$:
javac -version
javac 11.0.3

why is libreoffice built with java 8?
Admin
Andreas Baumann commented on 18.05.2019 19:00

weird: on my pentium4 test machine with jdk 8 and 11 installed, I can switch to java 8
and everything is fine.
Admin
Andreas Baumann commented on 18.05.2019 19:03

I remember issues with shared libraries and the way the Jvm is bootstrapping. For
instance not having a /proc causes trouble of this sort. But we have a /proc
(we are using arch-chroot and a bind mount point).
Admin
Andreas Baumann commented on 18.05.2019 19:07

using java 11 and javac 11 on pentium4 works..
Admin
Andreas Baumann commented on 18.05.2019 19:08

..and now we get to “find the 10 differences in this picture”. Admin
Andreas Baumann commented on 18.05.2019 19:14

The only thing I can think of is a different kernel (with more protection enabled):

https://bugs.openjdk.java.net/browse/JDK-8023956 https://bugs.openjdk.java.net/browse/JDK-8181068

This cries for building it on a real Pentium4 or on a properly emulated one, not
in a chroot.
Admin
Erich Eckner commented on 22.05.2019 04:34

&gt; using java 11 and javac 11 on pentium4 works..

why not simply pin the java version to 11, then?
Admin
Andreas Baumann commented on 06.06.2019 18:19

When installing the i686 version of glibc and openjdk8 there is no segfault!
So this sounds more like a new glibc and optimization triggering something in java..
Admin
Andreas Baumann commented on 07.06.2019 16:54

Actually also original SUN java 7 segfaults with this glibc.
Rebuilding glibc didn’t help. So I’m pretty sure it’s some protection thingy
getting into the way of old Java JDKs (because they always pushed their limits
and did funny tricks in the past).
Luke commented on 18.06.2019 18:27

Erich Eckner,
Ant is still broken with pentium4 build of java 11 (i686 works).

$ archlinux-java status
Available Java environments:

java-11-openjdk (default)

Admin
Andreas Baumann commented on 19.06.2019 17:57

19:40 &lt; slacka123&gt; should use “-march=i686 -msse2 -mtune=generic -mfpmath=sse -mstackrealign” instead?
19:54 &lt; slacka123&gt; Yes, it does - https://bugs.documentfoundation.org/show_bug.cgi?id=108619
19:54 &lt; phrik&gt; Title: 108619 – (32bitjavacrash) Java Crash on x86 in jfw_plugin_startJavaVirtualMachine

             w/ recent linux kernels (at bugs.documentfoundation.org)

19:55 &lt; slacka123&gt; Fedora 30 also needs that kernel parameter, “stack_guard_gap=1” to run/build

                 LibreOffice and other java apps

… 19:56 &lt; slacka123&gt; but i686 arch32 also needs it

from the chat protocol: https://mirror.archlinux32.org/irc-logs/%23archlinux32/2019-06-19.html#19:39:59 Admin
Andreas Baumann commented on 21.06.2019 08:29

See: https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc.spec Admin
Andreas Baumann commented on 21.06.2019 12:23

Thanks slacka123 for the hint. This seems to solve the java/javac crashes.

It’s fixed now in staging and will soon hop into testing.
Admin
Andreas Baumann commented on 11.08.2019 06:03

The segfaults persist through all pentium4 versions of the openjdk.
Additionally now also the 7 version of i686 and pentium4 are segfaulting.
Admin
Andreas Baumann commented on 11.08.2019 07:11

jkd7 also cannot find libattr:

https://patchwork.openembedded.org/patch/110857/ Admin
Andreas Baumann commented on 11.08.2019 07:13

On 64-bit it complains about ant:

error: target not found: apache-ant&gt;=1.8.1

flagged out-of-date upstream, unusable currently for bootstrapping.
Admin
Andreas Baumann commented on 11.08.2019 07:56

https://bugs.archlinux.org/task/63430 Admin
Andreas Baumann commented on 11.08.2019 07:56

configure: Found potential Boot JDK using java© in PATH
configure: Potential Boot JDK found at /usr/lib/jvm/java-penjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/java-penjdk)
configure: Potential Boot JDK found at /usr/lib/jvm/java-penjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/default-runtime)
configure: Potential Boot JDK found at /usr/lib/jvm/default-runtime is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/default)
configure: Potential Boot JDK found at /usr/lib/jvm/default is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Could not find a valid Boot JDK.
configure: This might be fixed by explicitely setting –with-boot-jdk
configure: error: Cannot continue
configure exiting with result code 1
Admin
Andreas Baumann commented on 11.08.2019 18:02

building on i686 (where openjdk8 still works) and using makepkg.conf with pentium4
cflags gives a package with wrong architecture though, but running in a pentium4
chroot if installed.

Though when I try to rebuild it with the ‘cross-compiled’ package in a pentium4
chroot, I get:

checking headful support… include support for both headful and headless
configure: Found potential Boot JDK using configure arguments
configure: Potential Boot JDK found at /usr/lib/jvm/java-penjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: error: The path given by –with-boot-jdk does not contain a valid Boot JDK configure exiting with result code 1

Inside I have a hs_err_pid3361.log showing again the darn SI_KERNEL SIGSEGV.

This problem is over my head (and skills).
Admin
Andreas Baumann commented on 12.08.2019 15:26

This sounds interesting:

https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3533

related question: is -march=pentium4 changing the stack layout?
Admin
Andreas Baumann commented on 12.08.2019 15:28

Should we force stack alignment globally for all libraries which could potentially be
called from java with -mstack-alignment=16? This could break havock on other software..
Admin
Andreas Baumann commented on 12.08.2019 15:28

Also interesting:

https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3533 Admin
Andreas Baumann commented on 12.08.2019 15:30

Also: -mincoming-stack-boundary=2

https://bugs.gentoo.org/attachment.cgi?id=522650&amp;action=diff Admin
Andreas Baumann commented on 12.08.2019 16:00

So -mstackrealign in the glibc flags helps to realign the stack, so that 4 and 16 byte stacks
can coexist, but Java generates it’s own executable code, which doesn’t respect that?
Why should -mincoming-stack-boundary=2 help then?
I’ll test again a double compilation via working i686 chroot to pentium4 (with -mincoming-stack-boundary=2 in the PKGBUILD of javapenjdk), then see if it can rebuild itself in a pentium4
chroot.
Admin
Andreas Baumann commented on 13.08.2019 04:48

Apparently this helps, thanks to the Gentoo guys. Admin
Andreas Baumann commented on 13.08.2019 05:05

Now to jdk10, jdk11 and jdk12 (weirdly enough there is no jdk9?).
Admin
Andreas Baumann commented on 15.08.2019 07:32

a working JDK8 for pentium4 hit staging. now for the other versions..
Admin
Andreas Baumann commented on 15.08.2019 11:40

This helps against GOT/PLT errors:

if test ${CARCH} = i686 -o ${CARCH} = pentium4; then
  echo "Removing '-fno-plt' from CFLAGS and CXXFLAGS to prevent build fail with th
  _CFLAGS=${CFLAGS/-fno-plt/}
  _CXXFLAGS=${CXXFLAGS/-fno-plt/}
fi

Admin
Andreas Baumann commented on 15.08.2019 12:03

Finished building targets ‘images docs’ in configuration ‘linux-x86-normal-server-release’ find: &lt;80&gt;&lt;98&gt;../jdk10u-jdk-10.0.2+13/build/linux-i386-normal-server-release/images&lt;80&gt;&lt;99&gt;: No such file or directory
ESC[1mESC[31m==&gt; ERROR:ESC[m^OESC[1m A failure occurred in build().ESC[m^O
ESC[1m Aborting…ESC[m^O
==&gt; ERROR: Build failed, check /var/lib/archbuild/staging-i686/abaumann/build
(END)

needs:

case “${CARCH}” in

x86_64) _JARCH='x86_64';;
i486|i686|pentium4)   _JARCH='x86';;

esac

Google Cache

26.11.2017 - In file included from ./arch/x86/include/asm/page.h:75:0, from ./arch/x86/include/asm/thread_info.h:11, from ./include/linux/thread_info.h:37, …

Attached to Project: Archlinux32
Opened by Markus Schaaf - 22.10.2019
 FS#92  - nfs mounts with sec=krb5 fail with ‘stale file handle’ for everyone but root

rpc.gssd bug due to missing syscall (setgroups). See https://bugzilla.linux-nfs.org/show_bug.cgi?id=340 `journalctl –unit=rpc-gssd.service` shows:

WARNING: unable to drop supplimentary groups!
WARNING: failed to change identity: Function not implemented

Until a fixed upstream release, use
$ cat abs/packages/nfs-utils/trunk/setgroups32.patch
— nfs-utils-2.4.1/utils/gssd/gssd_proc.c.orig 2019-10-22 11:26:48.059877484 +0200
+++ nfs-utils-2.4.1/utils/gssd/gssd_proc.c 2019-10-22 11:28:03.874553996 +0200
@@ -437,7 +437,7 @@

    int res;

    /* drop list of supplimentary groups first */

- if (syscall(SYS_setgroups, 0, 0) != 0) {
+ if (syscall(SYS_setgroups32, 0, 0) != 0) {

            printerr(0, "WARNING: unable to drop supplimentary groups!");
            return errno;
    }

Google Cache

newsboat: error while loading shared libraries: libjson-c.so.4: cannot open shared object file: No such file or directory

Attached to Project: Archlinux32
Opened by Andreas Baumann - 14.09.2019
Last edited by Andreas Baumann - 14.09.2019
 FS#86  - newsboat contains SSE2 instuctions

shell&gt; newsboat

Program received signal SIGILL, Illegal instruction.
0x005f5cd9 in ?? ()
=&gt; 0x005f5cd9: f2 0f 10 06 movsd (%esi),%xmm0
(gdb) bt
#0 0x005f5cd9 in ?? ()
#1 0x005f40fa in ?? ()
#2 0x005f3f3b in ?? ()
#3 0x0072e9fd in ?? ()
#4 0×00661600 in ?? ()
#5 0×00659435 in ?? ()
#6 0x0061fe88 in ?? ()
#7 0x0065770c in ?? ()
#8 0x005ea416 in ?? ()
#9 0x0044ca68 in ?? ()
#10 0xb76f9859 in __libc_start_main () from /usr/lib/libc.so.6
#11 0x0044da75 in ?? ()

This actually looks like glibc got a SSE2 infection on i686.

Google Cache

I didn’t found any message about reporting new mirrors of archlinux32 project, so I decided to open new FR. Sorry if I mistaken and show me the right way, please :)

Domain name: mirror.nw-sys.ru
Country: Russia
Supported access methods for mirror:
http(s) - http(s)://mirror.nw-sys.ru/archlinux32/
rsync - rsync://mirror.nw-sys.ru/archlinux32
Mirror bandwidth - 100 Mbit/s almostly, with slight slowdowns around the day.
Primary administrative contact - no1@no1sg.ru
Alternative administrative contact - morgan29rus@gmail.com
Source mirror - mirror.archlinux32.org