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

[arch-dev-public] Improving overall experience for contributors
by Bartłomiej Piotrowski 06 Feb '19

06 Feb '19

Hi all, Spending some time outside the regular Arch circles, I realized that the way we "outreach" potential contributors is at least imperfect. One of the problems I keep hearing about is that there is no clear place where potential contributors could start. Sure, some things seem obvious to us: take care of some wiki article or adopt orphan AUR packages. It isn't actually that easy. Not everyone is interested in editing or maintaining random packages, and while there is plenty to do, how someone new could know it? We could use help not only with existing projects like archweb, pyalpm or namcap, but also with development of new code (for example a maintainable rebuild automation) and infrastructure side (which is in fact too generic term that could be better described). I am totally in love with What can I do for Mozilla?[1] which is open source, so why not steal this wonderful idea? But it also means we need a way to communicate with people interested in helping us: at least an IRC channel and new mailing list. Another thing that I heard in last few months isthat it is actually hard for potential TU candidates to find a sponsor. While I believe it is perfectly fine to e-mail few potential sponsors to ask for opinion, throwing random messages at people doesn't sound really appealing. In my humble opinion, we should rethink the way we recruit people and probably introduce fine-grained permissions to dbscripts that would allow to limit new maintainers to limited set of packages. We should also lower our expectations towards candidates. At least once we rejected one for some stupid reason (no fingerpointing here, I'm not saint either), leaving packages they wanted to adopt virtually orphan. It's better to help amn inexperienced packager gain experience than voting no, really; to be brutally honest, quite a lot of packaging work we are handling doesn't have much in common with rocket science. I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we will tackle it another time. Your thoughts? Bartłomiej [1] https://whatcanidoformozilla.org/

8 11

[arch-dev-public] New build server in Singapore
by Bartłomiej Piotrowski 04 Apr '18

04 Apr '18

Hi all, for those of you that are living closer to Asia than Europe, there is new build server available, located in Singapore. It is considerably less beefy than soyuz, but should be okay for regular builds. All packagers should be able to ssh into it with username and the key used on other servers. The address is sgp.pkgbuild.com. You can compare fingerprints below: SHA256:f9VrDpIpOHvgWk+OXXRG+VMvJlbs577YFZfyxPtXKqU (ED25519) SHA256:fDdeGInsD764tfnGCbNIPH69L4k7mNs98ttFpTOv01U (RSA) SHA256:MsoXUmTXowWcPb4gma3U60Po0/5sTT5Fg+oM8bWIIUE (ECDSA) It also hosts a mirror available at https://sgp.mirror.pkgbuild.com Enjoy, Bartłomiej

3 4

[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] 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] 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