Re: [DNG] Systemd Shims

[James Powell]

Systemd is not an option. Uselessd is an option, Runit is an option, s6 is an 
option, OpenRC is an option. Why, because any of these are init/supervisor sane 
replacements and/or extensions to sysvinit.

When you replace the underlying system core with a completely alien hypervisor, 
you kill the option, and kill choice. Once systemd is in, it is in.

-Jim

From: T.J. Duchene
Sent: ‎8/‎15/‎2015 12:48 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] Systemd Shims

On Sat, 15 Aug 2015 03:15:50 -0700
James Powell  wrote:

Hi Jim! =)

>
> To me, a shim is not the way. Sanitization is what is needed, and if
> that requires work, then question this, 'Will the work be worth it?'
> and to me the answer is a definable 'yes'.

I suppose there are some people like yourself who will always feel that
way, and that is quite frankly - "totally awesome".

All that I ever try to say that I think there should be room for
both sorts to make Devuan a home.  Yes, I think Devuan should have
systemd as an option, but only as an option - never part of the base
system.



>
> Not to push a button, but I think Funtoo had the right mindset about
> systemd 'No way or chance in Hell'.

I'm sorry Jim, but I see Funtoo as really a bad example of the
situation.

Funtoo is source based, and Devuan is not.  They are both Linux but it
is two very different worlds of users, like apples and oranges. It's a
LOT easier to excise systemd when you are not expected to provide a
binary.  The minute you are expected to provide an official binary and
have major features removed, users start to complain that your version
is less than everyone else.

Usually, the only ones who use source versions are power users and
programmers who understand and accept the trade-offs in compiling your
own OS.

Have a great day!  =)

T.J.

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

Re: [DNG] Systemd Shims

[Laurent Bercot]

On 16/08/2015 06:53, Steve Litt wrote:

The toughest part is how to store the passwords in a way that isn't a
security problem.


 Unfortunately, /etc/wpa_supplicant.conf doesn't have an include feature
(which is strange, because hostapd supports a wpa_psk_file option).
 So you have to store the passwords (or the equivalent binary PSKs) in the
configuration file, and make this file readable only from root - which means
you need a small suid root binary to write the whole configuration file.

 Password security isn't a problem that you can fix at the interface level,
it's something that must be tightly integrated with the tool that uses the
password - and there's no doubt wpa_supplicant could do better here.

--
 Laurent

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

Re: [DNG] Systemd Shims

[Steve Litt]

On Sun, 16 Aug 2015 07:37:16 +0300
Lars Noodén  wrote:

> 
> >> I would be interested in
> >>
> >> * No-dbus replacement for NetworkManager/Wicd
> >>
> >> Are you thinking a C program?
> > 
> > HECK no! There's no requirement for this program to be fast, and I
> > want to make it easy on myself. Python probably, with the minimum
> > Python addons, and only addons that ship with Python itself.
> > 
> > If people really hate the Python dependency (I thought almost
> > everyone installs Python anyway), perhaps I could make it out of
> > shellscripts, awk and the like.
> 
> I too am interested in a no-dbus replacement for NetworkManager/Wicd
> 
> I also like the idea of a shell script, it would make it more
> accessible to more people, but only if it is feasible.  A thing
> should be as simple as possible but no simpler.  So if it needs perl
> or python then so be it, it would not be the first tool with such a
> dependency.  But my preference would be shell.
> 
> Regards,
> /Lars

You might be in luck, if a few more people jump in. One person emailed
me offlist with code to do this, either we could all start using his
code, or I could use his code as a starting point.

The toughest part is how to store the passwords in a way that isn't a
security problem. But then again, with NetworkManager, as I remember,
you can click "clear text" and see the passwords :-)

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Lars Noodén]

>> I would be interested in
>>
>> * No-dbus replacement for NetworkManager/Wicd
>>
>> Are you thinking a C program?
> 
> HECK no! There's no requirement for this program to be fast, and I want
> to make it easy on myself. Python probably, with the minimum Python
> addons, and only addons that ship with Python itself.
> 
> If people really hate the Python dependency (I thought almost everyone
> installs Python anyway), perhaps I could make it out of shellscripts,
> awk and the like.

I too am interested in a no-dbus replacement for NetworkManager/Wicd

I also like the idea of a shell script, it would make it more accessible
to more people, but only if it is feasible.  A thing should be as simple
as possible but no simpler.  So if it needs perl or python then so be
it, it would not be the first tool with such a dependency.  But my
preference would be shell.

Regards,
/Lars

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

Re: [DNG] Systemd Shims

[Steve Litt]

On Sun, 16 Aug 2015 14:26:41 +1200
Daniel Reurich  wrote:

> On 16 August 2015 7:47:46 AM GMT+12:00, "T.J. Duchene"
>  wrote:


> >All that I ever try to say that I think there should be room for
> >both sorts to make Devuan a home.  Yes, I think Devuan should have
> >systemd as an option, but only as an option - never part of the base
> >system.
> >
> >
> No no no!
> 
> If you Devuan with systemd install Debian.  

