Re: [DNG] ..forensics on systemd or journald logs

[John Hughes]

On 22/11/17 17:35, Arnt Karlsen wrote:

..to reiterate: Is there a way to decode and read those binary
systemd journal logs on classic POSIX/Unix etc forensic systems
_not_ running systemd?


Of course.

Either install a tool that does it for you, i.e. journalctl, or write a 
tool to do it using the publicly available documentation.



..the "strings" approach suggested by John Hughes requires an intimate
knowledge of systemd and might be relevant if the investigations were
on "systemd sabotaging Devuan playing _new_ zero-day dirty tricks."


Intimate knowledge?  No, all it requires knowing is that most of the 
fields in a systemd journal are ascii keyword=value pairs.


Tell you what, I'll see if I can write a little perl script to output a 
systemd journal in a format a little more pretty than strings(1) for 
you, give me a day, ok?



..so, the systemd crowd should have an interest in e.g. exposing
"Devuan incompetence and paranoia" by coming up with an easy way
to decode and read binary systemd journal logs without having to
run systemd, to prove their case on "Devuan incompetence and
paranoia on systemd", rather than confirm my current belief.


incompetence is your word, not mine.  Paranoia seems to fit some 
people.  For example, what do you mean by "_new_ zero-day dirty tricks" 
above?


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

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[John Hughes]

On 22/11/17 15:08, Aldemir Akpinar wrote:


On 22 November 2017 at 17:03, John Hughes <j...@atlantech.com 
<mailto:j...@atlantech.com>> wrote:


On 22/11/17 14:18, Aldemir Akpinar wrote:


Could you elaborate why are you comparing a relational database
system where its files must be binary with a logging system where
its files doesn't need to binary?



Need?  Nothing "needs" to be in binary[*].  It's a design
decision.  Do the advantages of a structured format (mostly speed)
override the disadvantages (higher costs for access if the reader
software is unavailable?





That's still not the answer to my question!


There is no simple answer to your question because your question 
contains the logical fallacy of "begging the question", i.e. the 
question assumes its own answer.


You said "why are you comparing a relational database system where its 
files must be binary with a logging system where its files doesn't need 
to binary?"


That assumes that the files of a relational database system *must* be 
binary, which is simply untrue and that there is no advantage to making 
the files of a logging system binary which is debatable.


The answer to your question is that there is no one single answer.  The 
system designer will make his decisions about the different tradeoffs.



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

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[John Hughes]

On 22/11/17 14:18, Aldemir Akpinar wrote:


That's routine. Few readers read everything that can be read. For
example, look at postgres. Its binary file format reveals quite a
bit more than you can get using psql, and by design: The writer
and binary format are intended for storing things quickly and
reliably, and the reader for reading what was stored. Anything
that's in the file but wasn't stored by instruction of an SQL user
is uninteresting to psql, and the file format writer has no
particular reason to avoid storing other information.




Could you elaborate why are you comparing a relational database system 
where its files must be binary with a logging system where its files 
doesn't need to binary?




Need?  Nothing "needs" to be in binary[*].  It's a design decision. Do 
the advantages of a structured format (mostly speed) override the 
disadvantages (higher costs for access if the reader software is 
unavailable?


[*] or, to put it another way -- *everything on a computer is in 
binary*.  "Text" files are binary.  The question is how easy is it to 
decode the file format.  It seems obvious that a "text" file is easy to 
decode, everyone knows the format (but what character set is it in?), 
but don't forget that the "text" file is stored on a filesystem, which 
is itself a complicated "binary" structure.  When you're talking about 
"forensics", i.e. looking at something that may be broken in exciting 
ways, it's quite naïve to assume that you can just mount the filesystem 
(which one?) and use cat, vi, grep or whatever.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 22/11/17 12:32, KatolaZ wrote:

On Wed, Nov 22, 2017 at 12:24:28PM +0100, John Hughes wrote:


I was amazed that KatolaZ couldn't imagine any way of reading text from a
file without a special application, doesn't he have strings(1) on his
"forensic system"?


As for journalctl, you forget to mention that it is not available as a
separate component from systemd.


"Not available"?  Attached to systemd with epoxy?  Or an independent 
executable that could easily be installed on a forensic system the good 
old fashioned way.  Or, if you prefer, just install the systemd package 
and use some other init system:



I had never thhougt that I would have been suggested to look at logs
by grepping the results of "strings" on a binary file. But I
understand that this is considered "amazing technological progress" in
some camps.


Whatever gets the job done.  Personally I'd just install the application 
that knows how to read the file, but if I was unable to do that for some 
reason or other I'd use one of the many useful tools Unix like systems 
come with rather than claiming the job was impossible.



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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 22/11/17 11:42, Jaromil wrote:

On Wed, 22 Nov 2017, John Hughes wrote:


No way to do that?  Seriously?  No way at all?

jeez, is John a troll?


My little joke about the usefulness of the systemd journal in diagnosing 
the /etc/rc.local problem could conceivably be considered trolling.  The 
skirt-clutching replies to it could also be considered trolling.


I was amazed that KatolaZ couldn't imagine any way of reading text from 
a file without a special application, doesn't he have strings(1) on his 
"forensic system"?



it would explain his constant questions, keeping ignoring details that
are already explicit in the thread and wasting our time.


What explicit details have I ignored?  As far as I can see you've never 
provided any link to the original complaints about /etc/rc.local not 
being run, just some ill-informed rubbish on stackoverflow(!) about 
things being "deprecated".


You, personally, have repeatedly ignored information I provided, for 
example:


You: 2017-11-21 14:20 +100


is it the case that one must run two systemctl commands in order for
rc.local to be processed, or will rc.local just be found and executed? 


Me: 2017-11-21 14:48 +100, in reply:


No, no systemctl commands are needed, systemd-rc-local-generator will
enable rc-local.service if /etc/rc.local is executable, 


You, later in the same thread: 2017-11-21 15:19 +100

Then I believe we also agree that rc.local is a serious regressions? 


Me, in reply:

What regression? 


You: 2017-11-21 16:18 +100


the fact that besides creating it and making it executable, one must
also activate the service unit.


But I'd already told you that "no systemctl commands are needed"!

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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 22/11/17 08:48, Didier Kryn wrote:

Le 22/11/2017 à 07:19, John Hughes a écrit :
Is there any way to read a file in format X without a program that 
reads format X? 


    The question is why use yet another "proprietary format"? Just to 
force people to be use systemd for every task they need to do with 
their computer.


Here we go again with the "assume bad faith".

The systemd journal format is not a proprietary format.

The systemd developers have said why they designed the format, but you 
think they have conspiratorial reasons for it.


You are not even forced to use systemd to read journald log files, you 
can have journalctl on a system not running systemd.


Hell, if you want you can just use strings(1).

strings /run/log/journal/bea434ed778c45fca34c5986c88ac085/system.journal 
| grep MESSAGE=


Personally I couldn't give a toss about the format, what's great about 
the journal is that it captures everything, especially things that would 
get written to the console and lost forever on a sysvinit based system.  
The original point was that the problem the bitcoin developers 
complained about should have been easy to diagnose if they were using 
systemd.  Since they weren't then whatever went wrong with their 
/etc/rc.local just scrolled off into outer space like the beginning of a 
Star Wars film with nobody watching.

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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 21/11/17 19:46, Jaromil wrote:

On Tue, 21 Nov 2017, John Hughes wrote:


Come to think about it, if the problem was that their rc.local
was failing somewhere then they should be able to see that in the
output of systemctl or journalctl.

Assuming they're using systemd, of course.  :-)

Not really. Its not just me, systemd is not considered to be safe for
use by any security expert I know of (and I know more than I wish...)
a legendary Bitcoin core developer (luke-jr) is explicitly encouraging
the switch to Devuan, while many already use it to run full nodes
using bitcoin-knots. One day we may even release a Devuan-based distro


So, this whole /etc/rc.local kerfuffle, it happened on a system with 
systemd or sysvinit?



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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 22/11/17 02:59, Arnt Karlsen wrote:

On Tue, 21 Nov 2017 18:21:14 +0100, John wrote in message
:


(Damn but the systemd journal is great :-))

..is there a way to decode and read those binary systemd journal logs
on classic POSIX/Unix etc forensic systems _not_ running systemd?


Is there any way to read a file in format X without a program that reads 
format X?


I suppose you could scatter iron filings on the disk the use a scanning 
electron microscope to examine their positions and, using paper, pencil 
and a copy of the systemd doc work out the contents by hand.


Or, being endowed with the minimum level of foresight necessary for 
survival have a forensic system that includes tools for reading the file 
formats you're likely to find  on the system you want to post-mortem.



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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 21/11/17 17:53, Jaromil wrote:

On Tue, 21 Nov 2017, John Hughes wrote:


I followed your link to "gitian-building-setup-gitian-debian.md"

Which says that you need to create the rc.local and reboot.  I see no
mention of systemctl.  Am I looking in the wrong place?

nono, as I wrote: that script doesn't works anymore, if ran on a
freshly debootstrapped version of Debian 9. It seemed that rc.local
wasn't executed anymore. But there is some confusion, since both brctl
and ifconfig are legitimately deprecated. Assuming you have done
better checking, then the failure may be caused by them bailing out.


Ok, I'll try a test:

   root@cufic:~# aptitude purge initscripts
   The following packages will be REMOVED:
  initscripts{p}
   0 packages upgraded, 0 newly installed, 1 to remove and 7 not upgraded.
   Need to get 0 B of archives. After unpacking 213 kB will be freed.
   Do you want to continue? [Y/n/?]
   (Reading database ... 188141 files and directories currently installed.)
   Removing initscripts (2.88dsf-59.9) ...
   Processing triggers for systemd (232-25+deb9u1) ...
   Processing triggers for man-db (2.7.6.1-2) ...
   (Reading database ... 188123 files and directories currently installed.)
   Purging configuration files for initscripts (2.88dsf-59.9) ...
   dpkg: warning: while removing initscripts, directory '/var/lib/urandom' not 
empty so not removed
   Processing triggers for systemd (232-25+deb9u1) ...
 
   root@cufic:~# ls -l /etc/rc.local

   -rwxr-xr-x 1 root root 306 Jan 31  2017 /etc/rc.local
   root@cufic:~# rm /etc/rc.local
   root@cufic:~# systemctl reboot

   ...

   ... it boots up ...

   john@cufic:~$ systemctl status rc-local.service
   ● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor 
preset:
  Drop-In: /lib/systemd/system/rc-local.service.d
   └─debian.conf
   Active: inactive (dead)

Seems it wasn't run 'cos rc.local doesn't exist.

Make a rc.local:

   root@cufic:~# cat > /etc/rc.local
   #! /bin/sh

   # Test rc.local

   echo Hello from rc.local

   exit 0
   ^D
   root@cufic:~# chmod a=rx /etc/rc.local
   root@cufic:~# ls -l /etc/rc.local
   -r-xr-xr-x 1 root root 62 Nov 21 18:08 /etc/rc.local
   root@cufic:~# systemctl reboot

   ...

   ... it boots up.

   root@cufic:~# systemctl status rc-local.service
   ● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor 
preset:
  Drop-In: /lib/systemd/system/rc-local.service.d
   └─debian.conf
   Active: active (exited) since Tue 2017-11-21 18:10:23 CET; 1min 9s ago
  Process: 595 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
   CGroup: /system.slice/rc-local.service

   Nov 21 18:10:23 cufic systemd[1]: Starting /etc/rc.local Compatibility...
   Nov 21 18:10:23 cufic rc.local[595]: Hello from rc.local
   Nov 21 18:10:23 cufic systemd[1]: Started /etc/rc.local Compatibility.


So, it looks to me if /etc/rc.local exists and is executable then 
systemd runs it as I thought.


If it didn't work for the bitcoin guys then the problem is somewhere else.

(Damn but the systemd journal is great :-))

