[arch-dev-public] State of PHP 8 update

[Pierre Schmitz]

Hi all,

as people start asking me when to expect PHP 8 packages in our repos,
here is a quick update:
* For those who seek adventure, I'll already have version 8 in my
unofficial repo
* A lot of the libraries I tested do not work with PHP 8 yet. E.g.
Doctrine, Elastic-Search, ...
* Software that was written for PHP 5 and was never properly ported to
7 will not work; e.g. FluxBB we use for our Forums
* Updating software to work with PHP 8 is quite easy though and I
expect way less issues than the back in the days when we transitioned
from 5 to 7
* A lot of developers use Arch, therefor I would like to provide PHP 8
as soon as possible which in turn should speed up the migration or
everybody
* I will check if we could provide php7 packages alongside version 8
so people can start developing for 9 but still are able to run some
apps with 7. PHP 7 will be supported by upstream for almost 2 years:
https://www.php.net/supported-versions.php

I'll keep you updated.

Greetings,

Pierre

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

Re: [arch-dev-public] Split openssl package

[Pierre Schmitz]

On Sun, Nov 22, 2020 at 2:57 AM Eli Schwartz via arch-dev-public
 wrote:
> As I mentioned there, I don't really see the need to make a split
> package just for 25kb of optional scripts that can just use optdepends.
>
> "I tendo o lean towards a separate package instead of using optdepends
> as it is more explicit and you do not end up with partly invalid package."
>
> Do you then propose Arch should switch policies and start using split
> packages everywhere instead of our usual optdepends? Not sure what to
> think here. This feels inconsistent.

First of all, I think using split packages and optdependes are both
reasonable solutions. Splitting a package can be used to either reduce
sizes of individual packages or to reduce dependencies. The latter can
be achieved by optdependes as well. My personal rule of thumb here
would be: If a program cannot work without a given dependent it should
not be optional. In contrast if you have software that e.g. is able to
use several databases for storage but falls back to sqlite one could
declare mysql, postgres etc. as optional as long as the program is
usable without them.

Either way, I would call both solutions to be correct.

Greetings,

Pierre

[arch-dev-public] Split openssl package

[Pierre Schmitz]

Hi all,

there is a new set of openssl packages in testing that are split into
openssl, openssl-doc and openssl-perl. See
https://bugs.archlinux.org/task/54887

As most users just need the library the perl dependency can be
dropped. Summing up:

Before:
openssl: depends on Perl; size:  3.6 MiB (7.31 MiB)

After:
openssl: depends just on glibc; size: 1.78 MiB (5.49 MiB)
openssl-perl: depends on Perl
openssl-doc: size: 1.82 MiB

We actually talked about this at ArchConf last year. Splitting the
package was the easy part, but dropping the Perl dependency means that
any package up the tree that depends on openssl needs to be checked if
it actually needs Perl itself. Thanks to everybody who did the hard
work here!

PS: Do you think we should post a news item about this change? Most
people won't need to worry about this, but those few who need the perl
scripts need to install the separate package.

Greetings,

Pierre

[arch-dev-public] archlinux/base docker image will no longer be updated

[Pierre Schmitz]

Hi all,

as the archlinux/base image has been replaced by
https://hub.docker.com/repository/docker/archlinux/archlinux I'll no
longer manually build this image alongside the ISO image release. I
guess it would be best to remove the repository so people will not
silently keep using an outdated image.

Greetings,

Pierre

Re: [arch-dev-public] News draft: Accessibility features added to installation media

[Pierre Schmitz]

A great addition, thanks a lot!

I'll put this announcement into the ISO information as well. The new
image should be live any minute.

Greetings,

Pierre

On Sun, Nov 1, 2020 at 1:08 AM Eli Schwartz via arch-dev-public
 wrote:
>
> On 10/31/20 2:52 PM, David Runge wrote:
> > Hey all,
> >
> > below is the news item I would like to post once the installation medium
> > is released some time tomorrow:
> >
> > ```
> > We are very happy to announce that accessibility features have been
> > added to our installation medium with [archiso
> > v49](https://gitlab.archlinux.org/archlinux/archiso/-/tags/v49). From
> > release 2020.11.01 onwards these are available via the 2nd boot loader
> > menu item.
> >
> > Many thanks go to Alexander Epaneshnikov who integrated the features
> > from the [TalkinArch](https://wiki.archlinux.org/index.php/TalkingArch)
>
> typo: missing "g" in the link text
>
> > project into archiso's releng profile, which is used for creating the
> > installation medium.
> >
> > Note: The bootloader timeouts have been set to 15s to allow blind users
> > to select the menu item as the bootloaders themselves do not offer
> > accessibility features.
> > The timeout is stopped as soon as e.g. an arrow key is pressed.
> > ```
> >
> > If you have improvement suggestions, please let me know!
> >
> > Best,
> > David
> >
>
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>

Re: [arch-dev-public] New version of the pkgstats client

[Pierre Schmitz]

Thanks for the hint. I thought I was on that list once; maybe I should
post more than twice a decade though :-)

On Sun, Oct 25, 2020 at 3:33 PM Morten Linderud via arch-dev-public
 wrote:
>
> On Sun, Oct 25, 2020 at 03:29:28PM +0100, Pierre Schmitz wrote:
> > For more information see the integrated help; I also wrote a quick
> > post at 
> > https://pierre-schmitz.com/pkgstats-version-3-lookup-package-statistics-from-your-terminal/
>
> Should add your blog to the planet :)
>
> https://www.archlinux.org/devel/profile/
> -> Website rss:
>
> --
> Morten Linderud
> PGP: 9C02FF419FECBE16

[arch-dev-public] New version of the pkgstats client

[Pierre Schmitz]

Hi all,

I just released the initial version of a new pkgstats package. As it
now requires different arguments (e.g. it does no longer submit the
list when run with no arguments) it is technically a BC break;
therefore version 3. For most users who simply install it to enable
the weekly submission of packages no intervention is needed.

The command now supports displaying statistics right from the terminal. E.g.
pierre@skynet ~> pkgstats show go nodejs
nodejs 65.26
go 61.34

For more information see the integrated help; I also wrote a quick
post at 
https://pierre-schmitz.com/pkgstats-version-3-lookup-package-statistics-from-your-terminal/

Greetings,

Pierre

Re: [arch-dev-public] Wiki Update in progress

[Pierre Schmitz]

Aside from the update issue we have quite a lot of load on the server
due to bots crawling all page revisions. Those links are now invisible
to anonymous users (such as bots). We'll see if that helps.

Greetings,

Pierre

On Sun, Sep 1, 2019 at 3:58 PM Alad Wenter via arch-dev-public
 wrote:
>
> On 9/1/19 1:32 AM, Pierre Schmitz wrote:
> > The wiki is now back up. Sorry for any inconvenience.
>
> I've noticed that some Special: pages (such as Special:RecentChanges)
> are no longer accessible when not logged in.
>
> Assuming it's not only on my end, is this an intentional change?
>
> Alad
>
> > Have fun!
> >
> > Pierre
> >
> > On Sun, Sep 1, 2019 at 12:35 AM Pierre Schmitz  wrote:
> >> I temporary disabled the FPM to reduce the server load. So everybody
> >> may enjoy a 502 error page now. :-)
> >>
> >> "1.33 has several database changes since 1.32, and will not work without 
> >> schema
> >>
> >> updates. Note that due to changes to some very large tables like the 
> >> revision
> >> table, the schema update may take quite long (minutes on a medium sized 
> >> site,
> >> many hours on a large site)."
> >>
> >> Fingers crossed.
> >>
> >> Greetings,
> >>
> >> Pierre
> >>
> >> On Sun, Sep 1, 2019 at 12:04 AM Pierre Schmitz  wrote:
> >>> Hi there,
> >>>
> >>> I triggered a Wiki update. Unfortunately the update script is running
> >>> longer than expected. So pages appear to be empty.
> >>>
> >>> Greetings,
> >>>
> >>> Pierre

Re: [arch-dev-public] Wiki Update in progress

[Pierre Schmitz]

The wiki is now back up. Sorry for any inconvenience.

Have fun!

Pierre

On Sun, Sep 1, 2019 at 12:35 AM Pierre Schmitz  wrote:
>
> I temporary disabled the FPM to reduce the server load. So everybody
> may enjoy a 502 error page now. :-)
>
> "1.33 has several database changes since 1.32, and will not work without 
> schema
>
> updates. Note that due to changes to some very large tables like the revision
> table, the schema update may take quite long (minutes on a medium sized site,
> many hours on a large site)."
>
> Fingers crossed.
>
> Greetings,
>
> Pierre
>
> On Sun, Sep 1, 2019 at 12:04 AM Pierre Schmitz  wrote:
> >
> > Hi there,
> >
> > I triggered a Wiki update. Unfortunately the update script is running
> > longer than expected. So pages appear to be empty.
> >
> > Greetings,
> >
> > Pierre

Re: [arch-dev-public] Wiki Update in progress

[Pierre Schmitz]

I temporary disabled the FPM to reduce the server load. So everybody
may enjoy a 502 error page now. :-)

"1.33 has several database changes since 1.32, and will not work without schema

updates. Note that due to changes to some very large tables like the revision
table, the schema update may take quite long (minutes on a medium sized site,
many hours on a large site)."

Fingers crossed.

Greetings,

Pierre

On Sun, Sep 1, 2019 at 12:04 AM Pierre Schmitz  wrote:
>
> Hi there,
>
> I triggered a Wiki update. Unfortunately the update script is running
> longer than expected. So pages appear to be empty.
>
> Greetings,
>
> Pierre

[arch-dev-public] Wiki Update in progress

[Pierre Schmitz]

Hi there,

I triggered a Wiki update. Unfortunately the update script is running
longer than expected. So pages appear to be empty.

Greetings,

Pierre

Re: [arch-dev-public] Edit /etc/php/php.ini config file in chroot

[Pierre Schmitz]

Do you have an example PKGBUILD? I'd say provide a custom php.ini or
use cli parameters like php -d extension=iconv etc.

On Mon, Feb 11, 2019 at 7:17 PM NicoHood  wrote:
>
> Hi,
> I am using devtools to create a package with php scripts. It uses
> composer to build the package. I get the error:
>
> The requested PHP extension ext-iconv * is missing from your system.
> Install or enable PHP's iconv extension.
>
> This can be solved by editing the config file and add:
> extension=iconv
>
> The config file is only accessible by root. How do I edit this config
> file within the PKGBUILD if its build by devtools? Any idea?
>
> ~Nico
>

Re: [arch-dev-public] FOSDEM 2019

[Pierre Schmitz]

Hi,

my colleague and I arrive early on Friday afternoon. So we are free to
join you. No idea where to go though.

