|
Software Development | chroot-nspawn | Bug Report | Medium | Medium | [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://git.hyperbola.info:51100/~git/software/chroot-nspawn.git
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'ssh://git.hyperbola.info:51100/~git/software/chroot-nspawn.git'
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
|
|
Packages | Stable | Bug Report | Very Low | Very Low | [fail2ban] update dovecot failregex to support verbose ... | Unconfirmed | |
Task Description
Description: The /etc/fail2ban/filter.d/dovecot.conf file has a failregex with the following:
^%(__prefix_line)s(?:auth|auth-worker\(\d+\)): (?:pam|passwd-file)\(\S+,<HOST>\): unknown user\s*$
and works with things like:
Month day time hostname dovecot: auth: passwd-file(user@domain.com,IP): unknown user
but with verbosity enabled in Dovecot, this output looks like this:
Month day time hostname dovecot: auth: passwd-file(user@domain.com,IP): unknown user (given password: password)
and in this case it doesn’t work, but it does if we fix the failregex if we replace it with:
^%(__prefix_line)s(?:auth|auth-worker\(\d+\)): (?:pam|passwd-file)\(\S+,<HOST>\): unknown user( \(given password: \S*\))?\s*$
with this new expression, it works with and without verbosity
And regarding postfix, to make it work correctly I “backported” some pieces from newest failregex:
/etc/fail2ban/postfixr-rbl.conf:
^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[<HOST>\]: [45]54 [45]\.7\.1 Service unavailable; Client host \[\S+\] blocked using .* from=<\S*> to=<\S+> proto=ESMTP helo=<\S*>$
/etc/fail2ban/postfix.conf: (second failregex)
^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[<HOST>\]: 45[04] 4\.7\.1 Client host rejected: cannot find your (reverse )?hostname, (\[\S*\]); from=<\S*> to=<\S+> proto=ESMTP helo=<\S*>$
I can create a patch if you want. Note that I haven’t tested all filters, some others may also need some rework
Additional info: * fail2ban-0.9.6-2.hyperbola3
|
|
Packages | Stable | Bug Report | Very Low | Very Low | [spamassassin] has different directory permissions than... | Deferred | |
Task Description
Description: The /usr/sbin directory in spamassassin has permissions 755 https://git.hyperbola.info:50100/packages/extra.git/tree/spamassassin/PKGBUILD#n88
And ‘filesystem’ sets it to 750 https://git.hyperbola.info:50100/packages/core.git/tree/filesystem/PKGBUILD#n135
So when installing spamassassin, pacman throws a warning
warning: directory permissions differ on /usr/sbin/
filesystem: 750 package: 755
Additional info: * spamassassin 3.4.2-1.hyperbola2
|
|
Packages | Stable | Bug Report | Very Low | Very Low | [postfix] has different directory permissions than 'fil... | Deferred | |
Task Description
Description: The /usr/sbin directory in postfix has permissions 755 https://git.hyperbola.info:50100/packages/extra.git/tree/postfix/PKGBUILD#n115
And ‘filesystem’ sets it to 750 https://git.hyperbola.info:50100/packages/core.git/tree/filesystem/PKGBUILD#n135
So when installing postfix, pacman throws a warning
warning: directory permissions differ on /usr/sbin/
filesystem: 750 package: 755
Additional info: * postfix-3.2.2-1.hyperbola6
|
|
Packages | Any | Update Request | Medium | High | Make Knock patch for Linux-libre 4.14 LTS | Closed | |
Task Description
The Knock patches for linux-libre maintained by you at https://git.hyperbola.info:50100/kernels/knock.git/ 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. https://github.com/copperhead/linux-hardened/releases
|
|
Packages | Stable | Bug Report | Very Low | Medium | [sshguard] violates Hyperbola packaging standards | Closed | |
Task Description
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"
BLACKLIST_FILE=120:/var/db/sshguard/blacklist.db
BACKEND="/usr/lib/sshguard/sshg-fw-iptables"
(commenting the first line temporally solves the issue)
|
|
Packages | Stable | Bug Report | Very Low | Medium | [fail2ban] uses old /usr/bin/sendmail location when it ... | Closed | |
Task Description
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 → https://git.hyperbola.info:50100/packages/community.git/tree/fail2ban/PKGBUILD#n79
Additional info: * fail2ban-0.9.6-2.hyperbola3
|
|
Packages | Any | Implementation Request | Very Low | Medium | [SPF][postfix] implement pypolicyd-spf and postfix-poli ... | Closed | |
Task Description
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:
pkgname=postfix-policyd-spf-perl
pkgver=2.011
pkgrel=1
pkgdesc='Postfix SPF policy engine, written in Perl'
arch=(i686 x86_64)
url='https://launchpad.net/postfix-policyd-spf-perl/'
license=(GPL)
depends=(perl-mail-spf perl-netaddr-ip perl-sys-hostname-long)
source=("https://launchpad.net/postfix-policyd-spf-perl/trunk/${pkgver}/+download/${pkgname}-${pkgver}.tar.gz"{,.asc})
sha512sums=('22fc00bf74912056a67e937a460ac1fd878f1cb1a3bfa7b19bc5f1e6bc1c36d815dcf8c945e818d242ed5e72a6295bb0e1569446e06b09aefb2842993b8016ba'
'SKIP')
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.
|
|
Packages | Any | Freedom Issue | Very High | Critical | [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.
[0] https://git.archlinux.org/svntogit/community.git/plain/aarch64-linux-gnu-linux-api-headers/trunk/PKGBUILD
[1] https://git.parabola.nu/abslibre.git/commit/?id=acaa4ba9c0bc77deb6b77e4dad815f66c673d662
|
|
Packages | Stable | Bug Report | High | Critical | [postfix][FHS] multiple issues, need rebuilding | Closed | |
Task Description
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
|
|
Packages | Stable | Bug Report | Very Low | Medium | [postgrey] has systemd service and no OpenRC init scrip ... | Closed | |
Task Description
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
|
|
Packages | Any | Privacy Issue | Very Low | Low | [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.
|
|
Packages | Any | Bug Report | Very High | Critical | [python-acme] to start crashing on June 19th | Closed | |
Task Description
Description: Quoted from https://bugs.launchpad.net/ubuntu/+source/python-acme/+bug/1777205 Bug #1777205 reported by Brad Warren on 2018-06-16
[Impact]
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 https://community.letsencrypt.org/t/acmev2-order-ready-status/62866
[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 https://community.letsencrypt.org/t/acmev2-order-ready-status/62866 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 https://github.com/certbot/certbot/commit/5940ee92ab5c9a9f05f7067974f6e15c9fa3205a 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/json_util.py", line 280, in fields_from_json
fields[slot] = field.decode(value)
File "/usr/lib/python3.6/site-packages/josepy/json_util.py", line 88, in decode
return self.fdec(value)
File "/usr/lib/python3.6/site-packages/acme/messages.py", 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.
|
|
Packages | Stable | Update Request | Low | High | [pigeonhole] needs to be updated (depends on older vers ... | Closed | |
Task Description
Description: The pigeonhole package depends on dovecot 2.2.29.1, which is in version 2.3.4.1-2.hyperbola1.backports1 at the moment. Due to this, I can’t use it
Additional info: * pigeonhole 0.4.18-1
|
|
Packages | Stable | Bug Report | Very Low | High | [apache][module] mod_wsgi returns "undefined symbol: Py ... | Closed | |
Task Description
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/mod_wsgi.so into server: /etc/httpd/modules/mod_wsgi.so: undefined symbol: PyObject_SetItem
* ERROR: httpd failed to stop
Additional info: * mod_wsgi-4.4.22-1.hyperbola1
|
|
Packages | Any | Freedom Issue | Very High | Critical | [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.
[0] https://git.archlinux.org/svntogit/community.git/plain/aarch64-linux-gnu-linux-api-headers/trunk/PKGBUILD
[1]https://git.parabola.nu/abslibre.git/commit/?id=acaa4ba9c0bc77deb6b77e4dad815f66c673d662
|
|
Packages | Any | Replace Request | Very High | Critical | [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:
linux-libre-lts-firmware
---
/usr/lib/firmware/av7110/bootcode.bin
/usr/lib/firmware/dsp56k/bootstrap.bin
/usr/lib/firmware/keyspan_pda/keyspan_pda.fw
/usr/lib/firmware/keyspan_pda/xircom_pgs.fw
ath9k-htc-firmware
---
/usr/lib/firmware/htc_7010.fw
/usr/lib/firmware/htc_9271.fw
openfwwf
---
/usr/lib/firmware/b43-open/b0g0bsinitvals5.fw
/usr/lib/firmware/b43-open/b0g0initvals5.fw
/usr/lib/firmware/b43-open/ucode5.fw
And here are the firmware files of the new linux-libre-firmware:
linux-libre-firmware
---
/usr/lib/firmware/av7110/bootcode.bin
/usr/lib/firmware/b43-open/b0g0bsinitvals5.fw
/usr/lib/firmware/b43-open/b0g0initvals5.fw
/usr/lib/firmware/b43-open/ucode5.fw
/usr/lib/firmware/carl9170-1.fw
/usr/lib/firmware/cis/3CCFEM556.cis
/usr/lib/firmware/cis/3CXEM556.cis
/usr/lib/firmware/cis/COMpad2.cis
/usr/lib/firmware/cis/COMpad4.cis
/usr/lib/firmware/cis/DP83903.cis
/usr/lib/firmware/cis/LA-PCM.cis
/usr/lib/firmware/cis/MT5634ZLX.cis
/usr/lib/firmware/cis/NE2K.cis
/usr/lib/firmware/cis/PCMLM28.cis
/usr/lib/firmware/cis/PE-200.cis
/usr/lib/firmware/cis/PE520.cis
/usr/lib/firmware/cis/RS-COM-2P.cis
/usr/lib/firmware/cis/SW_555_SER.cis
/usr/lib/firmware/cis/SW_7xx_SER.cis
/usr/lib/firmware/cis/SW_8xx_SER.cis
/usr/lib/firmware/cis/tamarack.cis
/usr/lib/firmware/dsp56k/bootstrap.bin
/usr/lib/firmware/htc_7010.fw
/usr/lib/firmware/htc_9271.fw
/usr/lib/firmware/isci/isci_firmware.bin
/usr/lib/firmware/keyspan_pda/keyspan_pda.fw
/usr/lib/firmware/keyspan_pda/xircom_pgs.fw
/usr/lib/firmware/usbdux_firmware.bin
/usr/lib/firmware/usbduxfast_firmware.bin
/usr/lib/firmware/usbduxsigma_firmware.bin
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:
Sources:
[0] https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.14-Migrates-Out-FW [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b38923a068c10fc36ca8f596d650d095ce390b85 [2] https://jxself.org/firmware/ [3] https://jxself.org/git/?p=linux-libre-firmware.git [4] https://git.parabola.nu/abslibre.git/tree/libre/linux-libre-firmware [5] https://git.parabola.nu/abslibre.git/tree/libre
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.
|
|
Packages | Any | Update Request | Very High | Critical | [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.
[0] https://community.letsencrypt.org/t/certbot-0-22-0-release-with-acmev2-and-wildcard-support/55061 [1] https://packages.debian.org/search?keywords=certbot
|
|
Packages | Stable | Bug Report | Medium | Critical | [apache][modules][FHS] move external modules to new loc ... | Closed | |
Task Description
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:
|
|
Packages | Stable | Bug Report | Medium | Critical | [roundcubemail-lts] not compatible with PHP 7.1 | Closed | |
Task Description
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
|
|
Packages | Any | Drop Request | High | High | [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)
|
|
Packages | Any | Feature Request | Very Low | High | [opendmarc] needs OpenRC init script and contains syste ... | Closed | |
Task Description
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
|
|
Services | PunBB Issue | Feature Request | Very Low | Medium | 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.
|
|
Packages | Any | Privacy Issue | Very Low | Medium | [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: https://api.luadns.com/signup
Currently we are supporting the following Git hosting services: > GitHub > Bitbucket
GitHub, as everybody knows, was acquired by Microsoft last year (2018) https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/
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.
|
|
Installation | Firrmware | Implementation Request | Very Low | Medium | [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:
install ovmf package
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
|
|
Packages | Stable | Bug Report | Very Low | Medium | [fail2ban] remove systemd integration | Closed | |
|
|
Services | Wiki Page Issue | Implementation Request | Very Low | Low | Add how-to about deblob kernel patches | Closed | |
|
|
Packages | Any | Feature Request | Very Low | Low | [opendkim] needs OpenRC init script and contains system ... | Closed | |
|
|
Packages | Any | Feature Request | Defer | Low | [php-imagick] add package | Closed | |
|