Re: What happened to cal?

[Thomas Schmitt]

Hi,

Jeremy Ardley wrote:
> As I recall, there used to be a
> command called "cal" which would simply print this month's calendar to the
> screen. [...]
> Now that I've moved to bullseye, I don't see the command nor
> a package containing it.

It is in the package ncal which obviously was newly introduced as binary
package of source package bsdmainutils
  https://packages.debian.org/bullseye/amd64/ncal/filelist
  https://packages.debian.org/source/bullseye/bsdmainutils

In buster there was only one binary package derived from that source:
  https://packages.debian.org/source/buster/bsdmainutils
  https://packages.debian.org/buster/amd64/bsdmainutils/filelist


Have a nice day :)

Thomas

Re: What happened to cal?

[Jeremy Ardley]

On 26/9/21 1:46 pm, Jeremy Ardley wrote:


On 26/9/21 1:24 pm, Paul M. Foster wrote:

Folks:

I'm wondering if I'm mis-remembering here. As I recall, there used to 
be a command called "cal" which would simply print this month's 
calendar to the screen. It would do other calendars, depending on 
command line parameters. Now that I've moved to bullseye, I don't see 
the command nor a package containing it. There is a command "gcal" 
which appears to do the same thing.


Am I missing something? Was there a separate package called "cal" 
which was automatically installed in earlier versions of Debian? Or 
was there an automatic alias to the gcal program?


Paul




I'm on buster and cal is stil there.


it's a link to ncal

ls -l /usr/bin/cal
lrwxrwxrwx 1 root root 4 May  4  2018 /usr/bin/cal -> ncal

--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: What happened to cal?

[Jeremy Ardley]

On 26/9/21 1:24 pm, Paul M. Foster wrote:

Folks:

I'm wondering if I'm mis-remembering here. As I recall, there used to 
be a command called "cal" which would simply print this month's 
calendar to the screen. It would do other calendars, depending on 
command line parameters. Now that I've moved to bullseye, I don't see 
the command nor a package containing it. There is a command "gcal" 
which appears to do the same thing.


Am I missing something? Was there a separate package called "cal" 
which was automatically installed in earlier versions of Debian? Or 
was there an automatic alias to the gcal program?


Paul




I'm on buster and cal is stil there.

--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

What happened to cal?

[Paul M. Foster]

Folks:

I'm wondering if I'm mis-remembering here. As I recall, there used to be 
a command called "cal" which would simply print this month's calendar to 
the screen. It would do other calendars, depending on command line 
parameters. Now that I've moved to bullseye, I don't see the command nor 
a package containing it. There is a command "gcal" which appears to do 
the same thing.


Am I missing something? Was there a separate package called "cal" which 
was automatically installed in earlier versions of Debian? Or was there 
an automatic alias to the gcal program?


Paul

Re: Proprietary USB Drivers; Ya Gotta' Love'em.

[Martin McCormick]

So, what is the easiest route to end up with a kernel that has
this patch in it?

The image for the current kernel is
4.19.0-5-686-pae

The Raspberry Pi is an arm-based system and the image
version number is probably different but the idea is the same,
have a kernel that doesn't choke when one is using the ICR-30
usbC port.

To put it bluntly, this is an area of Linux I have very
little familiarity with because generally, Linux kernels just
work so this is a left-handed complement in that I think this is
the first kernel bug that I have encountered ever.

I am sure I have run kernels with other bugs that I
didn't know about but this is the first time one has bitten me,
so to speak.

Thanks.


Martin WB5AGZ
Martin McCormick  WB5AGZ

Re: backup directory/file exclusion pattern list for borgbackup

[Default User]

On Sat, Sep 25, 2021 at 8:04 PM Kushal Kumaran  wrote:
>
> On Sat, Sep 25 2021 at 06:24:12 PM, Default User  
> wrote:
> > Hello!
> >
> > I want to try using borgbackup to do backups of my (only) user directory:
> > /home/debian-user
> >
> > I just want to do so using Vorta, a GUI for borgbackup.
> >
> > But I just need a good, general list of directory and file type
> > exclusions that I can just cut and paste into the Exclude Patterns
> > window in Vorta.  Something like the default list of exclusions that
> > appears by default in the Backintime backup program.
> >
>
> I don't understand what a general list of exclusions would look like.
> Do you have examples of what backintime excludes by default?  My own
> borgbackup runs backup everything on disk; I don't feel the need to
> exclude anything.
>
> > Note 1: borgbackup uses a matching pattern called "Fnmatch" with which
> > I am not familiar, and don't want to learn by trial and error, losing
> > data in the process.  Which is why I am looking for a "drop-in" basic
> > exclude list.
> >
>
> Run "borg help patterns" to see explanation of how borgbackup deals with
> patterns.  It has this to say about fnmatch:
>
> This is the default style for --exclude and --exclude-from.  These
> patterns use a variant of shell pattern syntax, with '*' matching
> any number of characters, '?' matching any single character, '[...]'
> matching any single character specified, including ranges, and
> '[!...]'  matching any character not specified. For the purpose of
> these patterns, the path separator (backslash for Windows and '/' on
> other systems) is not treated specially. Wrap meta-characters in
> brackets for a literal match (i.e. [?] to match the literal
> character ?). For a path to match a pattern, the full path must
> match, or it must match from the start of the full path to just
> before a path separator. Except for the root path, paths will never
> end in the path separator when matching is attempted.  Thus, if a
> given pattern ends in a path separator, a '*' is appended before
> matching is attempted.
>
> > Note 2: I am not intending to use borgbackup to back up the whole
> > system; just /home/debian-user and its subdirectories.  I am using
> > timeshift to back up the rest of the system.  Timeshift uses a huge
> > amount of disk space, but it . . .  works.
> >
>
> I don't know how timeshift stores backups.  borg uses deduplicated
> storage that avoids storing identical data multiple times.  My own borg
> backups results in ~1G of new data every week (and about the same amount
> being deleted from expiring backups).  There is no significant increase
> in repository size week-over-week.  That obviously would not be the same
> for everyone, but if you're bothered by the amount of disk space used
> you can try it out.
>
> > Note 3: I am aware that some use backintime to back up user data, and
> > I have tried it myself.  But it just seems to have some "problems".
> > For example, the built-in "diff" utility does not seem to do anything.
> > It seems old and gives the impression of not being heavily developed.
> > The documentation is "adequate" but mediocre. And what really grinds
> > my gears about backintime, a problem apparently known as far back as
> > 2014:
> >
> > "Warning: A recent security audit revealed several possible attack
> > vectors for EncFs.
> >
> >>From https://defuse.ca/audits/encfs.htm:
> >
> > EncFS is probably safe as long as the adversary only gets one copy of
> > the ciphertext and nothing more. EncFS is not safe if the adversary
> > has the opportunity to see two or more snapshots of the ciphertext at
> > different times. EncFS attempts to protect files from malicious
> > modification, but there are serious problems with this feature.
> >
> > This might be a problem with Back In Time snapshots."
> >
> > Gee . . .  think so?
>
> That report talks about issues with encfs design.  There is nothing
> backintime can do to fix those.
>
> borg can encrypt its backup images, and it recommendeds enabling that.
> So an adversary would not get access to the encfs ciphertext directly.
> They could get access to borg ciphertext instead, which may or may not
> be vulnerable to the same problems.  AFAIK there hasn't been a security
> audit of borgbackup itself.  The page at
> https://borgbackup.readthedocs.io/en/stable/internals/security.html#borgcrypto
> describes the design of borg security.
>
> --
> regards,
> kushal
>


Hi, Kushal.

In Vorta, under the "Sources" tab, there is an area (window) for input
into which you can type or paste text, such as:

**/.cache

to denote exclusions, that is, things you do not want to back up.
This is from /home/debian_user/.config/backintime/config:

