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

[arch-dev-public] Follow-up on the “Proposal: minimal base system”
by Bruno Pagani 18 Mar '19

18 Mar '19

Hi there, This is a follow-up on the last month discussion about a “minimal base system”. # Reminder of the starting statement > There is no strict definition of what a minimal Arch Linux system installation must contain. However in reality we mostly don’t add any packages that are in the base group as a dependency to other packages, which basically makes it a hard requirement. The corollary being that, since we don’t actually enforce `base` as a policy, some breakage might (and does) happen when people remove part of it from their system. Following on that, the discussion was about implementing a metapackage with a stricter set of packages to be required as installed on any Arch system, and whether or not to keep the `base` group in addition. From this discussion and parallel ones that happened on IRC, I can summarize three important questions (that are, notice, actually independent of the exact content of base-whatever): 1. There is a disagreement on the `base` group purpose: should it just be a convenient helper to bootstrap an Arch system quickly and/or also be used as a set of assumed installed dependencies? 2. Are people actually wanting to be able to assume some installed dependencies at all, and if so, what are they argument(s) for not listing some, e.g. `glibc`? I haven’t seen many apart from “don’t want to list tons of dependency in my PKGBUILD” or “no sane system wouldn’t have it”, and we can discuss whether those are valid one or not, but since the discussion wasn’t happening on that point particularly, there may also be some others that have escaped me. 3. Although it could seems not deeply related at first, what about transitive dependencies (e.g. package A depending on B and C, but only listing B because this one already depends on C)? Here again, breakage happens because of this (when B stop depending on C, which A maintainer cannot be reasonably expected to track), and I’ve only heard “don’t want to list tons of dependency in my PKGBUILD”. Before going further on any proposal in those directions, I’ve thought it surely requires more input, and not only from the ~10 people at most that already participated in those discussions (but still should, because points have changed a bit) since we are discussing distro-wide policy on dependencies here. Regards, Bruno

5 9

[arch-dev-public] Proposal: minimal base system
by Levente Polyak 18 Mar '19

18 Mar '19

# Proposal There is no strict definition of what a minimal Arch Linux system installation must contain. However in reality we mostly don’t add any packages that are in the base group as a dependency to other packages, which basically makes it a hard requirement. The current way of defining a minimal system via a group is non-optimal for the following reasons: - A group can’t enforce installation of packages when being extended or modified - The current base group contains lots of unneeded packages - Manually getting rid of some of the packages may result in broken deps To overcome the disadvantages, a better way to handle a strictly defined set would be a simple virtual base-system package that depends on the bare minimum of what we define as given and required. This virtual package can be changed/extended and every installation will pull it in during the next system upgrade. Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all. This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system. The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime Possible candidates for the virtual package: #### Base requirements: - filesystem - gcc-libs - glibc - bash - coreutils #### Distro requirements: - licenses - pacman - systemd #### Some POSIX tools - coreutils - file - findutils - gawk - grep - procps-ng - sed - tar - gettext - pciutils - psmisc - shadow - util-linux - bzip2 - gzip - xz #### Some networking tools - iputils - iproute2 ## Alternative Another approach would be, assuming we want to properly support tiny containers, to reduce the above list even further to a bare minimum of running pacman and not omit any further 1st level runtime dependencies in our packages. ## Short summary Required: - Use a virtual package instead of a group for the bare minimum Option 1: - Define a base-system virtual package as a required set of packages containing something like a POSIX interactive runtime environment Option 2: - Reduce the set even further to aid tiny containers and don't omit any other 1st level runtime dependency in packages - We could additionally still have a smaller set for a POSIX interactive runtime environment for convenience PS: Please focus on the abstract before bikeshedding whether single packages should or should not be added cheers, Levente

11 31

[arch-dev-public] Dropping trilinos
by Alad Wenter 17 Mar '19

17 Mar '19

With the netcdf rebuild in sight, I will be dropping trilinos. Maintaining it requires significant resources which I do not have at the moment (half a dozen of failing tests in the release version, and 11 hours per -j4 build on soyuz). If anyone is willing to take over maintenance, please let me know before the netcdf migration is complete. Otherwise I will drop it back to AUR. Alad

1 0

[arch-dev-public] Vacation (2019-03-21 -- 2019-04-04)
by David Runge 15 Mar '19

15 Mar '19

Hey all, I'll be on vacation in the timespan mentioned in the title of this mail. In case there are any urgent package updates required, feel free to do them! I might be available online from time to time, but most likely will not have the time to package anything. Best, David -- https://sleepmap.de

1 0

[arch-dev-public] Edit /etc/php/php.ini config file in chroot
by NicoHood 12 Feb '19

12 Feb '19

Hi, I am using devtools to create a package with php scripts. It uses composer to build the package. I get the error: The requested PHP extension ext-iconv * is missing from your system. Install or enable PHP's iconv extension. This can be solved by editing the config file and add: extension=iconv The config file is only accessible by root. How do I edit this config file within the PKGBUILD if its build by devtools? Any idea? ~Nico

3 2

[arch-dev-public] Archweb migration
by Jelle van der Waa 08 Feb '19

08 Feb '19

Hi All, Tommorow night (CET) I will update archweb (archlinux.org) to Python 3. We've already tested it on a staging server and it seems to work well so tommorow I'll update it on our main server. This will mean that archlinux.org will be unavailabe for ~ 30 minutes since the upgrade requires some manual work with removing and creating a new virtualenv. -- Jelle van der Waa

1 1

[arch-dev-public] Improving overall experience for contributors follow up
by Jelle van der Waa 06 Feb '19

06 Feb '19

Hi, I still believe we should take some initiative on thse issues. What we have so far is: - Getting involved page, not sure where it's linked from? Only findable on the wiki. [1] Which links to a nice list of projects with an already dedicated irc channel and mailing lists. (I was not even aware of #archlinux-projects). But does anyone ever find this page? I think we should at least link it from archlinux.org. - The mozilla idea, I'm up for it? Should we host it under whatcanidofor.archlinux.org? Note that this also requires some effort from the team's side. We should however keep our bugtracker tidy and maybe label "new contributor" tickets since this is quite crucial to get new people in. I however have also some thoughts on things which these days have no tickets, but could be worked on for example: - revamping the Ruby guidelines. They should be as nice as the Python ones - Hardening our custom systemd services and creating bugs with patches, for example grafana has hardening applied now. [5] - Man pages for more devtools binaries. I'm quite sure others others have such projects on their mind which are not publicly findable yet. (sogrep to devtools for example) [1] https://wiki.archlinux.org/index.php/Getting_involved [2] https://wiki.archlinux.org/index.php/DeveloperWiki:Projects [3] https://github.com/archlinux/archweb/issues [4] https://github.com/archlinux/pyalpm/issues [5] https://git.archlinux.org/svntogit/community.git/tree/trunk/grafana.ser= vice?h=3Dpackages/grafana P.S. sorry for splitting up into a new thread, but it seems replying makes spamassasian mark my reply to the thread as spam. -- Jelle van der Waa

3 2

[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] Away until Feb 11
by Bartłomiej Piotrowski 25 Jan '19

25 Jan '19

Hi all, I'm trying to run away from winter so I'll be away starting Wednesday. I will be partially available via IRC/e-mail but I don't plan to do any packaging. Bartłomiej

1 0

[arch-dev-public] FOSDEM 2019
by Morten Linderud 24 Jan '19

24 Jan '19

Yo! Last year at FOSDEM we where quite a few members from the Arch team present, and I though it would be nice to have a dinner together! My suggestion is to do it Friday around 18:00 then head for the beer event at delirium afterwards. To make it managable I'll cap the attendees to 15 people. Priority for members of the Arch team (developers, trusted users and support staff) and any free spots after this can be taken by anyone interested :) Please send an email so I have some ability to keep track. If Friday does not fit for some people in the team, please write if saturday or sunday fits better. If multiple people arrive super late we could move things around, or have multiple dinners! Restaurant suggestions are also welcome! (I have CC'ed arch-dev-public since I don't actually know how many people watch arch-events. Sorry for the noise!) -- Morten Linderud PGP: 9C02FF419FECBE16

5 5