Re: libXp -- was there a better way?

[Sven Joachim]

On 2020-10-23 23:53 +0100, Mark Fletcher wrote:

> I occasionally use a specialist piece of software called xephem, which
> is old but doesn't to my knowledge have a newer replacement that's 1% as
> good. I tried to fire it up the other night for the first time since I
> installed buster. It refused to run because libXp.so.6 was missing. A
> bit of googling showed me that this is an old, deprecated library for
> printing in X.

That is true, it is a client library for a server (xprint) which had
been removed from Debian a few years earlier.

> I couldn't run the execuable of xephem I had previously
> built and I couldn't build the latest version because of its expectation
> to find the include  which is provided by the same
> library... ("latest" version isn't very new...)

From 2015, I guess the xephem authors have stopped its development.

> libXp.so.6 was last in Debian in Jessie, in package libxp6. Looking at
> the dependencies of libxp6 in Jessie, they were all installed on my
> system (obviously newer versions) except multiarch-support. So I
> downloaded the package from Jessie and used gdebi to install it on my
> system. This worked, and now xephem runs.
>
> To avoid trouble when I next upgrade I propose from here to create a
> dummy package for xephem using equivs to register the dependency on
> libxp6, and then mark libxp6 as automatically installed, so the package
> manager in a future upgrade can figure out it can remove xephem's dummy
> package and thereby get rid of libxp6 if it causes conflicts.

Sounds like a good plan to me.

> I have no
> idea if xephem will now be able to print, but I don't care as I don't
> want to use its printing functionality, I only did any of this because
> the missing library was preventing it from starting.

I guess it won't be able to print because of the missing server, but
maybe I am wrong here.

> My question is, was there a better way to resolve this dependency? And,
> in a Buster system which has been installed not upgraded, am I in danger
> of creating trouble for myself by having this old package on my system?

Quite unlikely, the only problem is the missing security support for
this library and the software using it (i.e., xephem).

Cheers,
   Sven

Re: Intel RST driver -> SSD bug ?

[David Christensen]

On 2020-10-22 21:48, A. Kapetanovic wrote:

23 oct. 2020 04:27:38 David Christensen :

Who wrote algo- B1.pl?  Who designed the database?  Are they for a personal 
project, for a business, or something else?


I designed all and it is for a personal business


Okay.


Do you own the four books I previously recommended?


Have you considered hiring a tutor or consultant?


On 2020-10-22 22:06, A. Kapetanovic wrote:
>> Then the problem is the Perl script and/or how the Perl script 
interacts with your database.

>
> But a function vanished from my file...


Does the source code of your script change when you run the script?  If 
so, is this by design?



Please condense your script down to a short example that demonstrates 
the bug, post your code, explain what you expect the code to do, post a 
sample run, explain what happened, and explain why what happened does 
not match your expectations.



David

RE: Sophos Users Database

[daniel rossie]

Hi There,



I am following up to check if you had a chance to review my previous email.



If yes, please email me with your requirements for the Counts, Pricing and 
Samples for your review.



Regards,

Daniel




From: daniel rossie
Sent: Tuesday, October 20, 2020 9:58 PM
To: 'debian-user@lists.debian.org'
Subject: Sophos Users Database
Importance: High


Hi,



Would you be interested in acquiring Sophos Users Database for your marketing 
campaigns?



The database will have access to decision makers and companies using Sophos 
with their emails, direct numbers, company name and other relevant data fields.



We can also deliver you other similar technology users like Symantec, Fortinet, 
Trend Micro, McAfee and Palo Alto Networks.



Please let me know your Target Geography: _ for the Counts and Pricing 
details.



This Halloween, We have a steal deal price on Sophos Users database.



Best Regards,

Daniel Rossie

Marketing | CA, USA



If you do not wish to receive future emails from us, please reply as 
'Unsubscribe'

libXp -- was there a better way?

[Mark Fletcher]

Hello

I am running Buster on c2009 amd64 hardware -- one of the earliest Intel 
Core i7s. This was a clean install of Buster done a little over a year 
ago. Previously I had run many older flavours of Debian on this hardware 
over the years.

I occasionally use a specialist piece of software called xephem, which 
is old but doesn't to my knowledge have a newer replacement that's 1% as 
good. I tried to fire it up the other night for the first time since I 
installed buster. It refused to run because libXp.so.6 was missing. A 
bit of googling showed me that this is an old, deprecated library for 
printing in X. I couldn't run the execuable of xephem I had previously 
built and I couldn't build the latest version because of its expectation 
to find the include  which is provided by the same 
library... ("latest" version isn't very new...)

libXp.so.6 was last in Debian in Jessie, in package libxp6. Looking at 
the dependencies of libxp6 in Jessie, they were all installed on my 
system (obviously newer versions) except multiarch-support. So I 
downloaded the package from Jessie and used gdebi to install it on my 
system. This worked, and now xephem runs.

To avoid trouble when I next upgrade I propose from here to create a 
dummy package for xephem using equivs to register the dependency on 
libxp6, and then mark libxp6 as automatically installed, so the package 
manager in a future upgrade can figure out it can remove xephem's dummy 
package and thereby get rid of libxp6 if it causes conflicts. I have no 
idea if xephem will now be able to print, but I don't care as I don't 
want to use its printing functionality, I only did any of this because 
the missing library was preventing it from starting.

My question is, was there a better way to resolve this dependency? And, 
in a Buster system which has been installed not upgraded, am I in danger 
of creating trouble for myself by having this old package on my system?

Thanks

Mark

Re: PATH nfg after su

[mick crane]

On 2020-10-23 19:01, Dan Ritter wrote:


I first used Linux in 1992, 13 or 14 months after Linus started
writing it. sudo was already 12 years old.


"Where do you want to go today" did it for me but I had such a lot of 
trouble shifting head into gear. Never really managed.


--
Key ID4BFEBB31

Re: PATH nfg after su

[Dan Ritter]

Tixy wrote: 
> 
> Thanks. Debian has su installed as part of a required package so I
> never bothered installing sudo, it just seemed to be an Ubuntu thing.

Robert Coggeshall and Cliff Spencer wrote the original subsystem
around 1980 at the Department of Computer Science at
SUNY/Buffalo. Robert Coggeshall brought sudo with him to the
University of Colorado Boulder. Between 1986 and 1993, the code
and features were substantially modified by the IT staff of the
University of Colorado Boulder Computer Science Department and
the College of Engineering and Applied Science, including Todd
C. Miller. The current version has been publicly maintained
by OpenBSD developer Todd C. Miller since 1994, and has been
distributed under an ISC-style license since 1999.

I first used Linux in 1992, 13 or 14 months after Linus started
writing it. sudo was already 12 years old.

-dsr-

Re: PATH nfg after su

[Tixy]

On Fri, 2020-10-23 at 15:11 +0200, Sven Hartge wrote:
> Tixy  wrote:
> > On Fri, 2020-10-23 at 08:19 -0400, Greg Wooledge wrote
> > > Using "sudo su -" is a new one to me.  Not only are you
> > > wastefully
> > > running two programs when you only need one.
> > It's useful (essential?) if you want a root shell when there's no
> > root
> > password set like on Ubuntu (and optionally on Debian).
> 
> No.
> 
> "sudo -i" does exactly that: Run a shell as "root" and ask for the
> password of the user calling it.

Thanks. Debian has su installed as part of a required package so I
never bothered installing sudo, it just seemed to be an Ubuntu thing.

-- 
Tixy

Re: Stretch => Buster: obsolete packages

[Clive Standbridge]

> Somehow both of those survived the upgrade from Jessie to Stretch (at a time 
> when I was not aware of the potential problem), and squirrelmail still works 
> fine.
> 
> Can I expect that they will also survive the upgrade to Buster?

Yes. I have done that, and the old squirrelmail package remained
installed in buster. I don't remember any special effort to keep it,
but it was a while ago.

You'd better make sure you don't have apt configured to automatically
answer yes, so you can choose what gets removed.

I can't tell you whether squirrelmail will continue to work in
buster. It wasn't working for me, and I removed it before realising my
immediate problem was an expired SSL certificate, not squirrelmail
itself.

-- 
Cheers,
Clive

Re: Stretch => Buster: obsolete packages

[Sven Hartge]

Jesper Dybdal  wrote:

> I use squirrelmail, and squirrelmail uses php5.

> Somehow both of those survived the upgrade from Jessie to Stretch (at
> a time when I was not aware of the potential problem), and
> squirrelmail still works fine.

> Can I expect that they will also survive the upgrade to Buster?

Expect? No. Unless you keep all the old and insecure packages and work
around possible package conflicts.

Besides: Squirrelmail is more or less dead. There is one lone sole
comitting to the code base and trying to keep it updated but I would not
trust any security on this.

My advise: Scrap Squirrelmail and migrate to Roundcube.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: PATH nfg after su

[Sven Hartge]

Tixy  wrote:
> On Fri, 2020-10-23 at 08:19 -0400, Greg Wooledge wrote

>> Using "sudo su -" is a new one to me.  Not only are you wastefully
>> running two programs when you only need one.

> It's useful (essential?) if you want a root shell when there's no root
> password set like on Ubuntu (and optionally on Debian).

No.

"sudo -i" does exactly that: Run a shell as "root" and ask for the
password of the user calling it.

S!

-- 
Sigmentation fault. Core dumped.

Stretch => Buster: obsolete packages

[Jesper Dybdal]

I use squirrelmail, and squirrelmail uses php5.

Somehow both of those survived the upgrade from Jessie to Stretch (at a 
time when I was not aware of the potential problem), and squirrelmail 
still works fine.


Can I expect that they will also survive the upgrade to Buster?

(Yes, I know I should switch to a supported webmailsolution, but I 
haven't got around to doing it yet...)


--
Jesper Dybdal
https://www.dybdal.dk

Re: PATH nfg after su

[Greg Wooledge]

On Fri, Oct 23, 2020 at 01:30:11PM +0100, Tixy wrote:
> On Fri, 2020-10-23 at 08:19 -0400, Greg Wooledge wrote
> [...]
> > Using "sudo su -" is a new one to me.  Not only are you wastefully
> > running two programs when you only need one.
> [...]
> 
> It's useful (essential?) if you want a root shell when there's no root
> password set like on Ubuntu (and optionally on Debian).

"sudo -s" and "sudo -i".

Hell, even "sudo bash" would be better.  su does a ridiculous amount
of extra crap.

Re: PATH nfg after su

[Tixy]

On Fri, 2020-10-23 at 08:19 -0400, Greg Wooledge wrote
[...]
> Using "sudo su -" is a new one to me.  Not only are you wastefully
> running two programs when you only need one.
[...]

It's useful (essential?) if you want a root shell when there's no root
password set like on Ubuntu (and optionally on Debian).

Re: Running HGST's DFT utility from a flash drive

[Celejar]

On Thu, 22 Oct 2020 10:32:17 +1100
David  wrote:

> On Thu, 22 Oct 2020 at 08:45, David  wrote:
> 
> Hmmm again. Ignore my previous message. I didn't read the thread
> carefully enough. I still haven't done that, because I should be
> doing other things, but I have looked a little bit more carefully
> so I have slightly better suggestions.

...

> I downloaded the bootable image
> https://www1.hgst.com/hdd/support/downloads/ftool_215_install.IMG
> 
> and looked inside it using:
> sudo mount -r -t msdos -o loop dft32_v416_b00_install.IMG /mnt/junk

I tried that too. Just for the record, mount is pretty smart these
days: a simple

# mount image_file mount_point

works fine ;)

> The CONFIG.SYS file in the image shows what drivers are expected
> to be loaded. A lot of what is in there is standard guff (ramdrive, upper
> memory use, that may well be unnecessary) and causing the error
> messages you reported earlier. It could be greatly simplified.
> It looks like no additional drivers are loaded for ATA drives.
> 
> The AUTOEXEC.BAT file in the image contains the essential
>   PATH=A:\DOS;A:\DFT;A:\;
>   cd DFT
>   LOADDFT.EXE  DFT-V300.EXE DFT.EXE /PSR >NUL
> 
> The final line is the most important.
> That shows the correct use of the LOADDFT.EXE  and
> DFT-V300.EXE files, and invalidates my previous advice.
> 
> The >NUL might be hiding diagnostic messages.
> 
> And I wonder if /PSR is anything like "terminate and stay resident"
> so I would be wary of expecting sensible results if running that
> line more than one time.
> 
> What I would do is rename AUTOEXEC.BAT in the image, to disable
> it, and I would run the above commands manually at the DOS prompt.
> And I would run them without the >NUL and perhaps also without the /PSR

Thanks much. I think I'm done wasting time trying to get this thing to
work, but if I'm motivated to try again, I'll keep this in mind.

Celejar

Re: PATH nfg after su

[Greg Wooledge]

On Fri, Oct 23, 2020 at 12:15:24PM +, Andrew M.A. Cater wrote:
> Behaviour changed in Buster - su - is now required. [Likewise sudo su - if 
> you use sudo]

That's silly.  Just use "sudo -i" if you want a root login shell, or
"sudo -s" if you want a normal root shell (roughly equivalent to what "su"
used to do before buster).

Using both sudo and su chained together is a complete waste.

Using "sudo su -" is a new one to me.  Not only are you wastefully
running two programs when you only need one, but you're ignoring the
fact that sudo has already changed PATH for you, so you don't need to
force su to run a login shell to do it *again*.

Re: PATH nfg after su

[Andrew M.A. Cater]

On Thu, Oct 22, 2020 at 11:41:07PM -0400, Bob Bernstein wrote:
> On Thu, 22 Oct 2020, Bob Bernstein wrote:
> 
> > PATH=/home/bob/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
> 
> I examined su(1) and learned that one solution for me is to invoke su with
> the '-l' argument, which creates a 'login' shell in the new env. This sets,
> for me, the PATH to
> '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
> 
> Which is very cool..
> 

Behaviour changed in Buster - su - is now required. [Likewise sudo su - if you 
use sudo]
Catches people out especially because of muscle memory :)

All the best,

Andy Cater


> Thank you.
> 
> -- 
> A person of great honour in Ireland (who was pleased to stoop so low as to
> look into my mind) used to tell me that my mind was like a conjured spirit,
> that would do mischief if I did not give it employment.
>   Jonathan Swift
> 

Re: PATH nfg after su

[Greg Wooledge]

On Thu, Oct 22, 2020 at 11:41:07PM -0400, Bob Bernstein wrote:
> On Thu, 22 Oct 2020, Bob Bernstein wrote:
> 
> > PATH=/home/bob/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
> 
> I examined su(1) and learned that one solution for me is to invoke su with
> the '-l' argument, which creates a 'login' shell in the new env. This sets,
> for me, the PATH to
> '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
> 
> Which is very cool..

Not the word I would have chosen.  See also:

https://wiki.debian.org/NewInBuster

Re: kbrequest & openvt

[Greg Wooledge]

On Thu, Oct 22, 2020 at 10:30:17PM +, mike.junk...@att.net wrote:
> For years under sysvinit, in /etc/inittab, this line:
> kb::kbrequest:$( [ "`id -u`" -eq 0 ] && /bin/openvt -su || sudo /bin/openvt 
> -su)
> allowed me to open another VT by keying Control-UpArrow.

What a cargo-culted mess.  Mixing both forms of command substitution
syntax is sure sign that someone "borrowed" some code that they don't
understand, and then banged on it with a rock until it appeared to
work some of the time.

Why do you even need a check for the user ID of a program spawned by
init?  It's always root.

> I've had no luck generating that same functionality under systemd.
> If anyone else has managed to do this I'd sure appreciate a primer.

So, I searched google for "systemd equivalent kbrequest", and
it gave me .

It has a section about a unit named kbrequest.target, under the
heading of SIGWINCH (very comparable to what the init/inittab man pages
show).

So, I would imagine what you want to do is place your command in a
customized kbrequest.target unit, which you would create under /etc.
And skip all that dumb ID-checking shell wrapper code, because it
always runs as root anyway.