[DNG] make-rc: A parallel (as in make(1)) alternative to sysv-rc

[Alejandro Colomar (man-pages) via Dng]

Hi all,

Most of you I added you to this email because I found you on the 
maintainers list for the Debian sysv-rc package (now dead for a long time).
I also CCd Devuan, since I hope you'll be interested in this little 
project of mine.
I also CCd linux-man@, since there's not many people listening there, 
and not much traffic these days so I hope you won't be angry for this 
little bit of spam; and I hope some good guys reading that list may have 
some comments on this.  Sorry again for the bit of spam.
I also CCd help-make@.  I (ab)used your software in a way that it was 
never designed to; not sorry for that; I'll say it was the original Unix 
authors' fault for designing such (ab)usable tools :).  Maybe you're 
interested in this thread, maybe you don't care, but I'll CC you in case 
some of you may be interested in this.

And finally, Randy, as you asked, I'll CC you for news on this.
Anyone not interested in follow-ups, please email me, and I'll try to 
remove from CC.


So, last friday (yes, that's New Year's Eve), I was reading something, 
and got this idea... the main valid claim for systemd is that it blows 
away competition in terms of performance?  Full parallelization?  Knows 
about dependencies?  I don't know too much of systems; I know some basic 
stuff, but I'm mostly a C programmer, so I don't know init(1)... okay. 
But since I program, I sure know the good ol' make(1).  It's old, and 
it's good at fully parallelizing _everything_.  Dependencies? sure; 
fast? sure; parallel? sure; simple? sure; a bit bloated? GNU make maybe, 
especially for init(1), but far from systemd(1):


$ ls -lh $(realpath $(which systemd make bash sh 2>/dev/null))
-rwxr-xr-x 1 root root 1.2M Dec 15 00:43 /usr/bin/bash
-rwxr-xr-x 1 root root 123K Nov  3 11:51 /usr/bin/dash
-rwxr-xr-x 1 root root 235K Apr 10  2021 /usr/bin/make
-rwxr-xr-x 1 root root 1.8M Nov 19 21:11 /usr/lib/systemd/systemd

So, if the problem is that the rc scripts don't run parallel and don't 
know about exact dependencies from each-other, let's rewrite that part 
and only that part of the system with make(1); that was the idea.  Don't 
touch init, don't touch the scripts themselves... only the part that 
decides on which order to run them.  That's the idea.



I decided to start with a clean install of Devuan (since I'm a Debian 
user, and I'm used to it; it might have been easier to start with a 
smaller system, but I might have found other issues in the middle;  I 
know that the only difference in Devuan is sysvinit, which is what I 
want).  The install has XFCE and sysvinit as options.  I wanted the 
system to have GUI, so that if I can boot XFCE with it, I can boot 
anything (except maybe for the bad boy, GNOME, but I don't even like it).


I wrote a couple of scripts to port the existing rc system to my 
make-based rc system.  The script didn't touch the old one, in case I 
needed it to boot if I screwed something, of course.  One script creates 
the makefiles without declaring the dependencies between them, and then 
another makefile creates the dependencies to match the current boot 
order (allowing for the same level of parallelization that the current 
semi-parallel rc script uses).  From there, one could analyze the 
dependencies to remove some that are incorrect, and make it faster, but 
since I don't know the real dependencies, I didn't want to break stuff.


So, here go the scripts:

== script1_basicmk.sh 
#!/bin/bash

find /etc/rc[0123456S].d/[KS]* \
|sed s,/etc/rc..d/...,, \
|sort \
|uniq \
|while read x; do\
mk="/etc/rc.mk.d/$x.mk";

test -e $mk \
&& continue;

>$mk cat /dev/null \
|sed s,/etc/rc,, \
|sed s,.d/S.*,, \
|sort \
|tac \
|while read n; do \
sed -i "/: S$x$/s/^/$n /" $mk;
done;

sed -i "s/ *:/:/" $mk;
sed -i "/^:/d"$mk;
done;
=

= script2_deps.sh ===
#!/bin/bash

find /etc/rc.mk.d/*.mk \
|sed s,/etc/rc.mk.d/,, \
|sed s,.mk$,, \
|sort \
|while read x; do\
mk="/etc/rc.mk.d/$x.mk";

for n in 0 1 2 3 4 5 6 S; do \
K=$(find /etc/rc$n.d/K??$x 2>/dev/null \
|grep -o /K.. \
|sed s,/K0*,,);
test -z "$K" || test $K -eq 1 \
&& continue;
k=$(printf %02d $(($K - 1)));

find /etc/rc$n.d/K$k* \
|sed s,/etc/rc$n.d/K$k,,;
done \
|sort \
|uniq \
|while read dep; do \
echo K$dep;
done \
|xargs echo \
|while read Kdeps; do
  

Re: [DNG] merged /usr breakage

[aitor]

Hi Karl,

On 4/1/22 22:17, k...@aspodata.se wrote:

the problem is that the lib is on a
filesystem that isn't available at kernel to init handover time.


Did you try something like this:

copy_exec /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0

in a hook located at/usr/share/initramfs-tools, in order to include it in the initrd? Sorry, 
but i'm a bit unaware of the thread...


Cheers,

Aitor.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 04/01/2022 à 23:38, Hendrik Boom a écrit :

On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:

There is no utility in splitting the OS in several partitions.

Might it make sense to have /usr mounted readonly except when upgradng
or installing paackages?

    What could you fear which makes you want to keep /usr readonly. If 
your OS is broken, you can reinstall it in a few hours. And the most 
likely thing which can break it is the package manager itself.


    Recently it happenned to me on Chimaera that some packages were 
broken, because of incompatible versions between backports and stable. I 
eventually solved the problem with the only help of Synaptic, and 
finally eliminated backports from sources.list. If necessary, I would 
just have re-installed Devuan without backports from the beginning.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Hendrik Boom]

On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:
> There is no utility in splitting the OS in several partitions.

Might it make sense to have /usr mounted readonly except when upgradng 
or installing paackages?

-- hendrik

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Bob Proulx via Dng]

Antoine via Dng wrote:
> Steve Litt wrote:
> > With my /bin/sh (which I believe is dash) I had to change:
> > 
> > function whatever {
> > 
> > to
> > 
> > whatever() {
> > 
> > on all three function declarations.
> 
> Yes, now that you mention it, that tends to vary between shells. I should
> have included them.

Portable shell use would be "whatever() {" which I wish to encourage
by saying that here.  Please use only that form for /bin/sh scripts. :-)

The "function" keyword was introduced by ksh.  This syntax is also
supported by bash and zsh but not by other shells.  When "function" is
used then the #! line must be /bin/ksh, /bin/bash, or /bin/zsh.

The ksh book refers to the other format as compatible "with recent
versions of the Bourne shell" (which I find funny now) because as we
know the original Bourne shell did not support functions at all.  The
book also reminds us that "{" and "}" are reserved words.  Meaning
that they must be separated from other tokens by whitespace in order
to be recognized.  They form a shell compound-list of commands.

Bob


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Antoine:
> On Monday,  3 January at 18:25, k...@aspodata.se wrote:
...
> >$ ldd /sbin/init | grep /usr
> >libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
> > (0x7f737ba28000)
...
> Maybe your /etc/ld.so.cache is misconfigured?
...

What makes you believe that ?

ld.so.cache is just fine, the problem is that the lib is on a 
filesystem that isn't available at kernel to init handover time.
If I move over the lib to the root fs, then there is no problem
other than that apt/dpkg et al. don't know about it.

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Antoine via Dng]

On Monday,  3 January at 18:25, k...@aspodata.se wrote:

The first one gives me an unbootable system
$ ldd /sbin/init | grep /usr
   libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
(0x7f737ba28000)

fortunately /bin/bash didn't depend on /usr so I could boot with
init=/bin/bash, but there is more breakage:

$ ldd /bin/mount | grep /usr
   libmount.so.1 => /usr/lib/x86_64-linux-gnu/libmount.so.1 
(0x7f5bc9b06000)
   libblkid.so.1 => /usr/lib/x86_64-linux-gnu/libblkid.so.1 
(0x7f5bc98f)
   libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 
(0x7f5bc982c000)

$ dpkg -l | grep sysvinit-core
ii  sysvinit-core2.96-7+devuan1 
amd64System-V-like init
$ dpkg -l | grep mount
ii  libmount1:amd64  2.36.1-8+devuan1   
amd64device mounting library
ii  mount2.36.1-8+devuan1   
amd64tools for mounting and manipulating filesystems

Soo, what can I do to help with that ?


Maybe your /etc/ld.so.cache is misconfigured?
Here's a little trick i discovered when I was learning to build initramfs 
files:


1. add the new /lib/ directories to /etc/ld.so.conf
2. run ldconfig to rebuild ld.so.cache
3. profit!

Hope this helps.

- Antoine

--
Any sufficiently advanced technology is indistinguishable from magic.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] inferno and FlyingTux

[Enrico Weigelt, metux IT consult]

On 08.08.21 22:01, Steve Litt wrote:

Hendrik Boom said on Sat, 7 Aug 2021 17:20:58 -0400



So putting it on top of Android and then using Infirno apps might well
be a way to alleviate some of the Android non-interoperability,

-- hendrik


If all we're talking about is making apps for phones and tablets, why
not Kivy?

https://kivy.org/


FT's goal is not to develop apps, but build a new mobile OS, that scales
from small handhelds to desktops and servers.


--mtx






SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Announce: FlyingTux project

[Enrico Weigelt, metux IT consult]

On 06.08.21 22:19, Steve Litt wrote:

Hi,


If I've got this right, FlyingTux is or creates containers hosting
applications somebody develops. Do I have that right so far?


correct.


What language(s) are best for building a FlyingTux container?


doesn't quite matter, as long as this works well with Linux :p
Actually, FT is trying to reuse existing code (and packages) as much
as possible.

FT itself (the runtime) is implemented in python, since I found it
the most easiest language to start off.


Will the containers run on Linux, Windows, Mac and BSD also?


For now just Linux, unless you find a way for getting docker and
Linux containers running on other platforms - including features like
mounting host directories, fd passing, ...


Does FlyingTux have a quick-programming facility for input screens as
well as data access?


sorry, don't know what you mean exactly. can you explain more in detail?


--mtx



Thanks,

SteveT


Enrico Weigelt, metux IT consult said on Fri, 30 Jul 2021 14:49:32 +0200


Hello folks,


maybe a bit offtopic, but allow me to announce the FlyingTux project:

It's an build/runtime infrastructure for running desktop and mobile
applications in containers and build an entirely container-based
mobile OS based on it.

The primary motivation is my long frustration about the monstreaus and
practically unmaintainable Android, which also still lacks lots of
common management abilities we know from the GNU/Linux world.

In some ways, FT can be seen as an conceptional combination of
containers (docker, k8s, etc) and apps (android, etc). One major
difference is that also the app images are based on some defined
distro base (for start, just alpine, others to follow later) and the
images are created on the host, based on host specific settings like
hw setups (eg. automatically deploys the right mesa drivers). In future
steps some packages of the app distro base (called 'osbase# here) will
be replaced or customized, in order to provide better integration with
the ecosystem and strip unneeded stuff.

Another key difference is moving common functionality (eg. various
data sources, communication protocols, ...) out of the individual
apps into generic services - and the binding between individual apps
and actual services instances can be customized by the user (e.g. one
can bind some apps to fake gps instead of the real one, separate
address books or user directories, etc, etc).

Here's a more detailed description:

https://github.com/metux/flyingtux/blob/master/README


Note that for now its very experimental and fast changing. Don't expect
anything field-ready yet. But it's already good enought to isolate some
common desktop apps like gimp, chrome, etc.


--mtx

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Announce: FlyingTux project

[Enrico Weigelt, metux IT consult]

On 06.08.21 22:16, Steve Litt wrote:

Hendrik Boom said on Fri, 6 Aug 2021 13:40:32 -0400


On Fri, Jul 30, 2021 at 02:49:32PM +0200, Enrico Weigelt, metux IT
consult wrote:

Hello folks,
   


Have a look at inferno. http://inferno-os.org/

-- hendrik


What's the relationship between Inferno and FlyingTux?


None at all.

I'm planning to use 9P and other plan9'ish concepts for service
interfaces in the future, but it still will be a real Linux.

--mtx




SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] inferno and FlyingTux

[Enrico Weigelt, metux IT consult]

On 07.08.21 23:20, Hendrik Boom wrote:


Inferno is the system I would have preferred Google used instead of
Android.


Ah, okay, that was a bit confusing ;-)

Actually, I'd like to see a combination of both Linux and Plan9
concepts - using the Linux kernel for all the HW stuff but extend
it to support Plan9'ish approaches (eg. mount-ns).

Much of it is already there, but still need to find a practical way
for having private mount namespaces as unprivileged user (w/o userns).
Already did some experimental implementations of /dev/cap*, srvfs, etc,
so we could design programs pretty much the plan9 way, but that's still
a longer way to go.


It isn't a candidate for FlyingTux virtualisation.
But it might be able to alleviate some of the frustrations
inherent in Android.


Not really, since the most problematic point with those devices is
kernel/driver support. When starting over with a completely new OS,
we'd have to start afresh with all these (usually completely
undocumented) devices. Using Linux as kernel IMHO still was the
best choice - but their userland is a crappy monster


I get it that there are better ways to have orovided the services Android
provides.  But creating a better system than Android using containers and
virtual machines is not going to eliminate the horrible constraints that
Google has foisted on the computing public by their Android system.
Without copatibility with Android and access to the Android app market,
it will not replace Android, not will it make it easy for those wishing
to escape Android still be interoperable with friends wo do use Android.


I don't intend to replace Android anytime soon - I'm trying to create a
Linux distro for mobile devices. Mobile here doesn't just refer to the
device itself, but also the applications (eg. easily moving around app
instances between devices, etc).

For now, FT is just a research project, unless many people join in, so
we can build something practically usable in the field.


And it does networking.  Just about every resource is modelled as a file,
and the file system naturally extends to other networked systems.


Yes, Plan9 already does this. For typical (existing) applications, I
don't see this a major issue when using containers anyways.
(don't have the resources to rewrite everything, eventhough I'd really
like to enjoy that).


So putting it on top of Android and then using Infirno apps might well
be a way to alleviate some of the Android non-interoperability,


But that wouldn't solve the major issues of Android - a huge, pretty 
unmaintainable and untrustworthy monster.



--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..another viable basis idea for Devuan as a hypervisor?, was: Announce: FlyingTux project

[Enrico Weigelt, metux IT consult]

On 05.08.21 12:55, Arnt Karlsen wrote:

Hi folks,


sorry for being too busy for replying so long ...


It's an build/runtime infrastructure for running desktop and mobile
applications in containers and build an entirely container-based
mobile OS based on it.


..I like the https://www.qubes-os.org/ approach, but not
their use of systemd nor of rpm.
Do we do something similar here?


the only similarity between the two is that applications are sandboxed
(and it linux-based, of course).

FT uses containers, instead of VMs.

The general idea is making application containers as small as possible.
For that, we don't use fixed images (like class docker), but deploy
from package management, just the actually needed packages (eg. don't
wanna have dozens of useless gl drivers).


The primary motivation is my long frustration about the monstreaus and
practically unmaintainable Android, which also still lacks lots of
common management abilities we know from the GNU/Linux world.


.."wonder why Google designed it that way." ;oD


maybe for making it as complicated as possible, so opensource looses
its primary value ? ;-P


In some ways, FT can be seen as an conceptional combination of
containers (docker, k8s, etc) and apps (android, etc). One major
difference is that also the app images are based on some defined
distro base (for start, just alpine, others to follow later) and the
images are created on the host, based on host specific settings like
hw setups (eg. automatically deploys the right mesa drivers). In
future steps some packages of the app distro base (called 'osbase#
here) will be replaced or customized, in order to provide better
integration with the ecosystem and strip unneeded stuff.


..which means an early step will be trim down the basic (net-install?)
images we have, as far down as possible, and build app, vm etc images
upon those stripped down base images.


actually, a bit more low level: we use a (almost) standard distro and
install just the really needed packages.

For now, just implemented apk backend, since alpine is the smallest
ready-to-use package based distro I'm aware of. (haven't tried, but
deb probably would be much bigger).


I guess we also want a bare bare metal hypervisor of some sort. ;o)


That's not planned (yet). I've got several use cases (or installation
types) in mind:

a) ontop of classic linux distro: use it similar to snap etc
b) as a pure os for larger devices
c) as a pure os for small mobile devies

For case b we'd have a really minimal base distro, just what's needed
to bring up a console or graphical display.

For case c we'd have a device-customized base distro (at least we'd
need customized bootloader and kernel)


..this means we can set up e.g. chromium in throw-away-after-use
containers?  Or stick new stuff with lib conflicts in containers?
Etc?


Yes, that's one of the use cases (category a).


..I see no .deb package?  Pretty soon we'll need debug packages
to shake out bugs.


It's not packaged yet - too early, needs more time to mature bevor
packaging makes sense. Just clone the git repo and run it from there.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Pipewire and PulseAudio: apulse & firefox

[Antoine via Dng]

On Wednesday, 22 December at 07:08, Steve Litt wrote:

(...)
PDC (Pretty Darn Cool)!


Thank you!



With my /bin/sh (which I believe is dash) I had to change:

function whatever {

to

whatever() {

on all three function declarations.


Yes, now that you mention it, that tends to vary between shells. I should 
have included them.




In the rest of this email, I'm referring to your program as jacketc to
save myself some keystrokes.

On my computer, Xterm normally has a nice 14 point font that I set in
.Xdefaults. But in jacketc, the fact that you give it a name
(jackinthebox) makes the font go to about 5 point, which is totally
useless for my eyes. Do I need to make some special adjustment in
.Xdefaults?


I don't know much about .Xdefaults (mine just has some yeahconsole 
leftovers), but xterm should have a parameter to define the font (and its 
size), maybe something like -fc?


As a temporary workaround, you can ctrl-rightclick anywhere in the window to 
get a menu, allowing you to change the font size.




I'm used to these kinds of terminals not having window decorations. Any
way to accomplish that?


That would depend on your window manager. I use Fluxbox, so I have the 
following lines in $HOME/.fluxbox/apps:


[app] (name=jackinthebox) {1}
  [Deco] {NONE}
[end]

YWMMV [ Your Window Manager May Vary :^D ]



On my machine, jacketc doesn't shift focus to the newly appeared
window. Is there a reason why not?


Huh, that's odd. The "windowfocus" command should do that, with "windowraise" 
thrown in for good measure.


YWMMV, again?



In any window manager enabling you to execute arbitrary commands with a
keystroke, you can just set that keystroke to run jacketc.


Sounds convenient if you have one of those window managers :^)



Thanks for introducing me to xdotool. I'll be using that a lot from now
on. Just another reason I'm going to wait as long as possible to switch
to Wayland.

I do have one criticism of jacketc: Lennart Poettering wouldn't approve
of it.


It's probably best if I not voice my opinion on the subject (not, I suspect, 
that many here would disagree with me).




:-)

SteveT


Sorry for not answering earlier (holidays and all that, y'know). In any case, 
thank you for your feedback; always appreciated.


- Antoine

--
To ask is allowed. To answer is a courtesy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

Le 04/01/2022 à 18:48, k...@aspodata.se a écrit :

Didier:

The simplest way to kick off problms with /usr merge is to *not*
make /usr a mountpoint.

Perhaps, but why break working systems, especially when they are
3h car ride from home and all in differnt locations.
That is just rude.


There is no utility in splitting the OS in several partitions.

...

My systems, my rules.

    I totally agree, "your system, your rules" (~: . And I fully agree 
that forcing the merge is at least impolite. I was just trying to 
de-dramatize the question. When some change prevents you to follow "your 
rules", the practical response is not to rant after the change (the 
merge) but first question the said rules.


--     Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Didier:
> The simplest way to kick off problms with /usr merge is to *not* 
> make /usr a mountpoint.

Perhaps, but why break working systems, especially when they are
3h car ride from home and all in differnt locations.
That is just rude.

> There is no utility in splitting the OS in several partitions.
...

My systems, my rules.

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] busybox init

[karl]

Steve Litt:
...
> If busybox init does not require daemons to self-background, I'd be
> even more enthusiastic.
...

Busybox init has its inittab, mostly for gettys, and a boot script,
that is your options.

Having daemons not-backgrounded in the rcS script isn't practical
and I don't think that is what you want.

You can have the daemon in the inittab like:

$ grep ssh /etc/inittab
tty2::respawn:/usr/sbin/sshd -d

and that works perfectly well, you can ssh to the box but only one
user at time, that is a sshd -d limit. Log output is printed on tty2.
My guess is that you don't want that either.

Why don't you start a process monitor, either at the end of the rcS 
script or from the inittab. So, in effect let init handle
/etc/rcS.d/S* and the gettys, and the process monitor /etc/rc2.d/S*.

Regards,
/Karl Hammar


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] busybox init

[karl]

Karl:
>  I have used busybox init for a while. It differs from sysvinit
> by not having runlevels, except perhaps on and off.
...
> One could possible (not tested) mimic sysvinit bootup by having
>  for i in /etc/rc2.d/S*; do $i start; done
> in the rcS file or if you prefer you can have your own handwritten
> and tuned script there.

  With this temporary fix:
mv /usr/lib/x86_64-linux-gnu/libpcre2-* /lib/x86_64-linux-gnu/
mv /usr/lib/x86_64-linux-gnu/libpcre2-* /lib/x86_64-linux-gnu/
mv /usr/lib/x86_64-linux-gnu/libblkid.so.1* /lib/x86_64-linux-gnu/
mv /usr/lib/x86_64-linux-gnu/libmount.so.1* /lib/x86_64-linux-gnu/
mv /usr/lib/x86_64-linux-gnu/uui /lib/x86_64-linux-gnu/
ldconfig

  static busybox compiled from git and installed in /busybox
  and theese files:
# cat inittab
::sysinit:/etc/rcS

::respawn:/sbin/agetty --noclear 38400 tty1 linux
tty2::respawn:/sbin/agetty --noclear 38400 tty2 linux
tty3::respawn:/sbin/agetty --noclear 38400 tty3 linux
tty4::respawn:/sbin/agetty --noclear 38400 tty4 linux
tty5::respawn:/sbin/agetty --noclear 38400 tty5 linux
tty6::respawn:/sbin/agetty --noclear 38400 tty6 linux

::ctrlaltdel:/busybox/poweroff
::shutdown:/busybox/swapoff -a
::shutdown:/busybox/umount -a -r
::restart:/busybox/init
# cat rcS
for i in /etc/rcS.d/S*
do
  $i start
done

for i in /etc/rc2.d/S*
do
  $i start
done

my test chimaera system boots just fine with init=/busybox/init.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Curtis Maurand via Dng]

> On Jan 4, 2022, at 11:10 AM, Didier Kryn  wrote:
> 
> The simplest way to kick off problms with /usr merge is to *not* make 
> /usr a mountpoint. There is no utility in splitting the OS in several 
> partitions. This wouldn't help you recover the OS if one partition is broken 
> since the package manager installs/deinstalls files not only on /usr, but 
> also /, /etc, /boot, /var. Splitting is even discouraged if you use a 
> filesystem with snapshots like btrfs (whih isn't my case). The only thing 
> which may (and should) be on a different disk (not partition) is the precious 
> user data, ie /home.
> 
> -- Didier

I simply save snapshots not only locally, but an external snapshots locally on 
a separate drive and to a NAS.

If my IQ were higher than the number of terabytes I have on the NAS, I would  
have the NAS in a separate location.

—Curtis

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Didier Kryn]

    The simplest way to kick off problms with /usr merge is to *not* 
make /usr a mountpoint. There is no utility in splitting the OS in 
several partitions. This wouldn't help you recover the OS if one 
partition is broken since the package manager installs/deinstalls files 
not only on /usr, but also /, /etc, /boot, /var. Splitting is even 
discouraged if you use a filesystem with snapshots like btrfs (whih 
isn't my case). The only thing which may (and should) be on a different 
disk (not partition) is the precious user data, ie /home.


--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Ralph:
> On Mon,  3 Jan 2022 18:25:12 +0100 (CET)
> k...@aspodata.se wrote:
> >  The first one gives me an unbootable system
> > $ ldd /sbin/init | grep /usr
> > libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> > (0x7f737ba28000)
> > 
> >  fortunately /bin/bash didn't depend on /usr so I could boot with
> >  init=/bin/bash, but there is more breakage:
...
> No solution, but it looks like "the culprit" for this is that the
> libselinux1 package changed in between beowulf (buster) and chimaera
> (bullseye) from depending on libpcre3 to depending on libcre2-8-0.

libpcre3 was the old, and libcre2 the new lib, with -8 is for working on
8bit walues, also available is -16 and -32 (if you have wide 
characters).

> The former, libpcre3, installs its libraries in both /lib and /usr/lib
> (different), in both its beowulf and chimaera versions,  whereas
> libcre2-8-0 installs only in /usr/lib.

Yes, so it is:

/lib/x86_64-linux-gnu/libpcre.so.3.13.3
/usr/lib/x86_64-linux-gnu/libpcreposix.so.3.13.3
 vs.
/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0.10.1

> I haven't reviewed the source for comment around that dependency
> change.

Apart from the strange numbering (which is upstreams fault),
the dependancy migration seems sane.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Question about the text editor named medit.

[aitor]

Hi,

On 4/1/22 13:47, Ralph Ronnquist via Dng wrote:

.. gratuitous result:

https://askubuntu.com/questions/1372529/is-it-possible-to-get-latest-version-of-medit-aka-mooedit-for-ubuntu-20-04-lts

The tarball was available; the rest is for ubuntu of course


The last packaging was in oldstable:

https://qa.debian.org/developer.php?login=josgalo%40gmail.com 



Looking at the control file, medit disappeared from chimaera repositories 
because of the deprecation of python-gtk2.
That is for the same reason that wicd did. So, there is a chance that packaging 
will return in testing or backports,
as happened in the case of wicd.

Edward: geany might be a good choice for you in the meantime.

Cheers,

Aitor.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Question about the text editor named medit.

[Ralph Ronnquist via Dng]

On Tue, 4 Jan 2022 13:18:07 +0100
Edward Bartolo via Dng  wrote:

> Dear All,
> 
> Upgrading to chimeara removed medit, a text editor I used for writing
> code and any other plain text document. I could not install it and it
> seems it has been removed from the repository. Searching online for a
> recently updated source tarball, I did not find any. It seems it has
> been abandoned by its developer/s.
> 
> Thanks for your replies.

.. gratuitous result:

https://askubuntu.com/questions/1372529/is-it-possible-to-get-latest-version-of-medit-aka-mooedit-for-ubuntu-20-04-lts

The tarball was available; the rest is for ubuntu of course

Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Question about the text editor named medit.

[Antony Stone]

On Tuesday 04 January 2022 at 13:18:07, Edward Bartolo via Dng wrote:

> Dear All,
> 
> Upgrading to chimeara removed medit, a text editor I used for writing
> code and any other plain text document. I could not install it and it
> seems it has been removed from the repository. Searching online for a
> recently updated source tarball, I did not find any. It seems it has
> been abandoned by its developer/s.

I believe you are correct.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939531

Antony.

-- 
Archaeologists have found a previously-unknown dinosaur which seems to have 
had a very large vocabulary.  They've named it The Saurus.

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Question about the text editor named medit.

[Edward Bartolo via Dng]

Dear All,

Upgrading to chimeara removed medit, a text editor I used for writing
code and any other plain text document. I could not install it and it
seems it has been removed from the repository. Searching online for a
recently updated source tarball, I did not find any. It seems it has
been abandoned by its developer/s.

Thanks for your replies.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[Ralph Ronnquist via Dng]

On Mon,  3 Jan 2022 18:25:12 +0100 (CET)
k...@aspodata.se wrote:

>  The first one gives me an unbootable system
> $ ldd /sbin/init | grep /usr
> libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> (0x7f737ba28000)
> 
>  fortunately /bin/bash didn't depend on /usr so I could boot with
>  init=/bin/bash, but there is more breakage:
> 
> $ ldd /bin/mount | grep /usr
> libmount.so.1 => /usr/lib/x86_64-linux-gnu/libmount.so.1
> (0x7f5bc9b06000) libblkid.so.1 =>
> /usr/lib/x86_64-linux-gnu/libblkid.so.1 (0x7f5bc98f)
> libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
> (0x7f5bc982c000)
> 
> $ dpkg -l | grep sysvinit-core
> ii  sysvinit-core2.96-7+devuan1
>   amd64System-V-like init $ dpkg -l | grep mount
> ii  libmount1:amd64  2.36.1-8+devuan1
>   amd64device mounting library ii  mount
>   2.36.1-8+devuan1   amd64
> tools for mounting and manipulating filesystems
> 

No solution, but it looks like "the culprit" for this is that the
libselinux1 package changed in between beowulf (buster) and chimaera
(bullseye) from depending on libpcre3 to depending on libcre2-8-0.

The former, libpcre3, installs its libraries in both /lib and /usr/lib
(different), in both its beowulf and chimaera versions,  whereas
libcre2-8-0 installs only in /usr/lib.

I haven't reviewed the source for comment around that dependency
change.

Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] busybox init

[karl]

Curtis Maurand:
...
> I was reading the “comment on systemd” article.  the last two sview
> and svcpage could be aliases to those shell scripts rewritten to
> take cli arguments in your .bashrc.

Whats wrong with
 grep named /var/log/messages | less
and similar ?

///

Don't cc me, I'm on the list.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] merged /usr breakage

[karl]

Steve Litt:
> k...@aspodata.se said on Tue,  4 Jan 2022 00:08:01 +0100 (CET)
...
> >busybox can replace the mount command, but there is no fsck.* in
> >busybox.
> 
> Rather than fighting the mostly political fight of usr-merge,

If it makes systems unbootable it isn't a "political" fight.

> my first
> thought would be to make a whole new directory on the root partition.
...
> I'd probably call it /bb . Put all the static executables
> needed in early boot there. If there are a lot, it could have
> subdirectories,

We already have /bin and /sbin, there is no need to create a new one.

> and a bb.d subdirectory with scripts to be performed in
> order.

We already have one, /etc/rcS.d, which serves booting.

///

If you seriously want new directories for booting, somewhere
in /boot is more appropriate, it could possible replace initrd.

Regards,
/Karl Hammar

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] busybox init

[Curtis Maurand via Dng]

> On Jan 3, 2022, at 6:08 PM, k...@aspodata.se wrote:
> 
> Didier Kryn:
>>> Le 03/01/2022 à 21:27, tito via Dng a écrit :
>>> On Mon,  3 Jan 2022 18:45:28 +0100 (CET)
>>> k...@aspodata.se wrote:
> ...
 The sysinit thing is a how you start the system, it's just
 one script /etc/init.d/rcS (or where you prefer to place it).
 
 One could possible (not tested) mimic sysvinit bootup by having
  for i in /etc/rc2.d/S*; do $i start; done
 in the rcS file or if you prefer you can have your own handwritten
 and tuned script there.
> 
> If you have /usr on a separate partition...
> 
> This didn't work:
> for i in /etc/rcS.d/S*; do $i start; done
> fsck.* and mount has dep. into /usr
> 
> Manually mounting with busybox/mount works, but
> there is no fsck.ext4 in busybox.
> After mountall /usr is available, so the rest did work and
> so did
> for i in /etc/rc2.d/S*; do $i start; done
> 
> ...
>>> I would build a static compiled busybox binary with:
> 
>  Yes like:
> git clone git://busybox.net/busybox.git
> cd busybox
> make defconfig
> make menuconfig # I wanted static busybox binary
> make
> mkdir /busybox
> cp busybox /busybox
> cd /busybox
> ./busybox --install .
> 
>>> init
>>> a shell
>>> reboot, shutdown
>>> swapon/swapoff
>>> mount, umount
>>> (start-stop-daemon)
>>> (getty, login)
>> AFAIR you would also need cttyhack, setsid and a few others I've 
>> forgotten if you want to be able to debug it.
> ...
> 
> cttyhack and setsid is in busybox upstream.
> 
> Regards,
> /Karl Hammar
> 
> __

I was reading the “comment on systemd” article.  the last two sview and svcpage 
could be aliases to those shell scripts rewritten to take cli arguments in your 
.bashrc.

just saying.

—Curtis 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng