[adelie-devel]The future of BusyBox in Adélie
by A. Wilcox
Hi all,
Now that we are tightening up all our loose ends and trying to make this
a really solid 1.0 release, I was wondering what we want to do with
BusyBox. This is by far the worst package we ship in the entire distro:
packages$ find . -name '*.patch' | cut -d'/' -f3 | sort | uniq -c
[ ... ]
12 binutils
12 openssl
17 firefox-esr
17 qemu
33 busybox
The way I see it, there are a few options for it:
== Move to user/ ==
There is no reason for it to be in system/; it is not used by any system
dependency, nor is it essential to build or run the Adélie Core system.
Things would basically stay the same. We would continue to be at the
mercy of Alpine's patching, unless someone here really wants to take on
the worst package in packages.git. However, seeing as nobody should be
using it, I don't know that such a thing would be bad.
== Remove ==
Considering the brokenness[1][2][3] of BusyBox, we could remove it from
the repositories entirely. We may be able to compile a static coreutils
for recovery.
== Replace with Toybox ==
Since BusyBox is only packaged for static tools for recovery, we could
replace it with Toybox. While it is missing some functionality, it is
much closer to the standards and what a reasonable user would expect
from a recovery environment.
I'd like to resolve this before BETA2 if possible. Let's discuss!
Best,
--arw
[1]: https://www.mail-archive.com/busybox@busybox.net/msg25157.html
[2]: https://bugs.alpinelinux.org/issues/9279
[3]: https://da.gd/buggybox
--
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 2 months
RFC: devs metapackage
by A. Wilcox
Right now, we have 'lang' to pull in all -lang subpackages, and 'docs'
to pull in all -doc subpackages.
There have been a few people who have asked for a way to "automatically
install all -dev packages".
Therefore, I propose we create a 'devs' or 'dev' metapackage similar to
'docs' and 'lang' that installs all -dev packages that correspond to
packages that are installed on the system.
Thoughts?
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 4 months
RFC: Adding /sbin to user $PATH
by A. Wilcox
Hi all,
Samuel Holland (smaeul on IRC) noted that /sbin and /usr/sbin are
omitted from our default $PATH and therefore things like ip(8) or
lspci(1) don't work as a normal user, nor do they work under sudo.
I originally felt that having the sbin directories in $PATH might be
confusing to new users because there would be a significant number of
utilities added to their tab complete and such. Additionally, they
would not be able to run most of these binaries due to insufficient
permission. However, ip(8) and lspci(1) are very commonly used by users
to debug issues, and it is often requested of them to run these when
they are asking for help.
Therefore, I am proposing that we add "/usr/sbin:/sbin" to the end of
the default Adélie $PATH.
Thoughts?
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 7 months
Blank screen G4 emac 125Ghz
by kelsoo＠riseup.net
Hi
I to have an emac 1.25 7447? with the same issue as Alex McKeever
I tried replying to the tread but when I hit reply it seemed to just
delete my post. You will no doubt receive another 2 versions of this
shortly :-)
I try and answer the same questions you posed Alex
Is this the 1.25 GHz retail model (Radeon 9200) or the 1.25 GHz education
market model (Radeon 9600)?
I think it's a 9200
Are you able to see the GRUB menu?
I could get the grub menu prior to the blank screen
When does the screen turn black?
Mid boot
After the screen turns black, does there appear to be further disk activity?
I believe there was
Are you using Mini-VGA or the built in display?
Built in though I have a mini-vga adaptor
Has this machine ever used something like Screen Spanning Doctor, which
enables extended desktops instead of mirroring in Mac OS X?
Not that I know of
If so, have you tried resetting the NVRAM (which will temporarily disable
the extended desktop patch until applied again)?
Yes after running the adelie ppc full CD and getting the blank screen. :-(
I have a freebsd install on the machine and it boots (or booted) from
open-firmware. When I booted adelie by holding the c key freebsd started
open-firmware. The CD booted and I got a blank screen mid boot but it has
stuck. Rebooting left me with the same blank screen. I tried to boot
open-firmware but got nothing so I press the pmu and rebooted with the
open-firmware keys I got open-firmware then the sad-mac icon and then
freebsd started. It then rebooted it's self and reverted to the black
screen and I can't seem to revive open-firmware again (yet). I hope it's
not bricked :-(
You said “just about any modern Linux distribution”; do older ones work?
Can you provide a list of what does and doesn’t work, so that we may
narrow down kernel versions?
Up to Debian 7.11 work later models install but boot to black screen, even
with video=ofonly I think the was a debian bug about modules that stops
systemd loading but I don't want systemd so never looked that hard.
I also have an othe ppc machines that I could possibly try.
imac G3 333Mhz 256MB
2 Emac G4 1Ghz
G4 800Mhz iirc
G4 867Mhz iirc this maybe a digital audio overclocked
17" imac White Half Sphere G4 1.25 GHz PowerPC 768 MB
20" imac G5 PowerPC 1.8 GHz 2GB
Kelsoo
2 years, 7 months
Update apk-tools immediately! Security vulnerability
by A. Wilcox
A grave security vulnerability has been found in `apk`[1], the package
manager used by Adélie Linux. The vulnerability allows any attacker on
the same network as your computer run malicious code as the superuser,
if you are not using HTTPS repositories /etc/apk/repositories.
This should not affect any standard installation of Adélie Linux, as our
mirrors force HTTPS and our default repositories file uses HTTPS.
However, if you have added your own custom repositories, or replaced
'https' with 'http' for any reason, you are vulnerable. A patch has
been released in apk-tools 2.10.1 and it is critical for you to update
all of your Adélie Linux computers immediately. New ISO and root FS
images for 1.0-BETA1 went live last night.
This vulnerability was discovered in early September by Max Justicz. A
patch was written on 5 September by Alpine Linux developers and released
on 10 September; the vulnerability was disclosed publicly on 13
September. The Adélie Linux team was not notified of this vulnerability
before the public disclosure. This vulnerability was disclosed
independently to Adélie Linux by Luke Dashjr via the public disclosure
by Max Justicz.
We are deeply troubled by the lack of responsible disclosure by Alpine
Linux, and we are actively investigating steps we may take in the future
to mitigate our continued reliance on Alpine.
[1]: https://justi.cz/security/2018/09/13/alpine-apk-rce.html
Best wishes for updating,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 7 months
[adelie-devel]Official release of Adélie Linux 1.0-BETA1
by A. Wilcox
The Adélie Linux Release Engineering Team is pleased to announce the
immediate release of Adélie Linux 1.0-BETA1 for the 32-bit and 64-bit
PowerPC, 32-bit and 64-bit x86, and 64-bit ARM platforms. This release
adds root FS downloads in .TXZ form so that you can try out Adélie in a
chroot with a single tar+xz command.
You can read more from our official release announcement:
https://www.adelielinux.org/announcements/1.0-BETA1.html
Or get right to the good stuff :)
https://distfiles.adelielinux.org/adelie/1.0-beta1/iso/
This release would not have been possible without all of our fantastic
contributors:
A. Wilcox
Kiyoshi Aman
Max Rees
Dan Theisen
Laurent Bercot
Horst G. Burkhardt
Lee Starnes
William Pitcock
Marek Benc
Brandon Bergren
Seamus Caveney
Rich Felker
Samuel Holland
Eliabeth Myers
In addition, we would like to personally thank musl libc, KDE, and
Repology for their dedication to correctness and making it easy to bring
our fixes upstream. Thank you!
Best to you and yours, and happy hacking,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 8 months
abuildd design considerations
by Max Rees
Hello all,
During some brief free time today I was thinking about how to go about
implementing some of the upcoming features that I plan to add to abuildd in
the next few weeks. Specifically, I am concerned about the handling of
dependencies.
My current proposal is that each new push to a branch ("push event") or update
to a merge request ("MR event") will create a new "job". The job can be
composed of one or more "tasks" which would be building a package on a
specific architecture. As an example, if a push event is received that changed
two APKBUILDs, a job would be added that would include tasks to build those
two packages on all applicable architectures.
I do not expect there to be any problems with handling dependencies between
tasks in a single job (intra-job dependencies). However, dependencies between
multiple jobs (inter-job dependencies) is more complex, at least the way I see
it now.
For push events, it could be easy to handle inter-job dependencies as long as
the artifacts for each job are collected and kept for that branch. It is MR
events that I am more concerned about.
I believe that as it stands right now (I cannot check it at the moment), my
abuildd-enqueue implementation does not distinguish between new commits added
to an existing MR, a force push over an existing MR, or a completely new MR.
Thus all added/changed (NB: *not* deleted) packages for a MR would be rebuilt
on each change to the MR.
I think it is possible to implement it such that we keep state for each MR and
thus only perform builds as necessary, but I'd like to hear all of your
thoughts on this.
If there are other questions or considerations you'd like to make, please let
me know. Another feature I thought of during the same period today is that it
should be possible to prioritize jobs based on type (push, MR) and branch, if
applicable. Things such as being able to skip a build that would be caused by a
particular commit (I have seen things like having "[ci-skip]" in the commit
title before) are more difficult in the present implementation, but I'm sure it
can be done at some point.
Max
2 years, 8 months
1.0-BETA1 release criteria
by A. Wilcox
Hi all,
We probably need to push back or remove some release criteria from BETA1
to ship it in time (we agreed via IRC to push back to 8 September).
* Branding
I think this can be pushed back safely to b2.
* Documentation
The User's Guide and Administrator's Guide are more important, but
should probably be pushed back to b2 because they aren't even started
yet beyond very rough outlines. I am going to try and write more of the
Developer's Guide tomorrow, with the hope of at least finishing chapters
4 and 5.
* gcompat
I don't think Mathematica nor Steam are going to make 1.0. Should we
punt this to 1.5? 2.0?
* KDE
Cantor (including Qalculate and R), K3b, and Calligra are left to
package that I can see. We may be able to make this before the 8th.
Not sure.
* VirtualBox
Doesn't seem to build with musl at all. Likely won't make 1.0; is this
highly desired? Would anyone else be willing to put in the effort to
port this?
* Missing list
This goes in to the version freeze; are we having a package freeze too?
If so, our missing list is frozen and we will not ship with any of the
packages left on it. If not, this can probably be shifted to b2.
* Parcel
I was thinking that we could start with a local Repology instance that
has each architecture listed as a family. That way, we can easily see
what is going on and what architectures have issues etc. It's very
close to what I envisioned the first version of Parcel looking like,
actually. I still want to write our own for the ability for users to
submit their package ideas to us.
* Register
Nobody is working on this. It looks like we may not ship this for 1.0.
Does anyone want to take this?
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
2 years, 8 months