Parabola Issue Tracker: Issueshttps://labs.parabola.nu/https://labs.parabola.nu/favicon.ico?15367742552023-09-25T09:03:36ZParabola Issue Tracker
Redmine Servers - Bug #3533 (confirmed): [parabolaweb]: does not ping IPv6-only mirrors, and does not sho...https://labs.parabola.nu/issues/35332023-09-25T09:03:36Zbill-auger
<p>for example:<br /><a class="external" href="https://www.parabola.nu/mirrors/cyberbits.asia/">https://www.parabola.nu/mirrors/cyberbits.asia/</a></p>
<p>it is currently the only such example; so this is still a hunch - however, i noticed a similar problem recently with yandex - they apparently had two separate replicas, one for IPv4 and one for IPv6 - parabolaweb only checks via IPv4 and it reported the mirror as out-of-sync - the IPv6 replica was up-to-date; but the IPv4 replica was not synch-ing - even their admin was confused at first, until i discovered the discrepancy between them</p> Servers - Bug #3508 (confirmed): [librerelease]: creates other/ directories owned by the userhttps://labs.parabola.nu/issues/35082023-07-15T05:45:47Zbill-auger
<p>this is probably an overlooked regression from when `librerelase` was changed to run as each user, staging in each user's $HOME, rather than as 'repo' user</p>
<p>the problem that causes is that no one else can publish a new libre source-ball, due to lack of permission in the target dir</p> Servers - Bug #3351 (in progress): git.parabola.nu 504 gateway time-outshttps://labs.parabola.nu/issues/33512022-09-26T00:52:46Zgap
<p>Over the last few days, <a class="external" href="https://git.parabola.nu">https://git.parabola.nu</a> has been taking ages to load and displaying many "504 Gateway Time-Out"s from nginx 1.16.1.<br />Am I the only one experiencing this?</p>
<p>Seeing as the latest version of nginx is 1.22.0, perhaps the issue is that nginx is outdated.<br />I also recall <a class="user active" href="https://labs.parabola.nu/users/282">bill-auger</a> saying cgit was misbehaving, so perhaps we should migrate to another git web interface.</p>
<p>The server might also be busy doing other tasks like building packages, but I don't know if this is the case.<br />This may also be a bandwidth issue but I doubt it.</p>
<p>In the worst case scenario, this could be a DoS or DDoS but I highly doubt this too.</p> Servers - Bug #3343 (unconfirmed): SSL connection timeouts towards redirector.parabola.nuhttps://labs.parabola.nu/issues/33432022-09-15T14:42:39ZDrag0nFly
<p>A number of packages today failed to be retrieved during a system upgradeādespite several tries.</p>
<pre><code class="shell syntaxhl"> python-cachecontrol-1:0.12.11-1-any.pkg.tar.zst failed to download
Total <span class="o">(</span>28/63<span class="o">)</span> 2.6 MiB 55.3 KiB/s 00:47 <span class="o">[</span><span class="c">################################################################################] 100%</span>
error: failed retrieving file <span class="s1">'sfsexp-1.4.0-1-x86_64.pkg.tar.zst'</span> from redirector.parabola.nu : SSL connection <span class="nb">timeout
</span>error: failed retrieving file <span class="s1">'python-cachecontrol-1:0.12.11-1-any.pkg.tar.zst'</span> from redirector.parabola.nu : SSL connection <span class="nb">timeout
</span>error: failed retrieving file <span class="s1">'python-cachecontrol-1:0.12.11-1-any.pkg.tar.zst'</span> from redirector.parabola.nu : SSL connection <span class="nb">timeout
</span>warning: too many errors from redirector.parabola.nu, skipping <span class="k">for </span>the remainder of this transaction
warning: failed to retrieve some files
error: failed to commit transaction <span class="o">(</span>download library error<span class="o">)</span>
Errors occurred, no packages were upgraded.
<span class="nb">grep </span>synchronizing /var/log/pacman.log | <span class="nb">tail</span> <span class="nt">-2</span>
<span class="o">[</span>2022-09-15T16:31:51+0200] <span class="o">[</span>PACMAN] synchronizing package lists
<span class="o">[</span>2022-09-15T16:36:29+0200] <span class="o">[</span>PACMAN] synchronizing package lists
</code></pre>
<p>This is similar to the previous issue which was reported. However, I can no longer find it in the bug list, so therefore opening a new ticket.</p> Servers - Bug #3178 (in progress): [parabola-repolint]: failed to detect registered, but missing ...https://labs.parabola.nu/issues/31782022-02-11T16:57:36Zbill-auger
<ul>
<li>steps to reproduce:<br /><pre>
# pacman -S lua53-lgi
</pre></li>
</ul>
<ul>
<li>expected result:<br /> lua53-lgi installs properly</li>
</ul>
<ul>
<li>actual result:<br /><pre>
# pacman -S lua53-lgi
....
extra/lua53 5.3.6-1 1.05 MiB
community/lua53-lgi 0.9.2-7 0.66 MiB 0.23 MiB
....
:: Retrieving packages...
lua53-lgi-0.9.2-7-x86_64.pkg.tar.zst failed to download
error: failed retrieving file 'lua53-lgi-0.9.2-7-x86_64.pkg.tar.zst' from repo.parabola.nu : The requested URL returned error: 404
warning: failed to retrieve some files
error: failed to commit transaction (failed to retrieve some files)
Errors occurred, no packages were upgraded.
</pre></li>
</ul> Servers - Bug #3038 (confirmed): autobuilder chroot cannot initialize libalpmhttps://labs.parabola.nu/issues/30382021-05-23T04:57:59Zbill-auger
<p><bill-auger> <oaken-source> bill-auger: this might be related: <a class="external" href="https://bugs.archlinux.org/task/69563">https://bugs.archlinux.org/task/69563</a><br /><bill-auger> <oaken-source> faccessat2() was introduced in Linux 5.8, so glibc 2.33 won't work in containers on hosts that have older kernels.<br /><bill-auger> <oaken-source> the failing syscall is faccessat2, as verified by strace<br /><bill-auger> <oaken-source> so we have to either downgrade the glibc in the chroot, or upgrade the glibc on the host<br /><bill-auger> IIRC you chose to downgrade glibc in the chroot<br /><bill-auger> <oaken-source> there is a compatibility package for glibc-2.33 on linux4<br /><bill-auger> <oaken-source> which doesn't include the faccessat2 system call<br /><bill-auger> <oaken-source> bill-auger: this fix <strong>will</strong> break next time glibc is upgraded in the chroot.<br /><bill-auger> ... and that was today - the autobuilder chroot auto-upgrades, and glibc got replaced</p>
<p><oaken-source> fortunately, an upgraded package for the fix is available. I'm upgrading in the chroot<br /><oaken-source> but this will obviously keep happening until we upgrade winston<br /><oaken-source> the trick is to procure a glibc-linux4-${glibc_pkgver}-${glibc_pegrel}-x86_64.pkg.tar.zst for the most recent glibc<br /><oaken-source> and then pacman -U ${glibc_linux4} -r /var/lib/archbuild/autobuilder/root/</p> Servers - Bug #3014 (confirmed): [labs.parabola.nu] Unusable layout on some widthshttps://labs.parabola.nu/issues/30142021-04-16T16:00:58Zbiovoid
<p>Between 900 and 1039 pixels wide, the forum/issues layout pushes the content to a sliver on the left side. Please see attached screenshots.</p> Servers - Bug #3004 (confirmed): [parabolaweb] Package flag out-of-date does not mark package as ...https://labs.parabola.nu/issues/30042021-04-02T18:10:32ZAnonymous
<p>For both packages, the out-of-date flag option does not change out-of-date status.</p>
<p>The post form reads:</p>
<p><cite>Note that the following 0 packages will be marked out of date:</cite></p>
<p>while the confirmation states:</p>
<p><cite>Thank you, the maintainers have been notified the following 6 packages are out-of-date:<br />elogind 243.7-2 [nonsystemd] (armv7h)<br />elogind 243.7-2 [nonsystemd] (i686)<br />elogind 243.7-2 [nonsystemd] (x86_64)<br />libelogind 243.7-2 [nonsystemd] (armv7h)<br />libelogind 243.7-2 [nonsystemd] (i686)<br />libelogind 243.7-2 [nonsystemd] (x86_64)</cite></p>
<p>However, the notification was sent while the Web interface did not reflect the change.</p> Servers - Bug #2861 (confirmed): hackers.git linter script accepts an insane configurationhttps://labs.parabola.nu/issues/28612020-08-09T04:00:05Zbill-auger
<p>there is a rather serious bug in the hackers.git linter script (parabola-hackers::bin/meta-check), which causes the nshd.service to crash, on the server where 'git' and 'autobuilder' live, upon a git push to hackers.git</p>
<p>the problem seems to be, that if any YAML file has a complete 'ssh_keys' entry, but is missing the 'shell' field, the linter will accept it; but it is fatal to the 'nshd'->'hackers-init' services - those are reloaded, as an initial step of the git hooks, and begin to process the insane configuration, and fail to initialize - the result is that no 'parabola-hackers' managed users exist on the system, and so the autobuilder fails to build the keyring (because the autobuilder user is also a 'parabola-hackers' managed user) - worse though, is that all shell logins are rejected for the same reason; and the nshd service can not be restarted until the offending YAML file is corrected - luckily, the 'git' user is not a 'parabola-hackers' managed user; so it can be corrected without logging in as a 'hacker'</p>
<p>i have not looked at the linter script yet; but i noticed that all YAML files have a complete 'shell' entry: (shell: "/bin/bash"), incliding those which shall have no shell access - its not clear if that is mandatory or not - perhaps, it is only the presence of the complete 'ssh_keys' entry, which causes the missing 'shell' entry to be fatal; but there is surely no necessity to specify a preferred shell, for users which shall have no shell access</p> Tools - Bug #1444 (open): [notsystemd] Remove logind, depend on elogindhttps://labs.parabola.nu/issues/14442017-08-19T00:01:48ZMegver83megver83@parabola.nu
<p>Hi, many DEs in the Systemd-free world are migrating to elogind, which has files in common with notsystemd. They can coexist, but for that I had to do a --force when installing with pacman. I was thinking that, as elogind is more optimized for non-systemd systems maybe we can remove those conflicting files from notsystemd and make elogind a dependency of it (at least as optional).</p>
<p>I [added eudev in provides=()](<a class="external" href="https://git.parabola.nu/abslibre.git/commit/libre/notsystemd?id=4fecb274dba93f27c116fdf19545cac09fdf2e7f">https://git.parabola.nu/abslibre.git/commit/libre/notsystemd?id=4fecb274dba93f27c116fdf19545cac09fdf2e7f</a>) as the eudev-openrc init script works with notsystemd's udev, but couldn't do the same for elogind-openrc. Elogind depends on eudev, and (as I said) it can work with notsystemd but it needs a better integration by its side.</p>
<p>The second option would be to include elogind inside notsystemd, so then put elogind in provides=() as I did with eudev, but I think it's easier to put it as a dependency.</p>
<p>Here I attach the list of files that conflict with elogind.</p> Tools - Bug #737 (open): [dbscripts]/[xbs-abslibre]: db-update complains when releasing split pac...https://labs.parabola.nu/issues/7372015-06-08T06:34:17Zlukeshulukeshu@parabola.nu
<p>For all but one of the split package members for each architecture, it will spit out</p>
<pre>
On branch master
nothing to commit, working directory clean
==> ERROR: An unknown error has occurred. Exiting...
/usr/bin/xbs: line 103: XXXXX User defined signal 1 "$HELPER" release-server "$@"
==> ERROR cd staging/XXXX//abslibre/XXXX/XXXX/XXXX && xbs release-server XXXX XXXX
</pre>
<p>The message is harmless, but it should be fixed.</p>
<p>I take full blame, and know what has to happen.</p> Tools - Bug #561 (open): [db-import-*]/[blacklist] I want to specify `pkgbase's, not `pkgname's.https://labs.parabola.nu/issues/5612014-06-23T03:18:12Zlukeshulukeshu@parabola.nu
<p>Yeah.</p> Tools - Bug #543 (open): [jh checksource] Should detect generated source files.https://labs.parabola.nu/issues/5432014-06-10T16:36:33Zlukeshulukeshu@parabola.nu
<p>Off the top of my head, that means these tools:</p>
<ul>
<li>JavaCC (<code>1/Generated By:(JJTree|JavaCC|JJTree&JavaCC):/</code>)</li>
<li>byaccj</li>
<li>JLex</li>
<li>JFlex</li>
</ul> Tools - Bug #473 (open): [abs] Gives you the same tree no matter the arch, despite discrepencies ...https://labs.parabola.nu/issues/4732014-01-22T06:37:26Zlukeshulukeshu@parabola.nu
<p>Title says it.</p> Tools - Bug #472 (open): I want [abs] to be implemented as `git pull`https://labs.parabola.nu/issues/4722014-01-22T06:36:34Zlukeshulukeshu@parabola.nu
<p>The entire ABS should be in a publicly available git (-pre-mips64el is not public, though perhaps it should be), and we should KISS. Also having rsync is fine, but I want it to use git.</p>