On Monday there was a news on Arch Linux site (https://archlinux.org/news/git-migration-announcement/), where one of points was merging [community] into [extra]. Would it have any impact on Artix repositories?
Yes, the current plan is to follow suit and merge galaxy into world.
Are there any other changes in PKGBUILDs repos structure? It seems main/desktop/addons/initsys repos are gone, how do i access PKGBUILDs in ARMtix build system now?
For Arch Linux PKGBUILD's, if those are of interest, this is the replacement to ASP:
https://gitlab.archlinux.org/archlinux/devtools (https://gitlab.archlinux.org/archlinux/devtools)
pkgctl repo clone will get the PKGBUILD's from here, looking at src/lib/common.sh, afaict:
https://gitlab.archlinux.org/archlinux/packaging/packages (https://gitlab.archlinux.org/archlinux/packaging/packages)
It also might not work in Artix without modification as there are some refs to /etc/pacman.d/mirrorlist which would be mirrorlist-arch in Artix as one obvious thing I saw while looking for that info, in config/pacman/extra.conf.
That's not what i asked actually. ARMtix build system heavily relies on the existence of some monorepo(s) with sources for all packages to fetch updates from and put packages in build queue. The thing is, packages with arm-specific patches also live in a monorepo and a patched package can only be built if it was simultaneously updated in both monorepos.
Without monorepos from Artix this logic breaks. The only way for me to fetch packages becomes fetching list of all repos from gitea and syncing my local list with it. To me this sounds like a very poor logic and also requires a major change in build system, and i'm not sure how much time it may requiere to implement it. Looks like ALARM project also faces this problem now.
As such, may i ask Artix development team to keep some monorepo for ARMtix builds? I think, it can be updated via CI to reduce manual intervention
Thank you for the explanation, I've also been following this with interest to see where PKGBUILD's in general will be located, and wasn't sure if that would be helpful or not to you.
$ git clone https://gitea.artixlinux.org/packagesL/less.git
Cloning into 'less'...
remote: Not found.
http://ix.io/1wrX (http://ix.io/1wrX)
Looks like the gitea server is being rearranged and the packages(suffix) structure has disappeared, hence Yaourtix will need modification - I was going to suggest you could copy that concept and loop through a list of packages to retrieve the pkgbuilds if you had to, but some other approach might be required now when things settle down and a pattern can be established to programmatically determine the URL to clone from.
Yeah there's several ongoing changes right now.
The letter suffix is being dropped from the urls so it should be just https://gitea.artixlinux.org/packages/package.git now. Something like packagesPython might remain for python packages though. Not sure.
Yeah those superrepos are no longer going to be used. Arch's new monorepo is the state repo (https://gitlab.archlinux.org/archlinux/packaging/state) in gitlab now. I think we'll probably end up with something similar. It's still a work in progress though.
If I could just make the humble request from the Artix devs to provide us users with a general guideline on what adjustments to our configuration files once the migration has been completed. It would obviously be super helpful.
Thank you all always for your hard work in maintaining this distribution that I've called home for nearly two years now. It's run smoothly and the community here has been very helpful whenever I've run into small issues. ☮️
https://artixlinux.org/news.php#Repository_changes
Hi, are there any updates on this? Is some sort of state repo planned or it won't be implemented?
Sorry about that. Yeah, we've been trucking along OK without such a repo so I'm thinking it probably won't happen. You could try writing a tool that uses libalpm to query the databases directly. Here's an example of what we're using for Arch/Artix differences: https://gitea.artixlinux.org/Qontinuum/checkupdates (https://gitea.artixlinux.org/Qontinuum/checkupdates)
I have used the packages link https://packages.artixlinux.org/ to find PKGBUILDS in the past and recently found I couldn't see the sources of the runit package. That was called an obscure bug (see https://forum.artixlinux.org/index.php/topic,5471.0.html).
I now find that all the links I test are returning 404; I assume that linux version marked as 5.16.16.artix1-1 and dated 2022-03-22 12:25:22 just means the search pages are unmaintained.
While the sources are being re-organised I assume that I'm looking at the wrong place. Where can I find the PKGBUILD sources?
We not gonna have a centralized state repo any time soon.
However, we will go intermediate before any server side state repo, and have a repo tracking yaml file in the package git repo.
Monorepos are gone, we maybe have a bot to assemble a monorepo later on, for pure user convenience, but it is atm not the most pressing issue.
https://gitea.artixlinux.org.
It's been reorganised.
The links on https://packages.artixlinux.org will need updating at some point
Just search directly on gitea
packages.artixlinux.org is not even maintained. Unfortunately it still seems to be linked on the front page for some reason (thought someone removed that).
thanks, is there any way to search for an exact package name? A search for runit gives a very large number of hits. I tried putting a space at the front, but it seems as though it's stripped out.
Here's a workaround. Go straight to the package's repo page directly: https://gitea.artixlinux.org/packages/$PKG (https://gitea.artixlinux.org/packages/runit)
Every package is in this group now, which makes locating packages easier.
is the migration over?
if it isnt could you make a news post when it is fully completed
i would like to know when i can remove [galaxy] and only have [world]
It is, as far as the repo structure is concerned. Our packaging tools are still being worked on, a few rough edges to address.
Don't touch any repos yet; [universe] will probably move into [galaxy] and still not decided what will become itself. An announcement will be made in due time.
So while this migration is going should users report warnings like
docker-runit: local (20220411-2) is newer than world (20180314-4)
these warnings will not impact users much. So my concern is would report of such warnings put extra unnecessary pressure on dev team.
Look at the context.
If you had
docker-runit: local (20220411-2) is newer than world (20220411-1)
then probably not.
But in your example the package in world looks to be four years older than your version so maybe worth reporting ?
I'd be wondering where 20220411-2 came from and where it's gone.
But if you look at the commits you can see it already been sorted. https://gitea.artixlinux.org/packages/docker-runit/commits/branch/master
Possibly due to your report ?
Sorry if I'm offtoping, but wouldn't it be easer to have just one repo for inits, init-daemons and recompiled systemd packages and rely on arch repos for the rest? Repackaging everything seems like a double-job.
This was how things started out, using more from Arch, however users often needed to upgrade / downgrade / ignorepkg to fix temporarily broken packages (or wait and update again later) due to version dependency mismatches between repos when they updated, there was often a window of a few minutes or hours before builds completed and got synced around.
I see. I've just found out some packages are outdated - like nvidia driver (535 on Arch and 530 on artix) and base linux kernel (6.3-8 arch, 6.3-6 artix) and that made me think relying on arch repos would be better solution.
hows the migration going?
I'm guessing great, but a small donation would definitely go a long way in helping the team :)
Going strong, no worries.