Re: [DNG] disable elogind messages?
On Sat, Nov 23, 2019 at 05:38:54AM -0600, hal wrote: > This still leaves the question however, is there a way to disable the > elogind messages in syslog? It seems like a lot of useless chatter in the > syslogs. Sorry, did not read your E-Mail before. Did you check /etc/pam.d/cron for elogind references? (Including the includes) cron should not produce any elogind output since it uses /etc/pam.d/common-session-noninteractive by default. elogind should be only listed in /etc/pam.d/common-session. cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] INJ - Init Freedom inJector (was: cannot exist without the help of Debian)
il devuanizzato Alexis PM via Dng il 23-11-19 10:54:31 ha
scritto:
Init Freedom inJector is great, fantastic, wonderful, if that really achieves
its goal (automatically introduce in all packages the necessary scripts to make
any init work _without problems or bugs_).
Best regards!
Thanks.
I have a busy schedule this days but I believe that I release script
before Thursday.
--
_
< Viverna >
-
\^/^
\ / \ // \
\ |\___/| / \// .\
\ /0 0 \__ /// | \ \ **
/ / \/_/// | \ \ \ |
@_^_@`/ \/_ //| \ \ \/\ \
//_^_/ \/_ // |\\ \ \
( //) |\/// | \ \ | |
( / /) | // | \ _\ | /
( // /) | ; -.|_ _\.-~ / /
(( / / )) |_ *-.|.-~-. .~~
(( // / ))\ / ~-. _ .-~ /
(( /// )) `. }{ /
(( / )) .~-.\\-` .~
///...<\ _ -~
///-._ _ _ _ _ _ _{^ - - - - ~
___
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 Sat, 23 Nov 2019, Andrew McGlashan via Dng wrote: > I have tried ASCII 2.0 -- but it looks like there is a new 2.1 > version just about to be announced? yes, there is a 2.1 ready and most of it is thanks to the passionate work of volunteers, among the few fsmithred, rrq, golinux, centuriondan and evilham. I believe there wouldn't be this point release without them. Only the VM and ARM images are lagging behind, which is mostly my fault. The place of reference is always files.devuan.org and the release notes are updated https://files.devuan.org/devuan_ascii/Release_notes.txt Devuan's history can be easily traced connecting people and versions, which also shows how much of the sustainability of our project is bound to individual initiative and vision. Devuan is not resilient. If Debian stops providing the forest around our cultivated patch, our plants will die. the VUA will announce the 2.1 point release tomorrow, on Monday. I believe all of us are motivated to continue in our best capacity to support Devuan, but I really do not want to see any of the great people involved burn out because of an incommensurable challenge. what we can also try is to scale Devuan's effort with an enterprise approach, but then we need clear commitment from at least one strong and reliable industrial partner. all this of course IMHO, I'm not speaking for Devuan, but sharing with you my personal opinions on this project ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] disable elogind messages?
On 11/24/19 4:57 AM, Andreas Messer wrote: Sorry, did not read your E-Mail before. Did you check /etc/pam.d/cron for elogind references? (Including the includes) cron should not produce any elogind output since it uses /etc/pam.d/common-session-noninteractive by default. elogind should be only listed in /etc/pam.d/common-session. No problem. Thank you for taking the time for this. So grep shows this: # grep elogind /etc/pam.d/* /etc/pam.d/common-session:session optional pam_elogind.so /etc/pam.d/elogind-user:session optional pam_elogind.so And contents of elogind-user are: # This file is part of systemd. # # Used by systemd --user instances. account required pam_unix.so session required pam_selinux.so close session required pam_selinux.so nottys open session required pam_loginuid.so session optional pam_keyinit.so force revoke session optional pam_elogind.so I've commented out all of these lines. Presumably elogind-user is absolutely pointless on a Devuan system anyway? Thanks again ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] disable elogind messages?
On Sun, Nov 24, 2019 at 07:14:48AM -0600, hal wrote: > > [...] > I've commented out all of these lines. Presumably elogind-user is > absolutely pointless on a Devuan system anyway? Hmm, I wouldn't edit /etc/pam.d/common-* directly. Contents in these files are managed and may/might change during package upgrade/install back. Also on a desktop machine I would choose elogind to be working for normal logins since it is needed for most desktop environments to mount/unmount removable media and to shutdown/reboot the system. If you really want do disable elogind for everything I would recommend to: a) either run "/usr/sbin/pam-auth-update" and unmark elogind entry in the dialog appearing (This will actually change all /etc/pam.d/common* files permanently). And disable elogind service running "/usr/sbin/update-rc.d elogind remove" b) Or just remove libpam-elogind and probably also elogind itself (if its not a dependency of some other package) Otherwise I'd suggest to only edit /etc/pam.d/ files to disable elogind for corresponding service if needed. This should only be required for files including "common-session". cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Method https has died unexpectedly!
Hi, the emmc card of my Odroid U3 (armhf) has died, so I had to reinstall the whole OS on a spare sd card. I installed the latest Debian Jessie image for that U3, then migrated it to Devuan Ascii. Now there is a problem with the apt https transport. On apt-get update I get the following errors: E: Method https has died unexpectedly! E: Sub-process https received a segmentation fault. E: Method /usr/lib/apt/methods/https did not start correctly Any ideas how to debug this error? Jochen ___ 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 2019-11-24 06:16, Denis Roio wrote: On Sat, 23 Nov 2019, Andrew McGlashan via Dng wrote: I have tried ASCII 2.0 -- but it looks like there is a new 2.1 version just about to be announced? yes, there is a 2.1 ready and most of it is thanks to the passionate work of volunteers, among the few fsmithred, rrq, golinux, centuriondan and evilham. I believe there wouldn't be this point release without them. One major omission . . . a shout out to LeePen who is doing a lion's share of the work setting up the new buildhost(s) on devuan infrastructure over which Devuan devs will have control. Once completed, Beowulf can move forward. Here are his notes from the last meet. LeePen has also been active promoting init diversity within Debian: ### LeePen New Devuan infra status: jenkins - Running on jenkins.devuan.dev. - Has existing buildhosts plus 4 new (i386, amd64, arm64 and armhf; armel is wip) - Issues with importing existing users. Can people with ci.devuan.org logins please try them on jenkins.devuan.dev and report back? # still to do: - import current jobs from ci.devuan.org (if this is possible?) - #devuan-ci output: same channel new nickname or new channel? - get releasebot to send it some jobs for testing. - backups? dak - installed on devuan ganeti host. - existing package archive imported. # still to do: - resolve issues with built-using dependencies (only affects debian-installer). - lots of cruft to clean out. - cron jobs. - send jenkins jobs output to new dak (I think this is releasebot again). In parallel with production dak for testing? - get amprolla(s) to use new dak. - consider merge of current debian git HEAD. - backups? We are not doing what we do just to pick up our marbles and go home. ;) golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] INJ - Init Freedom inJector (was: cannot exist without the help of Debian)
On Fri, 22 Nov 2019 20:55:52 +0100 viverna wrote: > il devuanizzato spiralofhope il > 22-11-19 20:25:03 ha scritto: > >On Fri, 22 Nov 2019 18:31:25 +0100 > >viverna wrote: > > > >> I propose this: a script called INJ - Init Freedom inJector > >> > >> I wrote this summer in this list about a possibility of inject init > >> run scripts (for example runit) in all Devuan packages > >> automatically. > >> > >> I'm writing a simple script that inject init diversity in a single > >> package. > >> ... > >> I would like to release the script in the next days with AGPL3 but > >> tell me. > > > > > >Do you mean AGPL3 as in the GNU Affero General Public License? > > > > https://www.gnu.org/licenses/agpl-3.0.en.html > > > >If so, please don't use the language "AGPL3 or later" since the "or > >later" could be a sabotaged license in the future. > Yes, GNU Affero General Public License 3.0 (no later). > But i'm willing to choose other license if change is helpful to save > Devuan. I think Affero is a bridge too far, as it basically prevents people from making a profit using Free Software. Why not make it whatever license is most used in Devuan (probably GPL2 or GPL3)? I agree with spiralofhope not to use the "or later" designation, on any license, for the exact reason he states. Stallman might not always control the GPL: Perhaps some day Redhat will control it. 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] Devuan cannot exist without the help of Debian
On Fri, 22 Nov 2019 10:55:46 +0100 Denis Roio wrote: > At last, please, do not consider Devuan as an alternative solution > which will survive any outcome of this vote. > > Because I'm sure Devuan will not survive without Debian's help. Some time in 2015, I remember hearing the VUAs saying that Devuan would be a modification of Debian for some time, but would eventually become an independent distro of its own, to prevent a crisis like this one. How far is Devuan from being its own distro? > Devuan is much, much smaller than Debian in resources, people and > infrastructure, Take a look at how the Void Linux project does things. They have some kind of software machine that cranks out rolling release updates, despite the fact that they have very few developers or maintainers. I'm pretty sure Devuan could provide similar automation for a version based release. > and despite our efforts were useful to both, the > Debian project has done very little to help us so far. I expected this. From my viewpoint, and others' may vary, the events of 2014 showed Debian's constitution to be defective, their decision processes to be kangaroo courts, and for whatever reason they seem indebted to the Redhat/FreeDesktop axis. Long run, they probably can't be a long term partner or resource. [snip] > If the resolution nr.4 proposed by Ian Jackson will not pass, > Devuan will die. From my reading of https://www.debian.org/vote/2019/vote_002 , it seems to me that Proposal E is best, D is second best, with A 3rd best: Each of them at least as good as what we have now. Proposal C should trigger a separation from Debian, of course, and proposal B is worrying. Three of the five are no worse than we have now, and one of them (E) represents a reversal of systemd's encroachment. I wrote to Ian Jackson earlier today describing my views on the subject. I'm not a Debian user nor dev nor maintainer, so I think that's the best I can do. Perhaps everybody should *nicely* write Ian: Remember, he's our friend, and if he'd succeeded in the 2014 GR, there would have been no need for Devuan. 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] Devuan cannot exist without the help of Debian
On 2019-11-24 19:23, Steve Litt wrote: On Fri, 22 Nov 2019 10:55:46 +0100 Denis Roio wrote: At last, please, do not consider Devuan as an alternative solution which will survive any outcome of this vote. Because I'm sure Devuan will not survive without Debian's help. Some time in 2015, I remember hearing the VUAs saying that Devuan would be a modification of Debian for some time, but would eventually become an independent distro of its own, to prevent a crisis like this one. How far is Devuan from being its own distro? Devuan is much, much smaller than Debian in resources, people and infrastructure, Take a look at how the Void Linux project does things. They have some kind of software machine that cranks out rolling release updates, despite the fact that they have very few developers or maintainers. I'm pretty sure Devuan could provide similar automation for a version based release. and despite our efforts were useful to both, the Debian project has done very little to help us so far. I expected this. From my viewpoint, and others' may vary, the events of 2014 showed Debian's constitution to be defective, their decision processes to be kangaroo courts, and for whatever reason they seem indebted to the Redhat/FreeDesktop axis. Long run, they probably can't be a long term partner or resource. [snip] If the resolution nr.4 proposed by Ian Jackson will not pass, Devuan will die. From my reading of https://www.debian.org/vote/2019/vote_002 , it seems to me that Proposal E is best, D is second best, with A 3rd best: Each of them at least as good as what we have now. Proposal C should trigger a separation from Debian, of course, and proposal B is worrying. Three of the five are no worse than we have now, and one of them (E) represents a reversal of systemd's encroachment. I wrote to Ian Jackson earlier today describing my views on the subject. I'm not a Debian user nor dev nor maintainer, so I think that's the best I can do. Perhaps everybody should *nicely* write Ian: Remember, he's our friend, and if he'd succeeded in the 2014 GR, there would have been no need for Devuan. SteveT Note that there is now a 5th option: Proposal E Proposer Dmitry Bogatov [kact...@debian.org] [text of latest proposal] Proposal E Seconds Ian Jackson [i...@debian.org] [mail] Matthew Vernon [matt...@debian.org] [mail] Jonathan Carter [j...@debian.org] [mail] Kyle Robbertze [paddatrap...@debian.org] [mail] Axel Beckert [a...@debian.org] [mail] Brian Gupta [bgu...@debian.org] [mail] Simon Richter [s...@debian.org] [mail] Proposal E Choice 5: Init diversity is Required Being able to run Debian systems with init systems other than systemd continues to be of value to the project. Every package MUST work with pid1 != systemd, unless it was designed by upstream to work exclusively with systemd and no support for running without systemd is available. Software is not to be considered to be designed by upstream to work exclusively with systemd merely because upstream does not provide, and/or will not accept, an init script. golinux ___ 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 Fri, 22 Nov 2019 18:31:25 +0100 viverna wrote: > No, we will not allow it! > I propose this: a script called INJ - Init Freedom inJector > > 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. > I'm writing a simple script that inject init diversity in a single > package. > Workflow I imagined it like this: > - Init script experts write run scripts for all daemon based on rules > specified below (also sysvinit) > - Script read a package one by one: > - Open package in tmp dir > - For all init system included in Devuan: > - If exists run script for package > - Insert run script > - Edit if requested postinst and prerm script > - Create package from tmp dir > - New package created (automatically) > > Run script resides in /var/local/INITSYSTEM/ and are copied in the > package. Nice! > > Script I wrote support epoch and runit. Other init can be supported > if implemented. Thank you so much for remembering Epoch! It's excellent and fast. Although Epoch was last maintained in 2016, it was the fastest and easiest init to configure, and my experience was that it was in the same ballpark, boot time wise, as systemd and runit. Thank you for doing runit! Runit is probably the simplest init system around, which is important for some people. Also, runit is similar enough to s6 that runit scripts could probably be converted to s6 scripts by a simple AWK program. One more thing: Systemd sucks, but their unit files are pretty good specifications for any daemon start file: * Run as what user? * Run as what group? * Expect the daemon to background itself? * What services must be online for this daemon to function? * What is the exact syntax for the daemon to run properly? * What must happen before the daemon is run? * What must happen after the daemon finishes? I think we could get 90% of the way to a set of legitimate daemon start scripts by running each unit file through a program to produce a daemon start file for a different init system. > For example /var/local/runit/openssh-server/sshd/run > #!/bin/sh > exec 2>&1 > sv start rsyslogd || exit 1 > mkdir -p /run/sshd > exec /usr/sbin/sshd -D Nice! I've been testing for functioning dependencies, and just quitting if not functioning, on the theory that eventually the dependency would be started. Your method is much more proactive. 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
[DNG] Affero: was - Init Freedom inJector (was: cannot exist without the help of Debian)
On Sat, 23 Nov 2019 09:54:31 + (UTC) Alexis PM via Dng wrote: > GNU AGPL version 3 is the best. Because? ... I'd like to see your list of benefits vs disadvantages. If I used an Affero program as a part of my for-profit website, would I be requires to provide the entirety of my website code to all comers, thereby creating competitors who are not in debt for the research and development I used to create it? Would I need to consult a $400/hr lawyer to answer this question? Would an Affero license put a chilling effect on using its code to make money, and if so, would your job be one of the victims? I know that the same arguments could be made about GPL2's copyleft facilities, but not to the same degree. If I init my for-profit web-server using a series of Affero-licensed daemon startup files, do I then need to supply my web code to those who request it? Are you sure? 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] Devuan cannot exist without the help of Debian
On Sun, 24 Nov 2019 19:34:19 -0600 goli...@devuan.org wrote: > On 2019-11-24 19:23, Steve Litt wrote: > > On Fri, 22 Nov 2019 10:55:46 +0100 > > Denis Roio wrote: > > > >> At last, please, do not consider Devuan as an alternative solution > >> which will survive any outcome of this vote. > >> > >> Because I'm sure Devuan will not survive without Debian's help. > > > > Some time in 2015, I remember hearing the VUAs saying that Devuan > > would be a modification of Debian for some time, but would > > eventually become an independent distro of its own, to prevent a > > crisis like this one. How far is Devuan from being its own distro? > > > >> Devuan is much, much smaller than Debian in resources, people and > >> infrastructure, > > > > Take a look at how the Void Linux project does things. They have > > some kind of software machine that cranks out rolling release > > updates, despite the fact that they have very few developers or > > maintainers. I'm pretty sure Devuan could provide similar > > automation for a version based release. > > > >> and despite our efforts were useful to both, the > >> Debian project has done very little to help us so far. > > > > I expected this. From my viewpoint, and others' may vary, the > > events of 2014 showed Debian's constitution to be defective, their > > decision processes to be kangaroo courts, and for whatever reason > > they seem indebted to the Redhat/FreeDesktop axis. Long run, they > > probably can't be a long term partner or resource. > > > > [snip] > > > >> If the resolution nr.4 proposed by Ian Jackson will not pass, > >> Devuan will die. > > > > From my reading of https://www.debian.org/vote/2019/vote_002 , it > > seems to me that Proposal E is best, D is second best, with A 3rd > > best: Each of them at least as good as what we have now. Proposal C > > should trigger a separation from Debian, of course, and proposal B > > is worrying. > > > > Three of the five are no worse than we have now, and one of them (E) > > represents a reversal of systemd's encroachment. > > > > I wrote to Ian Jackson earlier today describing my views on the > > subject. I'm not a Debian user nor dev nor maintainer, so I think > > that's the best I can do. Perhaps everybody should *nicely* write > > Ian: Remember, he's our friend, and if he'd succeeded in the 2014 > > GR, there would have been no need for Devuan. > > > > SteveT > > > > Note that there is now a 5th option: > > Proposal E Proposer > > Dmitry Bogatov [kact...@debian.org] [text of latest proposal] > Proposal E Seconds > > Ian Jackson [i...@debian.org] [mail] > Matthew Vernon [matt...@debian.org] [mail] > Jonathan Carter [j...@debian.org] [mail] > Kyle Robbertze [paddatrap...@debian.org] [mail] > Axel Beckert [a...@debian.org] [mail] > Brian Gupta [bgu...@debian.org] [mail] > Simon Richter [s...@debian.org] [mail] > > Proposal E > Choice 5: Init diversity is Required > > Being able to run Debian systems with init systems other than systemd > continues to be of value to the project. Every package MUST work with > pid1 != systemd, unless it was designed by upstream to work > exclusively with systemd and no support for running without systemd > is available. > > Software is not to be considered to be designed by upstream to work > exclusively with systemd merely because upstream does not provide, > and/or will not accept, an init script. > > golinux Yes! That's the one that rolls back the systemd encroachment, and I'm cheering for that one. 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
