[arch-dev-public] News draft: nvidia 455.28 is incompatible with linux >= 5.9

[Sven-Hendrik Haase via arch-dev-public]

nvidia is currently partially incompatible with linux >= 5.9 [1][2].
While graphics should work fine, CUDA and OpenCL are broken. Users
who've already upgraded and need those features are advised to switch to
the linux-lts kernel for the time being.

[1]
https://forums.developer.nvidia.com/t/nvidia-driver-not-yet-supported-for-linux-kernel-5-9/157263
[2] https://bugs.archlinux.org/task/68312



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Autumn extra cleaning

[Sven-Hendrik Haase via arch-dev-public]

On 12.10.20 17:49, Archange wrote:
> Le 05/10/2020 à 09:16, Sven-Hendrik Haase via arch-dev-public a écrit :
>> hunspell-fr
>> hyphen-fr
>> mythes-fr
> 
> I could take those ones if moved, and since apparently we already have
> some for other languages in [community]…
> 
> I’ll also take libpano13 once moved, only required for hugin.
> 
> Archange
> 

All moved.



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Autumn extra cleaning

[Sven-Hendrik Haase via arch-dev-public]

On 05.10.20 11:29, Justin Kromlinger via arch-dev-public wrote:
> On Mon, 5 Oct 2020 07:16:14 +0200
> Sven-Hendrik Haase via arch-dev-public 
> wrote:
> 
>> xournalpp
> 
> I can adopt it when it gets moved into [community].
> 

I just moved it.



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Autumn extra cleaning

[Sven-Hendrik Haase via arch-dev-public]

On 05.10.20 08:02, Antonio Rojas via arch-dev-public wrote:
> El lunes, 5 de octubre de 2020 7:16:14 (CEST), Sven-Hendrik Haase via
> arch-dev-public escribió:
>> Hey everyone,
>>
>> It was suggested as part of this year's spring cleanup of [community]
>> that we should be have a cleanup in [core]/[extra] and move packages
>> downwards into [community].
>>
>> This round only concerns [extra] packages.
>>
>> Devs that want the packages in [extra], please adopt packages, and TUs
>> can notify which packages they are interested to maintain in [community]
> 
> That list contains many packages that are dependencies of other packages
> in [extra]. Do we officially no longer care about repo hierachy?

It does and in such a case I see four options in case no [extra]
maintainer comes and picks it up:

1) Not care about repo hierarchy and move the dep regardless
2) Encourage maintainers of packages that need those packages to just
pick up the orphaned deps
3) Move the whole dep chain to [community]
4) Do nothing and have unmaintained packages just sitting there

I think out of all of these, 4) is the worst option. I'd prefer 2) as
it'd be the most seamless. I'm torn between 1) and 3) but if repo
hierarchy is a hard constraint, there's only 3).



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] Autumn extra cleaning

[Sven-Hendrik Haase via arch-dev-public]

Hey everyone,

It was suggested as part of this year's spring cleanup of [community]
that we should be have a cleanup in [core]/[extra] and move packages
downwards into [community].

This round only concerns [extra] packages.

Devs that want the packages in [extra], please adopt packages, and TUs
can notify which packages they are interested to maintain in [community]

Orphaned packages in [extra]:

a2ps
aalib
abook
adwaita-icon-theme (Jan can you just take this?)
antlr2
antlr4
arch-install-scripts
asp
aspell-es
bzflag
c-ares
chromaprint
cln
cmark
convertlit
cvs
cvsps
davfs2
dcraw
enca
expac
fakechroot
farstream
fastjar
font-bh-ttf
freetds
fvwm
geeqie
giblib
gifsicle
gnugo
gperftools
graphene
gsfonts
gstreamer
gtksourceview4
gts
gupnp-igd
gv
hddtemp
hunspell-fr
hunspell-it
hunspell-ro
hyphen-fr
hyphen-it
icewm
id3lib
ifplugd
ispell
java-activation-gnu
java-bcel
java-commons-net1
java-gnumail
java-hamcrest
java-inetlib
java-jdepend
java-jline
java-jsch
java-resolver
java-rhino
joe
jpegexiforient
junit
leveldb
libatomic_ops
libkate
liblqr
libmilter
libmng
libnet
libnice
libnma
libofa
libots
libpano13
libspiro
libstroke
libtiger
libtommath
libuninameslist
libusb-compat
lua51
lua52
m17n-db
mercurial
mtools
munin
munin-node
mysql-python
mythes-fr
mythes-it
mythes-ro
nawk
netpbm
npapi-sdk
nss-mdns
ocamlbuild
opencore-amr
perl-http-daemon
pkgfile (I suggest we just drop this in favor of pacman -F)
potrace
psiconv
python2-cairo
python2-numpy
python2-ordered-set
python2-setuptools
rcs
rhino
rhino-javadoc
screen
shared-color-targets
snappy
snarf
swt
tcl
telepathy-farstream
telepathy-idle
telepathy-salut
time
tinycdb
tk
ttf-junicode
ttf-linux-libertine
uim
usbmuxd
vcdimager
vim-spell (and its 50 split packages)
w3c-mathml2
x11-ssh-askpass
x11vnc
xalan-java
xerces2-java
xine-lib
xine-ui
xmltoman
xorg-font-util
xorg-xfontsel
xorg-xlsfonts
xournalpp
yajl

Thanks to Morten for ghostwriting this. ;)

Cheers,
Sven



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs

[Sven-Hendrik Haase via arch-dev-public]

On Tue, Aug 25, 2020, 21:59 Evangelos Foutras via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> I am not sure these serve any purpose. The maintainer line duplicates
> information available from the archweb or aur interfaces and could
> also be outdated. The contributor lines are mostly redundant with svn
> or git history, can take up several lines in the PKGBUILD and can
> become irrelevant after significant refactoring.
>
> What are your thoughts on dropping all these seemingly unnecessary
> lines from our official PKGBUILDs? Anyone feel strongly about keeping
> them (and why)?
>

I agree with your reasoning and am all in favor.

Sven

>

Re: [arch-dev-public] [aur-general] AUR migration

[Sven-Hendrik Haase via arch-dev-public]

On 24.07.20 23:27, Eli Schwartz via arch-dev-public wrote:
> On 7/24/20 3:24 PM, Giancarlo Razzolini via arch-dev-public wrote:
>> Em julho 23, 2020 17:09 Giancarlo Razzolini via aur-general escreveu:
>>> Hi All,
>>>
>>> In continuing with the improvements being done to our infrastructure,
>>> we're
>>> planning to migrate the AUR to another machine. This means that,
>>> during the migration,
>>> there *will* be downtime of the whole AUR.
>>>
>>> I expect the migration to take around two hours and happen either
>>> tomorrow (Friday)
>>> or on Saturday, depending on availability.
>>>
>>> Regards,
>>> Giancarlo Razzolini
>>>
>>
>> The migration is almost done. Since we are moving to a new machine, it will
>> have new host keys. They are:
> 
> This seems like it could be a reasonable situation for posting to
> https://www.archlinux.org/news/ so that people seeing the keys change
> understands why and that it's okay. Not everyone follows a-d-p or
> aur-general.
> 
> Thoughts?
> 

+1



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Abandoning all my vim-* plugin packages

[Sven-Hendrik Haase via arch-dev-public]

On Wed, 18 Mar 2020 at 20:40, Sven-Hendrik Haase 
wrote:

> I've started using a vim plugin manager and don't use my packages anymore.
> They need a new home. Please show these packages some love:
>
> * vim-a
> * vim-colorsamplerpack
> * vim-doxygentoolkit
> * vim-guicolorscheme
> * vim-minibufexpl
> * vim-omnicppcomplete
> * vim-project
> * vim-taglist
> * vim-vcscommand
> * vim-workspace
>
> The packages are pretty low maintenance but I'd prefer if someone who
> actually uses them maintained them.
>
> Anything that's not taken within 2 weeks will be dropped to AUR.
>

Welp, I forgot about this but these are now dropped to AUR.

Re: [arch-dev-public] GitLab switchover and SSO migration

[Sven-Hendrik Haase via arch-dev-public]

On 17.05.20 22:37, Lukas Fleischer via arch-dev-public wrote:
> On Sun, 17 May 2020 at 14:39:25, Sven-Hendrik Haase via arch-dev-public wrote:
>> As some of you know, we've been toying with two ideas for a while:
>> Arch-wide centralized user management as well as using GitLab to
>> consolidate some of our current services. The overall goal is manifold.
>> In no particular order, the goals are to
>> - make Arch more contributor friendly
>> - provide more modern tools for ourselves
>> - enable more automation
>> - make Arch services more secure
>> - make team management activities less error-prone and more streamlined
> 
> Great! Thanks a lot for working on this!
> 
>> After looking at various solutions, we eventually settled on Keycloak
>> since it seemed like a modern, well-maintained, and secure piece of
>> software. It allows us to enable logins for services via OpenID Connect
>> and SAML which is likely the best coverage we could hope for. It also
>> allows us to connect other social login providers such as github.com and
>> gitlab.com and it supports Recaptcha, 2FA, and WebAuthn out of the box.
>> The idea is to eventually transition all our online service as well as
>> SSH keys to Keycloak to ease on-/offboarding and make it less error-prone.
> 
> Is 2FA going to be opt-in? Will it be mandatory for members of the
> staff? You mentioned increased security before but having a single
> password also increases the attack surface in case a password is stolen.
> 

The current idea is to make 2FA mandatory for all staff (because let's
face it, we have a lot of staff and a single hacked staff account could
cause A LOT of trouble).
As of right now, only DevOps people are forced to use 2FA but this
requirement will be expanded soon. For ease of collaboration, we're not
planning to force outside contributors to use 2FA for the time being but
we'll monitor that situation.

>> 1) Transition as many staff-only services to Keycloak as possible. We
>> looked at our current services and put up a table on the wiki that shows
>> support per service [2].
>> Some of the services that we operate are deprecated or have
>> functionality that is also provided by GitLab. In our current
>> understanding, this concerns Flyspray, Kanboard, and Patchwork. Of
>> those, Kanboard and some of the Flyspray projects will be our first
>> targets to transition to GitLab. We'll continue using Flyspray for the
>> time being for package bugs but will discontinue its use for all
>> non-packaging bugs. The reason for this is that how we manage our bugs
>> for packages is somewhat intertwined with the svn2git migration which is
>> yet to be done and might dictate a different repo structure than what we
>> would come up with currently and we don't want to block on this. This
>> was also discussed in a recent DevOps meeting [3].
> 
> When saying "svn2git migration", are you referring to the already
> existing svntogit repositories on git.archlinux.org or to the migration
> of our main package VCS to Git?
> 

I was talking about the latter point you mentioned: the permanent
conversion of our repos from svn to git.

The svntogit repos, on the other hand, can likely be easily migrated to
GitLab. To those who don't know: This is a git-accessible read-only
mirror for our svn package repos currently hosted at git.archlinux.org
[0][1]. Maybe there's a complication I don't know about right now but I
don't see why not.

> Could you elaborate on how svn2git migration and Flyspray are
> intertwined? I could not find any details in [3].
> 

We currently don't have a perfect grasp on what needs doing for svn2git
seeing as that project was begun a few times and stopped just as often.
I think the last idea was to have a git repo per package and then have a
metadata repo gather a bunch of package metadata but I'm not sure this
was ever perfectly fleshed out and I don't want to block this migration
on that decision. If we _do_ go with one repo per package then we could
track bugs for each package in its repo right there on GitLab and
personally, I think this is what we should go with. In this way, the
Flyspray migration of package bugs and the GitLab migration are
intertwined since we have to know _where_ the bugs will go in the end.
It does make sense to have package sources and package bugs together in
the same repo. However, doing this also requires some more tooling from
our side (you're not going to create 1 repos in GitLab by hand and
keep them in sync if you decide to change something). Again, we don't
want to block on that. Keeping Flyspray running for only package bugs
but migrating the project issues will already improve the status quo.

freswa had some opinions on that as well and a plan of attack.

[arch-dev-public] GitLab switchover and SSO migration

[Sven-Hendrik Haase via arch-dev-public]

Hi everyone,

As some of you know, we've been toying with two ideas for a while:
Arch-wide centralized user management as well as using GitLab to
consolidate some of our current services. The overall goal is manifold.
In no particular order, the goals are to
- make Arch more contributor friendly
- provide more modern tools for ourselves
- enable more automation
- make Arch services more secure
- make team management activities less error-prone and more streamlined

These two topics (SSO + Gitlab) are a bit intertwined because we wanted
to have SSO on GitLab before starting off with that so we'd have a
properly validated user base to work with going forward. Also, GitLab
seemed like a good first service for SSO due to it having good support
for that.

