Benedikt Morbach | 15 Dec 22:32 2014

github.exlib changes

Hi everyone,

I just pushed some changes to how github.exlib works.

The most important change is that the 'rev' exparam now only takes git
commit ids.
If you want to fetch a tag, use the 'tag' exparam.

I've fixed every official repo that I use and submitted gerrit changes
for the unofficial ones.

It will throw an error for everything that mixes those up, so please
fix any exheres that you maintain/come across, if I missed them

Ciaran McCreesh | 1 Oct 20:06 2014

Paludis 2.2.0 released

Paludis 2.2.0 has been released:

* Bug fixes.

* Compilation fixes for Clang.

* Added ‘cave resolve –chroot-path’.

* Removed the “breaks Portage” feature.


Ciaran McCreesh
Exherbo-dev mailing list
Jorge Aparicio | 25 Jun 18:35 2014

New ARM stage

Hello guys,

Just dropping by to let you know that I've uploaded a new (unofficial) exherbo
stage for ARM [1]. If you'll like to give it a try, check the README [2] for
install instructions and more details.


[1] (the 20140624 one)
Vasiliy Tolstov | 5 May 07:10 2014

paludis and its config files

Why paludis by default does not install to /etc/ default config files
for exherbo?
I'm understand that if i install exherbo i known about configuration,
but as i known - all software by default ships it config files to etc
or share/examples...
May be i miss something?


Vasiliy Tolstov,
e-mail: v.tolstov@...
jabber: vase@...
Wulf C. Krueger | 3 May 12:54 2014

Adding Emacs to the stages set


we've had vim in the stages for a long time. For those of us and our
users who don't use vim but Emacs, this has been a nuisance.

Thus, I'd like to add Emacs to the stages set so that both editors
will be available to everyone from the start. Having both of the major
editors will ensure that whoever comes to Exherbo will have his
favourite editor around to use and feel right at home.

Adding Emacs adds about 30 MB to the stages but I don't think this is
a major issue these days.

In private discussions, the proposal to remove vim, not add Emacs and
instead add nano to the stages came up. I don't think this would be
very useful since it would alienate basically everyone.


Best regards, Wulf
Vasiliy Tolstov | 3 May 08:31 2014

failed to build sydbox

Hi. I have errors then building sydbox undex lxc (kernel headers 3.12.18)

Can you helps me?

Vasiliy Tolstov,
e-mail: v.tolstov@...
jabber: vase@...
Wulf C. Krueger | 29 Apr 18:22 2014

Fwd: Re: request for pbin is on by default in paludis stages

This was of course meant to be a list reply:

-------- Original Message --------
Subject: Re: [Exherbo-dev] request for pbin is on by default in paludis
Date: Tue, 29 Apr 2014 17:53:05 +0200
From: Wulf C. Krueger <wk@...>
To: Vasiliy Tolstov <v.tolstov@...>

gpg control packet
Hello Vasiliy,

On 28.04.2014 22:24, Vasiliy Tolstov wrote:
> May be the best option build paludis with pbin enabled in stages. 
> That pulls libarchive, acl for deps, but its size not very big.

I agree with this suggestion. pbins are really usable these days and
the dependencies are marginal so I think we should do this.

Unless someone objects, I'm going to profile-enable the pbin option
for Paludis during the coming weekend.


Best regards, Wulf

Vasiliy Tolstov | 28 Apr 22:24 2014

request for pbin is on by default in paludis stages

Hello. I have exherbo on some linux servers, my work and laptop computers.
I'm very happy with it. I'm building pbins for speedup upgrading, also
i'm create diskless network images for boot my servers (kvm compute
Now i need to always rebuild paludis from sources to get pbins worked for me.
May be the best option build paludis with pbin enabled in stages. That
pulls libarchive, acl for deps, but its size not very big. But after
this option is on nobody need recompile paludis after downloading
I think that is very useful feature.

What do yo think about this option?


Vasiliy Tolstov,
e-mail: v.tolstov@...
jabber: vase@...
Wulf C. Krueger | 14 Apr 14:06 2014

Re: CAcert, ca-certificates from Debian


On 25.03.2014 21:47, Denis Knauf wrote:
> About the CAcert-problem and Debian. I trust and use CAcert, Debian
> not. Debian removed it, we use their ca-list in our
> ca-certificates-package:
> DOWNLOADS="mirror://debian/pool/main/c/${PN}/${PN}_${PV}_all.deb"
> No other sources. So we have to add CAcert manually.

I've done this now (65ff7cf in arbor;

ca-certificates-20140223-r1: Optionally re-add CAcert (default-enabled)

Debian, the package of which we're using, decided to remove CAcert's
certificates due to CAcert's failure to undergo security audits.

This decision was controversial and, thus, I feel it's appropriate to
give people a choice here and add an option to install CAcert's
certificates. Since CAcert has been included for years, the option is
enabled in the base profile (in a separate commit).


Best regards, Wulf
(Continue reading)

Wulf C. Krueger | 26 Feb 18:54 2014

Re: Providers (and virtuals)

On 26.02.2014 18:35, Bo Ørsted Andresen wrote:
> On Wed, Feb 26, 2014 at 05:29:53PM +0100, Wulf C. Krueger wrote:
>>> Here is another take on that || ( ) thingy.
>> Seeing this being used now, I think we should provide sane
>> defaults for those providers.
> [...]
>> Thoughts?
> Sounds good to me.

(Fully quoting Bø who accidentally only replied to me personally. :-) )

I just pushed this:

# Wulf C. Krueger <philantrop <at>>
# Provide sane defaults for the virtual providers
virtual/blas                    PROVIDERS: OpenBLAS
virtual/cron                    PROVIDERS: cronie
virtual/dhcp-client             PROVIDERS: dhcpcd
virtual/javadoc                 PROVIDERS: icedtea7
virtual/kerberos                PROVIDERS: heimdal
virtual/libaacs                 PROVIDERS: libaacs
virtual/mta                     PROVIDERS: sendmail
virtual/mysql                   PROVIDERS: mysql
virtual/notification-daemon     PROVIDERS: notification-daemon
virtual/pkg-config              PROVIDERS: pkg-config
virtual/syslog                  PROVIDERS: rsyslog
virtual/zathura-pdf             PROVIDERS: zathura-pdf-poppler
(Continue reading)

Quentin Glidic | 18 Feb 22:44 2014

Providers (and virtuals)

Hello Exherbo,

Here is another take on that || ( ) thingy.

You will find attached [any-deps.log] the list of currents (non-virtual) 
|| ( ) dependencies.
It is a light version, I removed from the full list the few cases which 
will disappear in a near future.
All remaining uses (except gcc[ada]) can be solved with the following 
proposal. (We should probably drop the ada option from GCC for know, as 
gnat is ::unwritten so that we cannot install gcc[ada] currently anyway.)

Now let me introduce you “providers”.

Providers is a suboption to select the provider of a feature. Its usage 
is *not* limited to virtuals, they are a special case of package using 
The attached e-f-s patch should explain the design well enough.

All packages using || ( ) dependencies to let the user choose should use 

I think we should go in two (or three) steps:
1. Migrate virtuals (cf. attached scripts)
2. Migrate the rest of the || ( ) list
(3. Migrate (“back”) ffmpeg/libav packages, maybe do that with 2.)

Here is the rationale for some design choices:
— Using a suboption avoids name collisions between normal options and 
providers (ffmpeg vs. providers:ffmpeg)
(Continue reading)