Bernhard Frauendienst | 13 Jun 14:13 2015
Picon

Add debian to REMOTE_IDS

Hi everybody,

I propose to add debian to the list of remote databases (REMOTE_IDS).

This could be useful for clients that use the debian-maintained
information to do further processing. The project I'm having in mind
here is exherbo-pkg[1], which uses the debian watch file to find new
package versions.
While this is already possible for many packages which have the same
name on exherbo and debian, there are a number of packages which
currently don't satisfy this requirement. Adding a debian REMOTE_ID for
those packages would allow the tool to work with them as well.

If this proposal is accepted, debian.exlib should probably patched to
provide the remote id automatically.

What do you think?

Best Regards
Bernhard

[1] https://galileo.mailstation.de/pkg/exherbo-pkg.xml
Wulf C. Krueger | 7 Jun 17:04 2015

Install systemd units unconditionally


Hello,

I'd like to suggest installing systemd units unconditionally. At the
moment, the "systemd" option is mostly used to install them.

Sometimes, though, e. g. in PHP, it means something completely
different. In other cases, it's used to break cyclic dependencies and
in yet other cases, it's actually used to disable systemd integration.

It's a mess.

If we just install systemd units unconditionally...

we can use the "systemd" option to just mean "systemd integration"
(and a handful of cyclic dep breakers),

we don't hurt anyone - they're tiny text files,

we reduce confusion (e. g. PHP usually should have the systemd
option *disabled*),

we get rid of an option that's purely for runtime configuration,

we reduce the options clutter,

Plus: The systemd option defaults to on anyway so unless someone
globally sets "-systemd" (fool!) the units are installed anyway.

Please do respond even if it's just +1. Knowing you lazy bastards ;-),
(Continue reading)

Benedikt Morbach | 21 May 02:11 2015

dosbin, newsbin and heresbin are banned

As we merged sbin and bin with multiarch, 'dosbin', 'newsbin' and
'heresbin' are now banned in exheres-0. The fix is to replace them
with their 'bin' equivalents.

Please note that if you do find an exheres that still uses them then
it hasn't been adjusted to multiarch yet and might need some further
changes.

Cheers
Benedikt
Ciaran McCreesh | 4 Apr 13:54 2015

Paludis 2.4.0 Released

Paludis 2.4.0 has been released:

2.4.0:
    * Bug fixes.

    * We now use Ruby 2.2, unless --with-ruby-version is specified.

--

-- 
Ciaran McCreesh
_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
Saleem Abdulrasool | 6 Apr 02:25 2015

cross/multiarch is live!

Hello exherbo-dev,

We have merged the cross branch on arbor into master.  This means that cross is now live!  Owners of other repositories are encouraged to do the same.

Much like the case with multibuild/multilib, this does not mean that cross is complete.  It does however mean that everyone can more easily take advantage of this progress.

Not all packages have been adapted to cross/multiarch.  However, many people have been using the branches and a large number of packages either just worked or have been adjusted slightly to work with the requirements for cross.

We have taken steps to ensure that the changes are as transparent as possible, though, some of the biggest changes involve the toolchain packages which now require the target triple prefixing on the tools.  Other than that, it does require that you perform a migration.  We have instructions for that at http://exherbo.org/docs/multiarch.html.  Please follow the guide closely as otherwise you may render your system in an inoperable state.

We have some documentation to help with familiarising yourself with packaging with cross at http://exherbo.org/docs/cross.html.  As usual, if you find issues please try to fix them if you can, otherwise ask around on #exherbo or #exherbo-multiarch.

Finally, thank you to everyone who has helped make cross/multiarch a reality.  This would have been impossible without their help, and there are too many to list individually.  This is certainly a large change and opens a number of possibilities in the future.  

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
Wulf C. Krueger | 6 Apr 02:05 2015

The Great Merge II: Exherbo's multi-arch/cross implementation has been merged to master


Exherbo's multi-arch/cross implementation[1] has been merged to master.

You WILL have to migrate to this new setup in order to be able to
install new software and updates.

You'll find the migration guide at [2]. Make sure to follow it VERY
closely because getting things wrong does have the potential to break
your system. (You'll of course be able to access your data via a rescue
system if everything goes wrong. We're changing the base system but are
NOT touching user data.)

If you don't want to migrate right now, you shouldn't update or install
ANYTHING anymore until you are ready to do so.

The last commit prior to the migration has been tagged as "pre-cross" in
all official repositories so that you can stick with that if need be.
If you wish to stay on the pre-cross revision, you need to set
"sync_options = --revision=pre-cross" in the repository's configuration
file.

If you do migrate (which you should), you'll find that some packages
might not yet install. As always, you're fully expected to help with
migrating exheres to the new base system which basically involves
undoing our former multi-lib approach. You'll find more details at [3]
and you're, of course, encouraged to look at recent commits that mention
"multiarch" or "cross" for tips on converting other packages.

Furthermore, we have no control over 3rd-party/unofficial repositories.
While quite a few of them feature a "cross" branch right now, they might
not have been merged when the official repositories were.
Thus, you might have to add "sync_options = --branch=cross" (without the
quotation marks) to the respective repository's configuration until the
maintainer has merged the cross branch into master.

[1]: http://exherbo.org/docs/multiarch.txt
[2]: http://exherbo.org/docs/multiarch.html
[3]: http://exherbo.org/docs/cross.html

Best regards, Wulf

Wulf C. Krueger | 5 Apr 11:44 2015

Cross/multi-arch: Preparations for the merge


Hello,

this is the plan for today:

I'm currently doing one last migration of a VM to check the validity
of our migration guide.

If all is well, I'm going to tag all official repositories' last
"master" commit with "pre-cross".
Do me a favour and DO NOT commit to "master" anymore today before the
merge is done.

Once the tagging is done, we start merging all cross branches to master.

Did I miss anything?

--

-- 
Best regards, Wulf
Wulf C. Krueger | 4 Apr 11:50 2015

Cross/multi-arch: Get going! Merge date: TOMORROW, Sunday, April 5th 2015


Hello,

I'd like to remind everyone that we are going to merge all the cross
branches to their respective master branches

          TOMORROW, Sunday, April 5th 2015!

Whatever you're doing Exherbo-wise, please DROP IT for the moment and
help us get more packages ready!

Migrating exheres to the new base system isn't (most of the time)
complicated: It basically involves undoing our former multi-lib
approach. You'll find more details at [1] and you're, of course,
encouraged to look at recent commits that mention "multiarch" or
"cross" for tips on converting other packages.

You may, of course, test cross-compilation to something but what's
REALLY important is that the package works on a NATIVE system, e. g.
boost does work natively but fails at cross-compilation currently. For
now, that's ok.

If you want to convert packages in a third-party repository that
doesn't have a cross branch yet, please get in touch with me - I can
create cross branches for EVERY repository in Gerrit.

To get started:

Fetch a current stage
Migrate it to cross/multi-arch (cf. [2])
Start converting!

So, go for it!

(And always remember: My statistics will record your fabulous work for
generations to come who will sing the praise of the immortal heroes
who made cross work! ;-) )

(Questions? -> #exherbo or this list)

[1]: http://exherbo.org/docs/cross.html
[2]: http://exherbo.org/docs/multiarch.html

--

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

Gmane