Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #205126 > unrolled thread

Setting default $PATH for all users

Back to article view | Back to linux.debian.user

Contents

  Setting default $PATH for all users Richard Owlett <rowlett@cloud85.net> - 2019-02-08 14:20 +0100
    Re: Setting default $PATH for all users Roberto C. Sánchez <roberto@debian.org> - 2019-02-08 14:30 +0100
      Re: Setting default $PATH for all users <tomas@tuxteam.de> - 2019-02-08 14:40 +0100
        Re: Setting default $PATH for all users Richard Owlett <rowlett@cloud85.net> - 2019-02-08 16:00 +0100
          Re: Setting default $PATH for all users Dan Ritter <dsr@randomstring.org> - 2019-02-08 16:10 +0100
            Re: Setting default $PATH for all users David Wright <deblis@lionunicorn.co.uk> - 2019-02-11 04:10 +0100
              Re: Setting default $PATH for all users <tomas@tuxteam.de> - 2019-02-11 10:00 +0100
                Re: Setting default $PATH for all users rhkramer@gmail.com - 2019-02-11 13:50 +0100
                  Re: Setting default $PATH for all users Curt <curty@free.fr> - 2019-02-11 14:10 +0100
                    Re: Setting default $PATH for all users rhkramer@gmail.com - 2019-02-11 18:10 +0100
                      Re: Setting default $PATH for all users Curt <curty@free.fr> - 2019-02-11 18:30 +0100
                        Re: Setting default $PATH for all users Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-11 18:40 +0100
                          Re: Setting default $PATH for all users Curt <curty@free.fr> - 2019-02-11 18:50 +0100
                            Re: Setting default $PATH for all users David Wright <deblis@lionunicorn.co.uk> - 2019-02-11 21:00 +0100
          Re: Setting default $PATH for all users <tomas@tuxteam.de> - 2019-02-08 16:40 +0100
    Re: Setting default $PATH for all users David Wright <deblis@lionunicorn.co.uk> - 2019-02-08 20:10 +0100
      Re: Setting default $PATH for all users Richard Owlett <rowlett@cloud85.net> - 2019-02-10 22:00 +0100
        Re: Setting default $PATH for all users Andy Smith <andy@strugglers.net> - 2019-02-10 22:30 +0100
          Re: Setting default $PATH for all users Richard Owlett <rowlett@cloud85.net> - 2019-02-10 22:50 +0100
            Re: Setting default $PATH for all users Andy Smith <andy@strugglers.net> - 2019-02-11 00:30 +0100
          Re: Setting default $PATH for all users Lee <ler762@gmail.com> - 2019-02-11 00:10 +0100
            Re: Setting default $PATH for all users Richard Owlett <rowlett@cloud85.net> - 2019-02-11 00:30 +0100
              Re: Setting default $PATH for all users Lee <ler762@gmail.com> - 2019-02-11 01:30 +0100
                Re: Setting default $PATH for all users Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-11 15:40 +0100
        Re: Setting default $PATH for all users <tomas@tuxteam.de> - 2019-02-10 22:50 +0100
          Re: Setting default $PATH for all users Richard Owlett <rowlett@cloud85.net> - 2019-02-10 23:30 +0100
            Re: Setting default $PATH for all users <tomas@tuxteam.de> - 2019-02-11 10:00 +0100
              Re: Setting default $PATH for all users David Wright <deblis@lionunicorn.co.uk> - 2019-02-11 14:50 +0100
        Re: Setting default $PATH for all users David Wright <deblis@lionunicorn.co.uk> - 2019-02-11 03:30 +0100

Page 1 of 2  [1] 2  Next page →

#205126 — Setting default $PATH for all users

I'm running Debian Stretch with MATE desktop.
I want the current user and all future users to include all directories 
in root's $PATH.

I haven't found a definitive answer in my web search. The answer's seem 
to depend on which Linux is used and multiple parameters.

TIA

[toc] | [next] | [standalone]

#205127

On Fri, Feb 08, 2019 at 07:18:39AM -0600, Richard Owlett wrote:
> I'm running Debian Stretch with MATE desktop.
> I want the current user and all future users to include all directories in
> root's $PATH.
> 
> I haven't found a definitive answer in my web search. The answer's seem to
> depend on which Linux is used and multiple parameters.
> 
As with most things in Linux and Unix, it depends.

Some likely candidates are /etc/bash.bashrc, /etc/profile,
/etc/profile.d/, and /etc/environment.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#205128

[Multipart message — attachments visible in raw view] — view raw

On Fri, Feb 08, 2019 at 08:22:54AM -0500, Roberto C. Sánchez wrote:
> On Fri, Feb 08, 2019 at 07:18:39AM -0600, Richard Owlett wrote:
> > I'm running Debian Stretch with MATE desktop.
> > I want the current user and all future users to include all directories in
> > root's $PATH.
> > 
> > I haven't found a definitive answer in my web search. The answer's seem to
> > depend on which Linux is used and multiple parameters.
> > 
> As with most things in Linux and Unix, it depends.
> 
> Some likely candidates are /etc/bash.bashrc, /etc/profile,
> /etc/profile.d/, and /etc/environment.

More background: processes inherit their environment from their
parent process, and so on.

Since most of your (user) environment doesn't make sense for
system daemons (what is Apache to do with LS_COLORS? But also
arguably PATH shouldn't be there, or should, at least, be
ignored), there are "checkpoints" at which the (user) environment
can be set.

Traditionally that happens at login (/etc/profile, ~/.profile
and all their shell-specific variations -- sometimes you want
slightly different environments for different shells).

But X. When X came up, a similar mechanism was introduced, to
let programs started directly from X also have nice environments:
That is where Xsession (of which there are system-wide scripts
in (Debian, at least) /etc/X11/Xsession, typically broken up
in task-specific snippets in /etc/X11/Xsession.d -- and user-specific
scripts in e.g. ~/.Xsession (or its older sibling ~/.Xsessionrc)).

See "man Xsession" and the scripts in /etc/X11/Xsession* -- they
are shell scripts and might inspire you.

With the advent of desktop environments things have become
a bit more complex, but I'm the wrong person for that: I just
fled the DE craze ten years ago.

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#205130

On 02/08/2019 07:37 AM, tomas@tuxteam.de wrote:
> On Fri, Feb 08, 2019 at 08:22:54AM -0500, Roberto C. Sánchez wrote:
>> On Fri, Feb 08, 2019 at 07:18:39AM -0600, Richard Owlett wrote:
>>> I'm running Debian Stretch with MATE desktop.
>>> I want the current user and all future users to include all directories in
>>> root's $PATH.
>>>
>>> I haven't found a definitive answer in my web search. The answer's seem to
>>> depend on which Linux is used and multiple parameters.
>>>
>> As with most things in Linux and Unix, it depends.
>>
>> Some likely candidates are /etc/bash.bashrc, /etc/profile,
>> /etc/profile.d/, and /etc/environment.
> 
> More background: processes inherit their environment from their
> parent process, and so on.
> 
> [snip] there are "checkpoints" at which the (user) environment
> can be set.
> 
> Traditionally that happens at login (/etc/profile,

Edited that to *NO* effect.

> ~/.profile

By my problem definition, any thing in /home/user is not relevant as I 
explicitly want something that affects all current and future users.


> and all their shell-specific variations -- sometimes you want
> slightly different environments for different shells).
> 
> But X. When X came up, a similar mechanism was introduced, to
> let programs started directly from X also have nice environments:
> That is where Xsession (of which there are system-wide scripts
> in (Debian, at least) /etc/X11/Xsession, typically broken up
> in task-specific snippets in /etc/X11/Xsession.d -- and user-specific
> scripts in e.g. ~/.Xsession (or its older sibling ~/.Xsessionrc)).
> 
> See "man Xsession" and the scripts in /etc/X11/Xsession* -- they
> are shell scripts and might inspire you.

No mention of path there.

> 
> With the advent of desktop environments things have become
> a bit more complex, but I'm the wrong person for that: I just
> fled the DE craze ten years ago.
> 
> Cheers
> -- tomás
> 

[toc] | [prev] | [next] | [standalone]

#205131

Richard Owlett wrote: 
> By my problem definition, any thing in /home/user is not relevant as I
> explicitly want something that affects all current and future users.

Everybody, no matter what?

pam_env can do that.

PAM is the pluggable authentication module system, and controls
all sorts of logins.

man pam_env  for instructions.

-dsr-

[toc] | [prev] | [next] | [standalone]

#205188

On Fri 08 Feb 2019 at 10:08:49 (-0500), Dan Ritter wrote:
> Richard Owlett wrote: 
> > By my problem definition, any thing in /home/user is not relevant as I
> > explicitly want something that affects all current and future users.
> 
> Everybody, no matter what?
> 
> pam_env can do that.
> 
> PAM is the pluggable authentication module system, and controls
> all sorts of logins.
> 
> man pam_env  for instructions.

Good point. And I notice that /etc/pam.d/lightdm talks about

    # Load environment from /etc/environment and ~/.pam_environment
    session      required pam_env.so readenv=1
    session      required pam_env.so readenv=1 envfile=/etc/default/locale

so experimenting with those files might be an idea.

BTW I notice that /etc/security/pam_env.conf contains a line that can
*set* the PATH, but only contains "PATH", not "PATH=". So I'm afraid
the OP should be searching /etc for USER rather than USER=, even
though this will output a lot more noise.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205192

[Multipart message — attachments visible in raw view] — view raw

On Sun, Feb 10, 2019 at 09:07:13PM -0600, David Wright wrote:
> On Fri 08 Feb 2019 at 10:08:49 (-0500), Dan Ritter wrote:
> > Richard Owlett wrote: 
> > > By my problem definition, any thing in /home/user is not relevant as I
> > > explicitly want something that affects all current and future users.
> > 
> > Everybody, no matter what?
> > 
> > pam_env can do that.
> > 
> > PAM is the pluggable authentication module system, and controls
> > all sorts of logins.
> > 
> > man pam_env  for instructions.
> 
> Good point. And I notice that /etc/pam.d/lightdm talks about
> 
>     # Load environment from /etc/environment and ~/.pam_environment
>     session      required pam_env.so readenv=1
>     session      required pam_env.so readenv=1 envfile=/etc/default/locale
> 
> so experimenting with those files might be an idea.
> 
> BTW I notice that /etc/security/pam_env.conf contains a line that can
> *set* the PATH, but only contains "PATH", not "PATH=". So I'm afraid
> the OP should be searching /etc for USER rather than USER=, even
> though this will output a lot more noise.

As already stated, PAM is an interesting alternative to the X11 path
pursued in another fork of this thread: interesting mainly because
it applies /also/ to other access --um-- paths to the computer (Linux
console, ssh, (ugh!) telnet -- basically everything which eventually
asks PAM for access permission).

It is thus more "universal" than the X11 --um-- path.

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#205195

On Monday, February 11, 2019 03:57:14 AM tomas@tuxteam.de wrote:
> On Sun, Feb 10, 2019 at 09:07:13PM -0600, David Wright wrote:
> > On Fri 08 Feb 2019 at 10:08:49 (-0500), Dan Ritter wrote:
> > > Richard Owlett wrote:
> > > > By my problem definition, any thing in /home/user is not relevant as
> > > > I explicitly want something that affects all current and future
> > > > users.
> > > 
> > > Everybody, no matter what?

Well, this is probably OP (off point), but not OT (off topic).

There is a directory /etc/sket (with all hidden files thus you need something 
like ls /etc/skel/.* to get a listing).

AIUI, these files are used, when a new user is created, to create the initial 
instance of those files for the new user.  It includes files like bashrc (and 
lots of others).

Maybe that will be of some help for future users.

[toc] | [prev] | [next] | [standalone]

#205197

On 2019-02-11, rhkramer@gmail.com <rhkramer@gmail.com> wrote:
> On Monday, February 11, 2019 03:57:14 AM tomas@tuxteam.de wrote:
>> On Sun, Feb 10, 2019 at 09:07:13PM -0600, David Wright wrote:
>> > On Fri 08 Feb 2019 at 10:08:49 (-0500), Dan Ritter wrote:
>> > > Richard Owlett wrote:
>> > > > By my problem definition, any thing in /home/user is not relevant as
>> > > > I explicitly want something that affects all current and future
>> > > > users.
>> > > 
>> > > Everybody, no matter what?
>
> Well, this is probably OP (off point), but not OT (off topic).
>
> There is a directory /etc/sket (with all hidden files thus you need something 
> like ls /etc/skel/.* to get a listing).