Come to think about it, if the problem was that their rc.local was 
failing somewhere then they should be able to see that in the output of 
systemctl or journalctl.


Assuming they're using systemd, of course.  :-)


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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 21/11/17 16:19, Jaromil wrote:


no, the "rumors" I refer to are, as I said, coming from an upstream
project whose CI has broken.


You said:


Here the rumors I've heard from bitcoin core development: a CI script
was broken for three reasons, of which the mandatory activation of
rc.local via systemctl is just one
https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-debian.md


I followed your link to "gitian-building-setup-gitian-debian.md"

Which says that you need to create the rc.local and reboot.  I see no 
mention of systemctl.  Am I looking in the wrong place?




I'm glad we also have an important take away for Devuan as Katolaz
points out: to mark the initscripts package as important.


That'll ensure that rc.local exists and is executable, but not that it's 
run -- that'll depend on the init system you're using.


If it's systemd or sysvinit it'll work, for others, maybe, maybe not.

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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 21/11/17 16:19, Jaromil wrote:

On Tue, 21 Nov 2017, John Hughes wrote:


Then I believe we also agree that rc.local is a serious regressions?

What regression?

the fact that besides creating it and making it executable, one must
also activate the service unit.


No, you don't.  systemd runs systemd-rc-local-generator at boot time and 
after any systemd configuration change.  You don't have to activate the 
unit, that's done for you.

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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 21/11/17 15:53, KatolaZ wrote:


Also, it is not clear to me *when* the automagic systemd tool that
should create the systemd service (if rc.local is executable) is
run.


man systemd.generator
...
   Generators are small binaries that live in
   /usr/lib/systemd/user-generators/ and other directories listed
   above.
   systemd(1) will execute those binaries very early at bootup and
   at configuration reload time — before unit files are loaded.
...



What matters is that we need to retain initscripts as "important".


If you have sysvinit then it's a damn site more than "important", it's a 
dependency for sysvinit-core.


--
John Hughes, CalvaEDI S.A.S. -- An Esker Company

<john.hug...@calva.com>
+33 1 4313 3131

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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 21/11/17 15:20, Jaromil wrote:

dear John and Olaf,

Thanks for proving me wrong, this is exactly what I hoped for.


I'm not actually sure you've been "proved wrong" -- in the case of a 
Debian 9 system without the initscripts package installed (i.e. a fresh 
install with systemd as pid 1 for example) then /etc/rc.local will not 
be automatically created.  However if it *is* created then systemd will 
run it.



I also note as you point out that this behavior may be
counterproductive for the public perception of this project: a way or
another I also represent Devuan and maybe I should hold off this
attitude and post only things that I am sure of. This is difficult for
me, since I conceive spaces for debate as this and other mailinglists
as spaces where to share doubts, fears, needs and dreams even more
than findings and announcements, for which an article or a twit
@DevuanOrg may be better.


There can be nothing wrong in admitting ignorance or searching for 
information.  However making strong, even aggressive or insulting, 
statements based on partial knowledge seems unlikely to advance the 
cause of Peace on Earth.  :-)




while the rc.local case its just that people don't care
about the regressions introduced by systemd.


Except that systemd introduces no regressions with rc.local.  In fact 
it's systemd that includes the compatibility code to make sure that 
/etc/rc.local is run if it exists.  This comes from the systemd team, 
not from Debian:


rc-local-generator.c

  Copyright 2010 Lennart Poettering
  Copyright 2011 Michal Schmidt



Then I believe we also agree that rc.local is a serious regressions?


What regression?


because it now needs to be activated via two new systemctl commands,


No it doesn't.  The systemd-rc-local-generator is run by systemd, users 
don't need to worry about it.


https://www.freedesktop.org/software/systemd/man/systemd.generator.html


In Debian right now I don't even see a debate,


A debate about what?  Whether rc.local should be run?  Whoever said it 
shouldn't be?  Or that it won't be in the future?



only rumors of "deprecation" in other
avenues. Whatever that may mean for Debian and its future.


Rumors.  From some of the least reliable tech sites on the web 
(stackoverflow!  Ack Pfft!).  Did you see any of these "rumors" on an 
actual Debian site or mailing list?


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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 21/11/17 14:54, Rowland Penny wrote:

On Tue, 21 Nov 2017 14:48:49 +0100
John Hughes <j...@atlantech.com> wrote:


No, no systemctl commands are needed, systemd-rc-local-generator will
enable rc-local.service if /etc/rc.local is executable, which it is
by default on Debian Stretch (AKA Debian 9).


Yes, but will 'systemd-rc-local-generator' exist on a Devuan OS where
no systemd components are loaded by default ??


Obviously not.

But what does that have to do with the price of eggs in China?  If 
you're using sysvinit instead of systemd then, on a Debian 9 system 
/etc/init.d/rc.local will run /etc/rc.local.  (How this works for other 
init systems is left as an exercise for the implementer).



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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 21/11/17 11:58, Olaf Meeuwissen wrote:

A quick check of the packages that would pull [ initscripts ] in (as per 
massaged
`apt-cache rdepends`) on Stretch gives:

   $ apt-cache rdepends initscripts | sed -n '/^ /p' | while read pkg; do \
 echo $pkg ; apt-cache depends $pkg | grep initscripts; done \
 | sed -n '/^[^ ]/{ H; N; /Depends/P }'
   sysvinit-core


Aha.  My systems have mostly been upgraded from Jessie -- I guess that's 
why they have initscripts installed, it seems nothing else would force 
them to have it.


So, it seems to me that the actual state of /etc/rc.local in Debian 9 is:

If you have the initscripts package installed then /etc/rc.local will be 
created for you (if it doesn't exist) and it will be run (if you are 
using sysvinit or systemd at least).


If you don't install initscripts (i.e. if you're using systemd and you 
don't explicitly install it or something that depends on it) then 
/etc/rc.local will not be created for you, but will be automatically run 
if it does exist (and is executable).


I'll be installing some new Stretch systems later this week, if I find 
anything different I'll get back to the list.

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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 21/11/17 14:21, Jaromil wrote:

On Tue, 21 Nov 2017, John Hughes wrote:


On 20/11/17 11:30, Jaromil wrote:

  1- it [ rc.local ] is not created by default

It exists on my stretch systems.

I always and only mean Debian 9. So I will reformulate:

1- /etc/rc.local does not exist by default on Debian 9.


Debian Stretch is Debian 9.

/etc/rc.local exists by default on Debian 9



this is not a major problem since most scripts won't fail.


  2- it is not executed in Debian Stretch (9) even if existing

I, as you might have guessed, use systemd, so rc.local is started by
rc-local.service:

is it the case that one must run two systemctl commands in order for
rc.local to be processed, or will rc.local just be found and executed?


No, no systemctl commands are needed, systemd-rc-local-generator will 
enable rc-local.service if /etc/rc.local is executable, which it is by 
default on Debian Stretch (AKA Debian 9).



I know about rc-local.service, my point is not about that being
available.

I believe both points 1 and 2 are regressions.

2 is a breaking regression in most setups.


What regressions?

https://upload.wikimedia.org/score/i/x/ixrxdpiezwcsj11b0mb4buzmt7p4025/ixrxdpie.ogg
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 20/11/17 11:30, Jaromil wrote:

1- it [ rc.local ] is not created by default


It exists on my stretch systems.  As  Olaf Meeuwissen said it is created 
by initscripts.postinst:


   #
   # Create /etc/rc.local on first time install and when upgrading from
   # versions before "2.86.ds1-16"
   #
   if dpkg --compare-versions "$PREV_VER" lt "2.86.ds1-16"
   then
    if [ ! -e /etc/rc.local ]; then
    cat << EOF > /etc/rc.local
   # rc.local
   #
   # This script is executed at the end of each multiuser runlevel.
   # Make sure that the script will "exit 0" on success or any other
   # value on error.
   #
   # In order to enable or disable this script just change the execution
   # bits.
   #
   # By default this script does nothing.

   exit 0
   EOF
    # make sure it's enabled by default.
    chmod 755 /etc/rc.local
    fi
   fi



2- it is not executed in Debian Stretch (9) even if existing


I, as you might have guessed, use systemd, so rc.local is started by 
rc-local.service:


   ● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static;
   vendor preset:
  Drop-In: /lib/systemd/system/rc-local.service.d
   └─debian.conf
   Active: active (exited) since Mon 2017-10-30 11:03:59 CET; 3
   weeks 1 days ago
  Process: 655 ExecStart=/etc/rc.local start (code=exited,
   status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/rc-local.service


The service rc-local.service is:

   # This unit gets pulled automatically into multi-user.target by
   # systemd-rc-local-generator if /etc/rc.local is executable.
   [Unit]
   Description=/etc/rc.local Compatibility
   ConditionFileIsExecutable=/etc/rc.local
   After=network.target

   [Service]
   Type=forking
   ExecStart=/etc/rc.local start
   TimeoutSec=0
   RemainAfterExit=yes
   GuessMainPID=no
   # This unit gets pulled automatically into multi-user.target by
   # systemd-rc-local-generator if /etc/rc.local is executable.
   [Unit]
   Description=/etc/rc.local Compatibility
   ConditionFileIsExecutable=/etc/rc.local
   After=network.target

   [Service]
   Type=forking
   ExecStart=/etc/rc.local start
   TimeoutSec=0
   RemainAfterExit=yes
   GuessMainPID=no


The source of the generator, systemd-rc-local-generator, is at 
https://github.com/systemd/systemd/blob/master/src/rc-local-generator/rc-local-generator.c



please correct me if I'm wrong. That would help.


I think you're wrong.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I found a new reason to dislike debian...

[John Hughes]

On 21/11/17 00:09, zap wrote:



it is "very strange" and also "really stupid" that they waited this 
long...


People scratch the itches *they* have.  That's how free software works,



and even now, they still don't have it included in stretch... its 
really infuriating... but yeah... initially I didn't make my self clear...


*Stretch* is the development codename for Debian 9. It is the current 
stable  distribution, released 
2017-06-17. 


Stable.  Means no new packages.  If you want more up to date software 
use testing or unstable.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I found a new reason to dislike debian...

[John Hughes]

On 20/11/17 14:08, zap wrote:


On 11/20/2017 04:08 AM, John Hughes wrote:


Firmware is required, which can be provided by installing the 
firmware-atheros <https://packages.debian.org/firmware-atheros> 
package. Open firmware 
<https://wiki.debian.org/ath9k_htc/open_firmware> for this driver is 
also available in the firmware-ath9k-htc 
<https://packages.debian.org/firmware-ath9k-htc> package starting 
from Buster. 


Wrong again. Trisquel, parabola, hyperbola... all have one thing in 
common, they use a completely blob free version of debian's non-free 
firmware version.  my complaint was that debian refuses to use that 
version so that I can use the dongle without having to use the blobs 
from the non-free area.


You are claiming that the package firmware-ath9k-htc contains non-free 
firmware or that it doesn't work on your dongle?


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

Re: [DNG] I found a new reason to dislike debian...

[John Hughes]

On 20/11/17 05:01, zap wrote:

there are dongle usbs whose firmware has been made free software, and I
cannot use this firmware from devuan, because some arrogant debian devs
were too lazy to remove the non-free package and add the free package.
so annoying.


Firmware is required, which can be provided by installing the 
firmware-atheros  
package. Open firmware 
 for this driver is 
also available in the firmware-ath9k-htc 
 package starting from 
Buster. 


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

Re: [DNG] rc.local removed from Debian 9, rly?

[John Hughes]

On 19/11/17 15:10, Jaromil wrote:

Following up after the conversation on redis, when we had the elected
Debian leader chiming in here to defend his position and keep deleting
init.d scripts, I still believe this is again "even worst than I
thought" and it is "vandalism".

But Jaromil, as Chris Lamb pointed out that is not what happened:

Chris Lamb:

I am the maintainer of Redis in Debian. All I have done is removed some
ill-conceived hooks that were not used by anyone. I have not dropped
sysvinit support and nor do I have any intention to do so. I only ask
politely that you do stop to refering to my work as "vandalism".

To summarise.

1. the upstream redis distribution does not include an init script. 
(There is an example init script in their git, but nothing in the 
distributed tarball).


2. Debian wrote their own init script.

3. At some point they added an undocumented feature to their init 
script.  This feature does not exist in the upstream example init script.


4. Since the feature was buggy, and since it had never been documented, 
Chris Lamb removed it.


5. Some people misread the commit message as saying that sysvinit 
support was being dropped.  They didn't check whether that was the case 
by looking at the publicly available package and source.


Is this the Devuan policy?  "Assume bad faith"?

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

Re: [DNG] Please provide systemd-free libreswan package

[John Hughes]

On 17/11/17 17:04, John Hughes wrote:

On 17/11/17 16:38, Arnt Gulbrandsen wrote:

Didier Kryn writes:
    That's why a bunch of people have endeavoured replacing 
systemd-udev by mdev or mdevd, something much simpler to configure 
and not locked-in. The only issue now is that sysfs is unstable on 
purpose to force libudev on people (sysfs is developped by the same 
persons which develop udev).


Linus accepts that? Isn't that precisely what he exploded about a few 
weeks ago? https://lkml.org/lkml/2017/10/26/511



Broken link?


The lkml.org archive contains a broken link.  How odd.  There's another 
message from Linus with the same subject:


https://lkml.org/lkml/2017/10/26/524


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

Re: [DNG] Please provide systemd-free libreswan package

[John Hughes]

On 17/11/17 16:38, Arnt Gulbrandsen wrote:

Didier Kryn writes:
    That's why a bunch of people have endeavoured replacing 
systemd-udev by mdev or mdevd, something much simpler to configure 
and not locked-in. The only issue now is that sysfs is unstable on 
purpose to force libudev on people (sysfs is developped by the same 
persons which develop udev).


Linus accepts that? Isn't that precisely what he exploded about a few 
weeks ago? https://lkml.org/lkml/2017/10/26/511



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

Re: [DNG] Please provide systemd-free libreswan package

[John Hughes]

On 17/11/17 16:14, Rowland Penny wrote:

On Fri, 17 Nov 2017 15:54:39 +0100
John Hughes <j...@atlantech.com> wrote:


systemd, like init(1), doesn't just run on boot -- it's running
continuously.


Excuse me apologist troll, but that is the whole point, it shouldn't
have to.


It doesn't?  You have many systems without PID 1 running?

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

Re: [DNG] Please provide systemd-free libreswan package

[John Hughes]

On 17/11/17 15:48, Nelson H. F. Beebe wrote:

Thus, systemd represents a code base of about 455,000 to 833,000 lines
spread over 2201 files.

The main problem that systemd tries to solve is correct ordering of
startup script execution, a job that is done only at boot time.


systemd, like init(1), doesn't just run on boot -- it's running 
continuously.


Also don't forget that you're counting udev into the size of systemd.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Please provide systemd-free libreswan package

[John Hughes]

On 16/11/17 01:59, Steve Litt wrote:


This situation is nothing unexpected. Many of us predicted in 2014 that
Debian would continue throwing down all the anti-anti-systemd
obstructionism they could muster. It would not be unreasonable to
expect that the time will come where most Debian packages will fail to
provide sysvinit scripts.


Or, an alternative, non-conflictual interpretation -- people scratch the 
itches they have.



If/when this time comes, we have several alternatives:

1) Help the Debian maintainers, as several have suggested in this
thread.

2) Write our own sysvinit scripts, for Devuan only.

3) Write Process Supervisor scripts, and run daemons from a Process
Supervisor.


I personally don't like #1. The Debian maintainers are
obstructionists,  so I wouldn't help them: I wouldn't give them the
sweat off my W*(#RF(#*.


You wouldn't be giving any thing to the Debian developers, you'd be 
giving to the Debian *users* (and, therefore) to the users of every 
Debian derived distribution, including Devuan.



#2 is nice, helps give Devuan a unique brand, but IMHO making and
maintaining a good-for-all-setups sysvinit script is difficult and time
consuming. As a matter of fact, those horrible scripts necessary to
cover most cases, is what made people furious at sysvinit in the first
place: I don't think anyone cared about boot time or parallel
instantiation.


But you are outraged that the some Debian developers don't want to do 
this, accusing them of bad faith.


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

Re: [DNG] Please provide systemd-free libreswan package

[John Hughes]

On 15/11/17 15:30, Sam Protsenko wrote:

Recently "libreswan" package was added to Debian: [1]. But it only
contains systemd init script and lacks sysvinit script. Corresponding
bug was reported to Debian bug tracking system: [2]. But libreswan
maintainer refuses to include sysvinit script to his package

What Daniel Kahn Gillmor actually said was:


If anyone wants to propose specific patches to the debian packaging to
either have the main libreswan package automatically support sysvinit
(or any other initsystem) or produce a libreswan-sysvinit (or
libreswan-runit, etc) binary package, and that the patch author
volunteers to help test and maintain that system integration work over
time, i'd be open to reviewing and incorporating reasonable changes into
the debian packaging.


Which seems pretty reasonable to me.


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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 14/11/17 12:53, Rowland Penny wrote:

On Tue, 14 Nov 2017 12:40:02 +0100
John Hughes <j...@atlantech.com> wrote:


On 14/11/17 12:32, Joerg Reisenweber wrote:

On Tue 14 November 2017 10:42:48 John Hughes wrote:

Those who do not understand UNIX are condemned to reinvent it,
poorly

funny you quote that in this particular context. Seems to me the
whole mess introduced by systemd (incl the /usr/ disaster) is
exactly that: reinventing unix poorly

Why do you keep claiming the /usr problem is something to do with
systemd?

Probably because it does, it wasn't really a problem until systemd came
along and couldn't seem to fix it.



systemd has no problem with /usr being on a different filesystem *if the 
filesystem is mounted before systemd starts*.


Making sure /usr was mounted before It was needed *was* really a problem 
before systemd was invented, which is why various UNIX systems started 
using a merged /usr in the 1990's.



Do you know what the "sysv" in "sysvinit" refers to?

Yes, thank you.

Oh sorry, you want someone to tell you ;-)

'sys' == 'system'
'v' == Roman numeral four


For values of four that are very close to five.

sysvinit is the set of init scripts for UNIX System V, one of the last 
versions of which was SVR4.2

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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 14/11/17 12:32, Joerg Reisenweber wrote:

On Tue 14 November 2017 10:42:48 John Hughes wrote:

Those who do not understand UNIX are condemned to reinvent it, poorly

funny you quote that in this particular context. Seems to me the whole mess
introduced by systemd (incl the /usr/ disaster) is exactly that: reinventing
unix poorly


Why do you keep claiming the /usr problem is something to do with 
systemd?  Did systemd exist in 1991?  Do you know what the "sysv" in 
"sysvinit" refers to?


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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 14/11/17 08:30, Joerg Reisenweber wrote:

On Mon 13 November 2017 15:46:30 John Hughes wrote:

systemd didn't exist in 1991 when USL decided that for SVR4.2 /bin, /lib
and /sbin should just be symlinks to /usr.

And when did USL (whoever that is)


USL = UNIX System Laboratories, the successors to the more informal USG 
(Unix Systems Group) inside AT



decide that SVR4.2 doesn't care about being
able to run on any ARM SoC?


Of course SVR4.2 could be ported to an ARM SoC -- you'd just put /stand 
on the internal NAND.  (/stand was the SVR4.2 name for what Linux called 
/boot).



  And how's that relevant for Linux?


Those who do not understand UNIX are condemned to reinvent it, poorly.

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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 13/11/17 13:09, Joerg Reisenweber wrote:

On Sun 12 November 2017 21:54:36 Steve Litt wrote:

One more thing: What did people do before maybe 2010,
when /sbin, /bin, /usr/sbin, and /user/bin were four separate
directories? Was life that hard back then? Were develpers smarter?

I'd bet all and my butt on the latter ;-) It's just too obvious.

Maybe intitially it was just systemd cabal who noticed that managing
dependencies in init process isn't exactly a nobrainer and thus (and because
of feature creep like needing d-bus and other high level crap in init) and not
willing to cope with the fallout that correctly beem described as dependency
hell in package/lib dependencies decided to rather cram /usr/ into /


systemd didn't exist in 1991 when USL decided that for SVR4.2 /bin, /lib 
and /sbin should just be symlinks to /usr.



john@sylvania ~ > ls -l / | grep -e '->'
lrwxrwxrwx    1 root sys   8 Apr 15  2005 bin -> /usr/bin
lrwxrwxrwx    1 root sys   8 Apr 15  2005 ccs -> /usr/ccs
lrwxrwxrwx    1 root sys   9 Apr 15  2005 lbin -> 
/usr/lbin

lrwxrwxrwx    1 root sys   8 Apr 15  2005 lib -> /usr/lib
lrwxrwxrwx    1 root sys  10 Apr 15  2005 share -> 
/usr/share
lrwxrwxrwx    1 root sys   8 Apr 15  2005 shlib -> 
/usr/lib
lrwxrwxrwx    1 root root 11 Apr  3  2017 unix -> 
/stand/unix


(I don't have any machines still running UnixWare 1.0, hence the rather 
recent create dates).


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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 12/11/17 04:24, Joerg Reisenweber wrote:

On Tue 07 November 2017 17:50:27 John Hughes wrote:

The separation of / and /usr is a relic of really, really tiny disk sizes.

Like, for example, ARMv7 systems with a 128MB NAND to boot from, keeping /usr
on a separate storage like SSD? Doesn't sound like an obsolete ancient relic


I have a N900, that is not news to me and has already been addressed by 
Adam Borowski: 
https://lists.dyne.org/lurker/message/20171108.052040.5cb5ca3d.en.html



In the last case I'm aware of where someone tried a stock
system with a split, Maemo, the /usr split was deemed inadequate and they
instead decided to move most stuff to /opt while stuffing the usual 
places
with symlinks -- adapting packages enough to have / capable of booting 
would

require too much work.


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

Re: [DNG] [SOLVED] Re: Our servers are unreachable (Current outage at OVH)

[John Hughes]

On 09/11/17 13:08, KatolaZ wrote:

just to let you know that the outage at OVH has been resolved, and all
our services are now back online. None of the machines was actually
rebooted, so it seems it was just a network issue on the OVH site.


Lucky you.  Mine is still in some kind of routing maze -- packets get to 
TATA in London then get lost in the wilderness.


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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 08/11/17 03:33, Steve Litt wrote:

1) If a tree falls in the woods but there's nobody to hear it, did it
make a sound?
Recommended reading for Steve Litt and others who use a kill-file (not 
that he'll see this):


Wave Without a Shore by C.J. Cherryh


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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 17:50, John Hughes wrote:


The separation of / and /usr is a relic of really, really tiny disk 
sizes.


(The first machine I used had 8 megacharacter disks -- not megabyte, 
megacharacter.   Six bit characters.  Ok, it didn't run Unix.  :-)).


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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 17:41, dev wrote:


On 11/07/2017 10:29 AM, John Hughes wrote:

On 07/11/17 17:13, Klaus Ethgen wrote:

[ separate / and /usr ] is the best way to keep your /usr flexible to
further lvm grows for example.

Personally I have a / on a lvm2 volume.  Works OK for me, I see no loss
in flexibility.

Until a user fills up their home directory with kitten gifs and you can
no longer login because syslog has no space to write to /var.


Neither /home not /var are on /, for obvious reasons.  / is for 
mostly-static things that are owned by the OS or the admin.


The separation of / and /usr is a relic of really, really tiny disk sizes.


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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 17:13, Klaus Ethgen wrote:

[ separate / and /usr ] is the best way to keep your /usr flexible to
further lvm grows for example.


Personally I have a / on a lvm2 volume.  Works OK for me, I see no loss 
in flexibility.


Like I say, SVR4.2 deprecated separate /usr in the 1990's.  I haven't 
used a machine without the root filesystem being on a LVM type system 
(VXVM in fact) since around 1998.





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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 16:50, Klaus Ethgen wrote:



If you have an seperate /usr (what is not supported by the ignorance of
systemd) and that /usr on lvm and a kernel with no initrd (what does not
exist in the ignorance of systemd), then you are doomed and your system
will not boot anymore.

What does this have to do with systemd?

Well, Debian deprecated a separate /usr as systemd is not working good
with a separate /usr.


They actually deprecated it as many things were not working with a 
separate /usr.  systemd has no more or less problems than anything else 
that uses things on /usr.


I come from a Unix background -- separate /usr was deprecated in the 
1990's with SVR4.2, I'm kind of amazed it took Linux so long to catch up.


In this particular case it's a bit irritating, it could be fixed by 
moving liblz4 to /lib or by not linking the various lvm2 binaries 
against libsystemd.


Presumably devuan and debian will have differing ideas of how and 
whether this should be fixed.  :-)


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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 16:21, John Hughes wrote:

On 07/11/17 15:29, Klaus Ethgen wrote:


today I suffered by a heavy bug in lvm2. With version 2.02.175-1 it
starts to depend on library in /usr.


Which binary? What library in /usr?


So, it seems some things depend on lz4.  But nothing mentions it directly.

But, here's the problem -- lvm2 depends on 
/lib/x86_64-linux-gnu/libsystemd.so.0 and *that* depends on liblz4.


This is sad.

To allow /usr-less booting either lvm2 should not depend on libsystemd, 
or liblz4 should be moved to /lib.


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

Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable

[John Hughes]

On 07/11/17 15:29, Klaus Ethgen wrote:


today I suffered by a heavy bug in lvm2. With version 2.02.175-1 it
starts to depend on library in /usr.


Which binary? What library in /usr?


If you have an seperate /usr (what is not supported by the ignorance of
systemd) and that /usr on lvm and a kernel with no initrd (what does not
exist in the ignorance of systemd), then you are doomed and your system
will not boot anymore.


What does this have to do with systemd?

If your system uses sysvinit instead of systemd does it manage to mount 
/usr if /usr is on lvm?  How?

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

Re: [DNG] RMS: was Google abandons UEFI in Chromebooks

[John Hughes]

On 03/11/17 20:58, Edward Bartolo wrote:

I know little about this Hurd 'little' thing, but it gives me the
shivers like systemd.


Ah.  "I know little about it but I don't like it".


Similar to the latter, there is a small core at the centre with all
the other helper executables intercommunicating.


What?  I thought the criticism of systemd was that it was monolithic and 
it's "core" was too large!



Sounds too complicated to get the added advantage, of having a very
minimal kernel running with root privileges, while all other helper
executables that do not need root privileges, run with a lesser
priviledge.


Huh?  Are you against the idea or the implementation?



If I am remember well, MS Windows (the operating system) does have a
micro-kernel, but is it more efficient with an extra layer of
intercommunication?


In general the idea with microkernels is security and reliability, not 
performance -- microkernel boosters will generally handwave and claim 
the inefficiency is worth it and small anyway.


Before writing them off as fools don't forget that MacOS/iOS uses a 
microkernel (famously one of the biggest/slowest).




I will stay with Linux, even though it is a huge monolithic executable.


Like systemd?


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

Re: [DNG] RMS: was Google abandons UEFI in Chromebooks

[John Hughes]

On 03/11/17 21:08, J. Fahrner wrote:


Windows NT is based on DEC VMS, not a very modern OS ;-)


