Re: auth-tarball-from-git: verifying signed git tags without sha256sums=(SKIP)
On 2022-05-29 12:40:22 (+0200), kpcyrd wrote: > I blogged about a new tool that can be used to verify a tarball from a > signed git tag, while still pinning the sourcecode with >= sha256sum: > > https://vulns.xyz/2022/05/auth-tarball-from-git/ > > Let me know what you think - that's all, Hi, in your article you are missing the commit pinning strategy, which should usually be used (admittedly a few of my packages also don't use that yet... :S) for scenarios where git based VCS sources are used and signed tags should be validated. According to how one can use VCS sources [1], it is possible to pin to a commit. This commit can be the signed tag object as retrieved by using git ls-remote [2]. There is no tooling in the context of our package tooling that allows for automating this (e.g. bump to new version, automatically retrieve the given commit checksum to pin), but it is a viable option to pin a given signed release by its commit checksum and have the `?signed` check as well, while continue using VCS sources. Best, David [1] https://man.archlinux.org/man/PKGBUILD.5#USING_VCS_SOURCES [2] https://man.archlinux.org/man/git-ls-remote.1 -- https://sleepmap.de signature.asc Description: PGP signature
Re: default gems in ruby deployment
Hi Andreas, first off: Thanks for looking into this! I guess not all of the packagers knows how complicated and time-consuming packaging ruby can be. On 2022-06-01 23:05:45 (+0200), Andreas 'Segaja' Schleifer wrote: > The problem is that in order to get this fully working we need to package > all 74 stdlib ruby gems. Currently we have only packaged 9 of them from > which 5 are in the AUR. If you have created a list somewhere and if I have some spare time, I'd be glad to help package some. > My proposal to get this into a working state are these steps: > > - remove all gems from the ruby package which are already packaged as > dedicated packages in [extra] or [community] > - create a ruby-stdlib meta package which requires the existing ruby stdlib > packages > - make the ruby package require the new ruby-stdlib package > > These steps should clear up the situation for the few existing separate > builds of the stdlib packages. > Then we can successively package the other stdlib packages and once one is > done remove it from the ruby package and add it as dependency to the > ruby-stdlib package. > > Next week I can prepare the ruby-stdlib package and a patch to the ruby > package to get the first steps of this plan working. As the ruby sources will drag in the vendored dependencies it could prove beneficial to have ruby's PKGBUILD carry ruby-stdlib as a split package (unless you think that complicates things). That way it is easy to determine if a new vendored dep is added or removed as well. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: default gems in ruby deployment
Hi all, sorry for the late reply. On 2022-06-14 21:18:18 (+0200), Andreas 'Segaja' Schleifer wrote: > As to the state of things and a patch for the PKGBUILD: > > I have a diff of the ruby PKGBUILD ready [0]. I’m adding another split > package to the mix called ruby-stdlib which is defining the dependencies we > already have. > Furthermore I’m removing the stdlib gem from the base ruby package which we > already have as a dedicated package. > > In the end we need to do this for all of the stdlib and bundled gems once > they are packaged. Afterwards we can simplify the cleanup logic that happens > in `package_ruby()` again. This looks good and seems like a reasonable way forward! Let's proceed! > One more point I would like to bring up is that currently the ruby package > [1] only has one maintainer (Anatol) and I think we should increase the bus > factor for this package. I don’t consider myself an expert for ruby > packaging, but I would be happy to help out. > The only problem is that the package is currently located in [extra] where I > don’t have write permissions to as a TU. What would be the effort / impact > of moving this package (and other related ruby packages) to [community] to > have more people (maybe also David or Tim) maintain it? > We also should update the comments at the beginning of the PKGBUILD file, as > it currently only lists people as “Contributor” and no one as “Maintainer”. Ruby does not seem to be directly required by anything in extra. E.g. apparmor only carries it as an optional dependency. So moving should not be an issue. @anatol what do you think? I agree that a higher bus factor on this package would be very good, but I also do not count myself as a ruby expert. If it proves impossible to move ruby to [community], I would volunteer to co-maintain to help implement the upcoming changes, but I'd much rather see this done by Tim and Andreas, who have been spending quite some time on improving the quality of many ruby packages already. Somewhat related, I'd love to see the respective package guidelines [a] be updated, so that they reflect a workflow in which packages are built from source tarballs, tests are run and unreproducible files are removed. This way we can guarantee a higher degree of functionality to the user and easily detect breakage on rebuilds, while having reproducible packages. Best, David [a] https://wiki.archlinux.org/title/Ruby_Gem_package_guidelines -- https://sleepmap.de signature.asc Description: PGP signature
Re: Gone until August
On 2022-06-26 19:36:47 (+0200), Morten Linderud wrote: > I'll be gone from the start of July until the start of August! Vacation time > along with starting a new job over the summer. I also need to recharge some > batteries. Enjoy your time off and have a great summer! > I've included a list of packages I'm the sole maintainer of. Feel free > to co-maintain or update it when there are new releases available. > Note the list contains core/extra/community packages. > > catatonit > cni-plugins > podman-dnsname adopted Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: default gems in ruby deployment
On 2022-06-24 22:47:04 (+0200), David Runge wrote: > Ruby does not seem to be directly required by anything in extra. E.g. > apparmor only carries it as an optional dependency. > So moving should not be an issue. @anatol what do you think? As there has been no negative feedback to this suggestion, I'd move ruby and rubygems to [community] tomorrow, so that work on the topic can commence. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: default gems in ruby deployment
On 2022-07-02 13:07:38 (+0200), David Runge wrote: > As there has been no negative feedback to this suggestion, I'd move > ruby and rubygems to [community] tomorrow, so that work on the topic > can commence. The packages are now moved and the updated package guidelines are in place: https://wiki.archlinux.org/title/Ruby_package_guidelines Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Blockers for release of archlinux-keyring
Hi all, if you are a main signing key holder or a packager for Arch Linux, please read this mail very carefully! We are currently blocked from releasing a new version of archlinux-keyring, as a release would imply demoting a few packager keys to marginal trust (aka. not enough signatures from our signing keys to be allowed to package). Some of these marginal trust keys still (or again...) have packages in the repositories. All in all the keyring is not in very good shape due to missing revocations or signatures (and broken keys that block us from updating to a newer gnupg version, but that is for another email). Blocking the release of archlinux-keyring for this long is problematic in several ways: * existing keys that need to be updated are blocked from being released to the users and packages may need to be rebuilt if keys expire on user systems (which leads to manual action to install the keyring first, etc.) * new keys can not be released to the users (blocking packagers from packaging, leading to many outdated packages that need to be taken over by other packagers) * the updated trust status of revoked keys can not be released to the users (allowing old keys to still package) # Marginal trust keys There are currently 25(!) marginal trust keys in the keyring, some of which are old and superseded by new keys (I had to manually assign which of the keys are old/new/current for the below overview). ``` alucryd 9437DD3815A7A9169E3D3946AFF5D95098BC6FF5 ~ marginal - old andrewSC 601F20F1D1BBBF4A78CF5B6DF6B1610B3ECDBC9F ~ marginal - current arodseth 8A9BC5819C54FEB3DC2A9B48C32217F6F13FF192 ~ marginal - old arodseth 962855F072C7A01846405864FCF3C8CB5CF9C8D4 ~ marginal - new cbehan6EA3F3F3B9082632A9CBE931D53A0445B47A0DAB ~ marginal - old coderobe 54EB4D6DB209862C8945CACCED84945B35B2555C ~ marginal - current dbermond 3FFA6AB7B69AAE6CCA263DDE019A7474297D8577 ~ marginal - old djgera0F334D8698881578F65D2AE55ED514A45BD5C938 ~ marginal - old escondida CB33B736591A9CA06098A9A5FCAC9CF5A6EE1209 ~ marginal - old farseerfc 4B1DE545A801D4549BFD3FEF90CB3D62C13D4796 ~ marginal - old ibiru F4DDD6DDCEC320B665F502AAE8F18BA1615137BC ~ marginal - old jlichtblau38EDD1886756924E1224E49524E4CDB0013C2580 ~ marginal - current jsteel8742F7535E7B394A1B048163332C9C40F40D2072 ~ marginal - current juergen 355BDB97ED4724E6B3A450E7A3D9562A589874AB ~ marginal - old kgizdov 4BE61D684CB4E31741614E7089AA27231C530226 ~ marginal - old kkeen 48C3B1F30DDD0FE67E516D16396E3E25BAB142C1 ~ marginal - current maximbaz EB4F9E5A60D32232BB52150C12C87A28FEAC6B20 ~ marginal - old mtorromeo 2C118C620F02DB9AC1D0F9FA94DD2393DA2EE423 ~ marginal - old muflone C521846436D75A3294795B27B4360204B250F0D3 ~ marginal - old nicohood 97312D5EB9D7AE7D0BD4307351DAE9B7C1AE9161 ~ marginal - current spupykin 3E518BF2526FD1979E8AAE4965C110C1EA433FC7 ~ marginal - old tensor5 A9B6710D760F6617C530746EC847B6AEB0544167 ~ marginal - old thomasA314827C4E4250A204CE6E13284FC34C8E4B1A25 ~ marginal - old wild 0E87D6C3F9AF7FDED0C8588D22E3B67B4A86FDE7 ~ marginal - old xyne EC3CBE7F607D11E663149E811D1F0DC78F173680 ~ marginal - old ``` # Revoking "old" marginal trust keys Revoking these "old" keys is *very important* so that `keyringctl` properly assigns trust to the packager keys (no old key should be fully trusted or have marginal trust) and helps a lot in figuring out which keys need immediate attention going forward (because they are new or current keys!). As I have gotten mostly no reply from signing key holders in regards to this, I hereby ask Florian, Pierre and Levente to please revoke keys that need revoking [1] *now* and make sure that the revocation certificates are merged into the archlinux-keyring repository. The amount of open tickets is increasing and it makes working with the keyring more and more difficult if no action is taken! # Rebuilding packages of "old" marginal trust keys For some packager keys the process of rebuilding their packages has already been started more than four months ago [2], some of which are completed, but there are still some left [3][4][5]. I have checked the list of "old" marginal keys to see whether there are any packages in the repositories signed by them ([6]) and have created rebuild TODOs for any that needed them. # **IMPORTANT**: Rebuilding packages of "current" marginal trust keys If by Friday, 2022-07-15 20:00 CEST the marginal trust status of the "current" keys is not improved to fully trusted, the packages in the repositories signed by them will be rebuilt and a new version of archlinux-keyring will be released as soon as that is done (2022-07-16 or 2022-07-17 depending on availability). Help with any upcoming rebuilds will be very much appreciated! This means those "current" keys can not be used for packaging anymore. If you are the holder of an affected key or a main si
Configure mailing lists to automatically reject mails by non-members
Hi all, I'm currently partly moderating mailing lists for Arch Linux. Since we've switched to mailman3 I receive *a lot* of info from the system, that mails are being held in the moderation queue due to being sent by non-members of the respective lists. IMHO, we should configure all of our mailing lists to be subscription only (i.e. automatically reject all mail by non-members). It makes no sense for anyone to moderate these emails and is a huge waste of time for people dealing with the moderation of the lists (I get enough spam everyday as it is... ;-)). While at it: To my knowledge, we are currently still allowing HTML emails to be sent to the lists and I think those should be automatically rejected as well, as it is unnecessary bloat and is not fitting our context at all (we are not trying to click-track users on a commercial info list). Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Systemd service and timer for refreshing archlinux-keyring keys via WKD
Hi all, I currently have a MR open against archlinux-keyring [1], that adds a systemd service and timer, which would automatically refresh valid and existing keys on user systems. For people without access to the repository's ticket and merge request features, it is possible to browse the commits in question on the respective branch [2]. To quote from the accompanying ticket [3]: ``` For situations in which we do have new signatures which have been released, we may want a service on user systems that update existing keys via WKD to have an updated set of keys before updating archlinux-keyring. Rationale: Keys are updated in WKD after a release of archlinux-keyring (currently this is still done in the https://gitlab.archlinux.org/archlinux/wkd repo). User systems may upgrade any time after that and pacman will pull new keys from WKD automatically, however it will not pull updates for existing keys. Packages that are signed with a key that still had marginal trust in release A (and therefore already existed on the user system since release A) and gained full trust in release B will not be updated before the user does a system upgrade. This leads to the requirement of installing archlinux-keyring before doing a system upgrade, as otherwise the key will still have marginal trust on the user system and the signatures of other updated packages using the key in question will fail to validate. To remedy this situation I think it would be helpful to have a service update existing keys from WKD twice daily on a timer. I am not 100% sure whether this has side-effects in regards to revocations, but as we only ever update WKD after issuing a release and not when updating the default branch, this should be fine(?). ``` In short: The service in question will update any valid keys in the pacman keyring on user systems, that use Arch Linux's relevant domains as UID to retrieve updated keys (e.g. extended expiration, additional signatures). Invalid keys and those of other domains are ignored. This feature is implemented to circumvent (some, but not all) cases of "update archlinux-keyring before doing a system upgrade". Cases not covered are (in no particular order): * *long* outdated system is updated * new main signing key is required for a packager key to gain full trust for the packages about to be updated * local system's archlinux-keyring does not yet offer this feature * local system's pacman does not yet offer the feature of downloading package signatures for new keys from WKD * packager key on local system does not yet have any main key signatures and would gain full trust with an update of archlinux-keyring Currently the timer which triggers this service is supposed to be vendor enabled (i.e. symlink in /usr/lib/systemd/system/timers.target.wants/) and run daily with a deviation of up to 12h. Members of the DevOps team have raised concerns about the interval as we do not really have a clear picture about how many Arch Linux installations there are world-wide to get numbers on expected median load for this. If you have ideas for improvement or general questions, please direct them at the merge request. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/138 [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/tree/wkd_sync_service [3] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/184 -- https://sleepmap.de signature.asc Description: PGP signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 2022-07-23 21:24:38 (+0200), Kristian Klausen wrote: > The load aspect should be solvable, worst-case DevOps gets annoyed ;) > > My main concern is putting ourselves in a position, where we know > every arch installation, yes it is just the IP addresses, but still. > At the same time it becomes easier to detect that a computer is > running arch, by just look at the network traffic (yes you can already > do that today, by checking if the computer is connecting to a arch > mirror). > > Maybe I'm blowing it out of proportion, but with our user base being > more privacy aware than most people, I think it is worth mentioning. Fair point, however, a similar concern was networkmanager doing a connectivity check [1]. It is up to us to configure our webserver accordingly and be as privacy conserving as possible. E.g. If we wanted to track users (which we don't), we could do so on a rudimentary basis now already by tracking downloads of packager keys. The Web Key Directory is a way more centralistic approach than e.g. SKS was, but we also have better control over how and what we provide there. Best, David [1] https://github.com/archlinux/svntogit-packages/blob/8bdf9488f2845cad527945898b5cb045a263a073/trunk/PKGBUILD#L121-L125 -- https://sleepmap.de signature.asc Description: PGP signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 2022-07-23 23:49:09 (+0300), Evangelos Foutras wrote: > This is solvable by not cutting a release with marginally trusted > keys. Having all Arch Linux installations make 100-ish requests daily > to cover such an edge case is a misutilization of resources (on both > sides). Refreshing existing and valid keys not only has the upside of pulling in new signatures on marginally trusted keys, but also to update expiration dates. I do not see this as misutilization of the systems, as it solves an existing and continued issue for users and user experience by making the upgrade procedure less error-prone (and confusing). When it comes to utilization of our systems (because we would be on the giving end of this transaction), I do understand your concerns. The WKD is a very central and important resource to the distribution and we need to ensure (in any case), that we can serve many users at once and that this does not mess with our gitlab setup. If we could communicate more detailed numbers there and figure out a way to make the hosting of our WKD very stable and reliable, that would be fabulous! > I'm certain there are also privacy concerns about enabling this > service by default. Each upgrade of a user system may trigger a request towards our WKD (unrelated to the proposed service). As mentioned in my response to Kristian, I believe that it is up to us to configure our webserver infrastructure as privacy conserving as possible (for all of our services). > Furthermore, I doubt our users need to the have their systems babysat > like this. In the rare situation where archlinux-keyring must be > updated first, the user should be able to handle it by themselves. As > you said, pacman will fetch new keys using WKD so, as long as > marginally trusted keys are excluded from keyring releases, there's no > issue with onboarding new people. Marginally trusted keys may not only end up in the keyring by adding new packagers, but also by existing packagers changing their keys. As mentioned above, they may be (temporarily) expired as well. We are not really able to make the guarantees that you stated (e.g. "we will from now on only release fully trusted keys"). Scenarios such as emergency key revocations, or just plain oversight may still lead to marginally trusted keys ending up in the keyring. Establishing a workflow around the maintenance and release of archlinux-keyring is challenging in itself and changing it would not solve the problems with temporarily expiring keys either (unless we forbid expiring keys). Spending time on various fora to explain to users of all experience ranges to "first do a partial upgrade to upgrade the keyring" is not only tiring and creating friction, but also wasting a more valuable resource: Contributor time. The update procedure on Arch Linux should be as easy as possible and as resilient to failure as possible for as long as possible. Currently we have reports about this issue (for various reasons) every few weeks and those are only the users reporting these issues somewhere and are not those that want to upgrade their system after e.g. one year of downtime. > tl;dr: I'm vibing way more with continuing to rely on the > archlinux-keyring package exclusively; auto-updates are sus. I understand that. However, maintaining a keyring reliably over a longer period of time is non-trivial. If the implemented service is not wanted by users, it is always possible to disable the unit by masking it. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 2022-07-24 10:53:24 (-0700), Brett Cornwall wrote: > Just wanna point out that just because we already do something it > doesn't validate doing a similar thing. :) No. That was not the point I was trying to make. :) It serves as a good example as to why such a thing does not have to be a privacy disaster automatically. After all, we are already dealing with this scenario (hopefully in a successful way). > I'm fine with centralized WKD but only because of the absence of a > functional key trust network. I do think that auto-key-updates are > probably the wrong way forward as it sets a precedent of automatic > network connectivity in the base system. NetworkManager's connectivity > check can be argued is a core part of the software package in the same > way that Firefox's is. I agree with Debian/Ubuntu setting automatic > updates since it's a general-user-facing OS, but IMO Arch should > remain more hands-on and empower the user to do the right thing but > expect them to do it themselves. If there is no network connectivity available, there is no keyring update and there is also no package upgrade. To run Arch a user will likely (at some point) want to upgrade the system. FWIW, the use-case of automatically updating valid and existing keys to allow to upgrade the system normally is a different from automatically upgrading packages. Quite objectively it will be impossible to prevent less proficient or new users in the current setup to not run into an issue with our keyring and ask the same questions for the millionth time (or give up). This would all be fine as long as noone else had to care about this, but affected packagers and keyring maintainers *will be* contacted by those users. > I do agree that the current situation of upgrading a system with an > outdated keyring is annoying at best and very confusing at worst. Last > year I kept receiving emails months after my old key expiration date. This is indeed unfortunately quite common and I am sure I will be contacted many more times over the next few months myself. Sure, I could just start ignoring those messages, but that is neither nice nor does it prevent me from spending time on reading a message half-way to figure out that it has to do with this issue. ;-) IMHO, trying to solve this issue with the approach of upgrading the keyring first, is solving a technological problem with "tribal knowledge" (you just "have to know" that this is an issue with the most central and common of all actions on this operating system to not be affected). This does not scale and it creates friction for users and contributors. > What about a pacman flag that hooks into keyringctl so that the > upgrade command extends to e.g. pacman -Syuk? Much like how we don't > have automatic package list updates, we can expect the user to update > the key trust. If not integrated with pacman, why not just expect the > user to update keys via keyringctl as part of the normal upgrade > process? More useful error messages than "package may be invalid or > corrupt" could point the user to know where the issue is and how best > to solve it. > > Keep it simple. :) This may sound simple at first, but would in fact not be as trivial as one might think. The keyring provided by archlinux-keyring provides old keys (e.g. revoked by issuer or with revoked signatures) and keys (and UIDs!) using non archlinux.org domains. All of those need to be ignored as they are not relevant for (Arch Linux) packages and would lead to many more queries to our and the WKDs of others. To integrate a "sync all locally available keys before upgrade" functionality in pacman, it would need to implement a configurable(!) subsystem which implements the above filtering mechanism domain agnostic (as the package manager is used by others as well). Not saying that this can not be done (it is what the proposed service does standalone), but I know that this will likely not be trivial in the context of pacman and that I do not believe I would be able to write it myself. FTR: Keyringctl is currently very tightly integrated with archlinux-keyring (upstream). It is not really a user-facing application yet (there is no separate upstream for it) and serves the purpose of allowing us to manage the keyring in such a way that it can be maintained in a git repository as source of truth. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 2022-07-24 21:56:28 (+0200), Johannes Löthberg wrote: > I'm fine with it existing, and I would be fine with it being enabled > in a vendor preset, but I'm against it being statically enabled in > /usr. This is not something that's critical for the regular > functioning of the system, and so is not something I think users > should have to mask to get rid of rather than be able to just disable > it. At the time of writing only fwupd [1] and systemd [2] make use of systemd preset [3]. Could you elaborate on what you see as the fundamental difference (from a user's perspective) between `systemctl disable --now ` and `systemctl mask --now `? My reasons for the proposed vendor enabling would be: * we are the vendor * no complicated actions required in an .install file of archlinux-keyring to add a file to the administrative layer (/etc/systemd/) of a user system (if not using a systemd preset file) * the disabling of a default unit is obvious to the user (by the existence of the /dev/null symlink) * the unit's activation state survives damaging/removing the administration layer > But daily seems a bit frequent to me. Anything more frequent than > weekly feels too often to me, and even that feels a bit frequent. I have been looking at this issue from the perspective of "how can a user system gain (mostly) functional keys before upgrading?" by looking at these two scenarios: 1. "A key gains full trust and locally has marginal trust" 2. "A key's expiry date has been extended and is locally expired" In 1. the duration between release of a new keyring to [core] and release of a package that is signed by the now fully trusted key in any of our repositories can be minutes and therefore may even affect systems that are upgraded every few hours or once daily. With a daily timer we could eradicate the issue in this scenario with a rule of "only add packages signed with a key that gains full trust in a new version of archlinux-keyring after one day of its move to [core]" (that is still a big "if", as it relies on us doing the right thing). In 2. let's assume that the release of a new archlinux-keyring is made at least two days before expiry of the key (FWIW, we've had worse!). The *persistent* daily timer (e.g. also directly triggered after having the machine powered off for a longer while) would synchronize the keys very likely before a system upgrade can be attempted. Again, this assumes that we catch the expiry early enough (for which now there is a proposed fix available, thanks to Brett [4] - thanks again for working on that!) for systems being upgraded in short intervals (e.g. daily) and do not have to emergy rebuild someone's packages (which is usually also already too late for some users). Best, David [1] https://archlinux.org/packages/community/x86_64/fwupd/ [2] https://archlinux.org/packages/core/x86_64/systemd/ [3] https://man.archlinux.org/man/systemd.preset.5 [4] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/127 -- https://sleepmap.de signature.asc Description: PGP signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 2022-07-25 09:23:53 (+0100), Leonidas Spyropoulos wrote: > I'm aligning probably against such systemd unit. Mainly because or > privacy issues and given the options users will probably set something > like refresh every 1 hour and then we need to go into rate-limiting > just to keep our gitlab up. As mentioned in another mail [1], I believe that the privacy issues and the approach towards them do not differ from the existing setup with networkmanager and pacman querying the WKD for new keys before upgrade. On IRC a high load on the gitlab pages runner serving the WKD has been discussed. If this indeed affects the performance of gitlab (now already?), then gitlab pages is not the right tool to serve the WKD. Given that we still lack numbers on the current load and the to be expected future load, I'd suggest starting out with a longer interval than daily (e.g. weekly), although this will only solve the issues as discussed in my reply to Johannes [2] if we ensure, that packagers wait one week from gaining full trust to their first package release. Best, David [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/4JRPZCQZGKKN6I5LIA276WNBWWVMIOHD/ [2] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/KB3CB56NGY3YFVIQJTFSZOUVBONYUMWY/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 2022-07-24 12:23:29 (+1000), Allan McRae wrote: > Not shipping keys that are marginally trusted is ideal in principle... > However we have seen it many times recently as main/master keys were > cycled. Hopefully this is less of an issue moving forward. This is > why the keyring was set up to have five main keys, to ensure packager > keys were signed by at least 3 at all times. However, not everyone > has all five main key signatures. Or even 4. In fact, according to > the web page [1], we are screwed if anything happens to Pierre's of > Florian's keys, and to a lesser extent with other keys. I am not sure > the extent that page reflects current reality, but note Pierre's key > is schedule for retirement... The likelyhood for a packager to have three signatures or more (fast) has not been very high over the past year. However, the website is also only showing the signatures correctly, if any given packager setup their current (e.g. new) key in their archweb profile. As notified about earlier [a][b] this is currently not the case and renders the overview a bit useless. Tbh, it would make more sense to automate the population of that subpage and make it completely unreliant on user input, as packagers may have more than one key at a given time. For figuring out current trust (in the yet unreleased keyring), it is possible to list keys with given trust level using `./keyringctl` (see e.g. `./keyringctl list -h`) in the archlinux-keyring repository. > (Is it correct that Giancarlo has signed zero keys? I thought they > were bought on to replace me almost a year ago!) > > [1] https://archlinux.org/master-keys/ Unfortunately yes. I have asked about this probably a dozen times and given up due to lack of action by now. > My conclusion is the reality of the keyring is not perfect. If all > packager keys were signed by all main key holders, and WKD was updated > before packages were released using a key, and if expiry dates were > extended at least 6 months in advance, and , then this would not > be an issue. That is a lot of "ifs" :) > David has put a lot of effort into the keyring to allow us to expose > these issues more easily, and has been pushing for main key holders to > increase their signing coverage, but this has not progressed at any > great rate. The service suggestion really works around limitations in > key signing activity. It would not be needed if main key holders > signed everything and packagers with keys that expire updated their > keys with extensive notice. > > > Onto the service. If the server load and privacy issues were not > issues, this would "solve" the problems above. Daily is probably too > often, even weekly/monthly would be fine. But I guess the concerns > raised mean we should focus on fixing the keyring instead (as futile > as that may seem to David currently...). After reading some of the responses (e.g. Brett's [c] and Filipe's [d]) it might make indeed more sense to envision a system in which we grab updated keys (if we need them) using pacman upon system upgrade (I guess this action can not be paired with that of pulling new keys though as that happens upon package validation AFAIK). This would lower the amount of requests significantly if no update is needed (i.e. only one HTTP request is needed to retrieve a timestamp file) and only update keys if there is a new version of the keyring data deployed to WKD (e.g. timestamp is newer, we are synchronizing the existing keys). Even if we went with the service, a timestamp file would make sense there as well. As mentioned in my reply to Brett [e] I am not sure how to achieve that in the context of pacman and I do see a configuration overhead there that needs addressing, but if you could point me in the right direction, I might be able to figure it out! :) Best, David [a] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/PID6TWOVFPDAHEVA6BWVHEVSQCBHFTHH/ [b] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/DZTBYV5QO7T3MNEAUGQCESXQAWSNITOW/ [c] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/PJ27YL4ORPEUC4PVIJOH2VYITQMXHJZ5/ [d] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/E5WU5JLOXIZKFMRTUL7ZPWBLN7LPSVE3/ [e] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/TGC6DREVVGTRHK5ZAZFO4F54SZIQ4KV4/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: Configure mailing lists to automatically reject mails by non-members
Hi all, On 2022-07-21 10:15:12 (+0200), David Runge wrote: > I'm currently partly moderating mailing lists for Arch Linux. > Since we've switched to mailman3 I receive *a lot* of info from the > system, that mails are being held in the moderation queue due to being > sent by non-members of the respective lists. > > IMHO, we should configure all of our mailing lists to be subscription > only (i.e. automatically reject all mail by non-members). It makes no > sense for anyone to moderate these emails and is a huge waste of time > for people dealing with the moderation of the lists (I get enough spam > everyday as it is... ;-)). > > While at it: To my knowledge, we are currently still allowing HTML > emails to be sent to the lists and I think those should be automatically > rejected as well, as it is unnecessary bloat and is not fitting our > context at all (we are not trying to click-track users on a commercial > info list). There has not been anything but positive feedback and no further feedback in a few weeks. I conclude that people agree and changes the mailing lists setup to automatically drop mails by non-list-members and to reject those sent with mime/htmlwill be implemented soon in the infrastructure repository. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Configure mailing lists to automatically reject mails by non-members
On 2022-08-09 09:43:49 (+0200), Morten Linderud wrote: > I have one exception I'd like us to make regarding auto rejection. > > Historically the aur-requests list has not required subscription to > reply. At some point this was removed and I think it's unreasonable > for AUR maintainers to subscribe to the high traffic aur-requests just > so they can reply to emails. > > It also decreases the value for having the list in the first place if > people don't bother to reply to the requests they are being emailed. I see that being a problem going forward, as it requires manual intervention by a moderator if things go wrong (e.g. spam), but I also see the issue with the signup for that mailing list. Not really sure how to solve that without wasting people hours on it though :S I'd be fine having it non-signup, but I also wouldn't want to do moderation for that list then tbh. Either way: I guess we need to update our documentation in regards to this in the wiki and also in the respective list overview pages so that people are instructed to sign up (if they have not done so already). Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: TU resignation
On 2022-08-09 12:16:26 (+0900), Nicola Squartini wrote: > Dear all, > > Due to my involvement in other projects I'm unable to dedicate the time it > deserves to Arch Linux, therefore I decided to resign from my role of > Trusted User. > > I thank György Balló for sponsoring me 6 years ago, and everybody else who > supported me during this time. It's been an honor and pleasure for me > working with you. > > Best regards, > Nicola Hi Nicola, I'm sorry to hear that you have decided to resign. I do understand that priorities change over time and would like to extend my thanks for your involvement with Arch Linux for the past years. Please make sure to answer to this mail with a signed mail using your fully trusted packager key with the ID A667E8A1B61D07A50FC430DF69DF1F2EB44B05BE. Your current mail has not been signed. Please also make sure to follow the following workflow, so that we can work towards rebuilding your packages and revoking the signatures on your key: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/remove-a-packager-key Best, David -- https://sleepmap.de signature.asc Description: PGP signature
repod 0.2.0 release - call for testing and participation
Hi all, I've just released repod 0.2.0 [1] (it is available as "repod" in our repositories). There are some significant changes in this release which allow for rudimentary handling of binary package repositories in configurable directory structures. For further information please refer to the documentation [2]. I would like to take the time and invite *everyone* (people involved with any distribution making use of pacman as well as their users - especially those with private package repositories) to participate in testing and improving repod. The project is actively maintained (although admittedly currently I am the main developer working on it and additional contributions - although present and valuable - are rare) and does bi-weekly meetings. Repod aims at generically offering the ability to maintain binary package repositories of alpm based packages. As such it transcends Arch Linux as its only client - the software is meant for Arch Linux, downstream distributions and private users alike! TL;DR: Please help the development of repod and associated tooling as it is important for all pacman based distributions and their users. Historically we have had quite a few distribution driven projects which allow us to do the things we do today (e.g. mkinitcpio, archiso, archweb, aurweb, dbscripts, arch-install-scripts, devtools, etc.). All of them have in common, that they lack dedicated development from time to time or are so large/old/deep that they require more than one person to "have the hat on". This being said: I do not feel comfortable being the only/ main person currently developing repod. The project is entwined with our pursuit of moving our packaging infrastructure to a more modern, git based setup in which package sources are separated from the binary packages that are built from them (opposite to how it is currently handled with dbscripts). This process is a gradual one in which we try to decouple the source repositories from the binary package repository state, while offering certain stability guarantees when consuming and handling packages. Upcoming work will entail dealing with necessary checks required for basic movement operations, which will consolidate a lot of (partially unused) code in the dbscripts project. For a more detailed overview for further topics, please have a look at the milestones [3]. Working on the upcoming features could use many more eyes and helping hands! Another piece of the puzzle when looking at moving to a git based workflow and improving our tooling, is the automation for builds/rebuilds (the road between our package source repositories and the binary package repository management software - e.g. repod). For this some solutions exist, some of which are VCS agnostic and some of which we use in larger rebuilds all the time. Morten has started to look at a buildbot based system which could be used for rebuild scenarios and also for building different architectures in the future. To my knowledge this is still very much a WIP, but if you are interested, idle in #archlinux-projects on libera.chat to get exposed to more information (this is also the case for repod btw!). I hope I was able to give a brief overview of what is the current state of things, where we want to go from here and spark some enthusiam about the above projects. There is still a lot of work left to be done for us and any help is much appreciated! :) Best, David [1] https://gitlab.archlinux.org/archlinux/repod/-/tags/0.2.0 [2] https://repod.archilnux.page [3] https://gitlab.archlinux.org/archlinux/repod/-/milestones -- https://sleepmap.de signature.asc Description: PGP signature
Re: New main key holder (replace Giancarlo)
Hi all, On 2022-09-06 22:06:12 (+0200), Levente Polyak wrote: > Therefore I'm proposing we replace Giancarlo's key and pass on the > duties to Johannes. I'd be happy for us to gain another functional main signing key, which is much needed to arrive at a setup in which we are resilient towards problems and have sufficient failover keys. @Johannes: Please start the process of adding a new main key [1] once you have gotten an additional hardware token for the key and found a revoker for it :) Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/add-a-new-main-key -- https://sleepmap.de signature.asc Description: PGP signature
Discussion around archlinux-keyring and pacman-key
Hi all, I've started a discussion [1] around a potential improvement for dealing with archlinux-keyring and pacman-key. Lately we have been facing quite a few issues (e.g. initialization and ordering issues in archiso and arch-boxes) again, that emerge from how gnupg is used in the context of pacman-key. The discussion linked to above is a bit more midterm in regards to what the proposed idea represents, but it tries to draw out a possible scenario of using key data in the future. When looking at pacman-key I noticed, that it does not do locking of the gnupg keyring data [2]. This means, that in environments in which we bootstrap the system (e.g. archiso/arch-boxes) we may run into inconsistent state if we use pacman too early, or generally if we modify the keyring concurrently. Unfortunately, (to my knowledge) there is no way of telling when is "too early" or whether we are already using the keyring, due to the missing locking mechanism. In the past days there have also been a multitude of reports of people with keyring issues on reddit. While some of theme have been due to initialization issues in archiso with pacman < 6.0.1-8, there is apparently also a set of issues on existing systems where it is unclear why pacman-key would have issues validating keys that are already present on the user system (trying to get more info from the users). Overall this is a bit worrying and I think we should work towards addressing the problem that we have with signing and verifying packages. The discussion in archlinux-keyring is only one possible solution, others are implementing a locking mechanism (;_;) or working towards a signing enclave for our packages and databases to minimize the keys in use. IMHO, removing the use of gnupg as proposed in the linked discussion could reduce complexity quite a bit, but it of course also requires implementation in archlinux-keyring and pacman. I'd be happy to get more input and thoughts on this entire topic. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/199 [2] https://gitlab.archlinux.org/pacman/pacman/-/blob/546433b4fd8a3ede5d04d56b3d07ab9f671c0f89/scripts/pacman-key.sh.in#L238 -- https://sleepmap.de signature.asc Description: PGP signature
[core] cleanup
Hi all, we need to do a bit of [core] repository cleanup. In this MD [1] (publicly visible readonly link [2]) we have a list of packages that should leave [core], some maybes that need discussion before moving them and some that should be moved to [core] from the other repositories. If you have more packages, that should not be in [core] anymore or should be moved to it, please add them to the list(s). The general rules for inclusion in [core] are, that we want to - preserve base-devel as a group there - preserve base as a meta-package there - preserve makedepends and depends of a [core] package there The checkdepends and also optdepends of a package may reside in other repositories. As we have a few removals of packages in the list that concern packages only in [core] for historical (or other) reasons, please keep the discussion about them focused on technical reasons as to why they should potentially remain there. Additionally, we have a few orphan packages in [core] that need adoption. Please adopt packages (if you can)! Best, David [1] https://md.archlinux.org/nrXL0ay5Tp6wP-f5M7N8bA# [2] https://md.archlinux.org/s/MliseALTG# -- https://sleepmap.de signature.asc Description: PGP signature
Re: [core] cleanup
On 2022-10-11 13:00:57 (+0200), Levente Polyak wrote: > I'm actually currently working on moving it to a meta-package as well. > We didn't do it when introducing `base` as we never really changed it. > Now we did with debugedit and face small inconveniences and we are > better of to have it as meta-package as well. Sounds good. While looking at base-devel I also noticed that e.g. fakeroot is in there, but it should actually be a dependency of pacman (as makepkg uses it) and opened a ticket for it [1]. > makedepends doesn't actually matter, similar how checkdepends doesn't > matter. Our builders always have the full repository set available > (minus multilib). We only need to consider runtime depends. Ah, that's an oversight on my part. All the better! Best, David [1] https://bugs.archlinux.org/task/76171 -- https://sleepmap.de signature.asc Description: PGP signature
Re: [core] cleanup
Hey Tobias, On 2022-10-11 12:53:25 (+0200), Tobias Powalowski wrote: > here my short additions: > - syslinux: > is dead and not used in our projects anymore I added it to the list. Syslinux itself is still somewhat useful if one doesn't want to deal with grub on legacy boot systems. > - nano vs. vi > one editor could be enough, I can live with both. I'd argue neither needs to be in core. However, nano at least is still somewhat maintained. > - reiserfsprogs: > dead/abandoned filesystem could be moved out or removed Now that my misunderstanding about makedepends has been cleared up, I guess it can just be added to the list (it is make and optdepends of btrfs-progs). Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [core] cleanup
On 2022-10-11 16:30:42 (+0200), Andreas Radke wrote: > How comes? Nano is actually pretty well maintained and has seen lots > of updates over the past years. See Yep, that's why I wrote, that it is at least still somewhat maintained (vi does not seem like it). :) My rationale would be, that text editors are not necessarily required for a working system and are rather basic tools (and one can argue endlessly which is the best hammer I guess :D). > If we want an editor in core beside "ed" at all is a different > question. Even ed is questionable, as it is only really required for `patch -e` (as optdepends) in [core] it seems. I have never seen a PKGBUILD make use of that. > In the past there was a rule to get a basic but usable system up with > base group and core repo (=cd iso image). On the installation medium we are able to define an arbitrary list of packages. For a long time the editor of choice seems to have been vim. Do you have a link to anything that was decided by the Arch Devs on the topic of what should be in [core] in the past? I guess I should have looked for that first, but I'm not aware of anything specific in the wiki at least. My rationale for slimming down [core] is to only have things in there that are required for running the most minimal Arch system and for building packages. > Vi is still part of Posix standard: > https://pubs.opengroup.org/onlinepubs/9699919799/ However, [core] does not cover all of the POSIX Shell & Utilities (e.g. looking at batch, asa, bc, etc.). Are we even committed to cover POSIX Shell & Utility compat in [core]? Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [core] cleanup
On 2022-10-12 11:29:52 (+1000), Allan McRae wrote: > On 11/10/22 21:00, Levente Polyak wrote: > > On 10/11/22 12:05, David Runge wrote: > > > - preserve base-devel as a group there > > > > makedepends doesn't actually matter, similar how checkdepends doesn't > > matter. Our builders always have the full repository set available > > (minus multilib). We only need to consider runtime depends. > > I would argue that makedepends and checkdepends do matter from a testing > perspective. If we have [core] defined at essential packages to bootstrap > a system, build time dependencies remain important and should go through > testing. > > Of course that depends on our definition of [core]... I like the above > definition, as it reflects the history of our distro starting from Linux > From Scratch, and the build dependencies for things in [core] are fairly > fundamental to things outside core too (e.g. meson) and deserve enforced > [testing]. > > It also serves us well as more architectures happen - that would make [core] > a self contained start point for bootstrapping an architecture. If we look at it from a bootstrap perspective, then it would indeed be good to become self-contained in regards to makedepends and maybe also checkdepends (more overhead though). I agree, that this should encompass build tools used for the packages in core (such as meson) in the future in regards to "going through testing", but I would not want all the build tools in there (e.g. cmake, waf, scons, whathaveyou), if they are not required by packages in [core]. This breaks with the above base-devel assumption in case we ever want to add all the build tools to it. However adding build tools in general also drags in its own kitchen sink, and I understand why the rather small group of developers might not be fond of this. > In summary, we need to define what it is we are trying to achieve with > [core]. Hm, we could create an RFC for evaluating and defining this better. It seems, that people have very different ideas and opinions about what should be in core and what not :) Maybe this would also provide a better overview to what proposed changes would actually mean in terms of added packages etc. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Arch Linux software projects: Request for participation
Hi all, we have recently cleaned up parts of the developer wiki a bit and moved the list of internal projects to a more prominent location: https://wiki.archlinux.org/title/Getting_involved#Software_projects As you can see, we have quite a few projects and some of them would be happy about more participation from members of the Arch Linux staff as well as users. Help in fixing and extending the software is much appreciated, but testing and opening tickets that describe flaws or usability problems are equally important! If you are familiar with writing documentation, Ash, Bash, C, JavaScript, Python, or Rust and always wanted to get involved with one of the Arch Linux projects: Look no further! :) As mentioned in the wiki, we have a central mailing list [1] and IRC channel [2] for discussing most of the projects (unless they provide other means of communication). We hope to spark people's enthusiasm, as healthy projects ensure a flexible distribution and allow us to tackle larger goals (e.g. move to a git based workflow for packaging, effortlessly providing several architectures, automating our infrastructure and releases, etc.). Best, David [1] https://lists.archlinux.org/mailman3/lists/arch-projects.lists.archlinux.org/ [2] ircs://irc.libera.chat/archlinux-projects -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] openssl 3.0
On 2022-11-01 18:27:23 (+0100), Pierre Schmitz wrote:
> I updated to 3.0.7 in staging. I had libprovides in my branch. Do you
> guys think this might be handy to define versioned dependencies when
> we have potentially three different openssl verions to maintain?
>
> provides=('libcrypto.so' 'libssl.so')
Always a fan! Please add! :)
> At the same time 1.1.1s was released which mainly fixes a regression
> from 1.1.1r (we are on 1.1.q). Do you guys think it is worth to
> release that 1.1.1 update in the meantime?
If it is not critical, maybe better to let the openssl 3 rebuild roll
through.
Best,
David
--
https://sleepmap.de
signature.asc
Description: PGP signature
Realtime kernels moved to [extra]
Hi all, today I have moved the realtime kernels to [extra]: https://archlinux.org/packages/extra/x86_64/linux-rt/ https://archlinux.org/packages/extra/x86_64/linux-rt-lts/ I have been maintaining these kernels in the AUR via a custom repository [1] for a couple of years now and believe that quit a few people actually make use of them (in various contexts). The effort to get the realtime kernel patchset [2] merged in its entirety has been going on for about 15 years already and the patchset is shrinking with every kernel release. In the future users will be able to configur the kernel build without a separate patchset. That all being as it is, historically there have been two repositories tracking the ongoing work: One for the work on the most recent Linux versions, while the other tracks all LTS branches that are supported. I am intending to follow both the most recent and the highest LTS version, while consolidating with core/linux and core/linux-lts wherever it makes sense. For that purpose we have moved the kernel repositories (with distribution specific patches), mirroring their respective upstream to: https://gitlab.archlinux.org/archlinux/packaging/upstream/linux-rt https://gitlab.archlinux.org/archlinux/packaging/upstream/linux-rt-lts This allows for easy collaboration and cherry-picking of patches (which I do currently already for linux-rt, using core/linux) and my hopes are, that the knowlegde in our developer and packager team grows in how to configure kernel builds and maintain the packages. The https://gitlab.archlinux.org/archlinux/packaging/upstream/ group location is meant for all projects that have to maintain custom patches on top of what upstream does (that is also why shadow lives there currently). In case there are developers or package maintainers interested in collaborating on the builds and maintenance of the kernels, please reach out! Best, David [1] https://pkgbuild.com/~dvzrv/repos/realtime/x86_64/ [2] https://wiki.archlinux.org/title/Realtime_kernel_patchset -- https://sleepmap.de signature.asc Description: PGP signature
Re: Updating ruby package guideline to only build gems and extensions once
On 2022-11-06 13:53:51 (+0100), Andreas 'Segaja' Schleifer wrote:
> Recently Felix found a way to only build the gem and possible extensions
> once and use them for both testing and packaging.
>
> To reflect these changes I would propose that we update our ruby package
> guidelines with the new way that Felix found.
Hi Andreas,
Thanks for investigating further and staying on top of it! Simplifying
the guidelines is immensely helpful to anyone trying to package Ruby
packages on Arch.
I took the initiative and already added the ruby-rspec change to the
"Build and test" section.
AFAICT, the new "Template" section looks alright!
To not generate a huge changeset, I guess we can bit by bit adapt the
"Gem based build" to match yours, then remove the "Rake based build",
move the contents of "Gem based build" to its parent heading
("Template") and add the "Gotchas" subsections below a "Tips and tricks"
section.
If you need help, let me know and thanks again for further looking into
this and keeping up with the documentation!
Best,
David
--
https://sleepmap.de
signature.asc
Description: PGP signature
Re: Archiving all package sources
On 2022-11-13 17:42:27 (+0100), Jelle van der Waa wrote: > For packaging we now rely on external parties to keep the source code > hosted which can be a problem and some packagers want to search > through all our packages code. [1] > > Currently we already archive sources using `sourceballs` on > repos.archlinux.org for GPL licensed packages, this is limited to a > subset of all packages and done after the fact (A timer which runs > every 8 hours and part of dbscripts). sourceballs calls `makepkg > --nocolor --allsource --ignorearch --skippgpcheck`. This can be a > problem as it runs after the package has been committed and it other > network issues which might occur specific to the server. (ie. source > cannot be downloaded where server is hosted) I believe it would be good if the build tooling would take care of this instead and release the source tarballs to the repository management software (alongside the packages). > To make this more robust, when committing a package using communitypkg > or equivalent we also rsync the sources to a location on > repos.archlinux.org (Gemini). This means the sources are consistent, > and this opens the ability to implement a fallback or to change > devtools to look at our sources archive when building a package. That > would benefit reproducible builds as well and automated rebuilds. > > Searching through our source code would be a next nice to have, most > solutions such as sourcegraph/hound require a Git repository. [3] [4] > So maybe we can hack up a repository which just git adds all directories and > keeps one git commit? That should probably be not too much of a waste. But > the first proposal is to first archive all our code in a way it can be > consumed by a search solution. If I understand this correctly, you would want to add the sources (upstream and our additions for the build) of each package to one repository, or each to their own? The creation of e.g. a git repository to store the (upstream and maybe our) sources of a package I would also see on the side of the tooling creating packages and uploading artifacts to $place for releasing. As the upstream tarballs contained in the source tarball that makepkg creates are (hopefully) versioned and if we think of adding their contents to a git repository, we need to come up with a clever solution on how to deal with the changes over time. But I'm not 100% sure I understood the idea for the creation of the repository yet. > Questions: > > * How do we deal with archiving patches, PKGBUILD's etc. for GPL compliance > (just save it next to the code?) > * How do we determine when sources can be removed / cleaned up (we can't > store things forever). DBscripts hooks? > * Do we have enough disk space for archiving? An additional question I would like to add to your set of questions is: What do we do with e.g. binary only upstreams (we have a few) for which we would not want to create source repos or exclude the binary blobs? As a sidenote: For repod I have just implemented the first basic (configurable) archiving functionality for successfully added packages: https://gitlab.archlinux.org/archlinux/repod/-/merge_requests/137 This does not yet extend towards source tarballs, as they are not created by repod (also source tarballs are currently still a bit of a backburner topic), and IMHO also should not be created by it in the future either, but rather by the tooling that built and pushes the artifacts into it. FWIW, this initial functionality also does not yet concern itself with any cleanup scenario of the archived files, but with being (in structure) compatible with dbscripts. When looking at (in the future) decoupling the building of source tarballs from the software maintaining the package and source artifacts (repod in that case), this still leaves us with a scenario in which we need to deal with cleanup of archive directories (e.g. upload to internet archive for long-term storage). I see some overlap with what repod's goals are in the questions you are bringing forward and it would be great if we could sync up on that during the next repod meeting if you have time. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Archiving all package sources
On 2022-11-13 21:17:29 (+0100), Jelle van der Waa wrote: > https://sources.archlinux.org/sources/$pkgbase/whatever.tar.gz > > They are versioned, example: > > -rw-r--r-- 1 sourceballs sourceballs 49M May 22 13:42 > zynaddsubfx-3.0.6-3.src.tar.gz > So I never said I wanted the archive in a Git repo, it might be > required for search but that's the next step. So for now binary > sources are just as normal as source tarballs. I see. I guess I misunderstood this, as you brought up the search tooling (which is super helpful btw and I often use your hound to search for things in PKGBUILDs). > I am not sure if this fits into repod and should. However, I'm happy > to discuss it in the next meeting, when is it? As mentioned in my last mail, the source tarball consumption feature is pretty much on the backburner at the moment. However, if we indeed have our build infrastructure/ build tooling generate the source tarballs in the future, we'll eventually want to tackle consumption of these artifacts I guess. Exposing the source tarballs of the current repository packages (as outlined in your examples above) could easily be a configurable thing (like many other features [1]). The next meeting is next week Wednesday [2]. Best, David [1] https://repod.archlinux.page/repod/man/repod_conf.html [2] https://lists.archlinux.org/archives/list/arch-proje...@lists.archlinux.org/thread/BQFBH33YG3IDPFZKU3ERTITUB6GE3ZLD/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: Virtual package naming
On 2022-11-28 23:19:09 (+0100), Jan Alexander Steffens (heftig) wrote: > Hello list, > > We're planning to make PipeWire the default PulseAudio sound server, and > for that we need to change some dependencies around. Notably, we want a > virtual "pulseaudio server" package that is fulfilled by both > pipewire-pulse and pulseaudio, with preference for the former. > > However, we weren't sure what to name it. We don't seem to have a > consistent naming scheme for virtual packages besides soprovides > (libfoo.so). Most virtual packages look like normal ones (e.g. > java-runtime, d-compiler). > > Some packages use SCREAMING-KEBAB-CASE to clearly separate "virtual" from > "normal" dependencies (e.g. WIREGUARD-MODULE), which makes their weirdness > (pacman -Si fails) less surprising. I'm not sure that's a pattern we want > to continue, but I still would like a consistent scheme. > > Looking forward to your input, > Jan Hi Jan, I'd be happy to see a more stream-lined approach here, that identifies the virtual dependencies for what they are. E.g. prefixed by a "virtual-" or "virtual@" string. In regards to the existing all-caps virtual provides/dependencies, it would be nice to change them to comply with our current guidelines on package naming [1]. That way they will get easier to parse (no extra rules required) and validate, which is currently still an issue when it comes to validation of package relations (i.e. provides, depends, optdepends, makedepends) in repod [2]. Best, David [1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_naming [2] https://gitlab.archlinux.org/archlinux/repod/-/issues/10 -- https://sleepmap.de signature.asc Description: PGP signature
Re: Upcoming PHP 8.2 update and introduction of legacy packages
On 2022-12-20 10:00:09 (+0100), Pierre Schmitz wrote: > The rebuild for modules and anything that links against PHP went quite > well and I have moved the packages into [testing]. Even uwsgi did > build with a simple patch. I did notice that this project is in > maintenance mode according to upstream; so I am not that optimistic we > can provide the PHP plugin in future. Yep :( That upstream is in a sad state unfortunately. I would be happy to see more extensive documentation on php-fpm in the wiki (and also upstream). Currently, the state of documentation is quite terrible around this (default) integration. :S > One of the special cases is probably nextcloud with its version check. > I'd suggest to use php-legacy here is this will always point to a > version that is supported by upstream. Please rebuild nextcloud packages and see if they work before moving php to outside of staging. This is what I introduced the php-interpreter virtual provides for! :) Package builds should fail right away in check() if it is not compatible. I think we will need to do an adjustment to the clamping code that Caleb introduced a while back though, as it still relies on the "php7" binary, but should instead rely on "php-legacy" instead now I guess. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Upcoming PHP 8.2 update and introduction of legacy packages
On 2022-12-20 11:09:15 (+0100), Pierre Schmitz wrote: > On Tue, Dec 20, 2022 at 10:44 AM Pierre Schmitz wrote: > >(I can do the required changes if you like) > > As some code is probably easier to talk about here is my idea in patch > from: https://gist.github.com/pierres/227602544b54a1b027471b6ccdab36c1 Hm, I'm not so happy about this removing the checks and hardcoding php-legacy though. With the current approach users can at least choose and we get more feedback during build of the package. Plus, this is supposed to work with automatic rebuilds (e.g. when bumping the interpreter(s)), which IMHO is quite desirable. I can look into fixing it later today. -- https://sleepmap.de signature.asc Description: PGP signature
Re: RFC - thoughts about Arch and init freedom?
On 2022-12-16 22:46:12 (+0100), Andreas Radke wrote: > Nowadays systemd has become much more than a plain init system > and plans to grow further. This may leadd to problems from a user and > system administrator perspective once you are hit by some bug. Systemd > as a whole thing doesn't care about the Unix philosophy to do only one > thing but well. > > Many and often highly skilled users left and leave Arch therefor or > choose some different distribution or an Arch fork because there's no > init choice in Arch Linux. The statements here are quite vague and as others have already commented on their accuracy I will abstain from going into that. What I'm missing: What specific problem do you intend to solve (how) and what are the numbers backing the other claims (e.g. users leaving, bringing back lost parts of the community, better portability)? > I suggest to fix this lack of init choice/alternative. I'd like to > implement it into the official Arch Linux repos allowing to choose > some different init replacement. We can either just add a 2nd init > system in the most simple way or allow real init-freedom[3] offering > full choice and leave it up to be further filled by the community. Frankly, I believe this work would not justify the gain but instead complicate things (e.g. writing of unit files, support, etc.) and introduce overhead for package maintainers. > Arch Linux could take advantage of this bringing back some lost parts > of the community. With more choice and better portability Arch could > become a better base for porting to new architectures. And freedom and > alternatives is always good in the open source world. The clear > drawback would become some added complexity allowing to choose either > systemd or its replacement parts and to make all of them to work with > existing packages especially daemon services. The porting to other architectures does not depend on what init system we are using (FWIW, I think systemd is quite flexible there), but rather our own distribution tooling. There are ongoing efforts to improve our tooling (e.g. dbscripts [1], devtools [2], keyringctl [3], repod [4], archlinux-buildbot [5], arch-release-promotion [6]), so that we can have a more flexible approach to (mass) rebuilding and releasing packages and artifacts. If you intend to support more architectures, the above are a must and something that needs to see more attention from all of us (however, currently these efforts are - on a very good day - led by less than a handful of people). I consider time on our distribution tooling more wisely spent than losing ourselves in a dogmatic approach to what PID1 is or should be. Best, David [1] https://gitlab.archlinux.org/archlinux/dbscripts [2] https://gitlab.archlinux.org/archlinux/devtools [3] https://gitlab.archlinux.org/archlinux/keyringctl [4] https://gitlab.archlinux.org/archlinux/repod [5] https://gitlab.archlinux.org/foxboron/archlinux-buildbot [6] https://gitlab.archlinux.org/archlinux/arch-release-promotion -- https://sleepmap.de signature.asc Description: PGP signature
Re: Git packaging sources: state of the art
On 2023-01-08 12:13:36 (+0100), Jelle van der Waa wrote: > On 05/01/2023 23:15, Levente Polyak wrote: > > # Introduction > > > > Behold, ~~winter~~ Git is coming. We've been working on and off to get > > Git packaging sources ready for a while now. Today I'd like to outline > > the final proposal regarding the action plan, workflow, tooling and also > > the reason for a couple of decisions. Consider this as a late xmas gift > > to our distro 🎁😻 First of all: I'm very excited this is finally happening! 🥳 > I'm looking into the Archweb changes for Git packaging support, at least > linking to the urls should be easier. But what do we do with kde-unstable, > gnome-unstable? I believe that kde-unstable is now a branch next of trunk? > Or a separate branch? [1] > > I'm actually not 100% sure how in Git packaging we handle > [testing]/[community] now. As far as I can see it will be a linear history. > > So I commit something to [community-testing], we tag it. I won't be able to > update [community] unless I bump both. Which honestly makes me wonder if we > should ideally just use branches in our Git packaging repo for community, > community-testing. > > [1] https://github.com/archlinux/archweb/issues/438 @jelle Maybe I misunderstand your last paragraph, but isn't this the case currently already? I think dbscripts will prevent you from updating the stable repository (e.g. extra), if any of the other stability layers (staging or testing) would then have the package in a version lower than the one you're trying to add. It is always staging > testing > stable. On IRC we have been writing a bit about how to make links to the package sources on our GitLab available in archweb (we need to implement the translation of version string to git tag string). As repod will need similar functionality for source verification purposes in the future, I sketched out the functionality in a small lib here: https://gitlab.archlinux.org/dvzrv/archlinux-version-tag-conversion/ Admittedly, it is not a lot of code and we could also consider having it in each application directly, but maybe we'll find more functionality for a shared library, that could go there. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Upcoming PHP 8.2 update and introduction of legacy packages
On 2022-12-20 11:49:28 (+0100), Pierre Schmitz wrote: > On Tue, Dec 20, 2022 at 11:25 AM David Runge wrote: > > Hm, I'm not so happy about this removing the checks and hardcoding > > php-legacy though. > > The check is done by calling versioncheck.php directly as it fails > when version constraints are not met. > > You are correct, if we want users to be able to use both PHP packages > we cannot hard-code it. On the other hand, the current solution hard > codes it during build time. This means users cannot switch to another > compatible PHP version without rebuilding the package. We should also > be aware that using this approach might unexpectedly change the > dependencies. E.g. if you build nextcloud today it will depend on > php-legacy. If you build it in 6 month it might depend on the regular > php package. When this happens, users might need to update their > php.ini, web server and systemd services configuration. > > But I do not mind much; in the end its a trade-off between complexity > and choice. > > > With the current approach users can at least choose and we get more > > feedback during build of the package. > > Plus, this is supposed to work with automatic rebuilds (e.g. when > > bumping the interpreter(s)), which IMHO is quite desirable. > > > > I can look into fixing it later today. There has been a problem [1] introduced by not renaming the soname of libphp-legacy.so. The soname was still libphp.so, so linking against libphp-legacy.so led to dependents requiring libphp.so instead (this was also the case for the apache plugin btw). This should have been tested more thoroughly and it took me some time to figure out what was going wrong yesterday. A patched php-legacy is in [testing] though. Meanwhile, there still seem to be issues with uwsgi-plugin-php-legacy and it would be great, if you could help solve them, since this is broken after switching to php-legacy. Best, David [1] https://bugs.archlinux.org/task/77124 -- https://sleepmap.de signature.asc Description: PGP signature
Re: Upcoming PHP 8.2 update and introduction of legacy packages
On 2023-01-15 12:25:36 (+0100), David Runge wrote: > There has been a problem [1] introduced by not renaming the soname of > libphp-legacy.so. The soname was still libphp.so, so linking against > libphp-legacy.so led to dependents requiring libphp.so instead (this was > also the case for the apache plugin btw). > This should have been tested more thoroughly and it took me some time to > figure out what was going wrong yesterday. A patched php-legacy is in > [testing] though. > > Meanwhile, there still seem to be issues with uwsgi-plugin-php-legacy > and it would be great, if you could help solve them, since this is > broken after switching to php-legacy. I would really appreciate if there was feedback on this issue from your side. The move to stable was (as you mentioned yourself) a potential breaking change. Doing this on a Friday and then not being available to fix potential breakage is not cool. Currently everyone relying on uwsgi + php-legacy is affected by this. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
squashfs-tools 4.6 dropped from testing
Hi all, squashfs-tools 4.6 has been dropped from testing due to a regression [1]. Please make sure to downgrade. Best, David [1] https://bugs.archlinux.org/task/77914 -- https://sleepmap.de signature.asc Description: PGP signature
Re: Away for several weeks
On 2023-04-24 08:26:54 (+0200), Laurent Carlier wrote: > Last week I fell from my bike and was diagnosed with a broken pelvis/ankle. > So for weeks I must stay on a bed for some weeks - and away from my main > computer. > > I was not able to build amdvlk with last releases, so if some can fix it, > it'll be awesome. > > I hope to be back asap, so take care of you and see you soon. > > NB: this eMail is not signed because is sent with my phone. Hey Laurent, ouch... that sounds mean :( I hope you'll recover quick! I'm sure there will be people available to bump your packages in the meantime. If you think there are some that require a bit of extra caution (e.g. require bumping in parallel with other packages or are prone to break others, etc.), please tell ;-) Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Consolidating our mkinitcpio hooks
On 2023-04-25 16:31:29 (+0200), Morten Linderud wrote: > Initially I really want to move the hooks from `cryptsetup` and `systemd`: > > * encrypt and sd-encrypt from core/cryptsetup > * systemd and udev from core/systemd > > We could maybe consider a few other hooks from [core] depending on peoples > opinion? We are missing a good networking hook for systemd, and that should > preferably be solved at some point. > > A list of possibly other relevant mkinitcpio stuff: > > Hook Package > * btrfs btrfs-progs > * dmraiddmraid > * mdadm mdadm > * mdadm_udevmdadm > * lvm2 lvm2 > * sd-lvm2 lvm2 > * net mkinitcpio-nfs-utils > * netconf mkinitcpio-netconf There is also mkinitcpio-systemd-tool [1]. Although fairly unmaintained these days, it has a lot of features. Another user has created mkinitcpio-systemd-extras [2] which does similar things and looks less complicated (have not used it yet). It also features networking hooks (for systemd). Either might be something to consider to adapt from after moving the current systemd hooks. > # Migration > > It's unclear to me how we should best move these hooks. We would need to merge > them upstream into `mkinitcpio` first, then remove them from the packages. > > Is a news item is enough for this? Or do we want to include a couple of > package > constraints to ensure people are accidentally removing their hooks? I guess adding install notices might be enough. Or will the hooks be renamed? > What are peoples opinions? This is very awesome and I am happy you are looking into this! <3 Best, David [1] https://github.com/random-archer/mkinitcpio-systemd-tool [2] https://github.com/wolegis/mkinitcpio-systemd-extras -- https://sleepmap.de signature.asc Description: PGP signature
Re: Python 3.11 in [staging]
On 2023-04-06 14:30:25 (+0200), Jelle van der Waa wrote: > Early Easter suprise, > > After some delay Python 3.11 rebuilds are happening in [staging], so please > don't start any rebuild. > > Thanks to felixonmars for starting and rebuilding! > > Thanks, > > Jelle van der Waa Just a short heads up to all package maintainers: Please refrain from using staging and/or testing atm, as we are running into some issues while moving the packages. There will be an update to this once the move is complete. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [multilib] access
On 2023-05-28 12:26:59 (+0200), Jelle van der Waa wrote: > Let's just give everyone access by default. Yes please! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Stepping down
On 2023-06-06 20:40:36 (+0200), Jerome Leclanche wrote: > I've not been able to update any of my packages in a couple of months and > unfortunately I don't see the situation resolving itself any time soon with > my life being busier than ever. > > I'd rather officially step down and re-apply in the future if it makes > sense. > > I'd sign this email but I can't even find my updated arch GPG key. Bleh. Hey Jerome, I guess that's how it is: Eventually life gets in the way of packaging! :) If you indeed want to stop packaging, please make sure to reply with a signed email (using your PGP key with the fingerprint 169704C6FB490C6892C7F23C37E0AF1FDA48F373) [1], so that we can create a removal ticket for archlinux-keyring. I wish all the best for your future adventures and hope that our paths cross again! Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/remove-a-packager-key#workflow -- https://sleepmap.de signature.asc Description: PGP signature
Re: Stepping down
Hi Jerome, just a friendly reminder, that we would still need a message signed with your packager key, so that we can take further action. :) On 2023-06-07 17:19:37 (+0200), David Runge wrote: > If you indeed want to stop packaging, please make sure to reply > with a signed email (using your PGP key with the fingerprint > 169704C6FB490C6892C7F23C37E0AF1FDA48F373) [1], so that we can create a removal > ticket for archlinux-keyring. > > [1] > https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/remove-a-packager-key#workflow Best, David -- https://sleepmap.de signature.asc Description: PGP signature
RFC: Sources for Python packaging
A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/20 Please visit the above link for discussion. Summary: Default to not using https://pypi.org for Python package sources and only use the platform if there is no other alternative. -- https://sleepmap.de signature.asc Description: PGP signature
RFC Final Comment Period: Sources for Python packaging
An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/20 Please visit the above link for discussion. Summary: Default to not using PyPI for Python package sources and only use the platform if there is no other alternative. signature.asc Description: PGP signature
Re: Bug Day
On 2023-08-27 11:45:45 (+0200), Jelle van der Waa wrote: > Reminder, this is next weekend! > > On 05/08/2023 17:53, Jelle van der Waa wrote: > > I'd like to propose that we have a bug weekend on 1-3 September to clean > > up our bug tracker before we fully migrate it to Gitlab. Thanks for getting the ball rolling on this! I have booked the Saturday/Sunday for me for this. Friday does not work, but I'm sure others will have time then! Let's close as many tickets as we can! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
News Draft: Default password hashing algorithm changed to yescrypt
Hi all, with shadow 4.14.0 I introduced some changes to default password hashing algorithms and would like to post the following on the website once the relevant packages (filesystem, pambase, shadow) move to [core]: ```markdown With shadow >= `4.14.0`, Arch Linux's default password hashing algorithm changed from `SHA512` to [yescrypt](https://www.openwall.com/yescrypt/) and [PAM](https://wiki.archlinux.org/title/PAM) honors the chosen `ENCRYPT_METHOD` in /etc/login.defs. While this should not require any direct user intervention, do note that since we now fully integrate with PAM the `YESCRYPT_COST_FACTOR` setting in `/etc/login.defs` is currently without effect, until [PAM implements reading its value](https://github.com/linux-pam/linux-pam/issues/607). If a `YESCRYPT_COST_FACTOR` higher (or lower) than the default (`5`) is needed, it can be set using the `rounds` option of the [pam_unix](https://man.archlinux.org/man/pam_unix.8) module (i.e. in /etc/pam.d/system-auth). Furthermore, additional changes in the filesystem (>= `2023.09.18`) and pambase (>= `20230918`) packages now ensure [umask](https://man.archlinux.org/man/umask.1p) being set centrally in /etc/login.defs instead of /etc/profile. ``` Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: News Draft: Default password hashing algorithm changed to yescrypt
On 2023-09-19 09:43:17 (+0200), David Runge wrote: I have been asked by Kristian Klausen (offlist) to add information on the motivation for using yescrypt as new default. I propose this update: > ```markdown > With shadow >= `4.14.0`, Arch Linux's default password hashing algorithm > changed from `SHA512` to [yescrypt](https://www.openwall.com/yescrypt/) and > [PAM](https://wiki.archlinux.org/title/PAM) honors the chosen > `ENCRYPT_METHOD` in /etc/login.defs. The password-based key derivation function (KDF) and password hashing scheme `yescrypt` has been chosen due to its adoption (readily available in *libxcrypt*) and its stronger resilience towards password cracking attempts over `SHA512`. Although the winner of the [Password Hashing Competition](https://www.password-hashing.net/) has been `argon2`, this even more resilient algorithm is [not yet available in libxcrypt](https://github.com/besser82/libxcrypt/pull/150). > While this should not require any direct user intervention, do note that > since we now fully integrate with PAM the `YESCRYPT_COST_FACTOR` setting in > `/etc/login.defs` is currently without effect, until [PAM implements reading > its value](https://github.com/linux-pam/linux-pam/issues/607). > If a `YESCRYPT_COST_FACTOR` higher (or lower) than the default (`5`) is > needed, it can be set using the `rounds` option of the > [pam_unix](https://man.archlinux.org/man/pam_unix.8) module (i.e. in > /etc/pam.d/system-auth). > > Furthermore, additional changes in the filesystem (>= `2023.09.18`) and > pambase (>= `20230918`) packages now ensure > [umask](https://man.archlinux.org/man/umask.1p) being set centrally in > /etc/login.defs instead of /etc/profile. > ``` Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: News Draft: Changes to default password hashing algorithm and umask settings
Hi again, as the changes are rather diverse and manual intervention should not be needed, Leonidas and I have spent some time to restructure the text a bit for readability (also altered title slightly): ```markdown With shadow >= `4.14.0`, Arch Linux's default password hashing algorithm changed from `SHA512` to [yescrypt](https://www.openwall.com/yescrypt/). Furthermore, the [umask](https://man.archlinux.org/man/umask.1p) settings are now configured in `/etc/login.defs` instead of `/etc/profile`. This should not require any manual intervention. ## Reasons for Yescrypt The password-based key derivation function (KDF) and password hashing scheme `yescrypt` has been chosen due to its adoption (readily available in *libxcrypt*, which is used by [PAM](https://wiki.archlinux.org/title/PAM)) and its stronger resilience towards password cracking attempts over `SHA512`. Although the winner of the [Password Hashing Competition](https://www.password-hashing.net/) has been `argon2`, this even more resilient algorithm is [not yet available in libxcrypt](https://github.com/besser82/libxcrypt/pull/150). ## Configuring yescrypt The `YESCRYPT_COST_FACTOR` setting in `/etc/login.defs` is currently without effect, until [PAM implements reading its value](https://github.com/linux-pam/linux-pam/issues/607). If a `YESCRYPT_COST_FACTOR` higher (or lower) than the default (`5`) is needed, it can be set using the `rounds` option of the [pam_unix](https://man.archlinux.org/man/pam_unix.8) module (i.e. in `/etc/pam.d/system-auth`). ## General list of changes - `yescrypt` is used as default password hashing algorithm, instead of `SHA512` - PAM honors the chosen `ENCRYPT_METHOD` in `/etc/login.defs` and does not override the chosen method anymore - changes in the filesystem (>= `2023.09.18`) and pambase (>= `20230918`) packages ensure, that [umask](https://man.archlinux.org/man/umask.1p) is set centrally in `/etc/login.defs` instead of `/etc/profile` ``` Changes have been done collaboratively in a pad [1] as doing them bit by bit over mail is rather cumbersome. Best, David [1] https://md.archlinux.org/Y5YE6OV8SCePY-sx-hVVXQ?view -- https://sleepmap.de signature.asc Description: PGP signature
freerdp dropped from [extra-testing]
Hi all! I just dropped freerdp from [extra-testing], as I moved it there erroneously. Freerdp > 3 is currently *not* compatible with most dependents. I will try to figure out whether a freerdp2 package is feasible in the coming days. Patching the dependents is of course also an option, however most upstreams seem to not have progressed sufficiently on the topic yet. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
New checks for SPDX license identifiers with namcap >= 3.5.0
Hi all! With RFC0016 [1] we have worked out a way to reason about SPDX license identifiers [2] in the context of PKGBUILDs and packages. Over the past months I have worked on the licenses package [3], as well as namcap [4] to create the integration for all packagers. This mail serves as a refresher and general overview of what this means for packagers. TL;DR: Namcap now emits more specific error messages and there are probably a few things in this mail that you will want to learn about! :) To be able to be more specific in the below text, I will use this mini-glossary to explain what some words refer to: * *known* licenses and exceptions - Licenses and license exceptions *known* to SPDX (i.e. they are in the lists [2][5]). * *unknown* licenses and exceptions - Licenses and license exceptions *not known* to SPDX (i.e. they are *not* in the lists [2][5]). License identifiers prefixed with "LicenseRef-" are not considered. * *common* licenses and exceptions - Licenses and license exceptions that are packaged in the context of the licenses package [3] and can be shared *commonly*. * *uncommon* licenses and exceptions - Licenses and license exceptions that are *known*, but are *not common* (i.e. they are in the lists [2][5] but not in the licenses package [3]). License identifiers prefixed with "LicenseRef-" are always considered *uncommon*. For packagers a few things change when it comes to handling license information for packages. * It is encouraged to have a look at the list of *known* license identifiers [2] and exceptions [5] to familiarize yourself with how identifiers look like. The *common* licenses can be found in /usr/share/licenses/spdx/ and the *common* license exceptions in /usr/share/licenses/spdx/exceptions/. * The `license` array in PKGBUILDs should now start to contain valid SPDX license identifiers [2][5] or custom license identifiers, that are prefixed with "LicenseRef-" (e.g. "LicenseRef-Custom-License-1.0"). To keep complex scenarios maintainable and readable, each entry in the `license` array may be interpreted as being concatenated by the `AND` license expression [6]. * We now distinguish between various versions of some identifiers (e.g. previously we were okay with simple identifiers such as "GPL3" but now we have "GPL-3.0-only" and "GPL-3.0-or-later", which are separate from one another). If you are unsure about what applies, either contact upstream or reach out over mail, IRC, Matrix to ask other packagers. * If in doubt, rather be more specific than less specific! * To aide in documenting copyright and attribution, many upstreams rely on SPDX License IDs [7], which are added as comments at the top of each source file. These often help a great deal in figuring out which specific licenses apply and help in finding out whether there are any license files missing. To help you with figuring things out, namcap gained a few more features with > 3.5.0 (although some issues had to be ironed out up until 3.5.2 and I seriously hope I didn't introduce even more bugs ;-)). Please remember that namcap does not take away the work of investigating and providing the correct license identifiers for you! * Namcap now emits errors on all *unknown* license identifiers [2] and license exceptions [5]. * Namcap now lists all *uncommon* licenses and license exceptions while providing an overview about how many license files it found for the amount of *uncommon* identifiers (each *uncommon* identifier requires a separate file). * Namcap now emits errors with suggestions on formatting issues of license expressions (e.g. `MIT and Apache-2.0` -> `MIT AND Apache-2.0`). * Namcap now emits errors on license strings that can not be parsed. * Namcap now emits errors when the license directory is a symlink to a location in another package, that is not in `depends`. * Namcap now emits errors when the license directory is a symlink to a location in another package and license files are missing for *uncommon* identifiers. * Namcap now emits warnings if it detects symlinks for the license directory or single license files to another package. This is done because it is *very* cumbersome and error-prone to detect files in other packages reliably (e.g. those could in turn be symlinks to non-existent files, etc.). It is encouraged to package license files per package! Symlinks in the same package are fine! I hope this summary was not too overwhelming and will help you to get through the licensing jungle! Please do note, that the Arch Wiki section on license identifiers in the PKGBUILD article [8] still needs to be adapted. If there are any questions, please reach out! Many thanks to everyone who worked on the RFC and helped with testing the implementation! Best, David [1] https://rfc.archlinux.page/0016-spdx-license-identifiers/ [2] https://spdx.org/licenses/ [3] https://archlinux.org/packages/core/any/licenses/ [4] https://gitlab.archlinux.org/pa
RFC: Arch Linux Ports
A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32 Please visit the above link for discussion. Summary: Introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. This integration is meant to provide infrastructure and community-based support for architectures until they are fully supported by the main distribution. signature.asc Description: PGP signature
Re: Spring cleanup '24
On 2024-03-11 21:23:36 (+0100), Morten Linderud wrote: > I've adopted the tpm2-* stuff and pesign. Cool, thanks! > Some quick observations is that there are several packages on the list we > should probably not be dropping. The ones that come to mind is refind at the > very least. > > Here is a list of the packages for the list. Some of those mentioned packages were mine and for nearly all of them I have either contacted other maintainers to take over (because they were not leaf packages, but not required by any of my other packages anymore) or those are unmaintained or otherwise leaf packages. I'll send a more specific mail later. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Spring cleanup '24
On 2024-03-11 21:09:15 (+0100), gromit wrote: > On 24/03/02 12:48PM, gromit wrote: > > > Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and > > adopt packages that you'd like to keep in the repos. > > > > I will start dropping packages on 2024-03-17, so please try to have a > > look at the lists in the next few days. > > Reminder: There is one week left until unneeded orphan packages will be > dropped to the AUR. Please have a look at the list again to see if other > people orphaned stuff that may be intersting for you. Last week I have dropped about 100 packages. If you are interested in any of the below, please make sure that upstream is in fact still alive. In the case of python packages, make sure that those are not leaf packages (not required by any other package). If in doubt, just reach out. ams-lv2 autorandr beatslash-lv2 cadence cyrus-sasl deteriorate-lv2 foxdot fst ganv gpa grub-customizer helm-synth ir.lv2 irker libgssglue libiio libircclient libopenshot libopenshot-audio lvtk marsyas meterbridge midimsg-lv2 minitube neovim-lsp_signature neovim-lspconfig neovim-nvim-treesitter nfoview ninjas2 non-daw non-sequencer opencore-amr openshot osmid patchage pc-ble-driver pesign python-cfgv python-click-completion python-coverage-conditional-plugin python-cytoolz python-diff-cover python-etesync python-ethtool python-furl python-git-url-parse python-gitdb python-gitpython python-gnupg python-identify python-ipy python-jaraco.logging python-jaraco.stream python-jinja-time python-kaptan python-langdetect python-ly python-nrfutil python-orderedmultidict python-pc-ble-driver-py python-pdm-pep517 python-piccata python-poyo python-publicsuffix python-pyspinel python-pythonfinder python-pymediainfo python-pytest-vcr python-pytest-xprocess python-schedutils python-smmap python-toolz python-tpm2-pytss python-tree-format python-whichcraft python-yapsy quodlibet redland refind ruby-activesupport ruby-i18n ruby-json ruby-minitest-focus ruby-rugged ruby-test_declarative ruby-test-unit-ruby-core ruby-tzinfo ruby-warning ruby-zeitwerk slimit solfege sonic-pi tap-plugins vim-ansible vim-coverage-highlight vim-editorconfig Best, David -- https://sleepmap.de signature.asc Description: PGP signature
RFC Final Comment Period: Arch Linux Ports
An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/32 Please visit the above link for discussion. Summary: Introduce "Arch Linux Ports" as testbed for unofficial architectures until they are integrated in the main Arch Linux repositories. This integration is meant to provide infrastructure and community-based support for architectures until they are fully supported by the main distribution. signature.asc Description: PGP signature
Re: Urgent news draft: The sshd service needs to be restarted after upgrading to openssh-9.8p1
On 2024-07-01 17:31:58 (+0200), Robin Candau wrote: > > # The sshd service needs to be restarted after upgrading to openssh-9.8p1 > > After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to > accept new connections. (See > https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5). > When upgrading remote hosts, please make sure to restart the SSH daemon > using `systemctl restart sshd` right after upgrading. If you are upgrading > to openssh-9.8p1-2 or higher, this restart will happen automatically. I think it may be better to just mention that we are evaluating to do this automatically for future major version upgrades. Whether we get it right properly with -2 is not yet clear ;-) The restart won't hurt either way (unless users have somehow bricked their configuration in the meantime). Other than that, looks good! Thanks for taking the initiative! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Resignation
On 2024-07-14 21:14:27 (+0200), Florian Pritz wrote: > Sadly I have no longer had the time necessary to properly handle master > key holder and packager duties for a while now. I don't feel like it's > fair to you guys and our users to keep this up any longer so I'm > officially resigning now. > > Most pressing topics that come to mind for someone wanting to take over: > > * I hold a master key, so you'll need to find a new holder for that > * perl 5.40 update > * various bug reports on Gitlab for my packages > * a few flagged packages > > Thanks for all the nice memories since "[2008-10-19 14:38] installed > filesystem (2008.03-2)". While I will no longer be involved in Arch > development, I'll still continue to use it and this nice, old install > will also continue to live on. > > Hope to see you guys around :) Hi Florian, first of all: Thank you for all the work you did for Arch Linux! It's much appreciated! It is always sad to see longterm contributors go ;_; I fully understand that dealing with packaging and additional chores such as the main signing key eats a lot of time (it is always an uphill battle after all). I will create a ticket for the main signing key removal (so that we can track who will need additional signatures, if any) and packager key removal (so that we can check which packages need rebuilding) for you. All the best for your future and see you around! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
libassuan 3.0.1-1 pulled from testing after crashing pacman
Hi all, please note that I have just pulled libassuan 3.0.1-1 from core-testing. In this patch-level release some major issues emerged, that break pacman: ``` pacman -Ss test pacman: /usr/lib/libassuan.so.9: version `LIBASSUAN_1.0' not found (required by /usr/lib/libgpgme.so.11) ``` Please note that if you have libassuan 3.0.1-1 installed, you may have to use an installation media or static pacman to get back to 3.0.0-1. I'm very sorry to have caused any inconvenience over this. I will contact upstream about this momentarily. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Away until 2024-08-12
Hi all, I'll be on holidays from tomorrow until 2024-08-12 and only sporadically read mails etc. Please feel free to bump/move packages I maintain. Have a good summer! :) Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Arch Linux public upload server
On 2024-09-01 11:56:30 (+0300), Orhun Parmaksiz wrote: > The other day, I started wondering why Arch Linux shouldn't support a > similar public service, like https://paste.ubuntu.com, but powered by > rustypaste. I believe we could configure rustypaste to allow public > uploads with a retention period and necessary security measures in > place. Sounds like a great idea! I'm all for it! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Replacing mlocate with plocate
On 2024-08-24 12:03:18 (+0200), Morten Linderud wrote: > The question is if people feel a strong desire to keep a locate implementation > in `[core]` or if we are fine with this living inside `[extra]`. Adding > `plocate` to `[core]` would mean we would need to move a `liburing` to > `[core]` > and I don't really know if we need that. > > Any opinions? I'm fine with it being moved to [extra]. Thanks for taking care of this! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: RFC Final Comment Period: License Package Sources
On 2024-09-03 13:42:46 (+0200), Sven-Hendrik Haase wrote: > On 03.09.24 13:30, Sven-Hendrik Haase wrote: > > An RFC has now entered its Final Comment Period. In 14 days, discussion > > will end and the proposal will either be accepted, rejected or withdrawn: > > > > https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40 > > > > Please visit the above link for discussion. > > > > Summary: > > Our package sources currently do not have explicit licenses. > > This RFC proposes to license all Arch Linux package sources under the > > terms of the Zero-Clause BSD license. > > I'm so sorry. I apparently sent an HTML email because it wasn't disabled for > this account. > > Here's the real link: > https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/40 No worries. It was HTML **and** plaintext ;-) -- https://sleepmap.de signature.asc Description: PGP signature
Dropping python-spsdk and others
Hi all,
with python-pynitrokey dropping the dependency on python-spsdk and others, I am
able to drop a few packages.
If you are interested in any of them, please make sure to adopt them, else I
will drop the following packages to the AUR in a week from now (2024-10-16):
python-spsdk
python-bincopy
python-argparse-addons
python-python-click-command-tree
python-python-click-option-group
python-deepmerge
python-hexdump
python-libusbsio
python-pylink-square
python-pyocd
python-cmsis-pack-manager
python-sly
python-pyftdi
python-frozendict
The python-fastjsonschema package is not used by any of the packages I maintain
(but used by fusesoc, jupyter-nbformat, python-{poetry-core,validate-pyproject})
and I will orphan it.
Best,
David
--
https://sleepmap.de
signature.asc
Description: PGP signature
RFC: Upstream Package Sources
A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46 Please visit the above link for discussion. Summary: Improve the security of Arch Linux distribution packages by relying on transparent and if possible also cryptographically verifiable upstream sources by default. signature.asc Description: PGP signature
Sovereign Tech Agency funding for ALPM project
Hi all, I am happy to announce that the [ALPM][0] (Arch Linux Package Management) project receives funding from the [Sovereign Tech Agency][1] for work on the Arch Linux packaging ecosystem. > The Sovereign Tech Agency supports the development, improvement, and > maintenance of open digital infrastructure. > Its goal is to sustainably strengthen the open source ecosystem, focusing on > security, resilience, technological diversity, and the people behind the code. The investment from the Agency's Sovereign Tech Fund provides financing for four developers to work on the ALPM project in a part time capacity over the course of 15 months. The developers are [Arne Christian Beer][2], [Heiko Schäfer][3], [Orhun Parmaksız][4] and [David Runge (myself)][5]. Work on the project has started in October 2024 and the funding continues until the end of 2025. The ALPM project provides specifications, as well as Rust libraries and tools. Its goals are robust integration for all package creation, validation and installation tasks, repository management, as well as drop-in replacements or alternatives for some facilities provided by [pacman][6]. The investment through the Sovereign Tech Fund supports multiple milestones, which are explained below. ## Formal specifications for packaging data formats The Arch Linux packaging ecosystem uses underspecified/undocumented file and metadata types, yet we need to be able to use them reliably in other contexts such as package creation, build and package repository management tooling. Therefore this milestone involves developing versioned specifications for all low-level descriptor file and implementing Rust libraries based on them. These will be based on the existing ad-hoc reference implementations in [makepkg][7] and pacman. ## Basic OpenPGP verification of artifacts Signature verification in Arch Linux package management currently hinges on a stateful GnuPG keyring. This solution is brittle and has already caused various issues related to the Arch Linux keyring in the past. To simplify signature verification - while at the same time enabling the use of a more diverse set of cryptographic technologies - a specification for the [UAPI group][8] will be written. An accompanying Rust library will be provided as a simple and stateless integration, not limited to use in Arch Linux. ## Rust library for handling of individual packages The structure of Arch Linux package files is currently not explicitly defined. This milestone focuses on providing a formal specification of what an ALPM-based package contains, how it is created and handled. A dedicated Rust library and tool will facilitate package creation, validation and installation. These new Rust libraries will also expose a C API for possible integration into the C-based libalpm library. ## Rust library for system package management This milestone revolves around the use of the previously implemented components by providing a library for package download, validation, verification, installation and state handling similar to pacman's libalpm and will handle sets of individual packages on user systems. A C-API will be provided for compatibility with libalpm-based applications. One specific concern of this milestone is modernizing the OpenPGP integration. Current package management tooling does not allow for scoping signature verifiers (e.g. OpenPGP certificates) for a specific purpose, such as "only packages" or "only repository metadata". The new system will rely on a stateless approach such as the one to be proposed as specification to the UAPI group. ## Distribution-agnostic OpenPGP stack for the verification of distribution artifacts This milestone will focus on a set of foundational libraries, based on a UAPI specification from a previous milestone. These libraries will add support for PGPKI (aka the “Web of Trust”) in the generic directory structure for OpenPGP certificates used for the verification of distribution artifacts. The libraries mentioned above will be integrated into the ALPM context to allow for example the full verification of packages and repository metadata. A Rust-based solution will be provided as a modern alternative to the current GnuPG-based approach. # The outcome(s) The ALPM project strives to build a modern, sustainable, maintainable and memory-safe framework for the Arch Linux packaging ecosystem. This framework will enable robust and predictable integration for all package related tooling and libraries. The project goals are intentionally ambitious while being constrained to a relatively short period of time. The work is organized so that real world benefits will happen early and often. Several infrastructure related projects have already reached out with a concrete interest to make use of libraries created in the first phase of the project. The work will be done in the open, on the [Arch Linux GitLab][0]. Everyone and anyone is welc
Re: TensorFlow packages incompatible with Python 3.13
On 2024-12-15 22:34:55 (+0100), Torsten Keßler wrote: > WARNING: This version of the TensorFlow package is not compatible with > Python 3.13 > > If you want to use TensorFlow, consider installing an older version of > Python and use a virtual environment or use the official Docker image, > https://www.tensorflow.org/install For making other Python interpreters available per user, you could also point at pyenv. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Issues with Libera.Chat and public access via Matrix
Hi all, back in October I have created channels for the buildbtw and signstar projects [1] which are meant to be publicly accessible for development and general user activities. While these work fine on the Libera.Chat side, the bridging via our private Matrix bridge causes friction: It is not possible to access the bridged rooms from Matrix without either being in the private Arch Linux staff space or being invited specifically to that room. This is due to the fact, that the official bridge has been shut down in August 2023 and eventually sunset entirely [2]. I raised this issue in the #archlinux-devops channel and after a chat with Jan the following possible scenarios materialized: - only use IRC (shut out Matrix users) - only use Matrix (shut out IRC users) - continue to invite interested people to bridged Matrix rooms manually (basically also shut out Matrix users) - switch to a different IRC network that is (still) accessible via a public Matrix bridge (e.g. oftc.net [3]) for public rooms I am not fond of the first three options as they either shut out user groups or require manual handholding of user additions, which in my mind does not scale. I'm raising this as a general note, because this is an issue when it comes to making public rooms available on Matrix beyond our own staff. For the ALPM project I have therefore chosen the path of least resistance and created #alpm on oftc.net for the time being. It would be great to find a less fragmenting solution for public rooms, so I'd be happy to get some input on this topic. Best, David [1]: https://lists.archlinux.org/archives/list/arch-proje...@lists.archlinux.org/thread/FN3PTFC7WLFCHUCXQIVS5QXPEPI7BRNI/ [2]: https://libera.chat/guides/matrix [3]: https://oftc.net -- https://sleepmap.de signature.asc Description: PGP signature
Re: Rust packaging guidelines: Remove --all-features suggestion
On 2025-02-18 19:29:41 (+0100), kpcyrd wrote: > hello, > > following up on an irc discussion on the Rust packaging guideline, I'd like > to propose changing the command in section 5 from: > > cargo build --frozen --release --all-features > > to > > cargo build --frozen --release > > Enabling all non-default features is rarely what we want, they are usually > off for a reason and instead features should be explicitly selected and > enabled, or added to the default feature set by upstream if they are meant > to be on by default. > > Setting --all-features in many projects (mine included) would enable the > `vendored` feature that opts you out of system libraries, which is something > we explicitly don't want. Yes, I think that is a good idea! Will you also add some form of note hinting at "you may want to look at the specific features of the project and potentially enable some selectively" with an example on how to enable features? Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Standardize on running autoreconf in prepare()
On 2025-02-26 21:53:50 (+0100), Jelle van der Waa wrote: > After all the recent RISC-V news I went ahead and checked out the existing > effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of > PKGBUILDs which require customization to be be able to build on RISC-V. A > lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in > prepare(), this re-generates `configure` to understand RISC-V. > > Since these patches are simple enough and I don't see them harming Arch > Linux, I would argue that we want these patches applied in our packages. > Re-generating configure should not break, and if it does we should not > accept the patch and get a bug filled upstream. Yes, this is generally a good idea and usually works withouot issue. Exceptions can't easily be detected though as we currently expect base-devel to be installed and not autotools specifically. However, they usually include: - projects with ancient and custom autotools (looking at you ncurses 👀) - projects where `configure` is actually not autotools (looking at you qemu 👀) > Re-creating configure and thus not using the provided `configure` could > arguably also be a good thing regarding supply chain security. And this also > should help with other architecture ports. That's also what RFC0046[1] is about in consequence. When not relying on custom source tarballs, autoreconf (or some custom bootstrap script like autogen.sh) usually must be run. > As a follow up we can discuss providing our own "/usr/share/config.site" and > then ./configure --prefix=/usr would automatically configure localstatedir, > libexecdir, etc. That would also be great and I think should be developed and maintained by us in a dedicated project, together with the custom `arch-meson` and any future cmake presets[2]. Best, David [1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46 [2] https://gitlab.archlinux.org/archlinux/ideas/-/issues/15 -- https://sleepmap.de signature.asc Description: PGP signature
RFC Final Comment Period: Upstream package sources
An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/46 Please visit the above link for discussion. Summary: Improve the security of Arch Linux distribution packages by relying on transparent and, if possible, cryptographically verifiable upstream sources by default. Provide guidelines and best practices for distribution package maintainers in a document covering various source types and technologies for digital signatures. Communicate the common goal of transparent and secure package delivery for package maintainers as well as upstream project maintainers. signature.asc Description: PGP signature
Re: [arch-dev-public] Goodbye
On 2021-01-21 14:08:11 (+0100), Bartłomiej Piotrowski via arch-dev-public wrote: > Hi everyone, > > I'm stepping down as a developer. It's been mostly fantastic ride for > the last 10 years but it's clear to me now that for better or worse it's > far from the project I initially joined. > > Thank you and good luck with everything, > Bart Bart! Thanks for your years spent with Arch! All the best for your future plans and projects. Seems you onboarded quite a few of us as devs (also me) :) Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] [signoff] [extra] postfix 3.5.9-1
Hi! I have just upgraded postfix to 3.5.9. The package has been split to allow specific installations based on requirements while not pulling in all of the backends at once: postfix postfix-cdb postfix-ldap postfix-lmdb postfix-mysql postfix-pcre postfix-pgsql postfix-sqlite Please do test the integration of the split-out optional dependencies with postfix to see whether everything still works as expected. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Chromium losing Sync support on March 15
On 2021-01-26 22:18:21 (+0100), Levente Polyak via arch-dev-public wrote: > On 1/26/21 9:53 PM, Morten Linderud via arch-dev-public wrote: > > > > It's dissapointing frankly. > > > > Disappointing doesn't really catch it tho. If it would be just about the > sync functionality: so be it. But crippling the API usage on a level > that rips out especially things like the safe browsing functionality as > well places chromium knowingly and forcefully into a position that > doesn't make it viable to be distributed to users. > > I'm incredibly mad that his is literally a situation where the open > source world is soaked up and in return a big clear "screw you guys, we > don't care" sign is raised. Well played, exploiting a monopoly position > like this and literally cheating on the open source community all around > them. > > PS: firefox is affected by safe browsing keys as well. I agree, that this situation and Google's position on this is utterly disappointing. However, I am one of the people that actually needs chromium for work daily and that needs to rely on it for several websites that are not supported by firefox (which I use mainly). I suggest we all take a deep breath and evaluate the situation. Is safe-browsing and geolocation in chromium and firefox really affected by this? If so, that would of course be bad (from the reactions so far, users seem mostly fine without the Google sync functionality). However, we need to test this carefully with e.g. packages in [testing] instead of prematurely deleting everything. If e.g. safe-browsing is indeed affected, now would be the time to contact mozilla about this to a) change this for firefox by default and b) evaluate whether it is possible to e.g. use their services in chromium. If safe-browsing is not affected, under what circumstances are we allowed to use and distribute a browser with it? The Google Chrome team can and needs to answer these questions. These are all things we need to figure out. Let's please not panic. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Chromium losing Sync support on March 15
On 2021-01-27 08:45:53 (-0300), Giancarlo Razzolini wrote: > If google drops the api key, yes. They said we can continue using > them, but we don't know for how long, and they also mentioned > reviewing quotas, which would render them unusable. We don't have any specifics, so we will have to wait until we know more. > > If so, that would of course be bad (from the reactions so far, users > > seem mostly fine without the Google sync functionality). > > However, we need to test this carefully with e.g. packages in [testing] > > instead of prematurely deleting everything. > > > > Again, it's not just sync functionality. Login won't work anymore, and > with it, a bunch of other stuff. I have sent the full list on > arch-general. The login functionality is only relevant for in-browser login, right? As long as users can still use chromium to safely browse the internet, I'm not too concerned about that. > > If safe-browsing is not affected, under what circumstances are we > > allowed to use and distribute a browser with it? The Google Chrome > > team can and needs to answer these questions. > > > > We are allowed to continue using the api key, until they fell like we > aren't anymore. Which is why we should probably ditch chromium > altogether. How is this situation different from all these years up until now though? If safe-browsing indeed stops working, without any viable replacement option, then we can still consider dropping chromium. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] RFC: Using RFCs
Dear staff, I have begun work on a Request for Comment (RFC) process for Arch Linux and I am excited to now be able to open the first RFC... to introduce "Using RFCs" :) A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1 Please visit the above link for discussion. Summary: A Request for Comment (RFC) is a way for Arch Linux contributors to propose, design, and discuss new features and changes in project direction in a focused environment. Best, David P.S.: To all staff members, that do not have an SSO account yet, please get in touch with Sven-Hendrik Haase to be signed up and be able to participate in the discussion. -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: Using RFCs
Hey all, it has been roughly two weeks since my first mail and the discussions we have had via comments on the RFC merge request have concluded. Thank you all for your improvement suggestions and feedback! This first RFC is rather special, as it is meant to bootstrap the process and introduce it for adoption (while the process is actually not yet in place). Therefore I am skipping the "Final Comment Period" on the issue tracker and instead move the proposal for adoption of the RFC process back to this mailing list for ratification (aka. the final ACK by you!). I am assuming, that a period of two weeks (starting now) is a good time frame to collect the final motion on this topic from many (if not all) of you. I would like to either merge (accept) or close (reject) the proposal after this time frame has passed. Please reply to this mail with an approval or disapproval of the process, so that a consensus can be reached. In case you have not yet read the RFC and the workflow, you can do so in the merge request [1], or - for a better reading experience - on the branch the merge request is created from [2]. Best, David [1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1 [2] https://gitlab.archlinux.org/dvzrv/rfcs/-/tree/rfc_process/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: Using RFCs
On 2021-02-16 13:38:06 (-0300), Giancarlo Razzolini via arch-dev-public wrote: > > Gitlab is going to be opened within the next months and we have > > users on Gitlab today. It's not limited to staff. True, but as we enforce the access rights to all of our repositories, we can change that if the need arises. Currently, the need has not yet arisen. > > Is it our obligation to propose any user-made RFC to a-d-p on behalf > > of them? Do we want that? > > > > The process is not clear and either assumes the RFC proposer can > > announce it, or makes it implicit that it will be announced. Providing an example of how to change the proposal would be very helpful and improve the process. > It's my understanding that Allan made some amendments that address > this issue specifically. Indeed, Allan did. I will extend the README with a section that adds a requirement for outside contributors to be supported by at least one Developer or Trusted User (and also highlight this in the RFC). > But basically I think that a TU/Dev/Staff should be the one doing the > post to a-d-p after vetting/sponsoring the RFC. But I maintain that I > think anyone should eventually be able to create RFC's. I agree. Given the above mentioned limitation for outside contributors, it is a good model IMHO. Even if outside contributors would like to discuss "controversial" topics, I don't think it is bad having that discussion (given, that it is not done in an inflammatory fashion). It is something that can be referred back to, in case the same topic comes up again. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Away until 2021-06-28
Hey all, I'll be away for about a week for holidays. If anything urgent comes up, feel free to bump or fix my packages. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Changes to the Code of Conduct
Dear all, Jonas and I have been working on changes to our Code of Conduct, which are represented in the following merge request: https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/11 While most changes are based on e.g. merging sections or moving topics to separate documents to make the text more concise and allow easier changes in the future, there are also a few changes and omissions explained in more detail in the respective commits of the merge request. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Changes to the Code of Conduct
On 2021-07-14 13:58:07 (+1000), Allan McRae via arch-dev-public wrote: > I just read the document as it stands after your proposed changes. My > conclusion was it is too long, often explained points in too much > detail, and was too long! I agree. The current work focusses mainly on splitting out technical guidelines (while still referencing them), as those - apart from containing links to outside resources - are also more likely to change more often and should not be part of the Terms of Service. I realize, that the following was not mentioned in my first mail: Without the minimum set of above changes we can not release the Terms of Service as is. This is because the ToS are a set of legal documents, that once released, can only be changed with prior notice of about a month. With inline references to other documents that are not explicitly marked as "outside of the ToS" and which may change at arbitrary points in time, this is of course not possible. > Compare with Codes of Conduct from other distros. > > Debian: https://www.debian.org/code_of_conduct > Gentoo: https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct > Fedora: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > Suse: https://suse.com/betaprogram/codeofconduct/ Some of them (but also others) are actually referenced in the ticket, that belongs to the merge request. I agree that ours is still too specific (and therefore also too long). > I highly recommend taking a scalpel to the current text. I'm happy to > take a pass if you would like my suggestions in more solid format. That would be very awesome, thank you! Preferably I would like to do further changes to the CoC (to improve wording and conciseness) in a follow-up MR though, as the diff will otherwise become a bit extreme in the current one. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Accidental todo for fluidsynth
Hey all, I made a dodo this morning by accidentally adding a TODO for a fluidsynth rebuild [1]. The rebuild can only be done after the hdf5 rebuild [2] is done, due to overlap. I will re-open it once we can proceed. Sorry for the noise. Best, David [1] https://archlinux.org/todo/fluidsynth-220-rebuild/ [2] https://archlinux.org/todo/netcdf-480-hdf5-1121-rebuild/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Accidental todo for fluidsynth
On 2021-07-23 10:48:19 (+0200), Antonio Rojas via arch-dev-public wrote: > El viernes, 23 de julio de 2021 10:28:42 (CEST), Archange via > arch-dev-public escribió: > > Please mind that here is already an (intel-)tbb rebuild waiting for the > > hdf5 one to finish. As well as a VTK one, but since I did not yet finish > > upgrading the PKGBUILD, I’m willing to let you the second spot on the > > waiting list. ;p > > > > Simultaneous rebuilds are OK as long as there is no overlap. AFAICS neither > tbb nor VTK conflict with fluidsynth. Hm, as there seems to be only csound overlapping, it might be possible to do the fluidsynth rebuild "at the same time" after all, as Bruno pointed out on IRC, by rebuilding all other dependants, moving the lot to [testing]/[community-testing] and rebuilding csound against testing. Let's see how fast we can be about it, given that some upstreams (csound included) where usually not super fast in adapting to changes in fluidsynth. Worst case we'll move both TODOs together then. I'll look into this with some test builds and report back on this later today (latest tomorrow). Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Away for two weeks
Hi all, I'll be away for about two weeks and likely not be super active packaging. There are a few TODOs for rebuilds [1][2][3] that I have started, which I may be able to move, but probably not be able to further help rebuild at the moment. Feel free to rebuild out-of-date packages. Note, that juce is still out of date because I wanted to look into applying a few useful things for lv2 compatibility from the distrho fork [4][5] but never really had the time to spend on it. In case anyone is interested in looking into that, it would be much appreciated, too! :) Best, David [1] https://archlinux.org/todo/libiio-022/ [2] https://archlinux.org/todo/capnproto-090/ [3] https://archlinux.org/todo/libnsl-200/ [4] https://github.com/DISTRHO/juce [5] https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/juce-current/patches -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] namcap maintainership
On August 21, 2021 9:24:20 PM GMT+02:00, Jelle van der Waa via arch-dev-public wrote: >I would love to see someone from our team pick up namcap maintainership, >take a look at all the pending patches, bugs on the tracker and keep it >in shape. Is anyone interested in potentially picking up this task? > >[1] https://gitlab.archlinux.org/pacman/namcap >[2] >https://lists.archlinux.org/pipermail/arch-projects/2021-January/005411.html >[3] >https://lists.archlinux.org/pipermail/arch-projects/2020-December/005403.html As Python is sort of my daily bread-and-butter at work these days, I can certainly help with getting things back in shape, setting up some form of automation, etc. Having the project on our gitlab already simplifies things quite a bit. Due to huge time commits on other tooling in our infrastructure I would not be able to actively maintain it though and I'd be happy to see e.g. Filipe and/or Caleb work that out :) Best, David P.S.: Sorry, on phone and can't sign this mail. -- https://sleepmap.de
Re: [arch-dev-public] community.files pacman database corrupt
On 2021-08-30 22:35:39 (+0200), Pierre Schmitz via arch-dev-public wrote: > Thanks for looking into this. It's still weird but let's see if it > will happen again. I hope it wasn't a memory issue and we can just > blame Allan. ;-) Unfortunately this has happened before. On 2021-04-06 I noticed the same with python-pytesseract's files db entry - a package which had not been touched since February - due to work on arch-repo-management (a pipeline started failing on validating the package database [1]). The package was bumped [2] and the corrupted files db entry was replaced. I have uploaded the community.files database with the corrupted entry [3] if anyone is interested. [1] https://gitlab.archlinux.org/archlinux/arch-repo-management/-/pipelines/6208 [2] https://github.com/archlinux/svntogit-community/commit/0a9473072bc114cfbefe43c92acbf245dccdc980#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a [3] https://pkgbuild.com/~dvzrv/bugs/2021/04/community.files -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] RFC: Adoption of a distribution-wide Code of Conduct
A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6 Please visit the above link for discussion. Summary: The adoption of a distribution-wide Code of Conduct (CoC) helps to describe the social contract by which communication takes place on the various communication channels offered by Arch Linux. This document describes the current CoC, its purpose and location and how to interact with it. Best, David signature.asc Description: PGP signature
[arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct
An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6 Please visit the above link for discussion. Summary: The adoption of a distribution-wide Code of Conduct (CoC) helps to describe the social contract by which communication takes place on the various communication channels offered by Arch Linux. This document describes the current CoC, its purpose and location and how to interact with it. Best, David signature.asc Description: PGP signature
Re: [arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct
On 2021-10-08 09:44:56 (+1000), Allan McRae via arch-dev-public wrote: > On 7/10/21 1:41 am, Sven-Hendrik Haase via arch-dev-public wrote: > > On 06.10.21 12:47, Allan McRae via arch-dev-public wrote: > >> On 27/9/21 4:33 am, David Runge via arch-dev-public wrote: > >>> An RFC has now entered Final Comment Period. In 14 days, > >>> discussion will end and the proposal will either be accepted, > >>> rejected or withdrawn: > >>> > >>> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6 > >>> > >>> Please visit the above link for discussion. > >> Note that visiting the above link to make a comment would require > >> agreeing to the Terms of Service, which includes the document under > >> discussion. FTR: This has been the case and *is* the case for the wiki, the forums, the mailing list and the IRC. > >> However, the RFC process does allow discussion external to the > >> merge request, so people should feel free to respond elsewhere. It does allow that, but we are now in the "Final Comment Period" [1] and not in the discussion period [2] anymore. Therefore it would be nice to not fragment discussion, by doing it on this mailing list, where only a subset of the staff can interact with it. > >> I do not think Arch should formally adopt *this* code of conduct. That is your right and we may disagree on that. > > You appear to generally be agreeing to the overall do's and don'ts > > (as your MR's [0] overall points are about the same). I therefore > > would like to implore you to roll with this version for now and then > > improve upon it as a direct follow up. I support what Sven wrote. Please improve upon your existing merge request for the Code of Conduct [4]. It has been open for two months, with no further work done on it, although there have been questions raised. I generally don't like bringing up any "could have"'s and "should have"'s; however, your MR precedes the RFC and could have been the "current version". Starting a discussion about the length and form of the Code of Conduct *after* not interacting with the own changes to the Code of Conduct that would fix it, *after* not interacting with the RFC that wants to establish the CoC distribution-wide during its comment period and also *after* not interacting with the changes that were done last to the CoC (which in fact you gave the initial idea for and were informed about its progress multiple times) by Jonas and I, but instead complained about *after the fact*, to me, quite frankly at this point feels nothing short of condescending and disrespectful. This form of communication is very ineffective and draining and I urge you to stop doing that. Best, David [1] https://gitlab.archlinux.org/archlinux/rfcs/-/blob/9bfa7561a500a2d4e527b376bf6e2929276a9315/README.rst#L190-200 [2] https://gitlab.archlinux.org/archlinux/rfcs/-/blob/9bfa7561a500a2d4e527b376bf6e2929276a9315/README.rst#L151-156 [3] https://gitlab.archlinux.org/archlinux/service-agreements [4] https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/14 -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Netboot of 2021.11.01 ISO image is broken
Hi Pierre, On 2021-11-01 15:32:51 (+0100), Pierre Schmitz via arch-dev-public wrote: > I did have some trouble build the current ISO image. As archiso > requires to be run as root I had to work around some issues with GPG. > As those did no longer work I thought I manually sign the artifacts. > This did work fine, but later on I noticed that when using Netboot > (PXE), mkinicpio-archiso is no longer able to verify the FS due to > lack of any public key for GPG to use. In the meantime I moved the > arch folder from the release directory. Note: just using Netboot is > broken; the regular ISO image is fine. This setup is already automatically built on a monthly basis as part of the releng project [1]. However, it is currently still missing the last bits to switch to a pull principle on the target server by signing and synchronizing artifacts using arch-release-promotion [2]. As this is a somewhat breaking change in the way the download directory is structured and how we build, sign and provide artifacts, it is described in a rather long ticket [3]. Due to other topics I did not have too much time for this entire side of Arch in a while, but hope to get back to it soon. You can have a look at the latest releng release from today [4] (click on the "Build artifacts" link). Do note, that the netboot artifacts are built **using a dummy keypair for codesigning** (the "real ones" still have to be setup in CI - see README of the project) and use an ephemeral PGP key (which is fine, as it is not relevant whether it is a specific PGP key, only that the *correct* PGP key is used to validate the root image). > The whole PXE boot setup is weird though. It starts with a openssl > signature for which I am the only one to sign it. We then verify the > airootfs using gpg for which we provide the public key (the part which > is currently broken). Wouldn't it be enough to instead verify the > integrity using the sha checksums we already have, if it was already > contain in the ssl signed image? The codesigning (the openssl cert) is to verify the loading of further blobs from a remote [5]. This is due iPXEs capabilities of dealing with this sort of setup. The PGP signature is used to verify the rootfs in early userspace if verification was requested by the user (could and probably should be done by default, but is off by default) [6]. > Before diving deeper into the issue in oder to solve it, I was > wondering if it wouldn't be better to ditch the whole netboot setup. > It is quite complex and hard to test. What do you think? I have to > admit that I do not know of any use case where you could not use a > regular ISO image and had to use PXE boot. I do believe there are still users of this use-case and there have been contributions over the past year to improve the security [5] of this as well and to devendor the netboot related binary blobs from archweb (which is also why we now have the ipxe package in the repositories). In fact we are very close to streamlining this process and it would be sad to drop it now. As an interim I invite you to use the build artifact from the releng pipeline next time (for that we only need to put "real certificates" for the netboot artifacts in place for the pipeline -- please do get in touch in #archlinux-releng on libera.chat), as that will save you the troubles of building this manually and will only require you to add PGP signatures, until the workflow with arch-release-promotion is in place. Best, David [1] https://gitlab.archlinux.org/archlinux/releng/ [2] https://gitlab.archlinux.org/archlinux/arch-release-promotion [3] https://gitlab.archlinux.org/archlinux/releng/-/issues/11 [4] https://gitlab.archlinux.org/archlinux/releng/-/releases/2021.11.01.38302 [5] https://gitlab.archlinux.org/archlinux/releng/-/blob/357009ee870d079ed01ee73c2a9423f9e1ca08a9/README.rst#L44 [6] https://gitlab.archlinux.org/mkinitcpio/mkinitcpio-archiso/-/blob/bdad4a12547ab2e0fc8829e778ecdc35c2072465/hooks/archiso#L157-165 [7] https://gitlab.archlinux.org/archlinux/releng/-/merge_requests/9 -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Netboot of 2021.11.01 ISO image is broken
On 2021-11-01 18:49:48 (+0100), Pierre Schmitz via arch-dev-public wrote: > On Mon, Nov 1, 2021 at 5:10 PM David Runge wrote: > > ... use an ephemeral PGP key (which is fine, as > > it is not relevant whether it is a specific PGP key, only that the > > *correct* PGP key is used to validate the root image). > > Thanks for your insights. I think I now found the missing peaces. > Using an ephemeral key made it much more easy. I created it as it is > done in > https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/.gitlab/ci/build_archiso.sh#L162 > (not part of archiso itself, so I got confused) I re-uploaded the arch > folder. Let's hope that should fix the issue. Cool, glad you could fix it! :) Yes, the key has to be provided during build time, which is possible, but starts getting a bit ugly once one is switching user contexts (nl6720 uses that type of setup from time to time, if you have questions). The build runs on a secure runner as root (in a VM in a container). There are still a few things preventing us from being able to run archiso without root [1]. > Still, doesn't this show we do not really need GPG to achieve > verification? We currently use _verify_signature() in > mkinicpio-archiso, but shouldn't _verify_checksum() be as secure > without the hassle to involve GPG? Hm, I would argue that PGP is cryptographically strong, is already implemented for this use-case and works (TM). Unless someone comes up with an equal or better solution that we can use there, I guess it is the way for us to do this currently. Additionally, this is already solved and automated within the context of releng and I believe a good way forward would be to establish a workflow in which we rely on the automatically built artifacts. As pointed out by you in your initial mail, you are currently the only person responsible for the openssl based codesigning certificate. All we need to do is create a new one following the workflow described in the README of the releng project and start using it (which conveniently also raises the bus factor for this a bit). What do you think? :) Best, David [1] https://gitlab.archlinux.org/archlinux/archiso/-/issues/40 -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Upcoming PHP 8.1 update
On 2021-12-06 16:11:45 (+0100), Pierre Schmitz via arch-dev-public wrote: > Hi all, > > a little heads up as it takes longer than expected. I'll start the PHP > 8.1 update and the required rebuilds soon. I noticed some unexpected > incompatibilities and I'd like to look into these first. I'll also > evaluate if we could drop the php7 packages at the same time. Hi Pierre, nextcloud does not yet support php > 8.0. The upcoming version 23.0.0 (currently in [community-testing]) neither unfortunately [1]. However, the package itself guards against upgrading to php 8.1, so it should be fine for current installations, but it will make installing nextcloud not possible for new systems. Best, David [1] https://github.com/nextcloud/server/issues/29287 -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Upcoming PHP 8.1 update
On 2021-12-06 17:58:57 (+0100), Levente Polyak via arch-dev-public wrote: > On 12/6/21 17:48, David Runge via arch-dev-public wrote: > > On 2021-12-06 16:11:45 (+0100), Pierre Schmitz via arch-dev-public wrote: > > > Hi all, > > > > > > a little heads up as it takes longer than expected. I'll start the PHP > > > 8.1 update and the required rebuilds soon. I noticed some unexpected > > > incompatibilities and I'd like to look into these first. I'll also > > > evaluate if we could drop the php7 packages at the same time. > > > > Hi Pierre, > > > > nextcloud does not yet support php > 8.0. > > The upcoming version 23.0.0 (currently in [community-testing]) neither > > unfortunately [1]. > > > > However, the package itself guards against upgrading to php 8.1, so it > > should be fine for current installations, but it will make installing > > nextcloud not possible for new systems. > > > That guard is just a stop gap from breaking the application after an > upgrade. That does not really help current installations either as it cuts > off the system from potentially important security updates. I agree. I was referring to right out breaking functionality on a running system due to the php upgrade. > We really need to keep the dependency resolution intact which means if we > are stuck for nextcloud the only viable options were either postpone php or > provide a maintained set of php 8.0 that nextcloud can depend on. We indeed need to make an effort in regards to these situations. It has happened before that nextcloud was not yet ready for a minor version upgrade of php and the upgrade broke functionality for users. That's why we have made the effort to signal the upper boundaries for the applications as clearly as possible (to not be in this situation anymore). My suggestion would be to wait for a little bit more to figure out whether there will be patch level releases for php 8.0.x or whether we should introduce another intermediary package (I'm not a fan of the latter). Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Upcoming PHP 8.1 update
On 2021-12-06 18:32:49 (+0100), Pierre Schmitz via arch-dev-public wrote: > In general we could provide PHP 7 till its end of life in about eleven > months. But I don't think its worth providing several different minor > versions at the same time. I agree. > This is not how semver is supposed to work :-) (Someone should check > Nextcloud but looking at their PR it mostly seems about tests, > documentation and deprecations but no hard errors). I would definitely wait until the PR for nextcloud [1] has settled (it's still a draft). The changes apply to 23.0.0 (which has been in testing only for a few hours). Do note, that effects of php 8.1.0 on the nextcloud-apps is completely unaccounted for in this scenario. I would like to have nextcloud 23.0.0 in [community] before we proceed with any testing with php 8.1.0 if that is fine with you. Best, David [1] https://github.com/nextcloud/server/pull/29862/commits -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] News draft: libxml2>=2.9.12-6 update may require manual intervention
Thanks for taking care of this! It generally looks good, but I would replace > If you get errors like these with "If you get errors such as the following" Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Updates to archlinux-keyring and signatures for packager keys
Hi all, in the past days there have been a few releases of our archlinux-keyring package, which contains the root trust of our distribution. We have successfully switched to using keyringctl [1] to manage the keyring. From now on all changes to the keyring are done via merge requests towards the archlinux-keyring repository, as it now serves as the source of truth, whereas in the past we have been relying on the dying SKS infrastructure or the Ubuntu keyserver (which may or may not support all key types in use). I have contacted all of you over the past months and either requested the addition of an @archlinux.org UID, the creation of a new PGP keypair or the verification of your PGP key by means of a clearsigned token. To all that have added a new @archlinux.org UID or have created a new key, please make sure that all signatures you have received from main signing keys are also present in the current keyring (`pacman-key --list-sigs @archlinux.org`) or in the current HEAD of archlinux-keyring (`./keyringctl inspect ` in a clone of the archlinux-keyring repository). If you have signatures that are not yet in the keyring, you can add them yourself [2] and do not have to wait on a main signing key holder to do it. To all that have created a new key, please make sure to setup the correct PGP key ID in your archweb profile so that the website displays the signatures correctly [3]. If you have gained more than or equal to three main key signatures for your new PGP key and the key as well as those signatures are already available in the keyring in [core] please rebuild all of your packages using your new key and start the process of having your old key removed [4]. For the purpose of mass package rebuilding you may create a TODO [5] and use `rebuild-todo` (in the archlinux-contrib package) which makes use of our build server infrastructure. I have not yet gotten a response from or have not yet been able to resolve my request with the following packagers (nickname in the archlinux-keyring repository): - bgyorgy - archange - arodseth - kylekeen - daurnimator - pierre - farseerfc Please make some time to create a new key/ UID/ or get signed, as Allan would like to revoke his signing key in the near future (which may mean the inability to sign packages and mass rebuild of packages in question) as soon as the above packager signature situation has stabilized. In case you have questions, feel free to reach out in #archlinux-staff on libera.chat or via mail. If you are interested in helping further develop keyringctl, have a look at the relevant open tickets [6]. Best, David [1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/#usage [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/Add-a-new-Signature [3] https://archlinux.org/master-keys/#master-sigs [4] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/Remove-a-packager-key [5] https://archlinux.org/todo/add/ [6] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues?scope=all&state=opened¬[label_name][]=new%20packager%20key¬[label_name][]=remove%20packager%20key¬[label_name][]=new%20main%20key¬[label_name][]=remove%20main%20key -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Updates to archlinux-keyring and signatures for packager keys
On 2022-01-14 16:57:00 (-0800), Brett Cornwall via arch-dev-public wrote: > On 2022-01-14 21:12, David Runge via arch-dev-public wrote: > > To all that have added a new @archlinux.org UID or have created a new > > key, please make sure that all signatures you have received from main > > signing keys are also present in the current keyring (`pacman-key > > --list-sigs @archlinux.org`) or in the current HEAD of > > archlinux-keyring (`./keyringctl inspect ` in a clone of the > > archlinux-keyring repository). If you have signatures that are not yet > > in the keyring, you can add them yourself [2] and do not have to wait on > > a main signing key holder to do it. > > Thanks for your work on this initiative. > > I see that my key has made it but the trust is only marginal: > > > [~]$ pacman -Q archlinux-keyring > archlinux-keyring 20220114-1 > [~]$ pacman-key --list-sigs ain...@archlinux.org > gpg: Note: trustdb not writable > pub ed25519 2018-10-03 [SC] [expires: 2022-07-18] > BE2DBCF2B1E3E588AC325AEAA06B49470F8E620A > [snip] > uid [marginal] Brett Cornwall > sig 3 A06B49470F8E620A 2021-11-18 Brett Cornwall > sig 4DC95B6D7BE9892E 2021-11-20 David Runge (Arch Linux Master Key) > Your @archlinux.org UID currently has marginal trust, as it is only signed by one main signing key (needs three signatures for full trust). Your other UID still has full trust though, which means that your key in general is still fully trusted! However, we would like to have signatures on the @archlinux.org UID only in the future of course :) If you have received more signatures for your @archlinux.org UID by now, you can add those via a merge request (see previous email). Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Upcoming PHP 8.1 update
On 2022-01-16 16:40:00 (+0100), Pierre Schmitz via arch-dev-public wrote: > So far everything looks fine. I am even using PHP 8.1 in production > for a week now, without any issues. So I'd like to move the packages > to [extra]. > > The remaining blocker is nextcloud though. What is the best option to > resolve this? > 1) Remove the version constraint > 2) same as above + try to apply the upstream patch: > https://github.com/nextcloud/server/pull/29862 I'll look into 1 or 2 asap. Sorry, I have been pre-occupied with other packages/work. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