I agree. Daniel, I don't know why it's so hard for some people to
understand. We're all for freedom of choice, but catering to this
mythical Devuan user who wants systemd reduces *our* choices by making
it much harder to (I've been told not to use the neologism), ummm,
decontaminate Devuan.

Considering the source you're replying to, it's not worth even worrying
about. 

The other side sure doesn't respect freedom of choice. That's why
we're here in the first place. Inclusion of systemd tends to reduce
freedom of choice, not enhance it.

 
> I will not continue to work on Devuan if it means compromising it for
> the systemd fan boys who want to infect Devuan with Lennarts and Co's
> crap.  If we could permanently remove avahi and pulseaudio then all
> the better.

I can't blame you a bit, but don't stop because of the guy to whom
you're replying.

> 
> If you want systemd with your linux, your in the wrong forum and
> looking at the wrong distrobution.

A-friggin-men, and that's why I long ago piped his messages
to /dev/null. And yet, apparently, months later, he's still advocating
bringing systemd into Devuan.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Wireless configuration tools (was: Re: Systemd Shims)

[Isaac Dunham]

On Sat, Aug 15, 2015 at 06:19:23PM -0400, Steve Litt wrote:
> 
> 
> On Sun, 16 Aug 2015 00:08:11 +0200
> shraptor  wrote:
> > I would be interested in
> > 
> > * No-dbus replacement for NetworkManager/Wicd
> > 
> > Are you thinking a C program?
> 
> HECK no! There's no requirement for this program to be fast, and I want
> to make it easy on myself. Python probably, with the minimum Python
> addons, and only addons that ship with Python itself.
> 
> If people really hate the Python dependency (I thought almost everyone
> installs Python anyway), perhaps I could make it out of shellscripts,
> awk and the like.

> > 
> > daemon and user interface/GUI separation?
> 
> I'm not sure whether an actual daemon would be needed, but either way,
> the user interface would be a separate program from the thing that
> reveals the wifi transmitters, deals with wpa-supplicant and iwlist,
> etc. I'd probably make one curses interface, and one GUI. I *might*
> even do them with dialog and zenity.
> 
> But I'd need *a lot* more people wanting it to do it. The way Devuan
> does Wicd right now means making this program isn't personally urgent.

I've written something along these lines myself about a year ago.

It's wpa_config, a shell script for wireless configuration.
Mostly, it modifies the wpa_supplicant configuration directly.

For a backend, it uses wpa_cli; for a frontend, it uses dialog or clones
that are adequately compatible (whiptail or Xdialog, though the latter
isn't really maintained at present).

It was actually written to accompany an init script that would launch
wpa_supplicant and handle DHCP properly, while not making the init scripts
hang waiting for wireless; the (limited) documentation all explains how to
use the init script, rather than how to use the configuration tool.
Contrary to what one might infer from the notes, wpa_config should work
with any way of starting wpa_supplicant with /var/run/wpa_supplicant/
as the control-interface directory.

Long story short: it's limited, somewhat odd in interface, and nearly
undocumented.
But if you've configured wpa_supplicant to start, or need to write an
initial config file, it should be adequate if you can follow the UI.
I tried to make the UI as obvious as possible, but I'm the only user
I'm aware of, so no promises ;-).

The full git tree is at:
 https://github.com/idunham/wpanet

The script in question is:
 https://github.com/idunham/wpanet/blob/master/tools/wpa_config


HTH,
Isaac Dunham

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

Re: [DNG] Systemd Shims

[Daniel Reurich]

On 16 August 2015 7:47:46 AM GMT+12:00, "T.J. Duchene"  
wrote:
>On Sat, 15 Aug 2015 03:15:50 -0700
>James Powell  wrote:
>
>Hi Jim! =)
>
>> 
>> To me, a shim is not the way. Sanitization is what is needed, and if
>> that requires work, then question this, 'Will the work be worth it?'
>> and to me the answer is a definable 'yes'.
>
>I suppose there are some people like yourself who will always feel that
>way, and that is quite frankly - "totally awesome".  
>
>All that I ever try to say that I think there should be room for
>both sorts to make Devuan a home.  Yes, I think Devuan should have
>systemd as an option, but only as an option - never part of the base
>system.
>
>
No no no!

If you Devuan with systemd install Debian.  

I will not continue to work on Devuan if it means compromising it for the 
systemd fan boys who want to infect Devuan with Lennarts and Co's crap.  If we 
could permanently remove avahi and pulseaudio then all the better.

If you want systemd with your linux, your in the wrong forum and looking at the 
wrong distrobution.

Daniel

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

Re: [DNG] Systemd Shims

[Steve Litt]

On Sun, 16 Aug 2015 00:08:11 +0200
shraptor  wrote:

> On 2015-08-15 18:01, Steve Litt wrote:

> >> 
> >>  Please, Steve, provide us with all you mentionned, as an
> >> alternative to mainstream bloated/infected stuff. Since Devuan is
> >> all about freedom, this is the place where to deliver to the
> >> world. As soon as I can install Devuan on metal, I'll be one of
> >> your testers.
> >> 
> >>  Didier
> > 
> > OK. What should come first?
> > 
> > * Automounter?
> > * No-dbus replacement for NetworkManager/Wicd?
> > * Other?
> > 
> > Please keep in mind, I'm not a good enough programmer to write a
> > substitute for Gimp or Gnome. Let's keep the first one simple and
> > easy so I can actually do it, in a reasonable timeframe, without
> > adversely impacting my real work.



> I would be interested in
> 
> * No-dbus replacement for NetworkManager/Wicd
> 
> Are you thinking a C program?

HECK no! There's no requirement for this program to be fast, and I want
to make it easy on myself. Python probably, with the minimum Python
addons, and only addons that ship with Python itself.

If people really hate the Python dependency (I thought almost everyone
installs Python anyway), perhaps I could make it out of shellscripts,
awk and the like.

> 
> daemon and user interface/GUI separation?

I'm not sure whether an actual daemon would be needed, but either way,
the user interface would be a separate program from the thing that
reveals the wifi transmitters, deals with wpa-supplicant and iwlist,
etc. I'd probably make one curses interface, and one GUI. I *might*
even do them with dialog and zenity.

But I'd need *a lot* more people wanting it to do it. The way Devuan
does Wicd right now means making this program isn't personally urgent.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Go Linux]

On Sat, 8/15/15, Simon Hobson  wrote:

 Subject: Re: [DNG] Devuan and upstream
 To: "dng@lists.dyne.org" 
 Date: Saturday, August 15, 2015, 3:53 PM
 
Hendrik Boom  wrote:

>> THe way I heard the story, in the ncient days when Apple was choosing
>> the kernel for OS X, they were originally planning to use Linux, but
>> they changed their mind for copyright reasons.  THey didn't want to risk
>> any of their proprietary software becoming free software because of
>> GPL contagion.
>>
>> The BSD licence allowed them to do what they wanted.
>>
>
> You do realise that they do in fact use a lot of GPL software don't you ? In 
> fact they have contributed > some very useful software back into the 
> community under GPL.
> I'm more inclined to think they just decided the BSD kernel was more suitable 
> to their needs
> 

I once investigated helping a friend use some open source software on her Mac. 
A program that was free (gratis) in the Linux community was available in the 
Apple app store for $30!  That really pissed me off and soured me even more on 
Apple than before (if that was possible).

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

Re: [DNG] Systemd Shims

[shraptor]

I would be interested in

* No-dbus replacement for NetworkManager/Wicd

Are you thinking a C program?

daemon and user interface/GUI separation?


On 2015-08-15 18:01, Steve Litt wrote:

On Sat, 15 Aug 2015 08:51:55 +0200
Didier Kryn  wrote:


Le 15/08/2015 02:26, Steve Litt a écrit :
> On Fri, 14 Aug 2015 14:49:17 -0700
> Go Linux  wrote:
>
>> On Fri, 8/14/15, T.J. Duchene  wrote:
>>
>>   Subject: Re: [DNG] Systemd Shims
>>   To: dng@lists.dyne.org
>>   Date: Friday, August 14, 2015, 2:47 PM
>>
>>> I know not everyone here agrees with me, especially Steve, and
>>> that's perfectly okay.  I have no problem with that at all. I just
>>> don't see "System 5 pure"  as realistic when planning ahead
>>> looking at a maintenance standpoint when Debuan upstream is more
>>> and more likely to stick with Systemd in designing their
>>> packaging.
>>>
>> Maybe we should just put Steve in charge of decontaminating all
>> packages with systemd deps!
> Oh, you wouldn't want to do that. Contrary to what I wrote in
> another thread about "the perfect is the enemy of the good", if *I*
> were in charge of decontamination, I'd throw out whole subsystems.
> Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if
> it gets all systemd on us.
>
> In the massive time I save as not being the bomb squad defusing Red
> Hat's terrorism, I'd write small replacements for a lot of things
> that use only Linux and a very rudimentary and optional GUI
> interface.
>
> Then I'd write documentation explaining how to use a sharp thinking
> computer, to the proud ignorants of the world, especially those who
> believe their ignorance is a badge of honor proving their age or
> gender.
>
> And the people who prioritize pretty over functional and robust: I'd
> tell them to get a Mac.
>
> You don't want me in that capacity.
>
> And yes, I *am* a hypocrit who takes one position in one thread, and
> then says he'd do the opposite in another. :-)
>
> SteveT
>
>

 Please, Steve, provide us with all you mentionned, as an
alternative to mainstream bloated/infected stuff. Since Devuan is all
about freedom, this is the place where to deliver to the world. As
soon as I can install Devuan on metal, I'll be one of your testers.

 Didier


OK. What should come first?

* Automounter?
* No-dbus replacement for NetworkManager/Wicd?
* Other?

Please keep in mind, I'm not a good enough programmer to write a
substitute for Gimp or Gnome. Let's keep the first one simple and easy
so I can actually do it, in a reasonable timeframe, without adversely
impacting my real work.

Thanks,

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

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

Re: [DNG] Devuan and upstream

[T.J. Duchene]

The lack of the last two: multiple versions and shell scripts are why
Debian derivatives cannot share packages, even though they use
identical base code. 

Correction:

The lack of multiple versions and packahe shell scripts are why
Debian derivatives cannot share packages, even though they use
identical base code. 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[T.J. Duchene]

On Sat, 15 Aug 2015 20:19:03 +
Stephanie Daugherty  wrote:

Hi, Stephanie! =)

> They did, but out of all this design by committee, hidden between all
> the political bullshit and bikeshedding, they also created the most
> brilliant, most comprehensive set of standards for quality control,
> package uniformity, license auditing, and of course. the most robust
> dependency management, at least among binary distributions.

Sorry, I can't agree.  =(

After using a number of distributions over about 20 years, I find Debian
to be more or less average.  Debian passes into stable roughly the same
number of bugs that most of the other major distributions do.  This is
not to say that Debian does not make an effort.  Far from it.  I'm
simply saying that when you take the top ten binary Linux
distributions, they pretty much all have the same or similar issues.

> 
> More importantly than that, they backed these standards up with
> automated tools that are nearly as robust as the standards
> themselves.

I agree their tools are decent - most of the time, but the tools are
really only useful for their particular use case. In my opinion, Debian
packaging was the best - 15 years ago - but after that initial work was
done, they stopped doing anything significant at all.  I'm not saying
 Debian packaging is bad.  I find it very good, but it also have
 serious limitations that should have been dealt with long ago.

Their tools work 90%  of the time when you confine yourself within the
Debian stable repository.  Debian packaging is extremely dependent on
versioning in their build process. It is unable to use anything other
than the last version. There are no rollbacks or test staging before
final install, for example.  There is no standard mechanism to allow
for multiple libraries and precedence.  Individual install scripts
should have been replaced with a Debian standard for a simple tokenized
installer so that there are no individualized shell scripts in the
packages to begin with. 

The lack of the last two: multiple versions and shell scripts are why
Debian derivatives cannot share packages, even though they use
identical base code.  It is also the source of the init scripts that
caused at least 70% of the reason that Devuan split from Debian in
the first place.  

What I am saying is that Debian could have raised the bar long ago, but
frankly, no one cares. (It's one of the reasons I am fed up with binary
Linux versions.  If it was not for lack of time, I would not be using
them at all.)

> You don't see packages interfering with one another very
> often in the Debian world, because this is caught right away by
> scripts that check that every file installed by a package, or
> automatically created by that package belongs to EXACTLY ONE package,
> otherwise all the packages have to use some approved mechanism to
> cooperate. You also see this effort it in difficult to configure
> packages that set themselves up and work out of the box, and in the
> modularized configuration that's common to many packages.

Yes and no.  I've seen plenty of packages break as soon as you use
something that the majority does not. I've also seen more than few
packages that require significant intervention to work properly.  That
has lessened the last few releases, but the spectre is always there.


Take care!
T.J.


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

Re: [DNG] [hai...@histomat.net: Re: Alpha2 without desktop environment]

[Isaac Dunham]