I believe you need something like 'ls -a /etc/skel/', in fact, to see those pesky dot
files.

Your command, actually, have you tried it? It produces results that are
different from what you expected, I think.

> AIUI, these files are used, when a new user is created, to create the initial 
> instance of those files for the new user.  It includes files like bashrc (and 
> lots of others).
>
> Maybe that will be of some help for future users.
>
>


-- 

When you have fever you are heavy and light, you are small and swollen, you
climb endlessly a ladder which turns like a wheel. 
Jean Rhys, Voyage in the Dark

[toc] | [prev] | [next] | [standalone]

#205202

On Monday, February 11, 2019 08:07:24 AM Curt wrote:
> On 2019-02-11, rhkramer@gmail.com <rhkramer@gmail.com> wrote:
> > There is a directory /etc/sket (with all hidden files thus you need
> > something like ls /etc/skel/.* to get a listing).
> 
> I believe you need something like 'ls -a /etc/skel/', in fact, to see those
> pesky dot files.

You're right.

> Your command, actually, have you tried it? 

Of course, for a command that simple, I almost always try it, and I got plenty 
of results that, at first glance, seemed plausible, but looking back, they were 
wrong.

> It produces results that are
> different from what you expected, I think.

[toc] | [prev] | [next] | [standalone]

#205203

On 2019-02-11, rhkramer@gmail.com <rhkramer@gmail.com> wrote:
> On Monday, February 11, 2019 08:07:24 AM Curt wrote:
>> On 2019-02-11, rhkramer@gmail.com <rhkramer@gmail.com> wrote:
>> > There is a directory /etc/sket (with all hidden files thus you need
>> > something like ls /etc/skel/.* to get a listing).
>> 
>> I believe you need something like 'ls -a /etc/skel/', in fact, to see those
>> pesky dot files.
>
> You're right.

I'm wrong because your command does output the dot files, as a matter of
fact (and so much more I didn't bother scrolling up to notice that it
did indeed show those hidden files).

I follow your logic. Give me everything in /etc/skel/ beginning with a dot.
Which works. But apparently a dot is also something else. Like a directory.

curty@einstein:~$ ls /etc/skel/.*
/etc/skel/.bash_logout  /etc/skel/.bashrc  /etc/skel/.profile

/etc/skel/.:

/etc/skel/..:

(etc.--the contents of /etc/

I'm not sure what it all means.

>> Your command, actually, have you tried it? 
>
> Of course, for a command that simple, I almost always try it, and I got plenty 
> of results that, at first glance, seemed plausible, but looking back, they were 
> wrong.
>
>> It produces results that are
>> different from what you expected, I think.
>
>

[toc] | [prev] | [next] | [standalone]

#205204

On Mon, Feb 11, 2019 at 05:26:34PM -0000, Curt wrote:
> I follow your logic. Give me everything in /etc/skel/ beginning with a dot.
> Which works. But apparently a dot is also something else. Like a directory.
> 
> curty@einstein:~$ ls /etc/skel/.*
> /etc/skel/.bash_logout  /etc/skel/.bashrc  /etc/skel/.profile
> 
> /etc/skel/.:
> 
> /etc/skel/..:
> 
> (etc.--the contents of /etc/
> 
> I'm not sure what it all means.

The shell glob .* expands to everything in the current directory that
begins with a dot.  Which includes "." and "..".

"." is the current directory.  ".." is the parent directory.  E.g. when
you type "cd .." it moves you "up" to the parent directory.

Asking ls to show you .* is usually a bad idea, precisely because it
expands to a list which includes . and .. and does exactly what you
just described.

This is why the ls command has -a and -A options.

[toc] | [prev] | [next] | [standalone]

#205205

On 2019-02-11, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Mon, Feb 11, 2019 at 05:26:34PM -0000, Curt wrote:
>> I follow your logic. Give me everything in /etc/skel/ beginning with a dot.
>> Which works. But apparently a dot is also something else. Like a directory.
>> 
>> curty@einstein:~$ ls /etc/skel/.*
>> /etc/skel/.bash_logout  /etc/skel/.bashrc  /etc/skel/.profile
>> 
>> /etc/skel/.:
>> 
>> /etc/skel/..:
>> 
>> (etc.--the contents of /etc/
>> 
>> I'm not sure what it all means.
>
> The shell glob .* expands to everything in the current directory that
> begins with a dot.  Which includes "." and "..".
>
> "." is the current directory.  ".." is the parent directory.  E.g. when
> you type "cd .." it moves you "up" to the parent directory.
>
> Asking ls to show you .* is usually a bad idea, precisely because it
> expands to a list which includes . and .. and does exactly what you
> just described.
>
> This is why the ls command has -a and -A options.
>
>

Thank you. That all makes perfect sense.

[toc] | [prev] | [next] | [standalone]

#205211

On Mon 11 Feb 2019 at 17:48:23 (-0000), Curt wrote:
> On 2019-02-11, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> > On Mon, Feb 11, 2019 at 05:26:34PM -0000, Curt wrote:
> >> I follow your logic. Give me everything in /etc/skel/ beginning with a dot.
> >> Which works. But apparently a dot is also something else. Like a directory.
> >> 
> >> curty@einstein:~$ ls /etc/skel/.*
> >> /etc/skel/.bash_logout  /etc/skel/.bashrc  /etc/skel/.profile
> >> 
> >> /etc/skel/.:
> >> 
> >> /etc/skel/..:
> >> 
> >> (etc.--the contents of /etc/
> >> 
> >> I'm not sure what it all means.
> >
> > The shell glob .* expands to everything in the current directory that
> > begins with a dot.  Which includes "." and "..".
> >
> > "." is the current directory.  ".." is the parent directory.  E.g. when
> > you type "cd .." it moves you "up" to the parent directory.
> >
> > Asking ls to show you .* is usually a bad idea, precisely because it
> > expands to a list which includes . and .. and does exactly what you
> > just described.
> >
> > This is why the ls command has -a and -A options.
> 
> Thank you. That all makes perfect sense.

If you want just the dotfiles, then    ls -dF  .[^.]*
might be helpful. You don't need the -dF, but -d will prevent
it listing any .dotdirectories (important in your $HOME) and
-F will reveal those directories (when you're not using -l)
and other non-regular-files.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205133

[Multipart message — attachments visible in raw view] — view raw

On Fri, Feb 08, 2019 at 08:58:28AM -0600, Richard Owlett wrote:
> On 02/08/2019 07:37 AM, tomas@tuxteam.de wrote:
> >More background: processes inherit their environment from their

> >parent process, and so on.
> >
> >[snip] there are "checkpoints" at which the (user) environment
> >can be set.
> >
> >Traditionally that happens at login (/etc/profile,
> 
> Edited that to *NO* effect.

I said "traditionally": there your primary "login" is a shell.
For X and graphical environments, it's another story.

> >~/.profile
> 
> By my problem definition, any thing in /home/user is not relevant as
> I explicitly want something that affects all current and future
> users.

Right -- I mentioned that for completeness, since this is a recurring
pattern: a system-wide config which can be overridden per user.

> >But X. When X came up [...]

> >See "man Xsession" and the scripts in /etc/X11/Xsession* -- they
> >are shell scripts and might inspire you.
> 
> No mention of path there.

No need: those are shell snippeds sourced by the X session shell,
which will be the mother of all your X processes -- and PATH is
part of their inherited environment. Setting PATH there will be
inherited by those.

But see Dan's other take -- pam will set things (among others
the PATH for any authentication which goes via PAM (i.e. the
display manager, where you log into X, a shell in a console,
or even an ssh from another box).

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#205139

On Fri 08 Feb 2019 at 07:18:39 (-0600), Richard Owlett wrote:
> I'm running Debian Stretch with MATE desktop.
> I want the current user and all future users to include all
> directories in root's $PATH.

If you're talking about PATH, then you're talking about logging in.
So of equal importance to the DE you're using is the DM, and I'll
guess that's likely lightdm. Was that amongst your search terms?

> I haven't found a definitive answer in my web search. The answers
> seem to depend on which Linux is used and multiple parameters.

Yes, as are so many other details of configuration.

If searching outwards gets you no further, then perhaps turn your
attention inwards. For example,   grep -r PATH /etc   or, a little
less noisy,   grep -r PATH= /etc   will reveal some candidates
(plus lots of false positives, which the filenames will make obvious).

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#205173

On 02/08/2019 12:55 PM, David Wright wrote:
> On Fri 08 Feb 2019 at 07:18:39 (-0600), Richard Owlett wrote:
>> I'm running Debian Stretch with MATE desktop.
>> I want the current user and all future users to include all
>> directories in root's $PATH.
> 
> If you're talking about PATH, then you're talking about logging in.
> So of equal importance to the DE you're using is the DM, and I'll
> guess that's likely lightdm. Was that amongst your search terms? >
>> I haven't found a definitive answer in my web search. The answers
>> seem to depend on which Linux is used and multiple parameters.
> 
> Yes, as are so many other details of configuration.
> 
> If searching outwards gets you no further, then perhaps turn your
> attention inwards. For example,   grep -r PATH /etc   or, a little
> less noisy,   grep -r PATH= /etc   will reveal some candidates
> (plus lots of false positives, which the filenames will make obvious).

I used "grep -r /usr/local/games /etc" which yielded "/etc/login.defs" 
and "/etc/profile". Editing those two files had no effect.

I did a new search including "lightdm" as one term.
I got multiple hits - [none seemed authoritative].

I did get one hit which hints I may not get what I want.

A thread discussing a quite different situation says in part:
> The basic problem is that lightdm in Debian hard-codes the path 
>   https://launchpadlibrarian.net/94971962/01_set-default-path.patch
	[https://lists.debian.org/debian-user/2014/04/msg00006.html]
Although the link is to a Ubuntu bug report, not Debian, the code shown 
is consistent with my observations.

Unless someone can point to a single location to modify that:
   1. modify existing user(s)
   2. have effect for ALL future users
   3. survive updating to future releases
I'll drop the issue.
Thanks all.







> 
> Cheers,
> David.
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#205175

Hello,

On Sun, Feb 10, 2019 at 02:57:22PM -0600, Richard Owlett wrote:
> I used "grep -r /usr/local/games /etc" which yielded "/etc/login.defs" and
> "/etc/profile". Editing those two files had no effect.

How are you determining that changes to /etc/profile had no effect?
Because changes there (or in files in /etc/profile.d/) should affect all
new shels that you launch. Example:

$ cat /etc/profile.d/extrapath.sh
export PATH=$PATH:/foo

Then I open a new shell and echo $PATH, /foo is in there.

If that is not your experience, you are doing something wrong, or your
system is very broken.

So what changes are you making and how are you checking for them?

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#205177

On 02/10/2019 03:26 PM, Andy Smith wrote:
> Hello,
> 
> On Sun, Feb 10, 2019 at 02:57:22PM -0600, Richard Owlett wrote:
>> I used "grep -r /usr/local/games /etc" which yielded "/etc/login.defs" and
>> "/etc/profile". Editing those two files had no effect.
> 
> How are you determining that changes to /etc/profile had no effect?

Being of the vacuum tube, 026, KSR35 era <grin;>
I did a brute force reboot [i.e. power off; wait; power on]

> Because changes there (or in files in /etc/profile.d/) should affect all
> new shels that you launch. Example:
> 
> $ cat /etc/profile.d/extrapath.sh
> export PATH=$PATH:/foo
> 
> Then I open a new shell and echo $PATH, /foo is in there.
> 
> If that is not your experience, you are doing something wrong, or your
> system is very broken.

Depends on your definition of broken ;/
The links you snipped suggest lightdm could be defined as broken.

> 
> So what changes are you making and how are you checking for them?
> 
> Cheers,
> Andy
> 

[toc] | [prev] | [next] | [standalone]

#205181

On Sun, Feb 10, 2019 at 03:49:00PM -0600, Richard Owlett wrote:
> On 02/10/2019 03:26 PM, Andy Smith wrote:
> >So what changes are you making and how are you checking for them?

I note you have neglected to explain what changes you are making, which
would be essential for us to help you with why the changes are seemingly
not taking effect. As such this seems like yet another endless Owlett
thread where assistance is not actually desired, and so I'm out. Good
luck to you and any who take on the task.

Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web