Christian Kluge | 14 Mar 19:05 2015
Picon

exheres-syntax in the stages?

I see no harm in adding exheres-syntax to the stages set.

But if we include it I think we should include exheres-mode for the emacs users too.
_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
Saleem Abdulrasool | 14 Mar 18:51 2015

exheres-syntax in the stages?

Hello exherbo-dev,

I'd like to request that we include exheres-syntax in the stage image by default.  This package is merely a few text files for syntax highlighting in exheres.  The impact should be minimal, but make working on intrusive changes easier for those of us who use vim.

Thanks.

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
Wulf C. Krueger | 9 Mar 22:40 2015

Getting rid of the bin/sbin split


It's historical nonsense and we should get rid of it:

bin & sbin in Exherbo are in a totally inconsistent messy state.

We've no criteria to put things in either directory. We all do it
differently.

We shouldn't keep pointless crap that's inconsistent.

Making sbin a symlink doesn't really cost us anything but makes
things finally consistent.

Unsplitting it also gains cross-distro compatibility. With the
merge+symlink, it doesn't matter where a script thinks the tool should be.

The split doesn't make any sense at all anymore.

The split is ugly aestetics and those must be eradicated.

For some background:

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

And we should do it *now* while we're breaking everything with cross
anyway in order to avoid breaking things twice.

--

-- 
Best regards, Wulf "who's never going to rely on IRC decisions
anymore" Krueger
Wulf C. Krueger | 7 Mar 15:30 2015

Preparing Cross


Hello,

we've decided to merge the cross branches to their respective master
no later than the end of this month.

In order to make this happen, some tasks have to be accomplished yet
and YOU can help!

There are basically two ways of helping:

Work on the tasks that block bug 386:
https://bugs.exherbo.org/show_bug.cgi?id=386

Test (and fix) packages on cross. We should try to get as many
package ready for cross BEFORE the merge as possible.
Thus, you're free to create new cross branches in ANY of our official
repositories and to fix whatever has to be fixed.

If you don't know how to migrate (a chroot) to cross, read this:

http://www.exherbo.org/docs/multiarch.html

If you haven't even heard of cross yet (been living under a rock, eh?
;) ), read this:

http://www.exherbo.org/docs/multiarch.txt

For help with fixing exheres/exlibs, read this:

http://www.exherbo.org/docs/cross.html

And, of course, we're usually available in #exherbo.

So, go and fix stuff! Or, as one of us put it: "the bazaar is open"

--

-- 
Best regards, Wulf
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.

[1] http://exherbo.org/docs/multiarch.txt

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
John Kallimanis | 20 Feb 15:11 2015
Picon

Re: Integrity checking

Hi,

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

Best wishes,

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

Integrity checking

Hi,

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?

Ole
_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
Somasis | 10 Jan 20:45 2015
Picon

summer: bootstrap theming

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

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

_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
Somasis | 9 Jan 14:14 2015
Picon

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 http://somasis.com:8000

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
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
Somasis | 4 Jan 19:20 2015
Picon

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 https://galileo.mailstation.de/gerrit/#/c/2486/ and https://galileo.mailstation.de/gerrit/#/c/2487/

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: http://somasis.com:8000

Thoughts? Feedback?
_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
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

Cheers
Benedikt

Gmane