|
181 | Packages | Bug Report | Medium | Low | rust 1.51.0 recompilation issues | Closed | |
Task Description
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..
|
|
129 | Packages | Bug Report | Medium | Low | rust 1.47 is outdated | Closed | |
Task Description
either building 1.49 via 1.48, via 1.47 or we have to bootstrap from a binary version again.
|
|
47 | Packages: Stable | Bug Report | Medium | Low | rankmirrors $repo guessing broken in i686 only | Closed | |
Task Description
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 > 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
|
|
273 | Packages: Stable | Bug Report | Very Low | Medium | Quazip Qt5 package contains Qt6 libraries | Closed | |
Task Description
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.
|
|
43 | Packages: Build-list | Bug Report | Medium | Low | qt5-webengine, firefox, firefox-developer-edition use t ... | Closed | |
Task Description
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
|
|
323 | Packages | Bug Report | Very Low | Medium | qemu-desktop installation error | Closed | |
Task Description
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.
|
|
93 | Packages: Stable | Bug Report | Very Low | Medium | pyparsing error is preventing applications from startin ... | Closed | |
Task Description
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.
|
|
158 | Packages | Bug Report | Medium | Low | protobuf python bindings fail to build | Closed | |
Task Description
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
|
|
159 | Packages | Bug Report | Medium | Low | prjtrellis doesn't build | Closed | |
Task Description
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?
|
|
120 | Packages | Bug Report | Very Low | Low | Princeton ArchLinux32 mirror has been out of date; ques ... | Closed | |
Task Description
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.
|
|
138 | Packages | Bug Report | Medium | Low | polkit doesn't build because of a stuck js78 | Closed | |
Task Description
no task description |
|
293 | Packages | Bug Report | Very Low | Low | Please update those packages:- | Closed | |
Task Description
Gimp Krita
If possible can u add Julia Lang though its on blacklist but i will try to compile it :)
|
|
298 | Packages | Bug Report | Very Low | Low | Please update Arduino | Closed | |
Task Description
Arduino is out dated and my teacher said to use the latest arduino version 1.8.x for the robotics class…
|
|
153 | Packages | Bug Report | Medium | Low | plasma cannot be installed or updated | Closed | |
Task Description
:: removing user-manager breaks dependency ‘user-manager’ required by plasma-meta
|
|
300 | Packages | Bug Report | Very Low | Low | Pinta needs to be updated | Closed | |
Task Description
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
|
|
122 | Packages | Bug Report | Very Low | Low | Permissions bits on files on the primary mirror are too ... | Closed | |
Task Description
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:
1. Access certain files from the primary mirror using rsync, for example:
% 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
2. Examine permission bits:
% ls -l extra.db.tar.gz
-rw------- 1 user user 2043851 Jan 8 11:51 extra.db.tar.gz
Should be -rw-r–r–.
|
|
274 | Packages | Bug Report | Very Low | Medium | perl-term-readline-gnu should be rebuilt due to new per ... | Closed | |
Task Description
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
|
|
180 | Packages: Stable | Bug Report | Very Low | Low | Pandoc requires specific-version haskell dependencies | Closed | |
Task Description
# 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
|
|
357 | Packages | Bug Report | Very Low | Medium | pacman-contrib 1.10.5 requires rebuild | Closed | |
Task Description
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.
|
|
193 | Packages: Stable | Bug Report | Medium | Low | pacman does not recognize sse2 on via processor | Closed | |
Task Description
/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?
|
|
106 | Packages | Bug Report | Medium | Low | packages are unstripped? | Closed | |
Task Description
looks, like the new devtools do not strip packages anymore - maybe it was only an intermediate version, that lacked automatic stripping.
|
|
350 | Packages | Bug Report | Very Low | High | openssh service will not start | Closed | |
Task Description
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 ~]$
|
|
75 | Packages: Build-list | Bug Report | Medium | Low | openjdk8/10/11/12 break with march=pentium4 optimizatio ... | Closed | |
Task Description
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
> 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 < slacka123> should use “-march=i686 -msse2 -mtune=generic -mfpmath=sse -mstackrealign” instead? 19:54 < slacka123> Yes, it does - https://bugs.documentfoundation.org/show_bug.cgi?id=108619 19:54 < phrik> Title: 108619 – (32bitjavacrash) Java Crash on x86 in jfw_plugin_startJavaVirtualMachine
w/ recent linux kernels (at bugs.documentfoundation.org)
19:55 < slacka123> Fedora 30 also needs that kernel parameter, “stack_guard_gap=1” to run/build
LibreOffice and other java apps
… 19:56 < slacka123> 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>=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&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: <80><98>../jdk10u-jdk-10.0.2+13/build/linux-i386-normal-server-release/images<80><99>: No such file or directory ESC[1mESC[31m==> ERROR:ESC[m^OESC[1m A failure occurred in build().ESC[m^O ESC[1m Aborting…ESC[m^O ==> 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
|
|
17 | Packages | Bug Report | Medium | Low | nvidia and nvidia-lts kernel module build failure on 32 ... | Closed | |
Task Description
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, …
|
|
92 | Packages | Bug Report | Medium | Low | nfs mounts with sec=krb5 fail with 'stale file handle' ... | Closed | |
Task Description
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
|
|
128 | Packages | Bug Report | Medium | Low | newsboat needs rebuild against newer libjson-c | Closed | |
Task Description
newsboat: error while loading shared libraries: libjson-c.so.4: cannot open shared object file: No such file or directory
|
|
86 | Packages: Stable | Bug Report | Medium | Low | newsboat contains SSE2 instuctions | Closed | |
Task Description
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> newsboat
Program received signal SIGILL, Illegal instruction. 0x005f5cd9 in ?? () => 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
|
|
169 | Packages | Feature Request | Very Low | Low | New mirror: mirror.nw-sys.ru | Closed | |
Task Description
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
|
|
178 | Devops | Bug Report | Very Low | Low | New installer overwrites pacman mirrors | Closed | |
Task Description
I tried to install archlinux32 using the archinstall installer, which is shipped with the installation medium. Installation is working fine until pacstrap, where it will crash because all mirrors will return 404. I checked my connection and it is working and dns also works. When I viewed the /etc/pacman.d/mirrorlist file, I saw that the script wrote the default archlinux mirrors for the region specified in the installer to the file and the don’t contain the 32bit packages.
|
|
135 | Packages | Bug Report | Medium | Low | namcap fails on libxkbcommon | Closed | |
Task Description
Checking PKGBUILD
Traceback (most recent call last):
File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/lib/python3.9/site-packages/namcap.py", line 247, in <module>
process_pkgbuild(package, active_modules)
File "/usr/lib/python3.9/site-packages/namcap.py", line 153, in process_pkgbuild
name = "PKGBUILD (" + pkginfo["name"] + ")"
File "/usr/lib/python3.9/site-packages/Namcap/package.py", line 128, in __getitem__
return self._data[self.canonical_varname(key)]
KeyError: 'name'
==> Running checkpkg
error: no targets specified (use -h for help)
==> WARNING: Skipped checkpkg due to missing repo packages
|
|
124 | Packages | Bug Report | Medium | Low | mutter and gnome-shell are in confllict | Closed | |
Task Description
:: installing mutter (3.38.1-1.1) breaks dependency ‘libmutter-6.so=0-32’ required by gnome-shell
|
|
121 | Packages | Bug Report | Very Low | High | Multiple packages need rebuild after libicu upgrade | Closed | |
Task Description
Over in FS#119 , @abaumann mentioned that the libicu upgrade from 67 to 68 was part of what broke gdb. I missed the libicu upgrade when looking at gdb, but now that that one is resolved, I noticed a number of other packages that still link against the old and now nonexistant /usr/lib/libicu*.so.67 files. On my particular system, the following packages are installed, link to icu 67, and need rebuilt as well:
* harfbuzz-icu (2.7.0-1.0) * mongo-c-driver (1.17.3-1.0) * postfix (3.5.6-2.0) * postgresql (12.4-1.0) * postgresql-old-upgrade (12.5-1.0) * samba (4.12.3-1.2) * smbclient (4.12.3-1.2) * syslog-ng (3.28.1-3.0) * texlive-bin (2020.54586-4.0) * xfsprogs (5.8.0-1.0)
… but I’m sure you have a way of determining all the affected packages?
As a workaround, in case others have the same problem, I manually extracted the old versioned .so files from the previous package to get things working again:
``` tar -C / -xf /var/cache/pacman/pkg/icu-67.1-1.0-i686.pkg.tar.zst –wildcards ‘usr/lib/lib*.so.*’ ```
- I’ll just have to remember to clean them up again later.
|
|
190 | Packages: Stable | Bug Report | Very Low | Critical | mpv-1:0.33.1-2.0-pentium4 aborts immediately | Closed | |
Task Description
Here’s 1:0.33.1-1.0-pentium4:
$ pacman -Qs mpv
local/mpv 1:0.33.1-1.0
a free, open source, and cross-platform media player
$ mpv --version
mpv 0.33.1-dirty Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
built on UNKNOWN
FFmpeg library versions:
libavutil 56.51.100
libavcodec 58.91.100
libavformat 58.45.100
libswscale 5.7.100
libavfilter 7.85.100
libswresample 3.7.100
FFmpeg version: n4.3.2
Here’s 1:0.33.1-2.0-pentium4:
$ pacman -Qs mpv
local/mpv 1:0.33.1-2.0
a free, open source, and cross-platform media player
$ mpv --msg-level=all=trace --version
libavutil: 56.70.100 -> 56.51.100
Aborted (core dumped)
Looks to me like it might be a library version thing (I’m up-to-date according to
pacman -Syu
), but I’ve only been running Arch32 for 24 hours so I’m not sure where further to dig.
|
|
191 | Packages | Bug Report | Very Low | Critical | mpv links against libsrt.so.1 which does not exist | Closed | |
Task Description
$ pacman -Qs mpv
local/mpv 1:0.33.1-1.0
a free, open source, and cross-platform media player
$ pacman -Qs srt
local/srt 1.4.3-1.0
Secure Reliable Transport library
$ pacman -Fl srt | grep libsrt
srt usr/lib/libsrt.so
srt usr/lib/libsrt.so.1.4
srt usr/lib/libsrt.so.1.4.3
$ mpv
mpv: error while loading shared libraries: libsrt.so.1: cannot open shared object file: No such file or directory
$ ldd /usr/bin/mpv | grep srt
libsrt.so.1 => not found
$ sudo ln -s /usr/lib/libsrt.so.1.4.3 /usr/lib/libsrt.so.1
$ mpv --version
mpv 0.33.1-dirty Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
built on UNKNOWN
FFmpeg library versions:
libavutil 56.51.100
libavcodec 58.91.100
libavformat 58.45.100
libswscale 5.7.100
libavfilter 7.85.100
libswresample 3.7.100
FFmpeg version: n4.3.2
$ ldd /usr/bin/mpv | grep srt
libsrt.so.1 => /usr/lib/libsrt.so.1 (0xb2a54000)
Running ldconfig does not create the missing symlink.
|
|
241 | Packages | Bug Report | Very Low | Low | mpd probably needs to be rebuilt against pipewire | Closed | |
Task Description
Hi,
If I run mpd, it fails to run due to a missing PW_LOG_TOPIC_DEFAULT symbol: > $ mpd > mpd: symbol lookup error: mpd: undefined symbol: PW_LOG_TOPIC_DEFAULT
While I run Parabola, both mpd and pipewire comes from the i686 repository of Arch Linux 32: > extra/mpd 0.23.5-1.2 [installed] > Flexible, powerful, server-side application for playing music > extra/pipewire 1:0.3.36-1.0 [installed] > Low-latency audio/video router and processor
If I look on a x86_64 Parabola installation instead, PW_LOG_TOPIC_DEFAULT can be found in libpipewire: > $ readelf -s /usr/lib/libpipewire-0.3.so.0 | grep PW_LOG_ > 383: 00000000000d7128 8 OBJECT GLOBAL DEFAULT 21 > PW_LOG_TOPIC_DEFAULT
But that command returns nothing on Parabola i686.
Denis.
|
|
356 | Packages | Bug Report | Medium | Low | mkinitcpio core dump | Closed | |
Task Description
double free or corruption (out)
/usr/bin/mkinitcpio: line 557: 2387 Aborted (core dumped) MKINITCPIO_PROCESS_PRESET="$preset_name" "$0" "${preset_cmd[@]}"
error: command failed to execute correctly
Maybe also the age of the machine, the CMOS, the RAM, the moon, the universe could be at fault here..
|
|
97 | Packages: Stable | Bug Report | Very Low | Low | mesa-vdpau /usr/lib/dri/r300_dri.so links to wrong libL ... | Closed | |
Task Description
grep LLVM /var/log/Xorg.0.log
[ 29.423] (EE) AIGLX error: dlopen of /usr/lib/dri/r300_dri.so failed (libLLVM-8.so: cannot open shared object file: No such file or directory)
[ 29.424] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (libLLVM-8.so: cannot open shared object file: No such file or directory)
ldd /usr/lib/dri/r300_dri.so
linux-gate.so.1 (0xb7f26000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb6836000)
libLLVM-8.so => not found
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb680a000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb6804000)
libsensors.so.5 => /usr/lib/libsensors.so.5 (0xb67f3000)
libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xb67e4000)
libelf.so.1 => /usr/lib/libelf.so.1 (0xb67c6000)
libdrm_amdgpu.so.1 => /usr/lib/libdrm_amdgpu.so.1 (0xb67b9000)
libdrm_nouveau.so.2 => /usr/lib/libdrm_nouveau.so.2 (0xb67ae000)
libglapi.so.0 => /usr/lib/libglapi.so.0 (0xb678d000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6773000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6595000)
libm.so.6 => /usr/lib/libm.so.6 (0xb64c3000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb64a6000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb6483000)
libc.so.6 => /usr/lib/libc.so.6 (0xb62d3000)
/usr/lib/ld-linux.so.2 (0xb7f27000)
ls /usr/lib/libLLVM*
/usr/lib/libLLVM-9.0.0.so /usr/lib/libLLVM-9.so /usr/lib/libLLVM.so
|
|
353 | Packages | Bug Report | Very Low | Low | mc: is broken | Closed | |
Task Description
$ mc
mc: symbol lookup error: mc: undefined symbol: g_string_new_take
$ mcedit
mcedit: symbol lookup error: mcedit: undefined symbol: g_string_new_take
|
|
150 | Packages | Bug Report | Medium | Low | MATE doesn't start up | Closed | |
Task Description
no task description |
|
27 | Packages | Bug Report | Medium | Low | man breaks on gdbm sobump | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 02.02.2018 Last edited by Andreas Baumann - 03.02.2018
FS#27 - man breaks on gdbm sobump
man man: error while loading shared libraries: libgdbm.so.4: cannot open shared object file: No such file or directory
either you must link against libgdbm_compat.so.4 or against libgdbm.5 Closed by Andreas Baumann 03.02.2018 07:47 Reason for closing: Fixed Additional comments about closing:
fixed in man-db-2.7.6.1-3.1, installing that package from testing as temporary is the better solution than adding a symlink you make forget to delete..
Comments (4)
Related Tasks (0/0)
Admin Andreas Baumann commented on 02.02.2018 17:50
temporary workaround: ln -fs libgdbm_compat.so.4 /usr/lib/libgdbm.so.4 Admin Andreas Baumann commented on 02.02.2018 17:53
weird: Archlinux has:
/usr/bin/man is owned by man-db 2.7.6.1-3 gdbm 1.14.1-1
Archlinux 32 has:
man-db 2.7.6.1-3.0 gdbm 1.14.1-1.0
This seems to be pretty much the same version. Admin Erich Eckner commented on 02.02.2018 18:15
it’s amazing what packages we managed to break I scheduled man-db for a rebuild Admin Andreas Baumann commented on 02.02.2018 20:38
man-db is rebuilding on my slave. *fingers crossed*
Google Cache
|
|
137 | Packages | Bug Report | Medium | Low | llvm rebuild fails (aka sphinx requires a python module ... | Closed | |
Task Description
Configuration error:
There is a programmable error in your configuration file:
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/sphinx/config.py", line 326, in eval_config_file
execfile_(filename, namespace)
File "/usr/lib/python3.9/site-packages/sphinx/util/pycompat.py", line 88, in execfile_
exec(code, _globals)
File "/build/llvm/src/llvm-11.0.1.src/docs/conf.py", line 40, in <module>
import recommonmark
ModuleNotFoundError: No module named 'recommonmark'
|
|
238 | Packages | Bug Report | Very Low | Low | Linux-zen kernel 5.16.8.arch1-1.0 made with gcc 11.1 an ... | Closed | |
Task Description
Linux and Linux-zen kernel 5.16.8.arch1-1.0 made with gcc 11.1 and cannot build dkms modules with gcc 11.2
remake linux and linux-zen kernel with gcc version 11.2
|
|
187 | Devops | Bug Report | Medium | Low | linux-pae is for x86_64? | Closed | |
Task Description
This seems to be a problem of either update-archlinux32-package in devops or of the (commented) code path in the PKGBUILD which gets executed by this script.
|
|
60 | Packages: Build-list | Bug Report | Medium | Low | lightdm gtk greeter fails | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 10.01.2019 Last edited by Andreas Baumann - 20.01.2019
FS#60 - lightdm gtk greeter fails
Jan 10 12:55:01 arch32-staging systemd-coredump[894]: Process 892 (lightdm-gtk-gre) of user 620 dumped core.
Stack trace of thread 892:
#0 0x00000000b712bb25 n/a (libglib-2.0.so.0)
#1 0x00000000b7120230 g_log_default_handler (libglib-2.0.so.0)
#2 0x00000000b712bd7d g_logv (libglib-2.0.so.0)
#3 0x00000000b712bf55 g_log (libglib-2.0.so.0)
#4 0x00000000b711267a g_thread_new (libglib-2.0.so.0)
#5 0x00000000b7132a1e n/a (libglib-2.0.so.0)
#6 0x00000000b7132a7a n/a (libglib-2.0.so.0)
#7 0x00000000b70e78d7 g_unix_signal_source_new (libglib-2.0.so.0)
#8 0x00000000b70ea3ef g_unix_signal_add_full (libglib-2.0.so.0)
#9 0x00000000b70ea463 g_unix_signal_add (libglib-2.0.so.0)
#10 0x00000000004dc145 main (lightdm-gtk-greeter)
#11 0x00000000b6c87a49 __libc_start_main (libc.so.6)
#12 0x00000000004de7f5 _start (lightdm-gtk-greeter)
Closed by Andreas Baumann 20.01.2019 16:04 Reason for closing: Fixed Additional comments about closing:
hotfixed in lightdm-1:1.28.0-1.3
Comments (12)
Related Tasks (0/0)
Admin Andreas Baumann commented on 19.01.2019 07:49
So, this happens when registering a signal handler: g_unix_signal_add.
Usually this points into the direction of ABI mismatches.. Admin Andreas Baumann commented on 19.01.2019 08:07
[+0.83s] DEBUG: Session pid=3468: Running command /usr/bin/lightdm-gtk-greeter [+0.83s] DEBUG: Creating shared data directory /var/lib/lightdm-data/lightdm [+0.83s] DEBUG: Session pid=3468: Logging to /var/log/lightdm/seat0-greeter.log [+1.45s] DEBUG: Seat seat0: Stopping; failed to start a greeter
the logfile is empty.
So, the question is, why doesn’t the greeter start and segfault. Admin Andreas Baumann commented on 19.01.2019 09:19
rebuilt both lightdm-gtk-greeter and glib2 with debugging information (options=debug in PKGBUILD).
Now the stacktrace looks like:
#0 0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554 554 G_BREAKPOINT (); (gdb) bt #0 0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554 #1 0xb716d230 in g_log_default_handler
(log_domain=0xb71b40d0 "GLib", log_level=6, message=0x78ee60 "creating thread 'gmain': Error creating thread: Resource temporarily unavailable", unused_data=0x0) at ../glib/glib/gmessages.c:3111
#2 0xb7178d7d in g_logv
(log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s", args=0xbf85e91c "\262\320 \267") at ../glib/glib/gmessages.c:1350
#3 0xb7178f55 in g_log
(log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s") at ../glib/glib/gmessages.c:1413
#4 0xb715f67a in g_thread_new (name=0xb720d0b2 “gmain”, func=0xb7180b70 , data=0×0)
at ../glib/glib/gthread.c:830
#5 0xb717fa1e in g_get_worker_context () at ../glib/glib/gmain.c:5888 #6 0xb717fa7a in ref_unix_signal_handler_unlocked (signum=15, signum
at ../glib/glib/gmain.c:5224
#7 0xb71348d7 in _g_main_create_unix_signal_watch (signum=15) at ../glib/glib/gmain.c:5332 #8 0xb71348d7 in g_unix_signal_source_new (signum=15, signum
at ../glib/glib/glib-unix.c:222
#9 0xb71373ef in g_unix_signal_add_full
(priority=0, signum=15, handler=0x495f90 , user_data=0x1, notify=0x0)
at ../glib/glib/glib-unix.c:252
#10 0xb7137463 in g_unix_signal_add (signum=15, handler=0x495f90 , user_data=0×1) –Type for more, q to quit, c to continue without paging–
at ../glib/glib/glib-unix.c:283
#11 0×00490145 in main (argc=, argv at lightdm-gtk-greeter.c:2768
Admin Andreas Baumann commented on 19.01.2019 09:44
creating thread ‘gmain’: Error creating thread: Resource temporarily unavailable
This is the interesting one. Why should creating a thread run out of resources? And which resources? Admin Andreas Baumann commented on 19.01.2019 09:47
This is not by any chance an unhandled EAGAIN? Admin Andreas Baumann commented on 19.01.2019 10:04
[pid 6607] execve(”/usr/bin/core_perl/plymouth”, [”plymouth”, “–ping”], 0xbfa9086c /* 22 vars */) = -1 ENOENT (No such file or directory)
this seems a collateral damage (aka hard-coded call to the bootup manager plymouth), not every Linux distribution has a plymouth, so I hope, this is actually optional.. The -ping indicates, that plymouth is started with ping, to see whether it is around. It doesn’t seem to have something to do with our problem though..
There is a strace entry showing the greeter gets started:
[pid 6616] execve(”/usr/bin/lightdm-gtk-greeter”, [”/usr/bin/lightdm-gtk-greeter”], 0xf61510 /* 15 vars */) = 0
later the sighandler tries to open a new thread:
825 GThread *thread; 826 827 thread = g_thread_new_internal (name, g_thread_proxy, func, data, 0, &error); 828 829 if G_UNLIKELY (thread == NULL) 830 g_error (”creating thread ‘%s’: %s”, name ? name : ““, error->message); 831 832 return thread;
So, if it runs out of resources here (due to a systemd limit, rlimit thing), this would explain the startup issues..
There is also a suspicious:
[pid 6616] mmap2(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)
So, I check the rlimit settings used by systemd for login session.. Admin Andreas Baumann commented on 20.01.2019 09:21
Sounds related:
https://github.com/abrt/faf/issues/212 Admin Andreas Baumann commented on 20.01.2019 10:37
mmh. why does lightdm-gtk-greeter work on 64-bit Archlinux? Admin Andreas Baumann commented on 20.01.2019 10:55
aha. the mmap works there. Admin Andreas Baumann commented on 20.01.2019 13:54
lightdm-gtk-greeter.c
mlockall (MCL_CURRENT | MCL_FUTURE);
commenting that out lets the mmap2 succeed.
As we deal with passwords, just disabling the locking is maybe not the best idea.
Incrementing the systemd limit in lightdm.conf LimitMEMLOCK=2684354560 didn’t help at all. Admin Andreas Baumann commented on 20.01.2019 13:58
Locking the whole greeter with all GTK inside is maybe also not the wisest idea.. Admin Andreas Baumann commented on 20.01.2019 14:03
LimitMEMLOCK=infinity in /lib/systemd/system/lightdm.service seemed so help.
Google Cache
|
|
131 | Packages | Bug Report | Medium | Low | libseccomp doesn't build in python bindings | Closed | |
Task Description
no task description |
|
31 | Packages | Bug Report | Medium | Low | librsvg fails with invalid opcode on 2.42.1 and newer | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Swift Geek - 16.03.2018 Last edited by Andreas Baumann - 26.03.2018
FS#31 - librsvg fails with invalid opcode on 2.42.1 and newer
traps: gtk3-demo[365] trap invalid opcode ip:aedd3e15 sp:bffc64c0 error:0 in librsvg-2.so.2.42.3[aed27000+11a000]
Downgrading to 2.40.19 seems to help. https://archive.archlinux32.org/repos/2017/11/01/extra/os/i686/librsvg-2:2.40.19-1-i686.pkg.tar.xz
This could be related to machine not having SSE2 (Pentium III-M Tualin)
Related bbs thread: https://bbs.archlinux32.org/viewtopic.php?id=1369 Closed by Andreas Baumann 26.03.2018 15:02 Reason for closing: Fixed
Comments (1)
Related Tasks (0/0)
Paul Gover commented on 26.03.2018 11:03
For me, librsvg-2:2.42.3-1.2 fixes the problem
Google Cache
|
|
77 | Packages: Build-list | Bug Report | Medium | Low | librsvg doesn't rebuild | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 30.05.2019
FS#77 - librsvg doesn’t rebuild
-> /build/librsvg/src/librsvg/target/release/build/typenum-ff577e94a786118f/out/consts.rs:2113:5
| 2111 | pub type P1024 = PInt; pub type N1024 = NInt;
| ----------------------------- previous definition of the type `P1024` here
2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>; 2113 | pub type P1024 = PInt; pub type N1024 = NInt;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `P1024` redefined here
|
= note: `P1024` must be defined only once in the type namespace of this module
error[E0428]: the name `N1024` is defined multiple times
-> /build/librsvg/src/librsvg/target/release/build/typenum-ff577e94a786118f/out/consts.rs:2113:35
| 2111 | pub type P1024 = PInt; pub type N1024 = NInt;
| ----------------------------- previous definition of the type `N1024` here
2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>; 2113 | pub type P1024 = PInt; pub type N1024 = NInt;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `N1024` redefined here
|
= note: `N1024` must be defined only once in the type namespace of this module
error: aborting due to 3 previous errors
For more information about this error, try `rustc –explain E0428`. error: Could not compile `typenum`.
Caused by:
process didn't exit successfully: `rustc --crate-name typenum /build/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.10.0/src/lib.rs --color never --crate-type lib --emit=dep-info,link -C opt-level=3 -C debuginfo=2 -C metadata=045a2ce7f5cfaab5 -C extra-filename=-045a2ce7f5cfaab5 --out-dir /build/librsvg/src/librsvg/target/release/deps -L dependency=/build/librsvg/src/librsvg/target/release/deps --cap-lints allow -C target-cpu=pentium3 -C target-feature=-sse2` (exit code: 1)
warning: build failed, waiting for other jobs to finish… error: build failed make[2]: * [Makefile:1934: /build/librsvg/src/librsvg/target/release/librsvg_internals.a] Error 101 make[2]: Leaving directory ‘/build/librsvg/src/librsvg’
make[1]: * [Makefile:1438: all-recursive] Error 1 make[1]: Leaving directory ‘/build/librsvg/src/librsvg’ make: *** [Makefile:931: all] Error 2
The same error with typenum as when bootstrapping rust in stage 2.
librsvg is very important as it blocks tons of other stuff (so why again was it written in Rust?!)
I might have seen a Debian patch for it, but Debian goes a “complete Rust micro-packaging” way, not sure whether we can apply it here?
Comments (1)
Related Tasks (0/0)
Levi commented on 30.05.2019 18:26
Since it looks to me like it’s redefining P1024 and N1024 the same, can’t you just eliminate one of these definitions. Sure, it makes a patch you’d have to maintain henceforth until they fix this upstream, and I don’t understand what kind of preprocessing is ending up with this particular duplication, but deleting a line is about the simplest patch you could maintain.
Google Cache
|
|
23 | Packages: Build-list | Bug Report | Medium | Low | libretro* packages failing, seem unsupported for 32-bit ... | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 04.01.2018 Last edited by Erich Eckner - 26.01.2018
FS#23 - libretro* packages failing, seem unsupported for 32-bit Intel/Linux
This affects the following packages: - libretro-citra (unsuported architecture in dynarmic submodule) - libretro-parallel-n64: tons of assembly errors - libretro-ppsspp: linking issues with ffmpeg - libretro-mupen64plus: direct GOT relocation R_386_GOT32X against _ZN9PluginAPI3getEv PluginAPI::get()
blacklisting all. Closed by Erich Eckner 26.01.2018 17:08 Reason for closing: Won’t fix Additional comments about closing:
blacklisted
Comments (0)
Google Cache
|
|
328 | Packages | Bug Report | Very Low | Medium | libreoffice-fresh on i686 is newer then pentium4 | Closed | |
Task Description
i686:- libreoffice-fresh 7.3.4-2.1 pentium4:- libreoffice-fresh 7.3.2-1.0
|
|
76 | Packages: Stable | Bug Report | Medium | Low | libreoffice-fresh needs to be rebuild against icu | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Raphael Scholer - 25.05.2019
FS#76 - libreoffice-fresh needs to be rebuild against icu
Comments (1)
Related Tasks (0/0)
Levi commented on 25.05.2019 18:22
This bug is already captured 90% by https://bugs.archlinux32.org/index.php?do=details&task_id=72 (see my comment underneath it), although to be fair I noted it against libreoffice-stable since that’s what I use.
Google Cache
|