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.
cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434

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> exherbo.org>
# 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)

Heiko Becker | 8 Feb 21:45 2014

Changes in qmake.exlib


our qmake4.exlib wasn't well suited to handle building packages
against Qt4 or 5 if the used version depended on an option.

Therefore I've committed some changes addressing this issue after some
discussion in #exherbo-kde. Because it can handle both versions now
I've renamed it to qmake.exlib. If you want to handle both you can
pass '4' or '5' to eqmake in your src_configure(). Look at
app-text/texmaker in ::desktop for an example. Otherwise you only need
"require qmake" or "require qmake [ slot=5 ]" respectively. Further
changes are:

* eqmake4                     -> eqmake
* Dependency handling in the exlib was dropped because everything
using it added appropriate deps anyway

If I didn't miss anything all packages in our repos should be already
fixed (or there should be at least patches awaiting approval on
gerrit). Feel free to fix remaining issues if that's not the case.


Best regards,
Heiko Becker
Michael Forney | 6 Feb 05:49 2014

Multiarch discussion


While multiarch is getting closer, I think there are still a couple of
things that need discussion.

- PT_INTERP path of multiarch executables

Currently, we patch gcc in order to use a special path for the PT_INTERP
field of the resulting executables. This has the benefit of ensuring
that none of the dynamic loaders clash (as they are in architecture
specific lib directories).

However, it also has the downside of breaking binary compatibility with
other distributions (executables built on an Exherbo multiarch system
will not run on any other non-Exherbo system). I'm strongly of the
opinion that PT_INTERP should be left as /lib/ld-whatever.so for the
following reasons:

    1. The ld.so names on the architectures most people care about do
       not conflict. From the gcc sources, I've come up with this list:

       aarch64             /lib/ld-linux-aarch64.so.1

       ia64                /lib/ld-linux-ia64.so.2

       arm-hardfloat       /lib/ld-linux-armhf.so.3

       arm-softfloat       /lib/ld-linux.so.3

       x32                 /libx32/ld-linux-x32.so.2
(Continue reading)

Bernd Steinhauser | 5 Jan 13:24 2014

Some X-related options

I was thinking about the optional support for xinerama we have in some exheres. 
Now for a short explanation:
xinerama [1] is an extension to the X server, which allows spanning a desktop 
across multiple monitors (with some downsides). Originally, this was used to do 
exactly that. These days, it has been deprecated by randr and it's purpose is to 
provide applications with information about the physical screen dimensions. This 
is only necessary for few applications, likewindow managers, media playersor 
toolkits. Therefore, the xinerama option is a bit misleading, is it is more 
about multimonitor support in *clients* rather than the server (which xrandr is 
In a world, where multiple monitor support should be mandatory (think about 
laptops, beamers etc.), this ability should be always available.In addition, 
libXinerama is rather small (takes less than a minute to compile and less than 
200K disc space), so I suggest to couple it to the other X libs(which means that 
it'll be optional if "X" is optional).

So while we are at it, I was looking at some other options, which fall in the 
same category:
xrandr: app-emulation/vice and x11-wm/pekwm; Running X these without xrandr in 
my opinion is just stupid. So unless there is a really good reason for this 
option, it'll go as well.
xv: mostly media players; xv is the standard video output, doesn't take much 
space and afaik, it is used as a fallback if accelerated outputs don't work; so 
basically just about everybody wants this
composite (libXcomposite): this one is more questionable, since not everybody 
will use the composite extension (used for composite window managers), but it is 
small (<160K here) and compiles fast (less than 30s for 32bit+64bit over here)

All of these will of course be handled the same as xinerama. If you think that 
an option should definitely stay, speak up now. ;)
(Continue reading)

Quentin Glidic | 3 Jan 23:45 2014


Hello there,

I was reading cave output (sometimes it does have the same hypnotic 
effect as a Windows 98 defragmentation had) when realising that some 
packages install a lot of translations I do not care about.

I was about to add linguas: options to a bunch of package, but I lack 
the list of languages that our users are actually using.

I would start with this list: en (US and GB), fr, de, ja. Is there any 
big language I forgot?




Quentin “Sardem FF7” Glidic

Exherbo-dev mailing list
Exherbo-dev <at> lists.exherbo.org
Quentin Glidic | 30 Dec 22:55 2013

[RFC] || ( ) dependencies and virtuals

Hello there,

In the last days, I have been fighting against || ( ) dependencies.
Here are the most common use cases:
— virtuals
— autotools.exlib (and similar slotted tools like vala.exlib)
— ffmpeg vs. libav
— vim vs. gvim
— cdrtools and friends
— ruby vs. rake/rubygems
— text-based browsers
There are a few other cases but I am not familiar enough with these so I 
will focus on the list above before “fixing” corner cases.

 From bottom to top:
The last cases (from vim to text-based browsers) can be solved with 
virtuals quite easily. I will just wait for the virtuals case to be 
decided to update them.

The ffmpeg vs. libav case is a bit more tricky. I will need the answer 
to one question to decide here: can you *always* runtime-switch between 
libav and ffmpeg? IOW, are some packages using build-time #ifs to use them?
If we *can* runtime-switch, a virtual is good here too.
If we *cannot*, here are two and a half solutions:
1. a slot-based virtual. With a := slot dependency, that would force 
people to rebuild packages if they change from libav to ffmpeg
2. use [ffmpeg] and [libav] on each package, two variants here:
a. make them mutually exclusive (but this is not 
DEFAULT_SRC_CONFIGURE_*-friendly, unless we add something to handle that 
choose-between -two-implementations case, which is quite common)
(Continue reading)

Wulf C. Krueger | 11 Dec 17:54 2013

Dropping the ipv6 option globally


It's the time of year again during which we traditionally discuss the
removal of the "ipv6" option. (I've checked my IRC logs since 2008 and
we always discussed this during autumn for some reason! :-) )

Recently, we got a patch
(https://galileo.mailstation.de/gerrit/#/c/298/) to disable the ipv6
option for NSPR.

I'm *not* in favour of that specific patch because it would mean we
would basically arbitrarily remove the ipv6 option from random
packages, not knowing what might break. Instead, I'd like us to just
drop the ipv6 option *completely*.

Personally, I've been running every single machine for the last 5
years or so with IPv6 enabled globally - nothing ever broke. And that
was independent of the actual existence of IPv6 connectivity (which I
didn't always have).

As for the argument that things might break if someone doesn't compile
IPv6 support into his kernel - things are likely to break if you don't
compile-in support for your CPU either. Just don't do that then.

We should, of course, add some instructions about that to our
documentation but that's something I'll gladly do.


(Continue reading)

Vasiliy Tolstov | 19 Nov 06:32 2013

Re: project live?

2013/11/18 Ridai Govinda Pombo <ridai.govinda@...>:
> I think the best way for you to see some roadmap is getting into the
> #exherbo channel on freenode, talk to the main developer, and contribute
> some patches...
> Best regards,
> Ridai



Vasiliy Tolstov,
e-mail: v.tolstov@...
jabber: vase@...
Vasiliy Tolstov | 18 Nov 04:35 2013

project live?

Hi all.
Where i can find plans or feature roadmap for exherbo?
I want ot use it in some cloud service and try to choose between
debian/ubuntu and exherbo.
Debian/Ubuntu have community and binary packages, but in case of ci
build on build server i can take Exherbo with paludis packages manager
and not have pain  then i need to create new version of package.
But finally i need to known - does project maintained and not dead.


Vasiliy Tolstov,
e-mail: v.tolstov@...
jabber: vase@...