Bo Ørsted Andresen | 20 May 23:32 2016

Unprefixed toolchain executables

Hi

A couple of months ago we had a discussion about readding unprefixed
toolchain executables to the user PATH, but banning their usage in the
exheres-0 environment. The Paludis support for this was finally merged
yesterday. And the documentation and the toolchain package changes has
just now been merged.

This requires everybody to reinstall paludis before upgrading the
toolchain packages.

If you've been testing this previously, you should verify
that /etc/env.d/banned_by_package_manager/ does not exist, or follow
the procedure in the news item to get rid of it, if it exists.

For exheres-0 authors see BANNEDDIR in
http://www.exherbo.org/docs/eapi/exheres-for-smarties.html#environment_variables
and dobanned in the utils section.

Once done kernels and other stuff should no longer require arguments
like HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu-
etc. for building correctly.

--
Bo Ørsted Andresen

_______________________________________________
Exherbo-dev mailing list
Exherbo-dev <at> lists.exherbo.org
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
(Continue reading)

Marc-Antoine Perennou | 13 May 12:41 2016

glibc: add compatibility symlink for x86_64 ELF loader

Hi,

For now, when we want to run x86_64 binaries that have not been
compiled on exherbo, we either need to call the loader by hand or we
need to use patchelf.
It's a real pain for several usecases such as bootstrapping a compiler
(ghc, rust, icedtea...) or running third-party binaries (like the
coverity compiler for example).

If you care a little about that, please go and review
https://galileo.mailstation.de/gerrit/#/c/6008/
If nobody goes against it, I'll merge it next week.

The jenkins failure is because jenkins has a /lib64 symlink which is
another approach to this workaround, which would no longer be
necessary with this patch applied.
Note that /lib64 being blacklisted by exheres-0, other packages still
wouldn't be able to install to this location.

Cheers,
Marc-Antoine
Niels Ole Salscheider | 16 Apr 12:39 2016
Picon

Set CMake build type as build_option

Hello,

currently, we set the CMAKE_BUILD_TYPE to "None". The reason for this is that 
CMake has CMAKE_C{,XX}_FLAGS variables where the corresponding build flags can 
be passed. When the build type is "None", only these flags are used. If the 
build type is however set to anything else, then the flags from CMAKE_C{,XX}
_FLAGS_$TYPE will be appended to the former.

This seems to make sense because the additional variables contain flags that we 
don't want. CMAKE_CXX_FLAGS_RELEASE, for example, defaults to "-O3 -DNDEBUG" 
and we don't want the -O3 flag.
But the "None" type is not really supported and some projects (e. g. LLVM) 
even forbid it. Apart from that projects might add additional flags to these 
variables. They could for example add defines that enable some debug code only 
in debug builds.

It would therefore make sense to set the build type to the right value so that 
these flags can be included. In that case we would also have to set the default 
values of all CMAKE_C{,XX}_FLAGS_$TYPE variables to sensible values that do 
not include any -O flags. CMAKE_CXX_FLAGS_RELEASE would for example only 
contain "-DNDEBUG".

Bernd Steinhauser proposed that we should set the CMake build type based on a 
build_option. What do you think?

Ole
_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
(Continue reading)

Wulf C. Krueger | 16 Apr 11:20 2016
Gravatar

No more reminders from me about proposed changes in Gerrit

Hello,

for a long time, I've tried reminding people about proposed changes in
Gerrit on IRC, via email and directly in Gerrit.

I did it because I hoped people would take another look at them, review
them, improve them and maybe eventually merge them.

The results often were not very useful, though, and the effort/benefit
ratio has simply not been good enough anymore for me for a few months now.

Thus, I'm stopping this practice now. I'll just stick to reviewing
things as always and will be ignoring all that old stuff.

--

-- 
Best regards, Wulf

_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
Kylie McClain | 11 Apr 18:32 2016
Picon
Gravatar

GUI option standards

Hi everyone,

I was working on making some changes to sys-devel/cmake, and I got to
thinking about the inconsistency we seem to have when it comes to
representing options for GUIs. We have some packages which have just
[providers:{gtk2,gtk3,qt4,qt5}], packages which have `X? ( (
providers: ... ) )`, packages with just [qt4], [gtk3], and so on, andd
the lack of consistency is kinda stupid.

It is my opinion that we should unify these using a new option: [gui],
and then provide the setting of the toolkit of choice (if there is an
option) via providers: suboptions.

This would replace the [X] option's usage as a way to decide if
graphical interfaces should be built into programs, and would prepare
us for whenever The Year of the Wayland desktop is here again.

(the cmake change is at https://galileo.mailstation.de/gerrit/#/c/5742/ )

Thoughts?
Kylie McClain | 1 Apr 22:49 2016
Picon
Gravatar

System set proposal

Hi everyone,

I'd like to propose that we add app-misc/zebrapig::bikeshed to the system set.
zebrapig is an integral part of the system, and if I'm not mistaken,
systemd actually
requires it for booting. Adding this will hopefully allow for us to
cut down on the
size of an Exherbo system, since it should be able to replace more common and
larger programs, such as app-shells/bash and sys-devel/gcc; zebrapig is to be
considered more desirable to bash and gcc, because it provides only what the
user will really use.

Discuss.
Calvin Walton | 30 Mar 18:06 2016
Picon
Gravatar

RFC: Switch default "jpeg" provider to jpeg-turbo

Hi all,

After zlin reported on IRC about a test failure when using "ijg-jpeg"
implementation that don't happen for people using "jpeg-turbo", I was
wondering why our default jpeg provider is still the ijg library.

Many other distributions have switched to using jpeg-turbo (at least by
default), including Debian, Ubuntu, Fedora, RHEL, SUSE. As a result, a
lot of current software isn't well tested with that library.

As a bonus, jpeg-turbo has committed to maintaining abi stability - no
more rebuilding lots of packages with a new major jpeg library release.

And so I propose to change the default provider used in Exherbo to
jpeg-turbo. Does anyone have any objections to that?

There's still a couple packages that depend on media-libs/jpeg directly
that should be taken care of, but since jpeg-turbo is compatible with
the common jpeg-6b api, this usually just requires a dependency change
(no patches).

Obviously this would only change the default, and if someone wants to
use one of the non-standard jpeg encodings supported by ijg's jpeg-8 or
jpeg-9, they're welcome to switch it.

--

-- 
Calvin Walton <calvin.walton@...>
Kylie McClain | 23 Mar 22:54 2016
Picon
Gravatar

Virtual announcement - wget

For the past two weeks or so, I've been experimenting with using
Busybox's wget applet as a replacement for GNU wget, with pretty good
success. It supports all the arguments which Paludis uses for wget,
and in addition, when an `openssl` binary is installed, it will use it
for supporting SSL; this is good for a few reasons, namely it'd be
another step in having Busybox act as a nice fallback for whenever
OpenSSL people manage to break the ABI compatibility without warning
again, or if the system just gets broken in some other way.

In order to do this, I have some changes on Gerrit[1] which take care
of the alternatives, the busybox changes, etc., replace net-misc/wget
in system.conf with virtual/wget, and enable [providers:gnu] for
virtual/wget by default. GNU wget's real binary would now be
`gnuwget`. Since there wasn't really a standard for this sort of
thing, I just decided to use `gnuwget` as the name.

Also, this'll serve as a test for the new virtual announcement process
which Wulf proposed; as such, I'll wait until Friday to merge these
changes.

Have a nice day, everyone
Wouter van Kesteren | 18 Mar 14:44 2016
Picon

Re: [RFC] Unprefixed executables.

On Fri, Mar 18, 2016 at 11:58 AM, Ridai Govinda Pombo
<ridai.govinda@...> wrote:
> Another? What do you mean? We won't be using paludis in some near future??

No, not near future, I just meant it as a general thing that might
happen in the far future.
Or might not ever happen and we will just all switch to ubuntu! It's
all just guesswork.
The point i was trying to make is just that we should try to avoid
needlessly coupling exheres tightly with paludis.
Wouter van Kesteren | 17 Mar 20:29 2016
Picon

[RFC] Unprefixed executables.

Hi list,

It's well known that people want unprefixed executables (gcc, ld,
pkg-config and friends) so that we for example don't break people
their `./configure && make` and avoid having to resort to weird
BUILDCC arguments to build the linux kernel. However we don't want
these to be usable from inside of exheres because we value correctness
over easiness there.

We talked on and off about this on irc for a while now and we believe
we have found a general and extendable solution that makes everyone
happy.

First a bit of backstory: We realised that there needs to be a list of
executables we need to ban somewhere. We gave thought to two locations
where we can put this list.

1. We can put this list in paludis, which has a massive downside of
needing to change and release a new paludis every time we want to ban
an additional tool.
2. We can put this list in some configuration file like the profiles,
which means we end up with a big list there of all imaginable
unprefixed things we want to ban in there instead.

Then moben suggested the novel idea: lets have the packages themselves
decide what they want to ban. The talking that followed after that led
to this proposal.

We want to designate a special directory (for the sake of this
document lets say $libexec/paludis/exheres-0/banned/ for now, to be
(Continue reading)

Wulf C. Krueger | 17 Mar 17:42 2016
Gravatar

RFC: Requiring an ML announcement before adding new virtuals and non-light alternatives

Hello,

during the last few months, we've seen an influx of new virtuals and
non-light alternatives.

At least I'm not happy with each and every one of those - not to speak
of technical complications we've seen.

Nevertheless, the intention of this RFC is *NOT* to remove existing
virtuals or alternatives. That's an entirely different topic.

Thus, my suggestion is as follows:

- We require an *announcement* on this list prior to introducing new
virtuals and non-light alternatives.

- The announcement should be sent at least 48 hours before pushing them.

- There's *no* approval involved. It just gives everyone a time frame
during which they can discuss the addition with the person wanting to
introduce it.

- Said discussion will hopefully avoid later "strong dissent" among us.

If you want to take a look at our current alternatives, you can use this
(thanks, zlin!):

for m in $(eclectic print-modules --group Alternatives); do echo ==== $m
====; eclectic $m list; done

(Continue reading)


Gmane