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

[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

[arch-dev-public] new archweb release
by Jelle van der Waa 12 Sep '19

12 Sep '19

Hi all, A new archweb release has been deployed on our server, with a couple of notable changes: - Signoff status has been moved up in the Developer Dashboard for more attention - When enough signoffs are reached, archweb automatically sends a mail to the packager that the package has reached the target signoffs! If this is too spammy we can consider a "daily" report. In the future release, I aim to improve onboarding of testers and further investigate where the lack of signoffs comes from. So far it seems we have around ~ 18 "active" testers.

3 2

[arch-dev-public] Semi-away till 2019
by Bartłomiej Piotrowski 06 Sep '19

06 Sep '19

Hi all, As I have free time shortage lately, I think it's fair to officially say I will be in semi-away mode till 2019. I will try my best to keep up with uncomplicated pkgver bumps for packages I maintain on my own and make sure all keys are properly signed, but that's all I can promise. It also means I'm unable to give toolchain attention it deserves. Please poke me somewhere if you happen to be interested in co-maintaining it. My responses on IRC or via e-mail may be also delayed so take that into account before kicking me out. Bartłomiej

4 4

[arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
by Eli Schwartz 04 Sep '19

04 Sep '19

QtWebEngine supports spellchecking: https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker However, they have helpfully decided (steered by upstream chromium) to *not* use hunspell dictionaries, and instead to use... hunspell dictionaries stored in /usr/share/qt/qtwebengine_dictionaries/ as ".bdic" files, because this is supposedly "more efficiently read by chromium". (Actually QtWebEngine's spell-checking infrastructure is entirely willing to read dictionaries in /usr/bin/qtwebengine_dictionaries before looking in /usr/share because clearly they've put great thought into how this is all supposed to work on a conceptual design level especially for distro packaging.) So I have a program -- pageedit -- which just added spellchecking support via qtwebengine in the latest release, and I would like to support that. And I don't want to see people being personally responsible for installing their own stuff in /usr/share. While I'm at it, Morten (Foxboron) pointed out to me that qutebrowser also supports spellchecking, and it currently provides a user script which downloads preconverted dictionaries from chromium's git repository into $HOME/.local/share/qutebrowser/ ... because there's apparently no guidance or precedent for actually distributing these dictionaries. (In fact, currently only Fedora seems to make these dictionaries available to users.) It's possible to convert them yourself, using the qwebengine_convert_dict tool shipped in the qt5-webengine package. I think it would be nice if users were able to obtain these dictionaries properly, but I'm not positive what the best way would be. Ideas: - Ship a pacman hook to convert whatever the user has installed, implemented via the following libalpm script and hooks: https://paste.xinu.at/m-ydTjU/ - make every hunspell-* package makedepend on qt5-webengine and produce those dictionaries - same thing but also make split packages for basically a tiny data file - force users to install an out of date AUR package not kept in sync with hunspell-* (this one is just a joke) The advantage of a hook is that users with webengine installed automatically get magic google-approved dictionaries corresponding to the hunspell dictionaries they have installed. The advantage of modifying each hunspell-* package is saving about 0.38 seconds per file at installation time, plus users don't have weird untracked files in some cloistered dir in /usr/ The advantage of doing anything other than possibility #3 is "avoid adding another 34 packages to the repositories, which users need to manually install in addition to the other dictionaries they explicitly installed". ... Prior art: Fedora uses rpm post-install filetriggers: https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/master/f/qt5-qtwebe… Gentoo has a proposal for a package that runs the conversion tool on each file the user has installed in /usr/share/hunspell/ and packages the results. ... Thoughts on the best way forward to make these dictionaries available on Arch Linux? -- Eli Schwartz Bug Wrangler and Trusted User

5 8

[arch-dev-public] deepin-kwin removed from [community-testing]
by Felix Yan 03 Sep '19

03 Sep '19

There are multiple major issues with the new version 5.0.0, and upstream doesn't yet have figured them out after a month. Currently it would be better to stick with 0.1.0. -- Regards, Felix Yan

1 0

[arch-dev-public] Wiki Update in progress
by Pierre Schmitz 01 Sep '19

01 Sep '19

Hi there, I triggered a Wiki update. Unfortunately the update script is running longer than expected. So pages appear to be empty. Greetings, Pierre

2 4