- Arch-dev-public - lists.archlinux.org

[arch-dev-public] Dropping pangox-compat
by Jan de Groot 28 Apr '20

28 Apr '20

Hello, I would like to drop pangox-compat. Reasons: 1. it does not compile with pango 1.44 2. the current compiled package links fine, but does not render any text when used with pango 1.44 3. upstream has archived the source and doesn't support it anymore 4. People care about 1. but not about 2. -> library only exists because software links to it So far we have only a few packages depending on it: - gtkglext (direct dependency, gdk_gl_font_use_pango_font* functions, removed in git master) - gtkmathview (direct dependency, libraries linking to it not used by abiword) - gambas3-gb-gtk-opengl (pulled in through gtkglext, no further relations) Todo: - patch gtkglext to remove API depending on pangox-compat, already packaged, not uploaded yet - drop gtkmathview parts that depend on pangox-compat (Abiword needs the libxml2 module, nothing else) - rebuild gambas3 (is in staging for ICU rebuild now) Any objections?

2 1

[arch-dev-public] moving dhcpcd to [extra]?
by Antonio Rojas 22 Apr '20

22 Apr '20

Is there any reason to keep dhcpcd in [core]? It's only an optional dependency of netctl in [core], it currently lacks an active maintainer, it doesn't seem to be much used (given the slow pace of signoffs), and there's already a basic dhcp tool in [core] (networkd). Any objections to move it to [extra]?

4 3

[arch-dev-public] qemu-arch-extra, ovmf, edk2
by David Runge 20 Apr '20

20 Apr '20

Hi all, Over the weekend I worked on getting archiso into a more reproducible state by building edk2's UEFI Shell from scratch so we can include it into the iso instead of downloading it. I realized, that the current ovmf [1] package basically uses the same toolchain (edk2), so I created a split package for them [2]. When looking at the included qemu firmware configuration files [3], I wondered why these are there and tried to get around using them by placing symlinks into the qemu directory (/usr/share/qemu) as qemu already provides configuratino files for edk2 based ovmf pointing at its own data directory. Only afterwards I realized, that the files mentioned in the qemu firmware configuration files (/usr/share/firmware/*.json) actually target the firmware blobs packaged with qemu-arch-extra (after Anatol was trying out the package and ran into file conflicts :-/). Long story short: While a separate package (e.g. edk2-ovmf) gives us more flexibility over **how** to create those firmwares, allows for signing of secure boot firmwares in the future, staying on top of edk2 releases and allows other applications that are unaware of those files below /usr/share/qemu to use them (some, such as lxd seem to default to /usr/share/OVMF for historical reasons), it is unclear to me whether qemu configuration files should or need to be still created for it (similar to the ones found in the current ovmf package). Any insights would be much appreciated! Best, David [1] https://www.archlinux.org/packages/extra/any/ovmf/ [2] https://www.archlinux.org/packages/testing/any/edk2/ [3] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/ovmf -- https://sleepmap.de

1 0

[arch-dev-public] Packages spring cleanup!
by Jelle van der Waa 20 Apr '20

20 Apr '20

Hi all, I'm going to disown some packages as I no longer actively use them and I want to shift focus into my on other Arch roles: ettercap openttd-opensfx openttd-opengfx rdesktop tesseract tesseract-* tidy unshield vim-pastie vim-align pstreams pdf2djvu bonnie++ gsmartcontrol leptonica jbigkit pbpst ccd2iso chromium-bsu fsarchiver dot2tex If packages need to be moved to [community] for you to be able to adopt them, please say so. Greetings, Jelle

4 3

Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
by Morten Linderud 20 Apr '20

20 Apr '20