On Sat, Aug 15, 2015 at 07:43:04AM -0400, Haines Brown wrote:
> I reiinstalled (avoiding past missteps), to a console, and from it
> installed xorg and fluxbox. I then ran xstart from console and all went
> well.
> 
> With one exception. I'm in what looks like VGA mode with large crude
> characters. It seems a problem (or symptom) is that installation did not
> create a /etc/X11/xorg.conf.d/ directory that should holding, I
> presume, a 20-nvidia.conf file. I created them by hand, but startx
> failed with error in log to effect that there is no server section.
> I suspect this is not the file that should have a Server section.
> 
> I purged and reinstalled xorg without luck. Installed were libglu1-mesa,
> x11-apps, x11-session-utils, x11-server-utils, xinit, xorg,
> xorg-docs-core.
> 
> The xorg log tells me that it is using as system configuration
> directory, /usr/share/X11/xorg.c. Because this file does not exist, the
> log complains about missing layout, screen and monitor definitions. It
> seems xorg is using defaults. 

Xorg looks in /etc/X11/xorg.conf.d/, then /usr/share/X11/xorg.conf.d/.
If you would rather use a single-file xorg.conf, you can create it via
"Xorg -configure" (IIRC).

But besides that, I'm wondering about a couple things.
1: You refer to "20-nvidia.conf". I'd assume that this would come from
the nvidia driver, which I see no reference to in your list of packages.

2: You refer to "/usr/share/X11/xorg.c." Is this a typo/abbreviation,
or is Xorg misconfigured?


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

Re: [DNG] Systemd Shims

[Didier Kryn]

Le 15/08/2015 18:01, Steve Litt a écrit :

On Sat, 15 Aug 2015 08:51:55 +0200
Didier Kryn  wrote:


Le 15/08/2015 02:26, Steve Litt a écrit :

On Fri, 14 Aug 2015 14:49:17 -0700
Go Linux  wrote:


On Fri, 8/14/15, T.J. Duchene  wrote:

   Subject: Re: [DNG] Systemd Shims
   To: dng@lists.dyne.org
   Date: Friday, August 14, 2015, 2:47 PM
   

I know not everyone here agrees with me, especially Steve, and
that's perfectly okay.  I have no problem with that at all. I just
don't see "System 5 pure"  as realistic when planning ahead
looking at a maintenance standpoint when Debuan upstream is more
and more likely to stick with Systemd in designing their
packaging.


Maybe we should just put Steve in charge of decontaminating all
packages with systemd deps!

Oh, you wouldn't want to do that. Contrary to what I wrote in
another thread about "the perfect is the enemy of the good", if *I*
were in charge of decontamination, I'd throw out whole subsystems.
Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if
it gets all systemd on us.

In the massive time I save as not being the bomb squad defusing Red
Hat's terrorism, I'd write small replacements for a lot of things
that use only Linux and a very rudimentary and optional GUI
interface.

Then I'd write documentation explaining how to use a sharp thinking
computer, to the proud ignorants of the world, especially those who
believe their ignorance is a badge of honor proving their age or
gender.

And the people who prioritize pretty over functional and robust: I'd
tell them to get a Mac.

You don't want me in that capacity.

And yes, I *am* a hypocrit who takes one position in one thread, and
then says he'd do the opposite in another. :-)

SteveT



  Please, Steve, provide us with all you mentionned, as an
alternative to mainstream bloated/infected stuff. Since Devuan is all
about freedom, this is the place where to deliver to the world. As
soon as I can install Devuan on metal, I'll be one of your testers.

  Didier

OK. What should come first?

* Automounter?
* No-dbus replacement for NetworkManager/Wicd?
* Other?

Please keep in mind, I'm not a good enough programmer to write a
substitute for Gimp or Gnome. Let's keep the first one simple and easy
so I can actually do it, in a reasonable timeframe, without adversely
impacting my real work.


Well you seem to have a lot of ideas and recipes and a good 
experience of not well known simple and smart tools. I got just two 
ideas of things you already discussed:


 Do you think a mount helper would be achievable with dmenu? I know 
you and some other people prefer an automounter, and may be it could be 
a first step before the mount helper.


A light replacement for wpagui/wicd would be nice. Interfacing 
directly with wpa_supplicant requires probably a lot of technical 
knowledge about wifi protocols. But maybe it is simpler when interfacing 
through wpacli - let's not re-invent the wheel.


I know we have all shaked ideas about all this but it does not 
prove that it is easy. What I mean is if you make something smart and 
usefull for you, people will love to try it because many here are tuned 
on the same frequency as you, KISS and smart.


Didier

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

Re: [DNG] Alpha2 without desktop environment

[Isaac Dunham]

On Sat, Aug 15, 2015 at 11:54:06AM -0400, Steve Litt wrote:
> On Fri, 14 Aug 2015 22:25:06 -0700
> Isaac Dunham  wrote:
> 
> > On Fri, Aug 14, 2015 at 07:01:11AM -0400, Haines Brown wrote:
> > > The aim is to boot to a console prompt, log in as root, install
> > > xorg and fluxbox. That gives me X and a window manager but no
> > > desktop environment. At present I get a log in prompt and can log
> > > in as user in console, but for some reason root log in not working.
> > > I suppose that when I provided a password I mistyped. 
> > 
> > At the grub menu, edit the kernel commandline to change
> > "root=... ro ..." to "root=... rw ... init=/bin/bash"
> > 
> > Then run "passwd", sync a couple times, and reboot.
> > 
> > HTH,
> > Isaac Dunham
> 
> Why change ro to rw?

"root=/dev/sda6 ro" means that when initrd (or the kernel) mounts
/dev/sda6, it mounts it read-only (ro).
Then the initscripts run fsck, and remount '/' as read-write (rw).

So if you don't change it to "rw", you will need to manually remount
/ so that it's writeable; I think this would be one way to do so:
 mount -o remount,rw /

HTH,
Isaac Dunham

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

Re: [DNG] Systemd Shims

[Rainer Weikusat]

Simon Hobson  writes:
> T.J. Duchene  wrote:
>> I used Debian Sid recently, with the apparent ability to boot
>> using either System 5 or Systemd via Grub. The choice seems clear to me
>> that Devuan could minimize upsteam maintenance by looking at that.
>
> The problem is not which init system to use - SystemD is not just an
> init system. Even if you use Sys5 init, there are a lot of packages
> that require parts of SystemD to install/work - so being able to boot
> with Sys5 init is a bit of a red herring really.

As recently demonstrated, dealing with such situations one-by-one isn't
really a problem: You (or anyone else) could use the patch I posted to
compile a systemd-free clamav package for Jessie and share the results
for distribution. In case it doesn't address the issue completely enough
from a practical point, I could very likely help with getting it to
this point (within some reasonable time limits, obviously).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Simon Hobson]

Stephanie Daugherty  wrote:

> They did, but out of all this design by committee, hidden between all the 
> political bullshit and bikeshedding, they also created the most brilliant, 
> most comprehensive set of standards for quality control, package uniformity, 
> license auditing, and of course. the most robust dependency management, at 
> least among binary distributions.
> 
> More importantly than that, they backed these standards up with automated 
> tools that are nearly as robust as the standards themselves. You don't see 
> packages interfering with one another very often in the Debian world, because 
> this is caught right away by scripts that check that every file installed by 
> a package, or automatically created by that package belongs to EXACTLY ONE 
> package, otherwise all the packages have to use some approved mechanism to 
> cooperate. You also see this effort it in difficult to configure packages 
> that set themselves up and work out of the box, and in the modularized 
> configuration that's common to many packages. 
> 
> Most importantly, this rigid attention to detail  is why for more than a 
> decade now, in place upgrades have been fully supported, officially 
> recommended and for the most part, Just Work(tm(. It used to be said, back in 
> the day that the installer was still horrible, "thank god you only ever have 
> to see it once"

That's how I see it too - I've been using Debian by choice for a lot of years - 
in fact, the only systems I run that aren't debian are where I've used a 
"packaged" setup, specifically I have a couple of PBX "appliances" which only 
support (at the time they were built) being setup on Centos.



On 15 Aug 2015, at 21:33, Laurent Bercot  wrote:

> And their package management features:
> 
> - no way to have several versions of the same package installed on
> your machine
> - no atomic upgrades for single binary packages: if you have stuff
> running during an upgrade, things can break.
> - no possibility to rollback.

The rollback is a bit of a pain. In spite of the quality control, I have had 
one or two issues in the past where an upgrade has broken a combination of 
stuff - as in X runs on language Y and uses Z for some of it's functions, but 
after an upgrade it "doesn't work" and then have to start manually installing 
older versions of X, Y, and Z to figure out which combination work.

> I'm sure there's a lot of good to say about the way Debian does
> things, but quality of their package management isn't a part of it.
> When you're running production servers and need reliability when
> upgrading software, you just can't use Debian.

I've found it pretty reliable - certainly not as bad as certain commercial 
ecosystems I have dealings with.
My expectations of "problems" during upgrades is less with my Debian systems 
than it is with anything else. That's not to say I've not had problems.


Hendrik Boom  wrote:

> THe way I heard the story, in the ncient days when Apple was choosing 
> the kernel for OS X, they were originally planning to use Linux, but 
> they changed their mind for copyright reasons.  THey didn't want to risk 
> any of their proprietary software becoming free software because of 
> GPL contagion.
> 
> The BSD licence allowed them to do what they wanted.

You do realise that they do in fact use a lot of GPL software don't you ? In 
fact they have contributed some very useful software back into the community 
under GPL.
I'm more inclined to think they just decided the BSD kernel was more suitable 
to their needs.

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

Re: [DNG] Devuan and upstream

[Laurent Bercot]

On 15/08/2015 22:19, Stephanie Daugherty wrote:

They did, but out of all this design by committee, hidden between all
the political bullshit and bikeshedding, they also created the most
brilliant, most comprehensive set of standards for quality control,
package uniformity, license auditing, and of course. the most robust
dependency management, at least among binary distributions.


 And their package management features:

 - no way to have several versions of the same package installed on
your machine
 - no atomic upgrades for single binary packages: if you have stuff
running during an upgrade, things can break.
 - no possibility to rollback.

 I'm sure there's a lot of good to say about the way Debian does
things, but quality of their package management isn't a part of it.
When you're running production servers and need reliability when
upgrading software, you just can't use Debian. And that is sad.

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

Re: [DNG] Devuan and upstream

[Hendrik Boom]

On Sat, Aug 15, 2015 at 02:20:44PM -0500, T.J. Duchene wrote:

> 
> Having a specifically defined base makes it easier for third parties to
> ensure that software is going to work without a hitch. It's much more
> attractive from a testing standpoint than the usual Linux hodge-podge. I
> think it is also one of the reasons that Google looks at Gentoo for
> Chrome OS and Apple to FreeBSD.  It just simplifies everything:
> testing, development and bug hunting.

THe way I heard the story, in the ncient days when Apple was choosing 
the kernel for OS X, they were originally planning to use Linux, but 
they changed their mind for copyright reasons.  THey didn't want to risk 
any of their proprietary software becoming free software because of 
GPL contagion.

The BSD licence allowed them to do what they wanted.

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

Re: [DNG] Devuan and upstream

[Stephanie Daugherty]

On Fri, Aug 14, 2015 at 8:20 PM James Powell  wrote:

> Slackware is maintained by 3 core people with extra help as needed. The
> rest of the packages are pushed by the community at large contributing.
> Devuan doesn't have to maintain every package possible. That's ludicrous to
> think so.
>
> Debian got in over its head by allowing this. Thousands upon thousands of
> packages that required a committee to oversee.
>
> They did, but out of all this design by committee, hidden between all the
political bullshit and bikeshedding, they also created the most brilliant,
most comprehensive set of standards for quality control, package
uniformity, license auditing, and of course. the most robust dependency
management, at least among binary distributions.

More importantly than that, they backed these standards up with automated
tools that are nearly as robust as the standards themselves. You don't see
packages interfering with one another very often in the Debian world,
because this is caught right away by scripts that check that every file
installed by a package, or automatically created by that package belongs to
EXACTLY ONE package, otherwise all the packages have to use some approved
mechanism to cooperate. You also see this effort it in difficult to
configure packages that set themselves up and work out of the box, and in
the modularized configuration that's common to many packages.

Most importantly, this rigid attention to detail  is why for more than a
decade now, in place upgrades have been fully supported, officially
recommended and for the most part, Just Work(tm(. It used to be said, back
in the day that the installer was still horrible, "thank god you only ever
have to see it once"

With that said, Debian could have accomplished far more had it not been a
case of Design by committee, or if they had a competent BDFL with a firm
grasp on the overall vision stepping in from time to time when all that
process got out of hand, but I'm not sure if they'd have been ambitious
enough to create some of the architectural  masterpieces they have with
different leadership.


Honestly, what is needed by a distribution? Look at Slackware or BLFS
> that's a lot of packages, but it's manageable by a small team. Why can't
> Devuan follow suit? There doesn't need to be a bagillion packages
> maintained by the main devs. If the rest need to be passed back to the
> community at large, then do it. This also hits the point of why do we need
> 5 different for things like, for example, SDL packages for -bin, -lib,
> -doc, -dev, -src, and such? One package is easier to maintain than five
> individual ones. It lightens the load significantly, especially for the
> poor soul having to make 5 or more different scripts for 5 packages from
> the same source tarball. Yes, it's nice to have small packages for embedded
> stuff and small disks, but do you really want to raise the workload of the
> maintainer that much?
>
>
The various -bin -lib etc packages raise the workload very little, if at
all - once it's properly set up, that part's effectively automated.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Simon Hobson]

T.J. Duchene  wrote:

> I used Debian Sid recently, with the apparent ability to boot
> using either System 5 or Systemd via Grub. The choice seems clear to me
> that Devuan could minimize upsteam maintenance by looking at that.

The problem is not which init system to use - SystemD is not just an init 
system. Even if you use Sys5 init, there are a lot of packages that require 
parts of SystemD to install/work - so being able to boot with Sys5 init is a 
bit of a red herring really.


On 15 Aug 2015, at 01:26, Steve Litt  wrote:

> Oh, you wouldn't want to do that. Contrary to what I wrote in another
> thread about "the perfect is the enemy of the good", if *I* were in
> charge of decontamination, I'd throw out whole subsystems. Gnome gone.
> KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all
> systemd on us.

Which really leads on to one of the "hard choices" facing Devuan.
If you don't have the packages people need to run, then they can't run Devuan. 
And if those needed packages have been modified to need SystemD then it needs 
work to re-convert them. I guess a look at Debian PopCon might give some ideas 
which packages are being used - and hence where to spend limited dev resources.
Though I suppose you could decide to ignore the GUI packages to stat with - 
there's a large user base (like myself) who run headless servers and so really 
don't care about any of the packages in that list !

Long term, you could try and get the GUI stuff in - but I suspect that's going 
to get harder and harder over time as the Japanese Knotweed of the software 
world gets a deeper hold.

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

Re: [DNG] Systemd Shims

[T.J. Duchene]

On Sat, 15 Aug 2015 03:15:50 -0700
James Powell  wrote:

Hi Jim! =)

> 
> To me, a shim is not the way. Sanitization is what is needed, and if
> that requires work, then question this, 'Will the work be worth it?'
> and to me the answer is a definable 'yes'.

I suppose there are some people like yourself who will always feel that
way, and that is quite frankly - "totally awesome".  

All that I ever try to say that I think there should be room for
both sorts to make Devuan a home.  Yes, I think Devuan should have
systemd as an option, but only as an option - never part of the base
system.



> 
> Not to push a button, but I think Funtoo had the right mindset about
> systemd 'No way or chance in Hell'.

I'm sorry Jim, but I see Funtoo as really a bad example of the
situation. 

Funtoo is source based, and Devuan is not.  They are both Linux but it
is two very different worlds of users, like apples and oranges. It's a
LOT easier to excise systemd when you are not expected to provide a
binary.  The minute you are expected to provide an official binary and
have major features removed, users start to complain that your version
is less than everyone else.

Usually, the only ones who use source versions are power users and
programmers who understand and accept the trade-offs in compiling your
own OS.

Have a great day!  =)

T.J.

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

Re: [DNG] Devuan and upstream

[T.J. Duchene]

On Sat, 15 Aug 2015 10:02:12 +
Roger Leigh  wrote:

> That's a considerable  achievement--how many other projects have been
> able to achieve an equivalent scale?

Not very many and I agree with you, it is very impressive, even if
Debian makes internal bickering look commonplace. I'd say it is even
more impressive, that in spite of that, they still manage it.

> 
> Now I think there may have been benefits to separating the "base"
> system from "everything else", and indeed it was discussed on several
> occasions in Debian, but this never happened for various reasons.  In
> retrospect, I think it would have been a good move.

I agree.  

I would rather that Devuan had a smaller fixed base install that was
supported for at least 5 years (or two releases) with a guaranteed ABI
for the life of that base.   You can say that upstream Debian already
does this to some extent, and yes that is true, but there really is no
divider between base and the rest of the repo. 


It might seem rather arbitrary at all, but giving someone a clear
notion of what is going on is key in IT.  Even if two products are
exactly the same, the one that is presented with less hassle wins
the day. 

Having a specifically defined base makes it easier for third parties to
ensure that software is going to work without a hitch. It's much more
attractive from a testing standpoint than the usual Linux hodge-podge. I
think it is also one of the reasons that Google looks at Gentoo for
Chrome OS and Apple to FreeBSD.  It just simplifies everything:
testing, development and bug hunting.

Heck, I'd make a reasonable guess that if Devuan had a fixed
base that Valve might even chose Devuan over Debian for future versions
of SteamOS, because it would be less work for them to do.  They wouldn't
have to dissect as much to get the base that they need.
 

> That said, I do think multi-binary package generation could be
> automated for the common cases.  It's pretty trivial to distinguish
> headers, libraries, documentation, translations, source, debug
> symbols from the filesystem locations they live in.  This is also
> something which has been discussed over the years.  The tool changes
> to accommodate it are not insignificant though.

 Gentoo proved that you can set a series of global package "flags"
 specifying what support to include or exclude when building a binary
 package. It's practical and it works for large scale package chains.
 It's completely automated. I see no reason why Debian or Devuan cannot
 incorporate the idea to build sets of the same packages with and
 without systemd support and then let the user choose what they want.

It's just my opinion, and no one has to agree, but if Devuan ever wants
to be a major distribution, systemd has to become a non-issue. It
should just another piece of software, installed at user's whim.  

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

Re: [DNG] Devuan and upstream

[T.J. Duchene]

On Sat, 15 Aug 2015 10:13:56 +
Roger Leigh  wrote:

er revision for 2017, and I think they are nuts.
> 
> I don't.  I write C++ code for my day job, and I'd have to say that 
> these revisions make C++ better than ever to write.  It's cleaner, 
> simpler, and more maintainable.  Just last week I wrote some
> prototype code in C++11, and later had to change it to use C++98
> features to comply with the project's requirements.  It doubled the
> line count and made it vastly less readable, and this was using only
> two features: auto types and range-base for loops.  The benefits it
> provides are not insignificant.

I don't argue against the apparent benefits.  Quite the reverse,
actually.  The people who work on the ISO standards are far from stupid
people and probably know more than I ever will on the subject.  

I admit I am concerned from time to time that things are not as thought
out as they might be.  Rapid releases curtail discussion, and one thing
I do not want to see is C++ ending up like de-facto languages, where
you can't depend on anything to any extent.

 
> When you say they are "nuts", are there any changes in C++14 or C++17 
> which you have found to be ill-considered?  

Not at presently, but to be perfectly honest, my exposure to C++11 has
been limited so far.  Thanks to you, I've been spending more time with
it.

My concern is actually over implementation. Historically, phasing in
support for standards tends to be done slowly, often piecemeal, and
there are always bugs.  By rapidly releasing changes to the standards,
I am concerned that more regressions will creep into the compiler
software in the mad scramble to keep up with demand.

Microsoft's Visual Studio is famous for being a pain in the backside.
I would hate to see GCC get worse, because they already have a less
than sterling reputation for bug resolution.  I've not used Clang
extensively, so I can't speak to it.



> While no standard is ever "perfect", I have no complaints about
> C++11 or C++14.  Since these are ISO standards, the realities of the
> process means there's little scope for pushing in lots of poorly
> thought out changes at the last minute--most of the changes have been
> planned and implemented for many years.  

I would agree with you, and rest easy in that the ISO is keeping things
under control except that they seem to be make use of "fast track" on a
number of things these days.  Thankfully, most of the fast track
ballots seem to be for Microsoft crap.

T.J.

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

Re: [DNG] Systemd Shims

[T.J. Duchene]

On Sat, 15 Aug 2015 12:01:35 -0400
Steve Litt  wrote:

Please, Steve, provide us with all you mentionned, as an 
> > alternative to mainstream bloated/infected stuff. Since Devuan is
> > all about freedom, this is the place where to deliver to the world.
> > As soon as I can install Devuan on metal, I'll be one of your
> > testers.
> > 
> >  Didier
> 
> OK. What should come first?
> 
> * Automounter?
> * No-dbus replacement for NetworkManager/Wicd?
> * Other?
> 
> Please keep in mind, I'm not a good enough programmer to write a
> substitute for Gimp or Gnome. Let's keep the first one simple and easy
> so I can actually do it, in a reasonable timeframe, without adversely
> impacting my real work.
> 
I think what can be done has been done as far as Devuan 1.0 and there
is no reason to be overly zealous about the issue of systemd.
Conversely, it is the future that concerns me.  I think that in
the interests of user choice and to ease upstream maintenance from
Debian and eventually from projects like Gnome some form of
accommodation for systemd will have to be made.

I used Debian Sid recently, with the apparent ability to boot
using either System 5 or Systemd via Grub. The choice seems clear to me
that Devuan could minimize upsteam maintenance by looking at that.  If
it is truly a System 5 boot, a lot of problems could be eased by
simply making System 5 boot the default in Grub, and then leaving the
choice up to the user.  

I suspect that the Sid install I was using had systemd-shim installed
in order to handle certain packages. I'm sorry to say that I did not
verify this.  My time was limited. I had to move on and install
something else. Even if it was systemd-shim, what if Devuan simply
cloned Debian, used System 5 + systemd-shim as the default?  As a
supplement, Devuan could add a set of alternative packages to replace
systemd ones in post-release.

I know that would be distasteful to some, but it would be the easiest
route with a small team, limited resources, and it would give the
Devuan time more breathing room and time to do things. It would
preserve user choice and not force Devuan to drop packages that it does
not have the developers to fork.


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

Re: [DNG] Systemd Shims

[Rainer Weikusat]

Simon Hobson  writes:
> Rainer Weikusat  wrote:
>
>> ClamAV claims to support FreeBSD, OpenBSD, NetBSD, Solaris, OpenVMS,
>> Slackware and Windows, all of which certainly don't have systemd. I've
>> just cloned the current development repository and build it on Wheezy
>> using a plain
>> 
>> ./configure
>> make
>> 
>> which worked without issues and this system is certainly systemd-free,
>> too.
>
> Which makes it even more non-sensical to make it have systemd dependencies.
>
>> Could perhaps provide some kind of link illustrating what you were
>> referring to?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789283
>
> And from http://lists.clamav.net/pipermail/clamav-users/2015-June/001604.html
>> BTW, since I'm the primary clamav maintainer in Debian, guess how
> >much action your report is going to get.

> As you've pointed out, this is a package widely used across various
> OSs, and is still officially supported in Wheezy through security
> updates. But the Debian Jessie package hard depends on libsystemd0.

Since that's basically a requirement one of Debian guys gratuitiously
added and the package actually supports building without systemd, just
not for Debian 8 onwards, it's easy to get rid of it:

-
diff -rNu clamav-0.98.7+dfsg/debian/clamav-daemon.install 
clamp/debian/clamav-daemon.install
--- clamav-0.98.7+dfsg/debian/clamav-daemon.install 2015-05-02 
03:48:31.0 +0100
+++ clamp/debian/clamav-daemon.install  2015-08-15 16:53:27.732670081 +0100
@@ -1,6 +1,4 @@
 debian/script usr/share/bug/clamav-daemon/
-debian/tmp/lib/systemd/system/clamav-daemon.service
-debian/tmp/lib/systemd/system/clamav-daemon.socket
 debian/tmp/usr/bin/clamconf
 debian/tmp/usr/bin/clamdtop
 debian/tmp/usr/sbin/clamd
diff -rNu clamav-0.98.7+dfsg/debian/clamav-freshclam.install 
clamp/debian/clamav-freshclam.install
--- clamav-0.98.7+dfsg/debian/clamav-freshclam.install  2015-05-02 
03:48:31.0 +0100
+++ clamp/debian/clamav-freshclam.install   2015-08-15 16:53:11.237179310 
+0100
@@ -3,6 +3,5 @@
 debian/clamav-freshclam-ifupdown etc/ppp/ip-down.d/
 debian/clamav-freshclam-ifupdown etc/ppp/ip-up.d/
 debian/script usr/share/bug/clamav-freshclam/
-debian/tmp/lib/systemd/system/clamav-freshclam.service
 debian/tmp/usr/bin/freshclam
 debian/usr.bin.freshclam etc/apparmor.d/
diff -rNu clamav-0.98.7+dfsg/debian/rules clamp/debian/rules
--- clamav-0.98.7+dfsg/debian/rules 2015-05-03 02:57:42.0 +0100
+++ clamp/debian/rules  2015-08-15 16:54:28.970779493 +0100
@@ -48,7 +48,6 @@
--disable-clamav --disable-unrar --enable-milter --enable-dns-fix \
--with-libjson \
--with-gnu-ld $(SYSTEM_LLVM) \
-   --with-systemdsystemunitdir=/lib/systemd/system
 
 DEBUG_OPTS=
 
@@ -60,20 +59,19 @@
 endif
 
 # The autotools in squeeze (Debian 6) are too old, so don't use autoreconf.
-# And don't use systemd.
 ifeq ($(shell cut -c1 /etc/debian_version),6)
   AUTORECONF =
-  SYSTEMD =
 else
 ifeq ($(shell cut -c1 /etc/debian_version),7)
   AUTORECONF = --with autoreconf
-  SYSTEMD =
 else
   AUTORECONF = --with autoreconf
-  SYSTEMD = --with systemd
 endif
 endif
 
+# don't use systemd
+SYSTEMD =
+
 # Use the default debhelper scripts, where possible.
 # Enable parallel building and conditionally autoreconf and systemd.
 %:

-

The patch is supposed to be applied to the unpacked Debian source
package. Without the changes to the install files, the package
apparently can't be build on wheezy at all, at least, it failed for me.
I've tested that it builds on wheezy with these changes.

BTW, one of the reasons why I'll try to stay clear of systemd is because
I won't ever voluntarily trust people who employ this "aggressive jerk
in a position of power" communication style in order to (man-)'handle'
individuals with dissenting opinions: This is not only unpleasant but
also deeply irrational.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [hai...@histomat.net: Re: Alpha2 without desktop environment]

[Steve Litt]

On Sat, 15 Aug 2015 07:43:04 -0400
Haines Brown  wrote:


> I purged and reinstalled xorg without luck. Installed were
> libglu1-mesa, x11-apps, x11-session-utils, x11-server-utils, xinit,
> xorg, xorg-docs-core.
> 
> The xorg log tells me that it is using as system configuration
> directory, /usr/share/X11/xorg.c.

What happens when you try it after manually creating the directory?




SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Steve Litt]

