I like that project. However, why would we need a new server? Can't we use the space and bandwidth of an existing host? I'm not too knowledgeable about our current servers so maybe Florian could shed some light on that. The script seems fairly manageable and you already provide systemd stuff and everything. +1 from me if we don't need a new server. On Sat, Oct 17, 2015 at 9:02 PM, Sébastien Luttringer wrote:

Hello,

More than one year ago[1] we started to discuss making the Arch Rollback Machine more official. There were pros and cons and I would give us the opportunity to move forward.

ARM was renamed to Archlinux Archive, following suggestions made earlier. The ALA acronym is now preferred to avoid confusion with the ARM architecture. AUR part was removed, the last/month/week links are optional.

The Archive project is basically a daily snapshot of our official repositories and ISOs. A description of it if available on our Wiki[2]. Of course this could be improved by anyone who want to help.

Today, this is used for hunting bugs (testing previous working package, bisecting at the system scale), rescue systems when broken package are pushed. Tomorrow, this may provide a ground for reproductible builds.

The project code base[3] is really simple (it's one bash script) and running a server don't need much maintenance. I was designed keeping that in mind. I got few donations over the year to provide this service and one request to create a mirror.

So far, the disk space used is: # du -hcs iso packages repos/* 60G iso 2,0G packages 110G repos/2013 254G repos/2014 204G repos/2015

Some concerns raised about the place of agetpkg[4] in our official repository so I deleted it. agetpkg is a command line tool used to easily download previous versions of packages for debugging purpose. For example, with the new gnome 3.8 release, the VFS access to smb shares was broken. It was really fast and easy to downgrade all gvfs package to a previous version to confirm (e.g: agetpkg -i gvfs 1.26.0 3)

Let me share the questions I got about the project so far and my answers.

Q: We will support old packages? A: No. Nothing change. We already have to check when people report bugs they upgraded their system to the last version.

Q: We will support partial upgrade? A: No.

Q: User will become lazy and stop report bugs A: I don't believe that providing more tools to test will make them stop reporting. The local cache already stop them to report.

Q: This will add more unwanted works? A: ARM exists for years. Users already use AUR packages, unofficial repositories and non-stock kernels and this didn't change our way of rejecting incorrect requests.

Q: This will lighten your sysadmin time. That's why you want to move it as an Archlinux project. A: Not at all. Firstly because I still plan to maintain the Archive for the Arch project. Moreover, I started another Archive server for my company.

Q: If you quit the Archlinux project, we will have to maintain it. A: Even though I'm not leaving, as soon as nobody want to maintain a service in arch, stopping it is easier than starting it.

The plan I propose for now: - Add a new server[5][6] to our farm (fsociety.archlinux.org?). - Move archivetools and agetpkg git repositories into project.al.org - Add archive.al.org - Adding agetpkg back to our repositories - News announcement. With all the warnings about our policy about downgrades.

Cheers,

[1] https://lists.archlinux.org/pipermail/arch-dev-public/2014-March/02 6011.html [2] https://wiki.archlinux.org/index.php/Arch_Linux_Archive [3] https://github.com/seblu/archivetools [4] https://github.com/seblu/agetpkg [5] http://www.online.net/en/dedicated-server/dedibox-md [6] http://www.online.net/en/dedicated-server/dedibox-classic

-- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A

[2015-10-17 21:02:00 +0200] Sébastien Luttringer:

More than one year ago[1] we started to discuss making the Arch Rollback Machine more official. There were pros and cons and I would give us the opportunity to move forward.

I think this is great. You've now been running that project unofficially for a while anyhow, so I don't see anything left for us to do other than put our official stamp on it. The only potential reason why we wouldn't want do that is if we didn't find that project useful, but I do not think anyone here believes it isn't. I just have one question. What is "fsociety.archlinux.org" for? Could it follow our current naming scheme? Is it different from "archive.al.org"? Cheers! -- Gaetan

On Sat, Oct 17, 2015 at 9:20 PM, Gaetan Bisson wrote:

[2015-10-17 21:02:00 +0200] Sébastien Luttringer:

...

Q: We will support old packages? A: No. Nothing change. We already have to check when people report bugs they upgraded their system to the last version.

I note that we provide aur.archlinux.org as a service to the community, but with a big warning that AUR packages are not supported. To me, your project would be exactly the same: we'd provide an archive.archlinux.org service (with associated helper scripts) but it would come with big warnings that this is for diagnosis purposes only, and that outdated packages are not supported.

Cheers.

-- Gaetan

My question about this is if we allow this into the repositories, an ability to go get unsupported package easily to install on your system even with a warning about the fact that they are not supported... can we put AUR helpers into the repositories? Maybe not ones that do all the compiling for you, but something like cower that just goes and gets the source. If we can't put in something for the AUR, then I don't think we should have this package in any of the repos either. I don't have a problem with putting the archive as a supported project, but if it is basically coming under the same rules as the AUR... should the tools to get the packages have different rules? Just my 2¢ Daniel

On Sun, Oct 18, 2015 at 10:41 AM, Florian Pritz wrote:

On Sat, 17 Oct 2015 22:46:49 +0200 Sven-Hendrik Haase wrote:

...

I like that project. However, why would we need a new server? Can't we

...

the space and bandwidth of an existing host? I'm not too knowledgeable about our current servers so maybe Florian could shed some light on

use that.

nymeria has about 500gb free space so that's not enough. luna and celestia only have 240gb ssd storage each.

At least a couple months ago Hetzner said upgrading an EX40 to an EX40-hybrid is possible so I guess we could ask them if they can also add the hdds to celestia. Doing so would raise the price from 59€/month to 69€/month. That would give us 2TB of additional storage, but I don't know if we'd want to host the archive on the build server. Opinions?

Florian

I think this quite a fine solution if that's possible from Hetzner's side. I don't mind the stuff being hosted on the build server. In fact, it's probably a good candidate because it doesn't really need its bandwidth anyway except for short periods of time when people upload packages and the other resource requirements probably won't conflict. Especially so since the data of this project would be hosted on another set of disks. Apart from that, I don't see anything wrong with adding cower to the repos along with a helper to download old packages as suggested by Daniel (but lets keep the discussion about the AUR helper stuff in another thread).

On Sat, 2015-10-17 at 21:26 -0500, Daniel Wallace wrote:

On Sat, Oct 17, 2015 at 9:20 PM, Gaetan Bisson wrote: My question about this is if we allow this into the repositories, an ability to go get unsupported package easily to install on your system even with a warning about the fact that they are not supported... can we put AUR helpers into the repositories?

There is an important difference between our outdated packages and external packages, which may not have the level of quality and trust we expect in official repositories. Moreover, an AUR package is potentially harmful, where outdated package aren't.  AUR helpers you mention are used to get external contents, where agetpkg helps to retrieve previous packages in order to troubleshoot or rescue a broken system. There is nothing more allowed that you can already do with pacman -U /var/cache/pacman/pkg/X. So, in my opinion, adding AURs helpers it's a different topic. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A

On sam., 2015-10-17 at 21:02 +0200, Sébastien Luttringer wrote:

More than one year ago[1] we started to discuss ...

I made a speech during our last Meetup in Paris about Arch Linux Archive and agetpkg. Slides are available here: http://slides.com/seblu/arch-linux-archive Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A

On 20/12/15 09:26, Sébastien Luttringer wrote:

I plan to move back agetpkg to extra next week if there is no objection.

I am assuming agetpkg is for dealing with archived packages (which are unsupported). The reasonv for not including AUR helpers in the repos was that they give what appears like supported access to unsupported content. Why should agetpkg be considered any different? A

On 20/12/15 10:09, Sébastien Luttringer wrote:

On dim., 2015-12-20 at 09:32 +1000, Allan McRae wrote:

...

On 20/12/15 09:26, Sébastien Luttringer wrote:

...

I plan to move back agetpkg to extra next week if there is no objection.

I am assuming agetpkg is for dealing with archived packages (which are unsupported). The reasonv for not including AUR helpers in the repos was that they give what appears like supported access to unsupported content. Why should agetpkg be considered any different?

I think there is a difference between outdated official packages and non- official packages. The last may not have the level of quality, trust and be harmful for a system. So preventing helpers to be in official repository make sense.

Outdated packages may be very harmful to your system - there are plenty with critical bugs in them. So the argument is that we trust these to be harmful to your system?

In the other hand, agetpkg helps to retrieve previous official packages in order to troubleshoot or rescue a broken system when they are missing in /var/cache/pacman/pkg/X.

I think what is not supported is non-official packages and reporting issues about non up-to-date packages, not downloading an outdated one.

The argument about AUR helpers is that we should not provide supported access to unsupported content, because this makes the unsupported content appear supported. I don't see the different here. A