Re: [arch-dev-public] New build server in the US?

[Eli Schwartz via arch-dev-public]

On 04/19/2018 03:19 PM, Florian Pritz via arch-dev-public wrote:
> We already have a second build server (sgp.pkgbuild.com) which is hardly
> used. Souyz is really used quite a bit, but in general it has quite some
> resources left to spare. I guess it depends on what you want and when.
> Do you want to get builds done quickly (like on a local machine) or are
> you happy with waiting until the machine is free? Maybe someone wants to
> work on a system that allows to pause builds if people don't care when
> they finish so that those that want them done quickly get priority? That
> way we could possibly use our available resources better. Maybe it's
> even as simple as queuing builds, but I don't know how long the builds
> that people run on soyuz take. If a single build takes an hour, queuing
> won't really work.
> 
> Some feedback on how people use soyuz would probably help a lot here.
> What are your build times, how quickly do you want the result, do you
> need to see live output, does the latency to the machine matter
> (interactive usage?), ...?

I usually only use soyuz for annoyingly long builds like my custom repo
with glibc-git, thunderbird-gtk2, etc. which can take as long as it
needs to (assuming I remember to run it in tmux so it doesn't die when I
lose internet).

> Is anyone interested in taking on this project and maybe also setting
> up/maintaining some build service if that turns out to be a good idea?

We could probably do something dead simple with a wrapper script that
checks pgrep makechrootpkg || sleep 1m in a loop, before running a
build. Anyone with a build they just want to run as soon as no one else
is doing one, could use that.

Just run it in tmux in case of latency/disconnection.

> Regarding the OSUOSL idea: I'm slightly against getting machines from
> yet another organisation. While it doesn't matter much during normal
> operation, fixing problems is usually more difficult because things like
> getting a live system booted, getting serial console access or even just
> getting support are often not easily possible when servers are hosted at
> companies that don't see hosting as a core goal. We've had this happen
> before and it's not great. I don't know what the situation is for this
> offer, but let's not rush into creating even more work for us.
> 
>> I honestly have no idea about Arch's financial situation, or how soyuz is
>> paid for in practice.
> 
> Soyuz is a rented server at hetzner.de (like all our other important
> servers) and payed for with donation funds.
> 
> Looking at a recent treasury report from SPI[1] we have around $47k
> right now and looking back a few months, it seems to be growing.
> 
> [1] http://lists.spi-inc.org/pipermail/spi-general/2018-April/003845.html

I guess we could afford to rent another server if we really needed one!

But I guess it is probably more used by people with large packages, in
which case faster builds was the reason they decided to use soyuz in the
first place.

We could just upgrade soyuz. I think that might double what we're
currently paying, but OTOH so would buying a second server.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Archweb (archlinux.org) upgrade

[Giancarlo Razzolini via arch-dev-public]

Em abril 19, 2018 17:52 Andrew Crerar escreveu:




Good luck folks! I'll be watching :)

Slightly OT but do we have staging servers for testing archweb or is the roll
out pretty much cutting a release from GitHub and deploying?



Hi Andrew,

Thanks to the awesome work Jelle did, we have a staging env on 
https://archweb-dev.archlinux.org/.

We used it, plus some other things, to test this upgrade. Of course, things can 
still go wrong,
which is why we plan to bring the site under maintenance mode and take a full 
backup before anything
else is done.

Regards,
Giancarlo Razzolini

pgpIYbK36bhnZ.pgp
Description: PGP signature

Re: [arch-dev-public] Archweb (archlinux.org) upgrade

[Andrew Crerar]

On 4/19/18 4:37 PM, Giancarlo Razzolini via arch-dev-public wrote:
> Em abril 19, 2018 17:04 Jelle van der Waa escreveu:
>> Hi all,
>>
>> Tommorow evening we will be updating https://archlinux.org (archweb), so
>> expect some downtime due to upgrading. Since it's a major version bump
>> 1.8 => 1.11 some issues might occur, but in general it should be a
>> smooth upgrade (tm).
>>
>> P.S. Next up is porting archweb to Python 3, any help is appreciated!
>>
> 
> Hi all,
> 
> I expect we should have a downtime of about 1-2 hours. If you notice anything
> different post upgrade, please let us know. Both me and Jelle are going to 
> probably
> be around on IRC too during the upgrade.
> 
> Regards,
> Giancarlo Razzolini
> 

Good luck folks! I'll be watching :)

Slightly OT but do we have staging servers for testing archweb or is the roll
out pretty much cutting a release from GitHub and deploying?

Regards,

Andrew



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Archweb (archlinux.org) upgrade

[Giancarlo Razzolini via arch-dev-public]

Em abril 19, 2018 17:04 Jelle van der Waa escreveu:

Hi all,

Tommorow evening we will be updating https://archlinux.org (archweb), so
expect some downtime due to upgrading. Since it's a major version bump
1.8 => 1.11 some issues might occur, but in general it should be a
smooth upgrade (tm).

P.S. Next up is porting archweb to Python 3, any help is appreciated!



Hi all,

I expect we should have a downtime of about 1-2 hours. If you notice anything
different post upgrade, please let us know. Both me and Jelle are going to 
probably
be around on IRC too during the upgrade.

Regards,
Giancarlo Razzolini

pgpBN_PNnMuo4.pgp
Description: PGP signature

[arch-dev-public] Archweb (archlinux.org) upgrade

[Jelle van der Waa]

Hi all,

Tommorow evening we will be updating https://archlinux.org (archweb), so
expect some downtime due to upgrading. Since it's a major version bump
1.8 => 1.11 some issues might occur, but in general it should be a
smooth upgrade (tm).

P.S. Next up is porting archweb to Python 3, any help is appreciated!

-- 
Jelle van der Waa


signature.asc
Description: PGP signature

Re: [arch-dev-public] New build server in the US?

[Gaetan Bisson via arch-dev-public]

[2018-04-19 21:19:43 +0200] Florian Pritz via arch-dev-public:
> Some feedback on how people use soyuz would probably help a lot here.
> What are your build times, how quickly do you want the result, do you
> need to see live output, does the latency to the machine matter
> (interactive usage?), ...?

For my own limited use, short build times are what matters most: if a
build is slowed down or delayed I'll likely have forgotten about it by
the time it's finished.

I'm glad you mentioned the Singapore server was underused. I've switched
my build scripts to using it since I'm the same ping time away from it
and soyuz.

Cheers.

-- 
Gaetan


signature.asc
Description: PGP signature

Re: [arch-dev-public] New build server in the US?

[Florian Pritz via arch-dev-public]

On 18.04.2018 13:27, Baptiste Jonglez wrote:
> OSUOSL [1] in the US has several "new" refurb servers with dual Xeon E5-2660.
> Each machine has a total of 16 cores / 32 threads and 140 GB RAM, so that
> would make nice build machines.
> 
> Would this be useful to the dev community?  Soyuz is a bit overloaded at
> times, and people in the US/Canada might appreciate the lower latency.

We already have a second build server (sgp.pkgbuild.com) which is hardly
used. Souyz is really used quite a bit, but in general it has quite some
resources left to spare. I guess it depends on what you want and when.
Do you want to get builds done quickly (like on a local machine) or are
you happy with waiting until the machine is free? Maybe someone wants to
work on a system that allows to pause builds if people don't care when
they finish so that those that want them done quickly get priority? That
way we could possibly use our available resources better. Maybe it's
even as simple as queuing builds, but I don't know how long the builds
that people run on soyuz take. If a single build takes an hour, queuing
won't really work.

Some feedback on how people use soyuz would probably help a lot here.
What are your build times, how quickly do you want the result, do you
need to see live output, does the latency to the machine matter
(interactive usage?), ...?

Is anyone interested in taking on this project and maybe also setting
up/maintaining some build service if that turns out to be a good idea?

Regarding the OSUOSL idea: I'm slightly against getting machines from
yet another organisation. While it doesn't matter much during normal
operation, fixing problems is usually more difficult because things like
getting a live system booted, getting serial console access or even just
getting support are often not easily possible when servers are hosted at
companies that don't see hosting as a core goal. We've had this happen
before and it's not great. I don't know what the situation is for this
offer, but let's not rush into creating even more work for us.

> I honestly have no idea about Arch's financial situation, or how soyuz is
> paid for in practice.

Soyuz is a rented server at hetzner.de (like all our other important
servers) and payed for with donation funds.

Looking at a recent treasury report from SPI[1] we have around $47k
right now and looking back a few months, it seems to be growing.

[1] http://lists.spi-inc.org/pipermail/spi-general/2018-April/003845.html

Florian



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] linux-manpages

[Andreas Radke via arch-dev-public]

Am Sat, 31 Mar 2018 14:01:03 +0200
schrieb Andreas Radke via arch-dev-public
:

> The recent docs are available online here:
> https://www.kernel.org/doc/html/latest/#
> 
> Should we keep packaging this at all or drop it? Is there anybody who
> want to take this package over? I'm not interested in packaging this
> though maintenance work is low.
> 
> 
> -Andy

I'm going to drop it from the repos within the next 48hours if nobody
jumps in. Online docs are available. I see no need to keep packaging
this.

-Andy


pgpktDbVMTvDQ.pgp
Description: Digitale Signatur von OpenPGP