On Sat, 15 Aug 2015 08:51:55 +0200
Didier Kryn  wrote:

> Le 15/08/2015 02:26, Steve Litt a écrit :
> > On Fri, 14 Aug 2015 14:49:17 -0700
> > Go Linux  wrote:
> >
> >> On Fri, 8/14/15, T.J. Duchene  wrote:
> >>
> >>   Subject: Re: [DNG] Systemd Shims
> >>   To: dng@lists.dyne.org
> >>   Date: Friday, August 14, 2015, 2:47 PM
> >>   
> >>> I know not everyone here agrees with me, especially Steve, and
> >>> that's perfectly okay.  I have no problem with that at all. I just
> >>> don't see "System 5 pure"  as realistic when planning ahead
> >>> looking at a maintenance standpoint when Debuan upstream is more
> >>> and more likely to stick with Systemd in designing their
> >>> packaging.
> >>>
> >> Maybe we should just put Steve in charge of decontaminating all
> >> packages with systemd deps!
> > Oh, you wouldn't want to do that. Contrary to what I wrote in
> > another thread about "the perfect is the enemy of the good", if *I*
> > were in charge of decontamination, I'd throw out whole subsystems.
> > Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if
> > it gets all systemd on us.
> >
> > In the massive time I save as not being the bomb squad defusing Red
> > Hat's terrorism, I'd write small replacements for a lot of things
> > that use only Linux and a very rudimentary and optional GUI
> > interface.
> >
> > Then I'd write documentation explaining how to use a sharp thinking
> > computer, to the proud ignorants of the world, especially those who
> > believe their ignorance is a badge of honor proving their age or
> > gender.
> >
> > And the people who prioritize pretty over functional and robust: I'd
> > tell them to get a Mac.
> >
> > You don't want me in that capacity.
> >
> > And yes, I *am* a hypocrit who takes one position in one thread, and
> > then says he'd do the opposite in another. :-)
> >
> > SteveT
> >
> >
> 
>  Please, Steve, provide us with all you mentionned, as an 
> alternative to mainstream bloated/infected stuff. Since Devuan is all 
> about freedom, this is the place where to deliver to the world. As
> soon as I can install Devuan on metal, I'll be one of your testers.
> 
>  Didier