Greetings,

Pierre

On Sun, Jan 6, 2019 at 1:09 PM Morten Linderud via arch-dev-public
 wrote:
>
> Yo!
>
> Last year at FOSDEM we where quite a few members from the Arch team present, 
> and
> I though it would be nice to have a dinner together! My suggestion is to do it
> Friday around 18:00 then head for the beer event at delirium afterwards.
>
> To make it managable I'll cap the attendees to 15 people. Priority for members
> of the Arch team (developers, trusted users and support staff) and any free 
> spots
> after this can be taken by anyone interested :) Please send an email so I have
> some ability to keep track.
>
> If Friday does not fit for some people in the team, please write if saturday 
> or
> sunday fits better. If multiple people arrive super late we could move things
> around, or have multiple dinners!
>
> Restaurant suggestions are also welcome!
>
>
> (I have CC'ed arch-dev-public since I don't actually know how many people 
> watch
> arch-events. Sorry for the noise!)
>
> --
> Morten Linderud
> PGP: 9C02FF419FECBE16

Re: [arch-dev-public] Remove CAcert root certs

[Pierre Schmitz]

Absolutely fine with me. Things have changed and there are better
options like "Let's Encrypt".

On Tue, Aug 21, 2018 at 8:21 PM, Jan Alexander Steffens
 wrote:
> Hi list,
>
> I completely agree with https://bugs.archlinux.org/task/59690 and would like
> to remove the ca-certificates-cacert package from our repos and our default
> providers. The ca-certificates package will lose the depends and gain a
> replaces and conflicts on -cacert.
>
> Any objections?
>
> Greetings,
> Jan

Re: [arch-dev-public] FrOSCon Arch Linux DevRoom

[Pierre Schmitz]

I could do a talk I guess. Do you know till when we have to create our
program to get it on the Froscon schedule?

On Sun, Jun 10, 2018 at 4:25 PM, Jelle van der Waa  wrote:
> Hi all,
>
> I've managed to get a room for Arch Linux on the Sunday of FrOSCon.
> FrOSCon is a conference ran for a weekend at 25th and 26th August in
> Bonn-Rhein-Sieg. It's a free event thanks to all the sponsors.
>
> We are free to plan our own program on Sunday, however it would be great
> if we could give some talks or a workshop. Since I'm not sure how much
> of the TU/Dev's can attend, community members are also welcome to mail
> me with an proposal for a talk!
>
> P.S. I'll hope to bring Arch stickers.
>
> --
> Jelle van der Waa

Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation

[Pierre Schmitz]

Great. I tried to define it briefly in the README:
https://github.com/archlinux/archlinux-docker#purpose I am open to any
suggestions though.

side note: The "release process" is described within a Makefile at
https://github.com/pierres/archiso-manager

On Mon, Mar 12, 2018 at 7:06 PM, Santiago Torres-Arias via
arch-dev-public <arch-dev-public@archlinux.org> wrote:
> Understood.
>
> Although I don't exactly know what's the "original purpose" I'll try to
> make sure no big radical changes are made without consensus from the
> community :)
>
> Thanks both of you!
> -Santiago.
>
> On Mon, Mar 12, 2018 at 03:41:56PM +0100, Pierre Schmitz wrote:
>> Yeah, that was the "and please don't get it the wrong way" part which
>> obviously did not work. I thought I just put this out there as I
>> already got PRs and mails from different people who wanted to make the
>> image more minimal by removing files from packages or provide
>> different images for all kind of uses cases.
>>
>> I just wanted to avoid frustration beforehand but not discourage your
>> work. I probably failed on this one :-)
>>
>> Greetings,
>>
>> Pierre
>>
>> On Mon, Mar 12, 2018 at 8:19 AM, Bartłomiej Piotrowski via
>> arch-dev-public <arch-dev-public@archlinux.org> wrote:
>> > On 2018-03-12 05:33, Pierre Schmitz wrote:
>> >> Thanks for digging this up again. You may use the github issue or
>> >> project system to plan the different steps. Also (and please don't get
>> >> it the wrong way) let's keep the purpose I intended for our Docker
>> >> image intact.
>> >
>> > No one has suggested changing "the purpose". I'm not sure what is
>> > unclear in Santiago's mail.
>> >
>> > Bartłomiej

Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation

[Pierre Schmitz]

Yeah, that was the "and please don't get it the wrong way" part which
obviously did not work. I thought I just put this out there as I
already got PRs and mails from different people who wanted to make the
image more minimal by removing files from packages or provide
different images for all kind of uses cases.

I just wanted to avoid frustration beforehand but not discourage your
work. I probably failed on this one :-)

Greetings,

Pierre

On Mon, Mar 12, 2018 at 8:19 AM, Bartłomiej Piotrowski via
arch-dev-public <arch-dev-public@archlinux.org> wrote:
> On 2018-03-12 05:33, Pierre Schmitz wrote:
>> Thanks for digging this up again. You may use the github issue or
>> project system to plan the different steps. Also (and please don't get
>> it the wrong way) let's keep the purpose I intended for our Docker
>> image intact.
>
> No one has suggested changing "the purpose". I'm not sure what is
> unclear in Santiago's mail.
>
> Bartłomiej

Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation

[Pierre Schmitz]

Thanks for digging this up again. You may use the github issue or
project system to plan the different steps. Also (and please don't get
it the wrong way) let's keep the purpose I intended for our Docker
image intact.

Greetings,

Pierre

On Mon, Mar 12, 2018 at 12:01 AM, Santiago Torres-Arias via
arch-dev-public <arch-dev-public@archlinux.org> wrote:
> On Fri, Mar 09, 2018 at 09:46:48PM +0100, Bartłomiej Piotrowski via 
> arch-dev-public wrote:
>> On 2018-01-29 20:29, Pierre Schmitz wrote:
>> > * I did not look into the details of how we exactly need to proceed
>> > with making an "official" image. A few pull requests or some kind of
>> > setp-by-step plan (wiki or github) would help.
>>
>> Necrobumping. You actually quoted the message from Santiago that
>> describes the process. I'm going to grant him and Christian write
>> permissions so they can start working on this on separate branch.
>
> Thanks!
>
> I'll dig this up from my pile of things to do now.
>
> -Santiago.

Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)

[Pierre Schmitz]

Sure, I am not suggesting a rewrite; but when we do it a slightly
different approach could be taken.

Also to explain it further: Whether I or someone else is reviewing PRs
I suggest a way how we could manage such major refactorings. ATM the
diff between gbfs and our origin branch reads as:
 80 files changed, 1578 insertions(+), 3959 deletions(-)
It seems nobody really felt comfortable merging that; which is sad as
a lot of effort went into this.

Two possible strategies:
a) Gradual migration: It might not work out for some aspects, but
maybe there is way to prepare the current code to replace svn by git
and postpoing the actual switch to the very end. It's also a good
strategy to always have code merged that can and will be "deployed to
production". Of course this would mean that we have git and svn
running at the same time at some point.

b) Big bang: Refactor in a branch; keep tests working and plan a
migration in the end. Maybe have PRs from feature to a new develop
branch to make code reviews possible. In the end replace the system,
migrate all data and hope for the best.

On Mon, Jan 29, 2018 at 9:05 PM, Eli Schwartz via arch-dev-public
<arch-dev-public@archlinux.org> wrote:
> On 01/29/2018 02:19 PM, Pierre Schmitz wrote:
>> Hi all. I feel bad about this. I was not transparent at all about my
>> plans and got lost in a pile of projects which are only slowly
>> progressing. I started improving dbscripts to make it easier to work
>> with; which led to creating a Docker base image to be able to test the
>> latter. Most of my free time then went into a huge refactoring of
>> archlinux.de to finally extract and improve on the pkgstats backend.
>> Now I am drowning in hundreds of arch related emails and "things I
>> should do".
>
> No problem, life gets to all of us! Thanks for getting back to us about
> what happened so we we don't have lingering feelings of guilt like we
> stole it out from under you, though. :)
>
>> I would welcome help on dbscripts a lot. I had a look at those git
>> attempts in the past but in the end they were not easily mergable.
>> Maybe a few suggestions:
>> * Let's use github for Pull Requests
>
> I'm okay with that, TBH I don't think we got a lot of dbscripts email on
> [arch-projects] but I am okay with tracking patches from either location.
>
>> * Make sure PRs are small enough to be reviewable in let's say within an hour
>
> Well, I think patchsets however they come should probably aspire to this. :D
>
>> * New code needs to be tested (Travis build needs to pass)
>> * Code Coverage should be as close to 100% as possible and useful
>
> I will see what I can do, bats looks simpler than I thought at first anyway.
>
>> If we prefer a complete rewrite (e.g. when moving from Bash to e.g.
>> Go) where small pull requests are not possible and we need to start
>> from scratch, I would still strongly recommend my suggestions above;
>> esp. those about testing.
>
> I see no reason to suddenly rewrite everything in a new programming
> language, surely dbscripts isn't *that* bad! :D
>
> I'm not sure we should be replacing parts of our infra with something
> that isn't a scripted language, but that may be a personal opinion
> Moreover, if the goal is to encourage contributions then bash is a
> pretty good language for that.
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>

Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation

[Pierre Schmitz]

About the ISO bus factor:
* I just recently put the whole process into a simple script to make
it easier for anybody else to build ISOs. Unfortunately at least the
signing process requires some manual work. See
https://github.com/pierres/archiso-manager

About the official Docker Image:
* The docker image archlinux/base is pretty young and I did some
significant changes to its content lately. I am pretty happy with the
result right now but some more field testing shouldn't hurt. On my
virtual todo list is also figuring out whether we could reuse the
created archlinux.tar for other containers as well
* I did not look into the details of how we exactly need to proceed
with making an "official" image. A few pull requests or some kind of
setp-by-step plan (wiki or github) would help.

I am glad the interest in Arch within Docker and other containers is increasing.

Greetings,

Pierre

On Mon, Jan 29, 2018 at 8:20 PM, Santiago Torres-Arias via
arch-dev-public  wrote:
>> > The official images projects info is on [1] and [2] if you want to read
>> > more in-depth/updated information. I'll summarize here though:
>> >
>> > 1) A TU/Arch Linux "affiliate" submits a PR to the official images
>> > repository, which basically contains the following:
>> > 1. A tag name/image name
>> > 2. A sha256/ref of a commit/tag containig the image's information 
>> > on
>> > *another* repository (in this case, our official dockerr image 
>> > repo)
>> > 3. Image building instructions.
>>
>> A PR to this repository is also required, not sure if you mentioned it
>> :) [1]
>
> Right, I omitted that one for the sake of brevity.
>
> Thanks!
> -Santiago.

Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)

