Parabola Issue Tracker: Issueshttps://labs.parabola.nu/https://labs.parabola.nu/favicon.ico?15367742552019-07-12T21:58:30ZParabola Issue Tracker
Redmine Packages - Bug #2373 (confirmed): i686 [evince] broken libsynctex dependencyhttps://labs.parabola.nu/issues/23732019-07-12T21:58:30Zisacdaavid
<p>evince for i686 is on an older version (3.30.2-1.0), which expects to use libsynctex.so.1. however, current versions of libre/libsynctex only provide libsynctex.so.2.</p>
<p>the program won't even start without libsynctex.so.1</p> Ports - Porting #1591 (open): armv7h kernel unsuitable for QEMUhttps://labs.parabola.nu/issues/15912017-12-21T20:31:41Zisacdaavid
<p>we have been using QEMU for some time to build armv7h packages on x86. however it should also be possible to boot a full armv7h Parabola system using one of the available machines in <a href="https://www.parabola.nu/packages/?name=qemu-arch-extra" class="external">qemu-arch-extra</a>.</p>
<p>one can skip emulation of the bootloader step by telling QEMU to load a kernel directly. for instance, the following works for this <a href="http://ftp.debian.org/debian/dists/wheezy/main/installer-armhf/current/images/vexpress/netboot/" class="external">Debian kernel</a> :</p>
<pre>
qemu-system-arm -machine vexpress-a9 -cpu cortex-a9 \
-serial stdio \
-kernel $KERNEL_IMAGE \
-append "root=/dev/mmcblk0 rw console=ttyAMA0" \
-initrd $INITRAMFS \
</pre>
<p>this is not the case with our kernels. i suspect we might be missing some module or configuration. ALARM is of no help either.</p> libretools - Bug #1234 (fixed): [librechroot] `librechroot -A armv7h make` aborts during `locale-...https://labs.parabola.nu/issues/12342017-03-17T02:54:15Zisacdaavid
<pre>
$ sudo librechroot -A armv7h -n armv7h make
[...]
:: Running post-transaction hooks...
[...]
Generating locales...
en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
/usr/bin/locale-gen: line 41: 27 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale
</pre>
<p>The problem isn't specific to librechroot, I have confirmed it in 2 machines by running <code>locale-gen</code> inside a chroot not made by librechroot. However it prevents everything after <code>locale-gen</code> from occurring, with awful consequences for <code>libremakepkg</code>:</p>
<pre>
$ sudo libremakepkg -n armv7h
[...]
==> Starting to build the package...
| /usr/bin/cp: cannot stat '/repo/repo.db': No such file or directory
| ==> Checking runtime dependencies...
| warning: database file for 'repo' does not exist
| ==> Installing missing dependencies...
| warning: database file for 'repo' does not exist
| error: failed to prepare transaction (could not find database)
| ==> ERROR: 'pacman' failed to install missing dependencies.
==> Copying log and package files out of the chroot...
</pre> Packages - Freedom Issue #1231 (in progress): [electron] embeds Chromium platform (or part of it)...https://labs.parabola.nu/issues/12312017-03-15T05:28:11Zisacdaavid
<p>I want this report to serve as a little more extensive reference for what the blacklist entry will summarize, but also to raise awareness of the Chromium question and its deep consequences.</p>
<p>Electron is a Web-based framework/toolkit for desktop applications, it builds heavily on the Chromium platform to provide everything a Web client is expected to do. Now onto the problems:</p>
<ul>
<li>1. The docs <a href="https://raw.githubusercontent.com/electron/electron/787bc8570382e98c4f204abff05b2af122e5a422/docs/tutorial/using-widevine-cdm-plugin.md" class="external">explain</a> how to install a nonfree DRM module. This could probably be easily addressed in a replacement package in the future.</li>
<li>2.1. Among the plethora of things worth checking that the PKGBUILD is pulling is a full Chromium release, regardless of what subset of modules electron might need...</li>
<li>2.2. ...although unclear Chromium licensing isn't a problem nowadays; concerns remain that Chromium doesn't distribute full source code of third-party code, doesn't build entirely from sources (unless downstream is getting hacky like Debian), and last but not the least: without <a href="https://github.com/gcarq/inox-patchset#patches" class="external">patching</a> Chromium is tantamount to spyware. A clear understanding of what bits of Chromium are used and what they are doing is needed to determine the extent of the infection.</li>
</ul> Packages - Packaging Request #1216 (open): [luv-icon-theme-git] Add package to PCRhttps://labs.parabola.nu/issues/12162017-02-15T01:53:33Zisacdaavid
<p>Submitting on behalf of <a class="external" href="https://lists.parabola.nu/pipermail/assist/2017-February/000801.html">https://lists.parabola.nu/pipermail/assist/2017-February/000801.html</a></p>
<blockquote>
<p>Would anyone be willing to add any of bitsquare (AGPL3), monero (Modified BSD license), and luv-icon-theme-git (CC BY-SA 4.0) to the pcr? The direct links to the AUR are here:<br /><a class="external" href="https://aur.archlinux.org/packages/bitsquare/">https://aur.archlinux.org/packages/bitsquare/</a><br /><a class="external" href="https://aur.archlinux.org/packages/monero/">https://aur.archlinux.org/packages/monero/</a><br /><a class="external" href="https://aur.archlinux.org/packages/luv-icon-theme-git/">https://aur.archlinux.org/packages/luv-icon-theme-git/</a></p>
<p>Thanks for your time.<br />-Christian</p>
</blockquote> Packages - Packaging Request #1215 (open): [monero] Add package to PCRhttps://labs.parabola.nu/issues/12152017-02-15T01:51:46Zisacdaavid
<p>Submitting on behalf of <a class="external" href="https://lists.parabola.nu/pipermail/assist/2017-February/000801.html">https://lists.parabola.nu/pipermail/assist/2017-February/000801.html</a></p>
<blockquote>
<p>Would anyone be willing to add any of bitsquare (AGPL3), monero (Modified BSD license), and luv-icon-theme-git (CC BY-SA 4.0) to the pcr? The direct links to the AUR are here:<br /><a class="external" href="https://aur.archlinux.org/packages/bitsquare/">https://aur.archlinux.org/packages/bitsquare/</a><br /><a class="external" href="https://aur.archlinux.org/packages/monero/">https://aur.archlinux.org/packages/monero/</a><br /><a class="external" href="https://aur.archlinux.org/packages/luv-icon-theme-git/">https://aur.archlinux.org/packages/luv-icon-theme-git/</a></p>
<p>Thanks for your time.<br />-Christian</p>
</blockquote> Packages - Packaging Request #1214 (open): [bitsquare] Add package to PCRhttps://labs.parabola.nu/issues/12142017-02-15T01:48:06Zisacdaavid
<p>Submiting on behalf of <a class="external" href="https://lists.parabola.nu/pipermail/assist/2017-February/000801.html">https://lists.parabola.nu/pipermail/assist/2017-February/000801.html</a></p>
<blockquote>
<p>Would anyone be willing to add any of bitsquare (AGPL3), monero (Modified BSD license), and luv-icon-theme-git (CC BY-SA 4.0) to the pcr? The direct links to the AUR are here:<br /><a class="external" href="https://aur.archlinux.org/packages/bitsquare/">https://aur.archlinux.org/packages/bitsquare/</a><br /><a class="external" href="https://aur.archlinux.org/packages/monero/">https://aur.archlinux.org/packages/monero/</a><br /><a class="external" href="https://aur.archlinux.org/packages/luv-icon-theme-git/">https://aur.archlinux.org/packages/luv-icon-theme-git/</a></p>
<p>Thanks for your time.<br />-Christian</p>
</blockquote> dbscripts - Bug #1178 (fixed): [ARM] db-import-archlinuxarm-pkg misses some packageshttps://labs.parabola.nu/issues/11782017-01-16T21:38:20Zisacdaavid
<p>Given that only [core], [extra], and [community] are imported from Arch ARM, certain packages that they have changed to depend on their [alarm] repository present unmet dependencies. An example of this is <code>ghc 8.0.1-1</code>, which was changed to depend on the custom <code>llvm37</code>:</p>
<p><a class="external" href="https://www.parabola.nu/packages/community/armv7h/ghc/">https://www.parabola.nu/packages/community/armv7h/ghc/</a></p> Packages - Bug #1082 (not-a-bug): [icedove] [gstreamer0.10-bad] download sources at build timehttps://labs.parabola.nu/issues/10822016-08-15T22:06:48Zisacdaavid
<p>I'm using this meta-bug to document packages that fail to build using libremakepkg, unless one specifies the -N flag.</p>
<p>Details could be different from one package to another. For instance, one possibility is that we are inheriting a bad choice of configure flags from Arch, or any other such scenario that would lead the build process to download external libraries, even when it's avoidable. However if that's not the case I suggest bug reports be opened upstream; we could work around it in the meantime in order to meet the Parabola packaging standards.</p>
<ul>
<li>kodi:<br />Attempts to download a copy of ffmpeg from <a class="external" href="https://github.com/xbmc/FFmpeg">https://github.com/xbmc/FFmpeg</a> during build() (<em>See <a class="external" href="https://github.com/xbmc/xbmc/blob/master/tools/depends/target/ffmpeg/autobuild.sh#L114">https://github.com/xbmc/xbmc/blob/master/tools/depends/target/ffmpeg/autobuild.sh#L114</a></em>) and fails with:<br /><pre>
...
| configure: "FFmpeg installation forced by user - installing our version"
| tar: ../ffmpeg-2.8.6-Jarvis-16.0.tar.gz: Cannot open: No such file or directory
| tar: Error is not recoverable: exiting now
| /build/kodi/src/xbmc-16.1-Jarvis/tools/depends/target/ffmpeg/autobuild.sh: line 128: ./configure: No such file or directory
| make: *** No targets specified and no makefile found. Stop.
| ERROR: Building ffmpeg failed
| checking for FFMPEG... no
| configure: error: "ffmpeg not found"
| ==> ERROR: A failure occurred in build().
| Aborting...
</pre></li>
</ul>
<ul>
<li>icedove:<br />Attempts to download a Python package called <code>blessings</code> with pip during build():<br /><pre>
...
| make[4]: Entering directory '/build/icedove/src/thunderbird-45.2.0/obj-x86_64-unknown-linux-gnu/mail/test/mozmill'
| ../../../config/nsinstall -t /build/icedove/src/thunderbird-45.2.0/mail/test/resources ../../../_tests/mozmill
| ../../../config/nsinstall -t /build/icedove/src/thunderbird-45.2.0/mozilla/python/virtualenv ../../../_tests/mozmill/resources/
| rm -rf ../../../_tests/mozmill/../mozmill-virtualenv && \
| mkdir ../../../_tests/mozmill/../mozmill-virtualenv && \
| unset MACOSX_DEPLOYMENT_TARGET && \
| /build/icedove/src/thunderbird-45.2.0/obj-x86_64-unknown-linux-gnu/_virtualenv/bin/python ../../../_tests/mozmill/resources/installmozmill.py \
| ../../../_tests/mozmill/../mozmill-virtualenv /build/icedove/src/thunderbird-45.2.0/mozilla/testing/mozbase
| Using real prefix '/usr'
| New python executable in /build/icedove/src/thunderbird-45.2.0/obj-x86_64-unknown-linux-gnu/_tests/mozmill-virtualenv/bin/python
| Installing setuptools, pip...done.
| Processing /build/icedove/src/thunderbird-45.2.0/mozilla/testing/mozbase/manifestparser
...
| Processing /build/icedove/src/thunderbird-45.2.0/mozilla/testing/mozbase/mozrunner
| Collecting blessings>=1.3 (from mozlog==3.1)
| Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after connection broken by 'ProtocolError('Connection aborted ...
| Could not find any downloads that satisfy the requirement blessings>=1.3 (from mozlog==3.1)
| No distributions at all found for blessings>=1.3 (from mozlog==3.1)
| Python: 2.7.12 (default, Jun 28 2016, 08:31:05)
| [GCC 6.1.1 20160602]
| Failure to install packages
| make[4]: *** [Makefile:30: mozmill-virtualenv] Error 1
| make[4]: Leaving directory '/build/icedove/src/thunderbird-45.2.0/obj-x86_64-unknown-linux-gnu/mail/test/mozmill'
...
| ==> ERROR: A failure occurred in build().
| Aborting...
</pre></li>
</ul>
<ul>
<li>gstreamer0.10-bad:<br />This one goes straight to the issue as soon as build() starts:<br /><pre>
| ==> Starting build()...
| + Setting up common submodule
| Submodule 'common' (git://anongit.freedesktop.org/gstreamer/common) registered for path 'common'
| Cloning into '/build/gstreamer0.10-bad/src/gst-plugins-bad/common'...
| fatal: Unable to look up anongit.freedesktop.org (port 9418) (Name or service not known)
| fatal: clone of 'git://anongit.freedesktop.org/gstreamer/common' into submodule path '/build/gstreamer0.10-bad/src/gst-plugins-bad/common' failed
| There is something wrong with your source tree.
| You are missing common/gst-autogen.sh
| ==> ERROR: A failure occurred in build().
| Aborting...
</pre></li>
</ul> Documentation - Bug #881 (fixed): Add links to the ARM installation and migration guides in the w...https://labs.parabola.nu/issues/8812015-12-03T02:49:59Zisacdaavid
<p>We advertise armv7h support a few occasions here and there but our most important pieces of documentation regarding this architecture are not present in the main wiki page: <a class="external" href="https://wiki.parabola.nu/Parabola_ARM_installation">https://wiki.parabola.nu/Parabola_ARM_installation</a> <a class="external" href="https://wiki.parabola.nu/Migration_from_Arch_Linux_ARM">https://wiki.parabola.nu/Migration_from_Arch_Linux_ARM</a></p>
<p>I argue that both the port and the guides are mature enough to be exposed to the general audience, even though the bootloader situation isn't yet as good as we want. Knowledgeable ARM board owners could easily get Parabola installed on their systems, and quality of these wiki pages could benefit from them.</p>
<p>So someone is needed with edit privileges to make the change.</p> Ports - Porting #852 (fixed): [texlive-bin] won't build on ARM hardware (xindy/clisp memory fault)https://labs.parabola.nu/issues/8522015-11-07T05:34:34Zisacdaavid
<p>xindy is a Tex package which depends on clisp and that we provide in our texlive-bin package. I was able to build texlive-bin unmodified on QEMU-ARM, but in real hardware clisp crashes with a memory fault while trying to compile texlive-bin/src/source/utils/xindy/xindy-2.5.1/src/base.lsp.</p>
<p>I attached a file with the relevant part of the build process.</p>
<p>For reference, Debian had xindy for arm soft-float during wheezy, and now the sid version claims to be available for armv7 hard-float, but there's no xindy package in Debian stable according to this search [[<a class="external" href="https://packages.debian.org/search?keywords=xindy&searchon=names&suite=all&section=all">https://packages.debian.org/search?keywords=xindy&searchon=names&suite=all&section=all</a>]] (and no other package seems to include it).</p>
<p>Other distros don't package xindy at all for ARM (Gentoo, Fedora, Arch ARM). The only mention of this bug I could find comes from a recent attempt to package xindy in Fedora: [[<a class="external" href="https://bugzilla.redhat.com/show_bug.cgi?id=1275438#c4">https://bugzilla.redhat.com/show_bug.cgi?id=1275438#c4</a>]]</p> Packages - Bug #796 (fixed): [sh-roundup] make dependency ronn doesn't exist in reposhttps://labs.parabola.nu/issues/7962015-08-31T18:42:08Zisacdaavid
<p>sh-roundup builds successfully with ruby-ronn installed though. Is the PKGBUILD outdated?</p>