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 #2836 (confirmed): [package web search] 'any' isn't listed in the architectures listhttps://labs.parabola.nu/issues/28362020-07-13T00:41:55ZMegver83megver83@parabola.nu
<p>Just noticed that 'any' is not in <a class="external" href="https://www.parabola.nu/packages/">https://www.parabola.nu/packages/</a> any longer. Now, 'any' packages are shown as if they where available for the other three listed architectures (x86_64, i686 and armv7h)</p> Servers - Bug #1949 (in progress): [makepkg]: syntax errorhttps://labs.parabola.nu/issues/19492018-08-13T12:01:05Zbill-auger
<p>while updating blacklist.git there is a syntax error that was hit several times</p>
<pre>
remote: /usr/share/makepkg/util/pkgbuild.sh: eval: line 90: unexpected EOF while looking for matching `)'
remote: /usr/share/makepkg/util/pkgbuild.sh: eval: line 91: syntax error: unexpected end of file
</pre>
<p>UPDATE 2019-11-15:<br />the original error is fixed - now there is a new error<br /><pre>
remote: | /usr/share/makepkg/util/pkgbuild.sh: line 92: blacklist-7091865c91f06d7b38fd6dfbeb2c1
remote: 51c.txt: No such file or directory
</pre></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> Servers - Bug #105 (open): [wiki,labs] JavaScript not labeled as freehttps://labs.parabola.nu/issues/1052012-05-15T15:53:56Zkete
<p>Nontrivial JavaScript should have a free license, so we can know what our browsers are doing. With libre licenses, we can study the JavaScript source code. The wiki and this lab could use a simple license declaration in the header as described at <a class="external" href="http://www.gnu.org/philosophy/javascript-trap.html#AppendixA">http://www.gnu.org/philosophy/javascript-trap.html#AppendixA</a><br />If the web dev already has a dynamic header that's created from one file, then they could simply add this declaration to that file to cover both sites in whole.</p>
<p>Regards</p>