. . .
profile1.snapshots.exclude.1.value=.gvfs
profile1.snapshots.exclude.2.value=.cache/*
profile1.snapshots.exclude.3.value=.thumbnails*
profile1.snapshots.exclude.4.value=.local/share/[Tt]rash*
profile1.snap

Re: `wget' web site

[Karthik]

On Sun, Sep 26, 2021 at 5:18 AM Rodolfo Medina  wrote:
>
> Hi all.
>
> I manage to download an entire website, say www.mysite.com, with simply
>
>  $ wget -r -l 0 www.mysite.com
>
> After that, I can surf that web site offline with all its internal links.
> Perfect.
>
> Now the problem comes when I want to copy that stuff into my Android tablet 
> and
> read it offline too.  Then the links do not work any more.
>
> Any suggestions?
>

That's because in Android 7+, when you open a file in any app through
the file manager
that opened app doesn't have access to the "file path" of that file.
it just gets the file descriptor of that file and accesses it as a stream.

when you open a downloaded website (bunch of html,js,css files in hierarchy).
you open a single html file(index.html) and click on hyperlinks(file
paths resolved relatively against index.html) to browse the website
from there on.
Since the browser in your desktop gnu/linux system has direct access
to file paths, it can resolve them and you can browse them easily.
But when open that same index.html file in android the file manager
sends an intent(request containing URI,file mime-type,perms)
requesting android system to resolve that file(.html file)
against installed apps, android system checks whether the any
installed app can open this type(mime-type) of file or not,
if there are multiple apps(mostly browsers) installed that can open
html files it asks user to choose one app(that just once and always
dialog),
since the browser can open html files it sends that intent to the
browser(or to the app you selected if there are multiple ones).
the browser checks the intent and resolves the URI in the intent(by
asking android system), the request gets passed back to the file
manager's Content provider,
that is why you see "content:://" type url in browser and not
"file://" as in desktop browser,then
the file manager content provider sends back a file descriptor of that
requested file(index.html) back to browser,
which then gets open as plain  html file because the css files,assets
cant be resolved from that URI

Solution is to use some app that can open offline websites  directly
from local storage
using storage permission and not through file manager apps unless you
have an android 6 or below device.

https://developer.android.com/about/versions/nougat/android-7.0-changes#sharing-files

Re: Privacy and defamation of character on Debian public forums

[The Wanderer]

On 2021-09-25 at 20:00, Greg Wooledge wrote:

> On Sat, Sep 25, 2021 at 07:51:18PM -0400, rhkra...@gmail.com wrote:
> 
>> On Saturday, September 25, 2021 07:43:04 PM rhkra...@gmail.com
>> wrote:

>>> I had to look up the meaning of FAOD.  Are you kidding me?  What
>>> did I do or say to get a response like that?
>>> 
>>> I may have misunderstood which message you were pointing to -- I
>>> was interested in the message that Chuck wrote that prompted all
>>> the criticism.
>>> 
>>> So a misunderstanding about which message we each were talking
>>> about, but FAOD???
>>> 
>>> And if FAOD means what I found on the internet, that must violate
>>> the Debian CoC.
>> 
>> Oops, I may need to apologize -- I googled for FAOD, but in googles
>> own "it knows better" manner, it showed me definitios of FOAD :-(
> 
> I've been assuming it was a typo for FOAD, but I don't know what you 
> said to provoke that reaction.
> 
> If it really was FAOD then I have no idea what it stands for.

rhkramer correctly identified it in the most recent reply: "For
Avoidance of Doubt". It hadn't occurred to me that it wouldn't be
readily recognizable in these circles, or that Google wouldn't find it
easily. (I may actually be more surprised by the latter than by the former.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: backup directory/file exclusion pattern list for borgbackup

[Kushal Kumaran]

On Sat, Sep 25 2021 at 06:24:12 PM, Default User  
wrote:
> Hello!
>
> I want to try using borgbackup to do backups of my (only) user directory:
> /home/debian-user
>
> I just want to do so using Vorta, a GUI for borgbackup.
>
> But I just need a good, general list of directory and file type
> exclusions that I can just cut and paste into the Exclude Patterns
> window in Vorta.  Something like the default list of exclusions that
> appears by default in the Backintime backup program.
>

I don't understand what a general list of exclusions would look like.
Do you have examples of what backintime excludes by default?  My own
borgbackup runs backup everything on disk; I don't feel the need to
exclude anything.

> Note 1: borgbackup uses a matching pattern called "Fnmatch" with which
> I am not familiar, and don't want to learn by trial and error, losing
> data in the process.  Which is why I am looking for a "drop-in" basic
> exclude list.
>

Run "borg help patterns" to see explanation of how borgbackup deals with
patterns.  It has this to say about fnmatch:

This is the default style for --exclude and --exclude-from.  These
patterns use a variant of shell pattern syntax, with '*' matching
any number of characters, '?' matching any single character, '[...]'
matching any single character specified, including ranges, and
'[!...]'  matching any character not specified. For the purpose of
these patterns, the path separator (backslash for Windows and '/' on
other systems) is not treated specially. Wrap meta-characters in
brackets for a literal match (i.e. [?] to match the literal
character ?). For a path to match a pattern, the full path must
match, or it must match from the start of the full path to just
before a path separator. Except for the root path, paths will never
end in the path separator when matching is attempted.  Thus, if a
given pattern ends in a path separator, a '*' is appended before
matching is attempted.

> Note 2: I am not intending to use borgbackup to back up the whole
> system; just /home/debian-user and its subdirectories.  I am using
> timeshift to back up the rest of the system.  Timeshift uses a huge
> amount of disk space, but it . . .  works.
>

I don't know how timeshift stores backups.  borg uses deduplicated
storage that avoids storing identical data multiple times.  My own borg
backups results in ~1G of new data every week (and about the same amount
being deleted from expiring backups).  There is no significant increase
in repository size week-over-week.  That obviously would not be the same
for everyone, but if you're bothered by the amount of disk space used
you can try it out.

> Note 3: I am aware that some use backintime to back up user data, and
> I have tried it myself.  But it just seems to have some "problems".
> For example, the built-in "diff" utility does not seem to do anything.
> It seems old and gives the impression of not being heavily developed.
> The documentation is "adequate" but mediocre. And what really grinds
> my gears about backintime, a problem apparently known as far back as
> 2014:
>
> "Warning: A recent security audit revealed several possible attack
> vectors for EncFs.
>
>>From https://defuse.ca/audits/encfs.htm:
>
> EncFS is probably safe as long as the adversary only gets one copy of
> the ciphertext and nothing more. EncFS is not safe if the adversary
> has the opportunity to see two or more snapshots of the ciphertext at
> different times. EncFS attempts to protect files from malicious
> modification, but there are serious problems with this feature.
>
> This might be a problem with Back In Time snapshots."
>
> Gee . . .  think so?

That report talks about issues with encfs design.  There is nothing
backintime can do to fix those.

borg can encrypt its backup images, and it recommendeds enabling that.
So an adversary would not get access to the encfs ciphertext directly.
They could get access to borg ciphertext instead, which may or may not
be vulnerable to the same problems.  AFAIK there hasn't been a security
audit of borgbackup itself.  The page at
https://borgbackup.readthedocs.io/en/stable/internals/security.html#borgcrypto
describes the design of borg security.

-- 
regards,
kushal

Re: Privacy and defamation of character on Debian public forums

[Greg Wooledge]

On Sat, Sep 25, 2021 at 07:51:18PM -0400, rhkra...@gmail.com wrote:
> On Saturday, September 25, 2021 07:43:04 PM rhkra...@gmail.com wrote:
> > On Saturday, September 25, 2021 06:32:16 PM The Wanderer wrote:
> > > FAOD,
> > 
> > I had to look up the meaning of FAOD.  Are you kidding me?  What did I do
> > or say to get a response like that?
> > 
> > I may have misunderstood which message you were pointing to -- I was
> > interested in the message that Chuck wrote that prompted all the criticism.
> > 
> > So a misunderstanding about which message we each were talking about, but
> > FAOD???
> > 
> > And if FAOD means what I found on the internet, that must violate the
> > Debian CoC.
> 
> Oops, I may need to apologize -- I googled for FAOD, but in googles own "it 
> knows better" manner, it showed me definitios of FOAD :-(

I've been assuming it was a typo for FOAD, but I don't know what you
said to provoke that reaction.

If it really was FAOD then I have no idea what it stands for.

Re: Privacy and defamation of character on Debian public forums

[The Wanderer]

On 2021-09-25 at 19:51, rhkra...@gmail.com wrote:

> On Saturday, September 25, 2021 07:43:04 PM rhkra...@gmail.com
> wrote:
> 
>> On Saturday, September 25, 2021 06:32:16 PM The Wanderer wrote:
>>> FAOD,
>> 
>> I had to look up the meaning of FAOD.  Are you kidding me?  What
>> did I do or say to get a response like that?
>> 
>> I may have misunderstood which message you were pointing to -- I
>> was interested in the message that Chuck wrote that prompted all
>> the criticism.
>> 
>> So a misunderstanding about which message we each were talking
>> about, but FAOD???
>> 
>> And if FAOD means what I found on the internet, that must violate
>> the Debian CoC.
> 
> Oops, I may need to apologize -- I googled for FAOD, but in googles
> own "it knows better" manner, it showed me definitios of FOAD :-(
> 
> Still don't know what FAOD means.
> 
> Ahh, looking harder, apparently means:For Avoidance Of Doubt
> (chiefly British)
> 
> Have a good day, and sorry for a 2nd misunderstanding.

No worries. I was a bit confused by your first response, but not in the
slightest bit offended.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Privacy and defamation of character on Debian public forums

[rhkramer]

On Saturday, September 25, 2021 07:43:04 PM rhkra...@gmail.com wrote:
> On Saturday, September 25, 2021 06:32:16 PM The Wanderer wrote:
> > FAOD,
> 
> I had to look up the meaning of FAOD.  Are you kidding me?  What did I do
> or say to get a response like that?
> 
> I may have misunderstood which message you were pointing to -- I was
> interested in the message that Chuck wrote that prompted all the criticism.
> 
> So a misunderstanding about which message we each were talking about, but
> FAOD???
> 
> And if FAOD means what I found on the internet, that must violate the
> Debian CoC.

Oops, I may need to apologize -- I googled for FAOD, but in googles own "it 
knows better" manner, it showed me definitios of FOAD :-(

Still don't know what FAOD means.

Ahh, looking harder, apparently means:  For Avoidance Of Doubt (chiefly 
British)

Have a good day, and sorry for a 2nd misunderstanding.



> > I understood the question I was responding to as asking which
> > message it was that contained the comments which Chuck was
> > characterizing as having "accused [him] in public of wrongdoing" -
> > which, naturally, would not have been written by Chuck.

`wget' web site

[Rodolfo Medina]

Hi all.

I manage to download an entire website, say www.mysite.com, with simply

 $ wget -r -l 0 www.mysite.com

After that, I can surf that web site offline with all its internal links.
Perfect.

Now the problem comes when I want to copy that stuff into my Android tablet and
read it offline too.  Then the links do not work any more.

Any suggestions?

Thanks for any help,

Rodolfo

Re: Privacy and defamation of character on Debian public forums

[rhkramer]

On Saturday, September 25, 2021 06:32:16 PM The Wanderer wrote:
> On 2021-09-25 at 09:06, rhkra...@gmail.com wrote:
> > On Friday, September 24, 2021 05:31:47 PM The Wanderer wrote:
> >> Based on what I've found in digging earlier, as well as the name
> >> mentioned by Andy Smith in his reply, I think it's probably
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899 -
> >> specifically. the first reply (comment 10).
> > 
> > Not replying specifically to The Wanderer, but just to this post
> > which mentions that the message at issue is #10, and noting that
> > message was not written by Chuck and instead written by someone from
> > the Debian side at least partially "critiquiing" Chuck's message #5.
> 
> FAOD,

I had to look up the meaning of FAOD.  Are you kidding me?  What did I do or 
say to get a response like that?

I may have misunderstood which message you were pointing to -- I was 
interested in the message that Chuck wrote that prompted all the criticism.

So a misunderstanding about which message we each were talking about, but 
FAOD???

And if FAOD means what I found on the internet, that must violate the Debian 
CoC.


> I understood the question I was responding to as asking which
> message it was that contained the comments which Chuck was
> characterizing as having "accused [him] in public of wrongdoing" -
> which, naturally, would not have been written by Chuck.

Re: upgrading and stuff

[Andy Smith]

Hi,

On Sat, Sep 25, 2021 at 06:22:17PM -0400, songbird wrote:
> Roy J. Tellason, Sr. wrote:

[Upgrading from Debian 8.11]

>   don't waste any more time trying to upgrade from a version that
> ancient.

I've done 8 to 10 (by way of 9) on ten different machines in the
year preceding the 11 release and I didn't find it very difficult or
time-consuming, though admittedly these were servers and those tend
to be less complex than desktops.

I'm not sure that going from 10 to 11 would add that much extra
work; it really depends on what packages are installed and how
carefully their configuration changes must be examined.

But yeah I wouldn't recommend it without that qualification, and it
may well be the case that a clean install is simpler and faster at
that point. A lot of people prefer that even for version x to
version x+1 changes.

Cheers,
Andy

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

Re: Proprietary USB Drivers; Ya Gotta' Love'em.

[Martin McCormick]

Gene Heskett  writes:
> You forgot to mention it can get the message thru better because it has a
> 12 db advantage over competing noise compared to the original AM,
> sometimes called Ancient Mary in our circles.

I did forget that but you are correct.  another
interesting thing about ssb which includes both sidebands is that
it was first tried during the 1930's as a concept and had to wait
until after World War II before amateur radio operators, the
millitary and commercial folks began using it routinely.  To not
stray too far from the group purpose, the usb dongles that give
you a wide coverage receiver from 26 to almost 1000 MHZ use
basically math to decode sideband, AM, FM and data using DSP
techniques.

Martin

Re: upgrading and stuff

[Dan Ritter]

Roy J. Tellason, Sr. wrote: 
> Lots of differences!  systemd instead of init,  grub instead of LILO,  and 
> probably many more than I'd want to list here.

As it turns out, these are just the defaults.

> I haven't been paying a whole lot of attention to upgrades.  Mostly
> it's been a matter of running synaptic package manager from time
> to time, and that's about it.  Except that lately it doesn't seem
> to be finding much of anything to do.  Reading some of the stuff
> in here, I suspect that I'm horribly out of date.  Executing "cat
> /etc/debian-version" returns 8.11!  And there's now apparently a
> version 11 out now?!  I have followed the advice of some of the posts
> in this list and consulted the release notes about how one might go
> about upgrading, and from the latest on back each one says something
> to the effect of only being able to upgrade from the last major
> version, so if there's a good way to do this whole thing at once I'd
> sure like to hear about it.

No -- you must go 8 to 9, reboot; 9 to 10; reboot; 10 to 11;
reboot. Normally that would have taken five or six years,
though.


> I sometimes want to log in as root.  (Please don't waste your time and
> mine by responding about how it's not a good idea to run as root...)
> Very early versions of debian would list root, as well as created
> users, on the login screen.  This one doesn't, I have to click on "not
> listed?" and then type in root and the root password.  That works on
> this install, but I also have a laptop with version 10 on it (sorry,
> but the codenames are just not something that I find easy to deal
> with) and in that case this procedure doesn't work.  At all.  The only
> thing that works there is to log in as a regular user, and then use
> the su command to get there.  A bit of a pain.  Where in the software
> is this controlled?  I really would like to change this behavior, if
> at all possible.

If the system will not let you login as root at a non-graphical
console, it means that root does not have a password set. Login
as a normal user, use su or sudo to change root's password, and
then you should be able to login as root.

If the system will not let you login as root from the graphical
display manager, it's the GDM's fault. It may be a configurable
option in its /etc/whateverdm. If not, you can always replace a
recalcitrant GDM with original xdm, which doesn't care so much.

-dsr-

Re: Privacy and defamation of character on Debian public forums

[The Wanderer]

On 2021-09-25 at 09:06, rhkra...@gmail.com wrote:

> On Friday, September 24, 2021 05:31:47 PM The Wanderer wrote:
> 
>> Based on what I've found in digging earlier, as well as the name
>> mentioned by Andy Smith in his reply, I think it's probably
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899 -
>> specifically. the first reply (comment 10).
> 
> Not replying specifically to The Wanderer, but just to this post
> which mentions that the message at issue is #10, and noting that
> message was not written by Chuck and instead written by someone from
> the Debian side at least partially "critiquiing" Chuck's message #5.

FAOD, I understood the question I was responding to as asking which
message it was that contained the comments which Chuck was
characterizing as having "accused [him] in public of wrongdoing" -
which, naturally, would not have been written by Chuck.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

backup directory/file exclusion pattern list for borgbackup

[Default User]

Hello!

I want to try using borgbackup to do backups of my (only) user directory:
/home/debian-user

I just want to do so using Vorta, a GUI for borgbackup.

But I just need a good, general list of directory and file type
exclusions that I can just cut and paste into the Exclude Patterns
window in Vorta.  Something like the default list of exclusions that
appears by default in the Backintime backup program.

Note 1: borgbackup uses a matching pattern called "Fnmatch" with which
I am not familiar, and don't want to learn by trial and error, losing
data in the process.  Which is why I am looking for a "drop-in" basic
exclude list.

Note 2: I am not intending to use borgbackup to back up the whole
system; just /home/debian-user and its subdirectories.  I am using
timeshift to back up the rest of the system.  Timeshift uses a huge
amount of disk space, but it . . .  works.

Note 3: I am aware that some use backintime to back up user data, and
I have tried it myself.  But it just seems to have some "problems".
For example, the built-in "diff" utility does not seem to do anything.
It seems old and gives the impression of not being heavily developed.
The documentation is "adequate" but mediocre. And what really grinds
my gears about backintime, a problem apparently known as far back as
2014:

"Warning: A recent security audit revealed several possible attack
vectors for EncFs.

>From https://defuse.ca/audits/encfs.htm:

EncFS is probably safe as long as the adversary only gets one copy of
the ciphertext and nothing more. EncFS is not safe if the adversary
has the opportunity to see two or more snapshots of the ciphertext at
different times. EncFS attempts to protect files from malicious
modification, but there are serious problems with this feature.

This might be a problem with Back In Time snapshots."

Gee . . .  think so?

Re: upgrading and stuff

[songbird]

Roy J. Tellason, Sr. wrote:
...
> For whatever it's worth,  I have no problems with a text-based login screen 
> and then typing startx once I've logged in,  which is pretty typical of my 
> Slackware installations anyhow.  The copy of Slackware that's running my 
> server machine doesn't even have a GUI installed on it.  But where would I 
> make that change?

  don't waste any more time trying to upgrade from a version that
ancient.  back up your data that you really care about and then
do a fresh install from the most recent stable version.

  i always come up with a desktop that has all my projects 
set up and ready to go in various sets of terminals.  the
one terminal i fire up first is the one where i log in as
root, bring up the network and then do my morning updates
and upgrade(s) (as needed).  i do this daily because i run
testing most of the time so i do want to check out what is
being updated recently.  sounds like you would be better 
off with stable.  :)


  songbird

Re: Postgresql ODBC driver not found

[Pierre Couderc]

On 9/25/21 3:46 PM, Henning Follmann wrote:


have you tried to use the odbc lib from unixodbc instead of
libiodbc?



I think you are right on many other points...

But particularly on this one !

I did remove libodbc2-dev and install unixodbc-dev and now it is OK...!!

Wow !

Thank you very much.

Let us have a Sunday without any odbc...

PC

Re: upgrading and stuff

[Andy Smith]

Hi Roy,

On Sat, Sep 25, 2021 at 05:07:46PM -0400, Roy J. Tellason, Sr. wrote:
> I haven't been paying a whole lot of attention to upgrades.
> Mostly it's been a matter of running synaptic package manager from
> time to time,  and that's about it.  Except that lately it doesn't
> seem to be finding much of anything to do.  Reading some of the
> stuff in here,  I suspect that I'm horribly out of date.
> Executing "cat /etc/debian-version" returns 8.11!

So, you are still running Debian 8.x (jessie). This went end of life
for support by Debian's security team in June 2018:

https://wiki.debian.org/DebianReleases#Production_Releases

You still have more limited support by the ELTS team up until some
time in 2022, but this is of limited scope which is why you haven't
seen many updates lately.

The release of the three newer stable versions of Debian seems to
have happened without you noticing. If you remain subscribed to this
mailing list then you will surely read here about the release of
Debian 12 (bookworm), but if you want a very low traffic
announcements feed then you could subscribe to the debian-announce
list instead:

https://lists.debian.org/debian-announce/

It's only received 6 emails so far this year:

https://lists.debian.org/debian-announce/2021/threads.html

> consulted the release notes about how one might go about
> upgrading,  and from the latest on back each one says something to
> the effect of only being able to upgrade from the last major
> version,  so if there's a good way to do this whole thing at once
> I'd sure like to hear about it.

Yes, upgrades are only supported from one release to another, so if
you wish to upgrade this machine you're going to have to consult the
release notes for Debian 9 about upgrading from 8.x to 9.x, and then
the release notes for Debian 10, and so on until you are at Debian
11.x.

It's not supported to go directly from 8 to 11 (or even from 8 to
10) and trying to do so will probably end in failure.

Or you could just reinstall and then put your data files back in
place from your backups. That may be quicker.

> The only thing that works there is to log in as a regular user,
> and then use the su command to get there.  A bit of a pain.  Where
> in the software is this controlled?  I really would like to change
> this behavior,  if at all possible.

I am not aware of any modern desktop environment that allows to log
in and run the entire GUI as root, for reasons you said you didn't
want to hear about. Someone else may be able to suggest some
alternate desktop environment that allows this.

Cheers,
Andy

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

Re: Proprietary USB Drivers; Ya Gotta' Love'em.

[Gene Heskett]

On Saturday 25 September 2021 14:11:30 Martin McCormick wrote:

> Charles Curley  writes:
> > Possibly a known kernel bug.
> >
> > https://forums.opensuse.org/showthread.php/538695-USB-driver-Zero-Le
> >ngth-Descriptor
> >
> > https://lore.kernel.org/lkml/1507709452-31260-1-git-send-email-msala
> >u...@iotecha.com/
> >
> > --
> > Does anybody read signatures any more?
> >
> > https://charlescurley.com
> > https://charlescurley.com/blog/
>
>   Thank you.  That's got to be it.  I've been doing debian Linux since
> right around 2000 but I must admit that I don't know the easiest
> way to include the patch referenced in the second link.
>
>   I will need to do that on an i86 box plus the Raspberry Pi
> I first discovered the issue on since I am apt to have the radio
> connected to either system and, if this problem is fixable, this
> solution is preferable because the radio defaults to using the
> usbC port as the serial port so it should still work if a full
> reset is ever needed and the mechanism for usb should naturally
> accept as many different devices as practical because you never
> know what you will need to connect until you try it and it fails.
>
>   As an amusing aside, the radio has a usb mode, but
> that's totally unrelated because in that case, USB stands for
> upper side band and is a very energy-efficient method of radio
> communication because it is only a spectrum of frequencies
> consisting of the sidebands of an audio signal without the
> carrier.  It can be LSB or lower side band or USB for upper side
> band.  Nothing like a few new acronyms for your day. I guess that's
> TMI.

You forgot to mention it can get the message thru better because it has a 
12 db advantage over competing noise compared to the original AM, 
sometimes called Ancient Mary in our circles.

> Martin McCormick WB5AGZ


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

upgrading and stuff

[Roy J. Tellason, Sr.]

I've been running Slackware since 1999 or so,  Debian somewhat less than that.  
I figured I'd give it a try because I was interested in handling dependencies 
easier (which it surely does well) and because in looking at so many distros I 
see a great many of them are "debian-based"...

Lots of differences!  systemd instead of init,  grub instead of LILO,  and 
probably many more than I'd want to list here.

I haven't been paying a whole lot of attention to upgrades.  Mostly it's been a 
matter of running synaptic package manager from time to time,  and that's about 
it.  Except that lately it doesn't seem to be finding much of anything to do.  
Reading some of the stuff in here,  I suspect that I'm horribly out of date.  
Executing "cat /etc/debian-version" returns 8.11!  And there's now apparently a 
version 11 out now?!  I have followed the advice of some of the posts in this 
list and consulted the release notes about how one might go about upgrading,  
and from the latest on back each one says something to the effect of only being 
able to upgrade from the last major version,  so if there's a good way to do 
this whole thing at once I'd sure like to hear about it.

Not much special about this installation,  I have done very little to it that's 
outside of debian packages,  maybe the odd script here and there.  I do see 
where they talk about backing stuff up.  Oh yeah,  and I have virtualbox 
running,  which is where I'm typing this email,  as I prefer some software's 
early versions,  running under an older Slackware.  Works for me,  anyhow...

I sometimes want to log in as root.  (Please don't waste your time and mine by 
responding about how it's not a good idea to run as root...)  Very early 
versions of debian would list root,  as well as created users,  on the login 
screen.  This one doesn't,  I have to click on "not listed?" and then type in 
root and the root password.  That works on this install,  but I also have a 
laptop with version 10 on it (sorry,  but the codenames are just not something 
that I find easy to deal with) and in that case this procedure doesn't work.  
At all.  The only thing that works there is to log in as a regular user,  and 
then use the su command to get there.  A bit of a pain.  Where in the software 
is this controlled?  I really would like to change this behavior,  if at all 
possible.

For whatever it's worth,  I have no problems with a text-based login screen and 
then typing startx once I've logged in,  which is pretty typical of my 
Slackware installations anyhow.  The copy of Slackware that's running my server 
machine doesn't even have a GUI installed on it.  But where would I make that 
change?

Any help,  advice,  etc. would be much appreciated.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: Proprietary USB Drivers; Ya Gotta' Love'em.

[Martin McCormick]

Charles Curley  writes:
> Possibly a known kernel bug.
> 
> https://forums.opensuse.org/showthread.php/538695-USB-driver-Zero-Length-Descriptor
> 
> https://lore.kernel.org/lkml/1507709452-31260-1-git-send-email-msa...@iotecha.com/
> 
> --
> Does anybody read signatures any more?
> 
> https://charlescurley.com
> https://charlescurley.com/blog/

Thank you.  That's got to be it.  I've been doing debian Linux since
right around 2000 but I must admit that I don't know the easiest
way to include the patch referenced in the second link.

I will need to do that on an i86 box plus the Raspberry Pi
I first discovered the issue on since I am apt to have the radio
connected to either system and, if this problem is fixable, this
solution is preferable because the radio defaults to using the
usbC port as the serial port so it should still work if a full
reset is ever needed and the mechanism for usb should naturally
accept as many different devices as practical because you never
know what you will need to connect until you try it and it fails.

As an amusing aside, the radio has a usb mode, but
that's totally unrelated because in that case, USB stands for
upper side band and is a very energy-efficient method of radio
communication because it is only a spectrum of frequencies
consisting of the sidebands of an audio signal without the
carrier.  It can be LSB or lower side band or USB for upper side
band.  Nothing like a few new acronyms for your day. I guess that's TMI.

Martin McCormick WB5AGZ

Re: Privacy and defamation of character on Debian public forums

[Jeremy Hendricks]

Chuck,

I’ve been following this email thread. I’m a nobody here but: you can’t
change the past but you control the future. People make mistakes in how
things are handled. But you can avoid them in the future.

I say this as an extrovert in a senior IT position and I've been known to
be “animated” in how I handle things sometimes.

Have a good weekend.

On Sat, Sep 25, 2021 at 12:59 PM Chuck Zmudzinski 
wrote:

> On 9/25/2021 10:02 AM, Andy Smith wrote:
> > Hello,
> >
> > On Sat, Sep 25, 2021 at 09:06:34AM -0400, rhkra...@gmail.com wrote:
> >> On Friday, September 24, 2021 05:31:47 PM The Wanderer wrote:
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899 -
> specifically.
> >>> the first reply (comment 10).
> > […]
> >
> >> I've read over message #5, and without being a Debian developer or a
> user of
> >> Xen, aside from being a little longer / wordier than probably
> necessary, I
> >> don't see anything so objectionable about it.
> > [ I am not a member of the Debian Xen team and haven't contributed
> > anything to this particular bug, but I have followed it all as I
> > have an interest in the team's work. ]
> >
> > It's not outrageously objectionable, it's just not a very good bug
> > report with some *slightly* objectionable elements and background.
> >
> > This whole thing is pretty mundane and has been blown out of all
> > proportion by Chuck failing to handle reasonable advice given by
> > someone trying to help in good faith.
>
> I don't doubt at all that the advice in message #10 was given
> in good faith. I thought the author of #10's decision to rudely
> refuse to collaborate with me forever by saying "Bye" in a later
> message was also an overreaction to anything wrong I might
> have done.
> > Also what would have remained
> > with a very niche audience (people interested in Debian's Xen
> > packages) has now been shown to a much wider audience as a
> > consequence of Chuck bringing this to the attention of debian-user.
> >
> > To explain a bit more of the background, you'll see that Chuck
> > referred to another bug in that bug log and a lot of other
> > discussion took place there. Some of the things that are wrong with
> > Chuck's bug are that Chuck criticised the Debian Xen team for
> > including particular patches, and made some other factually
> > incorrect statements,
>
> For example?
> > and wrote in a style as if as if the situation
> > were fully known about by the Debian Xen team while valiant users
> > like Chuck are crushed underfoot.
>
> I admit the Debian Xen Team may not have been aware
> of the situation, and besides, I was more concerned that
> the Debian Release Team did not notice that patches from
> an unstable branch of the Xen upstream source made it
> into the Debian stable release. There is what I would call
> a "Debian patch" exploit attack surface exposed here to the
> authors of malware. THAT is a serious issue. The Xen Team's
> patches in question are perfectly acceptable in unstable and
> maybe in testing, but IMO, not in stable.
> >
> > In reality, the Debian Xen team didn't have good visibility of the
> > issue and it's not yet been proven where exactly the bug lies. Even
> > if it was shown to be in a patch that the team HAD taken on
> > questionable basis, so what, we are all volunteers here, there is no
> > need to berate people for their good faith efforts,
>
> I think its an overstatement to say I "berated" anyone in the
> bug report. You, however, judge me as "damned" and as a
> "laughingstock" in your first reply to my original post. That also
> is an overstatement of anything wrong I might have done,
> don't you think?
> > we should expect
> > bug reports to just focus on finding and fixing the bug not as
> > someone's platform to deal out a blame narrative.
>
> Agreed.
> >
> > Basically it's not a big deal and could have easily been turned
> > around; I felt #10 was a fairly gentle request to focus on the facts
> > and make progress but to say the criticism was not received well
> > would be an understatement!
>
> I am truly sorry, are there second chances in the Debian Community?
> >
> > For example, one of the "strongest" statements in #10 is
> >
> >  "It's good that you filed this bug against the Debian Xen
> >  package […] way you went about it ... not so good."
> >
> > Chuck's response to that seems to have been to go about complaining
> > in multiple unrelated locations of how he has been accused of being
> > "not good". Note that he's morphed a statement of "your bug report
> > was not done in a good way" into "someone in the Debian community
> > told me I was not a good person; remove their slander or risk being
> > sued". A dramatic misrepresentation of what actually happened. The
> > rest of it is full of things like that.
>
> Are you trying to say now I am not a good person? Seems so to me.
> >
> > It could be partially understandable if #10 had simply said, "your
> > bug report sucks," which believe me, I have seen and co

Re: Privacy and defamation of character on Debian public forums

[Chuck Zmudzinski]

On 9/25/2021 10:02 AM, Andy Smith wrote:

Hello,

On Sat, Sep 25, 2021 at 09:06:34AM -0400, rhkra...@gmail.com wrote:

On Friday, September 24, 2021 05:31:47 PM The Wanderer wrote:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899 - specifically.
the first reply (comment 10).

[…]


I've read over message #5, and without being a Debian developer or a user of
Xen, aside from being a little longer / wordier than probably necessary, I
don't see anything so objectionable about it.

[ I am not a member of the Debian Xen team and haven't contributed
anything to this particular bug, but I have followed it all as I
have an interest in the team's work. ]

It's not outrageously objectionable, it's just not a very good bug
report with some *slightly* objectionable elements and background.

This whole thing is pretty mundane and has been blown out of all
proportion by Chuck failing to handle reasonable advice given by
someone trying to help in good faith.


I don't doubt at all that the advice in message #10 was given
in good faith. I thought the author of #10's decision to rudely
refuse to collaborate with me forever by saying "Bye" in a later
message was also an overreaction to anything wrong I might
have done.

Also what would have remained
with a very niche audience (people interested in Debian's Xen
packages) has now been shown to a much wider audience as a
consequence of Chuck bringing this to the attention of debian-user.

To explain a bit more of the background, you'll see that Chuck
referred to another bug in that bug log and a lot of other
discussion took place there. Some of the things that are wrong with
Chuck's bug are that Chuck criticised the Debian Xen team for
including particular patches, and made some other factually
incorrect statements,


For example?

and wrote in a style as if as if the situation
were fully known about by the Debian Xen team while valiant users
like Chuck are crushed underfoot.


I admit the Debian Xen Team may not have been aware
of the situation, and besides, I was more concerned that
the Debian Release Team did not notice that patches from
an unstable branch of the Xen upstream source made it
into the Debian stable release. There is what I would call
a "Debian patch" exploit attack surface exposed here to the
authors of malware. THAT is a serious issue. The Xen Team's
patches in question are perfectly acceptable in unstable and
maybe in testing, but IMO, not in stable.


In reality, the Debian Xen team didn't have good visibility of the
issue and it's not yet been proven where exactly the bug lies. Even
if it was shown to be in a patch that the team HAD taken on
questionable basis, so what, we are all volunteers here, there is no
need to berate people for their good faith efforts,


I think its an overstatement to say I "berated" anyone in the
bug report. You, however, judge me as "damned" and as a
"laughingstock" in your first reply to my original post. That also
is an overstatement of anything wrong I might have done,
don't you think?

we should expect
bug reports to just focus on finding and fixing the bug not as
someone's platform to deal out a blame narrative.


Agreed.


Basically it's not a big deal and could have easily been turned
around; I felt #10 was a fairly gentle request to focus on the facts
and make progress but to say the criticism was not received well
would be an understatement!


I am truly sorry, are there second chances in the Debian Community?


For example, one of the "strongest" statements in #10 is

 "It's good that you filed this bug against the Debian Xen
 package […] way you went about it ... not so good."

Chuck's response to that seems to have been to go about complaining
in multiple unrelated locations of how he has been accused of being
"not good". Note that he's morphed a statement of "your bug report
was not done in a good way" into "someone in the Debian community
told me I was not a good person; remove their slander or risk being
sued". A dramatic misrepresentation of what actually happened. The
rest of it is full of things like that.


Are you trying to say now I am not a good person? Seems so to me.


It could be partially understandable if #10 had simply said, "your
bug report sucks," which believe me, I have seen and continue to see
even from long standing Debian Developers. But Diederik did also
take the time to give useful advice about HOW to move the situation
forward, in fact that was the majority of the response.


I really appreciate Diederik's input, my  point was I would have
preferred he contact me in private about any criticisms he had
for me personally before criticizing the way I wrote my bug
report in public. That is what I would have done if I wanted to
criticize him. But he is the one who made the first criticism
of a Debian volunteer in PUBLIC. So to defend myself, it had
to also be in public. That is why defamation is not the only
issue to discuss here. The other is privacy and whether or
not Debian v

Re: `aptitude update' won't update

[David Christensen]

On 9/25/21 2:08 AM, Rodolfo Medina wrote:

Please help with this:

# aptitude update
Hit http://dl.google.com/linux/chrome/deb stable InRelease
Get: 1 http://ftp.debian.org/debian stable InRelease [113 kB]
Get: 2 http://ftp.uk.debian.org/debian stable InRelease [113 kB]
E: Repository 'http://ftp.debian.org/debian stable InRelease' changed its
'Codename' value from 'buster' to 'bullseye'
E: Repository 'http://ftp.uk.debian.org/debian stable InRelease' changed its
'Codename' value from 'buster' to 'bullseye'
E: Failed to download some files
W: Failed to fetch http://ftp.uk.debian.org/debian/dists/stable/InRelease:
W: Failed to fetch http://ftp.debian.org/debian/dists/stable/InRelease:
E: Some index files failed to download. They have been ignored, or old ones
used instead.


My /etc/apt/sources.list:



deb http://ftp.uk.debian.org/debian/ stable main
deb-src http://ftp.uk.debian.org/debian/ stable main

# non-free
deb http://ftp.debian.org/debian/ stable main contrib non-free

#deb http://repository.spotify.com stable non-free

#deb [arch=amd64] https://repo.skype.com/deb stable main



Thanks in advance for any help...

Rodolfo



On 9/25/21 2:45 AM, Andrew M.A. Cater wrote:
> Change your /etc/apt/sources.list to reference buster by name - where 
there

> is stable, substitute the word buster.

+1


Here is the relevant portion of /etc/apt/sources.list on my daily 
driver, which I updated yesterday:


2021-09-25 09:36:14 dpchrist@dipsy ~
$ cat /etc/debian_version ; uname -a
10.10
Linux dipsy 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 
GNU/Linux


2021-09-25 09:38:46 dpchrist@dipsy ~
$ head -n 8 /etc/apt/sources.list
deb http://deb.debian.org/debian/ buster main non-free contrib
deb-src http://deb.debian.org/debian/ buster main non-free contrib

deb http://security.debian.org/debian-security buster/updates main 
contrib non-free
deb-src http://security.debian.org/debian-security buster/updates main 
contrib non-free


deb http://deb.debian.org/debian/ buster-updates main contrib non-free
deb-src http://deb.debian.org/debian/ buster-updates main contrib non-free


David

Re: USB sticks & Debian

[Bob Bernstein]

On Sat, 25 Sep 2021, rhkra...@gmail.com wrote:


I don't understand what you are trying to do.  Do you want to:


This one:
  * create a bootable USB on another OS to boot (the USB) and 
install Linux on some other system, or



--
...a society must incorporate the rationalizing
power symbolized by scientific knowledge, for
otherwise it will be a fatally split society-
split between a powerful elite and the
disenfranchised mass. To this we add now: an
irrational elite is the most dangerous of all.

Holton, Gerald. 1985. On the Integrity of
Science: The Issues Since Bronowski. Leonardo
18 (4), Special Issue: Jacob Bronowski: A
Retrospective (1985): 229-232.

KSig for Debian 11/bullseye

[Intense Red]

   KSig is a graphical editor for e-mail signature lines with a handy random 
function that can be plugged into KMail and other programs.

   For some reason it was dropped from Debian way back when. Someone 
recompiled it, made a *.deb and it ran fine in buster. But that binary *.deb 
requires KDE 4 libraries and other things that are not in bullseye.

   Does anyone know if a *.deb has been made for KSig to run in bullseye? (Or 
a similar functioning GUI editor for signatures?) TIA.


-- 
"You’re talking about the American dream. You find something that you love and 
then you twist and you torture it, try to find a way to make money at it. You 
spend a lifetime doing that and at the end you can’t find a trace of what you 
started out loving." -- From the 1998 movie Hope Floats.

Re: Privacy and defamation of character on Debian public forums

[Andy Smith]

Hello,

On Sat, Sep 25, 2021 at 09:06:34AM -0400, rhkra...@gmail.com wrote:
> On Friday, September 24, 2021 05:31:47 PM The Wanderer wrote:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899 - specifically.
> > the first reply (comment 10).

[…]

> I've read over message #5, and without being a Debian developer or a user of 
> Xen, aside from being a little longer / wordier than probably necessary, I 
> don't see anything so objectionable about it.

[ I am not a member of the Debian Xen team and haven't contributed
anything to this particular bug, but I have followed it all as I
have an interest in the team's work. ]

It's not outrageously objectionable, it's just not a very good bug
report with some *slightly* objectionable elements and background.

This whole thing is pretty mundane and has been blown out of all
proportion by Chuck failing to handle reasonable advice given by
someone trying to help in good faith. Also what would have remained
with a very niche audience (people interested in Debian's Xen
packages) has now been shown to a much wider audience as a
consequence of Chuck bringing this to the attention of debian-user.

To explain a bit more of the background, you'll see that Chuck
referred to another bug in that bug log and a lot of other
discussion took place there. Some of the things that are wrong with
Chuck's bug are that Chuck criticised the Debian Xen team for
including particular patches, and made some other factually
incorrect statements, and wrote in a style as if as if the situation
were fully known about by the Debian Xen team while valiant users
like Chuck are crushed underfoot.

In reality, the Debian Xen team didn't have good visibility of the
issue and it's not yet been proven where exactly the bug lies. Even
if it was shown to be in a patch that the team HAD taken on
questionable basis, so what, we are all volunteers here, there is no
need to berate people for their good faith efforts, we should expect
bug reports to just focus on finding and fixing the bug not as
someone's platform to deal out a blame narrative.

Basically it's not a big deal and could have easily been turned
around; I felt #10 was a fairly gentle request to focus on the facts
and make progress but to say the criticism was not received well
would be an understatement!

For example, one of the "strongest" statements in #10 is

"It's good that you filed this bug against the Debian Xen
package […] way you went about it ... not so good."

Chuck's response to that seems to have been to go about complaining
in multiple unrelated locations of how he has been accused of being
"not good". Note that he's morphed a statement of "your bug report
was not done in a good way" into "someone in the Debian community
told me I was not a good person; remove their slander or risk being
sued". A dramatic misrepresentation of what actually happened. The
rest of it is full of things like that.

It could be partially understandable if #10 had simply said, "your
bug report sucks," which believe me, I have seen and continue to see
even from long standing Debian Developers. But Diederik did also
take the time to give useful advice about HOW to move the situation
forward, in fact that was the majority of the response.

> I'm not sure which message Chuck wants deleted -- #5 or #10 (if either), but 
> I'm not sure he has "standing" to ask that #10 be deleted -- it seems he 
> would 
> have to contact the writer of message #10 and ask him to ask that message #10 
> be deleted.

I hope #10 is not deleted as it contains a lot of useful advice for
anyone else who experiences this bug and wants to help resolve it.
I'd also say that I can see Diederik is still working on narrowing
down where the bug lies, so the work of Diederik and potentially
others on the bug in question clearly isn't over, it can just
now proceed without Chuck's further input.

Though Chuck did clearly say that he wanted #10 deleted and
apparently now says that he has agreement that it will be from
someone official:

https://lists.debian.org/debian-user/2021/09/msg00802.html

I remain sceptical that this is an accurate report of whatever
discussion that Chuck has had with the powers that be. :)

Cheers,
Andy

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

Re: Proprietary USB Drivers; Ya Gotta' Love'em.

[Charles Curley]

On Sat, 25 Sep 2021 08:16:37 -0500
"Martin McCormick"  wrote:

> This is an embedded usb serial port in a radio receiver which
> works in MS Windows10 and I was hoping to write some control
> routines for a Raspberry Pi running buster and it does the
> following:

Possibly a known kernel bug.

https://forums.opensuse.org/showthread.php/538695-USB-driver-Zero-Length-Descriptor

https://lore.kernel.org/lkml/1507709452-31260-1-git-send-email-msa...@iotecha.com/

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Postgresql ODBC driver not found

[Henning Follmann]

On Sat, Sep 25, 2021 at 09:16:33AM +0200, Pierre Couderc wrote:
> 
> On 9/24/21 5:31 PM, Henning Follmann wrote:
> > 
> > and I see you do not do any error checking.
> > This would be a first step to find out where it fails.
> > 
> > I added some code...
> > 
> 
> You hare fully right, I have corrected, but I have the same result and no
> more idea.. :

I do not have much time this weekend, but I will try to set up my
computer to reproduce your setup  - maybe on Monday ...

In the meanwhile a few thoughts,
have you tried to use the odbc lib from unixodbc instead of
libiodbc?

Another thing I have myself no clue but, what happens if you do
not set the odbc version?

And just one thought about your loop:

try
do {
/* in there look at SQLSTATE
   for anything other than SQL_SUCCESS
   I am concerned that SQL_NO_DATA is
   not a reliable break indicator */



}while (ret == SQL_SUCCESS || ret == SQL_SUCCESS_WITH_INFO)

