Re: [DNG] Dng Digest, Vol 23, Issue 103
Hi Ralph, On 08/26/2016 02:00 PM, Ralph Ronnquist wrote: So, I took the steps of forking Jude Nelson's vdev on git.devuan.org, and augmenting it with an initial set up for deb package building. I set it up as three deb's: libudev1-compat to replace libudev1, vdevd being the daemon, and vdev being the configuration, initramfs building and the set up as sysvinit startup script. I've built sample packages for amd64, and tested on a pristine Devuan 1.0.0, (with DE+Xfce, printer server and ssh server). Available at https://git.devuan.org/ralph.ronnquist/vdev/release If you download those and install together (as in dpkg -i *.deb), your system will change into using vdev rather than udev, but it doesn't uninstall udev for you. It "only" removes udev's sysvinit scripts, and udev's configuration for initramfs building, and the "init" script (replaces the one from initramfs-tools). When installing, it might warn about volume symlinks not being created. It's is safe to ignore this. Alternatively you install lvm2 first. You can also build your own deb's by cloning https://git.devuan.org/ralph.ronnquist/vdev and using $ make -f debian.mk provided you have dh_make and dpkg-buildpackage, as well as build-essential. Since I'm quite new to package building, it only contains the bare-bones so far. There are also no upstream changes to source other than to Makefile's and initramfs scripts, with the exception of the very minor patch to vdevd/helpers/LINUX/udev-compat.sh. As a side note, eventually I realised that the main issue why the keyboard didn't work, was that the evdev module didn't get installed, and that it needs to be installed before /dev/input is populated. Ralph. This is what i get trying to register in your website: 2 errors prohibited this user from being saved: * Email has already been taken * Username has already been taken Cheers, Aitor ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev packaging
On 2016-08-25 14:06, Ralph Ronnquist wrote: So, I took the steps of forking Jude Nelson's vdev on git.devuan.org, and augmenting it with an initial set up for deb package building. I set it up as three deb's: libudev1-compat to replace libudev1, vdevd being the daemon, and vdev being the configuration, initramfs building and the set up as sysvinit startup script. I've built sample packages for amd64, and tested on a pristine Devuan 1.0.0, (with DE+Xfce, printer server and ssh server). Available at https://git.devuan.org/ralph.ronnquist/vdev/release If you download those and install together (as in dpkg -i *.deb), your system will change into using vdev rather than udev, but it doesn't uninstall udev for you. It "only" removes udev's sysvinit scripts, and udev's configuration for initramfs building, and the "init" script (replaces the one from initramfs-tools). When installing, it might warn about volume symlinks not being created. It's is safe to ignore this. Alternatively you install lvm2 first. You can also build your own deb's by cloning https://git.devuan.org/ralph.ronnquist/vdev and using $ make -f debian.mk provided you have dh_make and dpkg-buildpackage, as well as build-essential. Since I'm quite new to package building, it only contains the bare-bones so far. There are also no upstream changes to source other than to Makefile's and initramfs scripts, with the exception of the very minor patch to vdevd/helpers/LINUX/udev-compat.sh. As a side note, eventually I realised that the main issue why the keyboard didn't work, was that the evdev module didn't get installed, and that it needs to be installed before /dev/input is populated. Ralph. Great work Ralph. I will test it during next week and give feedback. Since I had a go at making it work meself could you explain how you went about getting evdev module loaded before /dev/input was populated Also how did you solve the problem with logfile could not be written at the logfile path? Just curious and need to learn /scooby ___ 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
On 2016-08-26 17:41, shraptor wrote: On 2016-08-25 14:06, Ralph Ronnquist wrote: So, I took the steps of forking Jude Nelson's vdev on git.devuan.org, and augmenting it with an initial set up for deb package building. I set it up as three deb's: libudev1-compat to replace libudev1, vdevd being the daemon, and vdev being the configuration, initramfs building and the set up as sysvinit startup script. I've built sample packages for amd64, and tested on a pristine Devuan 1.0.0, (with DE+Xfce, printer server and ssh server). Available at https://git.devuan.org/ralph.ronnquist/vdev/release If you download those and install together (as in dpkg -i *.deb), your system will change into using vdev rather than udev, but it doesn't uninstall udev for you. It "only" removes udev's sysvinit scripts, and udev's configuration for initramfs building, and the "init" script (replaces the one from initramfs-tools). When installing, it might warn about volume symlinks not being created. It's is safe to ignore this. Alternatively you install lvm2 first. You can also build your own deb's by cloning https://git.devuan.org/ralph.ronnquist/vdev and using $ make -f debian.mk provided you have dh_make and dpkg-buildpackage, as well as build-essential. Since I'm quite new to package building, it only contains the bare-bones so far. There are also no upstream changes to source other than to Makefile's and initramfs scripts, with the exception of the very minor patch to vdevd/helpers/LINUX/udev-compat.sh. As a side note, eventually I realised that the main issue why the keyboard didn't work, was that the evdev module didn't get installed, and that it needs to be installed before /dev/input is populated. Ralph. Great work Ralph. I will test it during next week and give feedback. Since I had a go at making it work meself could you explain how you went about getting evdev module loaded before /dev/input was populated Also how did you solve the problem with logfile could not be written at the logfile path? Just curious and need to learn /scooby Also Ralph may I ask if you believe the vdev upgrade would work on rpi3? rpi3 with really no peripherals as it is used as a server so it probably would work although I don't know how to install the build chain for it. Probably not a good idea to build vdev on the rpi3 when it is in "production", right? /scooby ___ 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] vdev packaging Was: Re: Dng Digest, Vol 23, Issue 103
On Fri, 2016-08-26 at 16:00 +0200, aitor_czr wrote: > > This is what i get trying to register in your website: > 2 errors prohibited this user from being saved: > Email has already been taken > Username has already been taken Please don't reply to a Digest mail without changing to the correct subject! Please! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev packaging
On 08/25/2016 08:06 AM, Ralph Ronnquist wrote: > So, I took the steps of forking Jude Nelson's vdev on git.devuan.org, and > augmenting it with an initial set up for deb package building. > > I set it up as three deb's: >libudev1-compat to replace libudev1, >vdevd being the daemon, and >vdev being the configuration, initramfs building and the set up as > sysvinit startup script. > > I've built sample packages for amd64, and tested on a pristine Devuan > 1.0.0, (with DE+Xfce, printer server and ssh server). Available at > > https://git.devuan.org/ralph.ronnquist/vdev/release I get a 404 error on that page. After looking around for a bit, I found the debs here: https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release Does the initramfs get built automatically when you install the debs, and if so, does it replace the one in /boot, or does it get dropped somewhere else and need to be copied? -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev packaging
fsmithred wrote on 27/08/16 07:57: On 08/25/2016 08:06 AM, Ralph Ronnquist wrote: So, I took the steps of forking Jude Nelson's vdev on git.devuan.org, and augmenting it with an initial set up for deb package building. I get a 404 error on that page. After looking around for a bit, I found the debs here: https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release Thanks. Yes, I suppose the "shorter" path is only if you clone it. Does the initramfs get built automatically when you install the debs, and if so, does it replace the one in /boot, or does it get dropped somewhere else and need to be copied? Yes, I spent most of the time on integrating the packaging with initramfs-tools, to make it build properly when you install it, and to persist to (hopefully) rebuild properly when you install other packages later on that cause rebuilding of initrd. However, the installation does not remove udev. It does unhook udev from being used, which of course is an unfriendly way for a package to behave. I tried various ways of declaring conflict to udev so as to have the packaging deal with it automagically, but I didn't find any way that didn't then unsintall X (and many ways that uninstalled the kernel). So in the end I left it with a) removing the udev hooks from initramfs-tools configurations, b) removing them from sysvinit activation, and c) replacing the "init" script for initrd; the last was necessary because the script enforced using udev. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev packaging
shraptor wrote on 27/08/16 02:08: On 2016-08-26 17:41, shraptor wrote: On 2016-08-25 14:06, Ralph Ronnquist wrote: So, I took the steps of forking Jude Nelson's vdev on git.devuan.org, and augmenting it with an initial set up for deb package building. I set it up as three deb's: libudev1-compat to replace libudev1, vdevd being the daemon, and vdev being the configuration, initramfs building and the set up as sysvinit startup script. I've built sample packages for amd64, and tested on a pristine Devuan 1.0.0, (with DE+Xfce, printer server and ssh server). Available at https://git.devuan.org/ralph.ronnquist/vdev/release If you download those and install together (as in dpkg -i *.deb), your system will change into using vdev rather than udev, but it doesn't uninstall udev for you. It "only" removes udev's sysvinit scripts, and udev's configuration for initramfs building, and the "init" script (replaces the one from initramfs-tools). When installing, it might warn about volume symlinks not being created. It's is safe to ignore this. Alternatively you install lvm2 first. You can also build your own deb's by cloning https://git.devuan.org/ralph.ronnquist/vdev and using $ make -f debian.mk provided you have dh_make and dpkg-buildpackage, as well as build-essential. Since I'm quite new to package building, it only contains the bare-bones so far. There are also no upstream changes to source other than to Makefile's and initramfs scripts, with the exception of the very minor patch to vdevd/helpers/LINUX/udev-compat.sh. As a side note, eventually I realised that the main issue why the keyboard didn't work, was that the evdev module didn't get installed, and that it needs to be installed before /dev/input is populated. Ralph. Great work Ralph. I will test it during next week and give feedback. Since I had a go at making it work meself could you explain how you went about getting evdev module loaded before /dev/input was populated Also how did you solve the problem with logfile could not be written at the logfile path? Just curious and need to learn /scooby Also Ralph may I ask if you believe the vdev upgrade would work on rpi3? rpi3 with really no peripherals as it is used as a server so it probably would work although I don't know how to install the build chain for it. Probably not a good idea to build vdev on the rpi3 when it is in "production", right? /scooby 1) there's a "force_load evdev" early in the init-top script. Though possibly it rather should be deferred to the script that populates /dev/input. 2) The logfile is moved to /run/vdev/vdev.log 3) Off hand I would say it would work, but on the other hand, afaik vdev is still in beta state. And I don't know anything about rpi3. To try it out, you should first make sure you can revert easily. But I haven't thought too much about how to do that. In practice, vdev conflicts with udev, libudev1 and initramfs-tools, because it removes or overwrites files (/links) from these. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Dng Digest, Vol 23, Issue 103
aitor_czr wrote on 27/08/16 00:00: Hi Ralph, On 08/26/2016 02:00 PM, Ralph Ronnquist wrote: So, I took the steps of forking Jude Nelson's vdev on git.devuan.org, ... This is what i get trying to register in your website: 2 errors prohibited this user from being saved: * Email has already been taken * Username has already been taken Ah. I'm afraid it's not _my_ site (yet?:). It's git.devuan.org, and presumably the matter is that you already have a login.. Sorry about causing confusion. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev packaging
On Sat, Aug 27, 2016 at 08:45:35AM +1000, Ralph Ronnquist wrote: > > > shraptor wrote on 27/08/16 02:08: > >On 2016-08-26 17:41, shraptor wrote: > >>On 2016-08-25 14:06, Ralph Ronnquist wrote: > >>>So, I took the steps of forking Jude Nelson's vdev on git.devuan.org, > >>>and augmenting it with an initial set up for deb package building. > >>> > >>>I set it up as three deb's: > >>> libudev1-compat to replace libudev1, > >>> vdevd being the daemon, and > >>> vdev being the configuration, initramfs building and the set up as > >>>sysvinit startup script. > >>> > >>>I've built sample packages for amd64, and tested on a pristine Devuan > >>>1.0.0, (with DE+Xfce, printer server and ssh server). Available at > >>> > >>>https://git.devuan.org/ralph.ronnquist/vdev/release > >>> > >>>If you download those and install together (as in dpkg -i *.deb), your > >>>system will change into using vdev rather than udev, but it doesn't > >>>uninstall udev for you. It "only" removes udev's sysvinit scripts, and > >>>udev's configuration for initramfs building, and the "init" script > >>>(replaces the one from initramfs-tools). > >>> > >>>When installing, it might warn about volume symlinks not being > >>>created. It's is safe to ignore this. Alternatively you install lvm2 > >>>first. > >>> > >>>You can also build your own deb's by cloning > >>>https://git.devuan.org/ralph.ronnquist/vdev > >>> > >>>and using > >>>$ make -f debian.mk > >>> > >>>provided you have dh_make and dpkg-buildpackage, as well as > >>>build-essential. Since I'm quite new to package building, it only > >>>contains the bare-bones so far. There are also no upstream changes to > >>>source other than to Makefile's and initramfs scripts, with the > >>>exception of the very minor patch to > >>>vdevd/helpers/LINUX/udev-compat.sh. > >>> > >>>As a side note, eventually I realised that the main issue why the > >>>keyboard didn't work, was that the evdev module didn't get installed, > >>>and that it needs to be installed before /dev/input is populated. > >>> > >>>Ralph. > >> > >>Great work Ralph. > >> > >>I will test it during next week and give feedback. > >> > >>Since I had a go at making it work meself could you explain how > >>you went about getting evdev module loaded before /dev/input was > >>populated > >> > >> > >>Also how did you solve the problem with logfile could not be written > >>at the logfile path? > >> > >>Just curious and need to learn > >> > >>/scooby > > > > > >Also Ralph may I ask if you believe the vdev upgrade would work on rpi3? > > > >rpi3 with really no peripherals as it is used as a server so it probably > >would work > >although I don't know how to install the build chain for it. > > > >Probably not a good idea to build vdev on the rpi3 when it is in > >"production", right? > > > >/scooby > > 1) there's a "force_load evdev" early in the init-top script. Though > possibly it rather should be deferred to the script that populates > /dev/input. > > 2) The logfile is moved to /run/vdev/vdev.log > > 3) Off hand I would say it would work, but on the other hand, afaik vdev is > still in beta state. And I don't know anything about rpi3. To try it out, > you should first make sure you can revert easily. But I haven't thought too > much about how to do that. In practice, vdev conflicts with udev, libudev1 > and initramfs-tools, because it removes or overwrites files (/links) from > these. It would be convenient from a user perspective, especaally while we are still testingg, to be able to choose udev or vdev at boot time, perhaps as a kerel parameter. But if the packages conflict to this degree, I suppose there isn't much hope of it. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev packaging
Hendrik Boom wrote on 27/08/16 08:52: On Sat, Aug 27, 2016 at 08:45:35AM +1000, Ralph Ronnquist wrote: .. 3) Off hand I would say it would work, but on the other hand, afaik vdev is still in beta state. And I don't know anything about rpi3. To try it out, you should first make sure you can revert easily. But I haven't thought too much about how to do that. In practice, vdev conflicts with udev, libudev1 and initramfs-tools, because it removes or overwrites files (/links) from these. It would be convenient from a user perspective, especially while we are still testing, to be able to choose udev or vdev at boot time, perhaps as a kernel parameter. But if the packages conflict to this degree, I suppose there isn't much hope of it. Agreed about convenience. Though without thinking too deep about it, it'd mean improving(?) both initramfs-tools and sysvinit (and alternatives) towards maintaining concurrent alternative initrd, and startup choice respectively. I'm sure it _could_ be patched into the vdev installation to provide a dynamic choice between it and a prior udev (for some systems), but I think it'd violate the package independence thought quite severely; much worse than it already does. In the present incarnation, the rollback (not tested by me, though) from vdev to udev is (should be): remove vdev and libudev1-compat (and perhaps vdevd), then reinstall udev, libudev1, and initramfs-tools. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] UMENU2 beta
Hi all, The UMENU2 beta is now available as a tarball, at http://www.troubleshooters.com/projects/umenu2/downloads/umenu2_1_9_1.tgz . UMENU2 is a very fast keystroke operated menu system capable of running arbitrary commands, with options and arguments, environment variables, specific current directory, and prepath (so necessary executables are on the path). I recommend using Suckless Tools' dmenu when you just need to run a program any old way (Palemoon, Claws-Mail, xterm), and UMENU2 when you need to run a program in a specific way, for instance, running LyX in a specific directory devoted to a specific book). Here are simple install instructions: 1. Back up and move away any existing ~/.umenurc and/or ~/umenu2/ 2. cd ~ 3. tar xzvf umenu2_1_9_1.tgz 4. mv umenu2_1_9_1 umenu2 5. cd umenu2/prog 6. ./umenu.py u Dependencies: * Posix * Bash or dash or another sh * Python3 No database, no YAML, no compiling a menu structure: The menu system definition is contained in a simple directory tree, as will be obvious when you run it. When installed the simple way, as described in the beginning of this email, it's capable of running up to 26 different menus (one for each letter of the alphabet). The letter u is already used as a helper for UMENU2 itself, helping you build new menus, peruse documents, and work with examples of various UMENU2 features. I've hammered this thing pretty hard, and on my computer it works exquisitely when operated "correctly", but I have a feeling there ar bugs lying around somewhere, and I know that the error handling in some cases (including trying to pull up a nonexisting menu) is a little rough and less than perfectly informative. I'd greatly appreciate feedback on how it worked and what needs to be fixed. Please feel free to get back to me with questions and comments, either onlist or offlist, and I'll quickly get back to you. Hope you like it, and don't hesitate to get back to me about it. SteveT Steve Litt August 2016 featured book: Manager's Guide to Technical Troubleshooting Brand new, second edition http://www.troubleshooters.com/mgr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev packaging
On 27/08/16 12:05, Ralph Ronnquist wrote: > Hendrik Boom wrote on 27/08/16 08:52: >> On Sat, Aug 27, 2016 at 08:45:35AM +1000, Ralph Ronnquist wrote: >>> .. >>> 3) Off hand I would say it would work, but on the other hand, afaik >>> vdev is >>> still in beta state. And I don't know anything about rpi3. To try it >>> out, >>> you should first make sure you can revert easily. But I haven't >>> thought too >>> much about how to do that. In practice, vdev conflicts with udev, >>> libudev1 >>> and initramfs-tools, because it removes or overwrites files (/links) >>> from >>> these. >> >> It would be convenient from a user perspective, especially while we >> are still testing, to be able to choose udev or vdev at boot time, >> perhaps as a kernel parameter. But if the packages conflict to this >> degree, I suppose there isn't much hope of it. > > Agreed about convenience. Though without thinking too deep about it, > it'd mean improving(?) both initramfs-tools and sysvinit (and > alternatives) towards maintaining concurrent alternative initrd, and > startup choice respectively. I'm sure it _could_ be patched into the > vdev installation to provide a dynamic choice between it and a prior > udev (for some systems), but I think it'd violate the package > independence thought quite severely; much worse than it already does. > > In the present incarnation, the rollback (not tested by me, though) from > vdev to udev is (should be): remove vdev and libudev1-compat (and > perhaps vdevd), then reinstall udev, libudev1, and initramfs-tools. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I'd imagine it should be possible to include both udev and vdev in the initrd and add a boot option to select which device manager to use. Once I've I've got a moment I'm going to jump in on this and see if we can get a vdev package into experimental and work towards including it in jessie-backports. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
