Re: [DNG] vdev packaging effort ( was: state of what's working, for modern desktop usage)

[aitor_czr]

Hi all,

On 02/10/2016 03:00 PM, aitor_czr wrote:

El 10/02/16 a las 13:00, shraptor  escribió:

I think Aitor wrote a while ago about creating a vdev package?
Aitor could you give an update on that effort?


best regards

Scooby


Hups!

:)


I just uploaded the most recent packaging of VDEV:

deb http://gnuinos.org/unsystemd jessie main
deb-src http://gnuinos.org/unsystemd jessie main

Here you are the link:

gnuinos.org/unsystemd

Some things still remain: for example, udev2vdev and the initramfs 
scripts (getinitramfs and mkinitramfs).


Cheers,

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

Re: [DNG] vdev packaging effort ( was: state of what's, working for modern desktop usage)

[aitor_czr]

On 02/29/16 20:30, shraptor  wrote:

But when I get to slim-login manager I get no keyboard.


This happened to me trying to build a Devuan_Rpi2.img (Raspberry Pi 2) : 
exim4 works, but the keyboard is not detected and i can't access to the 
prompt. I tried with a couple of kernels: Devuan's armmp, and Raspbian's 
trunk-rpi2.


I will continue testing...

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

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[Rainer Weikusat]

Didier Kryn  writes:

[...]

> A few releases ago, intoducing a new init script in /etc/init.d,
> and the corresponding links in rc?.d has become a little more
> complicated, because the comments at the head of the script now
> consitute a meta-language describing the interdependencies of these
> scripts. AFAIR, after copying the script in /etc/init.d, the admin
> should invoke update-rc.d in some way to do the job.

update-rc.d (which used to be the tool for creating a set of 'default'
start/stop links) has been extended to deal with the other situation,
too, but provided an init.d script contains a valid set of 'LSB
headers', eg, from /etc/init.d/udev,

### BEGIN INIT INFO
# Provides:  udev
# Required-Start:mountkernfs 
# Required-Stop: 
# Default-Start: S
# Default-Stop:
# Short-Description: Start udevd, populate /dev and load drivers.
### END INIT INFO

(maybe useful as a template here)

the real 'installation program' is called insserv (originally came from
SuSE Linux and was a server at some point in time in the past). In order
to install a script, it can be invoked as

insserv 

(insserv -r removes a script).


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

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[Mitt Green]

Scooby wrote:

>However me who never ever ran debian and are somewhat unfamiliar with
>init here ran into problem getting vdev to run at start up?

There is actually a couple of documents available‎,
the first is README [1] and the second is How to Test vdev
[2].

>I tried putting it into /etc/rcS.d that is a link here to a startup
script
>in /etc/init.d

If there is one thing I don't like about sysvinit, 'tis lack
of /etc/rc.conf. Thus, I'd suggest sysv-rc-conf, which
is something like system-config-services on RHEL/CentOS/
SL, before 7th release, I suppose. Very simple and clean
curses interface.

Hope this helps,
Mitt


References:
[1]: https://git.devuan.org/pkgs-utopia-substitution/vdev
[2]: https://github.com/jcnelson/vdev/blob/master/how-to-test.md
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[shraptor]

Due to real(boring?) work I've had not much time to put in on
this.

I did get devuan-jessie-amd64-alpha4-netboot.iso installed in a 
VirtualBox VM.

This went without problems.


Jude had already done some basic package-building that is present on 
git.



However me who never ever ran debian and are somewhat unfamiliar with
init here ran into problem getting vdev to run at start up?

I tried putting it into /etc/rcS.d that is a link here to a startup 
script

in /etc/init.d

But when I get to slim-login manager I get no keyboard.

Seems to try to start vdev when choosing systemd boot alternative but no
evidence of start with eudev that I could see?

If I boot to prompt vdev --once seems to run OK allthough not on /dev
which could be due to devtmpfs mounted?

Any input? anyone more familiar with devuan init.


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

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[Rainer Weikusat]

Rainer Weikusat  writes:

[/bin/dash -> /bin/sh]

>>> There is no question here. *If* the script in question uses dash
>>> spuriously, ie, it doesn't use features specific to dash but is actually
>>> a Bourne shell script, replacing /bin/dash with /bin/sh should be
>>> fine. If not, stuff is going to break sooner or later, either because
>>> /bin/sh isn't really dash (eg, someone might use bash for that) or
>>> because of difference between the busybox and Debian (d)ash forks.
>>
>> There shouldn't be any "feature specific to dash", by
>> construction.
>
> There are, "by construction". Eg, dash supports local, the POSIX /bin/sh
> doesn't. 

A more serious one (which has once bitten me badly): dash supports chdir
as undocumented alias for cd (at least up to Wheezy)

[rw@doppelsaurus]/tmp#dash -c 'chdir / && pwd'
/
[rw@doppelsaurus]/tmp#bash -c 'chdir / && pwd'
bash: chdir: command not found

And then, the busybox (d)ash and the Deban dash are still completely
independent codebases
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[Didier Kryn]

Le 11/02/2016 19:25, shraptor a écrit :

In my setup /usr/bin/dash is a symlink to /usr/bin/bash


That's a big mistake.

On any Debian system, /bin/sh points to /bin/dash, and dash doesn't 
point to bash. Your system has certainly been hacked.


It works!
Sure, bash can process ash scripts. The problem is the opposite 
isn't true because bash provides a lot of additional features, 
"bashisms", which distros decided to erradicate from their scripts. 
Users are free to write bash or ksh scripts, but portable scripts must 
execute on ash.


Didier

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

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[Didier Kryn]

Le 11/02/2016 17:04, Rainer Weikusat a écrit :

Didier Kryn  writes:

[...]


It should be the name of a shell capable of running Bourne/ standard
shell scripts. But this may not work if the /bin/dash in the original
script was there for a reason, ie, it was using dash features.


 As I already wrote, vdev was working well with busybox's ash.,
replacing 'dash' with 'sh' in the shebang.

 If the question is why Jude replaced /bin/sh with /bin/dash in the
middle of the development, I think it was to make sure to not invoke
bash. But (sorry for the repetition) I used to modify the shebang
everytime I tested a new version, and there was never any issue with
the shell.

There is no question here. *If* the script in question uses dash
spuriously, ie, it doesn't use features specific to dash but is actually
a Bourne shell script, replacing /bin/dash with /bin/sh should be
fine. If not, stuff is going to break sooner or later, either because
/bin/sh isn't really dash (eg, someone might use bash for that) or
because of difference between the busybox and Debian (d)ash forks.



There shouldn't be any "feature specific to dash", by construction. 
The only reason why dash (Debian's Ash, I guess) exists is portability 
through POSIX conformance. I think Jude uses dash instead of bash, Xsh 
or what else to let it check for POSIX conformance, and he wants to be 
sure to not invoke bash by mistake; he might answer himself, but this is 
the only sensible reason I see.


But POSIX conformance is not enough, /bin/dash in the shebang 
obviously renders portability impossible.  Just look at any system 
script in your Debian or Devuan system and tell me if any of them start 
with #! /bin/dash.



This depends on the code of the script/ scripts in question and blindly
advocating to replace the shell chosen by whoever wrote the script with
a generic name is not a good idea.
Who speaks of doing it blindly? I have clearly written I had 
checked it many times and there was never an issue. Further more, I 
consider that if there was an error,


1) the script should be corrected
2) a bug report should be sent to the authors of the non-conformant 
shell, be it Busybox or Debian.


Didier

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

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[Rainer Weikusat]

Didier Kryn  writes:

> Le 11/02/2016 17:04, Rainer Weikusat a écrit :
>> Didier Kryn  writes:
>>
>> [...]
>>
 It should be the name of a shell capable of running Bourne/ standard
 shell scripts. But this may not work if the /bin/dash in the original
 script was there for a reason, ie, it was using dash features.

>>>  As I already wrote, vdev was working well with busybox's ash.,
>>> replacing 'dash' with 'sh' in the shebang.
>>>
>>>  If the question is why Jude replaced /bin/sh with /bin/dash in the
>>> middle of the development, I think it was to make sure to not invoke
>>> bash. But (sorry for the repetition) I used to modify the shebang
>>> everytime I tested a new version, and there was never any issue with
>>> the shell.
>> There is no question here. *If* the script in question uses dash
>> spuriously, ie, it doesn't use features specific to dash but is actually
>> a Bourne shell script, replacing /bin/dash with /bin/sh should be
>> fine. If not, stuff is going to break sooner or later, either because
>> /bin/sh isn't really dash (eg, someone might use bash for that) or
>> because of difference between the busybox and Debian (d)ash forks.
>>
>
> There shouldn't be any "feature specific to dash", by
> construction.

There are, "by construction". Eg, dash supports local, the POSIX /bin/sh
doesn't. 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[Didier Kryn]

Le 10/02/2016 12:02, shraptor a écrit :

On 2016-02-10 00:35, Adam Borowski wrote:

On Tue, Feb 09, 2016 at 09:20:32AM -0500, Hendrik Boom wrote:

On Tue, Feb 09, 2016 at 09:15:28AM +0100, shraptor wrote:
> >Vdev is still in its final stages of development, as far as I know.
> >Running on developpment asd some test systems, but still being
> >thorougly tested on corner cases before being introduced into 
Devuan.

>
> It is my belief that vdev should go in some testing or development
> repo.

Like Debian's 'experimental' repo?


Yes please!

If you think the code is in good enough shape to be unleashed into the
public, even into experimental, I'd be delighted to help on the
packaging/uploading front.

(I know nothing about the workings of udev, though.)


I think the code is good enough and now is the time to get more users 
testing it.

It works on my specific hardware cause I bug-hunted the sh** out of it.
needs to be tested on more computers.

I guess I have to install devuan to get a working environment then.
Any input on what would be a good install iso for this? I mean
an iso with a system we should target. Maybe better to do a virtualbox
install, might be a lot of rebooting with initramfs work.

Thank you Adam for offering help, Are you knowledgeable on initramfs 
in general?
I think we need someone versed in debian/devuan initramfs generation 
with hooks and so

on?


I think Aitor wrote a while ago about creating a vdev package?
Aitor could you give an update on that effort?


best regards

Scooby


I have some experience with initramfs, and I have already tested 
vdev with Busybox in initramfs a while ago. But have no experience in 
generating a Debian/Devuan initramfs. Here's my experience with 
vdev+busybox:


There was two problems:
1) Busybox's blkid doesn't accept any option. Formatting options 
are no problem because vdev manages to not use them, but the -p option 
is definitely missing. To be able to fully test vdev, I had to build the 
legacy blkid from util-linux.
2) At the time of this test campaign, the shebang line of vdev 
scripts was #!/bin/dash, which doesn't work in Busybox. It should be 
replaced by #!/bin/sh which works in all cases.


With the conditions described above, ie busybox, vdev, blkid (all 
linked statically against Musl libc) and modified shebang lines, the 
startup was working without error when booting from a USB key on my 
amd64 laptop.


I guess in Devuan/Debian, Busybox is dynamicaly linked against 
glibc; therefore adding blkid wouldn't dramatically increase the bloat.


Didier

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

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[shraptor]

On 2016-02-10 15:11, Didier Kryn wrote:

Le 10/02/2016 12:02, shraptor a écrit :

On 2016-02-10 00:35, Adam Borowski wrote:

On Tue, Feb 09, 2016 at 09:20:32AM -0500, Hendrik Boom wrote:

On Tue, Feb 09, 2016 at 09:15:28AM +0100, shraptor wrote:
> >Vdev is still in its final stages of development, as far as I know.
> >Running on developpment asd some test systems, but still being
> >thorougly tested on corner cases before being introduced into Devuan.
>
> It is my belief that vdev should go in some testing or development
> repo.

Like Debian's 'experimental' repo?


Yes please!

If you think the code is in good enough shape to be unleashed into 
the

public, even into experimental, I'd be delighted to help on the
packaging/uploading front.

(I know nothing about the workings of udev, though.)


I think the code is good enough and now is the time to get more users 
testing it.
It works on my specific hardware cause I bug-hunted the sh** out of 
it.

needs to be tested on more computers.

I guess I have to install devuan to get a working environment then.
Any input on what would be a good install iso for this? I mean
an iso with a system we should target. Maybe better to do a virtualbox
install, might be a lot of rebooting with initramfs work.

Thank you Adam for offering help, Are you knowledgeable on initramfs 
in general?
I think we need someone versed in debian/devuan initramfs generation 
with hooks and so

on?


I think Aitor wrote a while ago about creating a vdev package?
Aitor could you give an update on that effort?


best regards

Scooby


I have some experience with initramfs, and I have already tested
vdev with Busybox in initramfs a while ago. But have no experience in
generating a Debian/Devuan initramfs. Here's my experience with
vdev+busybox:

There was two problems:
1) Busybox's blkid doesn't accept any option. Formatting options
are no problem because vdev manages to not use them, but the -p option
is definitely missing. To be able to fully test vdev, I had to build
the legacy blkid from util-linux.
2) At the time of this test campaign, the shebang line of vdev
scripts was #!/bin/dash, which doesn't work in Busybox. It should be
replaced by #!/bin/sh which works in all cases.