On Mon, Apr 20, 2020 at 09:05:27AM +0300, Christoph Gysin wrote: > On Mon, Apr 20, 2020 at 1:32 AM Morten Linderud via arch-dev-public < > arch-dev-public(a)archlinux.org> wrote: > > > https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines > > > > In the fist example, you set both: > > CGO_LDFLAGS=$LDFLAGS > > and pass: > > -ldflags "-extldflags ${LDFLAGS}" > > Yet in the example PKGBUILD, only the former? If you read the example: # *or alternatively* you can define some of these flags from the CLI options" > Also, maybe it would be nice to have an example how to add additional > ldflags correctly without overwriting LDFLAGS, e.g. passing: > > -ldflags "-X my.package.Version=$pkgver" The goal of the page is not to teach you how the go compiler works, but I'll consider it. Thanks -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

[arch-dev-public] Yet another missing solink announcement
by Antonio Rojas 13 Apr '20

13 Apr '20

The zn_poly package prior to version 0.9.2-2 was missing a soname link. This has been fixed in 0.9.2-2, so the upgrade will need to overwrite the untracked files created by ldconfig. If you get an error zn_poly: /usr/lib/libzn_poly-0.9.so exists in filesystem when updating, use pacman -Syu --overwrite usr/lib/libzn_poly-0.9.so to perform the upgrade.

1 0

[arch-dev-public] News draft: nss>=3.51.1-1 and lib32-nss>=3.51.1-1 updates require manual intervention
by Jan Alexander Steffens 09 Apr '20

09 Apr '20

The nss and lib32-nss packages prior to version 3.51.1-1 were missing a soname link each. This has been fixed in 3.51.1-1, so the upgrade will need to overwrite the untracked files created by ldconfig. If you get any of these errors nss: /usr/lib/p11-kit-trust.so exists in filesystem lib32-nss: /usr/lib32/p11-kit-trust.so exists in filesystem when updating, use pacman -Syu --overwrite /usr/lib\*/p11-kit-trust.so to perform the upgrade.

2 1

[arch-dev-public] Away on holiday for the next 2 weeks
by Eli Schwartz 06 Apr '20

06 Apr '20

I've been only sporadically available the last few days, as some people may have noticed, and I will be mostly inaccessible until after Passover[1] / the 19th. It's been very hectic here recently, and ugh, it is so frustrating to get ready for a major holiday in the middle of a pandemic. :( We have still done basically no shopping because my brother was sick so we were in quarantine. Fortunately he's feeling a lot better now and everyone else is fine, so we get to be even *busier*. \o/ I don't anticipate much other than routine updates for my packages; feel free to update anything that is needed. There are already a few updates I haven't had time to handle yet. Note to jelle: If/when calibre gets a new release it will probably need a new rapydscript-ng release, if so, ask upstream for one. -- Eli Schwartz Bug Wrangler and Trusted User [1] https://en.wikipedia.org/wiki/Passover

2 1

[arch-dev-public] TexLive 2020 packages
by Rémy Oudompheng 02 Apr '20

02 Apr '20

Hello, TexLive 2020 is frozen upstream and will be officially released in the coming days. Packages have been uploaded to [testing] and [community-testing] (for biber). Please let me know if you encounter issues with these. Regards, Rémy.

1 0

[arch-dev-public] Looking for an Arch ISO maintainer
by Jelle van der Waa 30 Mar '20

30 Mar '20

Hi all, Gerardo has stepped down as Arch ISO maintainer, which makes archiso unmaintained. I've asked Pierres if he was interested in maintaining the project and he is willing to do bug fixes when required but no major maintenance. Which means that we are looking for a new maintainer :-) To be completely honest, I am not sure what maintenance archiso requires but there are a few things I would love to see: - Proper CI / automated testing of the archiso - Reproducible archiso (patches on the mailing list) [1] - Support secure boot [2] - Accessibility improvements (patches available on the mailing list) [3] Please reply if you are interested in becoming an archiso maintainer, so far Alad has shown interested. [1] https://bugs.archlinux.org/task/63683?project=6 [2] https://bugs.archlinux.org/task/53864?project=6 [3] https://bugs.archlinux.org/task/63166?project=6 -- Jelle van der Waa

6 9