OK. What should come first?

* Automounter?
* No-dbus replacement for NetworkManager/Wicd?
* Other?

Please keep in mind, I'm not a good enough programmer to write a
substitute for Gimp or Gnome. Let's keep the first one simple and easy
so I can actually do it, in a reasonable timeframe, without adversely
impacting my real work.

Thanks,

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Alpha2 without desktop environment

[Steve Litt]

On Fri, 14 Aug 2015 22:25:06 -0700
Isaac Dunham  wrote:

> On Fri, Aug 14, 2015 at 07:01:11AM -0400, Haines Brown wrote:
> > The aim is to boot to a console prompt, log in as root, install
> > xorg and fluxbox. That gives me X and a window manager but no
> > desktop environment. At present I get a log in prompt and can log
> > in as user in console, but for some reason root log in not working.
> > I suppose that when I provided a password I mistyped. 
> 
> At the grub menu, edit the kernel commandline to change
> "root=... ro ..." to "root=... rw ... init=/bin/bash"
> 
> Then run "passwd", sync a couple times, and reboot.
> 
> HTH,
> Isaac Dunham

Why change ro to rw?

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Go Linux]

On Fri, 8/14/15, Steve Litt  wrote:

 Subject: Re: [DNG] Systemd Shims
 To: dng@lists.dyne.org
 Date: Friday, August 14, 2015, 7:26 PM
 
 On Fri, 14 Aug 2015 14:49:17 -0700

Go Linux  wrote:

> On Fri, 8/14/15, T.J. Duchene  wrote:
>
>  Subject: Re: [DNG] Systemd Shims
>  To: dng@lists.dyne.org
>  Date: Friday, August 14, 2015, 2:47 PM
>> 
>> > I know not everyone here agrees with me, especially Steve, and
>> > that's perfectly okay.  I have no problem with that at all. I just
>> > don't see "System 5 pure"  as realistic when planning ahead looking
>> > at a maintenance standpoint when Debuan upstream is more and more
>> > likely to stick with Systemd in designing their packaging.
>> >
>>
>> Maybe we should just put Steve in charge of decontaminating all
>> packages with systemd deps!
>
> Oh, you wouldn't want to do that. Contrary to what I wrote in another
> thread about "the perfect is the enemy of the good", if *I* were in
> charge of decontamination, I'd throw out whole subsystems. Gnome gone.
> KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all
> systemd on us.
> 



Whoa!  I suggested putting you in charge of decontaminating packages not 
deciding inclusion/exclusion policy!  Actually the suggestion was more to pull 
your chain than anything else (and it worked didn't it).  You're quite 
entertaining when you get wound up.  :)

golinux





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

Re: [DNG] Using apt pinning to block systemd in DEVUAN 64 bit

[Anto]

On 15/08/15 15:53, Edward Bartolo wrote:

So, init was transitional.

Thanks.


Yes. It was. But now it is an essential package in both Debian and 
Devuan. I am not sure what is the purpose of that for Devuan. But 
according to the discussion some time ago, it looks like it is to keep 
the option for Devuan to support systemd open.


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

Re: [DNG] Using apt pinning to block systemd in DEVUAN 64 bit

[Adam Borowski]

On Sat, Aug 15, 2015 at 03:33:31PM +0200, Anto wrote:
> On 15/08/15 14:39, Edward Bartolo wrote:
> >What is the purpose of:
> >
> >Package: init
> >Pin: origin ""
> >Pin-Priority: -1
> 
> As far as I understood, the init package was developed to allow smoother
> transition of Debian default init from sysvinit to systemd. As sysvinit was
> an essential package in Debian before, there was no way to switch the
> default init to systemd so they invented init package. Some people argue
> that the init package was necessary to allow switching from one init system
> to the other ones. But I don't really buy that because there was no problem
> in switching init systems before systemd started to emerge. It is quite
> clear to me that it is there because of systemd.
> So I really hate the idea
> of keeping that in Devuan. That is why I don't want to use init,

Switching init systems worked, infesting already installed systems did not.
The package though is harmless, and it's cleaner than wheezy's essential
sysvinit package forcing itself on non-sysv systems.

> init-system-helpers

Now this, despite its description lying through the teeth about "being
useful for all init systems, I swear" is purely 100% systemd crap.  But a
load of daemons depend on it in order to work on systemd systems.  The
helpers are benign with a sane init, and do nothing but wasting a few kb of
space.  Certainly not something worth the effort to work around the
dependencies.

> sysvinit-core

Uhm... that _is_ sysvinit now.  100% unrelated to systemd.

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Using apt pinning to block systemd in DEVUAN 64 bit

[Anto]

On 15/08/15 14:39, Edward Bartolo wrote:

What is the purpose of:

Package: init
Pin: origin ""
Pin-Priority: -1

Thanks.



Hello Edward,

As far as I understood, the init package was developed to allow smoother 
transition of Debian default init from sysvinit to systemd. As sysvinit 
was an essential package in Debian before, there was no way to switch 
the default init to systemd so they invented init package. Some people 
argue that the init package was necessary to allow switching from one 
init system to the other ones. But I don't really buy that because there 
was no problem in switching init systems before systemd started to 
emerge. It is quite clear to me that it is there because of systemd. So 
I really hate the idea of keeping that in Devuan. That is why I don't 
want to use init, init-system-helpers, sysvinit-core and anything 
related to them, and of course "no systemd!".


The impact is that, I have to keep using the version of sysvinit in 
Debian wheezy as below.I am not sure for how long but I will keep trying 
to have other init system, in case at some point I will not be able to 
use sysvinit anymore.


Cheers,

Anto

root@hp8530w:~# dpkg --list | grep sysvinit
ii  sysvinit 2.88dsf-41+deb7u1amd64
System-V-like init utilities
ii  sysvinit-utils 2.88dsf-41+deb7u1amd64
System-V-like utilities

root@hp8530w:~#
root@hp8530w:~# apt-cache policy sysvinit sysvinit-utils
sysvinit:
  Installed: 2.88dsf-41+deb7u1
  Candidate: 2.88dsf-41+deb7u1
  Version table:
 2.88dsf-59.2+devuan2 0
 90 http://packages.devuan.org/merged/ jessie/main amd64 Packages
 *** 2.88dsf-41+deb7u1 0
800 http://ftp.debian.org/debian/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status
sysvinit-utils:
  Installed: 2.88dsf-41+deb7u1
  Candidate: 2.88dsf-41+deb7u1
  Version table:
 2.88dsf-59.2+devuan2 0
 90 http://packages.devuan.org/merged/ jessie/main amd64 Packages
 *** 2.88dsf-41+deb7u1 0
800 http://ftp.debian.org/debian/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status
root@hp8530w:~#

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

Re: [DNG] Correction: Re: systemd files found in fresh devuan alpha2 install.

[Riccardo Boninsegna]

Il 15/ago/2015 03:05 PM, "Hendrik Boom"  ha scritto:
> There are still a few systemd-related packages iinstalled:
>
> libpam-systemd
> systemd
> systemd-shim
> libsystemd0
> Is this normal?