[Pierre Schmitz]

Hi all. I feel bad about this. I was not transparent at all about my
plans and got lost in a pile of projects which are only slowly
progressing. I started improving dbscripts to make it easier to work
with; which led to creating a Docker base image to be able to test the
latter. Most of my free time then went into a huge refactoring of
archlinux.de to finally extract and improve on the pkgstats backend.
Now I am drowning in hundreds of arch related emails and "things I
should do".

I would welcome help on dbscripts a lot. I had a look at those git
attempts in the past but in the end they were not easily mergable.
Maybe a few suggestions:
* Let's use github for Pull Requests
* Make sure PRs are small enough to be reviewable in let's say within an hour
* New code needs to be tested (Travis build needs to pass)
* Code Coverage should be as close to 100% as possible and useful

If we prefer a complete rewrite (e.g. when moving from Bash to e.g.
Go) where small pull requests are not possible and we need to start
from scratch, I would still strongly recommend my suggestions above;
esp. those about testing.

Greetings,

Pierre

On Mon, Jan 29, 2018 at 7:29 PM, Gaetan Bisson via arch-dev-public
 wrote:
> [2018-01-29 16:51:54 +0100] Florian Pritz via arch-dev-public:
>> Eli offered to take the lead on getting that done and also later
>> migrating us to git instead of svn. If there are no objections I'll help
>> where necessary and give him access to the dbscripts and devtools repos
>> in two weeks.
>
> That sounds great!
>
> --
> Gaetan

[arch-dev-public] Responsive views for Forums and Wiki

[Pierre Schmitz]

Hi,

for the last few days I had been working on a more mobile friendly
view of our Wikis and Forums. These have just been deployed. Here is
what changed:

While it's not perfect on small screens it should at least be way more
readable on your mobile phones. Let me know of any issues though.

Wiki:
* Updated to MediaWiki 1.29.1
* Removed our fork of the MonoBook skin
* Introduce a new "ArchLinux" extension which injects some styles and
our navigation bar independent of the skin. This was quite a lot of
work to figure out, but future updates should be way easier now.
* The default skin is Vector; MonoBook is still available and can be
enabled in your personal settings
* The MobileFrontend extension has been removed (So we have a branded
view for mobile as well)
* PR see https://github.com/archlinux/archwiki/pull/9/files

Forums:
* Created a github repo at https://github.com/archlinux/archbbs
* PR at https://github.com/archlinux/archbbs/pull/1
* Some docker compose configuration to simplify development (similar
to the on in the wiki)

In addition to this I have been working on a re-implementation of
https://www.archlinux.de. Part of this is a new more mobile friendly
design. Especially the navigation which moves the menu entries into a
so called Hamburger menu on smaller screens is still missing from the
implementation mentioned above.

I plan to extract these "somehow" so we can use a common navigation in
all our websites. At least a generated snippet we can copy into our
projects.

Greetings,

Pierre

Re: [arch-dev-public] Kernel 4.11 status

[Pierre Schmitz]

On 05.05.2017 23:32, Bartłomiej Piotrowski wrote:

On 2017-05-05 08:29, Tobias Powalowski via arch-dev-public wrote:

Your opinion on pushing this to [testing].


I can't care less about binary modules that keep causing problems. +1
for having 4.11 in [testing].

Bartłomiej


I disagree. We should not break [testing] on purpose. We actually want 
people to use [testing] to look for unknown bugs. If we want to drop 
support for the nvidia module that would be a different discussion.


Greetings,

Pierre

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

Re: [arch-dev-public] OpenSSL 1.1.0

[Pierre Schmitz]

On 23.04.2017 03:30, Allan McRae wrote:

On 23/04/17 08:07, Gaetan Bisson wrote:

[2017-04-22 18:05:27 +0200] Sébastien Luttringer:

When do you plan to move openssl rebuild out of testing?


Quoting arojas on IRC:

2017-04-20 09:11:27 arojas: current blocker for openssl if FS#53618
2017-04-20 09:11:47 arojas: someone needs to decide whether we care 
about it or not, and if yes do something to fix it




Given there is a workaround, a news item should be posted and we should
stop blocking the entire distribution with this rebuild.

Allan


This is fine by me. I cannot reproduce the error with Steam. See my 
comment at https://bugs.archlinux.org/task/53618 Does anybody have more 
input on this? Even if games try to access the system library rather 
than the steam ones, this is more of game or steam bug.


Pierre

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

[arch-dev-public] More packages for adoption

[Pierre Schmitz]

Hi all,

let's do some spring cleaning. Here are some packages I no longer use 
and may be adopted by someone more interested in them:

* aspell-de
* fcgi
* fetchmail
* hefur
* imap
* lighttpd
* logrotate
* lynx
* rsync
* run-parts

Let me know if you are interested in maintaining one of these, so I can 
drop maintainer ship. Of course I'll keep updating those that wont find 
a new owner; excep PSI. If there are no objections I'd like to drop the 
following packages as there are no new lreeases since 2012:

* psi
* psi-i18n

Greetings,

Pierre

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

Re: [arch-dev-public] OpenSSL 1.1.0

[Pierre Schmitz]

On 30.01.2017 14:09, Giancarlo Razzolini wrote:

Em janeiro 30, 2017 1:05 Allan McRae escreveu:


Please cite one example.   Every CVE I have seen that is of at least
high severity has affected both.  There have been some low severity 
ones

only affecting openssl.

Even worse, the fix time for libressl in the couple of issues I
monitored was worse than openssl.



I don't have a ready list, but I can make one, sure. One thing I can 
say
is that it wasn't *every*[0] high/critical CVE that affected both 
libraries.


And yes, I presume fix time will be somewhat worse than OpenSSL's, 
because

it is a portable version of a library mainly focused on OpenBSD.

As I said, it is a suggestion for us to consider instead of going 
OpenSSL 1.1
way. Both will be hard, but I think in the end we would be better off 
using

LibreSSL.

Cheers,
Giancarlo Razzolini

[0] https://en.wikipedia.org/wiki/LibreSSL


For now I'd like to keep openssl. This might change when upstream 
projects might switch to libressl. ATM I do not see an objective reason 
to do so. If it is a drop in replacement a separate package could be 
provided.


Greetings,

Pierre

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

Re: [arch-dev-public] OpenSSL 1.1.0

[Pierre Schmitz]

On 29.01.2017 21:49, Pierre Schmitz wrote:

Hi,

I'd like to propose a migration to OpenSSL 1.1. The update comes with
ABI and API changes. Every linked packages needs to be rebuild. There
will likely be broken packages. Once the protobuf* rebuild has left
the [staging] repo I would like to upload a first set of OpenSSL 1.1
packages.

I have created a todo list of packages that either have a direct
dependency on openssl or link to libssl.so.1.0.0 or
libcrypto.so.1.0.0:
  https://www.archlinux.org/todo/openssl-110-rebuild/


I will push the first set of packages to [staging]. Please avoid doing 
other rebuilds until this one is done.


Greetings,

Pierre

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

[arch-dev-public] OpenSSL 1.1.0

[Pierre Schmitz]

Hi,

I'd like to propose a migration to OpenSSL 1.1. The update comes with 
ABI and API changes. Every linked packages needs to be rebuild. There 
will likely be broken packages. Once the protobuf* rebuild has left the 
[staging] repo I would like to upload a first set of OpenSSL 1.1 
packages.


I have created a todo list of packages that either have a direct 
dependency on openssl or link to libssl.so.1.0.0 or libcrypto.so.1.0.0:

  https://www.archlinux.org/todo/openssl-110-rebuild/

Further reading:
* https://wiki.openssl.org/index.php/1.1_API_Changes
* https://wiki.debian.org/OpenSSL-1.1
* https://lists.debian.org/debian-devel-announce/2016/11/msg1.html
* http://pkgs.fedoraproject.org/cgit/rpms/

*) https://www.archlinux.org/todo/protobuf-320/

Greetings,

Pierre

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

Re: [arch-dev-public] [RFC] Add archlinux.org domain to HSTS Preload list

[Pierre Schmitz]

On 04.01.2017 20:43, Giancarlo Razzolini wrote:

Hi All,

  With some improvements we have been doing to the infrastructure, 
we've
  reached a point were practically everything on archlinux.org is 
hosted

  using TLS/SSL.

  I have run a sslyze test on every of our DNS entries and the ones 
that
  did not answered are supposed to. In case you guys are interested, 
I'm
  putting links to the tests I performed in json format in the end of 
the

  email.[0][1]

  My question is, should we add archlinux.org to the HSTS preload 
list?[2]

  Or, better yet, should we ever host something *not* using TLS/SSL?
  Cheers,
Giancarlo Razzolini

[0] Full test, quite big: https://paste.xinu.at/UOII
[1] Failed hosts: https://paste.xinu.at/5srl/
[2] https://hstspreload.org/


In general a great idea. Our Torrent tracker does not support https as 
it seems: http://tracker.archlinux.org:6969/stat I haven't looked into 
it yet though. Port 443 redirects to bbs which is strange...


Greetings,

Pierre

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

Re: [arch-dev-public] readline 7.0 rebuild

[Pierre Schmitz]

On 06.11.2016 20:52, Bartłomiej Piotrowski wrote:

Hi all,

as Evangelos is back with us, the rebuild will be done automatically. 
If

you pushed any packages between the todo creation and reading this
message, don't worry – it will be rebuild again.

I'm removing the todo to prevent further confusion.

Bartłomiej


When do you plan to release these rebuilds from the testing repo?

Greetings,

Pierre

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

Re: [arch-dev-public] Cleaning up the DNS

[Pierre Schmitz]

On 15.06.2016 17:00, Sven-Hendrik Haase wrote:

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


I think the community repo was on a dedicated system once. It should not 
be used anymore. I'd say let's remove that DNS entry and see if anybody 
complains. TU's might use it to connect to nymeria by ssh.


Pierre

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

Re: [arch-dev-public] Hooks rebuild #1

[Pierre Schmitz]

On 27.04.2016 14:36, Allan McRae wrote:

We are ready to start the first hooks rebuild.  This rebuild covers
packages using these hooks:

update-desktop-database
update-mime-database
install-info
glib-compile-schemes
gtk-update-icon-cacne/xdg-icon-resource
gconf
gio-querymodules

Each rebuild requires the install file updated to remove these 
commands.


No need to use staging/testing for this rebuild (except [core] 
packages).


GO!


Why is lib32-openssl on that list?

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

Re: [arch-dev-public] Consensus: DKMS modules

[Pierre Schmitz]

On 15.03.2016 01:06, Allan McRae wrote:

On 14/03/16 09:07, Allan McRae wrote:

On 13/03/16 00:52, Sébastien Luttringer wrote:
Please note that as an ideal target, I would have all our kernel 
modules
available via dkms _and_ via prebuilt modules for each kernel flavor 
we
provide. I read on the dev IRC that few modules could only be shipped 
from

sources. Not sure of that btw.

For example, we could, for simplicity says that we provide pre-built 
modules

only for the main kernel and dkms for all others kernels.

What I would like is a team consensus/decision on how we handle 
kernel oot

modules not complains directed on virtualbox only.



I vote for binary modules for all kernels in [core] and dkms versions.
Kernels outside of [core] can have binary modules provided at the
maintainer's choice.



We are going to need more opinions here to build a consensus...

A


I agree. There is no point in having every user building the exact same 
module on every update. That's why we package precompiled packages. This 
looks more like a workaround of how kernel and module updates are 
handled atm. E.g. the kernel stays in testing for a long time and is not 
put into staging first so packagers can rebuild their modules.


Greetings,

Pierre

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

Re: [arch-dev-public] Issues updating to openssl 1.0.2g

[Pierre Schmitz]

On 05.03.2016 12:16, Pierre Schmitz wrote:

The rebuild is now done and all packages have been moved to the
testing repositories. Thanks to everybody who helped to make this
happen! Please test and sign off the core repository candidates so we
can release these soon.


Packages have been moved. I do expect some breakage especially with 
third party packages. maintainers of e.g. AUR PKGBUILDs should find 
fixes at Debian's or Fedora's repos.


Greetings,

Pierre

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

Re: [arch-dev-public] Issues updating to openssl 1.0.2g

[Pierre Schmitz]

On 02.03.2016 19:14, Pierre Schmitz wrote:

On 01.03.2016 15:53, Pierre Schmitz wrote:

I just looked into updating to openssl 1.0.2g. Unfortunately this
comes with an ABI change due to SSL2 being disabled by default. This
would mean we need to rebuild most packages that link against openssl.
Imho re-enabling ssl2 seems to be a bad idea.


I have updated openssl to also disable sslv3 and zlib besides sslv2.
We are currently rebuilding all depending packages:
https://rebuilds.foutrelis.com/?all It would b great if those packages
wont get updated till we are able to finish this rebuild.


The rebuild is now done and all packages have been moved to the testing 
repositories. Thanks to everybody who helped to make this happen! Please 
test and sign off the core repository candidates so we can release these 
soon.


Greetings,

Pierre

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

[arch-dev-public] Issues updating to openssl 1.0.2g

[Pierre Schmitz]

Hi all,

I just looked into updating to openssl 1.0.2g. Unfortunately this comes 
with an ABI change due to SSL2 being disabled by default. This would 
mean we need to rebuild most packages that link against openssl. Imho 
re-enabling ssl2 seems to be a bad idea.


I already pushed the packages into staging. We would need to do the 
rebuild as quickly as possible.


What do you think?

Greetings,

Pierre

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

Re: [arch-dev-public] PHP 7

[Pierre Schmitz]

On 29.12.2015 20:12, Pierre Schmitz wrote:

I am about to move the packages from [staging] into [testing]


Just moved the packages into [testing]. If nothing breaks I'd probably 
move them to [extra] within the next days.


Greetings,

Pierre

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

Re: [arch-dev-public] PHP 7

[Pierre Schmitz]

On 29.12.2015 09:05, Ike Devolder wrote:

Could you add a note in your announcement that the upcoming php-mongodb
package is not compatible with the current php-mongo (5.x version)


Could you add more details about this? If I get this right, you'd like 
to remove the legacy package named php-mongo but then add the new 
php-mongodb?

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

Re: [arch-dev-public] PHP 7

[Pierre Schmitz]

On 19.12.2015 10:12, Pierre Schmitz wrote:

Hi all,

I would like to publish PHP 7 packages to our repos soon.I have been
working on them for some time now and it looks quite fine.

It comes with a catch though as we'd have to remove most third party
extensions from our repos as they are no longer compatible (some of
them are also no longer in active development). These modules are:

php-geoip
php-memcache
php-memcached
php-mongo
php-xcache

We'd also need to drop PHP support from graphviz and uwsgi.


I am about to move the packages from [staging] into [testing] (have to 
wait for the ruby rebuild to be finished). Good news for geoip and uwsgi 
users as we were able to package patched versions which are now 
compatible with PHP 7.


This means when these are moved to [extra] the following have to be 
dropped for now:


php-memcache
php-memcached
php-mongo
php-xcache
graphviz' PHP bindings

We might also see a php-mongodb package which is not a drop in 
repalcement for php-mongo though.


Greetings,

Pierre

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

Re: [arch-dev-public] PHP 7

[Pierre Schmitz]

On 19.12.2015 10:12, Pierre Schmitz wrote:

We might be able to move these package to [extra] by end of this or
beginning of next year.


Thanks for all the testing! I'll move the packages to [testing] and they 
should hit the [extra] repo shortly after. I'll send an announcement 
draft soon.


Greetings,

Pierre

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

[arch-dev-public] PHP 7

[Pierre Schmitz]

Hi all,

I would like to publish PHP 7 packages to our repos soon.I have been 
working on them for some time now and it looks quite fine.


It comes with a catch though as we'd have to remove most third party 
extensions from our repos as they are no longer compatible (some of them 
are also no longer in active development). These modules are:


php-geoip
php-memcache
php-memcached
php-mongo
php-xcache

We'd also need to drop PHP support from graphviz and uwsgi.

We also provide a bunch of PHP scripts packages which I did not test. So 
any help with these is very appreciated. It would be great to get some 
feedback about this. You'll find my repo with PHP 7 packages and more 
information about all the changes at 
https://pierre-schmitz.com/php-7-on-arch-linux/ These packages are 
considered stable and I will provide a smooth upgrade path when these 
hit [extra] (means: just add the repo and you are done).


We might be able to move these package to [extra] by end of this or 
beginning of next year.


Greetings,

Pierre

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

Re: [arch-dev-public] C++ ABI rebuild announcement

[Pierre Schmitz]

On 10.12.2015 04:02, Allan McRae wrote:

Here is a draft announcement.


I assume the cxx11abitest symlink can be reomved from he repos now?

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

Re: [arch-dev-public] C++ ABI rebuild announcement

[Pierre Schmitz]

On 13.12.2015 10:28, Allan McRae wrote:

On 13/12/15 19:02, Pierre Schmitz wrote:

On 10.12.2015 04:02, Allan McRae wrote:

Here is a draft announcement.


I assume the cxx11abitest symlink can be reomved from he repos now?



Can you clarify what/where this is?  I have no idea...

A


It looks like it is only on at least one mirror:

rsync://mirror.leaseweb.net/archlinux/

ignoring unsafe symlink "cxx11abitest" -> "/mnt/cxx11abitest/repo/"

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

Re: [arch-dev-public] FOSDEM 2016 participation (please reply until Wednesday if you are interested)

[Pierre Schmitz]

On 05.10.2015 19:44, Thomas Bächler wrote:

..

So, anyone who is interested to
 1) help watch the room
 2) give a talk
 3) hold a discussion panel
 4) bring hardware
 5) generally be there
 6) ...
..


Thanks for bringing this up. I plan to be there; I still need to 
organize accommodation and travel though. What kind of hardware did you 
have in mind? I doubt I can bring anything else other than my notebook. 
I am interested in everything else though; especially number 6.


I still need to come up with a useful topic for a talk. Maybe something 
about packaging, containers, organizing the Arch project or a 
combination of these.


Greetings,

Pierre

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

Re: [arch-dev-public] Automated rebuild for ncurses 6.0 in progress

[Pierre Schmitz]

On 06.09.2015 19:02, Evangelos Foutras wrote:

You can follow the progress at: https://rebuilds.foutrelis.com/

If anyone wants to tackle a build failure, you can commit the fix in
/trunk (without bumping pkgrel) and then click on the failing package
and select "Retry build task".

Note: This rebuild is not listed on https://www.archlinux.org/todo/ in
order to avoid any confusion.


Looks awesome. How exactly is this down? Did you setup jenkins etc.?

Greetings,

Pierre

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

Re: [arch-dev-public] [arch-events] FrOSCon 2015

[Pierre Schmitz]

On 02.06.2015 17:39, Pierre Schmitz wrote:

Hi all,

I did not get any feedback yet. Is there any interest to meet up at
FrOSCon?


Hi there,

the conference starts this Saturday. If anybody else wants to join us in 
the dev room, drop me a mail so you can add you to the list of 
participants.


Greetings,

Pierre

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

Re: [arch-dev-public] PGP key update

[Pierre Schmitz]

On 12.06.2015 17:56, Evangelos Foutras wrote:
On Fri, Jun 5, 2015 at 7:42 AM, Pierre Schmitz pie...@archlinux.de 
wrote:

there is a new keyring package in testing.


Can we move this to [core]? The old signature expired today.


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

Re: [arch-dev-public] PGP key update

[Pierre Schmitz]

On 04.06.2015 21:56, Johannes Löthberg wrote:

Hey,

I just noticed that my PGP key had an expiry on the 12th, so have
extended it a year and pushed to keyservers. Could some dev push a new
keyring package with the updated key?


Hi,

there is a new keyring package in testing.

Greetings,

Pierre

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

[arch-dev-public] Fwd: [arch-events] FrOSCon 2015

[Pierre Schmitz]

Hi all,

I did not get any feedback yet. Is there any interest to meet up at 
FrOSCon? And if anybody like to join and prepare a talk or workshop 
that'd be great. I'd then update our submission.


A few rough ideas would be sufficient.

Greetings,

Pierre

 Original Message 
Subject: [arch-events] FrOSCon 2015
Date: 21.05.2015 21:30
From: Pierre Schmitz pie...@archlinux.de
To: Mailing list for Archlinux events arch-eve...@archlinux.org
Reply-To: Arch Linux Events arch-eve...@archlinux.org

Hi all,

let's get started for this year. I went ahead and registered a Devroom 
as the deadline is approaching. I think we saw some nice potential last 
year in having our own track.


Now, who like's to give a talk or help hosting an event (including 
hackathons etc.)


If a booth is wanted as well we need to register asap; but we'll need a 
couple more staff on site then.


Btw, see http://www.froscon.de/startseite/ or 
http://www.froscon.de/en/home/


Greetings,

Pierre

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

Re: [arch-dev-public] [arch-commits] Commit in xz/trunk (PKGBUILD)

[Pierre Schmitz]

Am 28.12.2014 10:36, schrieb Andreas Radke:

What's the plan with xz update? Will you push 5.2.0 with smp
support right after the 5.0.8 update?

-Andy


Yes, that's the plan. Atm I only have very limited internet access and 
no current repo snapshot.


Greetings,

Pierre

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

Re: [arch-dev-public] Proposal: enabling full ASLR on x86_64 via hardening-wrapper

[Pierre Schmitz]

Am 26.12.2014 01:56, schrieb Allan McRae:
I am not in favour of using the hardening script because I don't find 
it

adheres to what we consider KISS.  Our build system is supposed to be
simple and entirely transparent when looking at the PKGBUILD and 
default

makepkg.conf.  Any user can run abs and makepkg and get (roughly)
the same package.


I agree, using such hacks kind of violates the kiss principle and our 
policy to follow upstream and don't patch or fork. I suggest to revistd 
this proposal once the needed changes are available upstream.


Greetings,

Pierre

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

[arch-dev-public] Dropping logrotate from core/base

[Pierre Schmitz]

Hi,

I just pushed a logrotate package to testing that is no longer part of 
the base group. This also means that this package can be moved from core 
to extra.


Any objections? I am not sure about e.g. wtmp faillog etc. So I might 
just need to revert that change.


Pierre

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

Re: [arch-dev-public] Plex Media Server in [community]

[Pierre Schmitz]

Am 14.10.2014 13:04, schrieb Andrea Scarpino:
On Tue, Oct 14, 2014 at 12:50 PM, Allan McRae al...@archlinux.org 
wrote:
Given it is a binary source, I see no real advantage to adding it to 
the

repositories.


Yep, me neither.

In fact I'd like to drop any binary source from our repositories...


I need to strongly disagree here. Why would we only package software 
that is compiled from source? What about scripting languages?


Or do you refer to the free software aspect here? We never forced people 
to only use or package free software and I hope we keep it that way.


So far our policy has been simply: Are we allowed to redistribute it?

And in case of Plex the answer seems to be: No we cannot! As 
https://plex.tv/legal states:
You may not, or allow anyone else to, directly or indirectly to: (1) 
copy, modify, distribute, sell, or lease any part of the Software


A random post on the forum is probably not enough; they need to update 
their terms if they want anybody to distribute their software.


Greetings,

Pierre

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

[arch-dev-public] PHP composer in [testing]

[Pierre Schmitz]

Hi all,

I just put an initial version of PHP composer* into the [testing] 
repository. It's a local (per project) package manager and required by a 
lot of PHP developers but also administrators.


Unfortunately the PKGBUILD is self referencing and I had to patch it 
using our own php.ini file as the global one might more be tweak for 
production usage.


Let me know of any problems or suggestions. We'll see if we can work 
with upstream to make this more distribution friendly.


Greetings,

Pierre


*) https://getcomposer.org/

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

Re: [arch-dev-public] [arch-events] FrOSCon 2014 - 23. 24. August

[Pierre Schmitz]

Am 23.05.2014 20:50, schrieb Pierre Schmitz:
I did register an application for a dev room. I still need a little 
help though:


* A list of participants and their mail address
* project description in German and English
* Our program for the devroom
* How many guests do we expect

Sounds like we might even be able to give mall talks in our dev room
if we like. But we need to apply for this now and provide at least a
rough plan.


Hi all,

I am cc'ing to dev-public to reach a broader audience. Maybe other dev 
or tus are interested.


I got an answer from the FrOSCon team and we have to choose between two 
options:

1) a room for 25 people, a built-in beamer but for only one day.
2) a smaller room for 10 people with an optional mobile beamer but for 
both days.


If we take option 1 we need to organize a couple of talks. We should use 
up to 6 slots a day: https://paste.archlinux.de/35ocw/plain
This could include some (open) dev meeting or discussions. But we 
probably need like three people who are willing to give a talk in front 
of a small group. As we did not do this before I am definitely 
interested in giving it a try. It shouldn't be too hard to come up with 
3 or 4 topics worth talking about. (We have till August to finalize 
these for the printed program)


Please let me know what you think about this and which option we should 
take. Also send me you name and mail address if you are likely to 
participate so I can sign you up for tickets.


@Thorsten: Did you hear back about the booth? We might combine these as 
in taking the dev room for Saturday and the booth for Sunday.


Greetings,

Pierre

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

Re: [arch-dev-public] [Draft] MariaDB 10.0 enters [extra]

[Pierre Schmitz]

Am 17.05.2014 14:40, schrieb Bartłomiej Piotrowski:

Hi guys,

New MariaDB is sitting in [testing] for a while now. It's temporarily
built using Clang, mainly because new gcc snapshot hasn't fixed
segfaults for everyone. I want to resolve it before moving anything,
but in the meantime I wrote an announcement draft.

Title: MariaDB 10.0 enters [extra]

Content:
A new major release of MariaDB will be moved to [extra] soon. The 
change

in versioning scheme has been made to clearly distinguish provided
functionality from MySQL 5.6. From now on, it won't be possible to
easily move between various MySQL implementations provided in the
official repositories.


I guess the client library remains compatible or do we need to recompile 
packages? ATM we also provide MySQL 5.6 by packaging the percona fork. 
It provides the mariadb version as well, is that still sensible with 10 
starting to be incompatible with mysql?



Due to major changes in MariaDB 10.0, it is recommended (although not
necessary) to dump the tables before upgrading and reloading the dump
file afterwards. After upgrading to the new version don't forget to
restart `mysqld.service` and run `mysql_upgrade` to check the databases
for possible errors.


Why is it recommend to reload from a dump? Some more details would be 
good, as this is not easily doable (without a longer downtime) for users 
with large databases.



Additionally TokuDB storage engine has been disabled because of
repeating build failures. I'm sorry for any inconvenience caused.


Well, we provide this with our current 5.5 packages? What happens to 
those who use this? Instead of the I am sorry.. part, better link to 
the upstream bug report.



For detailed information on changes and upgrade steps, please refer to
[MariaDB Knowledge
Base](https://mariadb.com/kb/en/what-is-mariadb-100/) and [MySQL
Reference
Manual](https://dev.mysql.com/doc/refman/5.6/en/upgrading.html).


In addition to this, is the gcc 4.9 issue reported somewhere and the 
workaround confirmed? This bug seems to destroy the db files, so we 
better be sure.


Greetings,

Pierre

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

Re: [arch-dev-public] Fwd: [arch-general] Java 8

[Pierre Schmitz]

Am 30.03.2014 11:21, schrieb Guillaume ALAUX:
 I have been working on a package based on OpenJDK8 built from source
 but without IcedTea that I think would fit to our repos. I still have
 some work for it to be released but I would be in favor of pushing
 this OpenJDK without IcedTea to extra until IcedTea v3.0 stable is
 out and could be used to build/augment our package.
 
 Any thought/objection/remark about?

So this OpenJDK would then be identical to what Oracle offers as binary
download? What do the IceTea patches provide then? If in doubt I would
applayy our don'T patch policy and ship whatever we get from upstream.

Greetings,

Pierre

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

Re: [arch-dev-public] [RFC] Add ARM to archlinux.org

[Pierre Schmitz]

Am 24.03.2014 23:35, schrieb Sébastien Luttringer:
 Hello,
 
 As you may know I'm running ARM[1] since the last maintainer resign in
 August 2013. I would like to propose its addition into our official
 services.
 
 My current suggestion is to keep the current server and hierarchy and to
 move it under an archlinux.org subdomain. So far, best suggestions are:
 - archive.archlinux.org
 - museum.archlinux.org
 - rollback.archlinux.org
 
 Current cost in byte is:
 # du -hcs 2013 2014
 111G2013
 55G 2014
 165Gtotal
 
 In a second time, we could:
 - move the files on an official server
 - move installer backups[2]
 - add AUR
 - backup them (by mirroring or others)
 
 Current used scripts are freely available here[3].
 
 [1] https://wiki.archlinux.org/index.php/ARM
 [2] https://users.archlinux.de/~pierre/archive/
 [3] https://github.com/seblu/armtools

Hi,

In general I think having a reliable package archive would be quite
beneficial to us and our users. IMHO we should support such an effort
financially and technically. I had used the original one to find a few
regressions and also test certain upgrade scenarios.

I would feel bad if we base our technical decision on a
misinterpretation or abuse of some users who are unwilling to read
documentation or warnings. Of course downgrading will be kept
unsupported.

I think we really shouldn't name it ARM or use the word rollback at all.
Let's call it package archive. That's more to the point and neutral
related to its possible usage. So I guess names like
archive.archlinux.org or museum.archlinux.org should be safer to avoid
misunderstandings.

I would also concentrate on the first step for now. We could setup a
master server that holds the old packages of one or two years (depending
on the available disk space). We should also setup a rsync setup like we
have on nymeria and see if we can find people who like to mirror it.
About 200GB is quite a lot, but not that unrealistic to host. The
traffic should be way less than for a regular mirror though.

Greetings,

Pierre

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

Re: [arch-dev-public] brynhild down a.k.a pkgbuild.com

[Pierre Schmitz]

Am 30.03.2014 10:54, schrieb Ionut Biru:
 Nice to hear that.
 
 Jan, mentioned that it will help more to have ssd on build server as well.
 Should we get SSD for it as well for an extra 10 EURO/mo ?

Sure, SSDs are allways faster. Problem is that we might run into disk
space issues; atm we use about 111GB. We also might be able to use tmpfs
to build.

Anyway, as I don't use this system, decide whatever you think is best.

Greetings,

Pierre

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

Re: [arch-dev-public] brynhild down a.k.a pkgbuild.com

[Pierre Schmitz]

Am 28.03.2014 15:26, schrieb Ionut Biru:
 We have to do something about it before getting a new invoice for this
 piece of crap. I see that Bluewind started to resolve a bit this issue
 but now it's offline again.
 
 alderaan replacement - 32 gb ECC with 2x240gb ssd is a.k.a PX60-SSD
 79€/mo + 99 € setup
 
 brynhild replament (if we don't keep the current alderaan for building)
 - 32 gb non ecc - 49€/mo + 49€ setup.
 
 
 We need to decide until 31 march.
 
 Lets do a vote.

Let me forward that to Aaron to check if he can give his OK financially.

That would be a one time fee of 99 + 49 = 148 € and our monthly fees
would increase by 30 €.

This means about 20 € extra for ECC RAM (if we still think that worth
it) and 10 € for SSDs instead of spinning drives.

Greetings,

Pierre

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

Re: [arch-dev-public] brynhild down a.k.a pkgbuild.com

[Pierre Schmitz]

Am 22.03.2014 18:15 schrieb =?UTF-8?B?SW9udcibIELDrnJ1?= biru.io...@gmail.com:

 Update, they found nothing, that's not a surprise and we always had a 
 problem with it (bit flip problem from time to time). 

 I think is time to stop using this server and get a newer one. 

 You guys mentioned that ecc it's a must. They have ex60 now with 32gb with 
 intel xeon. for 69€/mo and for an additional ip we can have ipmi access as 
 well but setup is 99€ 

 My idea is to move forums/wiki/aur on this on since we struggle a bit with 
 ram on alderaan and use alderaan as build box. 

 What do you guys think? 



 On Sat, Mar 22, 2014 at 11:56 AM, Ionuț Bîru biru.io...@gmail.com wrote: 

  Hello, 
  
  Just to let you guys know, the server became unstable and unreachable 2 
  hours ago. 
  Is rebooting by itself couples of times and then is unreachable and cannot 
  be even hard rebooted from the interface. 
  
  The guys from hetzner are performing a hardware check right now, they said 
  it may take up to 10-14 hours. 
  Sadly, I won't be available more to follow this, Florian is getting all 
  the emails from support. 
  
  -- 
  Ionut 
  



 -- 
 Ionut

Hi,

A replacement for alderaan would be great as we could easily use more RAM for 
our DB. I'd even say the EX40 with SSDs might be worth a look. That would 
probably solve our forum search issues by brute force. I'd prefer this over 
ECC, but I wouldn't argue if we can pay for both.

As for the current alderaan server: I'd say we cancel this as well and get at 
least an EX40 as build system. It's faster, has better disks and four times the 
RAM. The monthly fee is the same.

Greetings,

Pierre

Re: [arch-dev-public] Upgrading Apache to 2.4

[Pierre Schmitz]

Am 06.03.2014 22:48, schrieb Anatol Pomozov:
 Hi
 
 On Wed, Feb 26, 2014 at 10:10 AM, Anatol Pomozov
 anatol.pomo...@gmail.com wrote:
 Hi

 On Wed, Feb 26, 2014 at 10:01 AM, Alexander Rødseth rods...@gmail.com 
 wrote:
 One suggestion is creating the Apache 2.4 PKGBUILD first, then talk to
 Jan de Groot.
 If he should not be interested in the endeavor, talk to another dev.

 Good news is that I work with Jan and other devs on pushing Apache 2.4
 to repos. In general they are very positive about this move.

 PKGBUILD is ready and once db5 todo is done I'll create Apache2.4 todo
 to rebuild the deps. So hopefully we'll see official apache 2.4
 package in [extra] some time soon. Stay tuned.
 
 Apache 2.4 has been moved from [testing] to [extra] and now available
 for everyone. Please update your setup, follow the migration
 instructions https://httpd.apache.org/docs/trunk/upgrading.html and
 report any problems.
 
 Thanks everyone.

I think we should write a short announcement about the Apache update and
maybe also mention the possible issues people run into when trying to
use mod_php with a threaded mpm.

Greetings,

Pierre

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

Re: [arch-dev-public] Upgrading Apache to 2.4

[Pierre Schmitz]

Am 26.02.2014 19:10, schrieb Anatol Pomozov:
 Hi
 
 On Wed, Feb 26, 2014 at 10:01 AM, Alexander Rødseth rods...@gmail.com wrote:
 One suggestion is creating the Apache 2.4 PKGBUILD first, then talk to
 Jan de Groot.
 If he should not be interested in the endeavor, talk to another dev.
 
 Good news is that I work with Jan and other devs on pushing Apache 2.4
 to repos. In general they are very positive about this move.
 
 PKGBUILD is ready and once db5 todo is done I'll create Apache2.4 todo
 to rebuild the deps. So hopefully we'll see official apache 2.4
 package in [extra] some time soon. Stay tuned.

I did push a rebuild PHP into [staging]. I had to add a hack to keep the
non-ZTS build that can only be used with the prefork MPM. For some
reason PHP devs thought it would be a good idea to base a PHP compile
time option on the stat of an Apache runtime config. Some day we might
just drop mod_php; I cant think of any sane usage of this SAPI. Am I
correct that Apache can now use FastCGI without third-party modules?

Anyway, I suggest in the end we should post an announcement on the front
page. IMHO that install message is not really needed then, but that
might be debatable.

Greetings,

Pierre

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

Re: [arch-dev-public] nvidia 331.49

[Pierre Schmitz]

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

Re: [arch-dev-public] Linux 3.13 status

[Pierre Schmitz]

Am 20.02.2014 20:32, schrieb Thomas Bächler:
 $ dmesg -t | grep ^i8042

This needs to be in quotes (at least on zsh):
  $ dmesg -t | grep '^i8042'

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

Re: [arch-dev-public] Fwd: The Final Cleanup

[Pierre Schmitz]

Am 07.12.2013 14:06, schrieb Thomas Bächler:
 Am 06.12.2013 18:20, schrieb Alexander Rødseth:
 * Arch Linux has vanilla packages, so we should try to avoid including
 files that are hand-crafted by packagers
 
 If the files are needed, we include them. It's that simple.
 
 * It clutters the repository
 
 One or two extra files per package is not a problem.
 
 * Including .desktop files is basically the same as patching. And this
 quote: Patching only occurs in extremely rare cases, to prevent
 severe breakage in the instance of version mismatches that may occur
 within a rolling release model. from
 https://wiki.archlinux.org/index.php/Arch_Linux
 
 That is nonsense. A .desktop file is a simple configuration file. We
 ship custom default configurations for our packages whenever necessary.
 
 More importantly, we should never compromise functionality for
 ideological or political reasons - for me, that is part of Arch's
 simplicity.
 
 In short, whenever upstream provides a correct .desktop file, we should
 use it. Otherwise, we should provide our own (exactly like we do with
 .service files).

I agree; let's not make things more complicated than needed. If a dev
wants to maintain his own desktop file, that's fine. We should try to
push these upstream though (similar to service files).

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

[arch-dev-public] Web servers down

[Pierre Schmitz]

Hi all,

currently some of our servers are unreachable due to a DDOS attack. 
This affects forums, wiki and AUR (also everything on archlinux.de). See 
http://www.hetzner-status.de/en.html for updates.


Greetings,

Pierre

--
https://pierre-schmitz.com

Re: [arch-dev-public] Making !staticlibs the default in makepkg.conf

[Pierre Schmitz]

Am 18.10.2013 03:01, schrieb Allan McRae:
 On 17/10/13 01:18, Andreas Radke wrote:
 Am Tue, 15 Oct 2013 23:18:00 -0400
 schrieb Eric Bélanger snowmanisc...@gmail.com:

 I just discussed on IRC with Allan about the possibility of
 making !libtool the default in makepkg.conf. Currently, 104 packages
 contains *.la files (mostly gambas stuff). We could check which of
 these packages really require the libtool files and add an
 options=('libtool') to them. This could be done at the same time as
 the !staticlibs rebuild.  Any objections?

 Eric


 Sounds good to me.

 +1

 
 If there are no objects to makeing !libtool the default too, I will do
 the pacman rebuild this weekend.
 
 Allan

OK, I'll update devtools once this happens.

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

Re: [arch-dev-public] Git

[Pierre Schmitz]

Am 29.09.2013 21:07, schrieb Tom Gundersen:
 On Sun, Sep 29, 2013 at 9:00 PM, Alexander Rødseth rods...@gmail.com wrote:
 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?
 
 I'm strongly in favor of git, and would be happy to work on the
 transition if we decide to make the switch.
 
 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 are going to do this change, let's spend some time on discussing
 how we want the new layout to be like. I think we can simplify stuff a
 lot compared to current svn.
 
 -t

We already did, but no time to implement yet:
https://wiki.archlinux.org/index.php/User:Pierre/pkgdbgit

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

Re: [arch-dev-public] Account removal for Daenyth (was: Special Removal of an Inactive TU: Daenyth)

[Pierre Schmitz]

Am 28.09.2013 11:57, schrieb Florian Pritz:
 Daenyth resigned on 27 Aug 2013 via Mail to Lukas with the subject Re :
 TU Votes -- Reminder!. Apparently this has been missed so his accounts
 are still marked TU in the bbs and archweb and he is still listed as
 maintainer for 35 packages in archweb.
 
 I've disabled his accounts on nymeria and brynhild, marked him past TU
 in the wiki and removed the TU status on flyspray. Someone else please
 take care of archweb and bbs.

This reminds me: We need some kind of policy regarding the gpg keys of
fellow packagers. As soon as there are no longer packages in the repos
we should remvoe the key from the keyring package.

The question that remains is if master key holders should revoke their
signatures on such keys. It's not so much I wouldn't trust fellow
packagers anymore, but an uused but valid signing key in the wild is
just an unnecessary risk imho. Let's say a former dev get his laptop and
that key stolen in a few years. I am not sure if I would blame him if he
would forget to inform us.

Maybe a simple rule of thumb: keys that are not or no longer included in
the keyring package cannot be valid.

Greetings,

Pierre

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

[arch-dev-public] systemd 207 ignores /etc/sysctl.conf

[Pierre Schmitz]

Hi,

a new features in systemd 207 is to no longer read /etc/sysctl.conf.
Instead /etc/sysctl.d/*.conf has to be used. Imho this needs a news item
and we also need to think about what to do with the file we ship as part
of procps-ng.

From the systemd changelog:
* The systemd-sysctl tool no longer natively reads the
  file /etc/sysctl.conf. If desired, the file should be
  symlinked from /etc/sysctl.d/99-sysctl.conf. Apart from
  providing legacy support by a symlink rather than built-in
  code, it also makes the otherwise hidden order of application
  of the different files visible.

Greetings,

Pierre

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

Re: [arch-dev-public] systemd 207 ignores /etc/sysctl.conf

[Pierre Schmitz]

Am 13.09.2013 19:47, schrieb Gaetan Bisson:
 [2013-09-13 16:37:16 +0200] Tobias Powalowski:
 All default values from sysctl.conf which are active are also the kernel
 default so no need to ship this file anymore.
 
 Great.
 
 I've just pushed procps-ng-3.3.8-3 to [testing]. It does not ship
 /etc/sysctl.conf anymore and post_upgrade() prints a message informing
 the user of the new location where their changes should go.

Note that this also renames the original file to
/etc/sysctl.conf.pacsave.

Anyway, we should still come up with a short news item; shouldn't hurt
us and probably saves people some trouble. Also adding a line about the
rationale of this upstream change would be nice.

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

Re: [arch-dev-public] systemd 207 ignores /etc/sysctl.conf

[Pierre Schmitz]

Am 13.09.2013 23:10, schrieb Gaetan Bisson:
 [2013-09-13 21:59:17 +0200] Pierre Schmitz:
 Anyway, we should still come up with a short news item; shouldn't hurt
 us and probably saves people some trouble.
 
 Here's a proposal:
 
 
 From version 207 on, systemd will not apply the settings from
 /etc/sysctl.conf anymore: it will only apply those from /etc/sysctl.d/*
 . Since the settings of our default /etc/sysctl.conf shipped by
 procps-ng have become kernel defaults anyway, we have decided to
 deprecate this file.
 
 Upon upgrading to procps-ng-3.3.8-3, you will be prompted to move any
 changes you made to /etc/sysctl.conf under /etc/sysctl.d . The easiest
 way to do this is to run:
 
   pacman -Syu
   mv /etc/sysctl.conf.pacsave /etc/sysctl.d/99-sysctl.conf
 
 If you never customized /etc/sysctl.conf, you have nothing to do.

Sounds fine to me.

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

Re: [arch-dev-public] db6 rebuild dropped - new ToDo list

[Pierre Schmitz]

Am 19.08.2013 08:20, schrieb Gaetan Bisson:
 [2013-08-10 11:47:50 +0200] Andreas Radke:
 Berkeley db5 won't see much further updates if any at all. We should
 check each package that now links to it if that functionality is
 essentially required.
 
 For postfix, it is not strictly required, but upgrading to a db-free
 postfix will require user intervention. This is probably worth it but I
 would welcome the input of other devs. Please discuss there:
 
   https://bugs.archlinux.org/task/36592

I would suggest to keep db support here for now. Esp. when user
interaction is required and there is a good chance of breakage. There is
no need to hurry, as db5 will be around and used by other distros for
some time. In these cases it would be best to push the decision
upstream.

Greetings,

Pierre

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

Re: [arch-dev-public] [core] build failures - 2013/08/14

[Pierre Schmitz]

Am 14.08.2013 02:38, schrieb Allan McRae:
 A couple of new failures here, but nothing related to the new toolchain.
 
 Build failures:
 FAIL:  openssl (perl 5.18 pod issue)

Afaik there is no solution yet; probably need to downgrade Perl if we
have to build openssl.

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

[arch-dev-public] PHP 5.5 entering [testing]

[Pierre Schmitz]

Hi all,

I'll move PHP 5.5 into testing soon. I'll rebuild the dependent modules
inside staging; so you can ignore any mail from the todo system you get
about that.

I'll create a second todo list with all the scripts we provide to check
their compatibility. I have been testing this for quite some time now
and don't expect any serious issues. Some scripts that set
error_reporting might need to be adjusted to suppress deprecation
warnings (FluxBBfor example:
https://projects.archlinux.org/vhosts/bbs.archlinux.org.git/commit/?id=aa747dac2a020a8d6200d4984cf035fff9c8d107)

Manual intervention is needed if you use APC. You can either use the new
opcache module and APCu for data caching or XCache. I'll need to write
an announcement about this.

Greetings,

Pierre

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

Re: [arch-dev-public] PHP 5.5 entering [testing]

[Pierre Schmitz]

Am 10.08.2013 16:38, schrieb Pierre Schmitz:
 I'll create a second todo list with all the scripts we provide to check
 their compatibility. 

This list can be found here:
https://www.archlinux.org/todo/php-55-scripts-check-list/

If you are not the maintainer but know that a certain script is fine
please to mark it as complete as well. Also, if you are not a TU or Dev,
send me a mail if you tested a certain package.

Greetings,

Pierre

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

[arch-dev-public] licensing issues with DB 6.0

[Pierre Schmitz]

Hi all,

we just finished the db 6.0 rebuild in staging. I was pointed* to an
issue with it's license though. It seems Oracle switched the license to
AGPL with version 6.0. I am not an expert, but afaik this makes it only
compatible with GPL3 clients and also enforces the AGPL terms on those.

Debian had a similar discussion
https://lists.debian.org/debian-legal/2013/07/msg0.html

If you think this is indeed a problem, I suggest to drop the rebuild for
now and keep db-5. We could introduce a db6 package if packages really
need that and are license-compatible. We might also want to try to
disable db-functionality if possible and switch to alternative
implementations.

Greetings,

Pierre

*) https://bugs.php.net/bug.php?id=65426

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

Re: [arch-dev-public] licensing issues with DB 6.0

[Pierre Schmitz]

Am 09.08.2013 19:54, schrieb Andreas Radke:
 After some reading the AGPLv3 license is not different from GPLv3
 with one addition. Since many services now run in the cloud in AGPLv3
 this is also covered as distribution of the code and must be done
 under the same rights that GPLv3 would require when shipping software
 as binary builds via some storage media.
 
 We do not change anything to the db v6 code base. A quick overview
 over the rebuilt packages I can't see a pkg that is published under a
 non-free license.
 
 If we would be allowed to link to DBv6 if it would be under GPLv3 then
 we are also allowed to link to it under AGPLv3.
 
 I see no serious reason to not accept that license change.

If I got it right, the problem is that it's not possible to link to AGPL
code within a program which has an incompatible license. So the linking
exception does not apply here (as it does for e.g. LGPL). So only
packages that are either AGPL3 themselves or GL3 can use DB6. Even GPL2
would not be possible; which is why Debian would need to relicense their
apt package in order to use DB 6.

Greetings,

Pierre

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

Re: [arch-dev-public] Nginx

[Pierre Schmitz]

Am 01.08.2013 22:59, schrieb Sébastien Luttringer:
 Externals modules are not often updated (e.g: auth-pam 11/2010,
 upstream-fair: 4/2012). Furthermore, there is no install-time
 dependencies added by passenger or the previous others external.
 
 Taking this in consideration, there is probably no need to split nginx
 and we can have only one package and update it when it's necessary.

The PKGBUILD looks strange, but I guess you already noticed that. The
nginx-extra package is identical to the nginx package except its
dependencies. Just use optdepends here if needed.

But more important please don't add random third party patches/modules
and keep the package vanilla. There are good reasons we have the don't
patch policy. They can break on nginx updates, introduce new issues
etc.; esp. since they are built-in. There might be very good reasons why
these modules are not included in the upstream distribution.

So in short: Don't split nor patch and keep the package as vanilla as
possible.

People can easily build their own if they need special modules or
patches.

Greetings,

Pierre

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

Re: [arch-dev-public] Nginx

[Pierre Schmitz]

Am 02.08.2013 14:14, schrieb Bartłomiej Piotrowski:
 On 2013-08-02 08:41, Pierre Schmitz wrote:
 But more important please don't add random third party patches/modules
 and keep the package vanilla. There are good reasons we have the don't
 patch policy. They can break on nginx updates, introduce new issues
 etc.; esp. since they are built-in. There might be very good reasons why
 these modules are not included in the upstream distribution.
 
 But the main point is to create separate nginx package with third party
 modules. Now we ship nginx with Passenger module and I have to rebuild
 nginx every time the latter has been upgraded.
 
 If we would create nginx-3rdparty, we could move Passenger and add other
 external modules by the way.

First, I have to apologize; I thought the nginx package would also have
these external modules. I missed that you build two copies in the
build function.

If you abuse the split package this way, you still have to rebuild and
publish both split packages if e.g. the passenger module requires a
rebuild.

In general I am not sure if there is a sane way to package these build
time modules. It would be impossible to cover all the combinations and
external modules a user might want. Is it a good idea to provide a
separate package that has all kinds of different modules built in?
Probably not. And people who need certain non-standard modules are
better off compiling their own package.

I would probably provide a vanilla package with sensible defaults and
make it easy for people to extend on that.

Greetings,

Pierre

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

Re: [arch-dev-public] Nginx

[Pierre Schmitz]

Am 02.08.2013 15:38, schrieb Sébastien Luttringer:
 In general I am not sure if there is a sane way to package these build
 time modules. It would be impossible to cover all the combinations and
 external modules a user might want. Is it a good idea to provide a
 separate package that has all kinds of different modules built in?
 There is  no perfect solution with build time modules. It's broken by design.

Does anybody know why the devs don't want or implemented modules than
can be loaded at runtime?

 Probably not. And people who need certain non-standard modules are
 better off compiling their own package.

 I would probably provide a vanilla package with sensible defaults and
 make it easy for people to extend on that.
 So, I think we'll rollback to one package co-maintained by Bartholomej and me,
 with interesting optional modules and auth-pam (I use it).
 Nothing should block a nginx update, so if auth-pam is incompatible,
 it will be dropped.
 
 Passenger external module will be dropped as it causes too frequent rebuild.

I'd say better drop all third-party modules even if you use it yourself.
I don't see why this should be an exception on the contrary: it was not
merged upstream and it was last updated in 2010. And dropping it in case
of an issue also introduces unexpected regressions for those users who
started using it.

So my recommendation would still be to keep at least the nginx package
minimal and vanilla.

Greetings,

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

[arch-dev-public] Announcement for the 2013.07.01 ISO image

[Pierre Schmitz]

Hi all,

with the July install image a few notable features got added. There is
initial support for secure boot and there are bootstrap tar files which
can be used to install Arch from within another distribution.

I have a hard time to write a news item about these though. I think it
would be best if we had at least some short documentation about these in
our wiki we can link to. There is probably no harm in delaying the
announcement for a few days as these are just new features.

Greetings,

Pierre

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

Re: [arch-dev-public] Bootstrap images for installing Arch from another system

[Pierre Schmitz]

Am 22.06.2013 17:33, schrieb Thomas Bächler:
 Setting up Arch on a root server should be as easy as this:
 * Boot rescue system, make sure you have Linux 2.6.32 or later
 * Download tarball from Arch, extract to /tmp/root.x86_64/
 * Set up partitions and such, mount to /tmp/root.x86_64/mnt/
 * chroot /tmp/root.x86_64/ (well, also some bind-mounts)
 * pacman-key --populate archlinux
 * pacstrap /mnt base and follow the installation guide
 
 I'd like to generate such tarballs regularly (monthly like our ISOs?)
 and put them on our mirrors, unless there are objections.

Good idea. I had something like this in mind for some time; I did not
think of putting only pacstrap and deps into the tar though.

I wonder if you could use arch-chroot isntead of just chroot here. You
can also use the pacman.conf from the releng scripts. And to be safe you
should prefix pacstrap with a setarch call.

I'd say we include this script into the releng scripts (either archiso
or create a nwe package; atm I use some additional script for releasing
an ISO image) and upload such a tar at the same time as the ISO image.

Greetings,

Pierre

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

Re: [arch-dev-public] Bootstrap images for installing Arch from another system

[Pierre Schmitz]

Am 22.06.2013 20:49, schrieb Thomas Bächler:
 I wonder if you could use arch-chroot isntead of just chroot here.
 
 It requires bash 4 - if that's not installed on the host, arch-chroot
 will not work. I would rather provide instructions involving manual
 bind-mounting and chroot.

Fair enough. It should not be too hard to make it work with bash 3
though. But maybe this is a good time to think about our minimum
requirements. E.g. Debian 6 (oldstable) already has Bash 4 and it seems
our glibc requires at least Linux 2.6.32. (it seems Debian 5 had 2.6.26
so that wont work anyway)

 You
 can also use the pacman.conf from the releng scripts.
 
 I pretty much used the default pacman.conf from our packages (also
 enabled Color, but that didn't do anything). Is the releng one different?

Not really; this would just reduce duplication and makes sure these tars
and the iso iamges allways match.
 

 I'd say we include this script into the releng scripts (either archiso
 or create a nwe package; atm I use some additional script for releasing
 an ISO image) and upload such a tar at the same time as the ISO image.
 
 I was thinking about including this into arch-install-scripts, but I am
 unsure if it really fits in there.

Yes, seems difficult. As I said, I also have other scripts like creating
torrents etc. that are used for a realease. Maybe we can create a releng
repo/package for these. 

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

Re: [arch-dev-public] Syslinux 6.0 released with efi support

[Pierre Schmitz]

Am 21.06.2013 11:52, schrieb Tobias Powalowski:
 Hi,
 my plan for this release will be to replace the syslinux package with
 syslinux-bios
 and package the efi part as syslinux-efi package. This will be like the
 grub packages.

Cant we just use one package? Unless this is required by upstream (e.g.
conflicting file names) I would not split this. The grub packages are a
mess.

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

Re: [arch-dev-public] New draft - Was: /usr move - update instructions

[Pierre Schmitz]

Am 03.06.2013 09:41, schrieb Tom Gundersen:
 On Mon, Jun 3, 2013 at 5:05 AM, Allan McRae al...@archlinux.org wrote:
 And the news draft:
 
 Looks good to me. Time to make the move?

Fine with me. Maybe we could also explain more about the reasons or just
link to you mail here:
https://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html

Greetings,

Pierre

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

Re: [arch-dev-public] Finishing the /usr move

[Pierre Schmitz]

Am 31.05.2013 13:40, schrieb Allan McRae:
 Why not symlink /usr/local/sbin to /usr/local/bin in filesystems?

 
 Because there is absolutely no upgrade path for that.

Wouldn't this work?

$ pacman -Syu --ignore filesystem
$ mv -i /usr/local/sbin/* /usr/local/bin
$ pacman -Syu

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

Re: [arch-dev-public] [signoff] syslinux-4.06-2

[Pierre Schmitz]

Am 31.05.2013 11:40, schrieb Tobias Powalowski:
 Hi,
 please signoff syslinux-4.06-2 for the /usr/bin move.
 It will go direct to [core] repository, due to 5.01 sits in testing.
 Please download from here:
 https://dev.archlinux.org/~tpowa/syslinux/

signoff x86_64

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

Re: [arch-dev-public] Adding !staticlibs to our default makepkg.conf

[Pierre Schmitz]

Am 29.05.2013 03:31, schrieb Allan McRae:
 We discussed removing static libraries for most packages back in March [1].
 
 Now makepkg for pacman-4.1 has an option staticlibs that automatically
 removes them. Should I make that the default in our makepkg.conf?
 
 Allan
 
 
 [1]
 https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024552.html

Let me know when you commit this to pacman. I can then adjust devtools
as we use our own copy of makepkg.conf here.

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

Re: [arch-dev-public] [arch-commits] Commit in fail2ban/trunk (PKGBUILD)

[Pierre Schmitz]

Am 15.05.2013 13:02, schrieb Bartłomiej Piotrowski:
 Alea iacta est. While I agree that move could be planned better, it's
 not exim (nor any other MTA) fault that someone took bad decision to
 hardcode path to sendmail.
 
 SMTP forwarders aren't as crucial as bash is, therefore I don't see any
 reason to revert changes or delay moving binaries to /usr/bin. Just
 message maintainer that his package is broken due to recent changes.

I am pretty sure this breaks a lot of stuff (PHP, web apps, scripts
etc.). There is no reason to intentionally break things. It also doesn't
matter who's fault it is and if using absolute paths is a great idea or
not.

I would say if a package is known to or might be used by third party
apps or custom scripts, we should delay the move to the point where we
can introduce a /bin /usr/bin symlink etc.

Greetings,

Pierre

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

Re: [arch-dev-public] [signoff] linux-3.8.11-1

[Pierre Schmitz]

Am 02.05.2013 19:24, schrieb Tobias Powalowski:
 Hi guys,
 please signoff 3.8.11 series for both arches.
 package is not in testing, please grab it from here:
 http://dev.archlinux.org/~tpowa/linux/
 
 This will move to [core] directly, because 3.9.0 is in [testing].

signoff x86_64

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

Re: [arch-dev-public] Signoff policy for i686

[Pierre Schmitz]

Am 22.04.2013 12:31, schrieb Allan McRae:
 So I would propose:
 1) x86_64 signoff policy stays the same
 2) i686 only requires one signoff
 3) the one i686 signoff can be waived if there is a testsuite that passes

Thanks for bringing this up to make it finally an official policy. This
might need some changes to archweb though.

Greetings,

Pierre

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

Re: [arch-dev-public] Default DEBUG_CFLAGS/CXXFLAGS provided with pacman 4.1

[Pierre Schmitz]

Am 31.03.2013 16:08, schrieb Allan McRae:
 On 27/03/13 12:49, Allan McRae wrote:
 Note with gcc-4.8:

 DWARF4 is now the default when generating DWARF debug information. When
 -g is used on a platform that uses DWARF debugging information, GCC will
 now default to -gdwarf-4 -fno-debug-types-section.

 
 Any comments?  You have ~12 hours...
 
 I will use -g -fvar-tracking-assignments if no-one comments otherwise.

What are the consequences here for packages? Does this increase package
size by a large margin and will it slow down programs a lot? (Maybe
break it down for people who are not that familiar with gcc and its new
features; maybe you'll get more feedback then)

Greetings,

Pierre

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

Re: [arch-dev-public] rc.d init files package

[Pierre Schmitz]

Am 31.03.2013 16:09, schrieb Ionut Biru:
 Hello,
 
 We (the place where I work) have some customers that run arch as their
 primary os and I would like to create a package that contains rc.d init
 files that were dropped until now.
 
 I know this idea was discussed in the past and a lot of our users liked
 the idea but until now nobody stepped up.
 
 Let me know what you guys want me to support and i'll add it into my
 package.

At this point it is no longer enough to just keep the old rc scripts.
Initscripts need to be maintained and an increasing number of packages
need to be altered to support both init systems. It would be quite some
work and you probably cant put everything into one single package
without affecting other packages.

I'd say you'll need a strong technical reason to do this. ATM I cant
think of any problem that initscripts solved but systemd cant.

Greetings,

Pierre

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

Re: [arch-dev-public] [announcement draft] MariaDB replaces MySQL in repositories

[Pierre Schmitz]

Am 25.03.2013 10:56, schrieb Thomas Bächler:
 Am 24.03.2013 17:50, schrieb Bartłomiej Piotrowski:
 Migration example
 # systemctl stop mysqld
 # pacman -S mariadb libmariadbclient mariadb-clients
 # systemctl start mariadb
 # mysql_upgrade -p
 
 I will be affected here, so I'll better ask this time:
 
 Is it really that simple? If a PHP application uses mysql/mysqli, will
 it just work with mariadb? Any problems I may encounter?

I did a lot of tests regarding PHP and so far everything just works
fine; I switched archlinux.de to mariadb 17 days ago. Recent PHP version
don't even use the mysql client libraries, but their own implementation
mysqlnd.

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

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

[Pierre Schmitz]

Am 16.03.2013 11:09, schrieb Pierre Schmitz:
 Am 16.03.2013 10:05, schrieb Andreas Radke:
 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 just noticed that Virtualbox does not work with the latest
 xorg-server due to ABI mismatch. Is this known? It's possible that
 rebuildig the driver might fix this.

Why was this moved to extra regardless of the known issues it causes?

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

Re: [arch-dev-public] svntogit repo generation script moved to nymeria

[Pierre Schmitz]

Am 10.03.2013 17:04, schrieb Evangelos Foutras:
 This is just a quick note. In order to avoid having to sync the
 Subversion repos from nymeria to gerolde just to facilitate the
 generation of Git repos by the arch-svntogit script [1], I have
 relocated the script to nymeria.
 
 The Git repos [2] themselves had to be regenerated from scratch (from
 the Subsversion repos), and as such, any existing cloned repos won't be
 able to cleanly pull from them. In this case, it's recommended to delete
 and re-clone the repo.
 
 (tl;dr: If you have any clones of the svntogit repos, you'll need to
 recreate them.)
 
 [1] https://github.com/foutrelis/arch-svntogit
 [2] https://projects.archlinux.org/svntogit/

The packages repo seems to be corrupted:

% git clone git://projects.archlinux.org/svntogit/packages.git
Klone nach 'packages'...
remote: error: Could not read 4fee98a0562f9adbab2c1135fb57954a7b95f809
remote: fatal: bad tree object 4fee98a0562f9adbab2c1135fb57954a7b95f809
remote: aborting due to possible repository corruption on the remote
side.
fatal: zu frühes Dateiende
fatal: index-pack failed

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

Re: [arch-dev-public] [core] build report

[Pierre Schmitz]

Am 13.03.2013 13:22, schrieb Allan McRae:
 Hi,
 
 This build was done with a chroot containing only base-devel and sudo.
 Not many packages failed due to this, and can readily be fixed by adding
 makedepends.  So it seems the idea of reducing our build chroots down is
 good to go!

Would it be reasonable to add systemd to base-devel or should we rather
add systemd as a dep to a bunch of packages? I see packages calling
tmpfiles etc. on install so we'll have runtime deps and not just
makedepends.

Greetings,

Pierre

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

Re: [arch-dev-public] [core] build report

[Pierre Schmitz]

Am 17.03.2013 11:32, schrieb Pierre Schmitz:
 Am 13.03.2013 13:22, schrieb Allan McRae:
 Hi,

 This build was done with a chroot containing only base-devel and sudo.
 Not many packages failed due to this, and can readily be fixed by adding
 makedepends.  So it seems the idea of reducing our build chroots down is
 good to go!
 
 Would it be reasonable to add systemd to base-devel or should we rather
 add systemd as a dep to a bunch of packages? I see packages calling
 tmpfiles etc. on install so we'll have runtime deps and not just
 makedepends.

Here is a list of packages that need to have the systemd dep added (if
it not already has):

libvirt
ndisc6
murmur
wesnoth
lightdm
openntpd
picocom
percona-server
minidlna
proftpd
bitlbee
pgbouncer
subversion
postgresql
mysql
mpd
php
fetchmail
lighttpd
transmission
apache
samba
lirc
mariadb 

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