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

[arch-dev-public] Mkinitcpio replacement with Dracut
by Giancarlo Razzolini 19 Feb '21

19 Feb '21

Hi All, Recently, Dave announced his intention to step down as mkinitcpio maintainer. I have been handling a few things on it, made some small changes to our mkinitcpio-busybox [0], closed a few old bugs, while also made sure some of the other bug reports are still valid. [1] I have been testing a few patches to mkinitcpio for a while to fix those bugs, but last week Dave and I had a discussion on IRC and we agreed that we could spend better time contributing somewhere else than keeping working with mkinitcpio. Currently mkinitcpio cannot boot from NFS properly, mknitcpio-nfs-utils [2] uses very old code. Even though ipconfig works, it has several drawbacks compared to using more modern tools. Not to mention that we have two use cases for mkinitcpio, which are base and systemd enabled initramfs. Even though we use by default our base enabled initramfs, we have to support systemd related issues and we have to keep developing our systemd hooks. I have been looking into dracut for some time now, I copied some stuff from them on a few of my own scripts and they also have an actual test suite, that we currently can't use on Arch, but I plan to change that. With this in mind, I have packaged dracut for Arch and put it on Extra [3]. I have been using a dracut initramfs for a while now to boot my encrypted partition. Surprisingly, I only had to create a small patch to one of the dm-crypt module scripts [4] In this initial phase I want to ask as many of you to test this as a replacement to mkinitcpio in your setups, as many as possible, and in as many scenarios as possible. We will probably have to keep both packages on our repos for a long time, but once we are confident it's a good fit, we can replace mkinitcpio on our iso and base, so new installs get dracut by default. Please, drop in your comments as well. Regards, Giancarlo Razzolini [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=pac… [1] https://bugs.archlinux.org/index.php?string=mkinitcpio&project=0 [2] https://git.archlinux.org/mkinitcpio-nfs-utils.git/ [3] https://www.archlinux.org/packages/extra/x86_64/dracut/ [4] https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-90crypt-Cha…

4 7

[arch-dev-public] Abandoning all my vim-* plugin packages
by Sven-Hendrik Haase 14 Jul '20

14 Jul '20

I've started using a vim plugin manager and don't use my packages anymore. They need a new home. Please show these packages some love: * vim-a * vim-colorsamplerpack * vim-doxygentoolkit * vim-guicolorscheme * vim-minibufexpl * vim-omnicppcomplete * vim-project * vim-taglist * vim-vcscommand * vim-workspace The packages are pretty low maintenance but I'd prefer if someone who actually uses them maintained them. Anything that's not taken within 2 weeks will be dropped to AUR.

1 1

[arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
by Frederik Schwan 02 Jul '20

02 Jul '20

We received a Feature Request today to remove fontconfig and xorg-mkfontscale dependencies from our font packages according to our own font packaging guidelines [0]. I discussed with Eli on #archlinux-bugs and we think it's a no-brainer but before creating a TODO we'd like to ask for your opinions first. Thank you [0] https://bugs.archlinux.org/task/66012

7 18

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

18 May '20

# Introduction To enable PIE compilation, we have relied on a patched version of the go compiler which has been distributed as `go-pie` since around 2017. However, full RELRO support for go binaries has been a bit back and forth the past years. With some thing working, and other things don't. With the release of Go 1.11 there was support for a general `GOFLAGS` variable that lets us pass flags directly to the compiler. This email details what these flags should be going forward. # Flags Expected environment variables in PKGBUILDs: export CGO_LDFLAGS="$LDFLAGS" export GOFLAGS="-buildmode=pie -trimpath -mod=vendor -modcacherw" Explanation: * `CGO_LDFLAGS` passes the proper `LDFLAGS` to the linker. This should enable full RELRO when used in conjunction with `GOFLAGS`. * `-buildmode=pie` is the proper way to enable PIE and replaces the `go-pie` patch. * `-trimpath` this is to achieve reproducible builds and remove PWD from the binary. * `-modcacherw` modules are downloaded to `$GOPATH/pkg/mod` and by default have the permissions 444 for god knows why. If we want to run `makepkg -c` or `git clean` we won't have the correct permissions. This is probably not a big problem for repository packages, but it's a nice addition so they work as expected. Notice that `-mod=vendor` is also added to `GOFLAGS`. This will make sure we are using the vendored dependencies in the project. If they are not present, please ensure they are downloaded in the `prepare` function: prepare(){ cd $pkgname-$pkgver go mod vendor } If the project is *not* using Go 1.11 modules, missing `go.mod` and/or `go.sum` in the project root, then disable it with `export GO111MODULE=off` and continue with symlink hacks. Some upstreams override these values for strange reasons in their `Makefile` and build systems. You *need* to read over them and ensure this does not happen! # Pacman Clearly we shouldn't have to specify this in every PKGBUILD, so I have been playing with a `pacman` patch that passes all of the variables. However I have been struggling with debug support and figuring out that part of the flags, so nothing have been upstreamed yet. However this is only applicable to around 126 packages, so I guess it's fine? ¯\_(ツ)_/¯ # In conclusion... If there are no objections to the New Way Of Doing Things™, I'll be updating the package guidelines within the next week or two and drop the `go-pie` package containing the patch. For the sake of compatibility, the `go` package will contain a `replaces=('go-pie')`. I also expect people packaging go packages to follow the guidelines! -- Morten Linderud PGP: 9C02FF419FECBE16

6 22

[arch-dev-public] Spring cleaning (moving orphaned packages from [community] to AUR)
by Alexander F Rødseth 01 May '20

01 May '20

Hello, It's time for the semi-yearly package cleanup of [community] packages, as is tradition. I have gathered a list of "unneeded orphans" in [community] (packages that currently has no maintainer, and no other package depends on them) from the excellent list on our web page. TUs and Devs, please adopt, if you're interested: adapta-kde - Adapta theme for KDE Plasma 5 agg - High Quality Rendering Engine for C++ aide - A file integrity checker and intrusion detection program. arch - A modern and remarkable revision control system. arc-kde - Arc theme for KDE Plasma 5 aspell-it - Italian dictionary for aspell aspell-ru - Russian dictionary for aspell bar - A script for showing progress bars. bomberclone - Clone of the game Atomic Bomberman cellwriter - A grid-entry natural handwriting input panel. curseofwar - Fast-paced RTS/Action game with ncurses interface dcfldd - DCFL (DoD Computer Forensics Lab) dd replacement with hashing dumb-a4 - IT, XM, S3M and MOD player library (for Allegro 4) easystroke - Use mouse gestures to initiate commands and hotkeys. eclipse-cpp - Highly extensible IDE for C++ eclipse-java - Highly extensible IDE for Java eclipse-javascript - Highly extensible IDE for JavaScript eclipse-jee - Highly extensible IDE for JEE eclipse-php - Highly extensible IDE for PHP eclipse-rust - Highly extensible IDE for Rust esmtp - An easy SMTP forwarder. gimp-dbp - David's batch processor for the GIMP gimp-plugin-fblur - Makes out of focus with luminosity and depth gimp-plugin-lqr - Plugin for The GIMP providing Liquid Rescale gimp-plugin-wavelet-denoise - Tool to reduce noise in each channel of an image separately gimp-refocus - A sharpen plugin for gimp using FIR Wiener filtering glide - Dependency management and vendoring for Go projects glitz - OpenGL image compositing library gnunet-gtk - A frontend for GNUnet gtk-theme-switch2 - Gtk2 theme switcher gvmd - greenbone-vulnerability-manager gvm-tools - greenbone-vulnerability-manager tools ifuse - A fuse filesystem to access the contents of an iPhone or iPod Touch iverilog - Icarus Verilog compiler and simulation tool javasqlite - Java wrapper including a basic JDBC driver for the SQLite 2/3 database engine matrix-appservice-irc - Node.js IRC bridge for Matrix minbif - An IRC gateway to IM networks that uses libpurple. mod_wsgi - Python WSGI adapter module for Apache monica - Monitor calibration tool mythes-pl - Polish thesaurus ode - High performance library for simulating rigid body dynamics openvas - Vulnerability scanning Daemon pinta - Drawing/editing program modeled after Paint.NET. It's goal is to provide a simplified alternative to GIMP for casual users processing - Programming environment for creating images, animations and interactions projectm-pulseaudio - Music visualizer which uses 3D accelerated iterative image based rendering (pulseaudio) projectm-sdl - Music visualizer which uses 3D accelerated iterative image based rendering (sdl) python2-pyxmpp - Python XMPP and Jabber implementation based on libxml2 python-pyinsane - Python library to access and use image scanners qtspim - New user interface for spim, a MIPS simulator. rdiff-backup - A utility for local/remote mirroring and incremental backups. remacs - Emacs with parts of it written in Rust steghide - Embeds a message in a file by replacing some of the least significant bits surf - A simple web browser based on WebKit/GTK+. tabbed - Simple generic tabbed fronted to xembed aware applications. transset-df - A patched version of X.Org's transset with added functionality. tuxpaint-config - Tux Paint configuration tool uncrustify - A source code beautifier vim-jellybeans - Colorful, dark color scheme, inspired by ir_black and twilight vim-ultisnips - TextMate-style snippets for Vim. wren - Small, fast, class-based concurrent scripting language xautomation - Controls X from the command line and does "visual scraping". xbindkeys - Launch shell commands with your keyboard or your mouse under X zapcc - C++ compiler based on Clang, but significantly faster zeal - An offline API documentation browser I'll wait two weeks before adding them to AUR, running both `db-remove` and `svn rm` on the unmaintained packages. PS. If unmaintained orphans in [core] could be moved to [extra], and unmaintained orphans in [extra] could be moved to [community], that could be a nice "trickle down" effect and would be an appreciated cleanup as well, but that is just my opinion. To quote our newly elected leader, in connection with the previous spring cleaning: > Cleanup is always good > > - Levente Polyak -- Best regards, Alexander F. Rødseth / xyproto

6 6

[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