I.E. more "modern" than Unix.

Being "modern" is not always a good thing.  I'd have assumed that wasn't 
a controversial idea around here.


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

Re: [DNG] Redhat CEO answers questions

[John Hughes]

On 31/10/17 14:23, Aldemir Akpinar wrote:
In case you guys have missed, Jim Whitehurst, redhat ceo, answered 
some questions on slashdot, and of course many people asked about 
systemd. You can find the question and his answer here:


https://linux.slashdot.org/story/17/10/30/0237219/interviews-red-hat-ceo-jim-whitehurst-answers-your-questions?utm_source=feedly1.0mainlinkanon_medium=feed



Screw what he thinks about systemd, this bit:


My first calls usually start at 8 am as I'm driving to the office.


Means he should have his driving licence taken away before he kills someone.


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

Re: [DNG] Google abandons UEFI in Chromebooks

[John Hughes]

On 30/10/17 08:44, Dr. Nikolaus Klepp wrote:

Am Montag, 30. Oktober 2017 schrieb J. Fahrner:

https://osseu17.sched.com/event/ByYt/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google

Nice. But it they suffer from the "not invented here"-syndrome: instead of using prooven 
good busysbox, they rewrite userspace in GO .. oops, who "invented" Go and wants to push 
it to the users?



The stated reason for using go is that the system is delivered as source 
and compiled on the fly -- see around the 23 minute mark.

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

Re: [DNG] Clear communication (Was: Debian testing drop redis)

[John Hughes]

On 29/10/17 00:41, Patrick Meade wrote:

On 10/28/2017 02:06 AM, John Hughes wrote:
While keeping your eyes peeled is obviously a good thing please 
remember the downsides of crying wolf when the wolf isn't there.


Clear communication is also a good thing. Perhaps the words

"[D]rops the Debian-specific support for ... in favour of using systemd"

were not the best choice of words to summarize something that was

"not a sysvinit-specific change"


Perhaps.

In poor light a dog can look look a wolf.  Do you cry "wolf!"  or use a 
flashlight?


Personally I'm in favour of light.  Some others prefer heat.

Anyway, this horse is dead, time to stop beating it.


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

Re: [DNG] Chris Lamb = Good Maintainer (Was: Debian testing drop redis)

[John Hughes]

On 27/10/17 21:56, Jaromil wrote:


my training in hermeneutics and epistemology rings a bell about this
being the wrong general attitude about changes and regressions, but
for now I just rest on the fact redis "just works" in Devuan ASCII
(using sysvinit) and that, as I stated at the beginning, this should
be an issue addressed by upstream rather than us. Upstream has been
warned. Lets all keep our eyes peeled for this and other packages.


But what is the issue to be addressed by upstream?  What do they have to 
be warned about?


Chris Lamb removed a misfeature that he put in himself.  That, 
undocumented, misfeature never existed in the upstream code.


While keeping your eyes peeled is obviously a good thing please remember 
the downsides of crying wolf when the wolf isn't there.


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

Re: [DNG] Runit for Devuan: was Debian testing drop redis

[John Hughes]

On 28/10/17 03:45, Steve Litt wrote:


I'm the original poster of the thread renamed "Runit for Devuan", and I
don't understand this email at all. What does a debian bug about s6
have to do with my offer to be one of a two person team to bring a
runit package to Devuan?



You said


> s6's maintainer is on the job every day improving s6, and once again,
> someone who knows how to build Devuan package plus me plus a little bit
> of guidance from s6' upstream would produce a Devuan package.


The Debian bug I quoted was a RFP (request for pakage) for s6, it was 
the closest I could find to a s6 package.  Since then I've found:


 https://github.com/lwf/s6-packaging

Which is the stuff necessary for a s6 .deb

Note that, as far as I know, this doesn't provide enough stuff for using 
s6 as pid 1.



By the way, anyone here good at Devuan packaging and also would like a
runit package? I could probably put together a Devuan/runit Vagrant
file, from which we could make a package.


You don't have to make a runit package for Debian/Devuan --  it exists 
already.


What is missing is the runit-init package, i.e. runit as pid 1, which 
was removed as nobody had the time to fix bug 861536.


I guess Devuan could just live with the bug, or declare it fixed by 
documenting it.


Or someone who was interested could fix it and get runit-init back into 
Debian (and, therefore) Devuan.


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

Re: [DNG] Debian testing drop redis

[John Hughes]

On 28/10/17 01:39, zap wrote:


On 10/27/2017 04:51 AM, John Hughes wrote:

On 27/10/17 07:21, Steve Litt wrote:

No Debian fan, Chris Lamb or otherwise,

Debian fan? He's one of the people who build the distribution Devuan
is  based on.  He's not a "fan".


That is very impressive indeed. I would have never guessed that he was
that skilled at development.

I wonder if he uses sid... or ceres probably...  I assume he uses one of
those. :)


Given that Chris Lamb is currently Debian Project Leader and a Debian 
developer since 2008 I suspect he uses sid.


https://chris-lamb.co.uk/about
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Runit for Devuan: was Debian testing drop redis

[John Hughes]

Oh, yes, the last thing in the runit changelog is:

runit (2.1.2-9.2) unstable; urgency=medium

  * non-maintainer upload
  * re-add /sbin/runit{,-init} to runit package so it remains possible to
use runit as PID 1

 -- Daniel Kahn Gillmor   Wed, 31 May 2017 12:44:38 
-0400

So the runit-init package no longer exists, but if you want to use runit 
as init you can do it manually.


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

Re: [DNG] Runit for Devuan: was Debian testing drop redis

[John Hughes]

On 27/10/17 07:29, Steve Litt wrote:

U mean runit's author/upstream maintainer, or do you mean Debian's
maintainer for runit? Where does this information come from?


Debian's runit maintainer, Dmitry Bogatov, was arrested, accused of 
"preparing to organize mass disorder" and making "public calls for 
terrorist activit".  He runs a TOR exit node and is accused of posting 
things that were probably posted by some other TOR user.


https://www.eff.org/deeplinks/2017/04/access-now-and-eff-condemn-arrest-tor-node-operator-dmitry-bogatov-russia


The last time I downloaded, compiled and installed
runit it worked just fine.
The problem is with runit-init, not runit.  runit is still in Debian 
(and, hence, Devuan).


The problem is Debian bug 861536 -- installing runit-init makes it 
impossible to shutdown or reboot until the next boot.


('cos runit-init removes the running inits shutdown/reboot logic and 
installs its own, but the current init is still running and so the 
runit-init versions of shutdown/reboot don't work).




If there's a problem with Debian's runit maintainer, no sweat:
Pair me up with somebody who is good with making packages, and
we'll create a Devuan runit package much better than Debian's old
one (which was kind of difficult the last time I tried it).


Your first job would be to fix bug 861536.  If you can do that maybe you 
could get runit-init back into Debian.



If runit's author/upstream author has had bad stuff happen to him to th
extent that runit isn't trusted anymore, s6 is a fairly close
replacement: A little more complex and a little more capable. AFAIK
s6's maintainer is on the job every day improving s6, and once again,
someone who knows how to build Devuan package plus me plus a little bit
of guidance from s6' upstream would produce a Devuan package.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733915

Only a RFP, not an ITP.

Everyone wants somebody else to do the work.

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

Re: [DNG] Debian testing drop redis

[John Hughes]

On 27/10/17 07:21, Steve Litt wrote:

No Debian fan, Chris Lamb or otherwise,


Debian fan? He's one of the people who build the distribution Devuan is  
based on.  He's not a "fan".



They're not stupid: They know how much they hurt Linux interchangeable parts
with their rush to judgment on systemd.


You seem to have some difficulty in understanding that people can 
disagree with you.

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

Re: [DNG] Debian testing drop redis

[John Hughes]

On 26/10/17 17:05, KatolaZ wrote:

John, I was among those who tried to calm the storm down.

As I noted.  It didn't seem to have much effect though.

We should all try to be a bit more careful before coming to
conclusions.

I agree.

Unfortunately, we have seen already silly things coming
from some Debian developers.

If you say so.

This was not the case, hopefully. :)
ITYM "thankfully".  "Hopefully" would imply that you doubted Chris 
Lamb's word.


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

