All Projects

ProjectCategoryTask TypePrioritySeveritySummaryStatusProgress
PackagesAnyFreedom IssueVery HighCritical  [aarch64-linux-gnu-linux-api-headers] compiles using b ...Closed
Task Description

The aarch64-linux-gnu-linux-api-headers from [community] is compiled using the blobbed Linux kernel sources[0], and in Parabola it has been replaced with aarch64-linux-gnu-linux-libre-api-headers[1].
This issue is exactly the same as linux-api-headers, so it should be blacklisted and replaced using the Linux-libre source.



PackagesAnyFreedom IssueVery HighCritical  [aarch64-linux-gnu-linux-api-headers] compiles using b ...Closed
Task Description

The aarch64-linux-gnu-linux-api-headers package from [community] compiles using the blobbed Linux kernel source[0], at Parabola it has been replaced with aarch64-linux-gnu-linux-libre-api-headers[1], since this issue is exactly the same as with linux-api-headers.

The solution is to simply compile using Linux-libre sources.



PackagesAnyReplace RequestVery HighCritical [kernel-firmware] split out firmware projects from linu ...Closed
Task Description

Since Linux 4.14, the in-tree kernel firmware was dropped[0][1], and Hyperbola uses linux-libre-lts-firmware from 4.9 which still supports that firmware.

However, I’d like to request upgrading to the new libre replacement of linux-firmware.git: linux-libre-firmware[2][3].

This version has no LTS releases (well, firmwares commonly don’t have LTS versions and the in-tree firmware was always the same in post-4.9 generations), but it has the same firmwares as Linux-libre-lts plus some others.

This is the list of firmware files in linux-libre-lts-firmware and its dependencies:


And here are the firmware files of the new linux-libre-firmware:


It has openfwwf and ath9k-htc-firmware included, plus some others. If actual versions of Hyperbola don’t get the update at least consider it for future releases. You can get the new PKGBUILD[4] and its new build dependencies at Parabola’s abslibre.git libre tree[5]

The new dependencies are:

  • sh-elf-gcc (which depends on sh-elf-binutils)
  • sh-elf-newlib
  • arm-linux-gnueabi-gcc (which depends on arm-linux-gnueabi-binutils)
  • xtensa-unknown-elf-gcc (already at Hyperbola)



Updated Note:

Since Linux-libre-firmware contains a lot of independent firmware, tools and assembly projects, it should be built from its official tarball separately and create a group called kernel-firmware to follow the our packaging guidelines. Tools and assembly projects shouldn’t be included in kernel-firmware since those ones are firmware dependencies.

PackagesAnyUpdate RequestVery HighCritical [certbot] update package to support ACMEv2 and Wildcard Closed
Task Description

Since certbot v0.22.0[0] there’s support for ACMEv2 and Wildcard. This is an important update since wildcard SSL certificates can make server security and maintaince easier by supporting all subdomains of a base domain.

Debian Stretch (stable) uses certbot 0.10.2 but there’s 0.23.0 in stretch-backports repository[1]. So I’d like to request an update or a backport of certbot and its dependencies.

These are the actual packages versions from Hyperbola and Arch:

  • certbot (0.23.0-1) / Hyperbola version ⇒ (0.14.0-1) [x]
  • python-acme (0.23.0-1) / Hyperbola version ⇒ (0.14.0-1) [x]
  • python-configargparse (0.12.0-1) / Hyperbola version ⇒ (0.11.0-2) [=]
  • python-parsedatetime (2.4-1) / Hyperbola version ⇒ (2.3-1) [x]
  • python-pbr (4.0.2-1) / Hyperbola version ⇒ (3.0.0-1) [<]
  • python-pytz (2018.4-1) / Hyperbola version ⇒ (2017.2-1) [<]
  • python-zope-component (4.4.1-1) / Hyperbola version ⇒ (4.3.0-2) [=]
  • python-zope-event (4.3.0-1) / Hyperbola version ⇒ (4.2.0-2) [=]

NOTE: packages marked with an “[x]” means that the pkg has Debian Stretch backports of the proposed updated version. The “[=]” means that Debian has no backports but uses the same version of the pkg as Hyperbola. The [<] means the Debian Version lower than Hyperbola’s Version.

The packages that may get the update should be only the ones marked with an [x], if we follow the Debian Stretch devel. If certbot gets the update, then the following Arch packages need to be added for obtaining wildcard certificates throught the DNS challenge:

  • certbot-dns-cloudflare
  • certbot-dns-cloudxns
  • certbot-dns-digitalocean
  • certbot-dns-dnsimple
  • certbot-dns-dnsmadeeasy
  • certbot-dns-luadns
  • certbot-dns-nsone
  • certbot-dns-rfc2136
  • certbot-dns-route53