> 
> nous@pcouderc:~/projets//build$ ./ttest
> D  0.0:ln 19:main(): Start  : Compile time : Sep 25 2021 09:03:28
> 
> 0x55cee70a5ed0
> 
> 
> 
> nous@pcouderc:~/projets//build$ cat ../main.cpp
> #include 
> #include 
> #include 
> #pragma GCC diagnostic ignored "-Wendif-labels"
> #pragma GCC diagnostic ignored "-Wwrite-strings"
> 
> 
> #define TDBG clock_t ttdbg=clock();float
> ftdbg=((float)ttdbg)/CLOCKS_PER_SEC;
> #define DBG_(fmt, args...) {TDBG fprintf(stdout,string( string("D%5.1f:ln
> %d:%s(): ")+fmt).c_str(),ftdbg,__LINE__, __func__, ##args);fflush(stdout);}
> 
> using namespace std;
> extern "C"
> {
> #include 
> #include 
> }
> int main(int argc, char **argv)
> {
>     DBG_("Start  : Compile time : " __DATE__" " __TIME__"\n");
>     SQLHENV env;
>     SQLCHAR driver[256];
>     SQLCHAR attr[256];
>     SQLSMALLINT driver_ret;
>     SQLSMALLINT attr_ret;
>     SQLUSMALLINT direction;
>     SQLRETURN ret;
> 
>     ret=SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env);
>     if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
>         cerr << "Failed to allocate handle" << endl;
>         return -1;
>     }
>     ret=SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) SQL_OV_ODBC3, 0);
>     if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
>         cerr << "Failed SQLSetEnvAttr" << endl;
>         return -1;
>     }
>     cout << env<     direction = SQL_FETCH_FIRST;
>     while(1)
>     {
>     ret = SQLDrivers(env, direction,
>                 driver, sizeof(driver),
> &driver_ret,
>                 attr, sizeof(attr), &attr_ret);
>         if(ret==SQL_NO_DATA) break;
>         printf("%s - %s\n", driver, attr);
>         if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata truncation\n");
>         direction = SQL_FETCH_NEXT;
>     }
>     return 0;
> }
> 
> 
> 


Have a nice weekend.
-H

-- 
Henning Follmann   | hfollm...@itcfollmann.com

Proprietary USB Drivers; Ya Gotta' Love'em.

[Martin McCormick]

This is an embedded usb serial port in a radio receiver which
works in MS Windows10 and I was hoping to write some control
routines for a Raspberry Pi running buster and it does the
following:

Sep 22 20:17:15 rpi2 kernel: [551843.541477] usb 1-1.2: new full-speed USB 
device number 6 using dwc_otg
Sep 22 20:17:16 rpi2 kernel: [551843.674681] usb 1-1.2: not running at top 
speed; connect to a high speed hub
Sep 22 20:17:16 rpi2 kernel: [551843.684432] usb 1-1.2: New USB device found, 
idVendor=0c26, idProduct=002b
Sep 22 20:17:16 rpi2 kernel: [551843.68] usb 1-1.2: New USB device strings: 
Mfr=1, Product=2, SerialNumber=3
Sep 22 20:17:16 rpi2 kernel: [551843.684452] usb 1-1.2: Product: IC-R30
Sep 22 20:17:16 rpi2 kernel: [551843.684460] usb 1-1.2: Manufacturer: Icom Inc.
Sep 22 20:17:16 rpi2 kernel: [551843.684468] usb 1-1.2: SerialNumber: IC-R30 
16002557
Sep 22 20:17:16 rpi2 kernel: [551843.727911] cdc_acm 1-1.2:1.0: Zero length 
descriptor references
Sep 22 20:17:16 rpi2 kernel: [551843.727940] cdc_acm: probe of 1-1.2:1.0 failed 
with error -22
Sep 22 20:17:16 rpi2 kernel: [551843.728056] usbcore: registered new interface 
driver cdc_acm
Sep 22 20:17:16 rpi2 kernel: [551843.728061] cdc_acm: USB Abstract Control 
Model driver for USB modems and ISDN adapters
Sep 22 20:21:11 rpi2 kernel: [552078.765119] usb 1-1.2: USB disconnect, device 
number 6

So much for that.  There is one other possibility.  It is
possible that one can go to one of the menu options and flip a
virtual switch that will take the serial data that should have
been on /dev/ttyACMx and put them on a logic-level serial line
that is accessible through the right stereo channel of a
3-conductor jack.  Whether or not that works is beyond the scope
of this list so my question is whether or not there is a wrapper
program of some kind in Linux that can fool an application like
the serial port module that tried to run here in to thinking that
it is home and among friends when it's really been kidnapped.

The possible use of a logic-level serial line is probably
what I will need to do but that means that if one resets the radio to
factory defaults, one will have to go in to the menus on
the radio's screen and restore the virtual switch setting.

As a computer user who happens to be blind, that's a major pain as
well as in a case where the radio is remotely located and one is
operating it headlessly.

I smiled a bit when reading the syslog admonition to
connect to a high-speed hub.  That would be quite a trick.

Thanks for any constructive suggestions.

Martin McCormick WB5AGZ

Re: Privacy and defamation of character on Debian public forums

[rhkramer]

On Friday, September 24, 2021 05:31:47 PM The Wanderer wrote:
> Based on what I've found in digging earlier, as well as the name
> mentioned by Andy Smith in his reply, I think it's probably
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899 - specifically.
> the first reply (comment 10).

Not replying specifically to The Wanderer, but just to this post which mentions 
that the message at issue is #10, and noting that message was not written by 
Chuck and instead written by someone from the Debian side at least partially 
"critiquiing" Chuck's message #5.