Scripts are still dash



With the conditions described above, ie busybox, vdev, blkid (all
linked statically against Musl libc) and modified shebang lines, the
startup was working without error when booting from a USB key on my
amd64 laptop.

I guess in Devuan/Debian, Busybox is dynamicaly linked against
glibc; therefore adding blkid wouldn't dramatically increase the
bloat.



Thanks a lot for information, Any is valuable.

I am not familiar with debian/devuan at all, I come from the Arch Linux 
way
of doing things. It will take some time to get down with devuan I am 
sure.


There is probably a world of difference between arch and debian/devuan.



Didier

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

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

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[shraptor]

On 2016-02-10 15:09, Jaromil wrote:

On Wed, 10 Feb 2016, shraptor wrote:



Thank you Adam for offering help, Are you knowledgeable on initramfs
in general?  I think we need someone versed in debian/devuan
initramfs generation with hooks and so on?


on irc #devuan there is gdm85 who is an expert on this. He is also in
Amsterdam and will join us in person for a Devuan beta sprint we are
planning on Friday at Dyne.org HQ

If you can be around on the channel on friday evening and/or lineup
some questions on problems you encounter then we can put this as a
TODO item and work following his lead on the initramfs issues.



I am sorry but that's much to soon. Like everybody else here
time is scarce for me. No way I get setup till friday, Don't even think 
I got

time on friday to put aside.



An installable package of vdev in Devuan beta will definitely leverage
its testing base. Thanks for working on this, is quite important.


I agree and think it's important that's why I began thinking about this





ciao

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

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

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[Didier Kryn]

Le 10/02/2016 18:50, Rainer Weikusat a écrit :

Didier Kryn  writes:

[...]


 2) At the time of this test campaign, the shebang line of vdev
scripts was #!/bin/dash, which doesn't work in Busybox. It should be
replaced by #!/bin/sh which works in all cases.

This isn't necessarily true. Both dash and the usual busybox sh are
forks of the Amquist shell (ash) which is supposed to be enable to
execute scripts written in the Bourne shell language/ for the
standardized /bin/sh but they also provide extensions of their own (eg,
like bash, dash supports lexically scoped function variables but the
Bourne/ standard shell doesn't). The busybox ash can also compiled w/o
certain features, eg, arithmetic expansion.

'Replacing /bin/dash with /bin/sh' will only work if the author of the
script use the non-standard name because he doesn't knew any better
instead of because the script actually uses dash features.

There's no theory behind that. It's just practical and the result 
of experimenting.


The way Busybox works is all applications are links to 
/bin/busybox. When invoqued, /bin/busybox calls a dispatcher function 
which determines which applet to call (there is one applet per supported 
application) from the name of the link. And there is no applet named 
'dash' in Busybox. But Busybox knows 'ash' and 'sh', which point to the 
same applet.


On the other hand, the default shell in Debian, the one invoked by 
/bin/sh, is dash. I guess in every distro /bin/sh points to the 
~POSIX-compliant shell. Therefore '#!/bin/sh' should just work everywhere.


Didier

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

Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

[Steve Litt]

On Wed, 10 Feb 2016 15:11:16 +0100
Didier Kryn  wrote:

>  I have some experience with initramfs, and I have already tested 
> vdev with Busybox in initramfs a while ago. But have no experience in 
> generating a Debian/Devuan initramfs. Here's my experience with 
> vdev+busybox:
> 
>  There was two problems:
>  1) Busybox's blkid doesn't accept any option. Formatting options 
> are no problem because vdev manages to not use them, but the -p
> option is definitely missing. To be able to fully test vdev, I had to
> build the legacy blkid from util-linux.
>  2) At the time of this test campaign, the shebang line of vdev 
> scripts was #!/bin/dash, which doesn't work in Busybox. It should be 
> replaced by #!/bin/sh which works in all cases.
> 
>  With the conditions described above, ie busybox, vdev, blkid
> (all linked statically against Musl libc) and modified shebang lines,
> the startup was working without error when booting from a USB key on
> my amd64 laptop.
> 
>  I guess in Devuan/Debian, Busybox is dynamicaly linked against 
> glibc; therefore adding blkid wouldn't dramatically increase the
> bloat.
> 
>  Didier

Didier,

If you ever come to Orlando, Florida, USA, could you please give a
presentation on Busybox and its use with initramfs systems at our local
LUG, GoLUG? Your info is tremendously geeky and tremendously useful.

Thanks,

SteveT

Steve Litt 
February 2016 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng