Bo Ørsted Andresen | 3 Feb 23:52 2016

Labels - cross and granularity

Hi

When trying to cross compile I have been coming across some packages
that have build: dependencies which are required both on the build
system and on the target system at build time - but should be safe to
remove afterwards.

For cross build: dependencies are pulled in only on the build system
while run: dependencies are pulled in on both. As such all we can
currently do to fix above mentioned packages is to make them build+run:
dependencies and thus forcing them to be pulled in by pbins and kept
when not building.

A lot of these dependencies, I've been running into are proto headers.
It's possible that a better match for those is the built-against: label.

The description for built-against: is useless, which in turn makes it
useless overall, because we all need to understand exactly when to use
a label in order to decide when it is correct to use. Furthermore the
implementation for built-against: is currently identical to the
implementation for build+run: in combination, so it does not actually
provide any granularity that build+run: does not provide.

Therefore is follows that built-against: should either have its
implementation and description improved, or we should remove it because
it does not provide us with anything.

For the build required on both build system and target system we need
one or more new labels. Three proposals seem to be circulating:

(Continue reading)

Bo Ørsted Andresen | 21 Jan 00:54 2016

Re: [exherbo-commits] python.git -- packages/dev-python/pip/ by Timo Gurr

On Wed, Aug 05, 2015 at 04:11:46PM +0000, git <at> git.exherbo.org wrote:
> Module:    python.git
> Branch:    master
> Commit:    32c36aa562884424e12234aa433a8e989f4e74b9
> URL:       http://git.exherbo.org/?p=python.git;a=commit;h=32c36aa562884424e12234aa433a8e989f4e74b9
> 
> Author:    Timo Gurr <tgurr <at> exherbo.org>
> Committer: Timo Gurr <tgurr <at> exherbo.org>
> Date:      Wed Aug  5 17:45:01 2015 +0200
> 
> ----
> 
> pip: avoid pip <-> mock depedendency loop
[...]  
>  DEPENDENCIES="
> -    test:
> +    suggestion:
>          dev-python/mock[python_abis:*(-)?]
>  "
[...]
>  test_one_multibuild() {
> -    edo mkdir tests
> -    setup-py_test_one_multibuild
> +    # avoid a pip <--> mock dependency loop
> +    if has_version dev-python/mock[python_abis:$(python_get_abi)] ; then
> +        edo mkdir tests
> +        setup-py_test_one_multibuild
> +    else
> +        ewarn "dev-python/mock[python_abis:$(python_get_abi)] not yet installed, skipping tests."
> +    fi
(Continue reading)

Heiko Becker | 9 Jan 23:29 2016
Gravatar

Getting rid of einstall

Hello,

some time ago the question why we still have einstall came up on IRC.
Well, I also don't see a reason why we should have a function that
throws quite a bunch of default values at custom makefiles and hopes
everything will work.
Makefiles supporting DESTDIR can and should just use emake
DESTDIR="${IMAGE}" ... install.

I have removed all three occurrences from our repos (bzip2 even used it
in spite of supporting DESTDIR) and prepared patches to remove it from
paludis, e-f-s and exheres-syntax:
https://galileo.mailstation.de/gerrit/#/q/topic:einstall-removal

Cheers,
Heiko
Wulf C. Krueger | 2 Jan 10:43 2016
Picon
Gravatar

Re: [exherbo-commits] arbor.git -- packages/sys-kernel/linux-headers/ by Kylie McClain


Hello Kylie,

I'm really not happy about this commit...

On 01/02/16 07:04, git@... wrote:
> Module:    arbor.git Branch:    master Commit:
> 84e8f0a7bfa06c4cf2200ca8584c5021b49d019c URL:
> http://git.exherbo.org/?p=arbor.git;a=commit;h=84e8f0a7bfa06c4cf2200ca
8584c5021b49d019c
>
>  Author:    Kylie McClain <somasis@...> Committer: Kylie
> McClain <somasis@...> Date:      Wed Dec 30 13:45:49 2015
> -0500
> 
> ----
> 
> linux-headers[>=4.0]: add musl patch
> 
> this will allow for getting rid of some weird workarounds being
> done in packages using the headers.
> 
> Change-Id: I0b09bb0efa8973791ad64336bae7df78befba112
[...]

> +Upstream: submitted +Reason: kernel headers have a few glibc
> specific definitions. +Source: https://lkml.org/lkml/2014/3/14/266 
> +Source: https://lkml.org/lkml/2014/3/14/269 +Source:
> https://lkml.org/lkml/2014/3/14/274

(Continue reading)

Kylie McClain | 3 Nov 03:55 2015
Picon
Gravatar

RFC: Removal of iputils and net-tools from system set

Hello everyone,

I've been working on bootstrapping an Exherbo system using musl-libc for the
past week or so, and I've now reached the point that the entire system set can
be compiled with musl[1] as the system's libc. However, there's been
two packages
in particular that have caused some issues with this: iputils and net-tools.

net-tools, if you are not aware, is a set of long obsoleted tools, such as
`ifconfig`, `route`, `domainname`, `netstat`, etc. April 2011 was the ten year
anniversary of it's last release, and in Linux time, it's basically a miracle
that the crusty thing still even compiles. (which it doesn't, on musl!)

Long ago it was superseded by iproute2, and was it was actually officially
unmaintained by the maintainers around 2009. [2]

So, it's safe to say that it's well past it's prime. It should be removed from
the system set, and given that we don't have live CDs or anything of that sort,
networking really doesn't matter for the system set, because we expect the user
to install whatever they happen to need for getting connected; and they probably
don't want to use `ifconfig`, if I had to guess.

iputils on the other hand, is a set of network-related tools such `ping`,
`tracepath`, and various other small utilities. Asking why it was in the system
set lead to me learning it's basically on there for historical reasons. It's not
required for any system-critical functionality, and again, we depend on the user
to deal with their networking setup.

I did get it to compile with a small patch to the source, so that's not my
reason, but I don't believe it's required for anything, and it should probably
(Continue reading)

Kylie McClain | 15 Oct 01:51 2015
Picon
Gravatar

coreutils alternatives merging notice (or, "The Coreutils Alternopocalypse 2: Electric Boogaloo")


Hi again everyone. I just wanted to let everyone know that I plan on merging the
coreutils alternatives changes on Saturday if no one says otherwise. The
possibility of this affecting uninterested users is gone now, since it has been
shown to work just fine by tests on Jenkins, on my computers, and by heirecka
and Keruspe's testing, per my request.

A summary of the changes, for those just tuning in...
GNU coreutils have had all their binaries prefixed with a 'g'.
    - This is to be like BSD OSes, which prefix GNU coreutils with 'g', as to
      not conflict with the system's utils. 'g' is the de facto prefix.
    - Autotools will pick up on these prefixed versions, since it checks
      for 'g' prefixed coreutils if it specifically wants the GNU versions.
An alternatives module named 'coreutils' has been made. 'gnu' is
the provider
  name for GNU coreutils.
sys-apps/coreutils has been removed from the system set, and has been
  replaced with a virtual package, virtual/coreutils.
The current other provider for coreutils is Busybox, since it's likely the
  most complete/most common replacement for it, and is the one most users will
  already be familiar with.
GNU coreutils remains the default for the system, and will remain
the default
  for the foreseeable future.

What this means in terms of expected compatibility:
(this is a summary of the changes that will be made to Exheres for Smarties[1])
All coreutils implementations should have very good compatibility with GNU
  coreutils. Common extensions that are widely used should be supported.
Exheres authors should avoid adding convoluted workarounds for certain
(Continue reading)

Kylie McClain | 15 Oct 01:45 2015
Picon
Gravatar

coreutils alternatives merging notice (or, "The Coreutils Alternopocalypse 2: Electric Boogaloo")


Hi again everyone. I just wanted to let everyone know that I plan on merging the
coreutils alternatives changes on Saturday if no one says otherwise. The
possibility of this affecting uninterested users is gone now, since it has been
shown to work just fine by tests on Jenkins, on my computers, and by heirecka
and Keruspe's testing, per my request.

A summary of the changes, for those just tuning in...
GNU coreutils have had all their binaries prefixed with a 'g'.
    - This is to be like BSD OSes, which prefix GNU coreutils with 'g', as to
      not conflict with the system's utils. 'g' is the de facto prefix.
    - Autotools will pick up on these prefixed versions, since it checks
      for 'g' prefixed coreutils if it specifically wants the GNU versions.
An alternatives module named 'coreutils' has been made. 'gnu' is
the provider
  name for GNU coreutils.
sys-apps/coreutils has been removed from the system set, and has been
  replaced with a virtual package, virtual/coreutils.
The current other provider for coreutils is Busybox, since it's likely the
  most complete/most common replacement for it, and is the one most users will
  already be familiar with.
GNU coreutils remains the default for the system, and will remain
the default
  for the foreseeable future.

What this means in terms of expected compatibility:
(this is a summary of the changes that will be made to Exheres for Smarties[1])
All coreutils implementations should have very good compatibility with GNU
  coreutils. Common extensions that are widely used should be supported.
Exheres authors should avoid adding convoluted workarounds for certain
(Continue reading)

Kylie McClain | 16 Sep 21:31 2015
Picon
Gravatar

GNU coreutils alternatives

Hi everyone, I have a lot to cover in this so I'd like to layout exactly
what I'm proposing.

1. Virtuals for coreutils, sed, and grep have been added and are in the
system set. Currently they don't do much. The idea is that the user will
be able to use providers to set their preferred userland;
[providers:gnu], [providers:busybox], etc. GNU coreutils provides a
library (libstdbuf.so) that is used internally, but it is not used by
any other programs, so it can be safely replaced without linkage issues,
and therefore is candidate for a virtual rather than per-package
providers options.

2. Changes for sys-apps/coreutils which add an alternatives module named
'coreutils' are in Gerrit right now. I already tried merging them a few
days ago and it... didn't go well. But, that change was reverted, and
there's a better and more stable method now, which is found at[1].
Anyone who is able to fix their coreutils without panicking, please test
and give feedback.

3. I propose that Exheres specification should be changed to allow for
coreutils implementations, sed, and grep implementations which are very
compatible with their GNU implementations. (toybox, busybox both fit
this very well from my testing)

4. Compatibility issues between a package expecting GNU coreutils should
either have a bug report filed with the upstream of the coreutils
implementation (if we it can be confirmed that's not expected behavior),
have a report filed with the upstream of the package if we have reason
to believe they don't specifically request GNU coreutils,
or add a dependency on sys-apps/coreutils to the package in question.
(Continue reading)

Thomas Anderson | 14 Sep 03:34 2015
Picon
Gravatar

Impending Removal of Baselayout; or, all your base are..

Hi everyone, I plan on removing baselayout from arbor within a week from
now, unless anyone has objections to this.

baselayout has been more or less unused, not recommended, and collecting
dust for a long time now, and I figure that it would do well to bury it
and remove options from packages which add support for baselayout.

Alternatives to baselayout include systemd, runit, and beginning.

Any objections to this?

~ Kylie (having haxx0red tanderson's computer)
Kylie McClain | 23 Jul 11:55 2015

Re: Yet another checksum proposal


On 07/23/2015 05:12 AM, Niels Ole Salscheider wrote:
> Hi,
> 
> this sounds like a proposal that could be implemented quickly. It
> might only protect against broken downloads and upstream changing
> files but I would be glad if at least this annoying problem was
> solved.
> 
> Would this include unofficial repositories?

Yes, it would. Unofficial repository distfiles fetching was enabled on
distfiles.e.o a little while ago.

(that reminds me, maybe I should post the list of packages with bad
DOWNLOADS that the mirror daemon keeps spamming me with every day and
get others to do my work for me...)

> I thought a bit more about this problem after my last mail to the
> list and I think that another alternative would be to let paludis
> handle this: Imagine someone bumps a package with "git mv". He or
> she will still test the change locally (we all do, don't we?) and
> therefore use paludis to build it. Paludis would see that there is
> no checksum stored for (some of) the distfiles. It could then offer
> to add it to some defined file inside the repository, git commit
> the change (or amend the last commit) and push it to the local
> repository from which it synced before.

The concern I have there is that we get into the messy part of dealing
with automating SCM changes, which would result in making Paludis have
(Continue reading)

Kylie McClain | 21 Jul 23:14 2015

Yet another checksum proposal

Hi everyone, a week or so ago me and Kim were talking about the
distfiles mirror, and we began to drift to the topic of checksumming and
how we could prevent bad downloads and such. Due to to it being 5:30 AM
at the time, I believe I managed to come up with an idea of how to
possibly work checksumming into our system in a way that doesn't
interrupt our One True Workflow.

Essentially, we'd offload checksum generation to the mirror by adding a
manifest generation to run_accerso.sh. Every day when accerso is ran on
distfiles.e.o, it would do a few sanity checks on the fetched files,
delete bad ones, and create a list of checksums which would be fetched
at some point in time, perhaps sync, and then used during installation.

A few obvious issues with this is how it would work with locally added
packages (such as when bumping a package and testing it), and how it
puts trust in the mirror to generate good checksums. The first issue
could be taken care of by allowing fetching to continue with a warning
or something that the integrity can't be checked, and the second... the
second I don't believe is that much of an issue, because if the mirror
has a bad checksum, then that means bad fetches, which means we have a
problem anyway and someone needs to fix that package's bad DOWNLOADS.

Benedikt proposed for the sanity checks, we could just check the file
extension of what we've fetched against what the actual file type is;
ex. `for file in *.tar.gz;do [[ $(file -b --mime-type) ==
application/x-gzip ]] || rm -v "$file";done` or something similar.
That would be able to protect the checksum generation from at least
things like badly configured servers serving 404 pages without sending
an actual 404 status back to us.

(Continue reading)


Gmane