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

[arch-dev-public] Arch Linux Wiki move
by Giancarlo Razzolini 03 Mar '18

03 Mar '18

Hi All, I am about to move the wiki to apollo. I'm estimating that it will be down for one to two hours. Please, let me know if any of you notice something not working on it. I have tested the role extensively, but you never know. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] PSA: third-party gems have been split from 'ruby' package
by Anatol Pomozov 02 Mar '18

02 Mar '18

Hello folks There been a packaging issue with 'ruby' package that annoyed me for a while. The problem comes from the fact that ruby-lang.org source tarballs contain ruby sources itself *and* some third party packages from rubygems.org. The third-party gems shipped by 'ruby' tarball are: minitest, net-telnet, did_you_mean, power_assert, rake, test-unit, xmlrpc, rdoc. Currently we repack these gems and ship it as a part of ruby Arch package. Because gems are bundled with ruby package we have no way to update gems separately. All we can do is to wait until ruby developers update their bundle and release it. The plan is to split these gems from 'ruby' package and install it independently from what ruby developers bundle. Upcoming ruby changes do that - ruby-2.5.0-4 will not include any of the third-party gems mentioned above. Two popular packages - rake and rdoc will get Arch packages (ruby-rake and ruby-rdoc respectively). Other gems need to be installed either from AUR or from gem.

2 3

[arch-dev-public] Realtime settings package
by David Runge 20 Feb '18

20 Feb '18

Hey all, I'd like to discuss the split-out of the realtime settings for jack{,2}* (see also the discussion on arch-proaudio [1]) to a separate package. Currently they all ship /etc/security/limits.d/99-audio.conf /usr/lib/udev/rules.d/40-hpet-permissions.rules Redundancy alone would suggest moving these to a separate package, but I think there is something more to gain from it: Other packages - potentially requiring realtime scheduling - can benefit from these settings (by depending or optdepending on such a "settings package"). Currently I am not aware of another use-case, but that might just be me working on a subset of what is available out there. Any hints or suggestions on what other software can possibly benefit from this are very welcome! The coupling with the audio group is more of a flaw, than anything imho, as every member of the group "audio", used for e.g. accessing MIDI devices, is automatically a realtime user (once jack is installed). I would want to create a dedicated group, e.g. "realtime", that will hold those limit permissions. Also rtprio should be reduced to 95, as it is actually rather dangerous having daemons run at the same pace as the kernel services themselves (this is a definite upstream documentation flaw [2]!). This means having a dedicated realtime group, that other packages can depend on. The only thing needed to use it, is to add a user to a group. Maybe there are even some ways to do this all with systemd by now? I have been running jack2 successfully using a systemd user service [3] for quite some time now (and eventually I plan on integrating it, because it enables a lingering user to auto-start jack as a service). However, this would only be a use-case for jack and jack2, but not for jack2-dbus, as there the request of other applications requiring the start of jack will not lead to using /usr/bin/jackd, but /usr/bin/jackdbus by default. I have looked at how Debian ships jackd2 [4] and they don't use the udev rule at all. So I'm a little hesitant on whether to continue shipping it and whether it is actually required. See also this very old bug report [5], `man 5 limits.conf`, `man 8 pam_limits` for more info on the overall topic. Any input is very welcome! Best, David [1] https://lists.archlinux.org/pipermail/arch-proaudio/2017-December/000020.ht… [2] http://jackaudio.org/faq/linux_rt_config.html [3] https://git.sleepmap.de/software/uenv.git/tree/user/jack@.service [4] https://packages.debian.org/jessie/amd64/jackd2/filelist [5] https://bugs.archlinux.org/task/26343 -- https://sleepmap.de

1 0

[arch-dev-public] Pro-audio packages from AUR
by David Runge 20 Feb '18

20 Feb '18

Hey all, I'd like to move the following packages to community: zita-at1 [1] zita-bls1 [2] zita-dpl1 [3] zita-lrx [4] zita-rev1 [5] zita-njbridge [6] zita-mu1 [7] jacktrip [8] padthv1 [9] The first seven are de-facto standards, developed by Fons Adriansen (some other of his zita-* tools are already in extra and community). They are low maintenance and have a low frequency release cycle. Jacktrip is one of the few working audio-over-network solutions using jack servers on both ends [10]. Padthv1 is (yet) another Qt based audio application by Rui Nuno Capela and part of the vee one suite [11] (the other three parts of the set are already in community - synthv1, drumkv1, samplv1). As they have a low voting count, I'm hereby asking: Are there any objections to them being moved? Best, David [1] https://aur.archlinux.org/packages/zita-at1 [2] https://aur.archlinux.org/packages/zita-bls1 [3] https://aur.archlinux.org/packages/zita-dpl1 [4] https://aur.archlinux.org/packages/zita-lrx [5] https://aur.archlinux.org/packages/zita-rev1 [6] https://aur.archlinux.org/packages/zita-njbridge [7] https://aur.archlinux.org/packages/zita-mu1 [8] https://aur.archlinux.org/packages/jacktrip [9] https://aur.archlinux.org/packages/padthv1 [10] http://jackaudio.org/faq/netjack.html [11] http://www.rncbc.org/drupal/node/1879 -- https://sleepmap.de