I ommited certbot-dns-google since it’s not compatible with the Hyperbola Packaging Guidelines.


PackagesAnyBug ReportVery HighCritical [python-acme] to start crashing on June 19th  Closed
Task Description

Quoted from Bug #1777205 reported by Brad Warren on 2018-06-16


Without this fix, on June 19, the library will start to fail when using Let’s Encrypt’s new ACMEv2 endpoint. We should avoid breaking this for users.

[Test Case]

On June 19, try to use Let’s Encrypt’s new ACMEv2 endpoint; it will error out, as described in

[Regression Potential]

If the endpoint changes again, this will need another update, but the only potential regression I see is server-side, which needs patches on our end to adjust (like in this case).

[Original Bug Description]

I am the upstream maintainer of python-acme. This bug only affects python-acme in Ubuntu 18.04.

Starting on June 19th, this library will start failing when used with Let’s Encrypt’s new ACMEv2 endpoint. This is because the library does not recognize the changes described in and will error out when it sees them.

To fix this, python-acme either needs to be upgraded to 0.25.1 (which came out two days ago) or the one line patch that originally landed upstream at applied. I think the latter is the safer option.

Please let me know what I can do to help get this resolved.

Additional info:
Solution is to upgrade the following packages

* certbot 0.23.0-1.hyperbola1.backports1
* python-acme 0.23.0-1.backports1

and any other that depends on certbot=0.23.0 and/or python-acme=0.23.0 (like the certbot plugins)

The other option is to patch certbot, as described in the launchpad’s issue

Steps to reproduce:

1) Install certbot
2) try anything related to the certificates (certonly, renew)
3) You may get an error like this:

Obtaining a new certificate
An unexpected error occurred:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/josepy/", line 280, in fields_from_json
    fields[slot] = field.decode(value)
  File "/usr/lib/python3.6/site-packages/josepy/", line 88, in decode
    return self.fdec(value)
  File "/usr/lib/python3.6/site-packages/acme/", line 123, in from_json
    '{0} not recognized'.format(cls.__name__))
josepy.errors.DeserializationError: Deserialization error: Status not recognized

During handling of the above exception, another exception occurred:

josepy.errors.DeserializationError: Deserialization error: Could not decode 'status' ('ready'): Deserialization error: Status not recognized
Please see the logfiles in /var/log/letsencrypt for more details.
PackagesAnyDrop RequestHighHigh [ssmtp] remove obsolete package Closed
Task Description

Package ssmtp is unmaintained:

ssmtp is unmaintained. Consider using something like msmtp instead. (source)

So it violates point 4 of our packaging guidelines “Anti-abandonware”, because it’s abandoned and has a replacement (msmtp)

PackagesAnyUpdate RequestMediumHighMake Knock patch for Linux-libre 4.14 LTSUnconfirmed
Task Description

The Knock patches for linux-libre maintained by you at have support up to linux-libre 4.13 only (and I think it didn’t work for it when I tried it, compilation failed) but from all of those supported versions, the newest maintained generation by the upstream is 4.9.x

However, since newer kernel generations might require reprogramming the patch, I want to request it only for the latest LTS generation which is 4.14. As you know, LTS software are supported for a long time, so it’s worth to make it for linux-libre 4.14.x

This might not be really important for Hyperbola in the short term, but you are the maintainers of the TCP Stealth implementation for Linux-libre and I and maybe other people would like to use it in their projects for newer versions.

Plus, it would be great since while 4.9 kernels can use the GRSec+Knock combination like linux-libre-lts-unofficial-grsec-knock, with support for 4.14 anyone would be able to use a combination of newer patches such as Linux-hardened+Knock (Linux-hardened supports 4.14 and 4.15 as of now) which is what I’d like to do.

PackagesAnyFeature RequestVery LowHigh[opendmarc] needs OpenRC init script and contains syste...Unconfirmed
Task Description


* needs OpenRC init script and contains systemd files

Additional info:
* 1.3.2-1

 $ pkgfile -l opendmarc | grep systemd
 community/opendmarc     /usr/lib/systemd/
 community/opendmarc     /usr/lib/systemd/system/
 community/opendmarc     /usr/lib/systemd/system/opendmarc.service

Steps to reproduce:

* none

ServicesPunBB IssueFeature RequestVery LowMedium Add a "General Moderation" subforum Closed
Task Description

There are moderation forums for specific languages, but there’s no subforum which involves all of them. I was thinking of a “Moderation discussion” or “General Moderation”, so we are not too specific if a moderator wants to discuss sth. that involves all languages.

PackagesAnyPrivacy IssueVery LowMedium [certbot-dns-luadns] LuaDNS service depends in non-free ...Closed
Task Description

According to their documentation:

In order to use LuaDNS service you’ll need a LuaDNS account and a Git repository.
Sign up for a free LuaDNS account here:
Currently we are supporting the following Git hosting services:
> GitHub
> Bitbucket

GitHub, as everybody knows, was acquired by Microsoft last year (2018)

And Bitbucket, like GitHub, is a centralized non-free git service.

There are other packages made for GitHub which haven’t been removed, but as you were deleting the certbot-dns-* packages that depended on a US-based DNS provider company, I thought you may wanted to know this.

InstallationFirrmwareImplementation RequestVery LowMedium [ISO][UEFI] Replace Syslinux with rEFInd Closed
Task Description

Actual v0.2 ISOs use Syslinux UEFI Boot Manager for supporting EFI systems. However, I wanted to request its replacement by rEFInd, which is much, much better.

Here is why Syslinux should not be used, at least for more advanced tasks than just booting the OS:

  • UEFI Syslinux application syslinux.efi cannot be signed by sbsign (from sbsigntools) for UEFI Secure Boot. Bug report: [3]
  • Using TAB to edit kernel parameters in UEFI Syslinux menu might lead to garbaged display (text on top of one another). Bug report: [4]
  • UEFI Syslinux does not support chainloading other EFI applications like UEFI Shell or Memtest86+. Enhancement request: [5]
  • In some cases, UEFI Syslinux might not boot in some Virtual Machines like QEMU/OVMF or VirtualBox or some VMware products/versions and in some UEFI emulation environments like DUET. A Syslinux contributor has confirmed no such issues present on VMware Workstation 10.0.2 and Syslinux-6.02 or later. Bug reports: [6], [7] and [8]
  • Memdisk is not available for UEFI. Enhancement request: [9]

The citations are from the ArchWiki, check it out for more info.

From all of those points, I have confirmed the 3rd and 4th ones. These are a PITA, because EFI Shell is super useful (Parabola and Arch has it in its ISOs) and not being able to test it in VMs make it harded for ISO testers since they’ve to take more time on writing the image to the USB... etc.

rEFInd doesn’t have these issues, plus, it can be easily testes with QEMU. Try this:

  1. install ovmf package
  2. run the following, and specify the latest Milky Way ISO:
/bin/qemu-system-x86_64 -soundhw ac97 \
      -k es -machine accel=kvm -m 1024 \
      -boot once=d,menu=off -net nic -net user -rtc base=localtime \
      -bios /usr/share/ovmf/x64/OVMF_CODE.fd -cdrom /path/to/file.iso

You will see errors in the CLI. Now, try with my customized ISO (dir with ISO file, sign [key: 6DB9C4B4F0D8C0DC432CF6E4227CA7C556B2BA78], and sha512 checksum), the same steps as above. You’ll see that it successfully boots, and has UEFI Shell apps.

Here is my hyperiso fork. Take a look at the refind/* branches. The refind/with-uefi-shell has EFI Shell from Tianocore EDK2 latest stable tag, and refind/without-uefi-shell, well, doesn’t have it. Note that the binary files from refind/with-uefi-shell are downloaded from upstream and they’re sha512 checksumed. If for any reason you cannot do that way, there’s the other branch as an alternative.

P.S.: I see that actual configs have configured syslinux.efi to show other boot menus rather than the “Boot Hyperbola” option, but I tested it in my PC with UEFI enabled and it just showed the mentioned option

ServicesWiki Page IssueImplementation RequestVery LowLow Add how-to about deblob kernel patches Closed
Task Description

Add a wiki page explaining how to deblob kernel patches.

PackagesAnyPrivacy IssueVery LowLow[github] check github-related packagesResearching
Task Description

We should check if the following packages run any non-free JS (like youtube-dl) or access a proprietary API:

- hub
- python-pygithub
- python2-pygithub

I haven’t check them, but they look fishy. Take it as a reminder, this is far from being urgent IMO.

PackagesAnyFeature RequestVery LowLow[opendkim] needs OpenRC init script and contains system...Unconfirmed
Task Description


* needs OpenRC init script and contains systemd files

Additional info:
* 2.10.3-4

 $ pkgfile -l opendkim | grep systemd
 community/opendkim      /usr/lib/systemd/
 community/opendkim      /usr/lib/systemd/system/
 community/opendkim      /usr/lib/systemd/system/opendkim.service

Steps to reproduce:

* none

Showing tasks 1 - 14 of 14 Page 1 of 1

Available keyboard shortcuts


Task Details

Task Editing