Saleem Abdulrasool | 28 Feb 19:22 2015

Crossing over to cross

Hello exherbo-dev,

I think that its about time that we consider crossing over to cross.  For most people, this is a one-time hassle of migrating the system layout.  The file system layout change is the piece that will enable supporting cross.  However, it brings us a much nicer multi-arch configuration, and a much nicer mechanism for supporting multiple ABIs (which multi build originally set out to solve).  See [1] for additional details on the layout and reasoning.

Once the layout changes are done, we can make further incremental improvements to cross to make it easier and nicer to use.  We have previously taken a similar approach with multibuild, and it worked out well, and I would like to do something similar here.

In preparation for this migration, I would like to gather the set of things that we must do before we actually engage in merging the necessary changes.  gcc:4.9 was fixed up on cross recently, and should be usable for at least the common case of a single host system.  One known limitation is the split debug (which I think can be addressed before the merge).  AFAICT, system should more or less work (though, due to the migration case, requires acrobatics with options to break circular dependencies).

The conversion is slightly painful, but certainly possible.  It involves acrobatics similar to bootstrapping exherbo on another linux distribution.  Starting from a stage would be the simpler approach.  We can still document both options and let the brave hearted try the more difficult option.


Saleem Abdulrasool
compnerd (at) compnerd (dot) org
Exherbo-dev mailing list
John Kallimanis | 20 Feb 15:11 2015

Re: Integrity checking


As often DOWNLOADS are defined in exlibs and are dependent on package 
versions, revisions and other variable information, wouldn 't it be most 
sufficient to keep,
i.e. a "checksums" somewhere within the repository, which would contain 
hashes that can be automatically or manually generated? Then, the 
fetcher would compare the downloaded distfiles against the checksums, 
and, for instance, retry the download from somewhere else, abort, etc.

IMO, it shouldn 't be up to individual packages to check for distifiles 

Best wishes,

John Kallimanis
Niels Ole Salscheider | 19 Feb 21:24 2015

Integrity checking


this topic has been discussed several times but Exherbo still lacks integrity 
checking for distfiles. The main reason why it has never been implemented is 
that it is said to break the development workflow.

We had some proposals to use git-annex for distfiles but there has not been 
any work on it. Also, one problem with git-annex is that it is written in 
Haskell which we do not want in the system set.
Yet, I think that integrity checking is important: it might not completely 
protect against e. g. the NSA but without it you become an easy target - for 
example, if you have to install something when only some untrusted and shared 
wireless connection is available. Integrity checking also helps to detect 
corrupt downloads or when upstream silently modifies a released tarball which 
can be annoying.

I would therefore like to discuss how a simple checksum based approach could 
look like and in which way it might break someone's workflow.

Such an approach could for example add a [[ checksum = SHA256 ]] annotation to 
each file in DOWNLOADS. We could have a tool that automatically fetches the 
files in the exheres and that adds / updates the checksum annotations. It 
would also present the computed checksums to the user so that he can compare 
them with published checksums from other sources. Maybe we could even run this 
tool as a git commit hook so that the process becomes mostly transparent...

We do not only have to check the downloaded files but also our repositories. 
Git helps here a bit since the SHA1 hashes change when history is rewritten.
Rewriting history is however something that occurs often during development. 
Therefore I suggest that we use forced pulls only from some configurable and 
trusted suffixes (so that "cave sync arbor --suffix local" continues to work 
when rewriting history during development). But we should make git complain if 
we pull from the official repositories and history is rewritten.
Of course, it is still possible to add malicious commits to the top but these 
are hopefully a bit easier to spot. Also, we can prevent most MITM attacks by 
using https for our repositories.

What do you think?

Exherbo-dev mailing list
Somasis | 10 Jan 20:45 2015

summer: bootstrap theming

Hi everyone. The changes to www and docs have been merged and are now live at and as such I started work on Summer's theme last night.

Right now the changes are live on so if anyone would like to comment on what looks good and what doesn't, now's the time.

Exherbo-dev mailing list
Somasis | 9 Jan 14:14 2015

Re: www+docs: bootstrap revamp

Any more feedback? I've changed the font choice and made a few other aspects such as <code> tags fit the theme. Changes are up on

Also just a heads up, Maruku seems to struggle a little bit with rendering some markup on the Multibuild for developers page. easy-multibuild.exlib's anchor link is broken and leaves an empty reference. I confirmed that this is an issue with newer Ruby or Maruku versions with Bo and unrelated to my changes. (Tchaikovsky uses older versions of both than what's in repos)

Exherbo-dev mailing list
Somasis | 4 Jan 19:20 2015

www+docs: bootstrap revamp

Hey list, I've been working on an update to the site that includes modifying it to be based on Bootstrap. This would help it be more readable, cleaner looking, and hopefully a lot more usable than the current design.

Since this is a fairly large change though, I'd like to have some feedback on what is thought of it. I'm not a core developer of course, so I don't have permission to push it directly; a Gerrit change is open at and

If this is accepted, I'll be working on making Summer conform to the design as well. I don't want to get started on it until everything else is accepted since it's a bit more work.

There's also a temporary live copy of my changes running here:

Thoughts? Feedback?
Exherbo-dev mailing list
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