Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Musl fixes #490

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Musl fixes #490

wants to merge 4 commits into from

Conversation

fosslinux
Copy link
Owner

Depends on #489

  • A painful regenerated file
  • Musl update to 1.2.5

Ever since an old patch version, it has (for reasonable security
reasons) not supported patched with ../ in the filename.
Many of our patches have been relying on this behaviour being OK,
because we start off with an ancient patch version that didn't perform
such checks. As soon as we need this behaviour after we build a newer
patch though, we will have problems.

So, let's change the policy.
Patches are relative to where tarballs are extracted, rather than the
"working directory" - e.g. have patches for `coreutils-9.4/src/cp.c`
instead of `src/cp.c`.
Keeping this consistent has a few implications;
- patches are applied from the build/ directory in bash era now, with
  `-p0`
- when patches are manually applied in the bash era, use `-p` as
  required, usually `-p1`
- in kaem era where patches are always manually applied, `-p1` is used
Some pregenerated header files exist in the src/ctype and src/locale
directories. They are generated by out-of-tree code found on GitHub,
musl-chartable-tools.

This causes a slight reordering of the early bootstrap, as the early
environment is quite spartan and has broken/missing tools to regenerate
these files. With an added rebuild everything works fine.
Copy link
Owner Author

@fosslinux fosslinux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I am not entirely happy with the licensing state of musl-chartable-tools.

richfelker/musl-chartable-tools#3 strongly implies to me that the author intends for it to be MIT licensed, yet there is a second contributor and no license in the repository.

Should we contact the author? Thoughts?

@stikonas
Copy link
Collaborator

FWIW, I am not entirely happy with the licensing state of musl-chartable-tools.

richfelker/musl-chartable-tools#3 strongly implies to me that the author intends for it to be MIT licensed, yet there is a second contributor and no license in the repository.

Should we contact the author? Thoughts?

Yes, they should either add a license to the repository or at least the 2nd author should clarify...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants