3 p.m.
Currently we have a "fork" of aports.git. It's very difficult to rebase
what we have, so it definitely needs to "restart" imo. We can move
aports.git to aports-historic.git and then re-clone from Alpine to make
it cleaner, but I think the better thing is to pull all the packages
that we want to keep different from Alpine and put them in system/ in
packages.git, leaving our aports.git fork strictly for changes we wish
to upstream.
Of course, since we can no longer merge in upstream changes, we would
therefore be tracking all the updates ourselves. This is why I would
like to be conservative.
These are the packages with changes that, for whatever reason, we cannot
merge upstream to Alpine. We should discuss what to do with them.
audacious (and audacious-plugins):
We are shipping the Qt variant. Alpine are shipping the Gtk variant.
Since Alpine doesn't have Qt5 in main/ we unfortunately cannot upstream
this change. We could rename it audacious-qt and ship it in user/,
where even Alpine users could enjoy it, but it would need a maintainer.
bash:
We have the -binsh virtual, the patch for bashrc location, and our own
bashrc file. None of these make sense for upstream. Unless I hear a
good argument for offering it in user/, I'm pretty sure this should be
in system/.
binutils:
We ship 2.29 instead of 2.28. We ship seven patches for everything from
tests to wrong behaviour with MIPS targets. ncopa did not seem
interested in bumping binutils until GCC is also bumped. This could be
moved to system/ since we are already maintaining it ourselves.
busybox:
We have an /sbin/init virtual. I added busybox as a provider.
Honestly, this was primarily for Alpine's benefit. Since they don't
have a reason to ship a /sbin/init virtual I think this change can be
discarded; if anyone wants to use busybox as /sbin/init, please speak up
now.
check:
They have a checkdepends of gawk which is satisfied by our mawk. Very
annoying as I don't want to ship gawk at all, but I suppose we can live
with it if it means we don't have to fork.
coreutils:
We have a bunch of hacks to support cross-compile, and a 32-bit PowerPC
patch. They don't release very often so I am fine with moving this to
system/.
exiv2:
We are tracking 0.26 which is not yet released on their official site
because it includes fixes for big-endian that are irrelevant to Alpine.
I know the maintainers personally and I am fine with maintaining this
myself in system/.
ffmpeg:
We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype,
wavpack, libwebp, and pulseaudio output support. Almost none of those
are in Alpine main/ so it is impossible to add them to ffmpeg
dependencies upstream. I really don't want to maintain ffmpeg myself
since it is a frequent security flyer; if someone else wants to maintain
it in system/ then that is fine. As someone who *uses* three of those
plugins on my own system,
freetype:
Our freetype-profile.sh differs (we enable infinality by default). We
have no other changes. Alpine upstream temporarily did re-enable
infinality by default, but they did not like it (I believe there was
some bug in their XFCE 4 maybe?) so they reverted it.
gcc:
Our gcc is wildly different from Alpine, so much so that this probably
belongs in system/ even if we do end up keeping an aports.git fork. In
addition, I don't feel comfortable with jumping to GCC 8 and Alpine has
been talking about it for retpoline support. This is going in system/
unless someone has a very good argument why it shouldn't.
I'm limiting each email to 10 packages. See you in the next message!
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
5:21 p.m.
On Feb 11 02:00 PM, A. Wilcox wrote:
Currently we have a "fork" of aports.git. It's very
difficult to rebase
what we have, so it definitely needs to "restart" imo. We can move
aports.git to aports-historic.git and then re-clone from Alpine to make
it cleaner, but I think the better thing is to pull all the packages
that we want to keep different from Alpine and put them in system/ in
packages.git, leaving our aports.git fork strictly for changes we wish
to upstream.
This makes sense to me. I was concerned about what would happen to the
old repo, so archiving it seems like a good idea.
audacious (and audacious-plugins):
We are shipping the Qt variant. Alpine are shipping the Gtk variant.
Since Alpine doesn't have Qt5 in main/ we unfortunately cannot upstream
this change. We could rename it audacious-qt and ship it in user/,
where even Alpine users could enjoy it, but it would need a maintainer.
audacious-qt is probably the better choice. Gentoo also calls it
audacious-qt, so there is some precedent.
ffmpeg:
We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype,
wavpack, libwebp, and pulseaudio output support. Almost none of those
are in Alpine main/ so it is impossible to add them to ffmpeg
dependencies upstream. I really don't want to maintain ffmpeg myself
since it is a frequent security flyer; if someone else wants to maintain
it in system/ then that is fine. As someone who *uses* three of those
plugins on my own system,
I think you forgot to finish this part.
freetype:
Our freetype-profile.sh differs (we enable infinality by default). We
have no other changes. Alpine upstream temporarily did re-enable
infinality by default, but they did not like it (I believe there was
some bug in their XFCE 4 maybe?) so they reverted it.
There is something weird going on with the LCD filtering such that only
"lcdnone" is usable on Adélie last time I tried, and even then there are
still some visual artifacts. I'm not sure if this is related to
infinality or not but it's worth investigating.
The rest of your proposals make sense to me.
Max
6:53 p.m.
On Sun, Feb 11, 2018 at 4:21 PM, Max Rees <maxcrees(a)me.com> wrote:
On Feb 11 02:00 PM, A. Wilcox wrote:
> Currently we have a "fork" of aports.git. It's very difficult to
rebase
> what we have, so it definitely needs to "restart" imo. We can move
> aports.git to aports-historic.git and then re-clone from Alpine to make
> it cleaner, but I think the better thing is to pull all the packages
> that we want to keep different from Alpine and put them in system/ in
> packages.git, leaving our aports.git fork strictly for changes we wish
> to upstream.
This makes sense to me. I was concerned about what would happen to the
old repo, so archiving it seems like a good idea.
> audacious (and audacious-plugins):
>
> We are shipping the Qt variant. Alpine are shipping the Gtk variant.
> Since Alpine doesn't have Qt5 in main/ we unfortunately cannot upstream
> this change. We could rename it audacious-qt and ship it in user/,
> where even Alpine users could enjoy it, but it would need a maintainer.
audacious-qt is probably the better choice. Gentoo also calls it
audacious-qt, so there is some precedent.
> ffmpeg:
>
> We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype,
> wavpack, libwebp, and pulseaudio output support. Almost none of those
> are in Alpine main/ so it is impossible to add them to ffmpeg
> dependencies upstream. I really don't want to maintain ffmpeg myself
> since it is a frequent security flyer; if someone else wants to maintain
> it in system/ then that is fine. As someone who *uses* three of those
> plugins on my own system,
I think you forgot to finish this part.
> freetype:
>
> Our freetype-profile.sh differs (we enable infinality by default). We
> have no other changes. Alpine upstream temporarily did re-enable
> infinality by default, but they did not like it (I believe there was
> some bug in their XFCE 4 maybe?) so they reverted it.
There is something weird going on with the LCD filtering such that only
"lcdnone" is usable on Adélie last time I tried, and even then there are
still some visual artifacts. I'm not sure if this is related to
infinality or not but it's worth investigating.
I believe this is why infinality is disabled on Alpine, there are
problems with gtk+2.
William
6:54 p.m.
New subject: main/ -> system/ + user/ vs aports.git fork [1]
On 02/11/18 16:21, Max Rees wrote:
On Feb 11 02:00 PM, A. Wilcox wrote:
> We can move
> aports.git to aports-historic.git
This makes sense to me. I was concerned about what would happen to the
old repo, so archiving it seems like a good idea.
We even still have the archive of Gentoo-based ebuilds, in case we need
them: https://code.foxkit.us/adelie/packages/tree/ebuild
> audacious (and audacious-plugins):
audacious-qt is probably the better choice. Gentoo also calls it
audacious-qt, so there is some precedent.
Okay, I will move that over to user/ soon-ish.
> ffmpeg:
>
> We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype,
> wavpack, libwebp, and pulseaudio output support. Almost none of those
> are in Alpine main/ so it is impossible to add them to ffmpeg
> dependencies upstream. I really don't want to maintain ffmpeg myself
> since it is a frequent security flyer; if someone else wants to maintain
> it in system/ then that is fine. As someone who *uses* three of those
> plugins on my own system,
I think you forgot to finish this part.
As someone who *uses* three of those plugins on my own system, I would
be very disappointed to have to give them up. But I don't want to have
to maintain ffmpeg, and I don't think I could track their releases.
Does anyone else want to?
> freetype:
There is something weird going on with the LCD filtering such that only
"lcdnone" is usable on Adélie last time I tried, and even then there are
still some visual artifacts. I'm not sure if this is related to
infinality or not but it's worth investigating.
I'm not seeing visual artifacts anywhere, on my desktop 21" wide-screen
flat panel monitor, my laptop 13" panel, or my 17" CRT. Is it only in
some software or does it affect all X clients? Maybe start a new thread
about that.
The rest of your proposals make sense to me.
Now we just have to find willing maintainers for the packages that need
them. :)
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
7:03 p.m.
On Feb 11 05:54 PM, A. Wilcox wrote:
We even still have the archive of Gentoo-based ebuilds, in case we
need
them: https://code.foxkit.us/adelie/packages/tree/ebuild
In my opinion these should be removed from packages.git and put in a
separate archive as well, unless it's something that you refer to often.
As someone who *uses* three of those plugins on my own system, I
would
be very disappointed to have to give them up. But I don't want to have
to maintain ffmpeg, and I don't think I could track their releases.
Does anyone else want to?
If nobody else steps up I can do this possibly.
I'm not seeing visual artifacts anywhere, on my desktop 21"
wide-screen
flat panel monitor, my laptop 13" panel, or my 17" CRT. Is it only in
some software or does it affect all X clients? Maybe start a new thread
about that.
It was mostly firefox-esr I believe. Once alpha5 is released I will test
again and report the results.
Max
10:09 p.m.
New subject: main/ -> system/ + user/ vs aports.git fork [1]
On 02/11/18 18:03, Max Rees wrote:
On Feb 11 05:54 PM, A. Wilcox wrote:
> We even still have the archive of Gentoo-based ebuilds, in case we need
> them: https://code.foxkit.us/adelie/packages/tree/ebuild
In my opinion these should be removed from packages.git and put in a
separate archive as well, unless it's something that you refer to often.
We have not yet finished migrating all the packages out of that to the
user/ repository. At that time, we likely will. (As it stands, horst@
is the only person I know who managed to build BasiliskII for musl.)
> As someone who *uses* three of those plugins on my own system, I
would
> be very disappointed to have to give them up. But I don't want to have
> to maintain ffmpeg, and I don't think I could track their releases.
> Does anyone else want to?
If nobody else steps up I can do this possibly.
I'll keep that in mind.
> I'm not seeing visual artifacts anywhere, on my desktop
21" wide-screen
> flat panel monitor, my laptop 13" panel, or my 17" CRT. Is it only in
> some software or does it affect all X clients? Maybe start a new thread
> about that.
It was mostly firefox-esr I believe. Once alpha5 is released I will test
again and report the results.
Sounds like a plan.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
6:52 p.m.
Hello,
On Sun, Feb 11, 2018 at 2:00 PM, A. Wilcox <awilfox(a)adelielinux.org> wrote:
Currently we have a "fork" of aports.git. It's very
difficult to rebase
what we have, so it definitely needs to "restart" imo. We can move
aports.git to aports-historic.git and then re-clone from Alpine to make
it cleaner, but I think the better thing is to pull all the packages
that we want to keep different from Alpine and put them in system/ in
packages.git, leaving our aports.git fork strictly for changes we wish
to upstream.
Of course, since we can no longer merge in upstream changes, we would
therefore be tracking all the updates ourselves. This is why I would
like to be conservative.
These are the packages with changes that, for whatever reason, we cannot
merge upstream to Alpine. We should discuss what to do with them.
audacious (and audacious-plugins):
We are shipping the Qt variant. Alpine are shipping the Gtk variant.
Since Alpine doesn't have Qt5 in main/ we unfortunately cannot upstream
this change. We could rename it audacious-qt and ship it in user/,
where even Alpine users could enjoy it, but it would need a maintainer.
I am more in favour of moving audacious to community, I just haven't
done it yet. But, Alpine ships a GTK+ desktop instead of a Qt one.
bash:
We have the -binsh virtual, the patch for bashrc location, and our own
bashrc file. None of these make sense for upstream. Unless I hear a
good argument for offering it in user/, I'm pretty sure this should be
in system/.
binutils:
We ship 2.29 instead of 2.28. We ship seven patches for everything from
tests to wrong behaviour with MIPS targets. ncopa did not seem
interested in bumping binutils until GCC is also bumped. This could be
moved to system/ since we are already maintaining it ourselves.
busybox:
We have an /sbin/init virtual. I added busybox as a provider.
Honestly, this was primarily for Alpine's benefit. Since they don't
have a reason to ship a /sbin/init virtual I think this change can be
discarded; if anyone wants to use busybox as /sbin/init, please speak up
now.
We may want to keep this for Adelie Core, as we will probably ship
busybox userland anyway in that case. But we may wind up just using
s6 as the init system there, so I don't know for sure.
check:
They have a checkdepends of gawk which is satisfied by our mawk. Very
annoying as I don't want to ship gawk at all, but I suppose we can live
with it if it means we don't have to fork.
We could use a virtual here instead.
coreutils:
We have a bunch of hacks to support cross-compile, and a 32-bit PowerPC
patch. They don't release very often so I am fine with moving this to
system/.
I am okay with upstreaming this.
exiv2:
We are tracking 0.26 which is not yet released on their official site
because it includes fixes for big-endian that are irrelevant to Alpine.
I know the maintainers personally and I am fine with maintaining this
myself in system/.
Technically, s390x is big-endian but I doubt anyone is using exiv2 there.
ffmpeg:
We enable a LOT more plugins: libcdio, ladspa, lzma, libspeex, freetype,
wavpack, libwebp, and pulseaudio output support. Almost none of those
are in Alpine main/ so it is impossible to add them to ffmpeg
dependencies upstream. I really don't want to maintain ffmpeg myself
since it is a frequent security flyer; if someone else wants to maintain
it in system/ then that is fine. As someone who *uses* three of those
plugins on my own system,
We should probably check this to make sure that we're not shipping
anything that violates patents.
freetype:
Our freetype-profile.sh differs (we enable infinality by default). We
have no other changes. Alpine upstream temporarily did re-enable
infinality by default, but they did not like it (I believe there was
some bug in their XFCE 4 maybe?) so they reverted it.
gcc:
Our gcc is wildly different from Alpine, so much so that this probably
belongs in system/ even if we do end up keeping an aports.git fork. In
addition, I don't feel comfortable with jumping to GCC 8 and Alpine has
been talking about it for retpoline support. This is going in system/
unless someone has a very good argument why it shouldn't.
It is complicated. I would prefer to have a gcc6 package for GCC 6
and a separate package for GCC 8. Shipping GCC 8 is necessary for
risc-v, which I am marginally interested in. Ideally, this is
something we would work with Alpine on.
William
7:13 p.m.
New subject: main/ -> system/ + user/ vs aports.git fork [1]
On 02/11/18 17:52, William Pitcock wrote:
Hello,
On Sun, Feb 11, 2018 at 2:00 PM, A. Wilcox <awilfox(a)adelielinux.org> wrote:
> audacious (and audacious-plugins):
I am more in favour of moving audacious to community, I just haven't
done it yet. But, Alpine ships a GTK+ desktop instead of a Qt one.
That's fine, but we still need audacious-qt. You can't build both kinds
in the same tree (I tried, it was a mess). That can go in user/ unless
you are suggesting that go in Alpine community/ (either would be fine
with me).
> busybox:
>
> We have an /sbin/init virtual. I added busybox as a provider.
We may want to keep this for Adelie Core, as we will probably ship
busybox userland anyway in that case. But we may wind up just using
s6 as the init system there, so I don't know for sure.
We'll need to have our own busybox package in system/, unless this
/sbin/init provider is being upstreamed. And it doesn't make sense for
Alpine because Alpine don't ship sysvinit (or other /sbin/init providers).
> check:
>
> They have a checkdepends of gawk which is satisfied by our mawk. Very
> annoying as I don't want to ship gawk at all, but I suppose we can live
> with it if it means we don't have to fork.
We could use a virtual here instead.
I had thought about cmd:awk, but wouldn't busybox provide that?
> coreutils:
>
> We have a bunch of hacks to support cross-compile, and a 32-bit PowerPC
> patch. They don't release very often so I am fine with moving this to
> system/.
I am okay with upstreaming this.
Trust me, you aren't. You really, really aren't.
https://code.foxkit.us/adelie/aports/commit/53c43166
It uses conditionals for sha512sum and source and it is the worst
ugliest hack in all of aports. You really don't want this upstreamed.
I had forgotten that the 32-bit PowerPC patch was upstreamed in 8.28 so
we don't actually ship that any more.
> exiv2:
>
> We are tracking 0.26 which is not yet released on their official site
> because it includes fixes for big-endian that are irrelevant to Alpine.
> I know the maintainers personally and I am fine with maintaining this
> myself in system/.
Technically, s390x is big-endian but I doubt anyone is using exiv2 there.
It is only relevant if you are also processing metadata on a separate
thread. I only ran in to it when Dolphin was thumbnailing a Pictures
directory with thousands of JPEGs. It is very unlikely that someone is
doing such on s390x, and anyway, when 0.26 is released it will be a moot
point.
> ffmpeg:
We should probably check this to make sure that we're not shipping
anything that violates patents.
I disabled all the mp4 stuff that didn't explicitly have a patent waiver
applied:
- --enable-libx264 \
The x265 stuff actually does have a patent waiver until "more than
250,000 copies are in use". I figure by that time it won't be a big
deal to give them their 10 cents per seat, especially since ffmpeg is
not included by default in the installation.
(This does raise a separate concern of the fact that we need a popcon
like system not only for research but for stuff like that. That will be
another thread, probably in -project.)
> gcc:
>
> Our gcc is wildly different from Alpine, so much so that this probably
> belongs in system/ even if we do end up keeping an aports.git fork. In
> addition, I don't feel comfortable with jumping to GCC 8 and Alpine has
> been talking about it for retpoline support. This is going in system/
> unless someone has a very good argument why it shouldn't.
It is complicated. I would prefer to have a gcc6 package for GCC 6
and a separate package for GCC 8. Shipping GCC 8 is necessary for
risc-v, which I am marginally interested in. Ideally, this is
something we would work with Alpine on.
I don't have a problem with having gcc8 for a RISC-V target only,
because the hardware itself is still new and would have the potential
for issues just as GCC 8 does. Since GCC 8 changes ABI for PA-RISC as
well, if we ever target that we should probably use GCC 8 there as well.
There are serious regressions in LTO when -g is passed, and SIMD
multiplication on aarch64 generates wrong code with any -O not 0
(multiple prs filed on this, maybe it will get fixed). In the same way
6.0 made me nervous until 6.3, 8 is shaping up to be similar. And I
have this feeling Alpine will be moving to 8 far before 8.3 ;)
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
11:38 p.m.
On Sun, 11 Feb 2018 14:00:15 -0600
"A. Wilcox" <awilfox(a)adelielinux.org> wrote:
bash:
We have the -binsh virtual, the patch for bashrc location, and our own
bashrc file. None of these make sense for upstream. Unless I hear a
good argument for offering it in user/, I'm pretty sure this should be
in system/.
I'd actually like to see dash moved into system to provide /bin/sh -
but that notwithstanding, the patch to make bash use bashrc properly
and our own bashrc are a good enough reason to keep our own bash in
system/ ...
binutils:
We ship 2.29 instead of 2.28. We ship seven patches for everything
from tests to wrong behaviour with MIPS targets. ncopa did not seem
interested in bumping binutils until GCC is also bumped. This could
be moved to system/ since we are already maintaining it ourselves.
gcc:
Our gcc is wildly different from Alpine, so much so that this probably
belongs in system/ even if we do end up keeping an aports.git fork.
In addition, I don't feel comfortable with jumping to GCC 8 and
Alpine has been talking about it for retpoline support. This is
going in system/ unless someone has a very good argument why it
shouldn't.
I support binutils and gcc going into our system/ - especially since
we're supporting different platforms from Alpine and those may have
technical demands of their own.
As for the rest, I defer judgement to people who know what they're
doing - the sooner we get alpha5 going and this grand unification done,
the sooner i get community/emacs and can actually work on things
comfortably :)
Regards,
- Horst
12:17 a.m.
New subject: main/ -> system/ + user/ vs aports.git fork [1]
On 02/11/18 22:38, Horst G. Burkhardt wrote:
On Sun, 11 Feb 2018 14:00:15 -0600
"A. Wilcox" <awilfox(a)adelielinux.org> wrote:
> bash:
I'd actually like to see dash moved into system to provide /bin/sh -
but that notwithstanding, the patch to make bash use bashrc properly
and our own bashrc are a good enough reason to keep our own bash in
system/ ...
dash is already in system via Alpine main. It's certainly possible to
provide /bin/sh using dash, but I'm not sure if that is well advised.
I suppose we could offer the option to advanced users, but I'm not sure
we should make it all that obvious that one can do it.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
6:58 a.m.
New subject: dash as /bin/sh (was: Re: main/ -> system/ + user/ vs aports.git fork [1])
On Sun, 11 Feb 2018 23:17:30 -0600
"A. Wilcox" <awilfox(a)adelielinux.org> wrote:
dash is already in system via Alpine main. It's certainly
possible to
provide /bin/sh using dash, but I'm not sure if that is well advised.
You've known me long enough to know that I would never use this as the
primary justification for anything, but: Ubuntu did it years ago and
haven't had trouble. When they implemented the change. system boot
times decreased drastically.
init scripts (the one area one might conceivably have trouble, if
someone gets sloppy) shouldn't be using bashisms anyway (we're aiming
to be POSIX-conformant, no?). And it's during that boot process where
we're going to see the real benefit of doing this - especially on the
older machines we're looking to support.
Per our discussion earlier today, I think we both agree that the
numbers indicate that dash utterly creams bash for execution speed.
also, in anecdata: i've been using dash as system /bin/sh for at least
five years now. I've had precisely zero issues with system management
attributable to that.
It's not as though we would be sacrificing bash or zsh as the user
shell.
I suppose we could offer the option to advanced users, but I'm
not
sure we should make it all that obvious that one can do it.
I can understand your reticence, but if Ubuntu can pull it off without
the sky falling - they did so eleven years ago now - I think we can
probably discern from that that it's not a horrible idea and is
probably not going to be a source of problems to the end-user, even the
novice.
You saw my numbers from earlier. You verified them yourself. The
difference executing a not-too-complex shell script is measured in
hundredths of seconds on a 1.42GHz PowerPC G4. Think how much
improvement is seen on, say, the 233MHz PowerPC 750 in an iMac/iBook.
Think how much of an improvement would be seen on a Pentium MMX
ThinkPad. It's an invisible change if you're using a modern machine,
but people still getting mileage out of older hardware will appreciate
it.
Best,
- Horst.
5:26 p.m.
New subject: dash as /bin/sh
init scripts (the one area one might conceivably have trouble, if
someone gets sloppy) shouldn't be using bashisms anyway (we're aiming
to be POSIX-conformant, no?). And it's during that boot process where
we're going to see the real benefit of doing this - especially on the
older machines we're looking to support.
Correct on both accounts. My concern is more with root's default login
shell being /bin/sh. I do not know how well dash would be tolerated as
the interactive shell for administrating Adélie.
Sure, we could default root to bash, but then we require bash (instead
of just suggesting bash).
It's not as though we would be sacrificing bash or zsh as the
user
shell.
Except that's exactly what we're doing, for root.
Think how much of an improvement would be seen on a Pentium MMX
ThinkPad.
Oh, definitely. OpenRC was the slowest part of booting Foxtoo on the
Pentium/100 laptop, way before Adélie even had its name.
It's an invisible change if you're using a modern machine,
unless you are root,
but people still getting mileage out of older hardware will
appreciate it.
It isn't just people with older hardware:
http://lists.alpinelinux.org/alpine-devel/5695.html
http://lists.alpinelinux.org/alpine-devel/5943.html
Some Alpine users want dash as /bin/sh too.
So again: I don't have a problem offering the option, but I really do
not want to make it the default until we have an answer for root.
All the best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
5:51 p.m.
New subject: dash as /bin/sh
On 02/12/18 16:26, A. Wilcox wrote:
So again: I don't have a problem offering the option, but I
really do
not want to make it the default until we have an answer for root.
Just pushed system/dash. It has dash-binsh. For testing purposes, I
swapped bash-binsh with dash-binsh on the ppc32 builder. (Nerves of
steel here.)
It works great, it didn't break anything or set the world on fire, etc.
I was so happy I actually tried building dash with itself as /bin/sh!
awilcox on elaine /usr/src/packages/system/dash $ abuild
/usr/bin/abuild: 1778: /usr/bin/abuild: Bad substitution
>> ERROR: dash: all failed
abuild does not work with dash as /bin/sh. This is pretty much going to
be a non-starter on builders, and it's going to make development on
computers with dash-binsh completely unusable.
I'm not sure if dash-binsh should conflict with abuild so a user can't
do that, or if I should just remove dash-binsh completely, or if abuild
should depend on bash and use #!/bin/bash. This is kind of terrible,
especially since abuild works fine with bash or busybox as /bin/sh. It
even almost works completely with zsh as /bin/sh.
Sincerely,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
6:04 p.m.
New subject: dash as /bin/sh
On Mon, 12 Feb 2018 16:51:07 -0600
"A. Wilcox" <awilfox(a)adelielinux.org> wrote:
On 02/12/18 16:26, A. Wilcox wrote:
> Correct on both accounts. My concern is more with root's
default
> login shell being /bin/sh. I do not know how well dash would be
> tolerated as the interactive shell for administrating Adélie.
Honestly, that's a preference issue - it's trivial to change the
default login shell for root to something friendlier.
> So again: I don't have a problem offering the option, but I
really
> do not want to make it the default until we have an answer for
> root.
"let root have nice things" or "don't spend any more time than you
need
to in an interactive root shell". Or perhaps some mix of both. This
isn't a huge obstacle, it's just another thing that needs to go in the
documentation - "hey, POSIX sh is kind of limiting, you might want to
use bash for day to day system administration."
Just pushed system/dash. It has dash-binsh. For testing purposes,
I
swapped bash-binsh with dash-binsh on the ppc32 builder. (Nerves of
steel here.)
It works great, it didn't break anything or set the world on fire,
etc.
I was so happy I actually tried building dash with itself as /bin/sh!
awilcox on elaine /usr/src/packages/system/dash $ abuild
/usr/bin/abuild: 1778: /usr/bin/abuild: Bad substitution
>>> ERROR: dash: all failed
ooft. I've seen this happen with some configure scripts that falsely
advertise that they're 'sh' when they only ever really got tested with
bash.
abuild does not work with dash as /bin/sh. This is pretty much
going
to be a non-starter on builders, and it's going to make development on
computers with dash-binsh completely unusable.
I'm not sure if dash-binsh should conflict with abuild so a user can't
do that, or if I should just remove dash-binsh completely, or if
abuild should depend on bash and use #!/bin/bash. This is kind of
terrible, especially since abuild works fine with bash or busybox
as /bin/sh. It even almost works completely with zsh as /bin/sh.
The solution is to make abuild depend on bash and use #!/bin/bash - if
it's using sh features that aren't quite POSIX it shouldn't be calling
sh.
If abuild doesn't honestly advertise its requirements and capabilities,
that's an issue with abuild, and it's a fixable one. We have a good
working relationship already with the Alpine folks, and you've
mentioned some of them also would like dash as /bin/sh - I'm sure
they'll be amenable to that being fixed.
Best,
- Horst.
6:38 p.m.
New subject: dash as /bin/sh
On 02/12/18 17:04, Horst G. Burkhardt wrote:
On Mon, 12 Feb 2018 16:51:07 -0600
"A. Wilcox" <awilfox(a)adelielinux.org> wrote:
> On 02/12/18 16:26, A. Wilcox wrote:
>> Correct on both accounts. My concern is more with root's default
>> login shell being /bin/sh. I do not know how well dash would be
>> tolerated as the interactive shell for administrating Adélie.
Honestly, that's a preference issue - it's trivial to change the
default login shell for root to something friendlier.
"let root have nice things" or "don't spend any more time than you
need
to in an interactive root shell". Or perhaps some mix of both. This
isn't a huge obstacle, it's just another thing that needs to go in the
documentation - "hey, POSIX sh is kind of limiting, you might want to
use bash for day to day system administration."
You make a good argument that users should not be spending time in an
interactive root shell anyway. Perhaps dash-binsh /would/ have a place;
but see below.
> awilcox on elaine /usr/src/packages/system/dash $ abuild
> /usr/bin/abuild: 1778: /usr/bin/abuild: Bad substitution
ooft. I've seen this happen with some configure scripts that falsely
advertise that they're 'sh' when they only ever really got tested with
bash.
> abuild does not work with dash as /bin/sh. This is pretty much going
> to be a non-starter on builders, and it's going to make development on
> computers with dash-binsh completely unusable.
>
> I'm not sure if dash-binsh should conflict with abuild so a user can't
> do that, or if I should just remove dash-binsh completely, or if
> abuild should depend on bash and use #!/bin/bash. This is kind of
> terrible, especially since abuild works fine with bash or busybox
> as /bin/sh. It even almost works completely with zsh as /bin/sh.
The solution is to make abuild depend on bash and use #!/bin/bash - if
it's using sh features that aren't quite POSIX it shouldn't be calling
sh.
If abuild doesn't honestly advertise its requirements and capabilities,
that's an issue with abuild, and it's a fixable one. We have a good
working relationship already with the Alpine folks, and you've
mentioned some of them also would like dash as /bin/sh - I'm sure
they'll be amenable to that being fixed.
Let me start off by saying abuild, as written upstream, is not falsely
advertising anything.
Upstream ships abuild with #!/bin/ash. They require BusyBox shell. I
managed to make it work on bash *and* get the patches upstreamed:
https://github.com/alpinelinux/abuild/commit/f1faef786
https://github.com/alpinelinux/abuild/commit/f39ef92cd
https://github.com/alpinelinux/abuild/commit/597a7f167
That said, I do not think Alpine's developers had any intention of
making a POSIX sh script when they wrote abuild.
The line that failed with "bad substitution" is:
if [ ! -f
"$REPODEST/$repo/${subpkgarch/noarch/$CARCH}/$subpkgname-$pkgver-r$pkgrel.apk"
]; then
This is a blatant bashism, but it's supported in BusyBox (and zsh), so
there is no harm in using it for them.
Additionally, since they require BusyBox, they specifically told me two
years ago that making it #!/bin/sh on Adélie was unsupported and that I
can keep the pieces when it breaks.
possible bashism in /usr/bin/abuild line 232 (type):
possible bashism in /usr/bin/abuild line 257 ($'...' should be "$(printf
'...')"):
possible bashism in /usr/bin/abuild line 265 (${foo:3[:1]}):
possible bashism in /usr/bin/abuild line 502 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 832 ($'...' should be "$(printf
'...')"):
possible bashism in /usr/bin/abuild line 834 ($'...' should be "$(printf
'...')"):
possible bashism in /usr/bin/abuild line 944 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1323 (${foo:3[:1]}):
possible bashism in /usr/bin/abuild line 1440 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1441 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1684 (type):
possible bashism in /usr/bin/abuild line 1778 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1793 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 1806 (${parm/?/pat[/str]}):
possible bashism in /usr/bin/abuild line 2029 (export foo=bar should be
foo=bar; export foo):
possible bashism in /usr/bin/abuild line 2111 (${parm/?/pat[/str]}):
I am almost positive that I could replace the ${var//} syntax with
subshells + sed and manage to bring this thing in to POSIX compliance,
or at least very close to it. However, I am equally almost positive
that such a change wouldn't be accepted upstream.
And even if I did, I don't trust that future patches and updates to
abuild wouldn't break it simply because Alpine's developers and
contributors might simply forget to test POSIX compliance. That would
unintentionally break it here over again.
Let me remind everyone that Alpine is *upstream*, not *downstream*.
They enforce the rules, and we play by them. We aren't the ones who
tell them to use POSIX, they're the ones that tell us to use a bash-like.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
5:53 a.m.
New subject: dash as /bin/sh
On Mon, 12 Feb 2018 17:38:33 -0600
"A. Wilcox" <awilfox(a)adelielinux.org> wrote:
Let me start off by saying abuild, as written upstream, is not
falsely
advertising anything.
I stand corrected; my only experience with abuild at this point is what
I've picked up here and there by orbiting Adelie.
Upstream ships abuild with #!/bin/ash. They require BusyBox shell.
I
managed to make it work on bash *and* get the patches upstreamed:
https://github.com/alpinelinux/abuild/commit/f1faef786
https://github.com/alpinelinux/abuild/commit/f39ef92cd
https://github.com/alpinelinux/abuild/commit/597a7f167
That said, I do not think Alpine's developers had any intention of
making a POSIX sh script when they wrote abuild.
The line that failed with "bad substitution" is:
if [ ! -f
"$REPODEST/$repo/${subpkgarch/noarch/$CARCH}/$subpkgname-$pkgver-r$pkgrel.apk"
]; then
This is a blatant bashism, but it's supported in BusyBox (and zsh), so
there is no harm in using it for them.
Additionally, since they require BusyBox, they specifically told me
two years ago that making it #!/bin/sh on Adélie was unsupported and
that I can keep the pieces when it breaks.
Then it sounds very much like if you've made it work with bash
reliably, and it uses bashisms that just happen to be supported by
their implementation of ash, that the sensible choice is indeed to
make abuild depend on bash specifically.
Let me remind everyone that Alpine is *upstream*, not *downstream*.
They enforce the rules, and we play by them. We aren't the ones who
tell them to use POSIX, they're the ones that tell us to use a
bash-like.
If they're telling us to use a bash-like, then we should clearly just
comply and make abuild depend on bash, then :)
Best,
- Horst.
10:08 a.m.
New subject: dash as /bin/sh
Hello,
On Tue, Feb 13, 2018 at 4:53 AM, Horst G. Burkhardt
<horst(a)adelielinux.org> wrote:
On Mon, 12 Feb 2018 17:38:33 -0600
"A. Wilcox" <awilfox(a)adelielinux.org> wrote:
> Let me start off by saying abuild, as written upstream, is not falsely
> advertising anything.
I stand corrected; my only experience with abuild at this point is what
I've picked up here and there by orbiting Adelie.
> Upstream ships abuild with #!/bin/ash. They require BusyBox shell. I
> managed to make it work on bash *and* get the patches upstreamed:
>
> https://github.com/alpinelinux/abuild/commit/f1faef786
> https://github.com/alpinelinux/abuild/commit/f39ef92cd
> https://github.com/alpinelinux/abuild/commit/597a7f167
>
> That said, I do not think Alpine's developers had any intention of
> making a POSIX sh script when they wrote abuild.
>
> The line that failed with "bad substitution" is:
>
> if [ ! -f
>
"$REPODEST/$repo/${subpkgarch/noarch/$CARCH}/$subpkgname-$pkgver-r$pkgrel.apk"
> ]; then
>
> This is a blatant bashism, but it's supported in BusyBox (and zsh), so
> there is no harm in using it for them.
>
> Additionally, since they require BusyBox, they specifically told me
> two years ago that making it #!/bin/sh on Adélie was unsupported and
> that I can keep the pieces when it breaks.
Then it sounds very much like if you've made it work with bash
reliably, and it uses bashisms that just happen to be supported by
their implementation of ash, that the sensible choice is indeed to
make abuild depend on bash specifically.
> Let me remind everyone that Alpine is *upstream*, not *downstream*.
> They enforce the rules, and we play by them. We aren't the ones who
> tell them to use POSIX, they're the ones that tell us to use a
> bash-like.
If they're telling us to use a bash-like, then we should clearly just
comply and make abuild depend on bash, then :)
Actually, I am interested in fixing the bashism there. abuild is
intended to work with any Almquist shell, but it is true that Alpine
does prefer Busybox ash as it's Almquist shell of choice.
So, patches definitely accepted if somebody wants to work on it.
William
8:05 p.m.
On 02/11/18 14:00, A. Wilcox wrote:
exiv2:
We are tracking 0.26 which is not yet released on their official site
because it includes fixes for big-endian that are irrelevant to Alpine.
I know the maintainers personally and I am fine with maintaining this
myself in system/.
Wrong. It's released in May, and the patch is for 0.26 itself. I meant
0.27. Anyway, I feel since it is a simple patch and it fixes an actual
issue, it should just be upstreamed now. So this is done.
[adelie-integration 687531e2ea] main/exiv2: bump to 0.26, modernise,
mark no tests
4 files changed, 106 insertions(+), 50 deletions(-)
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
1183
days inactive
1185
days old
adelie-devel@lists.adelielinux.org
17 comments
4 participants
participants (4)
-
A. Wilcox -
Horst G. Burkhardt -
Max Rees -
William Pitcock