I've read over message #5, and without being a Debian developer or a user of 
Xen, aside from being a little longer / wordier than probably necessary, I 
don't see anything so objectionable about it.

I'm not sure which message Chuck wants deleted -- #5 or #10 (if either), but 
I'm not sure he has "standing" to ask that #10 be deleted -- it seems he would 
have to contact the writer of message #10 and ask him to ask that message #10 
be deleted.

Just my $0.02.

Re: USB sticks & Debian

[rhkramer]

On Friday, September 24, 2021 05:38:38 PM Bob Bernstein wrote:
> Is there a favored HOW-To or wiki page describing the care and
> feeding of USB sticks intended to boot a linux system into some
> other OS?

I don't understand what you are trying to do.  Do you want to:

   *  create a bootable USB on another OS to boot (the USB) and install Linux 
on some other system, or 

   * do you want to install a Linux OS in a virtual  on a Windows (or other non-Linux 
system), or 

   * something else?

Re: `aptitude update' won't update

[rhkramer]

On Saturday, September 25, 2021 08:32:26 AM Greg Wooledge wrote:
> When you're ready to upgrade to a newer stable release, you can read
> through the release notes, and take the time to perform the upgrade
> properly.

All replies I've seen so far mention this (reading (and following) the release 
notes, but I'd like to emphasize that.  I don't know about the transition from 
Buster to Bullseye, but many version upgrades have had what I would call 
"gotchas" that will get you if you don't follow the release notes.

Re: `aptitude update' won't update

[Greg Wooledge]

On Sat, Sep 25, 2021 at 09:08:55AM +, Rodolfo Medina wrote:
> Please help with this:

Andrew already covered some or most of this, but I think it bears
repeating.

> 
> deb http://ftp.uk.debian.org/debian/ stable main
> deb-src http://ftp.uk.debian.org/debian/ stable main
> 
> # non-free
> deb http://ftp.debian.org/debian/ stable main contrib non-free
> 
> #deb http://repository.spotify.com stable non-free
> 
> #deb [arch=amd64] https://repo.skype.com/deb stable main
> 

You should NEVER use the word "stable" (or "oldstable") in your
sources.list.  If you do this, you are quite likely to be caught by
surprise when a new release happens.

You should always use the actual release name that you're following,
such as "buster" or "bullseye".

When you're ready to upgrade to a newer stable release, you can read
through the release notes, and take the time to perform the upgrade
properly.

> # aptitude update
> Hit http://dl.google.com/linux/chrome/deb stable InRelease
> Get: 1 http://ftp.debian.org/debian stable InRelease [113 kB]
> Get: 2 http://ftp.uk.debian.org/debian stable InRelease [113 kB]
> E: Repository 'http://ftp.debian.org/debian stable InRelease' changed its
> 'Codename' value from 'buster' to 'bullseye'
> E: Repository 'http://ftp.uk.debian.org/debian stable InRelease' changed its
> 'Codename' value from 'buster' to 'bullseye'
> E: Failed to download some files
> W: Failed to fetch http://ftp.uk.debian.org/debian/dists/stable/InRelease: 
> W: Failed to fetch http://ftp.debian.org/debian/dists/stable/InRelease: 
> E: Some index files failed to download. They have been ignored, or old ones
> used instead.

The good news here is that, while the new release has caught you by
surprise, no actual damage has been done yet.  It aborted early in the
process, before any new packages had been installed.

At this point, assuming you've done nothing but post to this mailing list,
you are still running buster (Debian 10).  You still have the chance to
make a choice.  You can either remain on buster for a little while
longer, or you can upgrade to bullseye (Debian 11).

If you want to remain on buster, simply change all the occurrences of
"stable" to "buster" in your sources.list (which is how it should have
been in the first place).  Then do an "apt update", and you should be
good to go.

If you want to upgrade to bullseye, read the bullseye release notes
 and follow
the instructions in them.

As a matter of fact, one of the steps in the upgrade process will be
making sure you're up to date on buster first, so in *both* situations,
you will need to change your sources.list to point to "buster" before
doing anything else.

Re: `aptitude update' won't update

[Andrew M.A. Cater]

On Sat, Sep 25, 2021 at 09:08:55AM +, Rodolfo Medina wrote:
> Please help with this:
> 
> # aptitude update
> Hit http://dl.google.com/linux/chrome/deb stable InRelease
> Get: 1 http://ftp.debian.org/debian stable InRelease [113 kB]
> Get: 2 http://ftp.uk.debian.org/debian stable InRelease [113 kB]
> E: Repository 'http://ftp.debian.org/debian stable InRelease' changed its
> 'Codename' value from 'buster' to 'bullseye'
> E: Repository 'http://ftp.uk.debian.org/debian stable InRelease' changed its
> 'Codename' value from 'buster' to 'bullseye'
> E: Failed to download some files
> W: Failed to fetch http://ftp.uk.debian.org/debian/dists/stable/InRelease: 
> W: Failed to fetch http://ftp.debian.org/debian/dists/stable/InRelease: 
> E: Some index files failed to download. They have been ignored, or old ones
> used instead.
> 
> 
> My /etc/apt/sources.list:
> 
> 
> 
> deb http://ftp.uk.debian.org/debian/ stable main
> deb-src http://ftp.uk.debian.org/debian/ stable main
> 
> # non-free
> deb http://ftp.debian.org/debian/ stable main contrib non-free
> 
> #deb http://repository.spotify.com stable non-free
> 
> #deb [arch=amd64] https://repo.skype.com/deb stable main
> 
> 
> 
> Thanks in advance for any help...
> 
> Rodolfo
> 

This is a consequence of "stable" having moved from buster to bullseye as 
the release happened on 14th July.

This will mean quite a large update for you at one time.

First things first:

Check the output of 

less /etc/debian_version to make sure which version of Debian you are 
running at the moment. I'll assume that it is 10 or Buster.

Assuming that you were using buster and that this is the first update for a 
while 

Change your /etc/apt/sources.list to reference buster by name - where there
is stable, substitute the word buster.

That fixes you to buster for a short while for the purposes of the upgrade.
if you want to stay on buster for a while longer, stop here. 
Continue to update from buster - another point release should be happening
shortly.

== If you want to upgrade safely to bullseye / Debian 11

Do a final update to make sure that you have brought the machine up to date
on buster before changing anything further.

Change the /etc/apt/sources.list to refer to bullseye
Note that the format of the sources.list has changed with bullseye 
specifically round the format of the lines for updates from 
security.debian.org

See also https://wiki.debian.org/SourcesList which has the lines written
in full.

== Doing the upgrade ==

I can't do better than refer you to the release notes at 
https://www.debian.org/releases/bullseye/amd64/release-notes/index.en.html

The suggestion there is to use apt rather than aptitude in this specific
instance of upgrading from one full release to another.

apt update ; apt upgrade -- without-new pkgs ; apt full-upgrade

You may want to retain the codename in /etc/apt/sources.list rather
than "stable" - this prevents this sort of large surprise if there's a 
release as references by codename would track the release as it moves from 
testing -> stable -> oldstable, for example.

Hope this helps,

With every good wish, as ever,

Andy Cater

Re: Debian 11: Nvidia NVS 310 with nvidia driver freezes after two days

[Roger Price]

On Tue, 21 Sep 2021, Roger Price wrote:


   Nvidia drivers
   --

Card Quadro 4000, GF100GL. 390.144.  Freezes with blank monitors after 15 
minutes. Card temperature 85C.


Card NVS 310. 390.144.  Freezes with monitors lit after 15 mins - 3 hours.

Card Quadro P400, GP107GL. 460.91.  Card temperature 46C.  Freezes with blank 
monitors before 30 mins.


   Current situation
   -

I wondered if a common feature of all the freezing was the automatic screen 
saver failing, so I installed xscreensaver and configured it to start saving 
my screen after 10 mins inactivity with the Quadro P400 card + 490.91 driver. 
This has so far held up for 22 hours.  If it holds up for a week, I will 
report it as a candidate workaround.


The workaround has held up for 5 days.  I use xscreensaver options "Only One 
Screen Saver", "SlideScreen", Blank after 10 minutes, No lock screen, No Display 
Power Management.  This keeps the monitors busy.


I tried turning on Display Power Management and ended up with frozen 
monitors.


It looks as if the nvidia driver 460.91 (and other versions) breaks when 
attempting to save energy with iiyama 2783QSU monitors.


Roger

`aptitude update' won't update

[Rodolfo Medina]

Please help with this:

# aptitude update
Hit http://dl.google.com/linux/chrome/deb stable InRelease
Get: 1 http://ftp.debian.org/debian stable InRelease [113 kB]
Get: 2 http://ftp.uk.debian.org/debian stable InRelease [113 kB]
E: Repository 'http://ftp.debian.org/debian stable InRelease' changed its
'Codename' value from 'buster' to 'bullseye'
E: Repository 'http://ftp.uk.debian.org/debian stable InRelease' changed its
'Codename' value from 'buster' to 'bullseye'
E: Failed to download some files
W: Failed to fetch http://ftp.uk.debian.org/debian/dists/stable/InRelease: 
W: Failed to fetch http://ftp.debian.org/debian/dists/stable/InRelease: 
E: Some index files failed to download. They have been ignored, or old ones
used instead.


My /etc/apt/sources.list:



deb http://ftp.uk.debian.org/debian/ stable main
deb-src http://ftp.uk.debian.org/debian/ stable main

# non-free
deb http://ftp.debian.org/debian/ stable main contrib non-free

#deb http://repository.spotify.com stable non-free

#deb [arch=amd64] https://repo.skype.com/deb stable main



Thanks in advance for any help...

Rodolfo

Re: Postgresql ODBC driver not found

[Pierre Couderc]

On 9/24/21 5:31 PM, Henning Follmann wrote:


and I see you do not do any error checking.
This would be a first step to find out where it fails.

I added some code...



You hare fully right, I have corrected, but I have the same result and 
no more idea.. :


nous@pcouderc:~/projets//build$ ./ttest
D  0.0:ln 19:main(): Start  : Compile time : Sep 25 2021 09:03:28

0x55cee70a5ed0



nous@pcouderc:~/projets//build$ cat ../main.cpp
#include 
#include 
#include 
#pragma GCC diagnostic ignored "-Wendif-labels"
#pragma GCC diagnostic ignored "-Wwrite-strings"


#define TDBG clock_t ttdbg=clock();float 
ftdbg=((float)ttdbg)/CLOCKS_PER_SEC;
#define DBG_(fmt, args...) {TDBG fprintf(stdout,string( 
string("D%5.1f:ln %d:%s(): ")+fmt).c_str(),ftdbg,__LINE__, __func__, 
##args);fflush(stdout);}


using namespace std;
extern "C"
{
#include 
#include 
}
int main(int argc, char **argv)
{
    DBG_("Start  : Compile time : " __DATE__" " __TIME__"\n");
    SQLHENV env;
    SQLCHAR driver[256];
    SQLCHAR attr[256];
    SQLSMALLINT driver_ret;
    SQLSMALLINT attr_ret;
    SQLUSMALLINT direction;
    SQLRETURN ret;

    ret=SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env);
    if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
        cerr << "Failed to allocate handle" << endl;
        return -1;
    }
    ret=SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void *) 
SQL_OV_ODBC3, 0);

    if (ret != SQL_SUCCESS && ret != SQL_SUCCESS_WITH_INFO) {
        cerr << "Failed SQLSetEnvAttr" << endl;
        return -1;
    }
    cout << env<                driver, sizeof(driver), 
&driver_ret,

                attr, sizeof(attr), &attr_ret);
        if(ret==SQL_NO_DATA) break;
        printf("%s - %s\n", driver, attr);
        if (ret == SQL_SUCCESS_WITH_INFO) printf("\tdata 
truncation\n");

        direction = SQL_FETCH_NEXT;
    }
    return 0;
}