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

Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
by Giancarlo Razzolini 11 Nov '19

11 Nov '19

Em novembro 11, 2019 16:18 Gaël PORTAY escreveu: > Hi Giancarlo, > > On Sun, Nov 10, 2019 at 06:41:38PM -0300, Giancarlo Razzolini via arch-dev-public wrote: >> >> I have been working on hooks for dracut to install the kernels to /boot, as mkinitcpio does, and >> also create a simple configuration file for each kernel. Right now dracut does not conflict with >> mkinitcpio, and it is possible to have both installed at the same time on a system. The hooks I'm >> writing for dracut will, however, check if mkinitcpio is installed and won't run if it is. We might >> eventually conflict them if we decide dracut is mature enough for usage with Arch Linux. As a side >> note, I have been using it for the past 8 months without any issues. > > Do you have commited your hooks somewhere? I would like to have a look > to them and probably to test them. > They should land on the dracut package itself sometime this week, or start of the next week. I might commit them to svn before that, so probably keep an eye on the dracut package git repository, but I make no promises. There will probably be some default dracut configuration as well. And each kernel might end up having two dracut.d configuration files, one for each image (regular and fallback), created from a preset, in a similar way mkinitcpio does it now. Regards, Giancarlo Razzolini

1 0

[arch-dev-public] Adding package (lib32-)-amdvlk in extra (and testing)
by Laurent Carlier 10 Nov '19

10 Nov '19

I would like to add these packages in the official repositories. It's a good alternative to vulkan-radeon packages, well maintained upstream and offer a good compromise with new gfx card released.

2 1

[arch-dev-public] Python 3.8 rebuilds
by Evangelos Foutras 31 Oct '19

31 Oct '19

For the next few days we'll be doing (semi-automated) rebuilds for Python 3.8. Please avoid adding new Python packages and starting other rebuilds during this time.

1 1

[arch-dev-public] xf86-input-keyboard dropped
by Andreas Radke 30 Oct '19

30 Oct '19

This Xorg input driver package shouldn't be used under Linux systems anymore. It has been removed from our repos. Use either xf86-input-libinput or xf86-input-evdev driver package. https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/merge_reques… -Andy

1 0

[arch-dev-public] Using SPDX License list as identifiers
by Jerome Leclanche 28 Oct '19

28 Oct '19

Hi This just came up on IRC. Thoughts on using the SPDX license list as valid license identifiers for all packages? https://spdx.org/licenses/ Most of the identifiers would change but we would have a consistent and much larger, externally-maintained list to choose from. It would also be a little more accurate; eg. the SPDX allows for distinctions such as "LGPL-3.0-or-later" vs. "LGPL-3.0-only". We could retain the current identifiers as symlinks. J. Leclanche

5 6

[arch-dev-public] Information about the base meta-package
by Levente Polyak 15 Oct '19

15 Oct '19