After looking at various solutions, we eventually settled on Keycloak
since it seemed like a modern, well-maintained, and secure piece of
software. It allows us to enable logins for services via OpenID Connect
and SAML which is likely the best coverage we could hope for. It also
allows us to connect other social login providers such as github.com and
gitlab.com and it supports Recaptcha, 2FA, and WebAuthn out of the box.
The idea is to eventually transition all our online service as well as
SSH keys to Keycloak to ease on-/offboarding and make it less error-prone.

As for GitLab, a few months back, we applied for a GitLab Ultimate
license in their open-source program [0] and we received one [1]. It's
an official program that many other open-source projects benefit from as
well and we think it's safe to assume that it'll continue being a thing
for the foreseeable future. We have to renew our license yearly. The
current license we have has support for 1000 seats but we can likely get
more seats if we need them.

Our general path is:
1) Transition as many staff-only services to Keycloak as possible. We
looked at our current services and put up a table on the wiki that shows
support per service [2].
Some of the services that we operate are deprecated or have
functionality that is also provided by GitLab. In our current
understanding, this concerns Flyspray, Kanboard, and Patchwork. Of
those, Kanboard and some of the Flyspray projects will be our first
targets to transition to GitLab. We'll continue using Flyspray for the
time being for package bugs but will discontinue its use for all
non-packaging bugs. The reason for this is that how we manage our bugs
for packages is somewhat intertwined with the svn2git migration which is
yet to be done and might dictate a different repo structure than what we
would come up with currently and we don't want to block on this. This
was also discussed in a recent DevOps meeting [3].
2) We'd like to get rid of our own cgit instance at git.archlinux.org
and transition our git hosting into GitLab. AUR git access will stay as
it is due to its special shell magic.
3) Eventually, after an internal testing phase of at least a few weeks,
we'll want to open Keycloak and GitLab up for outside contributors. We
know of the abuse potential and the potential moderation problems and
have to make sure to set proper limits and set up monitoring before
opening this up.
4) Connect remaining services like BBS and wiki to SSO. In 1) we only
mentioned staff-only services because those are less problematic.
However, in the future, we'd also like to enable our remaining services
to connect to Keycloak.

We tried hard to come up with a good source of users to import into
Keycloak so that we could seed that database with a solid user base but
sadly it appears that there is no trusted source of users that we can
rely on. Potential candidates were the wiki, BBS, AUR but we ruled them
all out in their current state as none of them have always had email
verification and so we can't trust those emails to be the sole source of
truth. In order to still allow users to keep their old contributions in
cases where they can prove their identity via email, we'll build a new
small web application that allows them to connect their new Keycloak
identity to their other identities. For now, we seeded the Keycloak
database with the only known-good source of trusted emails: Staff from
Archweb.

We'd like to make heavy use of GitLab CI for running automatic tests and
release automation. We're aware that the implication of eventually
allowing non-staff users to come in will result in untrusted code being
run on our CI. This is fine by itself but security-wise would prevent us
from creating trusted releases on the same CI runners. We currently have
two sponsored bare-metal GitLab CI runners that we plan on using for
running untrusted code. We'll get a new bare-metal box from Hetzner for
trusted releases that will only run on hand-picked pipelines that only a
select few of us can push to. Bare metal runners also allow us to test
and build VM images and such which isn't usually possible on most VPS.

On more goal we had is automatic github.com mirroring in some fashion.
We looked 

Re: [arch-dev-public] Packages spring cleanup!

[Sven-Hendrik Haase via arch-dev-public]

On Sun, 19 Apr 2020 at 20:50, Jelle van der Waa  wrote:

> Hi all,
>
> I'm going to disown some packages as I no longer actively use them and I
> want to shift focus into my on other Arch roles:
>
> ettercap
> openttd-opensfx
> openttd-opengfx
> rdesktop
> tesseract
> tesseract-*
> tidy
> unshield
> vim-pastie
> vim-align
> pstreams
> pdf2djvu
> bonnie++
> gsmartcontrol
> leptonica
> jbigkit
> pbpst
> ccd2iso
> chromium-bsu
> fsarchiver
> dot2tex
>
> If packages need to be moved to [community] for you to be able to adopt
> them, please say so.
>
> Greetings,
>
> Jelle
>

Adopted rdesktop.

Re: [arch-dev-public] Discussion - Increasing our CPU requirements

[Sven-Hendrik Haase via arch-dev-public]

On Sun, 29 Mar 2020 at 12:26, Allan McRae via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Remember when Arch Linux was optimized out of the box.   We have the
> blazingly fast i686 port while other distros hung out in i386 land.
> Those were the days where the idea of Arch being fast started.  Now it
> has degraded to stuff of legend.
>
> Now, x86_64 is old.  We should continue to push forward and add further
> optimization.
>
> Reasonable optimizations to consider:
>
> AVX2
> FMA
> SSE4.2
>
> AVX2 is Intel Haswell and newer or AMD Ryzen and newer.  This CPUs
> released 2013 to 2015.  So 5 - 7 years old.
>
> Discuss.
>

I'm definitely all for this. However, I'd strongly prefer it if we used
some heavy automation for building for all the variants. coderobe actually
started an experimental project to explore this. It would also increase our
mirror size requirements quite drastically which I think is likely fine as
our full mirror size is quite small but it should be considered.

I suggest going by processor support generation alone instead of per
feature. For instance, Haswell introduced AVX2 as well as FMA3 so it
doesn't really make much sense to separate those out, I think. Besides, if
you have AVX2 support and care for speed you'll also want to enable FMA3.

Suggested processor-generation based optimization "tier"s:

- nehalem (SSE4.2)
- sandybridge (SSE4.2, AVX)
- haswell (SSE4.2, AVX, AVX2, FMA3)
(soon-ish) - icelake (SSE4.2, AVX, AVX2, FMA3, AVX-512)

I know this sounds Intel specific so these names might not be optimal.

There is quite some work involved in this but I also strongly believe that
we have to keep pushing forward.

[arch-dev-public] Abandoning all my vim-* plugin packages

[Sven-Hendrik Haase via arch-dev-public]

I've started using a vim plugin manager and don't use my packages anymore.
They need a new home. Please show these packages some love:

* vim-a
* vim-colorsamplerpack
* vim-doxygentoolkit
* vim-guicolorscheme
* vim-minibufexpl
* vim-omnicppcomplete
* vim-project
* vim-taglist
* vim-vcscommand
* vim-workspace

The packages are pretty low maintenance but I'd prefer if someone who
actually uses them maintained them.

Anything that's not taken within 2 weeks will be dropped to AUR.

Re: [arch-dev-public] Can anyone take nvidia-390xx?

[Sven-Hendrik Haase via arch-dev-public]

On Thu, 5 Mar 2020 at 20:05, Sven-Hendrik Haase  wrote:

> On Sun, 23 Feb 2020 at 13:57, Sven-Hendrik Haase  wrote:
>
>> On Wed, 18 Jul 2018 at 01:40, Sven-Hendrik Haase 
>> wrote:
>>
>>> I don't run nvidia-390xx on any of my devices. I would appreciate it if
>>> somebody could take those drivers. I will continue maintaining the mainline
>>> nvidia package.
>>>
>>
>> This is still a problem. Somebody please over the fricken 390xx packages.
>>
>
> Since I was unable to trick anyone into maintaining these packages despite
> the best attempts, I'll be dropping them to AUR soon.
>

The 390xx packages have been dropped to AUR.

Re: [arch-dev-public] Can anyone take nvidia-390xx?

[Sven-Hendrik Haase via arch-dev-public]

On Sun, 23 Feb 2020 at 13:57, Sven-Hendrik Haase  wrote:

> On Wed, 18 Jul 2018 at 01:40, Sven-Hendrik Haase  wrote:
>
>> I don't run nvidia-390xx on any of my devices. I would appreciate it if
>> somebody could take those drivers. I will continue maintaining the mainline
>> nvidia package.
>>
>
> This is still a problem. Somebody please over the fricken 390xx packages.
>

Since I was unable to trick anyone into maintaining these packages despite
the best attempts, I'll be dropping them to AUR soon.

Re: [arch-dev-public] Spring cleaning (moving orphaned packages from [community] to AUR)

[Sven-Hendrik Haase via arch-dev-public]

On Tue, 3 Mar 2020 at 13:15, Christian Rebischke via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> On Thu, Feb 27, 2020 at 10:11:24AM +0100, Public mailing list for Arch
> Linux development wrote:
>
> > PS. If unmaintained orphans in [core] could be moved to [extra], and
> > unmaintained orphans in [extra] could be moved to [community], that could
> > be a nice "trickle down" effect and would be an appreciated cleanup as
> > well, but that is just my opinion.
>
> Wouldn't it make more sense to move from [core]/[extra] to [community]
> instead of moving from [core] to [extra] to [community].
>
> The group of possible maintainers is constant for a move of [core] to
> [extra] and I don't think, that such a repository change is helpful.
> The package will just decay for another year before it will get exposed
> to a new group of possible maintainers.
>
> Chris
>

That's actually a pretty good point. +1

Re: [arch-dev-public] Can anyone take nvidia-390xx?

[Sven-Hendrik Haase via arch-dev-public]

On Wed, 18 Jul 2018 at 01:40, Sven-Hendrik Haase  wrote:

> I don't run nvidia-390xx on any of my devices. I would appreciate it if
> somebody could take those drivers. I will continue maintaining the mainline
> nvidia package.
>

This is still a problem. Somebody please over the fricken 390xx packages.

Re: [arch-dev-public] mailman3/hyperkitty/postorius in the repos now

[Sven-Hendrik Haase via arch-dev-public]

On Sun, Feb 2, 2020, 17:48 David Runge  wrote:

> Hey all!
>
> I'm just on my way home from FOSDEM - train time, mail time ;-)
>
> I've spent the last weeks bringing the mailman3 ecosystem(!) to
> [community] and [community-testing] (~56 packages). Today I've added
> wiki pages for mailman3 [1] (it will replace the current mailman page
> once it's done by moving that to be 'mailman2' and eventually deleting
> it), hyperkitty [2] and postorius [3].
>
> I've done initial integration tests with mailman3, hyperkitty and
> postorius and they "should just work"(TM).
>
> Before moving all the stuff to [community] and replacing the wiki page,
> it would be great to get some further integration testing with actual
> mail servers (note the expansion macro [4] in the mailman article) and
> importing of mailman2 data [5] [6] going.
>
> Any help is very much appreciated, as the switch requires quite the data
> migration and configuration changes for e.g. our own lists (the archives
> of some of them are pretty large).
>
> Additionally, the hosting aspects of both Hyperkitty and Postorius need
> some expansion as well (e.g. for Apache setups and for proper subdomain
> setups).
>
> Everyone, feel invited to install and test the applications and propose
> fixes and expansions to the documentation (or packages) as needed.
>
> Best,
> David
>
> [1] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman
> [2] https://wiki.archlinux.org/index.php/Hyperkitty
> [3] https://wiki.archlinux.org/index.php/Postorius
> [4]
> https://wiki.archlinux.org/index.php/User:Davezerave/Mailman#Integrate_with_a_mail_server
> [5]
> https://wiki.archlinux.org/index.php/User:Davezerave/Mailman#Migrate_from_mailman_%3C_3.0
> [6]
> https://wiki.archlinux.org/index.php/Hyperkitty#Importing_mailman2_archives
>
> --
> https://sleepmap.de



Thanks for all of the hard work, David! :)

Re: [arch-dev-public] Package openvpn in [core]?

[Sven-Hendrik Haase via arch-dev-public]

On Fri, Jan 24, 2020, 11:28 Christian Hesse  wrote:

> Hello everybody,
>
> currently the package openvpn is located in our [core] repository and it's
> like that since the beginning of time. [0]
>
> Following a discussion on IRC and our definition for official repositories
> [1] we think there is no reason to have it there. Thus I would like to move
> it (and its dependency pkcs11-helper) to [extra].
> If you have any concern please raise your hand now!
>
> [0]
> https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/openvpn=3eb4941a937f2e9dc47ca7273c299d968787a181
> [1] https://wiki.archlinux.org/index.php/Official_repositories#core
> --
> main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
> "CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
> putchar(b-1/(/*Chriscc -ox -xc - && ./x
> */b/42*2-3)*42);}
>

+1

>

Re: [arch-dev-public] Guidelines for news posting

[Sven-Hendrik Haase via arch-dev-public]

On Thu, 16 Jan 2020 at 07:01, Sven-Hendrik Haase 
wrote:

> On Tue, 7 Jan 2020 at 01:14, Gaetan Bisson via arch-dev-public <
> arch-dev-public@archlinux.org> wrote:
>
>> [2020-01-06 23:11:57 +0100] Sven-Hendrik Haase via arch-dev-public:
>> > Every news post needs to have a corresponding draft submitted to
>> > arch-dev-public and wait for feedback for at least 24 hours unless:
>> > 1. it is urgent (and would be too late after 24 hours)
>> > 2. it is a simple --overwrite rule, or
>> > 3. there are strong reasons for the team member posting the draft to
>> > believe that it should not be visible to the public before it is
>> announced.
>> > In this third case, the draft should be submitted to the
>> > st...@lists.archlinux.org ML instead.
>>
>> That sounds great, Sven, thank you.
>>
>> I would however propose to remove rule 2. Mostly because I don't like
>> exceptions and also because we should try our best to keep the number of
>> such announcements to a minimum.
>>
>> Cheers.
>>
>> --
>> Gaetan
>>
>
> Since I haven't heard any further objections or feedback on this, I'm
> going make a PR adding this to archweb on the news posting page:
>
> Every news post needs to have a corresponding draft submitted to
> arch-dev-public and wait for feedback for at least 24 hours unless:
> 1. it is urgent (and would be too late after 24 hours)
> 2. there are strong reasons for the team member posting the draft to
> believe that it should not be visible to the public before it is announced.
> In this third case, the draft should be submitted to the
> st...@lists.archlinux.org ML instead.
>

Somebody made me aware privately about a typo so now the text is:

Every news post needs to have a corresponding draft submitted to
arch-dev-public and wait for feedback for at least 24 hours unless:
1. it is urgent (and would be too late after 24 hours)
2. there are strong reasons for the team member posting the draft to
believe that it should not be visible to the public before it is announced.
In this second case, the draft should be submitted to the
st...@lists.archlinux.org ML instead.

Re: [arch-dev-public] Guidelines for news posting

[Sven-Hendrik Haase via arch-dev-public]

On Tue, 7 Jan 2020 at 01:14, Gaetan Bisson via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> [2020-01-06 23:11:57 +0100] Sven-Hendrik Haase via arch-dev-public:
> > Every news post needs to have a corresponding draft submitted to
> > arch-dev-public and wait for feedback for at least 24 hours unless:
> > 1. it is urgent (and would be too late after 24 hours)
> > 2. it is a simple --overwrite rule, or
> > 3. there are strong reasons for the team member posting the draft to
> > believe that it should not be visible to the public before it is
> announced.
> > In this third case, the draft should be submitted to the
> > st...@lists.archlinux.org ML instead.
>
> That sounds great, Sven, thank you.
>
> I would however propose to remove rule 2. Mostly because I don't like
> exceptions and also because we should try our best to keep the number of
> such announcements to a minimum.
>
> Cheers.
>
> --
> Gaetan
>

Since I haven't heard any further objections or feedback on this, I'm going
make a PR adding this to archweb on the news posting page:

Every news post needs to have a corresponding draft submitted to
arch-dev-public and wait for feedback for at least 24 hours unless:
1. it is urgent (and would be too late after 24 hours)
2. there are strong reasons for the team member posting the draft to
believe that it should not be visible to the public before it is announced.
In this third case, the draft should be submitted to the
st...@lists.archlinux.org ML instead.

Re: [arch-dev-public] rsync & bundled zlib

[Sven-Hendrik Haase via arch-dev-public]

On Mon, Jan 13, 2020, 17:23 Christian Hesse  wrote:

> Hello everybody,
>
> to date we ship rsync with bundled zlib to keep compatibility with rsync
> up to version 3.1.0 and it's old-style --compress option. This is no longer
> required with rsync 3.1.1, which was released on 2014-06-22 - nearly six
> years ago!
> The bundled zlib carries some security issues, so time to act - one way
> or another.
>
> Even old-stable Debian Jessie [0] has rsync version 3.1.1. So any concern
> to
> finally drop bundled zlib and use system zlib?
>
> I would suggest to post a news item, feel free to give thoughts and
> feedback.
>
> --- >8 ---
> rsync compatibility
>
> Our `rsync` package was shipped with bundled `zlib` to provide
> compatibility
> with old-style `--compress` option up to version 3.1.0. Version 3.1.1 was
> released on 2014-06-22 and is shipped by all major distributions now.
>
> So we decided to finally drop the bundled library and ship a package with
> system `zlib`. Go and blame those running old versions if you encounter
> errors with `rsync 3.1.3-3`.
> --- >8 ---
>
> [0] https://packages.debian.org/de/jessie/rsync
> --
> main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
> "CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
> putchar(b-1/(/*Chriscc -ox -xc - && ./x
> */b/42*2-3)*42);}
>

+1 to idea and +1 to news item. Maybe make users aware of the security
implications of the bundled zlib.

>

[arch-dev-public] Guidelines for news posting

[Sven-Hendrik Haase via arch-dev-public]

Hi all,

in light of recent events, we had a little get-together in #archlinux-staff
to hack on an initial suggestion on guidelines for news posting. If we can
agree on these, they should be added on the news posting page on archweb
(and perhaps somewhere on the wiki).

The draft we came up with is this:

Every news post needs to have a corresponding draft submitted to
arch-dev-public and wait for feedback for at least 24 hours unless:
1. it is urgent (and would be too late after 24 hours)
2. it is a simple --overwrite rule, or
3. there are strong reasons for the team member posting the draft to
believe that it should not be visible to the public before it is announced.
In this third case, the draft should be submitted to the
st...@lists.archlinux.org ML instead.

Happy to hear about feedback.

Cheers,
Sven

Re: [arch-dev-public] soyuz (pkgbuild.com) server move to homedir.archlinux.org

[Sven-Hendrik Haase via arch-dev-public]

On Fri, 13 Dec 2019 at 08:00, Sven-Hendrik Haase 
wrote:

> On Mon, 18 Nov 2019 at 07:34, Sven-Hendrik Haase 
> wrote:
>
>> Hi all,
>>
>> I set up a new Hetzner VPS that is going to become our new
>> homedir/public_html server available to all TUs and Devs like soyuz was. We
>> decided to decommission soyuz and put the public_html stuff on its own
>> server for security reasons, to cut costs, and so that we can
>> compartmentalize further.
>>
>> The server uses a Hetzner Cloud Volume which we can scale if we want but
>> for now, it's 100GiB of zstd-compressed btrfs. If possible, we'd like to
>> keep it at this size for the time being. You can host your own repos there
>> if you want and that's fine. Please talk to us beforehand if you see
>> yourself exhausting the volume with what you want to do.
>>
>> If you had stuff hosted in the public_html of soyuz, I'd ask you to
>> transfer stuff over to the new box which is already reachable at the names
>> pkgbuild.com (you'll get an SSH error because of this) and
>> homedir.archlinux.org. Please check if you can throw away some old
>> stuff/junk that you might not necessarily need on the new server.
>>
>> This new box is *not for building*. That's what dragon is for. Please
>> only put documents/files onto the new pkgbuild.com that you actually
>> want people to be able to access publicly. The box has no building
>> facilities and you get no sudo'd commands.
>>
>> soyuz is going to be decommissioned no sooner than 2020-01-01 but do not
>> expect it to hang around for long after that. We will not transfer any
>> files for you from soyuz. In other words: All data not explicitly
>> transferred by you will be destroyed after 2020-01-01.
>>
>> Please bring up any problems you might have with this new server on the
>> arch-devops list or IRC (#archlinux-devops).
>>
>> Enjoy,
>> Sven
>>
>
> This is a short reminder that this is happening. soyuz is going away soon.
> I'll mark it for cancellation one of these days. If you haven't done so
> yet, please migrate your data if it's important.
>

It's 2020 and you know what that means: soyuz has been securely wiped and
canceled. If there is anything you might have forgotten to save, we got
backups to restore it from.

Re: [arch-dev-public] zstd rollout complete

[Sven-Hendrik Haase via arch-dev-public]

On Fri, Dec 27, 2019, 16:31 Robin Broda via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Hello everyone,
>
> We have just tested and released everything necessary for zstd packages in
> our repos.
>
> Right now, the updated devtools is still in [testing],
> but our preliminary testing shows that nothing immediately combusted on
> release, so I'm confident.
>
> Once it has left testing, packages built with devtools will automatically
> use zstd with the correct options.
>
> There is no intervention necessary, this should be an essentially
> transparent process.
>
>
> Happy packaging and greetings from 36c3.
>

We found out that the historical archive uploader is broken as python
doesn't have native zstd support in the tarfile package. We're trying to
fix this currently.

Re: [arch-dev-public] Missing bugtracker assignment emails

[Sven-Hendrik Haase via arch-dev-public]

On Sat, 14 Dec 2019 at 16:25, Morten Linderud via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Yo!
>
> Andreas Radke has done an impressive amount of bug assignments the past
> week. But it looks like the assignment emails themselves are not sent
> correctly and you might not have noticed this.
>
> Please look over your bug assignments on the tracker in case you haven't
> taken a look in a while :)
>
> Happy holidays!
>
> --
> Morten Linderud
> PGP: 9C02FF419FECBE16
>

Just for the archive: We seem to have emails now somehow. Morten confirmed
this today in IRC when I assigned a bug to him. If this comes back, at
least we'll remember it worked for him and me today.

Re: [arch-dev-public] soyuz (pkgbuild.com) server move to homedir.archlinux.org

[Sven-Hendrik Haase via arch-dev-public]

On Mon, 18 Nov 2019 at 07:34, Sven-Hendrik Haase 
wrote:

> Hi all,
>
> I set up a new Hetzner VPS that is going to become our new
> homedir/public_html server available to all TUs and Devs like soyuz was. We
> decided to decommission soyuz and put the public_html stuff on its own
> server for security reasons, to cut costs, and so that we can
> compartmentalize further.
>
> The server uses a Hetzner Cloud Volume which we can scale if we want but
> for now, it's 100GiB of zstd-compressed btrfs. If possible, we'd like to
> keep it at this size for the time being. You can host your own repos there
> if you want and that's fine. Please talk to us beforehand if you see
> yourself exhausting the volume with what you want to do.
>
> If you had stuff hosted in the public_html of soyuz, I'd ask you to
> transfer stuff over to the new box which is already reachable at the names
> pkgbuild.com (you'll get an SSH error because of this) and
> homedir.archlinux.org. Please check if you can throw away some old
> stuff/junk that you might not necessarily need on the new server.
>
> This new box is *not for building*. That's what dragon is for. Please only
> put documents/files onto the new pkgbuild.com that you actually want
> people to be able to access publicly. The box has no building facilities
> and you get no sudo'd commands.
>
> soyuz is going to be decommissioned no sooner than 2020-01-01 but do not
> expect it to hang around for long after that. We will not transfer any
> files for you from soyuz. In other words: All data not explicitly
> transferred by you will be destroyed after 2020-01-01.
>
> Please bring up any problems you might have with this new server on the
> arch-devops list or IRC (#archlinux-devops).
>
> Enjoy,
> Sven
>

This is a short reminder that this is happening. soyuz is going away soon.
I'll mark it for cancellation one of these days. If you haven't done so
yet, please migrate your data if it's important.

Re: [arch-dev-public] soyuz (pkgbuild.com) server move to homedir.archlinux.org

[Sven-Hendrik Haase via arch-dev-public]

On Mon, 18 Nov 2019 at 09:00, Konstantin Gizdov  wrote:

> Sounds good. One question - where do we move our email aliases?
>

Not quite sure what you mean. All email is still being handled by apollo
unless I'm mistaken and soyuz had more duties than I thought. In the latter
case, we should migrate that to apollo. Could anyone shed some light on
this?

[arch-dev-public] soyuz (pkgbuild.com) server move to homedir.archlinux.org

[Sven-Hendrik Haase via arch-dev-public]

Hi all,

I set up a new Hetzner VPS that is going to become our new
homedir/public_html server available to all TUs and Devs like soyuz was. We
decided to decommission soyuz and put the public_html stuff on its own
server for security reasons, to cut costs, and so that we can
compartmentalize further.

The server uses a Hetzner Cloud Volume which we can scale if we want but
for now, it's 100GiB of zstd-compressed btrfs. If possible, we'd like to
keep it at this size for the time being. You can host your own repos there
if you want and that's fine. Please talk to us beforehand if you see
yourself exhausting the volume with what you want to do.

If you had stuff hosted in the public_html of soyuz, I'd ask you to
transfer stuff over to the new box which is already reachable at the names
pkgbuild.com (you'll get an SSH error because of this) and
homedir.archlinux.org. Please check if you can throw away some old
stuff/junk that you might not necessarily need on the new server.

This new box is *not for building*. That's what dragon is for. Please only
put documents/files onto the new pkgbuild.com that you actually want people
to be able to access publicly. The box has no building facilities and you
get no sudo'd commands.

soyuz is going to be decommissioned no sooner than 2020-01-01 but do not
expect it to hang around for long after that. We will not transfer any
files for you from soyuz. In other words: All data not explicitly
transferred by you will be destroyed after 2020-01-01.

Please bring up any problems you might have with this new server on the
arch-devops list or IRC (#archlinux-devops).

Enjoy,
Sven

Re: [arch-dev-public] Adding package (lib32-)-amdvlk in extra (and testing)

[Sven-Hendrik Haase via arch-dev-public]

On Sun, 10 Nov 2019 at 12:00, Laurent Carlier via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> I would like to add these packages in the official repositories.
>
> It's a good alternative to vulkan-radeon packages, well maintained
> upstream
> and offer a good compromise with new gfx card released.
>
>


+1

Re: [arch-dev-public] Drop ekiga?

[Sven-Hendrik Haase via arch-dev-public]

On Sun, 9 Jun 2019 at 23:25, Jan de Groot  wrote:

> On Fri, 2019-06-07 at 16:55 +0200, Sven-Hendrik Haase via arch-dev-
> public wrote:
> > Since I actually use it but don't care enough to start maintaining
> > it, I'd
> > appreciate it if you could try bumping it first and then drop it if
> > that
> > turns out to break other stuff.
>
> I tried to bump Ekiga to git master, progress so far:
> - needs "recent" (2016) versions of Opal and ptlib (2.16.3 prerelease
> from git)
> - current ptlib is patched for OpenSSL 1.1 support, upstream has no
> support for 1.1 and is not planning to support it either (ticket closed
> as notabug/wontfix)
> - SSL code in ptlib has changed a lot, patch no longer applies,
> applying by hand is not enough
> - OpenSuSE has a patch which is half-finished and doesn't compile
>
> Things are not looking good for Ekiga. I don't have any plans to revert
> to OpenSSL 1.0 to get this working.
>

Well, drop it like it's hot.

Re: [arch-dev-public] Drop ekiga?

[Sven-Hendrik Haase via arch-dev-public]

On Fri, 7 Jun 2019 at 16:47,  wrote:

> Hello,
>
> I would like to drop Ekiga. The software hasn't seen a release in years,
> the
> git master branch has some active development now and then, but a release
> for Ekiga5 is not near (though upstream stated the software itself is ready
> enough to release v5 a year ago).
>
> Alternative is to bump Ekiga to git master and hope it doesn't have too
> much
> bugs.
>
> Issue that gets fixed: one package less that depends on gconf
> Issue that remains: Ekiga still depends on deprecated and unmaintained
> versions of Opal/ptlib
>
> Regards,
> Jan de Groot
>

Since I actually use it but don't care enough to start maintaining it, I'd
appreciate it if you could try bumping it first and then drop it if that
turns out to break other stuff.

Re: [arch-dev-public] Dropping nvidia-340xx series

[Sven-Hendrik Haase via arch-dev-public]

On Tue, Jun 4, 2019, 21:06 Giancarlo Razzolini via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Em maio 21, 2019 14:52 Giancarlo Razzolini via arch-dev-public escreveu:
> > Em maio 21, 2019 11:40 Ralph Corderoy escreveu:
> >
> > Doesn't help keeping it rotting in our repo when the next kernel update
> will
> > make it obsolete.
> >
>
> As announced previously, I have removed all packages related to 340xx from
> the
> repositories. I haven't uploaded anything to the AUR, since I would
> probably need
> to orphan the packages after uploading them.
>
> Therefore, I'll leave it up to the AUR community itself to upload them
> again, if
> it's needed.
>
> Regards,
> Giancarlo Razzolini


Good riddance!

Re: [arch-dev-public] Dropping nvidia-340xx series

[Sven-Hendrik Haase via arch-dev-public]

On Thu, 16 May 2019 at 23:56, Giancarlo Razzolini via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Hi All,
>
> As you might be aware, this last kernel broke (again) the nvidia-340xx
> driver. Usually
> when this happens, it delays our kernel or we end up pushing a kernel
> without the driver.
>
> We have to wait on nvidia to fix it or we have to use patches that are not
> always trivial,
> nor there is enough people working on them.
>
> Up until four months ago, however, I was always testing this on actual
> hardware. But, that
> machine do not have a monitor on it anymore. And, the card itself is
> troublesome, it sometimes
> make the whole machine crash when it heats.
>
> Having said this, I'm going to orphan the package in a couple of weeks, if
> nobody is interested
> in maintaining it. But, I would propose this package get dropped to the
> AUR so someone with the
> actual hardware can maintain it.
>
> P.s: Ironically I used the (almost) exact subject Felix use almost 3 years
> ago when proposing this.
>
> Cheers,
> Giancarlo Razzolini


Well, you have my blessing.

Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd

[Sven-Hendrik Haase via arch-dev-public]

On Sun, 24 Mar 2019 at 19:35, Robin Broda via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Hello all,
>
> in the past few weeks, some TUs and Developers have compared different
> compression algorithms to potentially replace the default compression
> method used in devtools.
> The current method is `xz -c -z -` which is single-threaded and rather
> slow, so we are looking to replace it with something faster.
>
> Multithreaded xz has come up in the past, and was quickly dismissed due to
> edge cases that would end up with packages being unreproducible on
> different machines - namely, xz -T0 -- the method that automatically
> determines the amount of threads -- produces different results when the
> amount of cores in a system is == 1:
> $ taskset -c 1 xz -c -z - -T0 < test > test.xz && sha256sum test.xz
> fe95a1af78304ae4be508e071f6697296e52b625fba95fca5622757779633d90  test.xz
> $ taskset -c 1,2 xz -c -z - -T0 < test > test.xz && sha256sum test.xz
> 3b2c520eda654de19c5fc02ea1d850e142ae24e1246edcce82e90bd690d18f99  test.xz
> $ taskset -c 1,2,3 xz -c -z - -T0 < test > test.xz && sha256sum test.xz
> 3b2c520eda654de19c5fc02ea1d850e142ae24e1246edcce82e90bd690d18f99  test.xz
>
> With this mail, i propose to switch to `zstd` instead (
> https://github.com/facebook/zstd).
> zstd does *not* exhibit this issue, and anthraxx has asked for some
> clarifications (
> https://github.com/facebook/zstd/issues/999#issuecomment-474114799) -
> just in case.
> The response is that zstd is generally friendly to reproducible builds.
>
> After some testing with heftig, I ran some additional benchmarks on our
> new build host 'dragon' to determine the appropriate compression level.
> Here are the results: (sorry for the wide mail :b)
>
> Compressor Package Name Size (MiB)  Comp. Size
> (MiB)  Ratio   Time (mm:ss)  Max. RSS in MiB  Decomp. Time (mm:ss)  Decomp.
> RSS in MiB
> xz -c -z - cuda 3038,58 1316,93
>43,34%  19:03.44  95,321:19.74   10,18
> zstd -c -T0 -18 -  cuda 3038,58 1375,41
>45,26%  01:12.50  2648,93  0:04.46   10,70
> zstd -c -T0 -19 -  cuda 3038,58 1371,94
>45,15%  01:34.13  3401,67  0:04.47   10,73
> zstd -c -T0 -20 -  cuda 3038,58 1371,94
>45,15%  01:34.34  3416,90  0:04.46   10,79
> zstd -c -T0 -21 -  cuda 3038,58 1371,94
>45,15%  01:31.60  3414,14  0:04.46   10,79
> xz -c -z - gcc  135,54  33,11
>24,43%  00:54.54  95,340:02.59   10,11
> zstd -c -T0 -18 -  gcc  135,54  35,87
>26,47%  00:12.37  419,23   0:00.23   10,77
> zstd -c -T0 -19 -  gcc  135,54  35,66
>26,31%  00:15.76  578,99   0:00.24   10,66
> zstd -c -T0 -20 -  gcc  135,54  35,66
>26,31%  00:16.36  579,11   0:00.25   10,75
> zstd -c -T0 -21 -  gcc  135,54  35,66
>26,31%  00:16.18  579,01   0:00.25   10,46
> xz -c -z - go   484,10  122,10
> 25,22%  03:19.11  95,350:08.78   10,16
> zstd -c -T0 -18 -  go   484,10  132,69
> 27,41%  00:15.40  1402,99  0:00.80   10,80
> zstd -c -T0 -19 -  go   484,10  131,84
> 27,23%  00:19.74  1914,07  0:00.79   10,78
> zstd -c -T0 -20 -  go   484,10  131,84
> 27,23%  00:20.19  1914,11  0:00.77   10,72
> zstd -c -T0 -21 -  go   484,10  131,84
> 27,23%  00:20.08  1914,09  0:00.79   10,78
> xz -c -z - intellij-idea-community-edition  772,46  384,37
> 49,76%  04:53.01  95,310:28.69   10,18
> zstd -c -T0 -18 -  intellij-idea-community-edition  772,46  392,44
> 50,80%  00:27.10  2341,02  0:00.91   10,63
> zstd -c -T0 -19 -  intellij-idea-community-edition  772,46  391,04
> 50,62%  00:37.09  3107,97  0:00.93   10,47
> zstd -c -T0 -20 -  intellij-idea-community-edition  772,46  391,04
> 50,62%  00:34.43  3107,87  0:00.93   10,70
> zstd -c -T0 -21 -  intellij-idea-community-edition  772,46  391,04
> 50,62%  00:35.45  3104,94  0:00.94   10,64
> xz -c -z - linux80,15   70,66
>

Re: [arch-dev-public] A contrib repository

[Sven-Hendrik Haase via arch-dev-public]

On Mon, Mar 18, 2019, 04:31 Morten Linderud via arch-dev-public
mailto:arch-dev-public@archlinux.org>>
wrote:

On Wed, Mar 13, 2019 at 02:05:47PM -1000, Gaetan Bisson via
arch-dev-public wrote:
> I think it's a great idea but it needs a solid maintainer. Without a
> clear leader it's (probably) going to be a free for all and we'll
drown
> under bikeshedding issues within a month. But of course that doesn't
> mean we'd lose anything trying anyhow.
>
> Among other things, I'd personally like to see the repo maintainer
> enforce sensible and consistent naming for the tools, preferring
longer,
> explicit names over shorter ones. For instance, I'm sure many of
us have
> one-letter scripts and if we contribute them all there's bound to be
> collisions along with the problem of not knowing at first glance what
> each tool does. We could maintain a bash alias file containing
> everyone's favorite nickname for each tool.


If we want someone to a dedicated maintainer, I can probably do so.
But I
believe that we can give everyone commit access, block commits to
master and just
enforce a system where two reviews are needed before merge.

I really don't think more is needed, but as noted; I can probably
take some
responsibilities if the devs think that is warranted.

When it comes to packaging and naming conflicts, I wonder if it's
just easier to
drop all the supplied files into `/usr/share/archcontrib` or
something. Makes it
easier to package and doesn't clutter anyone's PATH with a lot of
(sometimes)
unneeded tools.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEktnGzemaICTWkKdu50JoO6CMsv8FAlyOvK0ACgkQ50JoO6CM
sv8lBQ//aoNFKxUDM4Qcpi6nXXDDw51loxJp4AB+SYTv/Vml5tag7fVAkniUphLD
ujJYY8/sSVqke29YYpG+OyJIIp91jP7WJ6nwtRVY2lsfOOUGkEX3HKEN0NCHxe9/
GpQHn1GqZAp3+FjSwxvJabpm+aGDL4CLVErdbiDKocpZJf61WSAXNHpGPj26PzUm
L+fIkPDu8SEqENBVVkC9cKnf2+oInQ2ECHknSN/lBbNbwh2z2kAW46kglJXryJcE
jO2gYt9kzU6NqcfKwHXHY0XCQd0H0pVMjfaK6PB1N+dwbgHAAbyhV/SIziFEP9kc
PDK5NAFAcgQI+999Q9T0nufc+lqvPn9MuQ89OPINQhwTGCxEkUlicVrBYY/9ZFhC
rrsTp7LExeBsMhAE6havnv2UHgkJH9ttv3FmSi81HsUYsgrxsUXpijqZUSacra5l
4VEGR9pPjsdERco2UZo9hcneLutQn0T2mCVLgIiCdjS2ZjsQuuHZ5RNBkyeNnWOC
lBOBq7lddxhIiWGAjz60KOox5KL68OYlY4mZXbMQ2x2n3v2XF5VVL/ncp9F9CFo4
J6JGjab38LEemMnOFBgFS2XkRMmV7G+siD1++VdEKSCoy2tICPm5SAQiG9Ueo48y
nUMD2+gfkzFNJmVQdym9YVxAKlbLWDGVHGd9/a43ZzjKKIReJgk=
=y2os
-END PGP SIGNATURE-


So shall we progress with this? I don't think we can lose anything by
just trying it out. Let's put up a GitHub repo and get coding. Of course
it should be mirrored to our infra.



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] New build server for TUs and devs

[Sven-Hendrik Haase]

Hi all,

Thanks to Hetzner sponsoring our new server [0] we now have a new box with
48 threads, 128 GiB RAM, and 2 NVMes in RAID0 with a total of 1.75 TiB of
storage. Should be plenty fast for the time being.

The new server is now available at dragon.archlinux.org for all of your
package building pleasures. All TUs and devs have had all of their keys
added.

pkgbuild.com will soon be pointed to this new server so keep that in mind
in case your SSH tells you the hostname changed.

IMPORTANT: No data has been migrated from soyuz. It is your responsibility
to transfer any data you might want on dragon. soyuz will stay available
for at least a month from now (probably more, don't worry, there will be
another mail for its termination), so you have plenty of time to migrate
any data.

dragon will not host public_html in your home dirs. That will move
somewhere else. dragon is very strictly a build box and no other services
should run on there.

soyuz hasn't been changed in any way and if you really want to keep using
that, you can do so until it gets terminated.

[0] https://twitter.com/svenstaro/status/1107938411254431744

Re: [arch-dev-public] A contrib repository

[Sven-Hendrik Haase]

On Thu, 14 Mar 2019 at 01:05, Gaetan Bisson via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> [2019-03-13 23:46:10 +0100] Morten Linderud via arch-dev-public:
> > There is a *lot* of small tools people have written over the years that
> resides
> > in bin/ directories which could be useful for more people. We also have
> several
> > such tools on soyuz, where sogrep was added to devtools this week.
> >
> > I have been thinking it could be great to have a simple `contrib`
> repository
> > where every team member has commit access. This could work as a staging
> area for
> > tools we would like to promote to `devtools` later on.
> >
> > We could maybe sort this into directories for its purpose:
> > * packaging
> > * security
> > * devops
> > * testing
> > * bugwrangler
> > * misc
> >
> > Tools that can be added here is the `ch` scripts from Bluewind, and the
> pkg-*
> > tools eli has created. I also have some tools to look for pkgname in
> archweb,
> > check them out from svn and check them against a nvchecker file.
> >
> > This would hopefully give us a space where we can experiment with new
> maintainer
> > tools in a collaborative manner. I'd love to hear some feedback or
> thoughs on
> > this!
>
> I think it's a great idea but it needs a solid maintainer. Without a
> clear leader it's (probably) going to be a free for all and we'll drown
> under bikeshedding issues within a month. But of course that doesn't
> mean we'd lose anything trying anyhow.
>

I also really like the idea but I think we could have a bunch of
maintainers and have everybody else just make PRs. However, then it would
be kind of like the devtools repo I suppose. We should decide exactly how
this repo would be different from devtools. If both of them necessitate
high-quality submissions with a PR-only system, I see them overlapping. We
can resolve this in two ways:

1. Not have an extra repo but strongly encourage PRs against devtools with
new tools.
2. Open-for-all devtools-contrib repo as originally suggested by Morten.

I actually prefer 2. as this encourages openly sharing even half-baked
scripts. This sets a lower barrier for entry and good tools with good
documentation could still be promoted to be part of devtools.


>
> Among other things, I'd personally like to see the repo maintainer
> enforce sensible and consistent naming for the tools, preferring longer,
> explicit names over shorter ones. For instance, I'm sure many of us have
> one-letter scripts and if we contribute them all there's bound to be
> collisions along with the problem of not knowing at first glance what
> each tool does. We could maintain a bash alias file containing
> everyone's favorite nickname for each tool.
>
>
I see your concerns and I'm not sure we should even try to address these
for what is meant to be a heap of random useful tools. I think there is a
lot of value in collecting the tools. I think about it a little bit like
AUR where the low barrier of entry makes everybody just throw stuff out
there and then the best tools are promoted.

Re: [arch-dev-public] Away for two weeks

[Sven-Hendrik Haase]

On Fri, Oct 5, 2018 at 8:30 PM Jelle van der Waa  wrote:

> Hi all,
>
> I'll be away for two weeks without a laptop so I won't be able to do any
> packaging. Feel free to update my packages or fix my open bugs ^_^
>
> If there is something really urgent, I should be able to reply via
> e-mail.
>
> --
> Jelle van der Waa
>

You go on vacation... without your laptop?! D:

Re: [arch-dev-public] /r/linux AMA

[Sven-Hendrik Haase]

On Thu, Aug 9, 2018 at 6:41 PM Morten Linderud via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> Yo!
>
> The subreddit /r/linux have started organizing AMA threads for relevant
> projects. Gentoo had one of these a few months ago and is an interesting
> read.
>
>
> https://www.reddit.com/r/linux/comments/8nsdj0/we_are_gentoo_developers_ama/
>
> https://www.reddit.com/r/linux/comments/93qlow/established_project_developer_team_member_flairs/
>
> I think it's a good idea Arch Linux does an AMA as it's might give users
> some
> incentive to help contributing to the project. I have chatted with a
> subreddit
> mod at /r/linux, and the AMA should preferably start on any Monday from
> 27th and
> onwards. It will also run for a few days, so there is no need to be
> present all
> the time, or when it starts.
>
>
> If you are interested participating please reply to the list with the
> following
> information:
>
> * Reddit username.
> * What you do.
> * What Monday fits for you?
>
> I have also started handing out flairs on the /r/archlinux subreddit. It's
> not
> an official forum, but if developers and team members want flairs for their
> reddit accounts you can also reply to this mail or poke me on IRC :)
>
> --
> Morten Linderud
> PGP: 9C02FF419FECBE16
>

Hi!

I think that's a pretty cool idea.

Reddit user name: Svenstaro.
I'm a dev, packager. I package mostly big, heavy packages :(.
I'm down for any Monday except for 2018-08-20.

[arch-dev-public] Can anyone take nvidia-390xx?

[Sven-Hendrik Haase]

I don't run nvidia-390xx on any of my devices. I would appreciate it if
somebody could take those drivers. I will continue maintaining the mainline
nvidia package.

Re: [arch-dev-public] Moving gcc7 into [community] for CUDA

[Sven-Hendrik Haase]

Ok, I'm moving gcc7 into [community] then. Thanks for the input.

Re: [arch-dev-public] Moving gcc7 into [community] for CUDA

[Sven-Hendrik Haase]

I meant to attach the proposed PKGBUILD in the OP. It's attached on this
one.


PKGBUILD
Description: Binary data

[arch-dev-public] Moving gcc7 into [community] for CUDA

[Sven-Hendrik Haase]

Hey,

I would like to move gcc7 (based on the latest version 7 commit of gcc [0])
into [community] because of cuda 9.2 and in return drop gcc54.

I tried to make it work with current gcc but to no avail. In earlier
releases of cuda the incompatibilities could be patched with header hacks
but not this time. I tested the whole setup with cuda 9.2 locally and it
seems to work fine.

I just want to get somebody's ok on this as apparently not everyone is
stoked about having yet another old version of gcc in there for some time.

Sven

[0]
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gcc=44e0a03db1b5cabf6135f194e540d513cf959245

[arch-dev-public] Abandoning nvidia 340xx packages - does anyone want them?

[Sven-Hendrik Haase]

I do not have any devices which require me to run nvidia 340xx packages and
I haven't tested them for quite some time now. The most recent
nvidia devices which require 340xx because the regular nvidia package
dropped support for them are now 8-9 years old.

I'm not really sure there is merit in maintaining these so unless anyone
wants them I'll drop them to AUR in two weeks.

Re: [arch-dev-public] 2017 repository cleanup

[Sven-Hendrik Haase]

Thanks for the work, I adopted a bunch of packages.

On Mon, Dec 18, 2017 at 12:05 PM David Runge  wrote:

> On 2017-12-18 10:54:37 (+0100), Bartłomiej Piotrowski via arch-dev-public
> wrote:
> > - dbus-c++:
> > schiv: libffado
> > dvzrv: libffado
> > fyan: kimtoy
> > - liboggz:
> > speps: sonic-visualiser
> > dvzrv: sonic-visualiser
> > - mxml:
> > dvzrv: zynaddsubfx
> > - twolame:
> > eric: audacity, sox
> > dvzrv: audacity
> > anthraxx: vlc
> Adopted the above
>
> > - fltk:
> > ronald: octave
> > schiv: alsa-tools
> > arojas: libgiac, xcas
> > arodseth: tuxpaint-config, monica
> > dvzrv: zynaddsubfx
> > kkeen: xdiskusage, dillo
> > lfleischer: lmms
> > spupykin: tigervnc
> > - libid3tag:
> > lfleischer: mixxx
> > ronald: imlib2
> > guillaume: easytag
> > muflone: gmtp
> > spupykin: minidlna
> > lcarlier: mtpfs
> > fyan: lib32-libid3tag
> > eric: alsaplayer, audacity, sox
> > speps: sonic-visualiser
> > dvzrv: audacity, sonic-visualiser
> > tpowa: libmp3splt
> > bisson: mpd
> > - libiec61883:
> > schiv: cinelerra-cv, libffado
> > dvzrv: libffado
> > heftig: gst-plugins-good
> > fyan: lib32-libiec61883
> > alucryd: ffmpeg
> Can't adopt the above, as they are in [extra]
>
> Will look into more in the coming days. Currently on the road.
>
> --
> https://sleepmap.de
>

[arch-dev-public] Hey everyone,

[Sven-Hendrik Haase]

I'll be on vacation for 2 weeks starting today. Feel free to update my
packages.

Sven

[arch-dev-public] Can we have optional deps on AUR packages?

[Sven-Hendrik Haase]

Moving this discussion from aur-general. I posed the question:

I just wanted to clear this up with the other TUs: Is it ok for [community]
packages to have optional deps on AUR packages or not?

Re: [arch-dev-public] News draft for i686 deprecation, rev. 2

[Sven-Hendrik Haase]

On 25 January 2017 at 08:54, Bartłomiej Piotrowski
 wrote:
> Due to the decreasing popularity of i686 among the developers and the
> community, we have decided to phase out the support of this architecture.
>
> The decision means that February ISO will be the last that allows to
> install 32 bit Arch Linux. The next 9 months are deprecation period,
> during which i686 will be still receiving upgraded packages. Starting
> from November 2017, packaging and repository tools will no longer
> require that from maintainers, effectively making i686 unsupported.
>
> However, as there is still some interest in keeping i686 alive, we would
> like to encourage the community to make it happen with our guidance. The
> [archlinux-ports][1] mailing list and Freenode IRC channel will be used
> for further coordination.
>
> [1]: https://lists.archlinux.org/listinfo/arch-ports

I kept up to date a bit with what people around the net are thinking
about this draft and it appears there is some confusion as to whether
[multilib] will be affected by this. I propose adding the following
sentence:

"The [multilib] repositories will not be affected by this change."

Re: [arch-dev-public] [RFC] Send signoff reports somewhere else (or not at all)

[Sven-Hendrik Haase]

On Mon, Jan 2, 2017 at 4:54 PM, Angel Velásquez  wrote:
> On 2017-01-02 10:50 AM, Giancarlo Razzolini wrote:
>> Hi All,
>>
>>   With the recent archweb migration, some services stopped working.
>>   We are just finishing migrating those services (and automating them
>>   on ansible). One of these services is the signoff reports emails.
>>
>>   For the past few days, the exact same e-mail was sent, from the old
>>   setup, and nobody seem to have noticed. I guess most (all) filter
>>   these emails out. Also, the service to populate the signoff's wasn't
>>   running too, but this one will be kept running.
>>
>>   Also, I have been pointed to this[0]. So, should we send signoff
>>   reports somewhere else or, not at all?
>>
>> Cheers,
>> Giancarlo Razzolini
>>
>
> +1 to drop them

+1. Drop it.

Re: [arch-dev-public] Dropping nvidia-304xx series

[Sven-Hendrik Haase]

Nope, I still got hardware using that.

On Mon, Dec 12, 2016 at 4:49 PM, Bartłomiej Piotrowski
<bpiotrow...@archlinux.org> wrote:
> On 2016-12-12 16:35, Sven-Hendrik Haase wrote:
>> +1
>
> Can we also drop 340xx?
>
> Bartłomiej
>

Re: [arch-dev-public] Dropping nvidia-304xx series

[Sven-Hendrik Haase]

+1

On Mon, Dec 12, 2016 at 3:46 PM, Felix Yan  wrote:
> I have recently disowned nvidia-304xx as I don't own relevant hardware
> anymore. Given that it's now an orphan and blocks xorg-server 1.19, I'm
> planning to move it to AUR in a few days, if nobody else wants to pick
> it up.
>
> --
> Regards,
> Felix Yan
>

Re: [arch-dev-public] Long out of date packages

[Sven-Hendrik Haase]

openvdb is updated as part of the boost rebuild.

On Thu, Oct 20, 2016 at 3:03 PM, Allan McRae  wrote:
> On 20/10/16 22:25, Florian Pritz via arch-dev-public wrote:
>>
>> allan:
>> extra/x86_64/fakechroot
>
> Updating this breaks the pacman testsuite (due to a fakechroot bug...).

Re: [arch-dev-public] i686 and SSE2

[Sven-Hendrik Haase]

This would probably be a good time to get a fully automated building
setup going. We certainly have the hardware for it now.

On Mon, Sep 19, 2016 at 11:12 PM, Gaetan Bisson  wrote:
> [2016-09-19 20:57:01 +0200] Balló György via arch-dev-public:
>> 2016-09-19 15:34 GMT+02:00 Allan McRae :
>> >
>> > If we limit our choice based on your CPU, then we need to limit based on
>> > the other CPU mentioned in this thread.
>> >
>> > That should not be a consideration at all. What we need to do is think
>> > about what make our distribution worthy of being a distribution.
>> > Original the selling points were rolling release, vanilla packages and
>> > optimised binaries.  We have lost the latter.  Do we want to get it back?
>> >
>>
>> Another option could be to keep i686 and x86_64 as is, and introduce new
>> architectures with automatically built optimised packages for i686 + SSE2
>> or SSE3, and for x86_64 + SSE4.2 or AVX. This is something similar to your
>> option #4, but keeps the compatibility with all existing systems.
>
> Yes!
>
> And I vote to put you in charge of the legacy platforms so the rest of
> us can focus on building software that uses more than half of the
> transistors >90% of us own. Besides, you'll do a much better job at it
> than me, given it's been nearly five years I last tested an i686 binary.
>
> So I say we create a new architecture that includes all extensions
> available on >90% of currently available hardware, make that our primary
> architecture, and let people interested in legacy platforms figure out
> the rest of the plan.
>
> Cheers.
>
> --
> Gaetan

Re: [arch-dev-public] i686 and SSE2

[Sven-Hendrik Haase]

I favor 3) as well. Seems rather easy to implement and I don't really
think we need to support architecture that old.

On Mon, Sep 19, 2016 at 7:02 AM, Allan McRae  wrote:
> This goes beyond just adding SSE2 support.
>
> Years ago, Arch Linux was "optimised for modern processors".  These were
> the days when every other distro was using i386 and we had a blazingly
> fast i686 port.  Now every other distro uses i686 while we have sat
> still.  Even major software developments are starting to require SSE2.
> It is time we moved forward.
>
> How can we achieve this?  I see several options:
>
> 1) Do "nothing".  Add a hook to the filesystem package that detects
> whether a system has SSE2 support and blocks installation of certain
> packages.
>
> 2) Add SSE2 to our optimisations and require "i686 + SSE2"
>
> 3) Move our minimum CPU to something less than 20 years old  (even i786
> would get us SSE2+3 instructions and is 15 years old)
>
> 4) We add more modern CPU builds  (and set them automatically building
> once the base architecture is updated).
>
>
> I am in favour of #3 for our 32-bit support.  And that would be end of
> line as far as 32 bit support in this distribution goes.
>
>
> (We may want to consider #4 for our x86_64, but that is another
> conversation).
>
> Allan

Re: [arch-dev-public] Me and my packages: A sad truth

[Sven-Hendrik Haase]

Hey Thomas,

Thank you for being honest and straightforward about this. Could you
provide a list of packages that are now orphaned due to this?

All the best. Glad to hear you are generally planning to stay onboard.

Sven

On Sat, Jul 30, 2016 at 1:48 PM, Thomas Bächler 
wrote:

> Hello guys,
>
> for over a year and a half, I have barely been able to do any packaging.
> Between job, kids, real life and some time to relax, only a few hours of
> time remains here and there. Sadly, this time is not enough to be able
> to contribute significantly to Arch Linux.
>
> Until recently, I always thought to myself that I'll return to packaging
> very soon. The reality is that this won't happen. This is a hard step
> for me, but I have to be honest to my fellow Arch Developers, the users
> and most importantly, to myself.
>
> Just a moment ago, I orphaned all my packages except for joe and ovmf,
> which I plan on taking care of for now, since they'll certainly be
> dropped from the repos if I don't (I think I can handle two packages).
> For the time being, I won't be taking any new packages. I'll also see if
> I can unsubscribe from all bug reports.
>
> However, I am not gone completely:
>
> * I will still keep my Arch Linux package signing master key and take
> care of signing and revoking developer and trusted user keys.
> * I will keep an eye on release engineering and espeically the new
> netboot system I just set up recently.
> * I will always remain available to you all via this list, the private
> dev list, IRC, XMPP and e-mail for advice and help.
>
> My heart beats for Arch and its community and I doubt that will ever
> change. I am sorry that I let you guys down. Facing this sad reality is
> a first step towards improving this, and I certainly hope that at some
> point, I will return to a more active role.
>
> Best regards
> Thomas
>
>

Re: [arch-dev-public] Discussion about optional dependencies

[Sven-Hendrik Haase]

On Jul 19, 2016 03:56, "Gaetan Bisson"  wrote:
>
> [2016-07-19 11:13:22 +1000] Allan McRae:
> > My opinion is the primary binary for a
> > package should run out of the box.  If you really need to reduce
> > dependencies, then a split package should be considered.
>
> That makes sense to me.
>
> --
> Gaetan

I also agree with that reasoning.

Sven

Re: [arch-dev-public] Moving repos to nymeria - possibly some interruption of service

[Sven-Hendrik Haase]

On Mon, Jun 27, 2016 at 7:23 PM, Lukas Jirkovsky via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> On 26 June 2016 at 23:25, Sven-Hendrik Haase <s...@lutzhaase.com> wrote:
> > Sounds like you have your repos subdomain fixed to nymeria in your hosts
> > file. Check out your route to repos.archlinux.org. If it doesn't point
> to
> > orion.archlinux.org, that's the problem.
>
> The route should be OK:
>
> [lukas@orochi Arch]$ tracepath repos.archlinux.org
>  1?: [LOCALHOST] pmtu 1500
> ...
> 11:  hos-tr1.ex3k6.rz16.hetzner.de16.654ms
> asymm 13
> 12:  orion.archlinux.org  13.987ms
> reached
>  Resume: pmtu 1500 hops 12 back 14
>
> [lukas@orochi Arch]$ host orion.archlinux.org
> orion.archlinux.org has address 88.198.91.70
>

Can you ssh into it?

Re: [arch-dev-public] Moving repos to nymeria - possibly some interruption of service

[Sven-Hendrik Haase]

On Sun, Jun 26, 2016 at 1:10 PM, Lukas Jirkovsky via arch-dev-public <
arch-dev-public@archlinux.org> wrote:

> On 13 June 2016 at 20:45, Jan Alexander Steffens via arch-dev-public
> <arch-dev-public@archlinux.org> wrote:
> > Actually, the right command would be:
> >
> > svn relocate svn+ssh://svn-packages@nymeria svn+ssh://svn-packages@repos
> ||
> > svn relocate svn+ssh://svn-community@nymeria
> svn+ssh://svn-community@repos
> >
> > Which should relocate the repo properly, no matter which type.
> >
> > On Mon, Jun 13, 2016 at 7:54 PM Sven-Hendrik Haase <s...@lutzhaase.com>
> wrote:
> >
>
> Due to the lack of time I didn't get to doing the relocation until
> now, and it's failing for me with:
>
> nologin: invalid option -- 'c'
> ...
> (nologin help)
> ...
> svn: E170013: Unable to connect to a repository at URL
> 'svn+ssh://svn-commun...@repos.archlinux.org/srv/repos/svn-community/svn'
> svn: E210002: To better debug SSH connection problems, remove the -q
> option from 'ssh' in the [tunnels] section of your Subversion
> configuration file.
> svn: E210002: Network connection closed unexpectedly
>
> Doing a clean checkout from repos.archlinux.org fails with the same error
>
> Any ideas?
>
> Lukas
>

Sounds like you have your repos subdomain fixed to nymeria in your hosts
file. Check out your route to repos.archlinux.org. If it doesn't point to
orion.archlinux.org, that's the problem.

[arch-dev-public] Cleaning up the DNS

[Sven-Hendrik Haase]

Hey all,

there is this DNS entry that I have no clue about what it does and whether
it's needed:

communityIN CNAME   nymeria

Since nymeria is going away, I would like to know what this does. Any clue
anybody? I can't even find community.archlinux.org on Google so it's
probably safe but then again I thought it's better to be safe than sorry.

Sven

Re: [arch-dev-public] Moving repos to nymeria - possibly some interruption of service

[Sven-Hendrik Haase]

Signing my message. Also, of course the topic is wrong. We're moving
FROM nymeria TO orion.

Sven



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] Moving repos to nymeria - possibly some interruption of service

[Sven-Hendrik Haase]

Hello all,

The devops team is currently in the process of moving the repos off nymeria
and onto orion as part of our planned infrastructure move (see arch-devops
archives). This might result in some minor breakages but we'll try to keep
that at a minimum. The move is expected to take place either later today or
tomorrow.

You will then receive a new mail with instructions how to migrate your svn
and what else there might be to know about this.

Sven

Re: [arch-dev-public] TU Resignation

[Sven-Hendrik Haase]

Aw. Fun ride. Good luck on all future ventures.

On Thu, Jan 21, 2016 at 10:34 PM, Daniel Wallace <
danielwall...@gtmanfred.com> wrote:

> Hey all,
>
> Over the last two months I have been considering this, and finally came to
> the decision that it was time to resign as a Trusted User.
>
> I haven't been able to dedicated a meaningful amount of time to Arch Linux
> for some time now, and think it is just time to give it up.
>
> I will still be around, but I don't use Arch anywhere near as much as I
> used to, but back when I did, it gave me so much experience and helped me
> get really started in Linux and then in Python and getting jobs along the
> way.
>
> I will always remember getting steam into the repositories, and working
> with the lawyers at Valve to get a workable EULA so we could redistribute
> it.
>
>
> https://lists.archlinux.org/pipermail/arch-dev-public/2012-November/024040.html
> http://www.phoronix.com/scan.php?page=news_item=MTIyOTI
>
> And all the cool people I got to talk to and work with.
>
> If any of yall are ever in Texas, look me up :)
>
> Thanks
> Daniel
>

Re: [arch-dev-public] [RFC] archive.archlinux.org

[Sven-Hendrik Haase]

On Sun, Oct 18, 2015 at 10:41 AM, Florian Pritz <bluew...@xinu.at> wrote:
>
> On Sat, 17 Oct 2015 22:46:49 +0200 Sven-Hendrik Haase
> <s...@lutzhaase.com> 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

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

Re: [arch-dev-public] [RFC] archive.archlinux.org

[Sven-Hendrik Haase]

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,0Gpackages
> 110Grepos/2013
> 254Grepos/2014
> 204Grepos/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
>

[arch-dev-public] [draft] nvidia-340xx and nvidia

[Sven-Hendrik Haase]

As NVIDIA dropped support for G8x, G9x, and GT2xx GPUs with the release
of 343.22, there now is set of nvidia-340xx packages supporting those
older GPUs. 340xx will receive support until the end of 2019 according
to NVIDIA.

Users of older GPUs should consider switching to nvidia-340xx. The
nvidia-343.22 and nvidia-340xx-340.46 packages will be in testing for a
few days.

Re: [arch-dev-public] Bringing libcl 1.2 into Arch

[Sven-Hendrik Haase]

On 23.05.2014 14:17, Lukas Jirkovsky wrote:
 Hello,
 I've been toying with the idea of bumping libcl from version 1.1 to
 1.2. Bellow I will sum up my findings.

 Current State
 ---
 The opencl support is split into three different packages:

   * opencl-headers - provides header files necessary for compilation,
 currently at version 1.1

   * libcl - provides libCL.so which is an ICD loader, ie. this
 libraryis used to the actual OpenCL implementation depending on the
 user needs. In arch we use proprietary libcl from the nVidia drivers.
 Because nVidia supports only OpenCL 1.1 our library does, too.

   * opencl-nvidia - an OpenCL implementation. There are packages in
 AUR that provide the implementation for other vendors, too, such as
 intel-opencl-sdk

 There are two main reasons why our OpenCL support is stuck at 1.1:
   * when the OpenCL support was introduced, libcl was only provided by
 nVidia and AMD as part of their proprietary drivers, but AMD binary
 drivers are not supported
   * nvidia supports only OpenCL 1.1

 Proposed Changes
 
 The time has changed and now there are two opensource ICD loaders available:
   * ocl-icd (https://aur.archlinux.org/packages/ocl-icd/)
   * opencl-icd (https://aur.archlinux.org/packages/opencl-icd/)
 Both ICD loaders provide libCL.so in version 1.2. Both ICD loaders are
 drop-in replacements for the current libcl, ie. no rebuild is needed.

 I propose the following changes:
   1. Update the opencl-headers to 1.2 (again). There is a package
 opencl-headers12 that grabs them from svn.
   2. replace libcl with either ocl-icd or opencl-icd

 Reasons for change:
   * replace proprietary libCL.so with an open source one
   * support for OpenCL 1.2. While nVidia doesn't support this, it will
 allow using OpenCL 1.2 features on devices that support it (Intel
 CPU's, AMD GPU's) which couldn't have been used before as they were
 not provided by libCL

 Possible Problems
 ---
 So far I was able to find only one possible problem. Applications
 using OpenCL has to check for the supported OpenCL version on runtime.
 However, if an application does the check only on compile time, it
 will crash. IIRC this used to be a problem with luxmark, but I tested
 it and it works correctly now. I have also tested imagemagick and
 blender and both work fine. Well, blender is broken for me, but it was
 before, too. At least it doesn't crash.

 In more detail, the reason is that you can compile OpenCL 1.2
 application without problems even on OpenCL 1.1 system as the
 libraries and headers will now provide everything needed. However, if
 the application tries to call an OpenCL 1.2 function, the driver will
 not provide it, in which case it will crash.

 In any case if such issue arises, it needs to be fixed upstream.

 The BIG Question
 --
 We once had problem that there were no suitable ICD loaders part the
 one from nVidia. Now we have two. The question is which one to use.

   * opencl-icd is the reference ICD loader from Khronos. It uses a
 custom license (or at least a license I don't know) which seems to
 forbid distributing of sources, but which explicitly allows
 redistribution of the compiled binaries

   * ocl-icd is an independent project under 2-clause BSD license. I
 think from the two this one has longer development

 Lukas
+1 for the idea.

As for which loader to use, I have no idea. Pick the saner one.

Re: [arch-dev-public] skype maintainer wanted

[Sven-Hendrik Haase]

On 26.04.2014 21:19, Florian Pritz wrote:

Hi,

I've stopped using skype quite a while ago and I don't want to maintain
it any more. If anyone wants to take over, please adopt the package in
archweb in the next ~2 weeks, otherwise I'll drop it to AUR.

If you take over be aware of the following open bug:
https://bugs.archlinux.org/task/39313

Synopsis: skype sometimes doesn't work with pulse, the workaround is
broken for random people and pulse upstream doesn't care.

Also note you'll need permissions to submit packages to [multilib],
request them on arch-multilib if necessary.



I'm taking this over.

Re: [arch-dev-public] nvidia 331.49

[Sven-Hendrik Haase]

On February 26, 2014 9:31:03 AM CET, Ionut Biru ib...@archlinux.org wrote:
hello,

i'm a bit busy this days. it's kinda a minor update but it would be
nice to
have this bug resolved as well:
https://bugs.archlinux.org/task/38604


On Tue, Feb 25, 2014 at 8:30 PM, Pierre Schmitz pie...@archlinux.de
wrote:

 Am 25.02.2014 18:26, schrieb Ike Devolder:
  Hi all,
 
  Is there a special reason we are not updating to the latest nvidia
  drivers ?
 
  problems building the kernel drivers or something ?
 
  I'm just asking, did not yet build the drivers myself, just have an
  updated pkgbuild for the utils already.

 Looks like a minor update to me. I think Ionut was busy lately. So I
 would say if the updated driver works fine and is not explicitly
marked
 as BETA, just go ahead and push an update.

 Greetings,

 Pierre

 --
 Pierre Schmitz, https://pierre-schmitz.com


Will handle this a little later today. 

Re: [arch-dev-public] Git

[Sven-Hendrik Haase]

On 30.09.2013 09:50, Ike Devolder wrote:
 On Sun, Sep 29, 2013 at 09:55:21PM +0200, Tom Gundersen wrote:
 On Sun, Sep 29, 2013 at 9:48 PM, Connor Behan connor.be...@gmail.com wrote:
 On 29/09/13 12:25 PM, Alexander R?dseth wrote:
 Hi,

 As I gather, we all like git better than svn, for a long list of
 reasons. Are there any objections to switching over from svn to git for
 repositories for the official packages?
 One reason to prefer svn is that you can do a non-recursive checkout and
 only have working copies of the packages you maintain. AFAIK, git does
 not (want to) support this.
 Yes, this can not be done in a heartbeat. The tools and documentation
 needs to be updated and the workflow needs to be tested, but are there
 objections to starting the transition process?
 If we were to use git, we should have one git repository per package,
 and also provide one repository which includes all the packages as
 submodules. This will allow both partial and full checkouts, just like
 with svn.

 Cheers,

 Tom
 If packages-repositories would be hosted on a service like github,
 gitorious,  it would be a very nice addition.  That would open up a
 lot of opportunity for non-dev/non-tu users to create pull requests in
 an easy way, leading to possible more input/help from the broad
 community.  In that case i'm very much in favour of this switch.

 If we only switch to git to switch to git because it is more popular and
 people are more used to it, I don't see the advantage. For what we are
 using it, svn is in my oppinion easier to use than git.


That is an excellent idea that I hadn't even considered yet.



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Orphans

[Sven-Hendrik Haase]

pypy3 is an orphan no longer.
openclonk is actually maintained by jsteel, he should just adopt it.
aircrack-ng is maintained

Re: [arch-dev-public] Proposal to change the nvidia-utils package to allow for better bumblebee integration

[Sven-Hendrik Haase]

In continuation of this discussion, I bring forth my proposed new
nvidia-utils PKGBUILD. Please see if you find anything wrong with it.
# $Id: PKGBUILD 179508 2013-03-05 18:36:25Z ioni $
# Maintainer: Thomas Baechler tho...@archlinux.org
# Contributor: James Rayner iphi...@gmail.com
pkgbase=nvidia-utils
pkgname=('nvidia-utils' 'nvidia-libgl' 'opencl-nvidia')
pkgver=313.26
pkgrel=1
arch=('i686' 'x86_64')
url=http://www.nvidia.com/;
license=('custom')
options=('!strip')

if [ $CARCH = i686 ]; then
_arch='x86'
_pkg=NVIDIA-Linux-${_arch}-${pkgver}

source=(ftp://download.nvidia.com/XFree86/Linux-${_arch}/${pkgver}/${_pkg}.run;)
md5sums=('3c2f5138d0fec58b27e26c5b37d845b8')
elif [ $CARCH = x86_64 ]; then
_arch='x86_64'
_pkg=NVIDIA-Linux-${_arch}-${pkgver}-no-compat32

source=(ftp://download.nvidia.com/XFree86/Linux-${_arch}/${pkgver}/${_pkg}.run;)
md5sums=('2d35124fa5a4b009f170fe893b5d07e3')
fi

create_links() {
# create soname links
while read -d '' _lib; do
_soname=$(dirname ${_lib})/$(LC_ALL=C readelf -d ${_lib} | sed -nr 
's/.*Library soname: \[(.*)\].*/\1/p')
[[ -e ${_soname} ]] || ln -s $(basename ${_lib}) ${_soname}
[[ -e ${_soname/.[0-9]*/} ]] || ln -s $(basename ${_soname}) 
${_soname/.[0-9]*/}
done  (find ${pkgdir} -type f -name '*.so*' -print0)
}

build() {
cd ${srcdir}
sh ${_pkg}.run --extract-only
}

package_opencl-nvidia() {
pkgdesc=OpenCL implemention for NVIDIA
depends=('libcl' 'zlib')
optdepends=('opencl-headers: headers necessary for OpenCL development')
cd ${srcdir}/${_pkg}

# OpenCL
install -D -m644 nvidia.icd ${pkgdir}/etc/OpenCL/vendors/nvidia.icd
install -D -m755 libnvidia-compiler.so.${pkgver} 
${pkgdir}/usr/lib/libnvidia-compiler.so.${pkgver}
install -D -m755 libnvidia-opencl.so.${pkgver} 
${pkgdir}/usr/lib/libnvidia-opencl.so.${pkgver} 

create_links
}

package_nvidia-libgl() {
pkgdesc=NVIDIA drivers libraries symlinks
conflicts=('libgl')
provides=('libgl')
cd ${srcdir}/${_pkg}

mkdir -p ${pkgdir}/usr/lib/xorg/modules/extensions
ln -s /usr/lib/nvidia/xorg/modules/extensions/libglx.so.${pkgver} 
${pkgdir}/usr/lib/xorg/modules/extensions/libglx.so.${pkgver}
ln -s libglx.so.${pkgver} 
${pkgdir}/usr/lib/xorg/modules/extensions/libglx.so.1
ln -s libglx.so.${pkgver} 
${pkgdir}/usr/lib/xorg/modules/extensions/libglx.so

ln -s /usr/lib/nvidia/libGL.so.${pkgver} 
${pkgdir}/usr/lib/libGL.so.${pkgver}
ln -s libGL.so.${pkgver} ${pkgdir}/usr/lib/libGL.so.1
ln -s libGL.so.${pkgver} ${pkgdir}/usr/lib/libGL.so
}

package_nvidia-utils() {
pkgdesc=NVIDIA drivers utilities
depends=('xorg-server' 'nvidia-libgl')
optdepends=('gtk2: nvidia-settings'
'opencl-nvidia: OpenCL support')
cd ${srcdir}/${_pkg}

# X driver
install -D -m755 nvidia_drv.so 
${pkgdir}/usr/lib/xorg/modules/drivers/nvidia_drv.so
# GLX extension module for X
install -D -m755 libglx.so.${pkgver} 
${pkgdir}/usr/lib/nvidia/xorg/modules/extensions/libglx.so.${pkgver}
ln -s libglx.so.${pkgver} 
${pkgdir}/usr/lib/nvidia/xorg/modules/extensions/libglx.so# X doesn't 
find glx otherwise
# OpenGL library
install -D -m755 libGL.so.${pkgver} 
${pkgdir}/usr/lib/nvidia/libGL.so.${pkgver}
# OpenGL core library
install -D -m755 libnvidia-glcore.so.${pkgver} 
${pkgdir}/usr/lib/libnvidia-glcore.so.${pkgver}
# VDPAU
install -D -m755 libvdpau_nvidia.so.${pkgver} 
${pkgdir}/usr/lib/vdpau/libvdpau_nvidia.so.${pkgver}
# nvidia-tls library
install -D -m755 tls/libnvidia-tls.so.${pkgver} 
${pkgdir}/usr/lib/libnvidia-tls.so.${pkgver}
install -D -m755 libnvidia-cfg.so.${pkgver} 
${pkgdir}/usr/lib/libnvidia-cfg.so.${pkgver}

install -D -m755 libnvidia-ml.so.${pkgver} 
${pkgdir}/usr/lib/libnvidia-ml.so.${pkgver}
# CUDA
install -D -m755 libcuda.so.${pkgver} 
${pkgdir}/usr/lib/libcuda.so.${pkgver}
install -D -m755 libnvcuvid.so.${pkgver} 
${pkgdir}/usr/lib/libnvcuvid.so.${pkgver}
install -D -m755 nvidia-cuda-proxy-server 
${pkgdir}/usr/bin/nvidia-cuda-proxy-server
install -D -m644 nvidia-cuda-proxy-control.1.gz 
${pkgdir}/usr/share/man/man1/nvidia-cuda-proxy-control.1.gz
# DEBUG
install -D -m755 nvidia-debugdump ${pkgdir}/usr/bin/nvidia-debugdump
# nvidia-xconfig
install -D -m755 nvidia-xconfig ${pkgdir}/usr/bin/nvidia-xconfig
install -D -m644 nvidia-xconfig.1.gz 
${pkgdir}/usr/share/man/man1/nvidia-xconfig.1.gz
# nvidia-settings
install -D -m755 nvidia-settings ${pkgdir}/usr/bin/nvidia-settings
install -D -m644 nvidia-settings.1.gz 
${pkgdir}/usr/share/man/man1/nvidia-settings.1.gz
install -D -m644 nvidia-settings.desktop 
${pkgdir}/usr/share/applications/nvidia-settings.desktop
install -D -m644 nvidia-settings.png 
${pkgdir}/usr/share/pixmaps/nvidia-settings.png
sed -e 's:__UTILS_PATH__:/usr/bin:' -e 
's:__PIXMAP_PATH__:/usr/share/pixmaps:' -i 

Re: [arch-dev-public] Xorg-server 1.14 hitting testing

[Sven-Hendrik Haase]

On 16.03.2013 17:48, Laurent Carlier wrote:
 Le samedi 16 mars 2013 10:05:54 Andreas Radke a écrit :
 Am Sun, 10 Mar 2013 09:27:16 +0100

 schrieb Laurent Carlier lordhea...@gmail.com:
 Users will have to wait until a compatible version is available. Mesa
 drivers are an alternative, or they can block the upgrade.

 ++
 I'd like to move Xorg 1.14 pretty soon, best would be together with
 the kernels. It's up to you whether you want to announce to hold the
 update for catalyst users or remove it from the repos.

 I suggest to use the video api dependency + conflicts like we do in all
 other driver packages to avoid the xorg-server update for catalyst
 users. But this is your choice.

 -Andy
 This was my first choice, to block updates through api dependency until an 
 api 
 compatible driver (packages will follow today in community-testing).

 So what is the best choice (final vote):
 * keep it and block update
 * remove it

 For both choices, there is mesa as an alternative.

 ++

I'd keep it for now and block update. AMD has been better the last 2
years. Maybe they'll follow up on this problem soon enough?



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Proposal to change the nvidia-utils package to allow for better bumblebee integration

[Sven-Hendrik Haase]

On 14.03.2013 10:03, Thomas Bächler wrote:
 Am 14.03.2013 02:59, schrieb Sven-Hendrik Haase:
 On 13.03.2013 22:15, Laurent Carlier wrote:
 Le mercredi 13 mars 2013 06:18:15 Sven-Hendrik Haase a écrit :
 I propose a change to the nvidia-utils that is as follows:

 1. Move all libs to /usr/lib/nvidia
 2. Create nvidia-utils-helper package that only adds a
 /etc/ld.so.conf.d/nvidia file containing /usr/lib/nvidia
 3. make nvidia-utils depend on nvidia-utils-helper

 1. package nvidia-utils without libGL.so and libGL.so.1 symlinks
 2. package nvidia-libgl with these symlinks.
 3. the package bumblebee could provide a /usr/lib/bumblebee that provide
 libGL.so and libGL.so. symlinks and conflicts with nvidia-libgl
 Shouldn't libglx.so go into that package as well? But then it wouldn't
 be correct to call it nvidia-libgl anymore. I like the symlink idea.
 mesa-libgl looks exactly the same.


Indeed, you are right. Well then, nvidia-libgl would fit fine.



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Proposal to change the nvidia-utils package to allow for better bumblebee integration

[Sven-Hendrik Haase]

On 13.03.2013 22:15, Laurent Carlier wrote:

Le mercredi 13 mars 2013 06:18:15 Sven-Hendrik Haase a écrit :

I propose a change to the nvidia-utils that is as follows:

1. Move all libs to /usr/lib/nvidia
2. Create nvidia-utils-helper package that only adds a
/etc/ld.so.conf.d/nvidia file containing /usr/lib/nvidia
3. make nvidia-utils depend on nvidia-utils-helper


1. package nvidia-utils without libGL.so and libGL.so.1 symlinks
2. package nvidia-libgl with these symlinks.
3. the package bumblebee could provide a /usr/lib/bumblebee that provide
libGL.so and libGL.so. symlinks and conflicts with nvidia-libgl


Shouldn't libglx.so go into that package as well? But then it wouldn't 
be correct to call it nvidia-libgl anymore. I like the symlink idea.

[arch-dev-public] Proposal to change the nvidia-utils package to allow for better bumblebee integration

[Sven-Hendrik Haase]

I propose a change to the nvidia-utils that is as follows:

1. Move all libs to /usr/lib/nvidia
2. Create nvidia-utils-helper package that only adds a
/etc/ld.so.conf.d/nvidia file containing /usr/lib/nvidia
3. make nvidia-utils depend on nvidia-utils-helper

Reasoning:
A while back, I asked aur-general what they thought about putting
bumblebee into [community] [0]. The responses were few but positive. So
now I want to actually get this working.

The suggested changes will enable me to integrate bumblebee without
having to create a nvidia-utils-bumblebee package which would
essentially duplicate all the data that is in the nvidia-utils package
to begin with I'd like to keep it simple and not create
nvidia-utils-bumblebee and lib32-nvidia-utils-bumblebee. Instead we can
do with just a simple helper package. At the same time, we could delete
a bunch of nvidia-utils packages on AUR.

A new package bumblebee that I'd add would conflict/provide
nvidia-utils-helper but wouldn't contain the ld.so.conf.d file. This
would mean that the nvidia libs wouldn't get used by default on an
optimus system but instead would need to be explicitly loaded (as is
wanted). The transition should be seamless for all other users on
non-nvidia systems.

I know there was a proposal by an nvidia employee a while back to make
changes to the nvidia upstream driver package as well as mesa that would
enable inherent coexistence of mesa-libgl and nvidia-utils but I asked
that employee and he said there had been no progress on that proposal.
So here we stand.

[0]
https://mailman.archlinux.org/pipermail/aur-general/2013-March/022295.html


signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Mesa 9.1 in testing

[Sven-Hendrik Haase]

On 24.02.2013 16:40, Andreas Radke wrote:
 Am Sun, 24 Feb 2013 22:41:08 +1100
 schrieb Gaetan Bisson bis...@archlinux.org:

 [2013-02-23 10:23:13 +0100] Andreas Radke:
 There are still packages in extra depending on the old libgl
 package. We will need to fix them before makepkg will properly
 allow to build only against new mesa.
 With [testing] enabled, `pacman -S libgl` still pulls the old libgl,
 rather than mesa-libgl which provides it and lies in a higher-priority
 repo. I am not sure why. Anyhow, most pacman transactions required to
 build anything depending (directly or not) on mesa and libgl result
 in:

  /usr/lib/xorg/modules/dri/swrast_dri.so exists in both 'mesa'
 and 'libgl'

 Is this what you were referring to? Or is there anything I am missing
 to avoid running into this issue.

 Yes. We are looking for a solution for this. I guess this is a
 pacman limitation. Afaik pacman can resolve replaces only on -Su
 upgrades.

 If nobody shows a real solution we can either move Mesa pretty quickly
 to extra resolving this. This will for sure trigger some bugs for the
 users. Or we use an ugly workaround: when a chroot build fails move the
 dependency array from the top of the PKGBUILD to the package() function
 array.

 -A
+1 for moving mesa quickly



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] Mesa 9.1 in testing

[Sven-Hendrik Haase]

On 24.02.2013 23:31, Gaetan Bisson wrote:

[2013-02-24 17:16:42 +0100] Sven-Hendrik Haase:

+1 for moving mesa quickly

Do you have any more arguments than Andreas gave to support this?

Or is the +1 entirely for free?



Moving it quickly would seem like the simplest solution and the bugs I 
heard of seem only to concern wayland. I'd wager that for most our 
users, moving it now would be a fine idea. The other trickery suggested 
doesn't sit well with me.

Re: [arch-dev-public] mesa packaging, libGL handling

[Sven-Hendrik Haase]

On 15.02.2013 20:15, Jan Steffens wrote:
 On Fri, Feb 15, 2013 at 8:02 PM, Tom Gundersen t...@jklm.no wrote:
 Out of curiosity, what would be the benefit of keeping it split up
 rather than just merging (almost) everything?
 The drivers are damn large (thanks to LLVM). No need to have them
 installed if you ain't got the hardware.
Can't you build them with shared llvm libs?

Re: [arch-dev-public] Adding {lib32-}libtxc_dxtn_s2tc in community/multilib

[Sven-Hendrik Haase]

On 17.12.2012 01:53, Jan Steffens wrote:
 On Sun, Dec 16, 2012 at 11:59 PM, Laurent Carlier lordhea...@gmail.com 
 wrote:
 S2TC is a patent-free S3TC compatible implementation and provides
  texture compression to Mesa. The package also includes tools to
  compress/decompress S2TC textures and convert S3TC textures to
  S2TC ones using the patent-free algorithm.

 Plan is to add these packages in community/multilib. These packages are 
 patent
 free S3TC implementation instead of libtxc_dxtn. These are already part of
 Ubuntu and Debian.

 There was a bug with etqw/quake4 that i've just fixed, so currently it's
 pretty bug-free.

 These packages are not filling requirement, but are essential for games, as
 these usually need S3TC support.

 https://aur.archlinux.org/packages/libtxc_dxtn_s2tc
 https://aur.archlinux.org/packages/lib32-libtxc_dxtn_s2tc

 S2TC on github:
 https://github.com/divVerent/s2tc

 Regards,
 Laurent Carlier
 Do we really care about patents enough? Can't we just include the
 standard libtxc_dxtn?
 Even if we care - I heard that S2TC may be encumbered as well.

Personally, I don't think we care about patents enough and should slap
both libs in there. I think plenty of stuff we have in binary in our
repos is encumbered by patents but s3tc just happens to get a lot of bad
press on that particular part. It probably doesn't make it any more
dangerous to have than the other stuff we already package. Can we get
some more opinions on this particular point?

Re: [arch-dev-public] fmodex

[Sven-Hendrik Haase]

On 20.11.2012 15:12, Stéphane Gaudreault wrote:
 I just noticed that we have fmodex (a proprietary audio library) in
 [community]. Considering the discussion we had recently about steam, I
 think that the situation is similar here. The FMOD Non-Commercial
 License does not explicitely allow redistribution and allow only
 non-commercial use [1]. In the svn repository, there is a PERMISSION
 file [2], but it looks quite imprecise to me.

 I am not very good in legal stuff, but I think that we need a more
 formal permission to redistribute a possibly modified version of this
 package and to make sure they won't sue us because of the
 non-commercial specification.

 Stéphane

 [1] http://www.fmod.org/fmod-sales.html
 [2]
 https://projects.archlinux.org/svntogit/community.git/tree/trunk/PERMISSION?h=packages/fmodex



The CEO himself answered me there. Isn't that official enough?

Re: [arch-dev-public] fmodex

[Sven-Hendrik Haase]

On 20.11.2012 15:24, Andrea Scarpino wrote:
 On Tue, Nov 20, 2012 at 3:14 PM, Sven-Hendrik Haase s...@lutzhaase.comwrote:

 The CEO himself answered me there. Isn't that official enough?

 Could you forward me the original mail so we keep a copy in arch-dev?

Done.

[arch-dev-public] Anyone want mongodb?

[Sven-Hendrik Haase]

I don't use mongodb, it keeps breaking and upstream is nuts. Anyone want 
this ungodly package? Otherwise I'll drop it into AUR in a few.

Re: [arch-dev-public] Anyone want mongodb?

[Sven-Hendrik Haase]

On 05.11.2012 01:41, Felix Yan wrote:
 On 11/05/2012 07:13 AM, Sven-Hendrik Haase wrote:
 I don't use mongodb, it keeps breaking and upstream is nuts. Anyone want
 this ungodly package? Otherwise I'll drop it into AUR in a few.
 Hi, I use mongodb at everyday work, but not so confident to deal with
 all its naughty nuts. If no one else is going to take it in a few, I'll
 adopt it.

 Felix Yan

Congrats and have fun.



signature.asc
Description: OpenPGP digital signature

[arch-dev-public] About to drop bacula

[Sven-Hendrik Haase]

I'm going to be dropping bacula to AUR soon as I don't use it and I keep
bug reports on it. I don't currently have a working bacula set up so it
might be better off in someone else's hands. I'll give it a few days
before dropping it in case another TU wants to take over.

[arch-dev-public] mongodb and courier packages

[Sven-Hendrik Haase]

I currently don't really use mongodb nor courier-*. heftig is currently
making systemd stuff for mongodb but courier will get no such love.

Basically, does anyone want mongodb or courier? Otherwise I'd be
maintaining mongodb for some time to come but courier-* would go to the
aur entirely.



signature.asc
Description: OpenPGP digital signature