Re: [DNG] Debian testing drop redis

[John Hughes]

On 26/10/17 16:06, KatolaZ wrote:


please discard the angry comments. Evidently not everybody had a full
understanding of what was going on, before posting them. We repeatedly
said that there was no reason to freak out, and that the situation was
under control. Thanks for confirming it yourself :)

Oh really?

1st message to list with the initial misunderstanding: 2017-10-18 15:46
KatolaZ's message attempting to calm things: 2017-10-19 09:57
Jaromil "This episode is again of great shame on Debian maintainers" 
**2017-10-19 10:21

Jaromil "Vandalisation" 2017-10-20 10:57
Me "a little more light and a little less heat" 2017-10-20 16:27
Jaromil "it is even worse than I initially thought" 2017-10-22 11:37
Patrick Meade actually makes the effort to see what happened 
2017-10-23 15:59


Frankly it seems that some people have been rather fast to assume bad 
faith and very few people who commented either knew what they were 
talking about or made the slightest effort to actually understand what 
Chris Lamb had done.


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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 26/10/17 15:55, John Hughes wrote:



They are around 89 lines long.  Hardly broken compared to most init 
scripts, check out /etc/init.d/sendmail -- a 1321 line monster in some 
versions.



Duh, hardly "bloated" I meant to say.

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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 25/10/17 19:51, Steve Litt wrote:


How bout this: Have a "runit-supervisor-only" pacakge that installs
runit but doesn't make it PID1. Have sysvinit run runit, and have runit
run redis, with all the correct config. The runit run script is
probably 1/10 the size of its bloatacious and apparently broken sysvinit
init script, so it's easy to correctly design the runit run script.
As far as I know there is nothing  broken about the redis init scripts 
in Debian.


They are around 89 lines long.  Hardly broken compared to most init 
scripts, check out /etc/init.d/sendmail -- a 1321 line monster in some 
versions.


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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 24/10/17 14:44, Patrick Meade wrote:


Only the first option is acceptable to me, so what needs to be done is 
also clear to me. I'm hoping that the Debian maintainer will be 
willing to revert this change, as that would be the easiest way for 
everybody to win. If not, well... there is some work ahead.



Perfectly reasonable.

It seems the obvious way forward is for a redis user who uses this 
feature to make a bug report.


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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 23/10/17 15:59, Patrick Meade wrote:



As John Hughes said, this isn't quite as bad as we originally thought. 
We can still run redis-server with the Debian provided sysvinit 
script, and Debian isn't throwing away upstream files for no reason.


Also note that the upstream init script example doesn't support the 
Debian hook scripts.  Perhaps upstream don't think that's useful 
functionality?




However, it's not all sunshine and flowers either. The daemon state 
change hooks are removed in the latest Debian package. If someone had 
a script that pre-loaded data into the redis cache on daemon start, or 
fired off a backup of the persistent store on daemon stop, these 
scripts would no longer be called when redis goes up/down.


Given that there is no documentation for these scripts other than the 
Debian changelog is anyone using them?


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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 21/10/17 01:53, Patrick Meade wrote:


That text is not from the Debian changelog, but rather from debian/NEWS.


Ah, didn't notice that.  Always trust the code before the doc.

Still don't understand why it says "in favour of systemd's ... commands" 
when the patch does no such thing.


The only way I can understand it is as a poorly phrased way of saying 
"we're dropping this feature, systemd users could do something to work 
around that".  I guess he could have added suggestions for sysvinit and 
upstart users as well.  But in no way does this patch somehow remove 
sysvinit support for redis in Debian.




The GitHub commit is here:

https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-e2b5949461a30128734d213f0ead1565 



I must admit that I'm still learning the ropes with respect to Debian 
packaging. Could you explain this diff of debian/redis-server.init to me?




What's to explain?  It "drops the Debian-specific support for the 
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories" 
by removing the calls to run-parts.


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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 22/10/17 11:37, Jaromil wrote:

Thanks everyone for adding details,

On Fri, 20 Oct 2017, Patrick Meade wrote:


https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-9e388da7cd119765989cc22d2bc07e5c

This diff clearly shows that redis-sentinel example scripts provided
by upstream redis developers for compatibility with sysvinit are being
*deleted* from the package, de facto removing even the documentation
on how to start/stop from init.d despite it being just an example.

The scripts that are removed:


+rm_conffile /etc/redis/redis-sentinel.pre-up.d/00_example 4:4.0.2-3~

+rm_conffile /etc/redis/redis-sentinel.pre-down.d/00_example 4:4.0.2-3~

+rm_conffile /etc/redis/redis-sentinel.post-up.d/00_example 4:4.0.2-3~

+rm_conffile /etc/redis/redis-sentinel.post-down.d/00_example 4:4.0.2-3~


Do not exist in the upstream distribution of redis, *which does not 
include sysvinit scripts*.


They were added by the Debian redis developers as part of a poorly 
documented feature (only mentioned in the changelog!) which only exists 
on Debian.


Debian still include sysvinit scripts for redis, which provide as much 
functionality as sysvinit can give.  (The systemd service files allow 
running multiple copies of redis.  The Debian provided sysvinit scripts 
never allowed this, the only way of doing it would be for the user to 
write his own init scripts, which will be much easier to do without the 
{pre,post}-{up,down} complexity),


it is even worse than I initially thought.

No, it isn't.

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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 20/10/17 16:37, Antony Stone wrote:

However, Bardot Jérôme's original posting in this thread, quoting Chris Lamb
 Wed, 11 Oct 2017 22:55:00 -0400 said:

"This version drops the Debian-specific support for the
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories in
favour of using systemd's ExecStartPre, ExecStartPost, ExecStopPre,
ExecStopPost commands."

So, yes, what's been dropped is Debian-specific, but shouldn't we still be
concerned about the "in favour of systemd's ... commands"?


That's not what the Debian changelog says:


redis (4:4.0.2-3) unstable; urgency=medium

   * Drop Debian-specific support for
 /etc/redis/redis-{server,sentinel}.{pre,post}-{up,down}.d and remove them
 if unchanged.
   * Include systemd redis-server@.service and redis-sentinel@.service template
 files to easily run multiple instances. (Closes: #877702)
   * Patch redis.conf and sentinel.conf with quilt instead of maintaining our
 own versions under debian/.
   * Refresh all patches.
   * Bump Standards-Version to 4.1.1.

  -- Chris Lamb   Thu, 12 Oct 2017 14:54:27 -0400


In the buster/sid version (4:4.0.2-3) there is no code that I can find 
to run the {pre,post}-{up,down} scripts in sysvinit *or* systemd.


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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 20/10/17 16:48, goli...@dyne.org wrote:

On 2017-10-20 09:27, John Hughes wrote:


My appologies for posting to a list from which I have been banned . . .



If you were 'banned' you would would not have been able to post. I 
just checked and your account has no restrictions on it.



Yup, I misrembered.  Sorry.

Also, appologies to golinux for replying off-list, cause by my lack of 
attention and Thunderbirds stupid defaults.


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

[DNG] Debian testing drop redis non systemd

[John Hughes]

Jaromil wrote:


I would like to know here if anyone knows in detail the "reasons"
Debian is removing the support for sysvinit scripts in the redis
package.


Wouldn't it be more to the point to find out *if* Debian is removing the 
support for sysvinit scripts in the redis package before trying to find 
out why?


Because they aren't.

What they have done is what the changelog says:


   * Drop*Debian-specific*  support for
 /etc/redis/redis-{server,sentinel}.{pre,post}-{up,down}.d and remove them
 if unchanged.


The Debian supplied init scripts (debian/redis-server.init and 
debian/redis-sentinel.init) still exist, they just no longer include the 
(Debian specific) calls to "Run_parts".


These init scripts do not exist in the upstream redis distribution.  
They were added by Debian.


My appologies for posting to a list from which I have been banned, but I 
thought it might be wise to have a little more light and a little less heat.






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

Re: [DNG] Our friendly community

[John Hughes]

On 20/12/15 13:20, Adam Borowski wrote:

On Sun, Dec 20, 2015 at 12:21:11PM +0100, John Hughes wrote:

On 20/12/15 11:18, Adam Borowski wrote:

Package: libpam-systemd
[...]
Depends: libc6 (>= 2.17), libpam0g (>= 0.99.7.1), libselinux1 (>= 1.32),
  systemd (= 228-2), libpam-runtime (>= 1.0.1-6), dbus,
  systemd-shim (>= 8-2) | systemd-sysv


Yes, like I said, libpam-systemd depends on systemd-shim *or* systemd-sysv.

You don't need or want systemd installed if you have systemd-shim installed.

Please reread what I pasted again.  There's a hard dependency on systemd.
And libpam-systemd is the only real user of systemd-shim.



You are in fact right, libpam-systemd needs systemd installed, and 
either systemd as pid 1, or systemd-shim installed (and hence init as 
pid 1).


That's not what I was hoping for.  I'll have to do more investigation.

Sorry for the confusion.

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

Re: [DNG] Devuan's goal: was Our friendly community

[John Hughes]

On 21/12/15 12:41, Rowland Penny wrote:

On 21/12/15 11:06, John Hughes wrote:

On 21/12/15 11:52, Rowland Penny wrote:

On 21/12/15 10:03, John Hughes wrote:



What I'm looking for is choice -- I want people who want systemd to 
be able to run it, and people who dont want it to be able to use 
sysvinit, openrc or upstart or whatever.  At the moment things are 
all fucked up because there is no long term alternative to the seat 
management part of systemd and few people seem prepared to work on it.




This is what people have been trying to get through to you, if you 
run debain jessie, you 'HAVE' to use systemd whether you want to or 
not.


No, you don't.  You do have to have systemd installed, [ see below 
for why ], but systemd does not have to be pid 1.


