All Projects

Project Category Task Type Priority Severity Summary Status Progress
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.
PackagesStableBug ReportHighCritical [postfix][FHS] multiple issues, need rebuilding Closed
Task Description

Postfix is a mess, first it failed to start (running ‘postfix start’) with the following:

  postfix: fatal: chdir(/usr/lib/postfix/bin): No such file or directory

Then, to solve this, I symlinked /usr/libexec/postfix to /usr/lib/postfix/bin, because there were the binaries, but then it came with the following:

  # postfix start
  /usr/lib/postfix/bin/postfix-script: line 89: /usr/bin/postconf: No such file or directory
  /usr/lib/postfix/bin/postfix-script: line 90: /usr/bin/postlog: No such file or directory

Because all the post* bins where now in /usr/sbin, so I symlinked them to /usr/bin, and it could finally run, but with many warnings

  # postfix start
  postfix/postfix-script: warning: symlink leaves directory: /usr/lib/postfix/./bin
  postfix/postfix-script: warning: not owned by group postdrop: /usr/bin/postqueue
  postfix/postfix-script: warning: not owned by group postdrop: /usr/bin/postdrop
  postfix/postfix-script: warning: not set-gid or not owner+group+world executable: /usr/bin/postqueue
  postfix/postfix-script: warning: not set-gid or not owner+group+world executable: /usr/bin/postdrop
  postfix/postfix-script: starting the Postfix mail system

Additional info:
* postfix 3.2.2-1.hyperbola6

PackagesStableBug ReportMediumCritical [apache][modules][FHS] move external modules to new loc ...Closed
Task Description

The apache pkg has a symlink in /etc/httpd/modules which points to /usr/lib/httpd/modules, and it’s wrong because modules are now located at /usr/libexec/httpd/modules

Also, packages that have apache modules, like:

  • extra/php-apache
  • community/mod_wsgi
  • community/mod_wsgi2

have them in the old location, so they need to be rebuilt.

Additional info:

  • apache 2.4.38-1.hyperbola2
PackagesStableBug ReportMediumCritical [roundcubemail-lts] not compatible with PHP 7.1 Closed
Task Description

After replacing roundcubemail with roundcubemail-lts, I got the following error:

  PHP Warning:  session_start(): Failed to read session data: user (path: ) in /usr/share/webapps/roundcubemail/program/lib/Roundcube/rcube_session.php on line 117

And going back to the non-lts version solved it

Additional info:
It looks like it is a problem of roundcube-lts not being fully compatible with PHP 7.1, maybe a backport could fix the issue

Steps to reproduce:
1) Install roundcube
2) open it in a web browser
3) Check /var/log/roundcubemail/errors

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 RequestMediumHigh Make Knock patch for Linux-libre 4.14 LTS Closed
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.

PackagesStableUpdate RequestLowHigh [pigeonhole] needs to be updated (depends on older vers ...Closed
Task Description

The pigeonhole package depends on dovecot, which is in version at the moment. Due to this, I can’t use it

Additional info:
* pigeonhole 0.4.18-1

PackagesAnyFeature RequestVery LowHigh [opendmarc] needs OpenRC init script and contains syste ...Closed
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

PackagesStableBug ReportVery LowHigh [apache][module] mod_wsgi returns "undefined symbol: Py ...Closed
Task Description

I updated mod_wsgi, restarted httpd service and got this error:

$ sudo rc-service httpd restart
 * httpd has detected an error in your setup:
httpd: Syntax error on line 183 of /etc/httpd/conf/httpd.conf: Cannot load modules/ into server: /etc/httpd/modules/ undefined symbol: PyObject_SetItem
 * ERROR: httpd failed to stop

Additional info:
* mod_wsgi-4.4.22-1.hyperbola1

Software Developmentchroot-nspawnBug ReportMediumMedium[chroot-nspawn] Create mount points if mountpoint exit ...Unconfirmed
Task Description

The actual behavior is to create mount points if mountpoint exits with exit status 1, however it may also exit with code 32 and thus creating a real mess:

$ sudo chroot-nspawn
Spawning container megver83 on /var/lib/archbuild/chroot1/megver83
Press ^] three times within 1s to kill container.
mount: /sys/fs/cgroup: mount point does not exist.
mkdir: cannot create directory '/sys/fs/cgroup/blkio': No such file or directory
ln: failed to create symbolic link '/sys/fs/cgroup/cpu': No such file or directory
ln: failed to create symbolic link '/sys/fs/cgroup/cpuacct': No such file or directory
mkdir: cannot create directory '/sys/fs/cgroup/cpu,cpuacct': No such file or directory
mkdir: cannot create directory '/sys/fs/cgroup/cpuset': No such file or directory
mkdir: cannot create directory '/sys/fs/cgroup/devices': No such file or directory  
mkdir: cannot create directory '/sys/fs/cgroup/freezer': No such file or directory
mkdir: cannot create directory '/sys/fs/cgroup/memory': No such file or directory
ln: failed to create symbolic link '/sys/fs/cgroup/net_cls': No such file or directory
mkdir: cannot create directory '/sys/fs/cgroup/net_cls,net_prio': No such file or directory
ln: failed to create symbolic link '/sys/fs/cgroup/net_prio': No such file or directory
mkdir: cannot create directory '/sys/fs/cgroup/pids': No such file or directory
mkdir: cannot create directory '/sys/fs/cgroup/systemd': No such file or directory
mount: /sys/fs/cgroup/blkio: mount point does not exist.
mount: /sys/fs/cgroup/cpuset: mount point does not exist.
mount: /sys/fs/cgroup/devices: mount point does not exist.
mount: /sys/fs/cgroup/freezer: mount point does not exist.
mount: /sys/fs/cgroup/memory: mount point does not exist.
mount: /sys/fs/cgroup/pids: mount point does not exist.

So I created a patch to fix this.

P.S.: although I can git clone the repo with ssh access, whenever I do a push I get:

error: remote unpack failed: unable to create temporary object directory
To ssh://
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'ssh://'

Do I have the permission to write in this repo? If not, I’d like it, as I’m planning to improve this great script

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

PackagesStableBug ReportVery LowMedium [sshguard] violates Hyperbola packaging standards Closed
Task Description

The sshguard package should have its /usr/bin/sshguard executable in /usr/sbin, has systemd service files and no OpenRC init script

Additional info:
* sshguard-2.0.0-4
* when I run `sshguard`:

# sshguard
/usr/bin/sshguard: line 87: /usr/bin/journalctl: No such file or directory

* default /etc/sshguard.conf

LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -o cat"

(commenting the first line temporally solves the issue)

PackagesStableBug ReportVery LowMedium [fail2ban] remove systemd integration Closed
Task Description

This package has a strong systemd integration. It has a systemd backend to get files modifications:

(from /etc/fail2ban/jail.conf)

# systemd:   uses systemd python library to access the systemd journal.
#              Specifying "logpath" is not valid for this backend.
#              See "journalmatch" in the jails associated filter config

and many files at /etc/fail2ban/filter.d have systemd stuff

[/etc/fail2ban/filter.d] [0]
$ grep -i systemd *
dovecot.conf:#journalmatch = _SYSTEMD_UNIT=dovecot.service
ejabberd-auth.conf:# Notes.:  systemd journalctl style match filter for journal based backend
postfix.conf:journalmatch = _SYSTEMD_UNIT=postfix.service
postfix-sasl.conf:#journalmatch = _SYSTEMD_UNIT=postfix.service
pure-ftpd.conf:journalmatch = _SYSTEMD_UNIT=pure-ftpd.service + _COMM=pure-ftpd
recidive.conf:journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=5
sshd.conf:journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd
sshd-ddos.conf:journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd

Additional info:
* fail2ban-0.9.6-2.hyperbola3

PackagesStableBug ReportVery LowMedium[fail2ban] uses old /usr/bin/sendmail location when it ...Unconfirmed
Task Description


I saw errors in logs because fail2ban couldn’t find /usr/bin/sendmail, and discovered this:

[/etc/fail2ban] [0]
$ grep /usr/bin/sendmail */*
action.d/sendmail-buffered.conf:              Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-buffered.conf:                 Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-buffered.conf:             Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-buffered.conf:                Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-common.conf:              Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-common.conf:             Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail.conf:            Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-geoip-lines.conf:            Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-whois.conf:            Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-whois-ipjailmatches.conf:            Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-whois-ipmatches.conf:            Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-whois-lines.conf:            Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>
action.d/sendmail-whois-matches.conf:            Fail2Ban" | /usr/bin/sendmail -f <sender> <dest>

Please, also check for other binaries with wrong locations

As of now, the solution is as simple as removing this line →

Additional info:
* fail2ban-0.9.6-2.hyperbola3

PackagesAnyImplementation RequestVery LowMedium[SPF][postfix] implement pypolicyd-spf and postfix-poli...Unconfirmed
Task Description

Hyperbola has the following SPF implementations:
* libspf2
* perl-mail-spf
* perl-mail-spf-query

However, none of them work out of the box with postfix. There’s postfix-policyd-spf-perl, which uses one the current perl implementations (perl-mail-spf), takes no time to build and all the dependencies are already satisfied with Hyperbola’s packages

Here I made a PKGBUILD that’s compliant with the packaging standards:

pkgdesc='Postfix SPF policy engine, written in Perl'
arch=(i686 x86_64)
depends=(perl-mail-spf perl-netaddr-ip perl-sys-hostname-long)
validpgpkeys=(E7729BFFBE85400FEEEE23B178D7DEFB9AD59AF1) # Scott Kitterman

package() {
  cd "${pkgname}-${pkgver}"

  install -Dm755 "${pkgname}" "${pkgdir}/usr/libexec/postfix/${pkgname}"
  install -Dm644 CHANGES INSTALL README -t "${pkgdir}/usr/share/doc/${pkgname}"
  install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"

in the other hand, to give users the possibility of having more options, we could add pypolicyd-spf (AUR), which depends in pyspf (AUR) and other packages that Hyperbola has. In fact, ArchWiki talks about this implementation, but this might not be relevant.

PackagesStableBug ReportVery LowMedium [postgrey] has systemd service and no OpenRC init scrip ...Closed
Task Description

The title says everything

Also, it doesn’t follow the FHS (/usr/bin/postgrey should be in /usr/sbin)

Additional info:
* postgrey-1.37-1

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 packages Closed
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 ...Closed
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

PackagesAnyFeature RequestDeferLow [php-imagick] add package Closed
PackagesStableBug ReportVery LowVery Low[spamassassin] has different directory permissions than...Deferred
PackagesStableBug ReportVery LowVery Low[postfix] has different directory permissions than 'fil...Deferred
PackagesStableBug ReportVery LowVery Low[fail2ban] update dovecot failregex to support verbose ...Unconfirmed
Showing tasks 1 - 29 of 29 Page 1 of 1

Available keyboard shortcuts


Task Details

Task Editing