Re: [DNG] Conversion script: was Formail for managing digests
Le 29/11/2019 à 02:08, s@po a écrit : freedesktop.org, should adress the situation, I don't trust Freedesktop to produce a good quality standard. I don't know who are the people behind Freedesktop, beyond Gnome and KDE, but they have produced Dbus and also the practice to automatically create unwanted directories in your home, unless you disable them explicitely. If "unit" files are something which can be retained (after all, there might be one non-negative outcome of Systemd), they can be used to produce init scripts for various init systems, or these init systems could be made able to, optionnaly, read their configuration from "unit files". Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan cannot exist without the help of Debian
On Wed, 27 Nov 2019, Joril via Dng wrote: > On 26/11/19 22:13, viverna wrote: > > > > I wrote this summer in this list about a possibility of inject init > > > > run scripts (for example runit) in all Devuan packages automatically. > > > > > > This is a great idea. I've been in favor of something similar since > > > 2015. It frees "upstreams" from the responsibility of maintaining init > > > script/configurations for init systems they don't care about or perhaps > > > despise. Daemon start files are written by experts on the init system. > > Sadly it's not just init scripts: for example how would a case like > http://bugs.devuan.org/db/27/276.html > be handled? I guess by hand. do you know about other show-stoppers for the systemd unit conversion plan? BTW, with this mail you just helped me fix this annoying bug on my beowulf day to day install :^) did not knew the fix thanks, ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan cannot exist without the help of Debian
On 29/11/19 12:29, Denis Roio wrote: Sadly it's not just init scripts: for example how would a case like http://bugs.devuan.org/db/27/276.html be handled? I guess by hand. Do you mean the user's hand, or the distro maintainer's? :D do you know about other show-stoppers for the systemd unit conversion plan? Well I'm not an expert but it looks like there are already projects that have started to tie themselves to systemd's specific services, so at least _for those projects_ converting units would not be enough BTW, with this mail you just helped me fix this annoying bug on my beowulf day to day install :^) did not knew the fix Glad to hear it :) I've stumbled on it myself just a few days ago, when installing Beowulf on my new laptop ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] IFJ - Init Freedom inJector
Inject init diversity in a single package.
I just released IFJ.
Grab it:
https://notabug.org/viverna/ifj
It is a posix shell script (use dpkg-deb and sed).
Sorry, it is not available a man pages.
--
_
< Viverna >
-
\^/^
\ / \ // \
\ |\___/| / \// .\
\ /0 0 \__ /// | \ \ **
/ / \/_/// | \ \ \ |
@_^_@`/ \/_ //| \ \ \/\ \
//_^_/ \/_ // |\\ \ \
( //) |\/// | \ \ | |
( / /) | // | \ _\ | /
( // /) | ; -.|_ _\.-~ / /
(( / / )) |_ *-.|.-~-. .~~
(( // / ))\ / ~-. _ .-~ /
(( /// )) `. }{ /
(( / )) .~-.\\-` .~
///...<\ _ -~
///-._ _ _ _ _ _ _{^ - - - - ~
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Crypted swap bug in todays "Ceres": "contains a filesystem type hfsplus".
Приветствую. In "Ceres", two days ago stopped working crypted swap, that is actualy just a file, with the "diagnose": "contains a filesystem type hfsplus". May here is on a list the one, that alreade have met and conquered the bug, and wills to share his precious knowledge? My web searches brought me to the bug in blockid but it still does not the problem. Thanks in any advance. Андрей. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] IFJ - Init Freedom inJector
On 2019-11-29 07:25, viverna wrote:
Inject init diversity in a single package.
I just released IFJ.
Grab it:
https://notabug.org/viverna/ifj
It is a posix shell script (use dpkg-deb and sed).
Sorry, it is not available a man pages.
--
_
< Viverna >
-
\^/^
\ / \ // \
\ |\___/| / \// .\
\ /0 0 \__ /// | \ \ **
/ / \/_/// | \ \ \ |
@_^_@`/ \/_ //| \ \ \/\ \
//_^_/ \/_ // |\\ \ \
( //) |\/// | \ \ | |
( / /) | // | \ _\ | /
( // /) | ; -.|_ _\.-~ / /
(( / / )) |_ *-.|.-~-. .~~
(( // / ))\ / ~-. _ .-~ /
(( /// )) `. }{ /
(( / )) .~-.\\-` .~
///...<\ _ -~
///-._ _ _ _ _ _ _{^ - - - - ~
___
Hi viverna,
Perhaps you could put the IFJ in https://git.devuan.org. And continue to
develop it there also?
Thanks.
golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On Fri, 29 Nov 2019 12:15:29 +0100 Didier Kryn wrote: > Le 29/11/2019 à 02:08, s@po a écrit : > > freedesktop.org, should adress the situation, > > I don't trust Freedesktop to produce a good quality standard. I > don't know who are the people behind Freedesktop, beyond Gnome and KDE, > but they have produced Dbus and also the practice to automatically > create unwanted directories in your home, unless you disable them > explicitely. > > If "unit" files are something which can be retained (after all, > there might be one non-negative outcome of Systemd), they can be used to > produce init scripts for various init systems, or these init systems > could be made able to, optionnaly, read their configuration from "unit > files". > I don't trust them neither.. But, they should have addressed this problem after all they were waving the flag of standards.. They seems to forgot a Standard Init API mechanism.. shame.. I spoke about that because I took 5 minutes to look at last development of SysVInit, and indeed you find there some stuff about systemd and dbus integration.. I understand the dbus integration as a way, so that SysVinit daemons could coexist with Dbus controlled daemons.. The Idea arrived.. Why not have an Interpreter, for the UnitFiles, that then internally do things as SysVInit does? In this way we could preserve SysVinit daemons functionality, and when impossible( or a "unscallable wall arrive".. ), SysVinit will continue to control, the usual daemons, plus the wave of non SysVinit ones( in the mean time we could have time to port daemons at the speed we can.. ). So this idea is some sort of a patched SysVinit, to have half of the 'Script Injector' idea( the interpreter of unit files part ), and some logic to do it like sysVInit does.. But that would also means.. that we had to have in /etc/init.d/, all the s*tty systemD service files.. which is a bit crazy.. Best Regards, tux -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] IFJ - Init Freedom inJector
il devuanizzato goli...@devuan.org il 29-11-19 17:09:02 ha
scritto:
Hi viverna,
Perhaps you could put the IFJ in https://git.devuan.org. And continue
to develop it there also?
Thanks.
golinux
Hi golinux, thanks, I thought it was reserved for main Devuan
developers.
I don't know very well Devuan infrastucture. Ideally a package
downloaded from Debian could be injected with ifj adding rules for init
system. It should be called by Amprolla I think.
My free time is very variable. I release it because for 2/3 week from
December my free time is equal to zero and I won't be able to develop
anything. This time can be useful to show it and let him try it.
--
_
< Viverna >
-
\^/^
\ / \ // \
\ |\___/| / \// .\
\ /0 0 \__ /// | \ \ **
/ / \/_/// | \ \ \ |
@_^_@`/ \/_ //| \ \ \/\ \
//_^_/ \/_ // |\\ \ \
( //) |\/// | \ \ | |
( / /) | // | \ _\ | /
( // /) | ; -.|_ _\.-~ / /
(( / / )) |_ *-.|.-~-. .~~
(( // / ))\ / ~-. _ .-~ /
(( /// )) `. }{ /
(( / )) .~-.\\-` .~
///...<\ _ -~
///-._ _ _ _ _ _ _{^ - - - - ~
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
Hi all, long time as a silent lurker, but is seems well time to get up and act. Although today I'm just about writing about doing, so feel free to ignore me. English is not my first language, so if I use inappropriate writing tone, I apologize now and please let me know about my errors. The exchange of ideas on converting init script is needed and I've seen plenty of interesting comments and proposed solutions. On 29/11/2019 18:17, s@po wrote: On Fri, 29 Nov 2019 12:15:29 +0100 Didier Kryn wrote: Le 29/11/2019 à 02:08, s@po a écrit : freedesktop.org, should adress the situation, I don't trust Freedesktop to produce a good quality standard. I don't know who are the people behind Freedesktop, beyond Gnome and KDE, but they have produced Dbus and also the practice to automatically create unwanted directories in your home, unless you disable them explicitely. If "unit" files are something which can be retained (after all, there might be one non-negative outcome of Systemd), they can be used to produce init scripts for various init systems, or these init systems could be made able to, optionnaly, read their configuration from "unit files". If (assuming that) we are going to lose the source of init scripts upstream, then it's the only way forward. (For those who consider recognizing the unit files as a valid source a defeat: I may agree with you, but sometimes a strategic retreat can lead to victory). I don't trust them neither.. But, they should have addressed this problem after all they were waving the flag of standards.. They seems to forgot a Standard Init API mechanism.. shame.. I spoke about that because I took 5 minutes to look at last development of SysVInit, and indeed you find there some stuff about systemd and dbus integration.. I understand the dbus integration as a way, so that SysVinit daemons could coexist with Dbus controlled daemons.. The Idea arrived.. Why not have an Interpreter, for the UnitFiles, that then internally do things as SysVInit does? In this way we could preserve SysVinit daemons functionality, and when impossible( or a "unscallable wall arrive".. ), SysVinit will continue to control, the usual daemons, plus the wave of non SysVinit ones( in the mean time we could have time to port daemons at the speed we can.. ). So this idea is some sort of a patched SysVinit, to have half of the 'Script Injector' idea( the interpreter of unit files part ), and some logic to do it like sysVInit does.. But that would also means.. that we had to have in /etc/init.d/, all the s*tty systemD service files.. which is a bit crazy.. Fascinating, but I'd like to explain my viewpoint about this idea. My impression is that it is viable building a batch init script generator, where package maintainers are able to check and validate the newly generated init scripts *in the maintainer test system*, as well as take care of any peculiar bug of the translation, or quirky behaviour of the unit files. As it's systemd we are talking about, I wouldn't ever place a bet on stable and documented behaviour on its part. Otherwise we wouldn't be here on devuan ML, after all. When new peculiar behaviour is discovered, we can adapt the initscript generator. This would mean a huge effort on repacking debian packages, or having blanket-like packages with init"scripts" for SysV/openrc/any_init that provide the init support to all/groups of debian packages, possibly synced with major revisions of devuan. On the other hand, a unitfile *interpreter* is a different story, I'm not sure this is viable as of now, and the risks look greater to me in this case. IMO there are two scenarios. 1) the interpreter is external to SysVinit/any_init init and is called after each package update (by means of apt ?). Still, any bug that creeps through by leveraging unexpected unit file behaviour will risk of breaking the interpreter *in the devuan user system*, and this would negatively affect devuan reliability. Imagine the backfire of a situation where the interpreter fails after a security update for some obscure change in a unit file, so at service start/stop or at next reboot the system goes astray. 2) the interpreter is run by the init process (bound to it some way) and used each time a script is accessed. I'd rather not see this, more complexity of this kind in the init process is bad for system health. I agree the interpreter idea is technically intriguing, but bot scenarios are a bit too close to reimplementing systemd, IMO. I'd rather develop something useful to the mantainers now, and keep the option to turn it into a package for the end user later on. So I'd first go with 1) the offline translation, 2) get it stable enough that it can run automatically on any debian package updates, 3) monitor the amount of bugs and manual corrections needed, then 4) enable the initscript to be automatically generated and added to packages in devuan, 5) monitor ag
[DNG] LSB script headers
I have been following the thread on using systemd unit files as a source for traditional init scripts. I write BSD headers for my freeBSD system, /etc/rc.d scripts and used to write LSB headers for /etc/init.d Linux scripts. What ever happened to the LSB format for scripts. If it still exists, would that not be a standard to follow? -- William (Bill) Moss billm...@acm.org NY (USA) Those who will not reason, are bigots, those who cannot, are fools, and those who dare not, are slaves. by Lord Byron Justice will not be served until those who are unaffected are as outraged as those who are. by Benjamin Franklin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Process Supervision Rosetta Stone
Hi all, I've created a Process Supervision Rosetta Stone to show identically or similarly functioning commands in each of daemontools, runit and s6. A benefit of this is that if one has a working runit run/finish script, translating to s6 is almost rote text substitution. This Rosetta Stone is nowhere complete nor do I believe it's entirely accurate. But I and other people will doubtlessly improve it: It's CC Share Alike license making this not only possible but easy. Runit run scripts are easy to come by: s6, not so much. This can conceivably bring s6 on an equal footing with runit. Check it out at: http://troubleshooters.com/linux/init/rosetta.html SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting 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] LSB script headers
On Fri, 29 Nov 2019 13:33:34 -0500 "bill.m.moss--- via Dng" wrote: > I have been following the thread on using systemd unit files as a source > for traditional init scripts. I write BSD headers for my freeBSD system, > /etc/rc.d scripts and used to write LSB headers for /etc/init.d Linux > scripts. What ever happened to the LSB format for scripts. If it still > exists, would that not be a standard to follow? > -- Indeed, is was a good proposition, with a lot of definitions on it.. -- tux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