OK, systemd doesn't have to be pid1, but by your admission, you still 
have to have it installed *even* if you don't want to, this is *not* 
choice!


Having a few files and directories on your disk is a major problem? 
systemd is not running if you're using systemd-shim, it just needs the 
systemd directories (that's why systemd-shim depends on systemd -- I 
suppose it would be possible to break the systemd package up into 
"systemd-config" and "systemd-binaries", but what would be the point?)




I can understand why parts of the desktop rely on something like 
udev, but this has now been subsumed by systemd.


No it hasn't.  The source code for udev is in the same tree as 
systemd, and they share some library functions, but udev still works 
without systemd.


Can you explain how? if you try to download the source package for 
udev, you will get the systemd source package.


So?   Who the hell cares?  Just build udev, there is source for some 
other things in the tree, ignore 'em.  When udev is running it does not 
need systemd.






If systemd had just been a replacement for sysv or upstart etc, then 
there would not have been all the row about it, those that wanted to 
use it could have and those that didn't, didn't have to, but no, 
because of the way it is taking over the established way of doing 
things, you are denied the free choice of what init system to use!


Assumes facts not in evidence.


Only because you seem to be ignoring the evidence, try setting up a 
debian jessie system with a gui. Now open a terminal as root and run 
'apt-get purge systemd* -y'


Why would you do that?  You've just broken your system.

Surely you care about what software is running, not what the package 
names or filenames are.


If you want to run an init system other than systemd the way to do it is:

Install your new init system, install systemd-shim, remove 
systemd-sysv.  Your fathers brother is called Robert.


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

Re: [DNG] Devuan's goal: was Our friendly community

[John Hughes]

On 20/12/15 19:01, Rainer Weikusat wrote:

John Hughes <j...@atlantech.com> writes:

On 19/12/15 11:58, dev1fanboy wrote:

Gnome

If you need more: apt-cache rdepends libsystemd0 | wc -l

We're going round in circles.  *I* posted that command:

https://lists.dyne.org/lurker/message/20151218.143549.77d859b4.en.html

But you still haven't said *why* you want to remove libsystemd0.

This is entirely the wrong question. There's presently no 'libsystemd0'
on my system. Why should it be added?


Joke answer, to let you run systemd?

What I'm looking for is choice -- I want people who want systemd to be 
able to run it, and people who dont want it to be able to use sysvinit, 
openrc or upstart or whatever.  At the moment things are all fucked up 
because there is no long term alternative to the seat management part of 
systemd and few people seem prepared to work on it.

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

Re: [DNG] Devuan's goal: was Our friendly community

[John Hughes]

On 21/12/15 11:52, Rowland Penny wrote:

On 21/12/15 10:03, John Hughes wrote:



What I'm looking for is choice -- I want people who want systemd to 
be able to run it, and people who dont want it to be able to use 
sysvinit, openrc or upstart or whatever.  At the moment things are 
all fucked up because there is no long term alternative to the seat 
management part of systemd and few people seem prepared to work on it.

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


This is what people have been trying to get through to you, if you run 
debain jessie, you 'HAVE' to use systemd whether you want to or not.


No, you don't.  You do have to have systemd installed, and I'm not sure 
why, but systemd does not have to be pid 1.



Can you answer why a desktop relies on an init system, because I cannot.


Because systemd (or systemd-shim) does session management, and Gnome 
didn't want to keep doing it (badly) themselves.


I can understand why parts of the desktop rely on something like udev, 
but this has now been subsumed by systemd.


No it hasn't.  The source code for udev is in the same tree as systemd, 
and they share some library functions, but udev still works without systemd.


If systemd had just been a replacement for sysv or upstart etc, then 
there would not have been all the row about it, those that wanted to 
use it could have and those that didn't, didn't have to, but no, 
because of the way it is taking over the established way of doing 
things, you are denied the free choice of what init system to use!


Assumes facts not in evidence.

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

Re: [DNG] Our friendly community

[John Hughes]

On 19/12/15 17:28, Adam Borowski wrote:


Systemd-shim is a tool for running _systemd_ without it being pid 1.
It's useless without systemd.



Huh?  systemd-shim is a tool for using libbpam-systemd (which Gnome 
depends on) without systemd being *installed*


In fact it *breaks* systemd, you can't have them both installed.


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

Re: [DNG] Our friendly community

[John Hughes]

On 20/12/15 11:18, Adam Borowski wrote:

On Sun, Dec 20, 2015 at 10:12:05AM +0100, John Hughes wrote:


Huh?  systemd-shim is a tool for using libbpam-systemd (which Gnome depends
on) without systemd being *installed*

In fact it *breaks* systemd, you can't have them both installed.

Package: libpam-systemd
[...]
Depends: libc6 (>= 2.17), libpam0g (>= 0.99.7.1), libselinux1 (>= 1.32),
  systemd (= 228-2), libpam-runtime (>= 1.0.1-6), dbus,
  systemd-shim (>= 8-2) | systemd-sysv


Yes, like I said, libpam-systemd depends on systemd-shim *or* systemd-sysv.

You don't need or want systemd installed if you have systemd-shim installed.



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

Re: [DNG] Devuan's goal: was Our friendly community

[John Hughes]

On 18/12/15 19:02, Steve Litt wrote:

Yeah, in an ideal world, we'd like to remove every rotting vestige of
systemd, but in a practical world, where if we don't timely produce
something people can actually use, this has all been for naught,
removal is a process, where on the first go-around we remove systemd as
PID1 and the process supervisor


Then I don't understand what the point of Devuan is -- you can "remove 
systemd as

PID1 and the process supervisor" in Debian.


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

Re: [DNG] Our friendly community

[John Hughes]

On 18/12/15 19:40, Steve Litt wrote:

On Fri, 18 Dec 2015 17:39:26 +0100
John Hughes <j...@atlantech.com> wrote:


On 18/12/15 17:18, Mitt Green wrote:

No, the actual work on packages that remove libsystemd0 dependency.
I've done quite of it for my machine. Notable examples include
angband repositories apart from Devuan's own. Adam made a big
base removing the dependency.

But why?  What badness does libsystemd0 do?

I don't know.

Here's what I do know. Before 12/18/2015 (today), not one single email
from "John Hughes" has been posted to dng@lists.dyne.org. Today
(12/18/2015), there have been 10 (and counting) "John Hughes" emails,


Yes I've only been reading the list as a lurker up to now.


most of which tended to say "libsystemd0 isn't that bad",


I don't think it's that bad, and, despite my asking nobody can tell me 
why it is.



  and one of
which seemed to say that you need remove systemd dependencies only from
*direct* systemdlib0 dependencies, and not the sub-dependencies, and
that makes no sense to me at all.


Huh?  if a depends on b which depends on c which depends on libsystemd0 
then only c needs modification to remove that dependancy, not a or b.


One of the reasons LKCL's post was met with such derision was his claim 
that over 4000 packages depended on libsystemd0, when the real number is 74.




But when I hear "John Hughes" post several "libsystemd0 isn't that bad"
posts on his very first day, well, Mr. Hughes' credibility descends.
And when his credibility descends, one must consider the possibility
that he's here only to stir up conflict. It's been tried before, and it
works very poorly on this list.


I decided to post to the list because it seems to me that you're all 
fiddling around with cosmetic parts of the problem (remove libsystemd0, 
replace udev and so on) while ignoring the huge steaming elephant turd 
in the middle of the room -- logind.


Without a functional replacement for logind then Devuan is doomed.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Our friendly community

[John Hughes]

On 18/12/15 15:50, Mitt Green wrote:

It's a library whose sole purpose is to make sure that
packages *don't* depend on
systemd.

So, you are saying that libsystemd0 is harmless and it
doesn't mean anything unless you install systemd, systemd-sysv and so on?


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

Re: [DNG] Devuan's goal: was Our friendly community

[John Hughes]

On 19/12/15 11:40, dev1fanboy wrote:


You have to avoid many other packages to avoid systemd and in some 
cases you will end up with systemd support that you don't want anyway.




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

Re: [DNG] Our friendly community

[John Hughes]

On 19/12/15 11:28, Rowland Penny wrote:

On 19/12/15 10:21, John Hughes wrote:

On 18/12/15 19:40, Steve Litt wrote:



most of [ JH's posts ] tended to say "libsystemd0 isn't that bad",


I don't think it's that bad, and, despite my asking nobody can tell 
me why it is.


I will give you a good reason why systemd is bad, if you try to remove 
it from debian, it also removes your desktop etc.


Are you talking about libsystemd0?  Because it's not true that removing 
systemd from Debian will remove your desktop.  If you are talking about 
libsystemd0 why do you want to remove it?  All I see are circular 
arguments -- "libsystemd0" is bad because removing it breaks things, so 
we must remove it.






I decided to post to the list because it seems to me that you're all 
fiddling around with cosmetic parts of the problem (remove 
libsystemd0, replace udev and so on) while ignoring the huge steaming 
elephant turd in the middle of the room -- logind.


Without a functional replacement for logind then Devuan is doomed.


Why?, Linux worked very well before 'logind' appeared.



Maybe, but it doesn't now, so either you stick to wheezy or you fix the 
problem.  Ignoring it won't make it go away.


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

Re: [DNG] Our friendly community

[John Hughes]

On 19/12/15 12:02, Rowland Penny wrote:


Look, you troll, If you 'apt-get remove systemd' on debian, it will
remove Gnome or Mate, I know I tried. Anything that does this, is
*BAD* in my books.


You're doing it wrong.

http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation

Hint: you need to install systemd-shim.

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

Re: [DNG] Our friendly community

[John Hughes]

On 19/12/15 12:54, Rowland Penny wrote:

On 19/12/15 11:45, John Hughes wrote:

On 19/12/15 12:02, Rowland Penny wrote:


Look, you troll, If you 'apt-get remove systemd' on debian, it will 
remove Gnome or Mate, I know I tried. Anything that does this, is 
*BAD* in my books.


You're doing it wrong.

http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation 



Hint: you need to install systemd-shim.


Firstly, *never* email me directly.


Sorry, pressed wrong button in crappy thunderbird interface.



Did you miss the bit about my pathological hatred of systemd??


You cannot imagine the depth of the all consuming lack of interest I 
have in your mental state, pathological or otherwise.


I'm interested in the tecnological aspects of avoiding systemd.  I'm 
unhappy that people who don't want to use systemd are forced into 
running broken systems, so I would like to see useful work towards 
making it possible to easily run alternatives to systemd.




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

Re: [DNG] Our friendly community

[John Hughes]

On 19/12/15 12:47, KatolaZ wrote:

On Sat, Dec 19, 2015 at 11:02:49AM +, Rowland Penny wrote:

[cut]


Look, you troll, If you 'apt-get remove systemd' on debian, it will
remove Gnome or Mate, I know I tried. Anything that does this, is
*BAD* in my books.


It also removes cups and many other things, for that matter.


Are you sure?  Why?  When I just tried on sid it didn't say it was going 
to remove cups.  It does say it's going to remove printer-driver-hpcups 
and printer-driver-hpijs for some insane reason.




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

Re: [DNG] Devuan's goal: was Our friendly community

[John Hughes]

On 19/12/15 11:58, dev1fanboy wrote:

Gnome

If you need more: apt-cache rdepends libsystemd0 | wc -l


We're going round in circles.  *I* posted that command:

https://lists.dyne.org/lurker/message/20151218.143549.77d859b4.en.html

But you still haven't said *why* you want to remove libsystemd0.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Our friendly community

[John Hughes]

On 19/12/15 14:34, Dragan FOSS wrote:

On 12/19/2015 01:05 PM, John Hughes wrote:

people who don't want to use systemd are forced into running broken
systems, so I would like to see useful work towards making it possible
to easily run alternatives to systemd.


You're obviously ignorant :)


Apparently.




Rock-solid Debian-jessie-based system without systemd et al (including 
logind, libsystemd0. *-shim etc..)


https://foss.rs/threads/trios-mia-openrc-zfs-rc1.3057/

https://lists.dyne.org/lurker/message/20151013.005909.eadfd010.en.html


And all the little no-systemd irritations are fixed? hibernation/suspend 
and so on?


Why isn't this Devuan?

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

Re: [DNG] Our friendly community

[John Hughes]

Rainer Weikusat writes:


A somewhat loaded "executive summary" of [Russ Allbery's] statement
> could be: > "Considering that systemd was forced into Debian, I 
really don't see why

I would want to bother was all this boring tech stuff any longer".


An improbable reading given that Russ voted for systemd in the TC vote.

In fact he seems to have resigned because he was pissed off with Ian 
Jackson's anti-systemd (pro-upstart) agitation.


See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729 for 
the TC vote:


  4x D U O V F (bdale, russ, keith, don)
 F U D O V (steve)
 U D O F V (colin)
 F V O U D (ian)
 U F D O V (andi)



(Duh, resend 'cos I got sender address wrong).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Our friendly community

[John Hughes]

On 18/12/15 15:54, Didier Kryn wrote:

Le 18/12/2015 15:35, John Hughes a écrit :

The list is, of course, spurious.

$ cat /etc/debian_version
8.2
$ apt-cache rdepends libsystemd0 | wc -l
74


Sorry, my primary attitude is to believe what people write. So
it's only 74. Does it include chained dependency?



Of course not.  Why should it?  LKCL's messages were about the enormous 
effort needed to fix the 4000 odd packages that "depended" on 
libsystemd0, when he only "needed' to modify 74 packages to get rid of 
all libsystemd0 dependency.



Every single function in libsystemd0 looks like:

 if (init_is_systemd) {
   do some systemd stuff;
 }
 else {
   carry on as before;
 }


But do they have also a libupstart0, libsysv0, etc, on which all
these 74 package depend?


Nope.  upstart and sysv-init don't provide any interesting features 
beyond the simple init subset that packages might like to use.  The 
point of libsystemd0 is to let packages use systemd features without 
depending on systemd.


Which makes LKCL's proposal of making libsystemd0 loaded by dlopen even 
funnier -- to avoid depending on libsystemd0 packages would have to 
include systemd specific code, or depend on a lib-not-systemd0 package. 
 But that package would also contain the magic word, so we'd need to 
dlopen it, so either programs would include systemd specific code or 
we'd have to invent a lib-not-not-systemd0 package, but that package 
would...


Does the arrow ever hit the target?  Does Achilles catch the tortoise?

(I hate Thunderbird -- resending 'cos idiot program chose wrong sender
address *again*)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Our friendly community

[John Hughes]

Didier Kryn writes:


The list of 4583 packages now depending on libsysemd0 includes a
lot of packages which definitely have nothing to do with it. The final
lock will happen when the dependency will reach the shells and gcc.
Given the fast contamination, we should expect this pretty soon.


The list is, of course, spurious.

$ cat /etc/debian_version
8.2
$ apt-cache rdepends libsystemd0 | wc -l
74

Even worse, this whole thread in d-u/d-d is based on a total misunderstanding by
LKCL of what libsystemd0 *is*.

It's a library whose sole purpose is to make sure that packages *don't* depend 
on
systemd.

Every single function in libsystemd0 looks like:

 if (init_is_systemd) {
   do some systemd stuff;
 }
 else {
   carry on as before;
 }

But LKCL decided that the problem was not systemd as init, it was the presence
of packages containing the letters d, e, m, s, t and y in one particular order.

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

Re: [DNG] Our friendly community

[John Hughes]

On 18/12/15 16:51, Mitt Green wrote:

is nothing but "systemd support code added to some
package".

If it is so, why there is so much hype about it?


Hype about what?  libsystemd0?  The only "hype" about libsystemd0 was 
from LKCL who came up with a strange plan to remove it by replacing 
libsystemd0 by a library that would dynamically load libsystemd0, 
probably called lib-not-quite-libsystemd0.



  I previously thought that Devuan aim was to remove
*any* of systemd components.


Funny, I thought Devuan was about choice.


As far as I see libsystemd0 is only a shared library.
Why should it provide features that I don't use?
It's like buying a pick-up lorry to drive it in an urban area.


libsystemd0 is a trailer hitch -- it's up to you if you want to hook up 
the trailer.



Then why pushing it everywhere where it is unnecessary?
Let then people decide whether to use it or not.


If libsystemd0 is not present people don't get a free choice -- they 
can't use some systemd features.



The same thing applies to libpulse and libselinux.


Just like libsystemd0 they do nothing if pulseaudio or selinux are not 
installed.




May gods bless this packaging system.


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

Re: [DNG] Our friendly community

[John Hughes]

On 18/12/15 16:25, Rainer Weikusat wrote:

If you look at

,
|  if (init_is_systemd) {
|do some systemd stuff;
|  }
|  else {
|carry on as before;
|  }
`

you'll note that the

if (init_is_systemd) {
do some systemd stuff;
} else {
/* syslog(LOG_EMERG, "ESYADMINDEPRECATED!!!"); */
}

is nothing but "systemd support code added to some package".


Can't find the string "ESYADMINDEPRECATED" in the source for libsystemd0.

I can understand people not liking systemd, but why criticize it for 
things it doesn't do?



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

Re: [DNG] Our friendly community

[John Hughes]

On 18/12/15 17:18, Mitt Green wrote:


No, the actual work on packages that remove libsystemd0 dependency.
I've done quite of it for my machine. Notable examples include
angband repositories apart from Devuan's own. Adam made a big
base removing the dependency.


But why?  What badness does libsystemd0 do?

I can understand working on replacements for libpam-systemd, that is a 
big problem for people who don't want systemd, but libsystemd0 seems 
pretty benign.





Funny, I thought Devuan was about choice.

A choice not to use systemd at all.


If I wanted to I could run Debian without systemd.  Some things wouldn't 
work, but as I understand it those things don't work on Devuan either.  
What more choice does Devuan give me?

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

Re: [DNG] Our friendly community

[John Hughes]

On 18/12/15 18:06, Hendrik Boom wrote:

Indeed, both are true.  Devuan is about choice.  Since Debian is quite
clearly providing the alternative of using systemd,


And the alternative of *not* using systemd.


the main effort here is to provide the alternative of not using systemd.
The main part of that effort is to remove systemd.


http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation

What more needs to be done?

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

Re: [DNG] Our friendly community

[John Hughes]

On 18/12/15 15:50, Mitt Green wrote:

It's a library whose sole purpose is to make sure that
packages *don't* depend on
systemd.

So, you are saying that libsystemd0 is harmless and it
doesn't mean anything unless you install systemd, systemd-sysv and so on?

Exactly.

(aargh.  resending 'cos got sender address wrong *again*)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng