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 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.

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

On Sun, 2015-10-18 at 11:49 +0200, Sven-Hendrik Haase wrote:

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).

The archive server is io-bound[1], and use network bandwidth to snapshots repositories and serve files through http. When the build server is cpu-bound with few network traffic and may suffer of the archive disk usage. A year of snapshots is about 460GiB, so we can host 2 years of snapshot on a 1TB server. So, my preference would go to take one separate server with unlimited traffic and dedicated disks. OVH and Online.net lease these kind of servers (don't find such at Hetzner). If we go trough this option, I suggest this one: * Online: Xeon E3 1220v2, 16GB RAM, 2x1TB, 300Mbps, 29€ HT [2] but cheaper alternatives may also fit (with no RAID). * OVH: i5-750 2.6GHz, 16GB RAM, 1x2 To HDD, 100 Mbps, 14,99 € HT [3] * Online: Intel C2750, 8GB RAM, 1x1To HDD, 200Mbps, 15.99€ HT [4] Upgrading celestia is also a suitable solution. Cheers, [1] See attached graph for metrics [2] http://www.online.net/en/dedicated-server/dedibox-classic [3] https://www.kimsufi.com/uk/ [4] http://www.online.net/en/dedicated-server/dedibox-xc -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A

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 ven., 2015-12-18 at 20:10 +0100, Sébastien Luttringer wrote:

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,

Hello, archive.archlinux.org is online. I pushed a new release of agetpkg, with the new Archive URL. I plan to move back agetpkg to extra next week if there is no objection. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A

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. 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. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A