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

[arch-dev-public] Arch Linux Docker / Vagrant: Current situation
by Christian Rebischke 12 Mar '18

12 Mar '18

Hello Everybody, It's now over a half year ago that I've started working together with sangy and pierre on our vagrant and docker images. I would like to give you a short update on this topic. The Arch Linux Vagrant images are currently be build for libvirt and virtualbox. We have over 3800 downloads at the moment and slowly catching up to the community based arch linux vagrant images.[1] My first goal has been to add some hypervisors, but due to the fact that we have only libvirt and virtualbox in our repositories I have dismissed this plan. The automated build process works fine so far (except some issues with qemu[2] and the dependency on punctual iso releases on soyuz. The latter should we definitly fix. Currently the iso images are build manually. Can we automate this somehow? I really rely on punctual releases otherwise the automated build will fail and somebody needs to trigger the build again manually. Happened about 1-2 times..) The other topic is the docker image. Has anybody of you contact to pierre? He doesn't answer my mails and he is the only one with access to the repository on github. Sangy/Santiago[3] was so nice to speak with the docker guys. They said they would approve our docker image and we could move it to the other official images[4]. But for this we need to do some changes on our docker repository on github. (As long I understood sangy correct it would be just some new branches). best regards, chris / shibumi [1] https://app.vagrantup.com/archlinux/boxes/archlinux [2] https://github.com/hashicorp/packer/issues/5769 [3] https://www.archlinux.org/people/support-staff/#sangy [4] https://hub.docker.com/explore/

7 19

[arch-dev-public] LLVM 6 and splitting up {clang, lld, lldb, compiler-rt} into separate PKGBUILDs
by Evangelos Foutras 09 Mar '18

09 Mar '18

I pushed llvm 6.0.0-1 to [staging] without the rest of the packages mentioned in the subject. I am planning to add them back as individual packages in the following days. This separation will bring faster builds when one of these components needs patching. It also allows building clang with shared libraries and merging the extra-tools package into it (thus fixing https://bugs.archlinux.org/tas k/50865). Once everything is in [staging], I'll create a TODO list for rebuilds as usual.

1 0

[arch-dev-public] Moving extra/radvd to [community] (to adopt it)
by Thore Bödecker 08 Mar '18

08 Mar '18

Hey, currently the radvd package sits in extra with an open issue that is really annoying: https://bugs.archlinux.org/task/57310 With this mail I'm offering to adopt and maintain this package if there are no objections. In order for me to do so it would need to moved from extra to community as I'm only a TU. Cheers, Thore --

2 1

[arch-dev-public] Windows Subsystem Linux - Arch Linux as official container?
by Christian Rebischke 07 Mar '18

07 Mar '18

Hello everybody, I would like to start a discussion about Windows Subsystem Linux and Arch linux. You all might know that Microsoft has increased their participation in open source software a lot since Satya Nadella is CEO of Microsoft. They even implemented a subsystem on Windows 10 for executing natively ELF binaries on Windows. This system is based on docker images and some nice guys from Microsoft have asked Allan and me if Arch Linux would be interested to participate in this project. The steps for getting into the project are: * Signup in the Microsoft Appstore (we would get a free voucher if we want to participate) as Organization (we need the ok from one of our trademark holders for this step) * modifying our docker container a little bit * pushing it into the microsoft appstore So what do you think? Should we participate in that project? Here are some pros and contras: pro: - CentOS and Ubuntu are there too - Would be a nice chance to increase the awareness about Arch Linux - might get people to change from Windows to Arch Linux (or linux in general) - Nice way to test our docker image in production - People who are forced to work on windows at work can use Arch Linux at work as well - More bugreports / feedback / forum activity? contras: - Microsoft is Microsoft (I think I don't need to explain) - More Newbies? - Somebody would need to maintain it (I would do it) - If Arch Linux partnerships with Microsoft could lead into bad image? I would like to hear as much feedback as possible. So don't be shy :) I want to give feedback to the microsoft guys in round about 1 week. I guess that should be enough to dicuss this topic. So deadline is 2018-02-7 -- Chris

8 11

[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