Re: [Dng] Fwd: [dng] vdev status update

[Anto]

On 17/04/15 06:00, Jude Nelson wrote:

Hi Anto,

I just committed preliminary support for using vdevd with devtmpfs. 
 vdevd should automatically detect whether or not devtmpfs is mounted 
on /dev, and nevertheless run device setup scripts (by using its own 
device metadata tree in /dev/vdev/ to see whether or not the device 
was actually processed).


NB for developers:  this problem isn't specific to Linux--I expect to 
encounter it with FreeBSD as well, since it has a full-blown in-kernel 
devfs.  vdevd will keep track of "OS quirks" in the future--one of 
which is the "Device Already Exists" quirk, whereby vdevd simply 
expects the OS to provide the device file (regardless of the 
mechanism).  The Linux-specific vdevd back-end now checks to see if 
vdevd will create files on a devtmpfs filesystem, and enables that 
quirk if so.


Funny, undocumented (!!) discovery:  the devtmpfs filesystem type (see 
statfs(2)) is the same (!!) as the tmpfs filesystem type, despite 
being a fundamentally different filesystem.  I'm surprised that this 
wasn't caught during the devtmpfs code review--guess I'll have to file 
a bug report. Anyway, if you find yourself wondering why vdev has to 
detect devtmpfs by parsing /proc/mounts and verifying that the 
realpath of the mountpoint is the same as or is a subdirectory of a 
devtmpfs mountpoint, that's why--we (currently) can't rely on the 
f_fsid in statfs(2) or statvfs(2).


Thanks,
Jude



Hello Jude,

Before I start pulling your latest commit, could you please let me know 
from which source should I pull that? Should it be from 
https://git.devuan.org/pkgs-utopia-substitution/vdev or 
https://github.com/jcnelson/vdev? So far I have been using the one on 
github.com.


Cheers,

Anto

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

Re: [Dng] Fwd: [dng] vdev status update

[Jude Nelson]

Hi Anto,

I push code to both github and git.devuan.org.  Either one works :)

Thanks,
-Jude

On Fri, Apr 17, 2015 at 9:40 AM, Anto  wrote:

> On 17/04/15 06:00, Jude Nelson wrote:
>
>> Hi Anto,
>>
>> I just committed preliminary support for using vdevd with devtmpfs.
>> vdevd should automatically detect whether or not devtmpfs is mounted on
>> /dev, and nevertheless run device setup scripts (by using its own device
>> metadata tree in /dev/vdev/ to see whether or not the device was actually
>> processed).
>>
>> NB for developers:  this problem isn't specific to Linux--I expect to
>> encounter it with FreeBSD as well, since it has a full-blown in-kernel
>> devfs.  vdevd will keep track of "OS quirks" in the future--one of which is
>> the "Device Already Exists" quirk, whereby vdevd simply expects the OS to
>> provide the device file (regardless of the mechanism).  The Linux-specific
>> vdevd back-end now checks to see if vdevd will create files on a devtmpfs
>> filesystem, and enables that quirk if so.
>>
>> Funny, undocumented (!!) discovery:  the devtmpfs filesystem type (see
>> statfs(2)) is the same (!!) as the tmpfs filesystem type, despite being a
>> fundamentally different filesystem.  I'm surprised that this wasn't caught
>> during the devtmpfs code review--guess I'll have to file a bug report.
>> Anyway, if you find yourself wondering why vdev has to detect devtmpfs by
>> parsing /proc/mounts and verifying that the realpath of the mountpoint is
>> the same as or is a subdirectory of a devtmpfs mountpoint, that's why--we
>> (currently) can't rely on the f_fsid in statfs(2) or statvfs(2).
>>
>> Thanks,
>> Jude
>>
>>
> Hello Jude,
>
> Before I start pulling your latest commit, could you please let me know
> from which source should I pull that? Should it be from
> https://git.devuan.org/pkgs-utopia-substitution/vdev or
> https://github.com/jcnelson/vdev? So far I have been using the one on
> github.com.
>
> Cheers,
>
> Anto
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Wana give a try to vdev

[Didier Kryn]

Le 31/03/2015 20:56, Jude Nelson a écrit :

Hi Didier,

Thank you for offering!  I haven't tried statically linking vdev or 
its helper programs yet, but I don't see why it wouldn't work.  You'll 
need to tweak the vdevd and vdevd helper program makefiles (in 
vdevd/Makefile and vdevd/helpers/LINUX/Makefile, respectively) to add 
the -static directive to gcc.  All of the helper programs only need 
libc.  vdevd needs libvdev (which can be built with make -C libvdev), 
but libvdev only needs libc.


Let me know how it goes?  I'll add it to the tutorial I just sent out 
if it works :)


Thanks,
Jude

On Tue, Mar 31, 2015 at 12:18 PM, Didier Kryn >wrote:


Dear Jude,

I would like to try your vdev. I plan to use a diskless
embeded powerpc I have available for devel. I prefer that to using
quemu and I want to keep my laptop functional h24.

I would do it in an OS built from scratch with only 3
components: kernel version 2.6.29, busybox and vdev. Therefore I
would like to compile vdev and link it statically from the source.
Does it seem feasible?

Didier

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



Hello Jude.

Here is a brief summary of what I did up to now. The goal was to 
install a minimal rootfs in flash memory of an embeded Powerpc 
(MVME3100) to use as a sandbox.


1) I compiled a kernel with the following boot parameters:
console=ttyS0,9600 root=/dev/mtdblock1 rootfstype=jffs2

2) The filesystem contains busybox-1.20.2 statically linked with 
musl, which I had done a while ago.


3) vdevd:

I first tried to compile vdev natively on Debian Wheezy, but could 
not link it statically as I wanted. This is actually a classical problem 
with glibc everytime network functions are used. Actually the offending 
functions are getpwnam_r() and the like. I guess this is related with 
NIS compatibility built in the glibc.


I decided to link against musl libc. To save time I just downloaded 
a ready-made image of sabotage-linux for powerpc and compiled vdev in a 
sabotage chroot.


I have now my minimal OS working. init is a little script doing the 
necessary mounts, including /dev on tmpfs and creating a few device 
files (console, ttyS0, null, zero). The script starts an interactive 
session and I could try to run vdevd by hand:


/ # vdevd /dev
00487:268746168: [  vdev.c:0425] vdev_init: ERROR: 
vdev_config_load('(null)') rc = -14

00487:268746168: [  main.c:0042] main: ERROR: vdev_init rc = -14
/ #

AFIU, I am only missing a config file... :-)

Didier

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

Re: [Dng] Wana give a try to vdev

[Jude Nelson]

Hi Didier,

[Snip]


>  Hello Jude.
>
> Here is a brief summary of what I did up to now. The goal was to
> install a minimal rootfs in flash memory of an embeded Powerpc (MVME3100)
> to use as a sandbox.
>
> 1) I compiled a kernel with the following boot parameters:
> console=ttyS0,9600 root=/dev/mtdblock1 rootfstype=jffs2
>
> 2) The filesystem contains busybox-1.20.2 statically linked with musl,
> which I had done a while ago.
>
> 3) vdevd:
>
> I first tried to compile vdev natively on Debian Wheezy, but could not
> link it statically as I wanted. This is actually a classical problem with
> glibc everytime network functions are used. Actually the offending
> functions are getpwnam_r() and the like. I guess this is related with NIS
> compatibility built in the glibc.


The functions that call getpwnam_r() and getgrnam_r() in libvdev are only
used by vdevfs.  It looks like this is going to be the case for the
foreseeable future.  I just pushed code that moves them into vdevfs, so you
shouldn't see those errors again when statically linking with glibc.
Thanks for trying that out!


> I decided to link against musl libc. To save time I just downloaded a
> ready-made image of sabotage-linux for powerpc and compiled vdev in a
> sabotage chroot.
>

Good to know!  I hadn't tried it with musl yet, but I'm glad to hear that
it works with it.


>
> I have now my minimal OS working. init is a little script doing the
> necessary mounts, including /dev on tmpfs and creating a few device files
> (console, ttyS0, null, zero). The script starts an interactive session and
> I could try to run vdevd by hand:
>
> / # vdevd /dev
> 00487:268746168: [  vdev.c:0425] vdev_init: ERROR:
> vdev_config_load('(null)') rc = -14
> 00487:268746168: [  main.c:0042] main: ERROR: vdev_init rc = -14
> / #
>
> AFIU, I am only missing a config file... :-)


Yup, missing a config file :)

If you run "make -C example" on the host, the Makefile will generate all
the host-tailored vdev config files you'll need (such as persistent
interface naming rules).  They will be generated in example/build/etc/vdev
(which can just be copied into /etc).

Once you have your config files generated, you'll need to add "-c
/path/to/config/file" as an argument.  I just pushed code to vdevd that
makes it look in /etc/vdev/vdevd.conf, if "-c" is not given (and if
/etc/vdev/vdevd.conf doesn't exist, vdevd should fail with ENOENT instead
of EFAULT).

Also, if you want more verbose debugging output from vdevd, you can pass
"-v" or "-v2" :)

Thank you for giving vdev a try, despite it's pre-alpha-ness :)

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

Re: [Dng] Fwd: [dng] vdev status update

[Anto]

On 17/04/15 06:00, Jude Nelson wrote:

Hi Anto,

I just committed preliminary support for using vdevd with devtmpfs. 
 vdevd should automatically detect whether or not devtmpfs is 
mounted on /dev, and nevertheless run device setup scripts (by using 
its own device metadata tree in /dev/vdev/ to see whether or not the 
device was actually processed).ÂÂ


NB for developers:  this problem isn't specific to Linux--I expect 
to encounter it with FreeBSD as well, since it has a full-blown 
in-kernel devfs.  vdevd will keep track of "OS quirks" in the 
future--one of which is the "Device Already Exists" quirk, whereby 
vdevd simply expects the OS to provide the device file (regardless 
of the mechanism).  The Linux-specific vdevd back-end now checks to 
see if vdevd will create files on a devtmpfs filesystem, and enables 
that quirk if so.


Funny, undocumented (!!) discovery:  the devtmpfs filesystem type 
(see statfs(2)) is the same (!!) as the tmpfs filesystem type, despite 
being a fundamentally different filesystem.  I'm surprised that 
this wasn't caught during the devtmpfs code review--guess I'll have to 
file a bug report.  Anyway, if you find yourself wondering why vdev 
has to detect devtmpfs by parsing /proc/mounts and verifying that the 
realpath of the mountpoint is the same as or is a subdirectory of a 
devtmpfs mountpoint, that's why--we (currently) can't rely on the 
f_fsid in statfs(2) or statvfs(2).


Thanks,
Jude



Hello Jude,

After I pulled your commit from github.com, I have done the following:

1. compile and install vdev
2. copy vdev's initrd into /boot
3. rename /sbin/init to /sbin/init.novdev
4. copy vdev's init file into /sbin
5. manually set the vdev's initrd and init.vdev in grub.cfg
6. manually add /etc/init.d/vdev into runlevel.conf (and keep 
/etc/init.d/udev)

first, I tried to put vdev before udev, then the other way around
7. reboot my PC using vdev's initrd and init

There are some progress on the boot messages, but I still ended up on 
(initramfs) prompt. As before, I can only use my keyboard using kernel 
3.2.0, so I could capture the vdev_debugging that you asked before. 
Please download that from 
https://minifora.eu/public/devuan/vdev/vdev_debug_logs.tar.gz. That file 
also contain the copy of /var/log/messages, but I just took the messages 
since I started to keep rebooting my PC.


I think something still do not work properly on the vdev's init as I got 
message saying "/sbin/init: 30: .: Can't open /conf/arch.conf" at boot 
and when I did reboot as below.


root@hp8530w:~# reboot

Broadcast message from root@hp8530w (pts/1) (Fri Apr 17 18:28:56 2015):

The system is going down for reboot NOW!
Loading, please wait...
mount: sysfs already mounted or /sys busy
mount: according to mtab, sysfs is already mounted on /sys
mount: proc already mounted
/sbin/init: 30: .: Can't open /conf/arch.conf
root@hp8530w:~#
root@hp8530w:~# reboot
WARNING: could not determine runlevel - doing soft reboot
  (it's better to use shutdown instead of reboot from the command line)
Loading, please wait...
mkdir: cannot create directory `/var/lock': File exists
mount: sysfs already mounted or /sys busy
mount: according to mtab, sysfs is already mounted on /sys
mount: proc already mounted
/sbin/init: 30: .: Can't open /conf/arch.conf
root@hp8530w:~#

I am still using file-rc instead of sysv-rc, but I didn't clean up 
/etc/rc?.d directories. I tried to use sysv-rc, but my mouse and 
keyboard are not being detected when using kernel 3.18.11. They are only 
being detected on kernel 3.2.0 from wheezy repository. I think there is 
something wrong with my kernel config but I will investigate that later.


Cheers,

Anto

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

Re: [Dng] Fwd: [dng] vdev status update

[Anto]

On 17/04/15 06:00, Jude Nelson wrote:

Hi Anto,

I just committed preliminary support for using vdevd with devtmpfs. 
 vdevd should automatically detect whether or not devtmpfs is mounted 
on /dev, and nevertheless run device setup scripts (by using its own 
device metadata tree in /dev/vdev/ to see whether or not the device 
was actually processed).


NB for developers:  this problem isn't specific to Linux--I expect to 
encounter it with FreeBSD as well, since it has a full-blown in-kernel 
devfs.  vdevd will keep track of "OS quirks" in the future--one of 
which is the "Device Already Exists" quirk, whereby vdevd simply 
expects the OS to provide the device file (regardless of the 
mechanism).  The Linux-specific vdevd back-end now checks to see if 
vdevd will create files on a devtmpfs filesystem, and enables that 
quirk if so.


Funny, undocumented (!!) discovery:  the devtmpfs filesystem type (see 
statfs(2)) is the same (!!) as the tmpfs filesystem type, despite 
being a fundamentally different filesystem.  I'm surprised that this 
wasn't caught during the devtmpfs code review--guess I'll have to file 
a bug report. Anyway, if you find yourself wondering why vdev has to 
detect devtmpfs by parsing /proc/mounts and verifying that the 
realpath of the mountpoint is the same as or is a subdirectory of a 
devtmpfs mountpoint, that's why--we (currently) can't rely on the 
f_fsid in statfs(2) or statvfs(2).


Thanks,
Jude



Hello Jude,

I just realised that you updated the installation guide on 
https://github.com/jcnelson/vdev/blob/master/INSTALL.md, with 
update-rc.d command to disable udev. I just tried to boot using vdev's 
initrd and init with /etc/init.d/udev disabled on /etc/runlevel.conf. I 
also tried to use the init from initramfs-tools with vdev's initrd. But 
the results are the same as the previous one, which logs I sent out 
earlier. Please just let me know if you need more information related to 
that logs.


Cheers,

Anto

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

[Dng] Filename conventions.

[Ángel Ramírez Isea]

Hi, VUAs.

First of all, thanks for all the hard work. It looks very promising.

I just visited https://files.dyne.org/devuan/ and saw all the files 
that represent a lot of work.


I would recommend reconsidering the filename convention used to 
organize the files. Right now they have a date appended at the end 
(right before the period and the filetype) in the format ddmmyy (two 
digits for day, two for month, two for year).


It looks organized, for the time being, but next month it'll start to 
mix days.


I recommend using the ISO format or a variation (yymmdd, for example).

--
Saludos cordiales,

Ángel Ramírez Isea.
Coordinador General.

Asociación Cooperativa Simón Rodríguez para el Conocimiento Libre, RS.
www.simonrodriguez.org.ve
(261) 524.55.93 -:- (426) 369.57.18
J-40294137-4
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Fwd: [dng] vdev status update

[Isaac Dunham]

On Fri, Apr 17, 2015 at 08:03:36PM +0200, Anto wrote:
> After I pulled your commit from github.com, I have done the following:
> 
> 1. compile and install vdev
> 2. copy vdev's initrd into /boot
> 3. rename /sbin/init to /sbin/init.novdev
> 4. copy vdev's init file into /sbin
> 5. manually set the vdev's initrd and init.vdev in grub.cfg
> 6. manually add /etc/init.d/vdev into runlevel.conf (and keep
> /etc/init.d/udev)
> first, I tried to put vdev before udev, then the other way around
> 7. reboot my PC using vdev's initrd and init
> 
> There are some progress on the boot messages, but I still ended up on
> (initramfs) prompt. As before, I can only use my keyboard using kernel
> 3.2.0, so I could capture the vdev_debugging that you asked before. Please
> download that from
> https://minifora.eu/public/devuan/vdev/vdev_debug_logs.tar.gz. That file
> also contain the copy of /var/log/messages, but I just took the messages
> since I started to keep rebooting my PC.
> 

Since I've dealt with things similar to this when debugging mdev,
I've got a few suggestions:

* Check what drivers you are currently using:
lsmod
* Check if they are in your initrd:
lsinitramfs ./initrd.vdev |grep $MODNAME.ko
In particular, look for "hid" (hid_generic, usbhid, hid), evdev,
ahci/ata_piix (if applicable), and sd_mod.
* If they are present, try to inject a line that will load usbhid and
evdev into the initramfs scripts.

That should provide keyboard support so you can investigate.

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

Re: [Dng] Live ISO's (Jessie with no systemd)

[Richard]

@fsmithred, David,

- edit /etc/sources.list.d/devuan.
> list and change "sid" to "ceres".
> - get the gpg key for the angband repo with the following commands:
> gpg --recv-keys 719DCC80BED007F9
> gpg --export --armor 719DCC80BED007F9 | apt-key add -
> (and don't forget the dash at the end of the line)
>

Thanks.
This has fixed the update & dist-upgrade problem.
All completed and looking good.



On Thu, Apr 16, 2015 at 11:55 AM, David Hare  wrote:

>
>  There appears to be no root password in the xfce image. There's only
>> an
>> asterisk in /etc/shadow.
>>
>
> Maybe my mistake, there was meant to be. However  should work
> (from where you can set a root password if wanted) That's the usual
> debian-live type setup anyway.
>
> For anyone interested in the TDE image, it's worth noting that TDE is
> fully functional without many of the gtk-orientated packages which had to
> be recompiled (consolekit, policykit udisks2 et al) Also TDE does not need
> GTK nor QT4.
>
>
> ___
> 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] Live ISO's (Jessie with no systemd)

[Richard]

All in all a good effort.
1. Synaptic wouldn't start from the menu, but works fine from
gksu synaptic
2. Installed Double Commander-0.5.11-1; however,
the latest, DC-0.6.1 is a real winner as a file manager.
It is my new first app to install on any installation.
Thunar is good but DC-0.6.1 is a real winner, even though
the OOTB configuration leaves a lot to be desired.

And no systemd. Great job.
Regards.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Fwd: [dng] vdev status update

[Jude Nelson]

Hi Anto,

[snip]


> 1. compile and install vdev
> 2. copy vdev's initrd into /boot
> 3. rename /sbin/init to /sbin/init.novdev

4. copy vdev's init file into /sbin
>

The init program in example/initramfs/init goes into
/usr/share/initramfs-tools/init, not /sbin/init :)  The initramfs's init
script is fundamentally different from the init program in /sbin.  That
also explains your inability to reboot.

Basically, when the bootloader loads the initramfs, the kernel mounts it as
the root device and starts /sbin/init.  /sbin/init, in turn, runs the
script at /init (which you can see from the initramfs shell with "ls /"),
which is copied into the initramfs image by the update-initramfs and
mkinitramfs tools from the file /usr/share/initramfs-tools/init.


> 5. manually set the vdev's initrd and init.vdev in grub.cfg
> 6. manually add /etc/init.d/vdev into runlevel.conf (and keep
> /etc/init.d/udev)
> first, I tried to put vdev before udev, then the other way around
> 7. reboot my PC using vdev's initrd and init
>
> There are some progress on the boot messages, but I still ended up on
> (initramfs) prompt. As before, I can only use my keyboard using kernel
> 3.2.0, so I could capture the vdev_debugging that you asked before. Please
> download that from
> https://minifora.eu/public/devuan/vdev/vdev_debug_logs.tar.gz. That file
> also contain the copy of /var/log/messages, but I just took the messages
> since I started to keep rebooting my PC.
>
> I think something still do not work properly on the vdev's init as I got
> message saying "/sbin/init: 30: .: Can't open /conf/arch.conf" at boot and
> when I did reboot as below.
>
> root@hp8530w:~# reboot
>
> Broadcast message from root@hp8530w (pts/1) (Fri Apr 17 18:28:56 2015):
>
> The system is going down for reboot NOW!
> Loading, please wait...
> mount: sysfs already mounted or /sys busy
> mount: according to mtab, sysfs is already mounted on /sys
> mount: proc already mounted
> /sbin/init: 30: .: Can't open /conf/arch.conf
> root@hp8530w:~#
> root@hp8530w:~# reboot
> WARNING: could not determine runlevel - doing soft reboot
>   (it's better to use shutdown instead of reboot from the command line)
> Loading, please wait...
> mkdir: cannot create directory `/var/lock': File exists
> mount: sysfs already mounted or /sys busy
> mount: according to mtab, sysfs is already mounted on /sys
> mount: proc already mounted
> /sbin/init: 30: .: Can't open /conf/arch.conf
> root@hp8530w:~#
>
> I am still using file-rc instead of sysv-rc, but I didn't clean up
> /etc/rc?.d directories. I tried to use sysv-rc, but my mouse and keyboard
> are not being detected when using kernel 3.18.11. They are only being
> detected on kernel 3.2.0 from wheezy repository. I think there is something
> wrong with my kernel config but I will investigate that later.
>

Not sure yet what could be the cause of your keyboard and mouse not
working.  Let's see what happens after you fix steps 3 and 4--it could be a
side-effect of the init program being broken, since the init program should
also run the console setup scripts.

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

Re: [Dng] Fwd: [dng] vdev status update

[Isaac Dunham]

On Sat, Apr 18, 2015 at 12:08:54AM -0400, Jude Nelson wrote:
[snip]
> > I am still using file-rc instead of sysv-rc, but I didn't clean up
> > /etc/rc?.d directories. I tried to use sysv-rc, but my mouse and keyboard
> > are not being detected when using kernel 3.18.11. They are only being
> > detected on kernel 3.2.0 from wheezy repository. I think there is something
> > wrong with my kernel config but I will investigate that later.
> >
> 
> Not sure yet what could be the cause of your keyboard and mouse not
> working.  Let's see what happens after you fix steps 3 and 4--it could be a
> side-effect of the init program being broken, since the init program should
> also run the console setup scripts.

To spare you a bit of experimentation:
The only thing that needs to happen for a standard keyboard or mouse
to work on a VT is the driver loading.
The driver for USB keyboards (and USB mice) is usbhid; I think 'hid'
is the driver for non-usb keyboards. 'evdev' is needed for some X
drivers to work right.
...
However, this reminds me: Busybox 1.23.0 and 1.23.1 had a bunch of
different issues with modprobe/depmod, and should not be used.

If you want to use a non-standard keyboard layout or a different font
or resolution, then you need a script for console settings (and a
framebuffer driver and fbcon).

HTH,
Isaac Dunham


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