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

[arch-dev-public] Away until May 11
by Christian Hesse 03 May '19

03 May '19

Hello everybody, I am on vacation until May 11. I have my notebook and a lte router with me, but I am not sure what my spare time and quality of internet connectivity will look like. Feel free to touch my packages if required. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 0

[arch-dev-public] Dropping Qt4
by Antonio Rojas 29 Apr '19

29 Apr '19

Hi all, Now that mumble has been ported to Qt5, I think it's time to finally drop Qt4, which has been EOL for 4 years. Most stuff that still depends on it has been dead upstream for many years. Here is a full list of applications (not libraries or plugins, which can be dropped once applications are gone): clementine - Qt5 port exists in git for years but no release - some distros ship a git snapshot, there's also the strawberry Qt5 fork fbreader - There's a patch to port to Qt5 in AUR https://aur.archlinux.org/packages/fbreader-qt5/ freemat - Last released 6 years ago, there seems to be a Qt-free version at https://sourceforge.net/p/freemat/code/HEAD/tree/branches/FreeMat5/ but with no activity for 2 years gebabbel - Last released >10 years ago, gpsbabel already provides a Qt5 UI gnuradio - Qt UI can be disabled until it is ported hydrogen - Qt5 beta version (>1 year old) available keepassx{,2} - We have keepass and keepassxc already launchy - Qt5 fork available at https://github.com/Slesa/launchy/ openssh-askpass - can actually be compiled with Qt5 qmpdclient - Last released 8 years ago, many alternatives available tipp10 - Qt5 fork available at https://gitlab.com/a_a/tipp10/ tuxcards - Last released 9 years ago, many alternatives available v4l2ucp - Last released 9 years ago I propose to move those who can to Qt5 forks, and disable the Qt5 bits (if possible) or completely drop the other ones. Any objections?

4 3

[arch-dev-public] Unmaintained packages from Dan
by Jelle van der Waa 28 Apr '19

28 Apr '19

Hi all, We have some packages which used to be maintained by toofishes which he no longer seems to take care of. So if anyone is willing to maintain these packages, please adopt them, if they need to be moved to [community] for a TU, ping me. The packages are: * munin{,-node} * numactl * irqbalance * cvsps * csope * nilfs-tools (I added myself as co-maintainer but I don't really use it) Also look at the bugtracker for old bugs, munin for example has a bunch

2 1

Re: [arch-dev-public] Spring cleaning (take 2)
by Antonio Rojas 03 Apr '19

03 Apr '19

Following up on xyproto's [community] cleanup, here is a list of unrequired orphans in [extra] which could be removed (minus the aspell/hunspell dicts). Please adopt them if you want to keep them (some of them are clearly maintained, eg. vulkan stuff). If you ∈{TU's}\{devs} and want to maintain something, reply and I will move it to [community]. Will start dropping stuff in a week. alsaplayer artwiz-fonts bluefish bluez-firmware bootchart di enlightenment16 epplet-base fetchmail fonts-tlwg foobillard++ fvwm-crystal fyre geeqie glsof gnome-alsamixer icewm idnkit linux_logo lua-luajson sbsms scim-anthy scim-hangul scim-m17n scim-pinyin scim-tables scim-uim streamripper thinkfinger ttf-arphic-ukai ttf-arphic-uming ttf-baekmuk ttf-cheapskate ttf-freebanglafont ttf-hannom ttf-khmer ttf-mph-2b-damase ttf-sazanami ttf-tibetan-machine ttf-ubraille vulkan-extra-layers vulkan-trace wpa_actiond xbill xfig xmahjongg xsnow

9 11

[arch-dev-public] FroSCon 2019
by Jelle van der Waa 22 Mar '19

22 Mar '19

Hi Archers, This there is another FroSCon 2019 organized! Last year we had a dev room on sunday and two talks, if enough dev/tu/community members want to hold a talk then I can organize a room again :-) [1] https://www.froscon.de/en/cfp/ -- Jelle van der Waa

1 0

[arch-dev-public] Co-maintainers and less time for packaging
by Morten Linderud 21 Mar '19

21 Mar '19

Yo! As some might be aware, I'm finishing up a master thesis that is due 1st of June. Because of this my time is going to be limited closer to the delivery date. To try relieve some stress I'm giving a heads up that the time spent on packaging is going to be strained going forward. Since we have been trying to focus on co-maintainers for each package, I have collected a list of packages where I am the sole maintainer. Feel free to adopt any package on the list :) I can probably share nvchecker setup for most of them. acpid bucklespring containerd delve dep git-lfs go-md2man gopass hexedit hy i3-gaps influxdb jgmenu jp2a minicom mopidy mypy neofetch font-awesome pass-otp pdfjs protege python-argparse python-autobahn python-babel python2-docs python2-functools32 python-hidapi python-jsonrpclib-pelix python-keyutils python-ldap python-m2crypto python-nltk python-pew python-pipenv python-psycopg2 python-pyaes python-pydocstyle python-pyserial python-send2trash python-shutilwhich python-sqlobject python-sqlparse python-xlib python-argparse python-autobahn python-babel python-docs python-hidapi python-jsonrpclib-pelix python-keyutils python-ldap python-m2crypto python-mypy_extensions python-nltk python-pew python-pipenv python-psycopg2 python-pyaes python-pydocstyle python-pypeg2 python-pyserial python-pywal python-send2trash python-shutilwhich python-sqlobject python-sqlparse python-typed-ast python-xlib restic udiskie qutebrowser might need an extra hand as well :) -- Morten Linderud PGP: 9C02FF419FECBE16

8 7

[arch-dev-public] Removing wine-staging-nine, replaced with wine-nine
by Laurent Carlier 21 Mar '19

21 Mar '19

Patches for nine support has not been available anymore since wine 4.1; instead of that a nine standalone version is. Plans is to remove wine-staging-nine from multilib repo and replace it with wine-nine package, which supports both wine and wine-staging packages. -- Laurent Carlier http://www.archlinux.org

1 0

[arch-dev-public] New build server for TUs and devs
by Sven-Hendrik Haase 20 Mar '19

20 Mar '19

Hi all, Thanks to Hetzner sponsoring our new server [0] we now have a new box with 48 threads, 128 GiB RAM, and 2 NVMes in RAID0 with a total of 1.75 TiB of storage. Should be plenty fast for the time being. The new server is now available at dragon.archlinux.org for all of your package building pleasures. All TUs and devs have had all of their keys added. pkgbuild.com will soon be pointed to this new server so keep that in mind in case your SSH tells you the hostname changed. IMPORTANT: No data has been migrated from soyuz. It is your responsibility to transfer any data you might want on dragon. soyuz will stay available for at least a month from now (probably more, don't worry, there will be another mail for its termination), so you have plenty of time to migrate any data. dragon will not host public_html in your home dirs. That will move somewhere else. dragon is very strictly a build box and no other services should run on there. soyuz hasn't been changed in any way and if you really want to keep using that, you can do so until it gets terminated. [0] https://twitter.com/svenstaro/status/1107938411254431744

1 0

[arch-dev-public] Follow-up on the “Proposal: minimal base system”
by Bruno Pagani 18 Mar '19

18 Mar '19

Hi there, This is a follow-up on the last month discussion about a “minimal base system”. # Reminder of the starting statement > There is no strict definition of what a minimal Arch Linux system installation must contain. However in reality we mostly don’t add any packages that are in the base group as a dependency to other packages, which basically makes it a hard requirement. The corollary being that, since we don’t actually enforce `base` as a policy, some breakage might (and does) happen when people remove part of it from their system. Following on that, the discussion was about implementing a metapackage with a stricter set of packages to be required as installed on any Arch system, and whether or not to keep the `base` group in addition. From this discussion and parallel ones that happened on IRC, I can summarize three important questions (that are, notice, actually independent of the exact content of base-whatever): 1. There is a disagreement on the `base` group purpose: should it just be a convenient helper to bootstrap an Arch system quickly and/or also be used as a set of assumed installed dependencies? 2. Are people actually wanting to be able to assume some installed dependencies at all, and if so, what are they argument(s) for not listing some, e.g. `glibc`? I haven’t seen many apart from “don’t want to list tons of dependency in my PKGBUILD” or “no sane system wouldn’t have it”, and we can discuss whether those are valid one or not, but since the discussion wasn’t happening on that point particularly, there may also be some others that have escaped me. 3. Although it could seems not deeply related at first, what about transitive dependencies (e.g. package A depending on B and C, but only listing B because this one already depends on C)? Here again, breakage happens because of this (when B stop depending on C, which A maintainer cannot be reasonably expected to track), and I’ve only heard “don’t want to list tons of dependency in my PKGBUILD”. Before going further on any proposal in those directions, I’ve thought it surely requires more input, and not only from the ~10 people at most that already participated in those discussions (but still should, because points have changed a bit) since we are discussing distro-wide policy on dependencies here. Regards, Bruno

5 9

[arch-dev-public] Proposal: minimal base system
by Levente Polyak 18 Mar '19

18 Mar '19

# Proposal There is no strict definition of what a minimal Arch Linux system installation must contain. However in reality we mostly don’t add any packages that are in the base group as a dependency to other packages, which basically makes it a hard requirement. The current way of defining a minimal system via a group is non-optimal for the following reasons: - A group can’t enforce installation of packages when being extended or modified - The current base group contains lots of unneeded packages - Manually getting rid of some of the packages may result in broken deps To overcome the disadvantages, a better way to handle a strictly defined set would be a simple virtual base-system package that depends on the bare minimum of what we define as given and required. This virtual package can be changed/extended and every installation will pull it in during the next system upgrade. Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all. This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system. The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime Possible candidates for the virtual package: #### Base requirements: - filesystem - gcc-libs - glibc - bash - coreutils #### Distro requirements: - licenses - pacman - systemd #### Some POSIX tools - coreutils - file - findutils - gawk - grep - procps-ng - sed - tar - gettext - pciutils - psmisc - shadow - util-linux - bzip2 - gzip - xz #### Some networking tools - iputils - iproute2 ## Alternative Another approach would be, assuming we want to properly support tiny containers, to reduce the above list even further to a bare minimum of running pacman and not omit any further 1st level runtime dependencies in our packages. ## Short summary Required: - Use a virtual package instead of a group for the bare minimum Option 1: - Define a base-system virtual package as a required set of packages containing something like a POSIX interactive runtime environment Option 2: - Reduce the set even further to aid tiny containers and don't omit any other 1st level runtime dependency in packages - We could additionally still have a smaller set for a POSIX interactive runtime environment for convenience PS: Please focus on the abstract before bikeshedding whether single packages should or should not be added cheers, Levente

11 31