Yes (for now), and you can easily remove all of them, except libsystemd0,
with no issues

If you use the version of Xfce in Ascii, install pm-utils and standby from
the GUI will work fine!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Correction: Re: systemd files found in fresh devuan alpha2 install.

[Hendrik Boom]

I accidentally checked for systemd using aptitude on the wrong system.
There are actually a lot more systemd packages.

On Sat, Aug 15, 2015 at 08:58:46AM -0400, Hendrik Boom wrote:
> After a clean install of devuan from the alpha2 iso using a USB stick
> my system is running properly, with xfce and an unknown display manager.
> The only packages I asked to install were ones from dselect in the installer, 
> and very few of those.  Beyond the defaults, I asked
> for xfce.
> 

There are still a few systemd-related packages iinstalled:

libpam-systemd
systemd
systemd-shim
libsystemd0

> 
> Is this normal?
> 
-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] systemd files found in fresh devuan alpha2 install.

[Hendrik Boom]

After a clean install of devuan from the alpha2 iso using a USB stick
my system is running properly, with xfce and an unknown display manager.
The only packages I asked to install were ones from dselect in the installer, 
and very few of those.  Beyond the defaults, I asked
for xfce.

There does appear to be one systemd package, though:

libsystemd-login0

and a whole lot of systemd files in /bin
  in /etc/systemd
  in /lib/systemd
  in /usr/bin
  in /usr/lib/systemd
  /usr/share/systemd
  in /usr/share/bash-completion/completions/

and so forth.

Is this normal?

Would I damage the system if I got rid of libsystemd-login0?

-- hendrik

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

[DNG] Stupid LVM conflict resolved

[Hendrik Boom]

On Sat, Aug 15, 2015 at 05:15:44PM +1200, Daniel Reurich wrote:
> On 15/08/15 16:54, Hendrik Boom wrote:
> >On Sat, Aug 15, 2015 at 03:21:47PM +1200, Daniel Reurich wrote:
> >>On 15/08/15 14:47, Hendrik Boom wrote:
> >>
> 
> Don't forget to do `update-initramfs -u -k all` and `update-grub` to
> rebuild the
> >>>
> >>>Ouch. update-initramfs crapped out:
> >>>
> >>>oot@notlookedfor:~# update-initramfs -u -k all
> >>>update-initramfs: Generating /boot/initrd.img-3.16.0-4-686-pae
> >>>mkinitramfs: failed to determine device for /usr
> >>>mkinitramfs: workaround is MODULES=most, check:
> >>>grep -r MODULES /etc/initramfs-tools/
> >>
> >>so it failed to determine the path for /usr.
> >>
> >>Double check your fstab uses either the new path and that the new
> >>path exists (if it's using UUID= for /usr it shouldn't need to be
> >>changed.
> >>
> >>You may need to do a `mount -o remount /usr` so that your cat
> >>/proc/mounts matches /etc/fstab
> >
> >mount -o remount /usr
> >
> >doesn't help.  It seems to have figured out all by itself that / is now
> >on
> >/dev/mapper/jessie-devuan--root
> >but it still thinks /usr is on
> >/dev/mapper/VG1-devuan--usr which no longer exists, even after the
> >remount.
> 
> that's a bit weird...
> >
> >It's late at night here, and I'm tired.  (I suppose it's daytime in New
> >Zealand) If no ideas show up overnight I'm going to try rebooting
> >on the off chance that the message is merely precautionary, and if that
> >doesn't work, I can simply reinstall.  It will be easier this time
> >because now that I've already done it.
> >
> >Still wondering why initramfs needs to know where /usr is.
> 
> For tools that it might need - could also be a hangover from systemd
> which can't cope with a separate /usr volume.

Rebooted with no problems.  I suspecct the need for /usr it was a 
precautionary check left over from systemd.

-- hendrik

> >
> >>
> >>>Another anomaly:
> >>>
> >>>I grepped for my new volume group in /boot/grub/grub.cfg, and the third
> >>>"linux" line it produced was:
> >>>
> >>>linux  /vmlinuz-3.16.0-4-686-pae root=/dev/mapper/jessie-devuan--root
> >>>ro  quiet init=/lib/systemd/systemd
> >>>
> >>>The others did not mention systemd.
> >>>
> >>>THen I noticed that /lib/systemd/ is a fully populated  directory, with
> >>>lots of systemd stuff in it.  Surprise!  To be investigated another day.
> >>
> >>That looks like you've got systemd-sysv installed - what do you have
> >>for PID1?
> >
> >4 S 0 1 0  0  80   0 -   810 poll_s ?00:00:01 init
> >
> >Some program called init.  There is an /sbin/init, but I have no proof
> >that it is indeed that one.
> 
> Ok that's fine then.
> >
> >There's also a process running systemd-logind but the name may have been
> >trunctated.  Could it have come in with xfce?  or whatever display
> >manager Devuan uses?
> 
> It's pulled in by libpamsystemd which some packages still depend on
> in particular cups.
> >
> >I thought, in my innocence, that devuan might have avoided systemd.  I
> >guess we're not all the way there yet.
> >
> We're working on it.  You should be able to have an entirely systemd
> free server and XFCE desktop, and possibly mate.  Not sure whether
> Gnome3 will ever be able to be fully free'd from systemd tho.
> 
> Daniel
> 
> -- 
> Daniel Reurich
> Centurion Computer Technology (2005) Ltd.
> 021 797 722
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Using apt pinning to block systemd in DEVUAN 64 bit

[Anto]

On 15/08/15 13:53, Edward Bartolo wrote:

I tried to install xfce4-power-manager which tried to pull in systemd.
Does it harm my new installation of DEVUAN to use apt pinning to block
packages like libsystemd0 and systemd?



Hello Edward,

Since months ago I always have /etc/apt/preferences.d/00blocksystemd on 
any of my installs either on my PC or VPS' containing entries at the 
bottom of this email.


On my PC, I have the following packages related to xfce4-power-manager 
installed on my PC.


root@hp8530w:~# dpkg --list | grep xfce4-power-manager
ii  xfce4-power-manager 1.0.11-2+b1  
amd64power manager for Xfce desktop
ii  xfce4-power-manager-data 1.0.11-2 
all  power manager for Xfce desktop, arch-indep files
ii  xfce4-power-manager-plugins 1.0.11-2+b1  
amd64power manager plugins for Xfce panel

root@hp8530w:~#
root@hp8530w:~# apt-cache policy xfce4-power-manager
xfce4-power-manager:
  Installed: 1.0.11-2+b1
  Candidate: 1.0.11-2+b1
  Version table:
 1.4.1-1 0
 90 http://packages.devuan.org/merged/ jessie/main amd64 Packages
 *** 1.0.11-2+b1 0
800 http://ftp.debian.org/debian/ wheezy/main amd64 Packages
100 /var/lib/dpkg/status
root@hp8530w:~#

I am still using XFCE 4.8 though, as I am not happy with XFCE 4.10. I 
will try XFCE 4.12 when it is available in Devuan repository.


Cheers,

Anto


root@hp8530w:~# cat /etc/apt/preferences.d/00blocksystemd
Package: dh-systemd
Pin: origin ""
Pin-Priority: -1

Package: gnome-logs
Pin: origin ""
Pin-Priority: -1

Package: golang-coreos-log-dev
Pin: origin ""
Pin-Priority: -1

Package: golang-go-systemd-dev
Pin: origin ""
Pin-Priority: -1

Package: init
Pin: origin ""
Pin-Priority: -1

Package: libghc-libsystemd-journal-dev
Pin: origin ""
Pin-Priority: -1

Package: libghc-libsystemd-journal-doc
Pin: origin ""
Pin-Priority: -1

Package: libghc-libsystemd-journal-prof
Pin: origin ""
Pin-Priority: -1

Package: libpam-systemd
Pin: origin ""
Pin-Priority: -1

Package: libsystemd0
Pin: origin ""
Pin-Priority: -1

Package: libsystemd-id128-0
Pin: origin ""
Pin-Priority: -1

Package: libsystemd-id128-dev
Pin: origin ""
Pin-Priority: -1

Package: libsystemd-journal0
Pin: origin ""
Pin-Priority: -1

Package: libsystemd-journal-dev
Pin: origin ""
Pin-Priority: -1

Package: libsystemd-login0
Pin: origin ""
Pin-Priority: -1

Package: libsystemd-login-dev
Pin: origin ""
Pin-Priority: -1

Package: live-config-systemd
Pin: origin ""
Pin-Priority: -1

Package: python3-systemd
Pin: origin ""
Pin-Priority: -1

Package: systemd-cron
Pin: origin ""
Pin-Priority: -1

Package: systemd-dbg
Pin: origin ""
Pin-Priority: -1

Package: systemd-gui
Pin: origin ""
Pin-Priority: -1

Package: systemd-shim
Pin: origin ""
Pin-Priority: -1

Package: systemd
Pin: origin ""
Pin-Priority: -1

Package: systemd-sysv
Pin: origin ""
Pin-Priority: -1

Package: systemd-ui
Pin: origin ""
Pin-Priority: -1

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

[DNG] Using apt pinning to block systemd in DEVUAN 64 bit

[Edward Bartolo]

I tried to install xfce4-power-manager which tried to pull in systemd.
Does it harm my new installation of DEVUAN to use apt pinning to block
packages like libsystemd0 and systemd?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] [hai...@histomat.net: Re: Alpha2 without desktop environment]

[Haines Brown]

I reiinstalled (avoiding past missteps), to a console, and from it
installed xorg and fluxbox. I then ran xstart from console and all went
well.

With one exception. I'm in what looks like VGA mode with large crude
characters. It seems a problem (or symptom) is that installation did not
create a /etc/X11/xorg.conf.d/ directory that should holding, I
presume, a 20-nvidia.conf file. I created them by hand, but startx
failed with error in log to effect that there is no server section.
I suspect this is not the file that should have a Server section.

I purged and reinstalled xorg without luck. Installed were libglu1-mesa,
x11-apps, x11-session-utils, x11-server-utils, xinit, xorg,
xorg-docs-core.

The xorg log tells me that it is using as system configuration
directory, /usr/share/X11/xorg.c. Because this file does not exist, the
log complains about missing layout, screen and monitor definitions. It
seems xorg is using defaults. 

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

Re: [DNG] Systemd Shims

[James Powell]

My $0.02...

Shims are not needed, or, in my viewpoint, wanted. You're still working with 
systemd or pseudo-systemd and either way you see it, it's still systemd. While 
the prospect of systemd-shim does allow to separate the API layer and logind 
out from the core project, as uselessd allowed the systemd-init to be separated 
out, it's still working with systemd, and systemd is still required to build 
it, the shim, from source. The only shim that doesn't require systemd is 
loginkit and that project hasn't really done much, no offensive meant.

To me, a shim is not the way. Sanitization is what is needed, and if that 
requires work, then question this, 'Will the work be worth it?' and to me the 
answer is a definable 'yes'.

If this is going to be System V based GNU/Linux, then why is there talk of 
systemd? System V GNU/Linux is not systemd GNU/Linux.

Not to push a button, but I think Funtoo had the right mindset about systemd 
'No way or chance in Hell'.

-Jim

From: Didier Kryn
Sent: ‎8/‎14/‎2015 11:52 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] Systemd Shims

Le 15/08/2015 02:26, Steve Litt a écrit :
> On Fri, 14 Aug 2015 14:49:17 -0700
> Go Linux  wrote:
>
>> On Fri, 8/14/15, T.J. Duchene  wrote:
>>
>>   Subject: Re: [DNG] Systemd Shims
>>   To: dng@lists.dyne.org
>>   Date: Friday, August 14, 2015, 2:47 PM
>>
>>> I know not everyone here agrees with me, especially Steve, and
>>> that's perfectly okay.  I have no problem with that at all. I just
>>> don't see "System 5 pure"  as realistic when planning ahead looking
>>> at a maintenance standpoint when Debuan upstream is more and more
>>> likely to stick with Systemd in designing their packaging.
>>>
>> Maybe we should just put Steve in charge of decontaminating all
>> packages with systemd deps!
> Oh, you wouldn't want to do that. Contrary to what I wrote in another
> thread about "the perfect is the enemy of the good", if *I* were in
> charge of decontamination, I'd throw out whole subsystems. Gnome gone.
> KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all
> systemd on us.
>
> In the massive time I save as not being the bomb squad defusing Red
> Hat's terrorism, I'd write small replacements for a lot of things that
> use only Linux and a very rudimentary and optional GUI interface.
>
> Then I'd write documentation explaining how to use a sharp thinking
> computer, to the proud ignorants of the world, especially those who
> believe their ignorance is a badge of honor proving their age or
> gender.
>
> And the people who prioritize pretty over functional and robust: I'd
> tell them to get a Mac.
>
> You don't want me in that capacity.
>
> And yes, I *am* a hypocrit who takes one position in one thread, and
> then says he'd do the opposite in another. :-)
>
> SteveT
>
>

 Please, Steve, provide us with all you mentionned, as an
alternative to mainstream bloated/infected stuff. Since Devuan is all
about freedom, this is the place where to deliver to the world. As soon
as I can install Devuan on metal, I'll be one of your testers.

 Didier

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

Re: [DNG] Devuan and upstream

[Roger Leigh]

On 15/08/2015 05:57, T.J. Duchene wrote:

On Fri, 14 Aug 2015 22:38:35 -0700
Isaac Dunham  wrote:




To elaborate on this, GCC 5.1 (I think) has changed the ABI for C++11
support.
Packages using C++11 need to be rebuilt with the new library;
libreoffice has already been rebuilt, but not KDE.


That's a very good point, Isaac.  C++11 is a very interesting revision,
although C++14 is technically the highest available standard. I'm never
a fan of rapidly changing standards, because they tend to be a mess,
poorly considered. I understand they plan another revision for 2017,
and I think they are nuts.


I don't.  I write C++ code for my day job, and I'd have to say that 
these revisions make C++ better than ever to write.  It's cleaner, 
simpler, and more maintainable.  Just last week I wrote some prototype 
code in C++11, and later had to change it to use C++98 features to 
comply with the project's requirements.  It doubled the line count and 
made it vastly less readable, and this was using only two features: auto 
types and range-base for loops.  The benefits it provides are not 
insignificant.


When you say they are "nuts", are there any changes in C++14 or C++17 
which you have found to be ill-considered?  While no standard is ever 
"perfect", I have no complaints about C++11 or C++14.  Since these are 
ISO standards, the realities of the process means there's little scope 
for pushing in lots of poorly thought out changes at the last 
minute--most of the changes have been planned and implemented for many 
years.  There's only one feature I can think of which was bad--template 
export--and this was in C++98; and I think they learned their lesson 
from that one--never put in a standard a features which hasn't been 
implemented and tested in the real world.



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

Re: [DNG] Devuan and upstream

[Roger Leigh]

On 15/08/2015 05:38, Isaac Dunham wrote:

On Fri, Aug 14, 2015 at 02:42:14PM +0200, Adam Borowski wrote:

On Fri, Aug 14, 2015 at 02:02:22PM +0200, Didier Kryn wrote:

 Seems to me there's something weird, both, in libreoffice depending on
just one single version of libstdc++, and in libklabxml being broken by this
version of libstdc++, be it the fault of kde or libstdc++ developpers.


That's the GCC-5 transition, unstable is broken as it's supposed to.  You
can use testing if you're bothered by uninstallable packages (or any other
form of the sky falling).


To elaborate on this, GCC 5.1 (I think) has changed the ABI for C++11
support.
Packages using C++11 need to be rebuilt with the new library; libreoffice
has already been rebuilt, but not KDE.


Technically, there's no ABI break.  Since GCC5, libstdc++ uses symbol 
versioning to provide the old and new std::string etc.  So existing C++ 
code will continue running without any changes.


The need to rebuild is to avoid incompatibilites due to transitive 
dependencies between libraries using the old and new ABIs, which means 
that in practice all C++ libraries need rebuilding using the new ABI.



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

Re: [DNG] Devuan and upstream

[Roger Leigh]

On 15/08/2015 00:19, James Powell wrote:

Slackware is maintained by 3 core people with extra help as needed. The
rest of the packages are pushed by the community at large contributing.
Devuan doesn't have to maintain every package possible. That's ludicrous
to think so.

Debian got in over its head by allowing this. Thousands upon thousands
of packages that required a committee to oversee.


While this might be true to an extent, you can also view it this way: 
the organisation and structure of Debian, the project, allowed it to 
scale to 1000 developers who could maintain 2 packages without 
stepping on each others toes too often.  That's a considerable 
achievement--how many other projects have been able to achieve an 
equivalent scale?


Now I think there may have been benefits to separating the "base" system 
from "everything else", and indeed it was discussed on several occasions 
in Debian, but this never happened for various reasons.  In retrospect, 
I think it would have been a good move.



Honestly, what is needed by a distribution? Look at Slackware or BLFS
that's a lot of packages, but it's manageable by a small team. Why can't
Devuan follow suit? There doesn't need to be a bagillion packages
maintained by the main devs. If the rest need to be passed back to the
community at large, then do it. This also hits the point of why do we
need 5 different for things like, for example, SDL packages for -bin,
-lib, -doc, -dev, -src, and such? One package is easier to maintain than
five individual ones. It lightens the load significantly, especially for
the poor soul having to make 5 or more different scripts for 5 packages
from the same source tarball. Yes, it's nice to have small packages for
embedded stuff and small disks, but do you really want to raise the
workload of the maintainer that much?


I think this is barking up the wrong tree.  Maintaining multi-binary 
source packages isn't the huge burden you're making out.  There's just 
one script to build all the binary packages, so the overhead on that 
side is unchanged.  The separate packages are generally just lists of 
files/directories to be copied into each package, and this is fairly 
easy to maintain.


Having everything in a single package is inflexible and wastes disc 
space.  Undoing all the effort that went into this in the first place 
would be a significant regression.


That said, I do think multi-binary package generation could be automated 
for the common cases.  It's pretty trivial to distinguish headers, 
libraries, documentation, translations, source, debug symbols from the 
filesystem locations they live in.  This is also something which has 
been discussed over the years.  The tool changes to accommodate it are 
not insignificant though.



Regards,
Roger

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