Q: Why has this been implemented so suddenly? A: That's a good question, while we have discussed this topic multiple times in the past and also issued a concrete proposal to arch-dev- public (plus its follow-up summary) no further steps were taken to get something testable. However, during arch-conf in Berlin, the general enthusiasm and acceleration of the group was so strong, that we have warp-10 driven this task. We acknowledge that this could have been handled more carefully, but in the spirit of arch-conf please excuse us and bear with us. For instance, we could have noticed during a test phase the consequences of not having systemd- sysvcompat. For the time being, we have added it to the base package as the implications were not explicitly desired and discussed beforehand, however that topic will be covered in a follow-up. Q: Why has the group been superseded by a meta-package? A: The difference with the new base package is that this defines the level at which we tell you, you have modified your system sufficiently that you break it, you bought it -- it is your responsibility to debug issues caused by your overriding basic assumptions of the system. This has theoretically already been the case before this change as packages in the old `base` group were expected to be installed by a lot of packages. On the other hand, it has never explicitly been stated that this indeed is a requirement. The consequence is that packages may potentially misbehave or fail to properly install. Following this reasoning, it's a very natural choice to use a meta- package. It allows us to reflect changes (additions or removals) in the required package set straight on user installs with the next system upgrade which allows preserving the consistency of those assumptions. A simple example would be the systemd package, no matter what use-case you have (like a tiny container) we assume you must have systemd installed as its being relied on (sysusers, tmpdirs, etc.). Q: Why has it been shrunk down and doesn't contain $package anymore? A: The base meta-package is meant to be the lowest common denominator across different use-cases like desktop usage, bare-metal server or container runtime and therefore defines the foundation people can build their desired environment upon. The old base group did not just contain too many unnecessary packages for us to reasonably be able to call it the lowest common denominator, it was also inconsistent (for example it shipped reiserfsprogs but not btrfs-progs). After reflecting on all of the feedback so far, it also became quite clear that the old base group was kind of misused as a poor man's installer. There is nothing wrong with such a use case per se, but if there is a desire to solve this on our side, we should find the optimal solution instead of just sticking to some legacy. Be it an actual installer, something like a base-extras group, or nothing at all, it is out of scope here, but we should look into it separately -- so maybe its a bit of xkcd#1172. Q: Why couldn't we just add a new package and leave the base group as it was? A: The primary reason is that base (as the name indicates) shall be the minimal foundation and denominator of different use-cases. If we would introduce anything other than 'base' to fulfill this job, like base-system, base-minimal, base-foundation, or whatever one could come up with, it wouldn't get the point across as clearly as the name 'base' itself. The historic knowledge is mostly responsible for our bias here, but it is clearly easier to grasp the intention compared to the difference between having `base` and `base-minimal`. Q: Should we update the dependencies of our packages to depend on base instead of on its members? A: Nothing has changed in that regard and there is no strict rule for do or don't yet. This is in general more related to the topic of transitive dependencies which needs to be discussed eventually. My recommendation is to just keep the members that are a first-level dependency because there is absolutely no point in making every single package in the universe depend on the base meta-package. However, it can be correct, clean and useful to list your first-level dependencies explicitly instead of not at all. Q: What happens next, are there any plans? A: The most important part was getting this abstract out to provide information and aid in resolving some of the confusion. The next steps will include multiple follow-up topics to iterate over and decide case by case -- for example how we want to handle systemd- sysvcompat and other topics that emerged. cheers

2 1

Re: [arch-dev-public] Packages added to todo list 'protobuf 3.9 rebuild'
by Lukas Fleischer 06 Oct '19

06 Oct '19

On Thu, 03 Oct 2019 at 12:27:45, Arch Website Notification wrote: > Todo list information: > Name: protobuf 3.9 rebuild > URL: https://www.archlinux.org/todo/protobuf-39-rebuild/ > Creator: Lukas Fleischer > Description: > Please rebuild affected packages and move them to > [staging]/[community-staging]. Since there's some overlap with the boost rebuild, we should probably wait until boost leaves [staging]. I temporarily removed protobuf from [staging] just to be safe.

1 2

[arch-dev-public] Retiring as a Trusted User
by Florian Pritz 02 Oct '19

02 Oct '19

Hi, I no longer have the time necessary to properly handle actual TU duties so I am retiring my TU hat. I will still continue maintaining some packages I have in [community] via my developer hat. That said, I'd like to orphan some of them too. If anyone is interested in taking over one of these packages (and its dependencies), please feel free to adopt it and tell me so that I can orphan it. asciidoc filezilla libfilezilla gcolor2 gmrun obconf openbox openshot libopenshot libopenshot-audio pydf slock tipp10 vimpager xplc zim Florian

6 6

[arch-dev-public] Dropping packages to AUR
by Alad Wenter 27 Sep '19

27 Sep '19

Hi, As I no longer use them, I will drop the following packages to AUR unless someone is interested in picking them up: * hashdeep * libclastfm * pragha * python-i3-py * python-pygraphviz * usbview * youtube-viewer The following packages are dependencies of existing packages, and could equally use a new maintainer: * glyr (optional dependency for abcde) If you are interested in any of the above packages, please let me know in a reasonable time period (say, two weeks.) Cheers, Alad

3 3

[arch-dev-public] A contrib repository
by Morten Linderud 12 Sep '19

12 Sep '19

There is a *lot* of small tools people have written over the years that resides in bin/ directories which could be useful for more people. We also have several such tools on soyuz, where sogrep was added to devtools this week. I have been thinking it could be great to have a simple `contrib` repository where every team member has commit access. This could work as a staging area for tools we would like to promote to `devtools` later on. We could maybe sort this into directories for its purpose: * packaging * security * devops * testing * bugwrangler * misc Tools that can be added here is the `ch` scripts from Bluewind, and the pkg-* tools eli has created. I also have some tools to look for pkgname in archweb, check them out from svn and check them against a nvchecker file. This would hopefully give us a space where we can experiment with new maintainer tools in a collaborative manner. I'd love to hear some feedback or thoughs on this! -- Morten Linderud PGP: 9C02FF419FECBE16

8 14