Parabola Issue Tracker: Issueshttps://labs.parabola.nu/https://labs.parabola.nu/favicon.ico?15367742552023-04-22T17:10:16ZParabola Issue Tracker
Redmine Packages - Freedom Issue #3471 (unconfirmed): [netctl] unclear licensehttps://labs.parabola.nu/issues/34712023-04-22T17:10:16ZGNUtooGNUtoo@cyberdimension.org
The netctl source code seems to be available here: <a class="external" href="https://gitlab.archlinux.org/archlinux/netctl">https://gitlab.archlinux.org/archlinux/netctl</a> and after downloading it, the only hints for a license are:
<ul>
<li>that there is a COPYING file</li>
<li>that for some reasons <a class="external" href="https://gitlab.archlinux.org/archlinux/netctl">https://gitlab.archlinux.org/archlinux/netctl</a> has a GNU GPLv3 button that then brings to a page that has this text: "This project is licensed under the GNU General Public License v3.0 only. Learn more". But this is done automatically by gitlab.</li>
</ul>
<p>So we probably need upstream to clarify the license of that software by sending a patch to do that (for instance by telling that this program and all that is in this git repository is released under the GPLv3 or later in the README as per what's explained both in the GPLv3 text (how to apply [...] and in the documentation that explains how to apply the GPL ( <a class="external" href="https://www.gnu.org/licenses/gpl-howto.html#why-license-notices">https://www.gnu.org/licenses/gpl-howto.html#why-license-notices</a> ).</p>
<p>Once done we can also update the FSD entry about netctl as well: <a class="external" href="https://directory.fsf.org/wiki/Netctl">https://directory.fsf.org/wiki/Netctl</a></p> Packages - Freedom Issue #3412 (unconfirmed): Evaluate the libreoffice extensions repositoryhttps://labs.parabola.nu/issues/34122022-12-27T23:55:36ZGNUtooGNUtoo@cyberdimension.orgPackages - Bug #3269 (unconfirmed): [telegram-desktop] possible DRM, security, privacy, and anony...https://labs.parabola.nu/issues/32692022-05-05T14:25:13ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>Someone described on the gnu-linux-libre mailing list a Telegram anti-feature that looks like DRM to me<sup><a href="#fn1">1</a></sup>: that anti-feature "forbids the user to copy/paste or forward text (and also forbids saving images or other media included in the messages) from certain groups where the admin has enabled the restriction".</p>
<p id="fn1" class="footnote"><sup>1</sup> <a class="external" href="https://lists.nongnu.org/archive/html/gnu-linux-libre/2022-05/msg00002.html">https://lists.nongnu.org/archive/html/gnu-linux-libre/2022-05/msg00002.html</a></p> Packages - Bug #3212 (unconfirmed): valgrind broken on armv7hhttps://labs.parabola.nu/issues/32122022-04-01T22:09:07ZGNUtooGNUtoo@cyberdimension.org
<p>on armv7h, valgrind is broken:<br /><pre>
$ make check
cc main.c -o main
valgrind --leak-check=full ./main
==10136== Memcheck, a memory error detector
==10136== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==10136== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==10136== Command: ./main
==10136==
==10136== Invalid write of size 4
==10136== at 0x401B100: _dl_start (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7b54 is on thread 1's stack
==10136== 120 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401236C: _dl_setup_hash (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7b68 is on thread 1's stack
==10136== 8 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4019548: _dl_sysdep_start (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7aec is on thread 1's stack
==10136== 104 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4015858: __GI___tunables_init (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7a8c is on thread 1's stack
==10136== 96 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4012544: _dl_sort_maps_init (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7afc is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401FC24: sbrk (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7af0 is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401BBF0: dl_main (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78dc is on thread 1's stack
==10136== 528 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400C488: _dl_new_object (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78ac is on thread 1's stack
==10136== 48 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400BF50: __minimal_calloc (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78b0 is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400BDF4: __minimal_malloc (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78ac is on thread 1's stack
==10136== 24 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400C3B8: _dl_add_to_namespace_list (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78e0 is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4019CCC: _dl_discover_osversion (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f76ec is on thread 1's stack
==10136== 496 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x400716C: _dl_init_paths (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78bc is on thread 1's stack
==10136== 40 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x40181F8: _dl_important_hwcaps (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7844 is on thread 1's stack
==10136== 112 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4018CAC: _dl_hwcaps_split_masked (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7858 is on thread 1's stack
==10136== 8 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4018BA0: _dl_hwcaps_split (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f7840 is on thread 1's stack
==10136== 16 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x4018140: copy_hwcaps (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f780c is on thread 1's stack
==10136== 40 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401B074: audit_list_add_dynamic_tag (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78f0 is on thread 1's stack
==10136== 8 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x40164D4: _dl_audit_activity_map (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f78b0 is on thread 1's stack
==10136== 40 bytes below stack pointer
==10136==
==10136== Invalid write of size 4
==10136== at 0x401BACC: handle_preload_list (in /usr/lib/ld-linux-armhf.so.3)
==10136== Address 0xbd9f68dc is not stack'd, malloc'd or (recently) free'd
==10136==
==10136==
==10136== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==10136== Access not within mapped region at address 0xBD9F68DC
==10136== at 0x401BACC: handle_preload_list (in /usr/lib/ld-linux-armhf.so.3)
==10136== If you believe this happened as a result of a stack
==10136== overflow in your program's main thread (unlikely but
==10136== possible), you can try to increase the size of the
==10136== main thread stack using the --main-stacksize= flag.
==10136== The main thread stack size used in this run was 8388608.
==10136==
==10136== HEAP SUMMARY:
==10136== in use at exit: 0 bytes in 0 blocks
==10136== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==10136==
==10136== All heap blocks were freed -- no leaks are possible
==10136==
==10136== For lists of detected and suppressed errors, rerun with: -s
==10136== ERROR SUMMARY: 33 errors from 20 contexts (suppressed: 0 from 0)
make: *** [Makefile:4: check] Segmentation fault (core dumped)
</pre></p>
<p>Here's my valgrind version on armv7h:<br /><pre>
$ pacman -sS valgrind
extra/valgrind 3.18.1-3 [installed]
Tool to help find memory-management problems in programs
[...]
</pre></p>
<p>On i686 I have instead:<br /><pre>
$ make check
cc main.c -o main
valgrind --leak-check=full ./main
==29363== Memcheck, a memory error detector
==29363== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29363== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==29363== Command: ./main
==29363==
Hello world
==29363==
==29363== HEAP SUMMARY:
==29363== in use at exit: 0 bytes in 0 blocks
==29363== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==29363==
==29363== All heap blocks were freed -- no leaks are possible
==29363==
==29363== For lists of detected and suppressed errors, rerun with: -s
==29363== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
</pre></p>
<p>With the following valgrind version:<br /><pre>
$ pacman -sS valgrind
extra/valgrind 3.18.1-4.0 [installed]
Tool to help find memory-management problems in programs
[...]
</pre></p>
<p>And on x86_64:<br /><pre>
# make check
cc main.c -o main
valgrind --leak-check=full ./main
==724655== Memcheck, a memory error detector
==724655== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==724655== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==724655== Command: ./main
==724655==
Hello world
==724655==
==724655== HEAP SUMMARY:
==724655== in use at exit: 0 bytes in 0 blocks
==724655== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==724655==
==724655== All heap blocks were freed -- no leaks are possible
==724655==
==724655== For lists of detected and suppressed errors, rerun with: -s
==724655== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
</pre></p>
<p>With the following valgrind version:<br /><pre>
# pacman -sS valgrind
extra/valgrind 3.18.1-4 [installed]
Tool to help find memory-management problems in programs
[...]
</pre></p>
<p>I've attached the files used by they are a simple hello world and a Makefile that runs valgrind --leak-check=full ./main</p> Packages - Bug #3211 (unconfirmed): gdb broken on armv7h when linking to opensslhttps://labs.parabola.nu/issues/32112022-04-01T22:00:26ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>If I link a hello world to libcrypto, I can't debug it anymore on armv7h:<br /><pre>
$ make check
cc main.c -o main -lcrypto
gdb ./main < commands.txt
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "armv7l-unknown-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
(No debugging symbols found in ./main)
(gdb) Starting program: /home/replicant/gdb-test/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
0xb6dec408 in ?? () from /usr/lib/libcrypto.so.1.1
(gdb) A debugging session is active.
Inferior 1 [process 9953] will be killed.
Quit anyway? (y or n) [answered Y; input not from terminal]
</pre></p>
<p>Here libcrypto comes from OpenSSL:</p>
<pre>
$ pacman -Q -o /usr/lib/libcrypto.so.1.1
/usr/lib/libcrypto.so.1.1 is owned by openssl 1.1.1.n-1
</pre>
<p>I've tried recompiling gdb and openssl and it didn't change<br />anything (it still crashed).</p>
<p>I've restored Parabola's gdb and openssl (by reinstalling them) <br />before doing the test I pasted above.</p>
<p>On i686 however it works fine:<br /><pre>
make check
cc main.c -o main -lcrypto
gdb ./main < commands.txt
GNU gdb (GDB) 11.1
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
(No debugging symbols found in ./main)
(gdb) Starting program: /tmp/tmp.OiT2tDGGNe/gdb-test/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Hello world
[Inferior 1 (process 28480) exited normally]
</pre></p>
<p>And here's OpenSSL version:<br /><pre>
$ pacman -Q -o /usr/lib/libcrypto.so.1.1
/usr/lib/libcrypto.so.1.1 is owned by openssl 1.1.1.n-1.0
</pre></p>
<p>And on x86_64 I've also no issues:<br /><pre>
# make check
cc main.c -o main -lcrypto
gdb ./main < commands.txt
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
(No debugging symbols found in ./main)
(gdb) Starting program: /root/gdb-test/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Hello world
[Inferior 1 (process 724520) exited normally]
</pre></p>
<p>And the OpenSSL version is the same than on armv7h:<br /><pre>
# pacman -Q -o /usr/lib/libcrypto.so.1.1
/usr/lib/libcrypto.so.1.1 is owned by openssl 1.1.1.n-1
</pre></p>
<p>I've attached the files used during the test, though it's just<br />a hello world and it just runs it through gdb so there is nothing fancy.</p> Packages - Bug #3193 (unconfirmed): /etc/pacman.d/gnupg/gpg.conf is not updatedhttps://labs.parabola.nu/issues/31932022-02-22T16:26:32ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>Many Parabola systems (including winston) have an old <code>/etc/pacman.d/gnupg/gpg.conf</code> with the following content:<br /><pre>
no-greeting
no-permission-warning
lock-never
keyserver-options timeout=10
keyserver pool.sks-keyservers.net
</pre></p>
<p>Instead it should have that:<br /><pre>
no-greeting
no-permission-warning
lock-never
keyserver-options timeout=10
keyserver-options import-clean
keyserver-options no-self-sigs-only
</pre></p>
<p>Somehow <code>gpg.conf</code> should be updated.</p>
<p>I've no idea if it's a bug in Parabola or Arch Linux though.</p> Packages - Housekeeping #2863 (open): Clarify the policy with UEFI "secure boot" and restricted boothttps://labs.parabola.nu/issues/28632020-08-09T06:42:15ZGNUtooGNUtoo@cyberdimension.orgPackages - Housekeeping #2862 (open): Clarify the copyright status of PKGBUILDshttps://labs.parabola.nu/issues/28622020-08-09T05:57:20ZGNUtooGNUtoo@cyberdimension.orgPackages - Bug #2805 (unconfirmed): Verify if the u-boot documentation is FSDG complianthttps://labs.parabola.nu/issues/28052020-06-14T18:54:57ZGNUtooGNUtoo@cyberdimension.orgUpstreaming Patches - Upstreaming #2802 (open): Add Parabola pacstrap support in Hyperbolahttps://labs.parabola.nu/issues/28022020-06-12T21:47:59ZGNUtooGNUtoo@cyberdimension.orgPackages - Feature Request #2578 (open): ARM: Add back GRUBhttps://labs.parabola.nu/issues/25782019-12-09T22:35:46ZGNUtooGNUtoo@cyberdimension.org
<p>On ARM, we currently use the standard distro booting scheme from u-boot:<br />- It tries boot.scr first<br />- It then try syslinux.cfg which is more familiar to people used to x86.</p>
<p>This can be improved to be even more by using grub which is even more familiar as most people are already using it on x86.</p> Installation Media - Feature Request #1780 (open): [armv7] do not set user/root password in futur...https://labs.parabola.nu/issues/17802018-05-02T11:11:24ZGNUtooGNUtoo@cyberdimension.org
<p>The <a class="external" href="https://repomirror.parabola.nu/iso/arm/LATEST/ParabolaARM-armv7-LATEST.tar.gz:"lastest">https://repomirror.parabola.nu/iso/arm/LATEST/ParabolaARM-armv7-LATEST.tar.gz:"lastest</a>" (at the time of writing) tarball release has a password set.</p>
<p>After booting the user can't log in.</p>
<p>Having no passwords in the next tarball release (and optionally adding the password to the <a class="external" href="https://wiki.parabola.nu/ARM_Installation_Guide#Change_or_set_the_root_password:"ARM">https://wiki.parabola.nu/ARM_Installation_Guide#Change_or_set_the_root_password:"ARM</a> installation guide" for this release would fix it.</p> Packages - Bug #1779 (open): [armv7] compile [qemu-user-static-binfmt]https://labs.parabola.nu/issues/17792018-05-01T15:31:32ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>Having qemu-user-static-binfmt would be nice to have on ARM, as it could enable users to transparently run x86 code.</p>
<p>On Parabola x86, it works fine to run arm code (with it you can transparently arch-chroot inside a Parabola ARM installation for instance)</p>
<p>Denis.</p> Ports - Porting #1252 (open): abs not working (+GPL issue?)https://labs.parabola.nu/issues/12522017-03-22T09:57:11ZGNUtooGNUtoo@cyberdimension.org
<p>Hi,</p>
<p>With the default config, I can't get the sources:</p>
<pre>
# uname -m
armv7l
# abs
==> ERROR: No mirrors found in mirrorlist file /etc/pacman.d/mirrorlist
</pre>
<p>In the default config /etc/pacman.d/mirrorlist is the same than on x86, I don't know if that information is relevant or not.</p>
<p>Denis.</p> Ports - Bug #1039 (open): ARM: architecture not autodetected properlyhttps://labs.parabola.nu/issues/10392016-06-21T19:30:18ZGNUtooGNUtoo@cyberdimension.org
<p>On my GTA04 which runs Parabola I have:<br /><pre>
# uname -m
armv7l
</pre></p>
<p>This seem to be picked by pacman, and I'm required to force the architectuer to armv7h in /etc/pacman.conf like that:<br /><pre>
Architecture = armv7h
</pre></p>