Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[Steve Litt]

Didier Kryn said on Tue, 16 Nov 2021 14:36:23 +0100

  
>    Yes, very active and with pretty constructive exchanges and
>collaboration with Glibc. I'm on the mailing list. See
>http://musl.libc.org 

LOL, from what I hear, a musl compiled Linux will not work with
systemd. Oh wait, Devuan doesn't have systemd.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lpr command not working

[Ralph Ronnquist via Dng]

On Wed, 17 Nov 2021 06:51:39 +1100
Ralph Ronnquist  wrote:

> On Tue, 16 Nov 2021 08:03:21 -0500
> Haines Brown  wrote:
> 
> > On Tue, Nov 16, 2021 at 12:28:57PM +1100, Ralph Ronnquist via Dng
> > wrote:
> > > On Mon, 15 Nov 2021 19:21:15 -0500
> > > Haines Brown  wrote:  
> > > > These problems I'll pursue, but my pont is that none of the ways
> > > > to get access to the lpr command are workig.  
> > > 
> > > 
> > > use: $ lpstat -d -v -p
> > > to list which the default printer is and which printers there are
> > >  
> > 
> >   $ lpstat -d -v  -p
> >   no system default destination
> >   lpstat: Bad file descriptor
> >   lpstat: Bad file descriptor
> > 
> > > use: # lpadmin -d "$queue"
> > > to set $queue as the default for cups and lpr  
> > 
> > I'm unsure whether you are telling me now to set the queue for CUPS 
> > or if I need to set it to "queue". 
> > 
> > I do # /etc/cups/diff -y cupsd.conf cupsd.conf.O | less .
> > I discover that is it cups.conf. not cups.conf.
> > So "O" means Original?
> > 
> > My current cupsd.conf has line Port 631 vs. Listen localhost:631
> > 
> > My current location is 
> > 
> > 
> > # Allow shared printing... 
> > Order allow,deny   
> > Allow @LOCAL   
> > 
> > 
> > the file cupsd.conf.O has 
> > 
> >   
> >   # Restrict access to the server...
> > Order allow,deny
> >   
> > 
> > One thing I could is to backup /etc/cups/cupsd.conf and replace
> > it with cupsd.conf.O and reinstall the printer. Would you suggest
> > doing this? 
> >  
> > > (using cups-lpr)  
> > 
> > what does this mean?
> 
> Sorry, I was a bit short...
> 
> That command, "lpadmin -d $queue", is documented as the one to be used
> for telling CUPS and lpr (from cups-lpr) which printer to use as
> default printer; the $queue bit is "the printer queue name" or "the
> user's printer name" and e.g. not it's connection detail (unless they
> happen to coincide).
> 
> The resulting "conf" change seems to be the inclusion of the line
> with "" (where again $queue is the printer
> queue name, which also is the file name for the ppd of the printer),
> together with a subsequent "". That same XML
> "object" appears in both /etc/cups/printers.conf and
> /etc/cups/printers.conf.O, and that's about the limit of what I know
> about those files.
> 
> In my simpleton approach to printing, I usually use the GUI of
> "system-config-printer" to administrate via its required combinations
> of mousing and keyboarding, and in fact I print so seldom that I
> hadn't even installed an lpr program before. So my short note merely
> reflected what I just had learnt from the man pages while attempting
> to print a small text file with lpr, and discovering that my
> defaulted default printer "PDF" was not what I wanted as default.

... actually the "DefaultPrinter" object has a lot of more stuff in it,
and is apparently just a rebadging of one of the pre-existing "" objects.

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

Re: [DNG] lpr command not working

[Ralph Ronnquist via Dng]

On Tue, 16 Nov 2021 08:03:21 -0500
Haines Brown  wrote:

> On Tue, Nov 16, 2021 at 12:28:57PM +1100, Ralph Ronnquist via Dng
> wrote:
> > On Mon, 15 Nov 2021 19:21:15 -0500
> > Haines Brown  wrote:  
> > > These problems I'll pursue, but my pont is that none of the ways
> > > to get access to the lpr command are workig.  
> > 
> > 
> > use: $ lpstat -d -v -p
> > to list which the default printer is and which printers there are  
> 
>   $ lpstat -d -v  -p
>   no system default destination
>   lpstat: Bad file descriptor
>   lpstat: Bad file descriptor
> 
> > use: # lpadmin -d "$queue"
> > to set $queue as the default for cups and lpr  
> 
> I'm unsure whether you are telling me now to set the queue for CUPS 
> or if I need to set it to "queue". 
> 
> I do # /etc/cups/diff -y cupsd.conf cupsd.conf.O | less .
> I discover that is it cups.conf. not cups.conf.
> So "O" means Original?
> 
> My current cupsd.conf has line Port 631 vs. Listen localhost:631
> 
> My current location is 
> 
> 
> # Allow shared printing... 
> Order allow,deny   
> Allow @LOCAL   
> 
> 
> the file cupsd.conf.O has 
> 
>   
>   # Restrict access to the server...
> Order allow,deny
>   
> 
> One thing I could is to backup /etc/cups/cupsd.conf and replace
> it with cupsd.conf.O and reinstall the printer. Would you suggest
> doing this? 
>  
> > (using cups-lpr)  
> 
> what does this mean?

Sorry, I was a bit short...

That command, "lpadmin -d $queue", is documented as the one to be used
for telling CUPS and lpr (from cups-lpr) which printer to use as default
printer; the $queue bit is "the printer queue name" or "the user's
printer name" and e.g. not it's connection detail (unless they happen
to coincide).

The resulting "conf" change seems to be the inclusion of the line
with "" (where again $queue is the printer queue
name, which also is the file name for the ppd of the printer), together
with a subsequent "". That same XML "object" appears
in both /etc/cups/printers.conf and /etc/cups/printers.conf.O, and
that's about the limit of what I know about those files.

In my simpleton approach to printing, I usually use the GUI of
"system-config-printer" to administrate via its required combinations
of mousing and keyboarding, and in fact I print so seldom that I hadn't
even installed an lpr program before. So my short note merely reflected
what I just had learnt from the man pages while attempting to print a
small text file with lpr, and discovering that my defaulted default
printer "PDF" was not what I wanted as default.

regards,

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

Re: [DNG] Devuan with usr merge?

[Hendrik Boom]

On Tue, Nov 16, 2021 at 07:42:18PM +0100, al3xu5 via Dng wrote:
> 
> My suspected is that the (totally unecessary) usr-merge decision made by
> Debian will force (almost) all its derivatives to adapt even if they
> despite. 
> 
> This is because maintaining a derived distribution rejecting usr-merge
> would become too complex and onerous...

Possibly as difficult as changing the entire OS *to* usr-merge.

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

Re: [DNG] Devuan with usr merge?

[al3xu5 via Dng]

Sat, 13 Nov 2021 17:24:51 -0500 - Steve Litt :

> k...@aspodata.se said on Sat, 13 Nov 2021 22:28:02 +0100 (CET)
> 
> >James Cloos:  
> >> > John Morris via Dng  writes:
> >> > So yes, it is time to eliminate /bin, /sbin and /lib.
> >> the real result shod be eliminate /usr.
> >
> >Guys, please don't push unnessary changes and policies
> >to the user. Let each and everyone be the master of his/her
> >own systems.  
> 
> Ex-actly!
> 
> >
> >Just because debian wants to go that route doesn't mean 
> >it has to be engraved as a policy for devuan.  
> 
> If it's possible to diverge from Debian's usr merge with Devuan's given
> (wo)manpower, I agree. 

I totally agree.

> Starting somewhere in the 00's, Debian started
> making a lot of bad decisions. 

Indeed. 

> By the way, for the person who really wants the usr merge, wouldn't the
> conversion from an unmerged system consist of two mass copies and a few
> symlinks?
> 
> SteveT

Unfortunately things seem to be rather more complex, as some people have
pointed out in this discussion:

Sat, 13 Nov 2021 23:29:16 +0100 - Martin Steigerwald :

> Steve Litt - 13.11.21, 23:24:51 CET:
> > By the way, for the person who really wants the usr merge, wouldn't
> > the conversion from an unmerged system consist of two mass copies and
> > a few symlinks?  
> 
> No.
> 
> At least not if you like dpkg to be working fine. As I noted before, see:
> 
> https://wiki.debian.org/Teams/Dpkg/MergedUsr


My suspected is that the (totally unecessary) usr-merge decision made by
Debian will force (almost) all its derivatives to adapt even if they
despite. 

This is because maintaining a derived distribution rejecting usr-merge
would become too complex and onerous...

Best regards
al3xu5

-- 
Say NO to copyright, patents, trademarks and industrial design
restrictions!


Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8  B624 DA50 835B 2624 A36B


pgppt2vdPgowm.pgp
Description: Firma digitale OpenPGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Globbing rsync != tar ?

[Ken Dibble]

In my never ending quest to cause myself headaches, I have been 
experimenting with

different backup methods.

What I am seeing is as follows:
rsync using a .gitignore file and tar using a the same.gitignore file 
have different opinions

about globbing.

Here are the commands for reference

rsync -a -r -t -p -o -g -s --exclude-from=.gitignore /home/kdibble 
/tmp/backup_test


tar --exclude-vcs-ignores -c /home/kdibble > /tmp/kdibble.tar



According to gnu.org tar 1.34 section 6.4

‘--exclude-vcs-ignores’

    Before archiving a directory, see if it contains any of the 
following files: ‘cvsignore’, ‘.gitignore’, ‘.bzrignore’, or 
‘.hgignore’. If so, read ignore patterns from these files.


    The patterns are treated much as the corresponding VCS would treat 
them, i.e.:



‘.gitignore’

    Contains shell-style globbing patterns. Applies to the directory 
where ‘.gitfile’ is located         and all its subdirectories.


    Any line beginning with a ‘#’ is a comment. Backslash escapes the 
comment character.




here is /home/kdibble/.gitignore

#.gitignore for home directory
#
.*
Downloads/
vmware/
#
bin/checkhosts/etc_hosts
bin/checkhosts/hosts
!/.gitignore
**/core
**/*.o
**/*.d
**/*.class
**/a.out
**/binary_data
**/perf_data
**/quotient.txt

After rsync:
  $ ls /tmp/backup_test | grep binary_data
  $
  $ ls /tmp/backup_test | grep "o.d"
  $

After tar:
  $ tar tf /tmp/kdibble.tar | grep binary_data
   home/kdibble/NetBeansProjects/factor/binary_data

  $ tar tf /tmp/kdibble.tar | grep "o.d"
home/kdibble/NetBeansProjects/Pell/build/Debug/GNU-Linux-x86/main.o.d
home/kdibble/NetBeansProjects/PollardRho/build/Debug/GNU-Linux/main.o.d
home/kdibble/NetBeansProjects/PollardRho/build/Debug/GNU-Linux-x86/main.o.d

   I understand that the documentation says "much as the corresponding 
VCS would treat them"


   but,

   IMHO,

   IF they are not going to work the same, don't make it sound as 
though they do work
   the same or name the command line switch like they do. Especially on 
utilities used
   for backing up data, where there is an expectation of being able to 
restore what

   you intended to back up.

   For reference the '**' glob was apparently introduced with Bash 4 in 
2009,

   so it isn't something new.

   Then again, maybe I am missing something

   Hoping to be enlightened,

   Ken

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

Re: [DNG] Chimaera Oddities

[Ken Dibble]

On 11/9/21 7:21 PM, Ken Dibble wrote:

On 10/28/21 12:36 PM, Ken Dibble wrote:

A couple of oddities.


The uas driver does not like the JMicron Sata/USB 3 bridge.

Bus 004 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron 
USA Technology Corp. JMS567 SATA 6Gb/s bridge



I updated to the 5.14 kernel from backports and the craziness with the 
disk being unreadable


and not recognizing formats seems to have stopped.


The I/O rate is horrible (35MB/s) with the JMicron Bridge and a 2.5 
velociraptor which WD says gets


up to 200MB/s sustained , although I have have only seen in the 140s.


I have a Weme bridge ordered which claims to be linux compatible, 
should be here next week.



We'll see what happens.



The Weme  bridge arrived.  Linux compatible?  Well, the ASM chip in it 
is listed in the kernel's built in blacklist.  So, I would say no, but 
it seems to work without the uas driver.


The underlying cause seems to be my USB 3 cards themselves.  They use a 
Renasas uPD720200 chip, which I have been unable to update the firmware 
through Linux, Dos, or Windows.


Unfortunately both of the machines in question had this card installed.

I did however find a USB 3 card with a Renasas uPD720202 chip in my pile 
of expansion cards and both bridges appear to work even if on the kernel 
blacklist.


So all of this stuff goes in the 'iffy' pile of hardware.  I am not 
willing to trust it or a manufacturer whose definition of compatible is 
that the computer doesn't go up in flames when used.  Tape is slow, but 
my hardware has never complained about working the midnight shift and 
tape has always been reliable for me.



Ken


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

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[onefang]

On 2021-11-16 14:36:23, Didier Kryn wrote:
> Le 16/11/2021 à 14:31, Dr. Nikolaus Klepp via Dng a écrit :
> > Anno domini 2021 Tue, 16 Nov 14:19:59 +0100
> >  Didier Kryn scripsit:
> >> Le 16/11/2021 à 12:15, onefang a écrit :
> >>> http://landley.net/aboriginal/about.html is what I used for my last
> >>> embedded Linux project.
> >>>
> >>> "Aboriginal Linux is a shell script that builds the smallest/simplest
> >>> linux system capable of rebuilding itself from source code. This
> >>> currently requires seven packages: linux, busybox, uClibc, binutils, gcc,
> >>> make, and bash."
> >>     Aboriginal is nice and Rob Landley is doing a great job. But are you
> >> sure about uClibc. I thought Aboriginal had switched to Musl years ago.
> >> uClibc is pretty far from POSIX compliance, and also from Glibc, which
> >> would make the system difficult to use as a build platform, although
> >> otherwise functional, of course. AFAIR, Rob Landley is developping his
> >> binutils mostly because of a disagreement with Busybox license.
> > Is it still under devlopment? The archives end 2016.
> >
>     Yes, very active and with pretty constructive exchanges and
> collaboration with Glibc. I'm on the mailing list. See
> http://musl.libc.org 

Think you are talking about two different things there.  Again quoting
from the website http://landley.net/aboriginal/news.html -

"April 30, 2017

-- End of Line --

Development of Aboriginal Linux has ended, replaced by mkroot."

He has much more to say on that topic, I suggest reading it.  Ah, he does
indeed comment on the license change of busybox in that.

My use of Aboriginal Linux predated that, so I can't comment on the
mkroot replacement.

BTW I did contribute to Aboriginal Linux, the x486 support was my work,
coz the embedded device I was using it for uses an x486 clone CPU.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[onefang]

On 2021-11-16 14:19:59, Didier Kryn wrote:
> Le 16/11/2021 à 12:15, onefang a écrit :
> > http://landley.net/aboriginal/about.html is what I used for my last
> > embedded Linux project.
> >
> > "Aboriginal Linux is a shell script that builds the smallest/simplest
> > linux system capable of rebuilding itself from source code. This
> > currently requires seven packages: linux, busybox, uClibc, binutils, gcc,
> > make, and bash."
> 
>     Aboriginal is nice and Rob Landley is doing a great job. But are you
> sure about uClibc. I thought Aboriginal had switched to Musl years ago.

That bit in quotes was copy pasted directly from the web site, which is
why I wrapped it in quotes.

> uClibc is pretty far from POSIX compliance, and also from Glibc, which
> would make the system difficult to use as a build platform, although
> otherwise functional, of course. AFAIR, Rob Landley is developping his
> binutils mostly because of a disagreement with Busybox license.

Toybox is Rob's version of the busybox thing, and Rob used to be the main
busybox maintainer.  You should read his web site for more details.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[Didier Kryn]

Le 16/11/2021 à 14:31, Dr. Nikolaus Klepp via Dng a écrit :
> Anno domini 2021 Tue, 16 Nov 14:19:59 +0100
>  Didier Kryn scripsit:
>> Le 16/11/2021 à 12:15, onefang a écrit :
>>> http://landley.net/aboriginal/about.html is what I used for my last
>>> embedded Linux project.
>>>
>>> "Aboriginal Linux is a shell script that builds the smallest/simplest
>>> linux system capable of rebuilding itself from source code. This
>>> currently requires seven packages: linux, busybox, uClibc, binutils, gcc,
>>> make, and bash."
>>     Aboriginal is nice and Rob Landley is doing a great job. But are you
>> sure about uClibc. I thought Aboriginal had switched to Musl years ago.
>> uClibc is pretty far from POSIX compliance, and also from Glibc, which
>> would make the system difficult to use as a build platform, although
>> otherwise functional, of course. AFAIR, Rob Landley is developping his
>> binutils mostly because of a disagreement with Busybox license.
> Is it still under devlopment? The archives end 2016.
>
    Yes, very active and with pretty constructive exchanges and
collaboration with Glibc. I'm on the mailing list. See
http://musl.libc.org 



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

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[Dr. Nikolaus Klepp via Dng]

Anno domini 2021 Tue, 16 Nov 14:19:59 +0100
 Didier Kryn scripsit:
> Le 16/11/2021 à 12:15, onefang a écrit :
> > http://landley.net/aboriginal/about.html is what I used for my last
> > embedded Linux project.
> >
> > "Aboriginal Linux is a shell script that builds the smallest/simplest
> > linux system capable of rebuilding itself from source code. This
> > currently requires seven packages: linux, busybox, uClibc, binutils, gcc,
> > make, and bash."
> 
>     Aboriginal is nice and Rob Landley is doing a great job. But are you
> sure about uClibc. I thought Aboriginal had switched to Musl years ago.
> uClibc is pretty far from POSIX compliance, and also from Glibc, which
> would make the system difficult to use as a build platform, although
> otherwise functional, of course. AFAIR, Rob Landley is developping his
> binutils mostly because of a disagreement with Busybox license.

Is it still under devlopment? The archives end 2016.

I like to use "buildroot" for my embedded systems.

Nik

> 
>     Here's a comparison of C libraries (by Rich felker, the author of
> musl). Unfortunately it is dated from 2014. Since that time, all
> librares should have made progress.
> http://www.etalabs.net/compare_libcs.html
> 
> 
> --     Didier
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] lpr command not working

[Dr. Nikolaus Klepp via Dng]

Anno domini 2021 Tue, 16 Nov 08:03:21 -0500
 Haines Brown scripsit:
> On Tue, Nov 16, 2021 at 12:28:57PM +1100, Ralph Ronnquist via Dng wrote:
> > On Mon, 15 Nov 2021 19:21:15 -0500
> > Haines Brown  wrote:
> > > These problems I'll pursue, but my pont is that none of the ways to
> > > get access to the lpr command are workig.
> > 
> > 
> > use: $ lpstat -d -v -p
> > to list which the default printer is and which pringters there are
> 
>   $ lpstat -d -v  -p
>   no system default destination
>   lpstat: Bad file descriptor
>   lpstat: Bad file descriptor
> 
> > use: # lpadmin -d "$queue"
> > to set $queue as the default for cups and lpr
> 
> I'm unsure whether you are telling me now to set the queue for CUPS 
> or if I need to set it to "queue". 
> 
> I do # /etc/cups/diff -y cupsd.conf cupsd.conf.O | less .
> I discover that is it cups.conf. not cups.conf.
> So "O" means Original?
> 
> My current cupsd.conf has line Port 631 vs. Listen localhost:631
> 
> My current location is 
> 
> 
> # Allow shared printing... 
> Order allow,deny   
> Allow @LOCAL   
> 
> 
> the file cupsd.conf.O has 
> 
>   
>   # Restrict access to the server...
> Order allow,deny
>   
> 
> One thing I could is to backup /etc/cups/cupsd.conf and replace
> it with cupsd.conf.O and reinstall the printer. Would you suggest
> doing this? 
>  
> > (using cups-lpr)
> 
> what does this mean?
> 

You need to install "cups-bsd", which has a cups version of "lpr". And you need 
to install "cups", as it "cupsd" is not running.

Nik

-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[Didier Kryn]

Le 16/11/2021 à 12:15, onefang a écrit :
> http://landley.net/aboriginal/about.html is what I used for my last
> embedded Linux project.
>
> "Aboriginal Linux is a shell script that builds the smallest/simplest
> linux system capable of rebuilding itself from source code. This
> currently requires seven packages: linux, busybox, uClibc, binutils, gcc,
> make, and bash."

    Aboriginal is nice and Rob Landley is doing a great job. But are you
sure about uClibc. I thought Aboriginal had switched to Musl years ago.
uClibc is pretty far from POSIX compliance, and also from Glibc, which
would make the system difficult to use as a build platform, although
otherwise functional, of course. AFAIR, Rob Landley is developping his
binutils mostly because of a disagreement with Busybox license.

    Here's a comparison of C libraries (by Rich felker, the author of
musl). Unfortunately it is dated from 2014. Since that time, all
librares should have made progress.
http://www.etalabs.net/compare_libcs.html


--     Didier


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

Re: [DNG] lpr command not working

[Haines Brown]

On Tue, Nov 16, 2021 at 12:28:57PM +1100, Ralph Ronnquist via Dng wrote:
> On Mon, 15 Nov 2021 19:21:15 -0500
> Haines Brown  wrote:
> > These problems I'll pursue, but my pont is that none of the ways to
> > get access to the lpr command are workig.
> 
> 
> use: $ lpstat -d -v -p
> to list which the default printer is and which pringters there are

  $ lpstat -d -v  -p
  no system default destination
  lpstat: Bad file descriptor
  lpstat: Bad file descriptor

> use: # lpadmin -d "$queue"
> to set $queue as the default for cups and lpr

I'm unsure whether you are telling me now to set the queue for CUPS 
or if I need to set it to "queue". 

I do # /etc/cups/diff -y cupsd.conf cupsd.conf.O | less .
I discover that is it cups.conf. not cups.conf.
So "O" means Original?

My current cupsd.conf has line Port 631 vs. Listen localhost:631

My current location is 


# Allow shared printing... 
Order allow,deny   
Allow @LOCAL   


the file cupsd.conf.O has 

  
  # Restrict access to the server...
Order allow,deny
  

One thing I could is to backup /etc/cups/cupsd.conf and replace
it with cupsd.conf.O and reinstall the printer. Would you suggest
doing this? 
 
> (using cups-lpr)

what does this mean?

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

Re: [DNG] lpr command not working

[Tomasz Kundera via Dng]

On Tue, Nov 16, 2021 at 1:07 PM Haines Brown  wrote:

> On Mon, Nov 15, 2021 at 07:56:06PM -0500, Steve Litt wrote:
> > Haines Brown said on Mon, 15 Nov 2021 19:21:15 -0500
> >
> >
> > >My printer lost its status as default, but I can't get to the CUPS
> > >web page to restore it
> >
> > Let me ask you a few probably dumb questions...
> >
> > * Was cupsd running?
> > * Did you go to http://127.0.0.1:631/  ?
> > * When CUPS asked for user and password, did you type root and your
> >   machine's root password?
> > * Did you go to Administration=>Set as default server for the printer
> >   you want to be default?
>
> Yes cupsd is running:
>
>   $ ps -auxw | grep cups
>   haines   28191  0.0  0.0   6560  3416 pts/6S+   05:21   0:00 nano
> cupsd
>   haines   29295  0.0  0.0   6180   664 pts/15   S+   06:51   0:00 grep
> cups
>

There is no running cups on your list. There are only grep and nano. Are
you editing cupsd with nano?
Running cups should show something like  /usr/sbin/cupsd


> On other hand,
>
>   #  cupsd -h
>   -bash: cupsd: command not found
>

So there is no cupsd or your PATH is bad (are you root?).


># service cups start
>
># service cups status
>

Your cups is not running. Should show:
[ ok ] cupsd is running.


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

Re: [DNG] lpr command not working

[Haines Brown]

On Mon, Nov 15, 2021 at 07:56:06PM -0500, Steve Litt wrote:
> Haines Brown said on Mon, 15 Nov 2021 19:21:15 -0500
> 
> 
> >My printer lost its status as default, but I can't get to the CUPS
> >web page to restore it
> 
> Let me ask you a few probably dumb questions...
> 
> * Was cupsd running?
> * Did you go to http://127.0.0.1:631/  ?
> * When CUPS asked for user and password, did you type root and your
>   machine's root password?
> * Did you go to Administration=>Set as default server for the printer
>   you want to be default?

Yes cupsd is running:

  $ ps -auxw | grep cups
  haines   28191  0.0  0.0   6560  3416 pts/6S+   05:21   0:00 nano cupsd
  haines   29295  0.0  0.0   6180   664 pts/15   S+   06:51   0:00 grep cups

On other hand, 

  #  cupsd -h
  -bash: cupsd: command not found

  #  cupsd
  -bash: cupsd: command not found

I initially went to localhost:631. But I find that going to it displays 
the CUPS web page, but I cannot open the Administration tab without 
getting "Unable to Connect". When I try the URI I cannot even connect 
to the Web intefac. This is probably a clue, but I don't know how to 
intepret it.

I supplied root and root's pw when asked. This was several days ago
and until yesterday I used the Web inerface without a problem. 

Can't retrace my steps at this point, but I belive I went to 
Administration amd for my printer and selected it to be default.

It status shows it to be default, but yesterday it mysteriously 
ceased to be default:

  $ lpstat -d
  no system default destination

So I do:

  # lpadmin -d HP_LaserJet_1320_series
  lpadmin: Unable to connect to server: Bad file descriptor

I look at /etc/cups/cupsd.conf and off hand see nothing odd.
For example:

  Port 631
  Listen /run/cups/cups.sock
  Share local printers on the local network.

I suppose an obious thing to would be to purge and reinstall CUPS, 
but I'd rather fix the problem than run around it. On-line discussaions
often presume systemd, which is no help. 

There is no file /etc/cups/client.conf

The file /etc/cups/cupds.conf does not have the line "hostnamelookups" 

It has 

  
# Allow shared printing...
Order allow,deny
Allow @LOCAL
  

  Should it be Order deny.allow ? should I change to Allow from all ?

When I run ~$ nc -zv  631 I get Connection refused

   # service cups start

   # service cups status

  $ lpstat -t
  scheduler is not running
  no system default destination
  lpstat: Bad file descriptor
  lpstat: Bad file descriptor
  lpstat: Bad file descriptor
  lpstat: Bad file descriptor
  lpstat: Bad file descriptor


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

Re: [DNG] Embedded devuan (was Re: Devuan with usr merge?)

[onefang]

On 2021-11-16 11:40:28, k...@aspodata.se wrote:
> Didier Kryn:
> > Le 16/11/2021 à 01:44, Florian Zieboll via Dng a écrit :
> > > On Mon, 15 Nov 2021 21:19:08 +0100
> ...
> > > As I use to do a minimal *.bian install on my SoC hardware, which
> > > I afterwards move to the Devuan repositories, while keeping the
> > > related original "firmware" repository, I must confess that the
> > > whole "embedded"-thing is still somewhat unclear to me, at least
> > > regarding kernel and firmware updates. I'd be more than happy to
> > > get a hint towards an honest introduction to this topic.
> 
> If you are using embedded linux, you probably have an ip-connection to
> the hw and uboot as the fw/bootlooder/bios or what you prefer to call it.
> If you have an ip-connection, you can just ssh to the box and copy it to
> the right place and do whatever is needed.
>  You usually don't update the processor, embedded board or other fw 
> than uboot. If you want to do that you have to check the manufacturer
> documentation.
> 
> ...
> >     I wish to every Linux fan to live this adventure.
> 
>  Ack, here is example manufacturer documentation of the process:
> http://developer.embedian.com/display/LOS/SMARC+T335X
> 
> That hw is similar to the BeagleBoneBlack mentioned by Antoine,
> so if you start off the BBB, this one could be the next in your
> learning curve.

http://landley.net/aboriginal/about.html is what I used for my last
embedded Linux project.

"Aboriginal Linux is a shell script that builds the smallest/simplest
linux system capable of rebuilding itself from source code. This
currently requires seven packages: linux, busybox, uClibc, binutils, gcc,
make, and bash."

It builds a QEMU image you can boot into, and then you use the included
build system to build the rest of the stuff you need.  Once done, strip
out the build tools, dd the result to something your embedded system can
boot from.

My project was for a device that needed to be audited by the government,
including providing them with something they could use to build it
themselves.  Making it into a reproducible build was easy.  It passed the
audit.

For all of my Devuan systems I start from minimal debootstrap install,
chroot into that, then apt install the rest.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Embedded devuan (was Re: Devuan with usr merge?)

[karl]

Didier Kryn:
> Le 16/11/2021 à 01:44, Florian Zieboll via Dng a écrit :
> > On Mon, 15 Nov 2021 21:19:08 +0100
...
> > As I use to do a minimal *.bian install on my SoC hardware, which
> > I afterwards move to the Devuan repositories, while keeping the
> > related original "firmware" repository, I must confess that the
> > whole "embedded"-thing is still somewhat unclear to me, at least
> > regarding kernel and firmware updates. I'd be more than happy to
> > get a hint towards an honest introduction to this topic.

If you are using embedded linux, you probably have an ip-connection to
the hw and uboot as the fw/bootlooder/bios or what you prefer to call it.
If you have an ip-connection, you can just ssh to the box and copy it to
the right place and do whatever is needed.
 You usually don't update the processor, embedded board or other fw 
than uboot. If you want to do that you have to check the manufacturer
documentation.

...
>     I wish to every Linux fan to live this adventure.

 Ack, here is example manufacturer documentation of the process:
http://developer.embedian.com/display/LOS/SMARC+T335X

That hw is similar to the BeagleBoneBlack mentioned by Antoine,
so if you start off the BBB, this one could be the next in your
learning curve.

Regards,
/Karl Hammar

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

Re: [DNG] Devuan with usr merge?

[Didier Kryn]

Le 16/11/2021 à 01:44, Florian Zieboll via Dng a écrit :
> On Mon, 15 Nov 2021 21:19:08 +0100
> Antoine via Dng  wrote:
>> For what it's worth, I can confirm this : I ran a BeagleBoneBlack
>> build of Devuan for a while and was rather surprised one day to
>> discover that it had no kernel package installed at all. The kernel
>> and initramfs where packed into a u-boot file and once loaded, the OS
>> didn't care.
> As I use to do a minimal *.bian install on my SoC hardware, which I 
> afterwards move to the Devuan repositories, while keeping the related 
> original "firmware" repository, I must confess that the whole 
> "embedded"-thing is still somewhat unclear to me, at least regarding kernel 
> and firmware updates. I'd be more than happy to get a hint towards an honest 
> introduction to this topic.
>
    This takes some learning by experimentation. The first lesson is to
install a Devuan distro in an empty directory which will become the root
directory of the new system. Then you can use it by the mean of chroot.
The way to install the distro in this directory is debootstrap.
Debootstrap, as its name tells, is the bootstrap of the installation of
a Debian distro. When you execute chroot, you change the whole
userspace, but you still run the same kernel. From your chroot you can
continue the install wih apt-get. There are other ways to install a
distro than debootstrap, but debootstrap is usefull to learn.

    Of course, if you want to install the distro for another
architecture, you must use debootstrap --foreign and, then you cannot
switch to it with chroot. It's a little more work and you need a kernel
and understanding how the kernel passes control to userspace.

    To compile the kernel, download a source from kernel.org, look at
howtos and readme files, prepare for a build "out of tree", start from
the config of a known kernel, like the one you are currently running,
run menuconfig (eg) and compile.

    There are a lot of tricks to learn but you can only learn them by
experimentation I cannot list all of them because I used to do that many
years ago. It's time-consuming but, after that you fill more comfortable.

    Another experiment with great fun is to just install busybox in a
chroot. Build a monolithic version of Busybox statically linked against
musl libc and "install" it with symbolic links. You get a fully
functional non-GUI Linux OS; it's simply amazing. Just Busybox + kernel
can also be the starting point of an install.

    To summarize, a linux OS needs kernel + some userspace application.
To go further, the first thing the application must do is to mount /proc
and /sys. If you have a hotplugger (eudev for Debian, mdev for Busybox),
then you should also mount /dev and /dev/pts and launch the hotplugger.
This applies if the OS is standalone; in a chroot, just mount these
/proc, /sys, /dev, /dev/pts as copies of the ones of the main OS, using
mount --bind.

    I wish to every Linux fan to live this adventure.

--     Didier


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