2 1

[arch-dev-public] Automating package conflict resolution whenever possible (xorgproto/libxfont dependency conflict)
by Baptiste Jonglez 15 Feb '18

15 Feb '18

Hi, Eli and I disagree about how dependency conflicts should be handled when packaging. This was prompted by the libxfont dependency conflict arising from recent xorgproto changes [1]. My position in this case: it would be really easy to avoid this conflict, by adding libxfont to the Replaces() array of xorgproto. This would cause libxfont to be automatically uninstalled upon sysupgrade, which is nice because it's an obsolete and now-useless package. I think this kind of automatic handling of dependencies and obsolete packages is desirable whenever possible, precisely because it is *automated*. On the contrary, with the current libxfont/xorgproto situation, every Arch user has to spend time to *manually* fix the dependency issue (by removing libxfont). As packagers, I believe we have better things to do than purposefully waste the time of Arch users. Especially for dependency conflicts like this one, which is so trivial and boring: libxfont should clearly be deleted, and an Arch user will learn nothing interesting by having to manually fix the dependency issue. But it seems that this position is not shared by Eli (and possibly others), who thinks that Arch users should be able to figure out this kind of issues by themselves. I agree, but this is not a reason to force boring tasks on them, while we could have easily avoided the issue in the first place. If there are some existing rules or "traditions" that address this question, please provide pointers. Otherwise, I would like to know if there is a consensus one way or the other. Thanks, Baptiste [1] https://bugs.archlinux.org/task/57495

6 11

[arch-dev-public] Test repository with gcc8
by Bartłomiej Piotrowski 13 Feb '18

13 Feb '18

Hi all, I've prepared external repository with GCC 8 built from trunk (as there is no stable release yet) that also contains glibc 2.27 and binutils 2.30. [gcc8] Server = http://pkgbuild.com/~bpiotrowski/gcc8/ From less obvious packaging changes, glibc no longer ships with obsolete rpc and nsl, which means that you should switch your packages to libtirpc; also if your nsswitch.conf still contains "compat" instead of "files", better fix it before reboot. If for some reason you still use nsl, the repository also ships libnsl and libnsl_nis packages. As usually, simple things build, and colossi like LibreOffice don't, but I haven't had time yet to check why. If you found some issue, the best would be to reply either here or arch-general. Enjoy, Bartłomiej

3 5

[arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
by Florian Pritz 12 Feb '18

12 Feb '18

Hi, Once again, debug repos came up in IRC. AFAIK progress on this is blocked by Pierre not responding/merging patches. gbs has implemented quite a lot in dbscripts itself, but we still need someone to come up with a migration plan, testing and deploying the whole thing. Eli offered to take the lead on getting that done and also later migrating us to git instead of svn. If there are no objections I'll help where necessary and give him access to the dbscripts and devtools repos in two weeks. I'm also CC'ing Pierre and gbs so they can jump in if necessary. Florian

4 6

[arch-dev-public] Moving schiv's packages to [community]
by Antonio Rojas 03 Feb '18

03 Feb '18

As per David's request [1], due to schiv's unresponsiveness, I will move all of his packages which are not dependencies of any [extra] package in a few days to [community], where David is willing to maintain them. Any objections? [1] https://lists.archlinux.org/pipermail/arch-proaudio/2018-Janua ry/000050.html

1 0

[arch-dev-public] Abandoning nvidia 340xx packages - does anyone want them?
by Sven-Hendrik Haase 31 Jan '18

31 Jan '18

I do not have any devices which require me to run nvidia 340xx packages and I haven't tested them for quite some time now. The most recent nvidia devices which require 340xx because the regular nvidia package dropped support for them are now 8-9 years old. I'm not really sure there is merit in maintaining these so unless anyone wants them I'll drop them to AUR in two weeks.

3 4

[arch-dev-public] New devops member - Phillip Smith (fukawi2)
by Florian Pritz 29 Jan '18

29 Jan '18

Hi, We have a new member joining the sysadmin/devops team by recommendation of Allan. I've already rolled out root and git access. Welcome Phillip, let's break stuff! (slightly) ;) Florian

1 0