"Stopped (with error) /dev/dm-0"

[Curt]

Failed  "Stopped (with error) /dev/dm-0"

At every shutdown; looks like another oldie but goodie bug affecting
those with encrypted swap (maybe some kind or race condition, if that is
indeed the proper term).

Having said that, filesystems are unmounted cleanly (no fsck at reboot,
although the shutdown routine stops at "Power down" and I must pull the
plug--a recurrent problem I've had before encryption in Wheezy).

Is it harmless? 

-- 
“True terror is to wake up one morning and discover that your high school class
is running the country.” – Kurt Vonnegut

Re: "Stopped (with error) /dev/dm-0"

[Henrique de Moraes Holschuh]

On Mon, 05 Feb 2018, Curt wrote:
> At every shutdown; looks like another oldie but goodie bug affecting
> those with encrypted swap (maybe some kind or race condition, if that is
> indeed the proper term).

Incorrect sequencing, actually.  But if this is ephemeral swap (or
ephemeral *anything*), it is a very minor bug at most.

Ephemeral would mean mounted on tmpfs (RAM), or with a throw-away
(random single-use) crypto key.

> Having said that, filesystems are unmounted cleanly (no fsck at reboot,
> although the shutdown routine stops at "Power down" and I must pull the
> plug--a recurrent problem I've had before encryption in Wheezy).

That's a kernel + platform bug.  Updating your BIOS/UEFI might fix it,
otherwise, it requires messing with kernel command line parameters until
you find the poweroff strategy that works, and reporting a bug to get
that into a quirk list inside the kernel.

-- 
  Henrique Holschuh

Re: policy around 'wontfix' bug tag

[Vincent Lefevre]

On 2018-02-04 08:22:23 -0500, Michael Stone wrote:
> On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote:
> > In which case, it should refuse to accept '4/2/2018' at all, right?
> 
> It can't, that would break working scripts. This is the heart of the
> problem: we know the parser is horrible, confusing, and irregular, but any
> attempt to change it will break lots of stuff that depends on the current
> brokenness.

It is not rare that the behavior of utilities change and break
scripts. So, why not here, in particular for a good reason?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: policy around 'wontfix' bug tag

[Vincent Lefevre]

On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> On 05/02/18 01:44, Nicolas George wrote:
> >> PS - please don't cc me; I'm on the list.
> > Done this once, but I cannot promise I will think of it later. Document
> > your preference in your mail mail header, the standard way, so that it
> > is automatic and works for everybody, just like I did. Too bad the list
> > software is not properly configured to do that automatically.
> 
> My preference is for any personal replies addressed to me to go to me,
> and I'd use the Reply-to header (as intended) if I needed it to go
> somewhere else. But replies to the list should go to the list (only)
> (unless otherwise requested), as per list policy.

You should set up a "Mail-Followup-To:" for that. This is entirely
your problem.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: policy around 'wontfix' bug tag

[Roberto C . Sánchez]

On Mon, Feb 05, 2018 at 02:07:47PM +0100, Vincent Lefevre wrote:
> On 2018-02-04 08:22:23 -0500, Michael Stone wrote:
> > On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote:
> > > In which case, it should refuse to accept '4/2/2018' at all, right?
> > 
> > It can't, that would break working scripts. This is the heart of the
> > problem: we know the parser is horrible, confusing, and irregular, but any
> > attempt to change it will break lots of stuff that depends on the current
> > brokenness.
> 
> It is not rare that the behavior of utilities change and break
> scripts. So, why not here, in particular for a good reason?
> 
It is equally common, perhaps even more so, that buggy behavior is
retained (especially if it is not harmful) and that "correct" behavior
require a switch or setting.  I am not personally affected by this, as
far as I know, but as a software developer I can certainly understand
wanting to retain backward compatibility, even when it is buggy.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: "Stopped (with error) /dev/dm-0"

[Curt]

On 2018-02-05, Henrique de Moraes Holschuh  wrote:
> On Mon, 05 Feb 2018, Curt wrote:
>> At every shutdown; looks like another oldie but goodie bug affecting
>> those with encrypted swap (maybe some kind or race condition, if that is
>> indeed the proper term).
>
> Incorrect sequencing, actually.  But if this is ephemeral swap (or
> ephemeral *anything*), it is a very minor bug at most.

Incorrect sequencing**, gotcha. 

> Ephemeral would mean mounted on tmpfs (RAM), or with a throw-away
> (random single-use) crypto key.
>

I believe it's random, single-use crypto key in my case.

('einstein kernel: Adding 6915068k swap on /dev/mapper/cryptswap1')

>> Having said that, filesystems are unmounted cleanly (no fsck at reboot,
>> although the shutdown routine stops at "Power down" and I must pull the
>> plug--a recurrent problem I've had before encryption in Wheezy).
>
> That's a kernel + platform bug.  Updating your BIOS/UEFI might fix it,
> otherwise, it requires messing with kernel command line parameters until
> you find the poweroff strategy that works, and reporting a bug to get
> that into a quirk list inside the kernel.
>

I think this machine is too ancient for a BIOS update.

Thank you.

** Creating an /etc/asound.conf (to define a default sound card) and
rebooting made the machine hang for such an extended period during the
boot sequence that I ctrl alt del into recovery mode and deleted the
newly created file. Upon rebooting once more things had returned to
normal again--unless I'm nuts. (Maybe this has nothing to do with
sequencing.)  

-- 
“True terror is to wake up one morning and discover that your high school class
is running the country.” – Kurt Vonnegut

Re: policy around 'wontfix' bug tag

[Vincent Lefevre]

On 2018-02-05 08:12:21 -0500, Roberto C. Sánchez wrote:
> On Mon, Feb 05, 2018 at 02:07:47PM +0100, Vincent Lefevre wrote:
> > On 2018-02-04 08:22:23 -0500, Michael Stone wrote:
> > > On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote:
> > > > In which case, it should refuse to accept '4/2/2018' at all, right?
> > > 
> > > It can't, that would break working scripts. This is the heart of the
> > > problem: we know the parser is horrible, confusing, and irregular, but any
> > > attempt to change it will break lots of stuff that depends on the current
> > > brokenness.
> > 
> > It is not rare that the behavior of utilities change and break
> > scripts. So, why not here, in particular for a good reason?
> > 
> It is equally common, perhaps even more so, that buggy behavior is
> retained (especially if it is not harmful) and that "correct" behavior
> require a switch or setting.  I am not personally affected by this, as
> far as I know, but as a software developer I can certainly understand
> wanting to retain backward compatibility, even when it is buggy.

It might be harmful because one silently gets a wrong date.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 08:11, Vincent Lefevre wrote:

> On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> 
>> On 05/02/18 01:44, Nicolas George wrote:

>>> Done this once, but I cannot promise I will think of it later.
>>> Document your preference in your mail mail header, the standard
>>> way, so that it is automatic and works for everybody, just like I
>>> did. Too bad the list software is not properly configured to do
>>> that automatically.
>> 
>> My preference is for any personal replies addressed to me to go to
>> me, and I'd use the Reply-to header (as intended) if I needed it to
>> go somewhere else. But replies to the list should go to the list
>> (only) (unless otherwise requested), as per list policy.
> 
> You should set up a "Mail-Followup-To:" for that. This is entirely
> your problem.

That does seem to be the trend and position of the world, especially in
recent years, but I disagree as a matter of philosophy.

A mailing list whose subscribers can post to it is a discussion forum.

Replies to a message which was posted to a discussion forum should, by
default, go back to that forum. If the poster wants the replies to go
somewhere else, it is that poster's responsibility to indicate this
fact, whether by message headers, signature comments, explicit
statements in the body of the message, or some other means.

This is just as true of offline fora as of online ones.

Usenet got this right, IMO, and so did all the mailing lists I remember
participating in back before Web fora became a vaguely-viable thing. I
consider it a sad thing that the precedent established there seems to
have been abandoned since that time.

-- 
   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: policy around 'wontfix' bug tag

[Curt]

On 2018-02-05, Roberto C  Sánchez  wrote:
>> 
>> It is not rare that the behavior of utilities change and break
>> scripts. So, why not here, in particular for a good reason?
>> 
> It is equally common, perhaps even more so, that buggy behavior is
> retained (especially if it is not harmful) and that "correct" behavior
> require a switch or setting.  I am not personally affected by this, as
> far as I know, but as a software developer I can certainly understand
> wanting to retain backward compatibility, even when it is buggy.

That's certainly why all bona fide linux hackers in the know commiserate
so readily with Windows' bug compatibility "features".

;-)

Or maybe I should have said, *afin de mettre tout le monde d'accord*,
that the principle of bug compatibility taken to facetious extremes gets
you the entomological leviathan that is Windows.

> Regards,
>
> -Roberto
>


-- 
“True terror is to wake up one morning and discover that your high school class
is running the country.” – Kurt Vonnegut

Re: policy around 'wontfix' bug tag

[Vincent Lefevre]

On 2018-02-05 08:40:27 -0500, The Wanderer wrote:
> On 2018-02-05 at 08:11, Vincent Lefevre wrote:
> > On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> >> My preference is for any personal replies addressed to me to go to
> >> me, and I'd use the Reply-to header (as intended) if I needed it to
> >> go somewhere else. But replies to the list should go to the list
> >> (only) (unless otherwise requested), as per list policy.
> > 
> > You should set up a "Mail-Followup-To:" for that. This is entirely
> > your problem.
> 
> That does seem to be the trend and position of the world, especially in
> recent years, but I disagree as a matter of philosophy.
> 
> A mailing list whose subscribers can post to it is a discussion forum.

However, for debian-user, non-subscribers can also post. So, for mail
without a "Mail-Followup-To:", it may be difficult to do the "right"
thing automatically.

> Replies to a message which was posted to a discussion forum should, by
> default, go back to that forum. If the poster wants the replies to go
> somewhere else, it is that poster's responsibility to indicate this
> fact, whether by message headers, signature comments, explicit
> statements in the body of the message, or some other means.

I would say that to avoid ambiguities, in any case, the poster should
use a "Mail-Followup-To:" to indicate what he wants (unless he doesn't
care).

Just like for "date -d", ambiguities should always be avoided.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: policy around 'wontfix' bug tag

[rhkramer]

On Monday, February 05, 2018 08:07:47 AM Vincent Lefevre wrote:
> On 2018-02-04 08:22:23 -0500, Michael Stone wrote:
> > On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote:
> > > In which case, it should refuse to accept '4/2/2018' at all, right?
> > 
> > It can't, that would break working scripts. This is the heart of the
> > problem: we know the parser is horrible, confusing, and irregular, but
> > any attempt to change it will break lots of stuff that depends on the
> > current brokenness.
> 
> It is not rare that the behavior of utilities change and break
> scripts. So, why not here, in particular for a good reason?

I'm not really going to answer the question, I think MIke Stone has answered 
it for you.  The way forward would seem (to me) to be to create a new date 
function (ndate?) (or a new option to date) that provides the desired better 
functionality.

I assume (I know) that the license for date is some free / open source license 
that would allow you to incorporate the old code into a new function (probably 
with appropriate citation / credit) and then add / modify / delete code as 
desired.

OK, I will say one thing--I suspect this is something like the (forget what 
they called it)--the year 2000 problem--there is code that people (and 
companies depend on) that is so old that the maintainers are long gone, thus 
breaking that old function wouild be a very bad thing.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 08:40:27 (-0500), The Wanderer wrote:
> On 2018-02-05 at 08:11, Vincent Lefevre wrote:
> 
> > On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> > 
> >> On 05/02/18 01:44, Nicolas George wrote:
> 
> >>> Done this once, but I cannot promise I will think of it later.
> >>> Document your preference in your mail mail header, the standard
> >>> way, so that it is automatic and works for everybody, just like I
> >>> did. Too bad the list software is not properly configured to do
> >>> that automatically.
> >> 
> >> My preference is for any personal replies addressed to me to go to
> >> me, and I'd use the Reply-to header (as intended) if I needed it to
> >> go somewhere else. But replies to the list should go to the list
> >> (only) (unless otherwise requested), as per list policy.
> > 
> > You should set up a "Mail-Followup-To:" for that. This is entirely
> > your problem.
> 
> That does seem to be the trend and position of the world, especially in
> recent years, but I disagree as a matter of philosophy.
> 
> A mailing list whose subscribers can post to it is a discussion forum.
> 
> Replies to a message which was posted to a discussion forum should, by
> default, go back to that forum. If the poster wants the replies to go
> somewhere else, it is that poster's responsibility to indicate this
> fact, whether by message headers, signature comments, explicit
> statements in the body of the message, or some other means.
> 
> This is just as true of offline fora as of online ones.
> 
> Usenet got this right, IMO, and so did all the mailing lists I remember
> participating in back before Web fora became a vaguely-viable thing. I
> consider it a sad thing that the precedent established there seems to
> have been abandoned since that time.

If it really worries you, the answer might be ~/.procmailrc and

:0 Wh: $HOME/msgid.lock
| formail -D 19 $HOME/msgid.cache

I used it for years.

Cheers,
David.

Re: policy around 'wontfix' bug tag

[Greg Wooledge]

On Sun, Feb 04, 2018 at 04:04:34PM +0100, Nicolas George wrote:
> All you describe is convenience for programmatic use. As I explained,
> this parser is meant for interactive use.

What on EARTH made you think THAT?

I promise you, people ARE using date -d '...' in shell scripts.
LOTS of people.  Hell, I've done it.(*)

If I'm a human working in an interactive shell, and I want to see "the
date of the Sunday that occurred in the previous week", I will simply
run cal(1) instead.  (Or for that specific example on this specific
day, "cal 1 2018" or even "cal 2018".)  It's a lot easier than trying
to guess which recipe you can put into date -d to get the same result.


(*) One specific shell script use case was "Get the last date of a given
month."  Now, obviously you can just set up an array of hard-coded month
ending dates, and then write a function to determine whether the current
year is a leap year for the February case.  But if you want to do it with
GNU date -d, then you have to guess a magic incantation that actually
works.  Usually by trial and error.

Anyway, here's what I came up with:

lastday() {
date +%Y-%m-%d -d "$1 1 day ago + 1 month"
}

Testing:

wooledg:~$ lastday 2016-03-01
2016-03-31
wooledg:~$ lastday 2016-02-01
2016-02-29
wooledg:~$ lastday 2016-01-01
2016-01-31
wooledg:~$ lastday 2000-02-01
2000-02-29
wooledg:~$ lastday 2001-02-01
2001-02-28
wooledg:~$ lastday 2100-02-01
2100-02-28
wooledg:~$ lastday 2100-03-01
2100-03-31

How does it work?  Who knows!  But it seems to work.  It correctly
handles the oddball corner cases like Feb 2100 (which is not a leap
year), and the March-that-follows-a-leap-day as well as the
March-that-does-not-follow-a-leap-day.  So that is where I left it.

That was written a long time ago.  In newer projects, I have generally
gone with the hard-coded array + is_leap_year function (but not in
bash).

Re: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 08:58, Vincent Lefevre wrote:

> On 2018-02-05 08:40:27 -0500, The Wanderer wrote:
> 
>> On 2018-02-05 at 08:11, Vincent Lefevre wrote:

>>> You should set up a "Mail-Followup-To:" for that. This is
>>> entirely your problem.
>> 
>> That does seem to be the trend and position of the world,
>> especially in recent years, but I disagree as a matter of
>> philosophy.
>> 
>> A mailing list whose subscribers can post to it is a discussion
>> forum.
> 
> However, for debian-user, non-subscribers can also post. So, for
> mail without a "Mail-Followup-To:", it may be difficult to do the
> "right" thing automatically.

Even for replies to messages posted by non-subscribers, replying back to
the forum by default is still the right thing to do.

If the poster wants to receive replies, it is the poster's
responsibility to do something to cause that to happen. That can take
the form of subscribing, or of setting mail headers, or of saying
"please CC me on replies", or simply of reading the replies in an online
archive or mirror of the mailing list. If the poster does not do such a
thing, then it should be presumed that the poster does not care about
receiving replies.

>> Replies to a message which was posted to a discussion forum should,
>> by default, go back to that forum. If the poster wants the replies
>> to go somewhere else, it is that poster's responsibility to
>> indicate this fact, whether by message headers, signature comments,
>> explicit statements in the body of the message, or some other
>> means.
> 
> I would say that to avoid ambiguities, in any case, the poster
> should use a "Mail-Followup-To:" to indicate what he wants (unless he
> doesn't care).

A: I do not see any way to achieve what I want via this mechanism.
(Especially given the variety of mailing lists to which I subscribe, and
the lack of ability to specify automatic headers dynamically that way in
any mail client with which I'm familiar.)

B: That would not bear on the question of the default. The default is
what happens when no special action is taken. If I have to take action
(in the form of ensuring that that header is set) to cause the desired
behavior to occur, then the desired behavior is not the default.

> Just like for "date -d", ambiguities should always be avoided.

It is part of my philosophy that unintentional ambiguity is anathema,
but I don't see the ambiguity here. This is just a case of disagreement
about what the default should be; each possible default is perfectly
self-consistent and produces unambiguous results as far as I can tell,
it's just that they aren't compatible with one another.

-- 
   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: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 09:32, David Wright wrote:

> On Mon 05 Feb 2018 at 08:40:27 (-0500), The Wanderer wrote:
> 
>> On 2018-02-05 at 08:11, Vincent Lefevre wrote:

>>> You should set up a "Mail-Followup-To:" for that. This is
>>> entirely your problem.
>> 
>> That does seem to be the trend and position of the world,
>> especially in recent years, but I disagree as a matter of
>> philosophy.
>> 
>> A mailing list whose subscribers can post to it is a discussion
>> forum.
>> 
>> Replies to a message which was posted to a discussion forum should,
>> by default, go back to that forum. If the poster wants the replies
>> to go somewhere else, it is that poster's responsibility to
>> indicate this fact, whether by message headers, signature comments,
>> explicit statements in the body of the message, or some other
>> means.
>> 
>> This is just as true of offline fora as of online ones.
>> 
>> Usenet got this right, IMO, and so did all the mailing lists I
>> remember participating in back before Web fora became a
>> vaguely-viable thing. I consider it a sad thing that the precedent
>> established there seems to have been abandoned since that time.
> 
> If it really worries you, the answer might be ~/.procmailrc and

Unfortunately, I do not have my mail system set up such that mail passes
through a local procmail instance before it reaches me. My mail client
pulls mail directly from the remote server.

I am theoretically interested in the possibility of setting things up to
change that, but it's very much a back-burner low-priority interest,
which has never risen to the level of even figuring out how to start on
the actual project.

> :0 Wh: $HOME/msgid.lock
> | formail -D 19 $HOME/msgid.cache
> 
> I used it for years.

I don't parse this well enough to understand what it would do, and I
don't know where to find a procmail reference which would let me read up
on it easily enough to understand quickly. Could you clarify?

-- 
   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: policy around 'wontfix' bug tag

[Greg Wooledge]

On Mon, Feb 05, 2018 at 09:11:23AM -0500, rhkra...@gmail.com wrote:
> I assume (I know) that the license for date is some free / open source 
> license 

No need to guess.  You can ask it.

wooledg:~$ date --version
date (GNU coreutils) 8.26
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

Re: policy around 'wontfix' bug tag

[Michael Stone]

On Mon, Feb 05, 2018 at 09:11:23AM -0500, rhkra...@gmail.com wrote:

I assume (I know) that the license for date is some free / open source license
that would allow you to incorporate the old code into a new function (probably
with appropriate citation / credit) and then add / modify / delete code as
desired.

OK, I will say one thing--I suspect this is something like the (forget what
they called it)--the year 2000 problem--there is code that people (and
companies depend on) that is so old that the maintainers are long gone, thus
breaking that old function wouild be a very bad thing.


IIRC it started out as a YACC function in the late 80s, and is now a 
Bison (YACC+GNU extensions) library. There are still people who work on 
it--the debug option added a couple of years ago has made it *much* 
easier to understand why it does the things that it does. I'm not sure 
that if I were implementing a new option I'd use the bison code at all 
(it does probably limit the contributor pool). The bigger issues aren't 
the choice of implementation language, they're 1) getting buy-in on what 
the replacement should look like and 2) getting people to use something 
different. It's tough, because almost every linux system out there has 
date(1) with the existing -d parser, and it's easier to assume that's 
there than to use something else. (E.g., it's possible to use python or 
perl or other scripting language one-liners with any number of date 
libraries to add much more maintainable date handling to their scripts, 
but most people just stick with the date(1) they know rather than using 
one of the alternatives.)


Mike Stone

Re: /lib/lsb/init-functions on LXC servers

[Harald Dunkel]

Hi Reco,

you mean this is a known issue???

Harri

Can't get my video card running

[Erkko Lahnajärvi]

Hi,


I fetched a new computer few days ago. The equipment are:

Motherboard: Gigabyte AB350-Gaming
CPU: Amd Ryzen 3 1300x
RAM: 16Gb
Video card: GeForce GTX 1050 Ti
Hard disk: WD green 240 Gb

On this computer I installed Debian-9.3.0-amd64.
I've first tried to install the video card. I found a particular driver for
Linux from Ndivia's website. And then I bigan to install it...

Filename: NVIDIA-Linux-x86_64-375.20.run

I ran the file in Konsole, but then installation started to ask me packages
I should install first.

First ask: 'gcc' -package, I installed it, another try to install -> didn't
get through
Second ask: 'make' -package, installed that too, another try to install
VC-driver -> didn't get through
Third ask: [some package which I don't remember!!??],installed that too,
another try to install VC-driver -> didn't get through
Fourth ask: 'kernel-source or kernel-devel RPM' or define
'--kernel-source-path

But my src folder does not contain kernel-source. From which folder should
I look the kernel-source?

Then I tried some guides from web:

https://linuxconfig.org/how-to-install-the-latest-nvidia-drivers-on-debian-9-stretch-linux

I did as I was ordered in the pages and restarted my computer. But after
that everything seems to be the same. From where can I set resolution and
other videocard adjustments?

How could I install my video card in first place?


-- 
Friendly regards

Erkko Lahnajärvi

Re: policy around 'wontfix' bug tag

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
> On 2018-02-05 at 09:32, David Wright wrote:

[...]

> > :0 Wh: $HOME/msgid.lock
> > | formail -D 19 $HOME/msgid.cache
> > 
> > I used it for years.
> 
> I don't parse this well enough to understand what it would do, and I
> don't know where to find a procmail reference which would let me read up
> on it easily enough to understand quickly. Could you clarify?

The trick is in formail (contained in the package procmail). Formail is
a pretty generic mail parser which can be used to filter mails (or parts
of mails) according to different criteria. Option -D instructs it to set
up a Message-ID cache to drop duplicate mails (duplicate in the sense of
Message-ID, that is). The number after the -D limits the cache's length.

As a careful guy, I have this:

  :0 Whc: msgid.lock
  | formail -D 8192 ~/.procmail/msgid.cache
  
  :0 a:
  duplicates

The 'c' in the first recipe lets a copy "pass through". The second
rule triggers on successful execution of the first one (i.e. a cache
hit, "this was a duplicate") and drops the duplicate into the mailbox
duplicates, where I can check whether something went wrong. Needless
to say, I haven't had to check in the last ten years, but disk space
is cheap :)

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlp4c5cACgkQBcgs9XrR2ka+bgCfd/ZKJyaLEAqNNgDHtMcs+a43
jE4An1QkauXZ10+quCxvwIY1nBskMtM9
=YnjT
-END PGP SIGNATURE-

Re: Causes, cures and prevention of orphaned inodes?

[Stephen P. Molnar]

On Mon, 2018-02-05 at 07:37 +0100, deloptes wrote:
> Stephen P. Molnar wrote:
> 
> > Can anyone give me some guidance in what I should be looking
> > for?  It
> > would be much appreciated.
> > From my experience most probably inappropriate shutdown (no unmount
> > when
> 
> shutdown).
> How do you shutdown your machine?
> Can you try without systemd (just install sysvinit and add to the
> kernel
> cmdline at boot: init=/lib/sysvinit/init)
> 
> regards
> 
> 
I am always greatful for the great advice, freely given by the folks
reading the Debian-users list. 

I always shut down the system with the Shutdown command.  The only
exception would be a locked system, which is the only recourse I know
of for orphaned inodes?

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Causes, cures and prevention of orphaned inodes?

[Stephen P. Molnar]

On Sun, 2018-02-04 at 20:45 -0500, Gene Heskett wrote:
> On Sunday 04 February 2018 15:49:36 Stephen P. Molnar wrote:
> 
> > I am running Debian Stretch on am eight thread AMD GPU platform.
> > Lately, it seems if I have been plagued by surfeit of orphaned
> nodes.
> >
> > I have goggled the causes. cures and prevention, but have gotten no
> > results that make any sense to me. I've been using computer since
> the
> > early 1960's but am an organic chemist by training and experience,
> not
> > a hardware expert.
> >
> > At first I though it might be impending hard drive failure as I
> > started receiving warning messages from the OS, but installing a
> brand
> > new drive has not solved the problem,  They seem to happen when I
> am
> > running  four or more apps at the same time. I have 8GB of RAM in
> the
> > system.
> >
> > I've installed several tools, lscup and lsh, but in all candor I
> don't
> > have the faintest idea what to make of the results. I'm not even
> sure
> > if the results have any application to solutions for the problem.
> >
> > Can anyone give me some guidance in what I should be looking
> for?  It
> > would be much appreciated.
> >
> > Thanks in advance.
> 
> Are you perchance running clamav? version 99.3's first release about
> 2 
> weeks back used up the available unix sockets, bricking the machine
> till 
> a reboot, wash, rinse, repeat. A new 99.3 has fixed that, but until
> that 
> filters thru the distro channels, you should shut clamav down. So I 
> have, and have commented out, the calls to inspect incoming emails
> out 
> of my .procmailrc.
> 
> 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)
> Genes Web page 
> 

Thanks for the suggestion.

No. I'm not using clamav.
-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 10:09, to...@tuxteam.de wrote:

> On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
>
>> On 2018-02-05 at 09:32, David Wright wrote:
> 
> [...]
> 
>> > :0 Wh: $HOME/msgid.lock
>> > | formail -D 19 $HOME/msgid.cache
>> > 
>> > I used it for years.
> 
>> I don't parse this well enough to understand what it would do, and I
>> don't know where to find a procmail reference which would let me read up
>> on it easily enough to understand quickly. Could you clarify?
> 
> The trick is in formail (contained in the package procmail). Formail is
> a pretty generic mail parser which can be used to filter mails (or parts
> of mails) according to different criteria. Option -D instructs it to set
> up a Message-ID cache to drop duplicate mails (duplicate in the sense of
> Message-ID, that is). The number after the -D limits the cache's length.

That wouldn't produce the behavior I want, though. Whether or not a
"duplicate" private copy (or probably not actually duplicate, since
mailing lists tend to modify other headers while leaving Message-ID
alone) is inappropriate depends on context, and specifically, primarily
on the sender's intent.

There can be legitimate reasons to send a message both to mailing list
and to a named recipient who is also subscribed to that list.

For example, consider a high-volume mailing list, where many subscribers
read only part of the traffic.

If there's an ongoing discussion on that mailing list, and one of the
participants wants to draw in a third person who also subscribes, it's
entirely appropriate to CC a reply to that third party.

However, if this were to happen with me, I would not want to receive
*only* the mailing-list copy. I would want to receive both: the
mailing-list copy to go into my local archive of the mailing list (and
to be present in the mailing list's folder, so that it appears properly
threaded with other replies), and the direct copy to draw my attention
to the subject. (Although I would probably then seek out the
mailing-list copy and reply to that. But that's a personal
idiosyncrasy.)

There are other possible complexifying scenarios, which distort the
picture in other directions, but I don't have them ready to mind right
now.

What it boils down to is that dropping duplicate messages is only always
appropriate when they are *complete* duplicates, in all headers (except
possibly things like transmission path history). With a mailing list,
that's rarely if ever the case.

-- 
   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: Causes, cures and prevention of orphaned inodes?

[Stephen P. Molnar]

On Mon, 2018-02-05 at 08:03 +0900, Mark Fletcher wrote:
> On Sun, Feb 04, 2018 at 03:49:36PM -0500, Stephen P. Molnar wrote:
> > I am running Debian Stretch on am eight thread AMD GPU platform.
> > Lately, it seems if I have been plagued by surfeit of orphaned
> > nodes.
> > 
> > I have goggled the causes. cures and prevention, but have gotten no
> > results that make any sense to me. I've been using computer since
> > the
> > early 1960's but am an organic chemist by training and experience,
> > not
> > a hardware expert.
> > 
> 
> The problem may not be hardware. From reading the details you
> provided, 
> it looks like you are using ext4 filesystems on your disks. Is that 
> correct? We occasionally get people on here reporting problems with
> more 
> esoteric / exotic file systems (cue the cries of protest from
> various 
> corners that super-duper-dijeridoo-fs isn't exotic, and that I'm a 
> dinosaur) but ext4 is in very wide use and as far as I know, stable.
> 
> Anyway worth confirming what filesystem(s) is/are actually on the
> disks 
> where orphaned inodes are occurring. If it is something more
> unusual, 
> you might have found a bug in the filesystem. Also, do you use 
> encryption on your disks eg LUKS?
> 
> Just a couple of thoughts
> 
> Mark.


I appreciate your suggestion.

Here are the results of blkid:

Installed drives:
root@AbNormal:/home/comp# blkid
/dev/sda1: UUID="8fa0b985-70ca-4d3e-a448-1a419d8b078b" TYPE="ext4" 
PARTUUID="b5226506-01"
/dev/sda5: UUID="3d0d7ebe-26f4-4f0e-be01-dca7ce9c9132" TYPE="swap" 
PARTUUID="b5226506-05"
/dev/sdb1: UUID="d65867da-c658-4e35-928c-9dd2d6dd5742" TYPE="ext4" 
PARTUUID="0003d403-01"
/dev/sdb2: UUID="007c1f16-34a4-438c-9d15-e3df601649ba" TYPE="ext4" 
PARTUUID="0003d403-02"

External USB Thumb drive:
root@AbNormal:/home/comp# blkid
/dev/sda1: UUID="8fa0b985-70ca-4d3e-a448-1a419d8b078b" TYPE="ext4" 
PARTUUID="b5226506-01"
/dev/sda5: UUID="3d0d7ebe-26f4-4f0e-be01-dca7ce9c9132" TYPE="swap" 
PARTUUID="b5226506-05"
/dev/sdb1: UUID="d65867da-c658-4e35-928c-9dd2d6dd5742" TYPE="ext4" 
PARTUUID="0003d403-01"
/dev/sdb2: UUID="007c1f16-34a4-438c-9d15-e3df601649ba" TYPE="ext4" 
PARTUUID="0003d403-02"
/dev/sdc1: UUID="28C1-0F73" TYPE="vfat"

External Backup drive:
root@AbNormal:/home/comp# blkid
/dev/sda1: UUID="8fa0b985-70ca-4d3e-a448-1a419d8b078b" TYPE="ext4" 
PARTUUID="b5226506-01"
/dev/sda5: UUID="3d0d7ebe-26f4-4f0e-be01-dca7ce9c9132" TYPE="swap" 
PARTUUID="b5226506-05"
/dev/sdb1: UUID="d65867da-c658-4e35-928c-9dd2d6dd5742" TYPE="ext4" 
PARTUUID="0003d403-01"
/dev/sdb2: UUID="007c1f16-34a4-438c-9d15-e3df601649ba" TYPE="ext4" 
PARTUUID="0003d403-02"
/dev/sdc1: LABEL="Seagate Expansion Drive" UUID="F0DAF608DAF5CABC" TYPE="ntfs" 
PARTUUID="6cccaf93-01"

However, I usually gt et the orphaned inodes where there are no exteranl drives 
mounted.

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Causes, cures and prevention of orphaned inodes?

[Stephen P. Molnar]

On Sun, 2018-02-04 at 23:06 -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 04 Feb 2018, Stephen P. Molnar wrote:
> > I am running Debian Stretch on am eight thread AMD GPU platform.
> > Lately, it seems if I have been plagued by surfeit of orphaned
> > nodes.
> 
> That means:
> 
> 1. "unlinked" files or directories were still open when the
> filesystem
>    had to be shutdown/made read-only.  Uncommon, unless you did
> something
>    like breaking the system by having /run on something other than
>    tmpfs, etc.
> 
> 2. Filesystem corruption, most likely due to bad RAM.
> 
> 3. Really unusual workload and usage (or *mis*usage ?) pattern that
>    results in (1), perhaps involving VMs.
> 
> This assumes XFS or ext3/ext4, which seems to be your case.
> 
> > At first I though it might be impending hard drive failure as I
> > started
> > receiving warning messages from the OS, but installing a brand new
> > drive has not solved the problem,  They seem to happen when I am
> > running  four or more apps at the same time. I have 8GB of RAM in
> > the
> > system.
> 
> Test that RAM.
> 
> > Model name:AMD FX(tm)-8320 Eight-Core Processor
> 
> Ensure you are running the latest AMD microcode on that processor:
> Update the motherboard firmware (BIOS/UEFI) to the latest version
> available from your vendor, and *also* install package amd64-
> microcode
> from non-free.  Unless you're on the latest AMD microcode on the
> FX-8300, you cannot even run VMs safely.  Who knows what else could
> be
> broken...
> 

Thanks for your reply.

I installed memtest86+ and ran it with all of the defaults.  It took
over an hour, but no errors were reported.

I am rather hesitant about updating the BIOS/UFEI.  In fact I can't
seem to find an upgrade for the FX-8320 on the AMD web site.

Also, I'm rather hesitant about installing the amd64-package.

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Causes, cures and prevention of orphaned inodes?

[Stephen P. Molnar]

On Mon, 2018-02-05 at 10:15 +1300, Ben Caradoc-Davies wrote:
> On 05/02/18 09:49, Stephen P. Molnar wrote:
> > They seem to happen when I am
> > running  four or more apps at the same time.
> 
> I would never expect to see orphaned inodes except after a system
> crash 
> or kernel memory corruption. How did you test your CPU and RAM? Do
> you 
> see any other symptoms such as segfaults that could suggest memory 
> problems under concurrent load? How long have you seen this problem?
> I 
> see you are using ext4; are the inodes on these filesystems? ext4 is 
> very well tested and robust.
> 
> My preferred memory test for my 4-core (8-thread) Kaby Lake i7 is to
> run 
> concurrent "memtester" instances equal to the number of cores (4 in
> my 
> case), concurrent with "stress" equal to the number of cores ("stress
> -c 
> 4" in my case). This workout detected memory problems not found by
> other 
> tools such as "memtest86+" or "mprime -t".
> 
> Other hardware issues to consider are overheating (addressed with
> better 
> cooling and thermald) and power supply problems which may only be 
> evident at load. Is your system prime stable (i.e. runs with "mprime
> -t" 
> (with AVX disabled) for many hours)? How do you monitor system
> temperature?
> 
> Kind regards,
> 
Thanks for your reply.

As a matter of fact I did get an overheating warning from the OS when
running a rather large organic molecule on the Orca package with 8
threads.  I upgraded the CPU cooler to a Hyper 212 EVO and the problem
went away.

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: Can't get my video card running

[floris]

Erkko Lahnajärvi schreef op 2018-02-05 15:49:

Hi,

I fetched a new computer few days ago. The equipment are:

Motherboard: Gigabyte AB350-Gaming
CPU: Amd Ryzen 3 1300x
RAM: 16Gb
Video card: GeForce GTX 1050 Ti
Hard disk: WD green 240 Gb

On this computer I installed Debian-9.3.0-amd64.
I've first tried to install the video card. I found a particular
driver for Linux from Ndivia's website. And then I bigan to install
it...

Filename: NVIDIA-Linux-x86_64-375.20.run

I ran the file in Konsole, but then installation started to ask me
packages I should install first.

First ask: 'gcc' -package, I installed it, another try to install ->
didn't get through
Second ask: 'make' -package, installed that too, another try to
install VC-driver -> didn't get through
Third ask: [some package which I don't remember!!??],installed that
too, another try to install VC-driver -> didn't get through
Fourth ask: 'kernel-source or kernel-devel RPM' or define
'--kernel-source-path

But my src folder does not contain kernel-source. From which folder
should I look the kernel-source?

Then I tried some guides from web:

https://linuxconfig.org/how-to-install-the-latest-nvidia-drivers-on-debian-9-stretch-linux

I did as I was ordered in the pages and restarted my computer. But
after that everything seems to be the same. From where can I set
resolution and other videocard adjustments?

How could I install my video card in first place?

--

Friendly regards

Erkko Lahnajärvi


Don't use the nvidia*.run file. Debian has the nvidia-driver package.
read: 
https://wiki.debian.org/NvidiaGraphicsDrivers#Debian_9_.22Stretch.22


(TL;DR)
- add non-free and contrib to your sources.list
- sudo apt-get update
- sudo apt-get install nvidia-driver
- reboot

Install the nvidia-settings package if you want to modify your video 
card settings.


---
Floris

Re: /lib/lsb/init-functions on LXC servers

[Reco]

Hi.

On Mon, Feb 05, 2018 at 04:04:37PM +0100, Harald Dunkel wrote:
> Hi Reco,
> 
> you mean this is a known issue???

Well, it's known to me (since then) at least as I merely read the
contents of /lib/lsb/init-functions in my Debian system.
Pinpointing the problem is easy, anyone who has access to the manpages
and has general understanding the way LXC works can do it.

Fixing the problem is harder - I wrote that I'm unsure of the solutions
proposed.

Reco

Re: Causes, cures and prevention of orphaned inodes?

[Henrique de Moraes Holschuh]

On Mon, 05 Feb 2018, Stephen P. Molnar wrote:
> I installed memtest86+ and ran it with all of the defaults.  It took
> over an hour, but no errors were reported.

Memtest86 and memtest86+ are not always that good at finding memory
errors for some reason...  Try a 24h/48h test over the weekend or
something like that if you really want to be sure.

> I am rather hesitant about updating the BIOS/UFEI.  In fact I can't
> seem to find an upgrade for the FX-8320 on the AMD web site.

An update, if any are available, would be found in the ASUSTEK support
page for your motherboard.

> Also, I'm rather hesitant about installing the amd64-package.

If you never updated that BIOS/UEFI, chances are you are running very
old microcode, which is known to be buggy, and unsupported.  There is
one extremely nasty VM security issue in that processor, as well as some
isses that could result in data corruption in rare cases.  They must be
patched by the most recent AMD microcode update for correct system
operation.

The amd64-microcode packages do not make any permanent changes to the
system, you can just remove them (and re-create the initramfs) if you
want to.

But it is up to you, really.  Your system is clearly misbehaving (unless
you like to power it off improperly or something, in which case the
orphan inodes are *expected* and you should have told us that first
thing :p).

-- 
  Henrique Holschuh

Re: Causes, cures and prevention of orphaned inodes?

[Jochen Spieker]

Stephen P. Molnar:
> 
> I installed memtest86+ and ran it with all of the defaults.  It took
> over an hour, but no errors were reported.

That's not long enough. From what I have read you should let it run for
a day or so and even then you cannot be sure that there are no memory
errors.

> I am rather hesitant about updating the BIOS/UFEI.  In fact I can't
> seem to find an upgrade for the FX-8320 on the AMD web site.

You need a UEFI update for your mainboard, not the CPU.

> Also, I'm rather hesitant about installing the amd64-package.

Do it (installing the amd64-microcode package). Henrique knows about
this stuff better than most people. Also, there is comparatively little
risk involved since the microcode is loaded during boot. You can always
boot from another medium and remove the package if it doesn't work.

J.
-- 
In this bunker there are women and children. There are no weapons.
[Agree]   [Disagree]
 


signature.asc
Description: PGP signature

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 09:41:20 -0500, The Wanderer wrote:

> On 2018-02-05 at 08:58, Vincent Lefevre wrote:
> 
> > On 2018-02-05 08:40:27 -0500, The Wanderer wrote:
> > 
> >> On 2018-02-05 at 08:11, Vincent Lefevre wrote:
> 
> >>> You should set up a "Mail-Followup-To:" for that. This is
> >>> entirely your problem.
> >> 
> >> That does seem to be the trend and position of the world,
> >> especially in recent years, but I disagree as a matter of
> >> philosophy.
> >> 
> >> A mailing list whose subscribers can post to it is a discussion
> >> forum.
> > 
> > However, for debian-user, non-subscribers can also post. So, for
> > mail without a "Mail-Followup-To:", it may be difficult to do the
> > "right" thing automatically.
> 
> Even for replies to messages posted by non-subscribers, replying back to
> the forum by default is still the right thing to do.

AfAIK. there isn't any way to determine whether a message posted to
-user is from a non-subscriber.
 
> If the poster wants to receive replies, it is the poster's
> responsibility to do something to cause that to happen. That can take
> the form of subscribing, or of setting mail headers, or of saying
> "please CC me on replies", or simply of reading the replies in an online
> archive or mirror of the mailing list. If the poster does not do such a
> thing, then it should be presumed that the poster does not care about
> receiving replies.

I have a feeling that it's not necessarily because they do not care but
because some users are unfamiliar with the idea of a mailing list and
engagement with it.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Greg Wooledge]

On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> AfAIK. there isn't any way to determine whether a message posted to
> -user is from a non-subscriber.

I believe some people are using the one of the X-Spam* headers
and looking for the LDOSUBSCRIBER substring.  Which is extremely
non-obvious, and probably not a vector that ordinary users can
easily pursue.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 16:09:11 +0100, to...@tuxteam.de wrote:

> On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
> > On 2018-02-05 at 09:32, David Wright wrote:
> 
> [...]
> 
> > > :0 Wh: $HOME/msgid.lock
> > > | formail -D 19 $HOME/msgid.cache
> > > 
> > > I used it for years.
> > 
> > I don't parse this well enough to understand what it would do, and I
> > don't know where to find a procmail reference which would let me read up
> > on it easily enough to understand quickly. Could you clarify?
> 
> The trick is in formail (contained in the package procmail). Formail is
> a pretty generic mail parser which can be used to filter mails (or parts
> of mails) according to different criteria. Option -D instructs it to set
> up a Message-ID cache to drop duplicate mails (duplicate in the sense of
> Message-ID, that is). The number after the -D limits the cache's length.
> 
> As a careful guy, I have this:
> 
>   :0 Whc: msgid.lock
>   | formail -D 8192 ~/.procmail/msgid.cache
>   
>   :0 a:
>   duplicates
> 
> The 'c' in the first recipe lets a copy "pass through". The second
> rule triggers on successful execution of the first one (i.e. a cache
> hit, "this was a duplicate") and drops the duplicate into the mailbox
> duplicates, where I can check whether something went wrong. Needless
> to say, I haven't had to check in the last ten years, but disk space
> is cheap :)

Now you have problems (or could have). The first problem is that the
"duplicates" are not duplicates because the headers are different. The
second problem is - which one do you wish to keep? The third problem
(related to the second one) is the order in which the messages arrive.
Is it the mailing list reply first or the Cc:?

Users of mutt have it easy:

send-hook . 'unmy_hdr Message-ID:'
send-hook 'debian-user@lists\.debian\.org' 'my_hdr Message-ID:<`date 
+"%Y%m%d%H%M%S"`noccsple...@example.com>'

A mail with NoCcsPlease in its In-Reply-To or References headers can
only have had the mailing list mail as its source. However, the CC will
not contain a List-ID: header. This makes it possible to distinguish
between a list mail and a CC. Procmail recipes based on these two
conditions can now file list mail with certainty and, if desired, delete
CCs.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:

> On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > AfAIK. there isn't any way to determine whether a message posted to
> > -user is from a non-subscriber.
> 
> I believe some people are using the one of the X-Spam* headers
> and looking for the LDOSUBSCRIBER substring.  Which is extremely
> non-obvious, and probably not a vector that ordinary users can
> easily pursue.

The presence of LDOSUBSCRIBER indicates the post is from a subscribed
member. It absence tells you nothing about whether the person (as
indicted by the From: header) is subscribed or not.

-- 
Brian.

Re: Causes, cures and prevention of orphaned inodes?

[Cindy-Sue Causey]

On 2/4/18, Henrique de Moraes Holschuh  wrote:
> On Sun, 04 Feb 2018, Stephen P. Molnar wrote:
>> I am running Debian Stretch on am eight thread AMD GPU platform.
>> Lately, it seems if I have been plagued by surfeit of orphaned nodes.
>
> That means:
>
> 1. "unlinked" files or directories were still open when the filesystem
>had to be shutdown/made read-only.  Uncommon, unless you did something
>like breaking the system by having /run on something other than
>tmpfs, etc.


As soon as I grasped the context, similar was my kneejerk thought. I
see that inode message related to either power failure or my having to
hardcore shut the power off rather than shut down a safer, more
logical way that protects data. So my thinking is that it could be
about something [buggy] not shutting down properly or simply just in
time even if a "proper" reboot/shutdown is being performed..

For some reason, I'm tying it most often to browsers in my case, but I
can't remember why I always think that. Maybe it's most often about
browsers seeming to cause the situation or something ? :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: Causes, cures and prevention of orphaned inodes?

[David Wright]

On Mon 05 Feb 2018 at 14:45:17 (-0200), Henrique de Moraes Holschuh wrote:
> On Mon, 05 Feb 2018, Stephen P. Molnar wrote:

> > I am rather hesitant about updating the BIOS/UFEI.  In fact I can't
> > seem to find an upgrade for the FX-8320 on the AMD web site.
> 
> An update, if any are available, would be found in the ASUSTEK support
> page for your motherboard.
> 
> > Also, I'm rather hesitant about installing the amd64-package.
> 
> If you never updated that BIOS/UEFI, chances are you are running very
> old microcode, which is known to be buggy, and unsupported.  There is
> one extremely nasty VM security issue in that processor, as well as some
> isses that could result in data corruption in rare cases.  They must be
> patched by the most recent AMD microcode update for correct system
> operation.

I'm not in the habit of upgrading BIOS/UEFI on my computers.
(I do have {amd64,intel}-microcode installed.) What old or
buggy code would I be running when booting a linux installation?
(I accept that Grub has to run, and the kernel and initramfs be
found, initially.)

Cheers,
David.

Re: policy around 'wontfix' bug tag

[rhkramer]

Thanks

On Monday, February 05, 2018 09:46:54 AM Greg Wooledge wrote:

> No need to guess.  You can ask it.
> 
> wooledg:~$ date --version

Re: Causes, cures and prevention of orphaned inodes?

[Felipe Salvador]

On Sun, Feb 04, 2018 at 11:06:21PM -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 04 Feb 2018, Stephen P. Molnar wrote:
> > I am running Debian Stretch on am eight thread AMD GPU platform.
> > Lately, it seems if I have been plagued by surfeit of orphaned nodes.
> 
> That means:
> 
> 1. "unlinked" files or directories were still open when the filesystem
>had to be shutdown/made read-only.  Uncommon, unless you did something
>like breaking the system by having /run on something other than
>tmpfs, etc.
> 
> 2. Filesystem corruption, most likely due to bad RAM.
> 
> 3. Really unusual workload and usage (or *mis*usage ?) pattern that
>results in (1), perhaps involving VMs.

Could it be due to an undersized(or faulty) power supply?

Could a barely sized power supply, on a heavy load scenario,
lead to file system corruption?

Thank you

> This assumes XFS or ext3/ext4, which seems to be your case.
> 
> > At first I though it might be impending hard drive failure as I started
> > receiving warning messages from the OS, but installing a brand new
> > drive has not solved the problem,  They seem to happen when I am
> > running  four or more apps at the same time. I have 8GB of RAM in the
> > system.
> 
> Test that RAM.
> 
> > Model name:AMD FX(tm)-8320 Eight-Core Processor
> 
> Ensure you are running the latest AMD microcode on that processor:
> Update the motherboard firmware (BIOS/UEFI) to the latest version
> available from your vendor, and *also* install package amd64-microcode
> from non-free.  Unless you're on the latest AMD microcode on the
> FX-8300, you cannot even run VMs safely.  Who knows what else could be
> broken...
> 
> -- 
>   Henrique Holschuh

Regards
-- 
Felipe Salvador

Re: policy around 'wontfix' bug tag

[rhkramer]

On Monday, February 05, 2018 10:02:50 AM Michael Stone wrote:
> On Mon, Feb 05, 2018 at 09:11:23AM -0500, rhkra...@gmail.com wrote:
> >I assume (I know) that the license for date is some free / open source
> >license that would allow you to incorporate the old code into a new
> >function (probably with appropriate citation / credit) and then add /
> >modify / delete code as desired.
> >
> >OK, I will say one thing--I suspect this is something like the (forget
> >what they called it)--the year 2000 problem--there is code that people
> >(and companies depend on) that is so old that the maintainers are long
> >gone, thus breaking that old function wouild be a very bad thing.
> 
> IIRC it started out as a YACC function in the late 80s, and is now a
> Bison (YACC+GNU extensions) library. There are still people who work on
> it--the debug option added a couple of years ago has made it *much*
> easier to understand why it does the things that it does. I'm not sure
> that if I were implementing a new option I'd use the bison code at all
> (it does probably limit the contributor pool). The bigger issues aren't
> the choice of implementation language, they're 1) getting buy-in on what
> the replacement should look like and 2) getting people to use something
> different. It's tough, because almost every linux system out there has
> date(1) with the existing -d parser, and it's easier to assume that's
> there than to use something else. (E.g., it's possible to use python or
> perl or other scripting language one-liners with any number of date
> libraries to add much more maintainable date handling to their scripts,
> but most people just stick with the date(1) they know rather than using
> one of the alternatives.)

Thanks for the (interesting, educational, and valid) response, but, for the 
record, I was trying to refer to all the scripts and such that use the date 
function rather than the coding of the date function itself.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 10:24:14 -0500, The Wanderer wrote:

> On 2018-02-05 at 10:09, to...@tuxteam.de wrote:
> 
> > On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
> >
> >> On 2018-02-05 at 09:32, David Wright wrote:
> > 
> > [...]
> > 
> >> > :0 Wh: $HOME/msgid.lock
> >> > | formail -D 19 $HOME/msgid.cache
> >> > 
> >> > I used it for years.
> > 
> >> I don't parse this well enough to understand what it would do, and I
> >> don't know where to find a procmail reference which would let me read up
> >> on it easily enough to understand quickly. Could you clarify?
> > 
> > The trick is in formail (contained in the package procmail). Formail is
> > a pretty generic mail parser which can be used to filter mails (or parts
> > of mails) according to different criteria. Option -D instructs it to set
> > up a Message-ID cache to drop duplicate mails (duplicate in the sense of
> > Message-ID, that is). The number after the -D limits the cache's length.
> 
> That wouldn't produce the behavior I want, though. Whether or not a
> "duplicate" private copy (or probably not actually duplicate, since
> mailing lists tend to modify other headers while leaving Message-ID
> alone) is inappropriate depends on context, and specifically, primarily
> on the sender's intent.

Intent is something difficult to work out. I suspect many just hit
mutt's equivalent of the "g" key. Getting upset about it is the road
to a flame war.

> There can be legitimate reasons to send a message both to mailing list
> and to a named recipient who is also subscribed to that list.

Indeed. 
 
> For example, consider a high-volume mailing list, where many subscribers
> read only part of the traffic.

Or, could we consider the BTS? Not Cc'ing a bug report submitter in a
reply runs a very high risk of leaving them out of the loop.

> If there's an ongoing discussion on that mailing list, and one of the
> participants wants to draw in a third person who also subscribes, it's
> entirely appropriate to CC a reply to that third party.

Definitely (whether they are known to subscribe or not).

Which brings us back to - how does one know someone is subscribed to a
Debian mailing list?
 
> However, if this were to happen with me, I would not want to receive
> *only* the mailing-list copy. I would want to receive both: the
> mailing-list copy to go into my local archive of the mailing list (and
> to be present in the mailing list's folder, so that it appears properly
> threaded with other replies), and the direct copy to draw my attention
> to the subject. (Although I would probably then seek out the
> mailing-list copy and reply to that. But that's a personal
> idiosyncrasy.)

Seeking out is time-consuming. A recipe for automation is given in
another post. It gives you everything you want.

> There are other possible complexifying scenarios, which distort the
> picture in other directions, but I don't have them ready to mind right
> now.

I've tried to point to some of them.

> What it boils down to is that dropping duplicate messages is only always
> appropriate when they are *complete* duplicates, in all headers (except
> possibly things like transmission path history). With a mailing list,
> that's rarely if ever the case.

(Transmission headers are not unimportant. You cannot have it both
ways; it's either a duplicate or it's not).

It's probably impossible. Determining a duplicate email solely on the
basis of an identical Message-Id: is a brain-dead idea.

-- 
Brian.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 08:32:32 -0600, David Wright wrote:

> If it really worries you, the answer might be ~/.procmailrc and
> 
> :0 Wh: $HOME/msgid.lock
> | formail -D 19 $HOME/msgid.cache
> 
> I used it for years.

So has Microsoft in Exchange. They use it to delete a user's mails
silently. Emulating this on Debian is not to be recommended. It is
sad to see this idea advanced here.

-- 
Brian.

Re: Causes, cures and prevention of orphaned inodes?

[Stephen P. Molnar]

On Mon, 2018-02-05 at 19:40 +0100, Felipe Salvador wrote:
> On Sun, Feb 04, 2018 at 11:06:21PM -0200, Henrique de Moraes Holschuh
> wrote:
> > On Sun, 04 Feb 2018, Stephen P. Molnar wrote:
> > > I am running Debian Stretch on am eight thread AMD GPU platform.
> > > Lately, it seems if I have been plagued by surfeit of orphaned
> > > nodes.
> > 
> > That means:
> > 
> > 1. "unlinked" files or directories were still open when the
> > filesystem
> >    had to be shutdown/made read-only.  Uncommon, unless you did
> > something
> >    like breaking the system by having /run on something other than
> >    tmpfs, etc.
> > 
> > 2. Filesystem corruption, most likely due to bad RAM.
> > 
> > 3. Really unusual workload and usage (or *mis*usage ?) pattern that
> >    results in (1), perhaps involving VMs.
> 
> Could it be due to an undersized(or faulty) power supply?
> 
> Could a barely sized power supply, on a heavy load scenario,
> lead to file system corruption?
> 
> Thank you
> 
> > This assumes XFS or ext3/ext4, which seems to be your case.
> > 
> > > At first I though it might be impending hard drive failure as I
> > > started
> > > receiving warning messages from the OS, but installing a brand
> > > new
> > > drive has not solved the problem,  They seem to happen when I am
> > > running  four or more apps at the same time. I have 8GB of RAM in
> > > the
> > > system.
> > 
> > Test that RAM.
> > 
> > > Model name:AMD FX(tm)-8320 Eight-Core Processor
> > 
> > Ensure you are running the latest AMD microcode on that processor:
> > Update the motherboard firmware (BIOS/UEFI) to the latest version
> > available from your vendor, and *also* install package amd64-
> > microcode
> > from non-free.  Unless you're on the latest AMD microcode on the
> > FX-8300, you cannot even run VMs safely.  Who knows what else could
> > be
> > broken...
> > 
> > -- 
> >   Henrique Holschuh
> 
> Regards


That's an excellent question.  I really don't know.

-- 
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> On Mon 05 Feb 2018 at 16:09:11 +0100, to...@tuxteam.de wrote:
> 
> > On Mon, Feb 05, 2018 at 09:44:43AM -0500, The Wanderer wrote:
> > > On 2018-02-05 at 09:32, David Wright wrote:
> > 
> > [...]
> > 
> > > > :0 Wh: $HOME/msgid.lock
> > > > | formail -D 19 $HOME/msgid.cache
> > > > 
> > > > I used it for years.
> > > 
> > > I don't parse this well enough to understand what it would do, and I
> > > don't know where to find a procmail reference which would let me read up
> > > on it easily enough to understand quickly. Could you clarify?
> > 
> > The trick is in formail (contained in the package procmail). Formail is
> > a pretty generic mail parser which can be used to filter mails (or parts
> > of mails) according to different criteria. Option -D instructs it to set
> > up a Message-ID cache to drop duplicate mails (duplicate in the sense of
> > Message-ID, that is). The number after the -D limits the cache's length.
> > 
> > As a careful guy, I have this:
> > 
> >   :0 Whc: msgid.lock
> >   | formail -D 8192 ~/.procmail/msgid.cache
> >   
> >   :0 a:
> >   duplicates
> > 
> > The 'c' in the first recipe lets a copy "pass through". The second
> > rule triggers on successful execution of the first one (i.e. a cache
> > hit, "this was a duplicate") and drops the duplicate into the mailbox
> > duplicates, where I can check whether something went wrong. Needless
> > to say, I haven't had to check in the last ten years, but disk space
> > is cheap :)
> 
> Now you have problems (or could have). The first problem is that the
> "duplicates" are not duplicates because the headers are different. The
> second problem is - which one do you wish to keep? The third problem
> (related to the second one) is the order in which the messages arrive.
> Is it the mailing list reply first or the Cc:?

Granted, you lose all the information in the header about how the
reply journeyed from Fred to bendel.debian.org and on to yourself
when the list copy arrives after the direct one but, unless you're
taking a special interest in how long messages are taking, what
exactly have you lost?

(OK, your responder uses Bcc: to post to the list, so you don't know
whether this was *only* a private reply. Anyone here doing that?)

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> 
> > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > AfAIK. there isn't any way to determine whether a message posted to
> > > -user is from a non-subscriber.
> > 
> > I believe some people are using the one of the X-Spam* headers
> > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > non-obvious, and probably not a vector that ordinary users can
> > easily pursue.
> 
> The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> member. It absence tells you nothing about whether the person (as
> indicted by the From: header) is subscribed or not.

Agreed; I've never earned the privilege of that in my header.
I've sometimes wondered whether that's the reason I occasionally
fall foul of the spam filter, and have to re-post.

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 19:00:16 (+), Brian wrote:
> On Mon 05 Feb 2018 at 08:32:32 -0600, David Wright wrote:
> 
> > If it really worries you, the answer might be ~/.procmailrc and
> > 
> > :0 Wh: $HOME/msgid.lock
> > | formail -D 19 $HOME/msgid.cache
> > 
> > I used it for years.
> 
> So has Microsoft in Exchange. They use it to delete a user's mails
> silently. Emulating this on Debian is not to be recommended. It is
> sad to see this idea advanced here.

The fact that someone abuses a method that you use yourself does not
invalidate that method. There's nothing sad about the method when
you've set it up ypurself.

I open my front door with a key. If I give a copy to my neighbour
for safekeeping, I don't expect them to go and open it without
(a) first being given permission and (b) telling me about the
circumstances, should it ever happen.

Cheers,
David.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 13:12:45 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> > 
> > Now you have problems (or could have). The first problem is that the
> > "duplicates" are not duplicates because the headers are different. The
> > second problem is - which one do you wish to keep? The third problem
> > (related to the second one) is the order in which the messages arrive.
> > Is it the mailing list reply first or the Cc:?
> 
> Granted, you lose all the information in the header about how the
> reply journeyed from Fred to bendel.debian.org and on to yourself
> when the list copy arrives after the direct one but, unless you're
> taking a special interest in how long messages are taking, what
> exactly have you lost?

The original mail has been lost. As far as I am concerned. the
original which was sent to me is the only thing of importance to
me. If that isn't important to you and you are satisfied with a
simulacrum, that's ok by me.

(The "unless you're taking a special interest in how long messages
are taking" is an indication of how important a user's mail is seen
to be. If the US Postal Service processed one's mail in such a 
subjective manner there might be a complaint or two).

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 13:18:29 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 19:00:16 (+), Brian wrote:
> > On Mon 05 Feb 2018 at 08:32:32 -0600, David Wright wrote:
> > 
> > > If it really worries you, the answer might be ~/.procmailrc and
> > > 
> > > :0 Wh: $HOME/msgid.lock
> > > | formail -D 19 $HOME/msgid.cache
> > > 
> > > I used it for years.
> > 
> > So has Microsoft in Exchange. They use it to delete a user's mails
> > silently. Emulating this on Debian is not to be recommended. It is
> > sad to see this idea advanced here.
> 
> The fact that someone abuses a method that you use yourself does not
> invalidate that method. There's nothing sad about the method when
> you've set it up ypurself.

So Microsoft is abusing the method but Debian system administrators who
use procmail to do the same thing are not?

But you have a good point. Users can do what they want with their own
mail. That includes deleting it using the brain-dead idea that the same
Messge-Id: indicates the same email.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 13:13:18 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> > On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> > 
> > > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > > AfAIK. there isn't any way to determine whether a message posted to
> > > > -user is from a non-subscriber.
> > > 
> > > I believe some people are using the one of the X-Spam* headers
> > > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > > non-obvious, and probably not a vector that ordinary users can
> > > easily pursue.
> > 
> > The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> > member. It absence tells you nothing about whether the person (as
> > indicted by the From: header) is subscribed or not.
> 
> Agreed; I've never earned the privilege of that in my header.
> I've sometimes wondered whether that's the reason I occasionally
> fall foul of the spam filter, and have to re-post.

I cannot account for that (and I doubt listmaster will enlighten us) but
this mail of yours has

Received: from david by alum with local (Exim 4.80) 
 
(envelope-from )
 
id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600

Received: from localhost (localhost [127.0.0.1])
 
by bendel.debian.org (Postfix) with QMQP
 
id B714B37A; Mon,  5 Feb 2018 19:13:44 + (UTC)

Very timely.

-- 
Brian.

Re: Causes, cures and prevention of orphaned inodes?

[Ben Caradoc-Davies]

On 06/02/18 07:32, David Wright wrote:

I'm not in the habit of upgrading BIOS/UEFI on my computers.
(I do have {amd64,intel}-microcode installed.) What old or
buggy code would I be running when booting a linux installation?
(I accept that Grub has to run, and the kernel and initramfs be
found, initially.)


Your BIOS/UEFI may perform boot-time memory training to adjust memory 
frequency and voltages. I think it might also be responsible for setting 
CPU and other chipset voltages during operation. These have a profound 
impact on system stability. I always upgrade my BIOS/UEFI to take 
advantage of any improvements recommended by the manufacturer.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Causes, cures and prevention of orphaned inodes?

[Ben Caradoc-Davies]

On 06/02/18 04:52, Stephen P. Molnar wrote:

I installed memtest86+ and ran it with all of the defaults.  It took
over an hour, but no errors were reported.


Please try parallel memtester and stress. These found memory errors for 
me that were not found by memtest86+.


In *eight* terminal windows as root run (noting that you have 8GB RAM):

memtester 768M

In one terminal window run (nothing that the FX-8320 has only 4 FPUs and 
stress -c spins on sqrt):


stress -c 4

You can also tell memtester to use multiple iterations:

memtester 768M 10


I am rather hesitant about updating the BIOS/UFEI.  In fact I can't
seem to find an upgrade for the FX-8320 on the AMD web site.


The BIOS/UEFI upgrade is an upgrade for your motherboard and can be 
obtained from your motherboard vendor. For the Asus M5A97 R2.0:

https://www.asus.com/us/Motherboards/M5A97_R20/HelpDesk_BIOS/

You are currently running "Version 2006 2013/10/16".
Please try upgrading to "Version 2603 2015/07/24".

Note the multiple entries entitled "Improve system stability".


Also, I'm rather hesitant about installing the amd64-package.


wat? Why? Modern CPUs are released full of microcode bugs. AMD release 
new microcode that they wrote to fix these bugs in their microcode and 
that they recommend. Why would you not use it?


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 19:37:45 (+), Brian wrote:
> On Mon 05 Feb 2018 at 13:12:45 -0600, David Wright wrote:
> 
> > On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> > > 
> > > Now you have problems (or could have). The first problem is that the
> > > "duplicates" are not duplicates because the headers are different. The
> > > second problem is - which one do you wish to keep? The third problem
> > > (related to the second one) is the order in which the messages arrive.
> > > Is it the mailing list reply first or the Cc:?
> > 
> > Granted, you lose all the information in the header about how the
> > reply journeyed from Fred to bendel.debian.org and on to yourself
> > when the list copy arrives after the direct one but, unless you're
> > taking a special interest in how long messages are taking, what
> > exactly have you lost?
> 
> The original mail has been lost. As far as I am concerned. the
> original which was sent to me is the only thing of importance to
> me. If that isn't important to you and you are satisfied with a
> simulacrum, that's ok by me.
> 
> (The "unless you're taking a special interest in how long messages
> are taking" is an indication of how important a user's mail is seen
> to be. If the US Postal Service processed one's mail in such a 
> subjective manner there might be a complaint or two).

Again, I'm left to think of an analogy in Real Life.

When some companies and institutions send an important letter, they
will often send one by normal post and one by Recorded Delivery.
The first gets delivered as normal and can be picked up on return
from work, whereas the other may be delayed (eg, P739 card in the UK).

When both eventually get delivered, they can be seen to be identical,
though the markings on the envelopes will differ. One is not a
simulacrum of the other; it's a clone, a duplicate.

My point about transit times was only to acknowledge that there are
occasional discussions on mailing lists about the time it takes posts
to play pinball round the various bits of bendel (for this particular
list), which depend on having the list version of the header. So an
email which was Cc'd to you as well as posted on the list could lose
you the grand total of one data point. No big deal. Nothing to do with
all the rest of your email, nor with USPS/snail mail.

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 20:26:46 (+), Brian wrote:
> On Mon 05 Feb 2018 at 13:13:18 -0600, David Wright wrote:
> 
> > On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> > > On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> > > 
> > > > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > > > AfAIK. there isn't any way to determine whether a message posted to
> > > > > -user is from a non-subscriber.
> > > > 
> > > > I believe some people are using the one of the X-Spam* headers
> > > > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > > > non-obvious, and probably not a vector that ordinary users can
> > > > easily pursue.
> > > 
> > > The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> > > member. It absence tells you nothing about whether the person (as
> > > indicted by the From: header) is subscribed or not.
> > 
> > Agreed; I've never earned the privilege of that in my header.
> > I've sometimes wondered whether that's the reason I occasionally
> > fall foul of the spam filter, and have to re-post.
> 
> I cannot account for that (and I doubt listmaster will enlighten us) but
> this mail of yours has
> 
> Received: from david by alum with local (Exim 4.80)   
>
> (envelope-from )  
>
> id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600
> 
> Received: from localhost (localhost [127.0.0.1])  
>
> by bendel.debian.org (Postfix) with QMQP  
>
> id B714B37A; Mon,  5 Feb 2018 19:13:44 + (UTC)
> 
> Very timely.

Is that meant to tell me something (as you wrote "but")?

Cheers,
David.

Re: policy around 'wontfix' bug tag

[Greg Wooledge]

> > Received: from david by alum with local (Exim 4.80)
> > (envelope-from )
> > id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600

> Is that meant to tell me something (as you wrote "but")?

Without knowing exactly what piece Brian was focusing on, I can at
least point out that your envelope-from is unusable.  You'll never
be able to get a bounce message at that address.  Whether that was
your intention, or an accident, only you can say.

Re: Frustration over Debian naming

[Jonathan de Boyne Pollard]

rhkramer:

Intentionally cross posted. Aside: For those on the debian-user lists, 
the thread came from the debian-backports list, but my frustration 
should probably be expressed more to the debian-user list (or 
debian-developer list, assuming there is such a list (to which I am 
not subscribed). [...]


But the various names and use of those names gets very frustrating for 
me, and I suspect I am not the only one. The numbered versions, the 
Toy Story names, and then the testing, stable, old stable, old old 
stable is just frustrating.


Tangentially to that, it seems that someone needs to pick up the dropped 
baton and update the pictures.


* 
http://wiki.lib.sun.ac.za/images/thumb/a/aa/Timelinededebian.png/800px-Timelinededebian.png


* 
http://blog.admin-linux.org/wp-content/uploads/2012/01/infographic_debian_history-en-v081.png


* http://doc.callmematthi.eu/pictures/Understanding_Debian.png

* https://i.stack.imgur.com/nLXu9.jpg

* 
https://bsdmag.org/wp-content/uploads/2016/08/infographic_debian-v2.1.en_.png

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 15:45:54 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 20:26:46 (+), Brian wrote:
> > On Mon 05 Feb 2018 at 13:13:18 -0600, David Wright wrote:
> > 
> > > On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> > > > On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> > > > 
> > > > > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > > > > AfAIK. there isn't any way to determine whether a message posted to
> > > > > > -user is from a non-subscriber.
> > > > > 
> > > > > I believe some people are using the one of the X-Spam* headers
> > > > > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > > > > non-obvious, and probably not a vector that ordinary users can
> > > > > easily pursue.
> > > > 
> > > > The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> > > > member. It absence tells you nothing about whether the person (as
> > > > indicted by the From: header) is subscribed or not.
> > > 
> > > Agreed; I've never earned the privilege of that in my header.
> > > I've sometimes wondered whether that's the reason I occasionally
> > > fall foul of the spam filter, and have to re-post.
> > 
> > I cannot account for that (and I doubt listmaster will enlighten us) but
> > this mail of yours has
> > 
> > Received: from david by alum with local (Exim 4.80) 
> >  
> > (envelope-from )
> >  
> > id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600
> > 
> > Received: from localhost (localhost [127.0.0.1])
> >  
> > by bendel.debian.org (Postfix) with QMQP
> >  
> > id B714B37A; Mon,  5 Feb 2018 19:13:44 + (UTC)
> > 
> > Very timely.
> 
> Is that meant to tell me something (as you wrote "but")?

I recived B714B37A 26 seconds after you posted it. Just thought you
would like the comfort of knowing your mail traversed the system
just as quickly as others do.

-- 
Brian.

Re: policy around 'wontfix' bug tag

[Brian]

On Mon 05 Feb 2018 at 15:42:32 -0600, David Wright wrote:

> On Mon 05 Feb 2018 at 19:37:45 (+), Brian wrote:
> > On Mon 05 Feb 2018 at 13:12:45 -0600, David Wright wrote:
> > 
> > > On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> > > > 
> > > > Now you have problems (or could have). The first problem is that the
> > > > "duplicates" are not duplicates because the headers are different. The
> > > > second problem is - which one do you wish to keep? The third problem
> > > > (related to the second one) is the order in which the messages arrive.
> > > > Is it the mailing list reply first or the Cc:?
> > > 
> > > Granted, you lose all the information in the header about how the
> > > reply journeyed from Fred to bendel.debian.org and on to yourself
> > > when the list copy arrives after the direct one but, unless you're
> > > taking a special interest in how long messages are taking, what
> > > exactly have you lost?
> > 
> > The original mail has been lost. As far as I am concerned. the
> > original which was sent to me is the only thing of importance to
> > me. If that isn't important to you and you are satisfied with a
> > simulacrum, that's ok by me.
> > 
> > (The "unless you're taking a special interest in how long messages
> > are taking" is an indication of how important a user's mail is seen
> > to be. If the US Postal Service processed one's mail in such a 
> > subjective manner there might be a complaint or two).
> 
> Again, I'm left to think of an analogy in Real Life.
> 
> When some companies and institutions send an important letter, they
> will often send one by normal post and one by Recorded Delivery.
> The first gets delivered as normal and can be picked up on return
> from work, whereas the other may be delayed (eg, P739 card in the UK).
> 
> When both eventually get delivered, they can be seen to be identical,
> though the markings on the envelopes will differ. One is not a
> simulacrum of the other; it's a clone, a duplicate.

To my knowledge, Royal mail do not destroy one of the mails because you
have received one already. Some ISPs are adept at it.

(The information conveyed by both letters is not the same. You only have
to look at them side-by-side to see that. They are not clones. Of course,
if you want to thow away the envelopes . But now you do not have the
original letters).


-- 
Brian.

Re: policy around 'wontfix' bug tag

[Jonathan de Boyne Pollard]

Michael Stone:

Anyway, if there was a simple solution someone would have implemented 
it by now.


Indeed, that is the case; and it has been around for almost as long as 
those 20 years that you have been watching people use the GNU tool.  In 
2001, Paul Jarc invented a fairly simple notation for such things; 
providing what is effectively a mini-language, made out of chaining 
programs and using environment variables for variables, with |add|, 
|sub|, |min|, |max|, |statfile|, and |match| operators.


* http://code.dogmap.org/runwhen/example/

* http://code.dogmap.org/runwhen/stamp-fmt/

* http://code.dogmap.org/runwhen/

Xe even went through the second-system-effect process of not liking the 
first way that xe implemented it.


* http://code.dogmap.org/runwhen/caldelay/

Leаh Neukirchen took the old |caldelay| idea, and turned environment 
variables into command-line options.


* https://github.com/chneukirchen/snooze

Although |add n d1s now1s match $now1s ,H=2,M=30 wake statfile started 
add $MTAI64N d1H earliest ||max $wake $earliest wake| (which is 
effectively a prefix notation which in an infix form would be something 
like |$now1s := ||now add d1s ; $||wake := ||$now1s findnextmatching 
H=2,M=30 ; $||MTAI64N||:= timestampof started ; $||earliest :=||$MTAI64N 
add d1H ; $||wake :=||$wake max $earliest|) is more along the lines that 
you were writing about earlier.  (One can imagine a pair of date 
calculator tools akin to |dc| and |bc| that understand the prefix and 
infix forms.)

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 17:07:35 (-0500), Greg Wooledge wrote:
> > > Received: from david by alum with local (Exim 4.80)
> > > (envelope-from )
> > > id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600
> 
> > Is that meant to tell me something (as you wrote "but")?
> 
> Without knowing exactly what piece Brian was focusing on, I can at
> least point out that your envelope-from is unusable.  You'll never
> be able to get a bounce message at that address.  Whether that was
> your intention, or an accident, only you can say.

Poor alum wouldn't have a clue what to do with a bounced email. Like
PCs on many home LANs, it only sends. When I'm at home, all my emails
leave this one PC as it makes filing and backing up the Sent-mail
copies easier. So what you see there is mutt on alum sending an email
to exim on alum which will rewrite the From as an address in the
UK. Again, it would be pointless to bounce mail back to the point at
which it enters the Internet, my ISP, as it would never get seen by me
(assuming they found somewhere to stick it).

Cheers,
David.

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 23:20:13 (+), Brian wrote:
> On Mon 05 Feb 2018 at 15:45:54 -0600, David Wright wrote:
> 
> > On Mon 05 Feb 2018 at 20:26:46 (+), Brian wrote:
> > > On Mon 05 Feb 2018 at 13:13:18 -0600, David Wright wrote:
> > > 
> > > > On Mon 05 Feb 2018 at 18:06:34 (+), Brian wrote:
> > > > > On Mon 05 Feb 2018 at 12:53:36 -0500, Greg Wooledge wrote:
> > > > > 
> > > > > > On Mon, Feb 05, 2018 at 05:31:29PM +, Brian wrote:
> > > > > > > AfAIK. there isn't any way to determine whether a message posted 
> > > > > > > to
> > > > > > > -user is from a non-subscriber.
> > > > > > 
> > > > > > I believe some people are using the one of the X-Spam* headers
> > > > > > and looking for the LDOSUBSCRIBER substring.  Which is extremely
> > > > > > non-obvious, and probably not a vector that ordinary users can
> > > > > > easily pursue.
> > > > > 
> > > > > The presence of LDOSUBSCRIBER indicates the post is from a subscribed
> > > > > member. It absence tells you nothing about whether the person (as
> > > > > indicted by the From: header) is subscribed or not.
> > > > 
> > > > Agreed; I've never earned the privilege of that in my header.
> > > > I've sometimes wondered whether that's the reason I occasionally
> > > > fall foul of the spam filter, and have to re-post.
> > > 
> > > I cannot account for that (and I doubt listmaster will enlighten us) but
> > > this mail of yours has
> > > 
> > > Received: from david by alum with local (Exim 4.80)   
> > >
> > > (envelope-from )  
> > >
> > > id 1eimCc-EV-Nv; Mon, 05 Feb 2018 13:13:18 -0600
> > > 
> > > Received: from localhost (localhost [127.0.0.1])  
> > >
> > > by bendel.debian.org (Postfix) with QMQP  
> > >
> > > id B714B37A; Mon,  5 Feb 2018 19:13:44 + (UTC)
> > > 
> > > Very timely.
> > 
> > Is that meant to tell me something (as you wrote "but")?
> 
> I recived B714B37A 26 seconds after you posted it. Just thought you
> would like the comfort of knowing your mail traversed the system
> just as quickly as others do.

Ah, OK, the timestamps. There's no need to worry about that. Every
email I send to my wife, sitting at the same table, crosses the
Atlantic twice, typically in under a minute, and sometimes much less.

By the way, I've never looked at those "id"s given there. Looking at
the line in exim's log, I assume it's the name of the spool files
when the email is queued between mutt and exim:

2018-02-05 13:13:18 1eimCc-EV-Nv <= david@alum U=david P=local S=1956 
id=20180205191318.GC32350@alum

The id= given on this line is, of course, the invariant Message-ID
that procmail would use using to deduplicate incoming traffic.
(Just for the record.)

Cheers,
David.

[Was: Re: policy around 'wontfix' bug tag

[Erik Christiansen]

On 05.02.18 09:39, Greg Wooledge wrote:
> On Sun, Feb 04, 2018 at 04:04:34PM +0100, Nicolas George wrote:
> > All you describe is convenience for programmatic use. As I explained,
> > this parser is meant for interactive use.
> 
> What on EARTH made you think THAT?

The fuzzy grammar of the date string makes programmatic use a bit
empirical, I must admit.

> I promise you, people ARE using date -d '...' in shell scripts.
> LOTS of people.  Hell, I've done it.(*)

A data point: I have been using "date" for a good 30 years, on hp-ux,
SunOS, Solaris, and now linux - pretty much _exclusively_ in scripts,
even with -d. An example still in use even scripts the "human readable"
input:

#!/bin/bash
[ `date '+%H'` -lt 4 ] && day="yesterday" || day="today"
d="`date -d $day '+%a %b %_d'`"
...
echo "`date -d $day '+%a %b %_d'`" $n >> ~/fetchmail_traffic

If a new formal grammar largely consistent with the "mostly free format
human readable date string" were defined in the manpage, then that could
be a step forward.

> If I'm a human working in an interactive shell, and I want to see "the
> date of the Sunday that occurred in the previous week", I will simply
> run cal(1) instead.  (Or for that specific example on this specific
> day, "cal 1 2018" or even "cal 2018".)  It's a lot easier than trying
> to guess which recipe you can put into date -d to get the same result.

Yes, cal is less effort. I use date interactively only when developing a
script. For me, the "mostly free format human readable date string" is
irrelevant, as it merely serves as an undocumented grammar.

> 
> (*) One specific shell script use case was "Get the last date of a given
> month."  Now, obviously you can just set up an array of hard-coded month
> ending dates, and then write a function to determine whether the current
> year is a leap year for the February case.  But if you want to do it with
> GNU date -d, then you have to guess a magic incantation that actually
> works.  Usually by trial and error.
> 
> Anyway, here's what I came up with:
> 
> lastday() {
> date +%Y-%m-%d -d "$1 1 day ago + 1 month"
> }
...

> How does it work?  Who knows!

That's quite straightforward, I submit. Omitting the "+ 1 month", your
expression is equivalent to: (with $1 substituted for example 1)

$ date +%Y-%m-%d -d "2016-03-01 - 1 day"
2016-02-29

which simply steps backward from first of the month to last of the
previous. Then stepping forward a month merely avoids the need to input
first of next month for last of this one.

> But it seems to work.  It correctly
> handles the oddball corner cases like Feb 2100 (which is not a leap
> year), and the March-that-follows-a-leap-day as well as the
> March-that-does-not-follow-a-leap-day.  So that is where I left it.

And for the far past, cal is superior; compare:

$ cal -3 9 1752
August 1752  September 1752 October 1752  
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  
   1 1  2 14 15 16   1  2  3  4  5  6  7  
 2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14  
 9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21  
16 17 18 19 20 21 2222 23 24 25 26 27 28  
23 24 25 26 27 28 2929 30 31  
30 31

with

$ date +%Y-%m-%d -d "1752-10-01 - 1 day"
date: invalid date `1752-10-01 - 1 day'

Cal delivers the goods, but date lacks the time travelling range.

Erik

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 06/02/18 02:11, Vincent Lefevre wrote:
> On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
>> On 05/02/18 01:44, Nicolas George wrote:
 PS - please don't cc me; I'm on the list.
>>> Done this once, but I cannot promise I will think of it later. Document
>>> your preference in your mail mail header, the standard way, so that it
>>> is automatic and works for everybody, just like I did. Too bad the list
>>> software is not properly configured to do that automatically.
>>
>> My preference is for any personal replies addressed to me to go to me,
>> and I'd use the Reply-to header (as intended) if I needed it to go
>> somewhere else. But replies to the list should go to the list (only)
>> (unless otherwise requested), as per list policy.
> 
> You should set up a "Mail-Followup-To:" for that. This is entirely
> your problem.

I could do that, I'm sure (though I'm not sure how) - but I'd rather
that someone intending to send me a private reply didn't send it to the
list by mistake. Having to (in my case) click 'Reply to List' helps me
not send to the list by mistake.

The behaviour and policy of this list, when followed, does what I want.

Richard




signature.asc
Description: OpenPGP digital signature

Re: policy around 'wontfix' bug tag

[David Wright]

On Mon 05 Feb 2018 at 23:39:30 (+), Brian wrote:
> On Mon 05 Feb 2018 at 15:42:32 -0600, David Wright wrote:
> 
> > On Mon 05 Feb 2018 at 19:37:45 (+), Brian wrote:
> > > On Mon 05 Feb 2018 at 13:12:45 -0600, David Wright wrote:
> > > 
> > > > On Mon 05 Feb 2018 at 18:01:08 (+), Brian wrote:
> > > > > 
> > > > > Now you have problems (or could have). The first problem is that the
> > > > > "duplicates" are not duplicates because the headers are different. The
> > > > > second problem is - which one do you wish to keep? The third problem
> > > > > (related to the second one) is the order in which the messages arrive.
> > > > > Is it the mailing list reply first or the Cc:?
> > > > 
> > > > Granted, you lose all the information in the header about how the
> > > > reply journeyed from Fred to bendel.debian.org and on to yourself
> > > > when the list copy arrives after the direct one but, unless you're
> > > > taking a special interest in how long messages are taking, what
> > > > exactly have you lost?
> > > 
> > > The original mail has been lost. As far as I am concerned. the
> > > original which was sent to me is the only thing of importance to
> > > me. If that isn't important to you and you are satisfied with a
> > > simulacrum, that's ok by me.
> > > 
> > > (The "unless you're taking a special interest in how long messages
> > > are taking" is an indication of how important a user's mail is seen
> > > to be. If the US Postal Service processed one's mail in such a 
> > > subjective manner there might be a complaint or two).
> > 
> > Again, I'm left to think of an analogy in Real Life.
> > 
> > When some companies and institutions send an important letter, they
> > will often send one by normal post and one by Recorded Delivery.
> > The first gets delivered as normal and can be picked up on return
> > from work, whereas the other may be delayed (eg, P739 card in the UK).
> > 
> > When both eventually get delivered, they can be seen to be identical,
> > though the markings on the envelopes will differ. One is not a
> > simulacrum of the other; it's a clone, a duplicate.
> 
> To my knowledge, Royal mail do not destroy one of the mails because you
> have received one already. Some ISPs are adept at it.

You seem determined to miss the point. The sender sends two identical
copies. Royal Mail delivers both of the letters. The addressee can bin
one because the paper bears the same ink marks as the other one.

> (The information conveyed by both letters is not the same. You only have
> to look at them side-by-side to see that. They are not clones. Of course,
> if you want to thow away the envelopes . But now you do not have the
> original letters).

In my analogy, the company sent two identical copies. They are
identical by definition, printed with copies=3 (one for them to file).

Similarly, the bodies of the two emails are identical. They are cloned
when they're sent by exim. Look, here is the cloning in action
(mangled to protect the innocent):

2018-02-05 13:13:18 1eimCc-EV-Nv <= david@alum U=david P=local S=1956 
id=20180205191318.GC32350@alum
2018-02-05 13:13:21 1eimCc-EV-Nv => debian-user@lists.debian.org 
R=smarthost T=remote_smtp_smarthost H=smtp.lionunicorn.co.uk [149.255.60.164] 
X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128 DN="OU=Domain Control 
Validated,OU=PositiveSSL Wildcard,CN=*.unlimitedwebhosting.co.uk"
2018-02-05 13:13:21 1eimCc-EV-Nv -> foo@bar R=smarthost 
T=remote_smtp_smarthost H=smtp.lionunicorn.co.uk [149.255.60.164] 
X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128 DN="OU=Domain Control 
Validated,OU=PositiveSSL Wildcard,CN=*.unlimitedwebhosting.co.uk"
2018-02-05 13:13:21 1eimCc-EV-Nv Completed

Cheers,
David.

Re: [Was: Re: policy around 'wontfix' bug tag

[David Wright]

On Tue 06 Feb 2018 at 12:32:06 (+1100), Erik Christiansen wrote:
> On 05.02.18 09:39, Greg Wooledge wrote:
> > On Sun, Feb 04, 2018 at 04:04:34PM +0100, Nicolas George wrote:
> > > All you describe is convenience for programmatic use. As I explained,
> > > this parser is meant for interactive use.
> > 
> > What on EARTH made you think THAT?
> 
> The fuzzy grammar of the date string makes programmatic use a bit
> empirical, I must admit.
> 
> > I promise you, people ARE using date -d '...' in shell scripts.
> > LOTS of people.  Hell, I've done it.(*)
> 
> A data point: I have been using "date" for a good 30 years, on hp-ux,
> SunOS, Solaris, and now linux - pretty much _exclusively_ in scripts,
> even with -d. An example still in use even scripts the "human readable"
> input:
> 
> #!/bin/bash
> [ `date '+%H'` -lt 4 ] && day="yesterday" || day="today"
> d="`date -d $day '+%a %b %_d'`"
> ...
> echo "`date -d $day '+%a %b %_d'`" $n >> ~/fetchmail_traffic
> 
> If a new formal grammar largely consistent with the "mostly free format
> human readable date string" were defined in the manpage, then that could
> be a step forward.

But how would you deal with the simplest (to express) problem of all,
that of

$ date -d 1/2/18
Tue Jan  2 00:00:00 CST 2018
$ 

which would mean a battery of locale-specific rules.

> And for the far past, cal is superior; compare:
> 
> $ cal -3 9 1752
> August 1752  September 1752 October 1752  
> Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  
>1 1  2 14 15 16   1  2  3  4  5  6  7  
>  2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14  
>  9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21  
> 16 17 18 19 20 21 2222 23 24 25 26 27 28  
> 23 24 25 26 27 28 2929 30 31  
> 30 31

That works for the British Empire at and since that time. In the years
before that, there are at least two problems with historic dates:

some places had already moved onto the Gregorian calendar years
earlier,

for dates before Lady Day, you need to know if the recorded date
was "Old Style" or "New Style", else you'll be off by one.

Cheers,
David.

Re: [Was: Re: policy around 'wontfix' bug tag

[Michael Stone]

On Tue, Feb 06, 2018 at 12:32:06PM +1100, Erik Christiansen wrote:

And for the far past, cal is superior; compare:

$ cal -3 9 1752
   August 1752  September 1752 October 1752
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
  1 1  2 14 15 16   1  2  3  4  5  6  7
2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14
9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21
16 17 18 19 20 21 2222 23 24 25 26 27 28
23 24 25 26 27 28 2929 30 31
30 31


Unfortunately, as cal isn't locale-aware, it's just wrong. :)
ncal handles (some) country codes.

Mike Stone

Re: [Was: Re: policy around 'wontfix' bug tag

[Michael Stone]

On Mon, Feb 05, 2018 at 08:13:10PM -0600, David Wright wrote:

But how would you deal with the simplest (to express) problem of all,
that of

$ date -d 1/2/18
Tue Jan  2 00:00:00 CST 2018
$

which would mean a battery of locale-specific rules.


Yup. You'd need to accept something (probably iso8601) by default, then 
require a format specifier for anything else. "locale specific 
formatting rules" is one possible format specifier, but that should be 
explicit.


Mike Stone

Re: [Was: Re: policy around 'wontfix' bug tag

[Richard Hector]

On 06/02/18 15:24, Michael Stone wrote:
> On Tue, Feb 06, 2018 at 12:32:06PM +1100, Erik Christiansen wrote:
>> And for the far past, cal is superior; compare:
>>
>> $ cal -3 9 1752
>>    August 1752  September 1752 October 1752
>> Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
>>   1 1  2 14 15 16   1  2  3  4  5  6  7
>> 2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14
>> 9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21
>> 16 17 18 19 20 21 22    22 23 24 25 26 27 28
>> 23 24 25 26 27 28 29    29 30 31
>> 30 31
> 
> Unfortunately, as cal isn't locale-aware, it's just wrong. :)
> ncal handles (some) country codes.

... and how do you deal with locales that have changed definition over
time? What was the country code for (eg) Prussia in 1752? It just gets
painful ...

Richard




signature.asc
Description: OpenPGP digital signature

Re: [Was: Re: policy around 'wontfix' bug tag

[Michael Stone]

On Tue, Feb 06, 2018 at 03:36:53PM +1300, Richard Hector wrote:

On 06/02/18 15:24, Michael Stone wrote:

On Tue, Feb 06, 2018 at 12:32:06PM +1100, Erik Christiansen wrote:

And for the far past, cal is superior; compare:

$ cal -3 9 1752
   August 1752  September 1752 October 1752
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
  1 1  2 14 15 16   1  2  3  4  5  6  7
2  3  4  5  6  7  8  17 18 19 20 21 22 23   8  9 10 11 12 13 14
9 10 11 12 13 14 15  24 25 26 27 28 29 30  15 16 17 18 19 20 21
16 17 18 19 20 21 22    22 23 24 25 26 27 28
23 24 25 26 27 28 29    29 30 31
30 31


Unfortunately, as cal isn't locale-aware, it's just wrong. :)
ncal handles (some) country codes.


... and how do you deal with locales that have changed definition over
time? What was the country code for (eg) Prussia in 1752? It just gets
painful ...


Yes, this is more a novelty than anything. Even apart from changing 
national borders, things were seldom as uniform within a country 200+ 
years ago as a single cutover date would imply, and the very concept 
of "country" is anachronistic for the cutover dates in the 16th century. 
But at least ncal tries. :) To bring things full circle to the date(1) 
discussion, note that ncal was introduced so cal could remain 
bug-compatible.


Mike Stone

Re: [Was: Re: policy around 'wontfix' bug tag

[Richard Hector]

On 06/02/18 15:45, Michael Stone wrote:
>> ... and how do you deal with locales that have changed definition over
>> time? What was the country code for (eg) Prussia in 1752? It just gets
>> painful ...
> 
> Yes, this is more a novelty than anything. Even apart from changing
> national borders, things were seldom as uniform within a country 200+
> years ago as a single cutover date would imply, and the very concept of
> "country" is anachronistic for the cutover dates in the 16th century.
> But at least ncal tries. :) To bring things full circle to the date(1)
> discussion, note that ncal was introduced so cal could remain
> bug-compatible.

Well, as the OP, to bring it properly full circle, I should be clear
that I'm mostly happy with the reasons for not fixing these 'bugs'. I
would just like to have seen the reason with the wontfix :-)

Richard



signature.asc
Description: OpenPGP digital signature

Reply to sender, Reply to list (was: policy around 'wontfix' bug tag)

[Ben Finney]

Richard Hector  writes:

> On 06/02/18 02:11, Vincent Lefevre wrote:
> > On 2018-02-05 01:53:02 +1300, Richard Hector wrote:
> > You should set up a "Mail-Followup-To:" for that.

For reference, this refers to one of two proposed (but never
standardised) fields “Mail-Followup-To” and “Mail-Reply-To”
https://cr.yp.to/proto/replyto.html>.

> I could do that, I'm sure (though I'm not sure how) - but I'd rather
> that someone intending to send me a private reply didn't send it to the
> list by mistake. Having to (in my case) click 'Reply to List' helps me
> not send to the list by mistake.

That's correct. The recipient isn't in a position to guess the intention
of the person composing the message; the responsibility is on the person
composing the reply, to choose “reply to sender” or “reply to list”.

If you, when composing a reply, mean to reply to the sender, use that
command in your mail client. It will go to the “Reply-To” address, or
(if that's not present) the sender address.

If you, when composing a reply, mean to reply to the mailing list, use
that command in your mail client. It will go to the declared mailing
list address (either that, or your mail client is broken for not
recognising the mailing list address in every mailing list message).

> > This is entirely your problem.
>
> The behaviour and policy of this list, when followed, does what I
> want.

Right. In particular the current list behaviour – don't alter or set
Reply-To – and Richard's messages – absence of any custom field
“Mail-Followup-To” or “Mail-Reply-To” – leaves the default behaviour,
and the default behaviour is what Richard wants.

There is often a call for changing the mailing list program so that it
manipulates the header fields for redirecting replies to sender. This is
simply a mistake, as explained in several places, e.g.
http://marc.merlins.org/netrants/reply-to-still-harmful.html>. I
didn't see anyone so far call for that alteration, but it pops up in
these discussion too often so the above document bears repeating.

As I understand it from this thread, Richard (and I, for what it's
worth) do not want to alter the default behaviour of either “reply to
sender” nor “reply to list”. Those MUA commands, if implemented per
existing standards, will each compose a message to the correct address
for the chosen function.

So the default behaviour, of the *command chosen by the person composing
a reply*, matches the reply behaviour of Richard, and I, for each of the
reply commands. This does not need any of us making any special
alterations to any message header fields.

The person composing a reply is the only one in a position to know
whether they want the “reply to sender” or “reply to list” command. (And
if they don't have one or both of those commands available, it is only
in their power to choose a better MUA.) Don't expect the mailing list,
nor individual posters, to second guess you on that.

This has all been hashed out here in the past many times, but it is good
to refresh the references and facts again.

-- 
 \ “I thought I'd begin by reading a poem by Shakespeare, but then |
  `\ I thought ‘Why should I? He never reads any of mine.’” —Spike |
_o__) Milligan |
Ben Finney

Re: policy around 'wontfix' bug tag

[The Wanderer]

On 2018-02-05 at 13:47, Brian wrote:

> On Mon 05 Feb 2018 at 10:24:14 -0500, The Wanderer wrote:

>> If there's an ongoing discussion on that mailing list, and one of
>> the participants wants to draw in a third person who also
>> subscribes, it's entirely appropriate to CC a reply to that third
>> party.
> 
> Definitely (whether they are known to subscribe or not).
> 
> Which brings us back to - how does one know someone is subscribed to
> a Debian mailing list?

I still fail to see why that's something we would need to know.

Whether or not the person who posted a given message is subscribed does
not change the correct replying behavior. In both cases, unless the
poster has in some way requested otherwise, replies should go to the
mailing list.

And, as you cite, the same "whether subscribed or not" applies equally
when deciding whether to CC in a new person to an ongoing discussion.

>> However, if this were to happen with me, I would not want to
>> receive *only* the mailing-list copy. I would want to receive both:
>> the mailing-list copy to go into my local archive of the mailing
>> list (and to be present in the mailing list's folder, so that it
>> appears properly threaded with other replies), and the direct copy
>> to draw my attention to the subject. (Although I would probably
>> then seek out the mailing-list copy and reply to that. But that's a
>> personal idiosyncrasy.)
> 
> Seeking out is time-consuming. A recipe for automation is given in 
> another post. It gives you everything you want.

If I'm correct in understanding which other post you're talking about:

I'm not sure that recipe does/would do everything I want, and it seems
to be specific to a mail client which I don't use and which I'm not sure
provides all the features / behaviors I want in a mail client.

It's still interesting for reference, if nothing else, however.

-- 
   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: policy around 'wontfix' bug tag

[Erik Christiansen]

On 05.02.18 10:02, Michael Stone wrote:
> IIRC it started out as a YACC function in the late 80s, and is now a Bison
> (YACC+GNU extensions) library.

In that case it has a precise grammar, expressed in BNF (Backus Naur
Form), though the lexer (I've always used lex together with
yacc/bison) could add a bit of elastic if the designer had a
free-wheeling approach. The existing flexibility then arises primarily
from explicit alternatives in grammar rules.

A BNF grammar is ideal for discussing in abstraction from the code, and
could be tweaked, both to correct erroneous results, and to add
alternative syntax which is more user-immune, if that is desired.
(But GIGO can also be cured by eliminating the GI.)

In any event, the one purportedly strange grammar example presented so
far was straightforward, both in behaviour and analysis. The one other
proposed as a challenge was nothing other than dd/mm order ambiguity.
(Purely a geographically isolated input confusion, having nothing to do
with "date".)

> There are still people who work on it--the debug option added a couple
> of years ago has made it *much* easier to understand why it does the
> things that it does. I'm not sure that if I were implementing a new
> option I'd use the bison code at all (it does probably limit the
> contributor pool).

A fork, with a new name, is on open prairie. For my money, the BNF
grammar and bison is an asset. (Even if debugging shift/reduce and
reduce/reduce conflicts can necessitate resort to old notes from previous
efforts, until one is back up to speed.)

> The bigger issues aren't the choice of implementation language,
> they're 1) getting buy-in on what the replacement should look like and
> 2) getting people to use something different. It's tough, because
> almost every linux system out there has date(1) with the existing -d
> parser, and it's easier to assume that's there than to use something
> else. (E.g., it's possible to use python or perl or other scripting
> language one-liners with any number of date libraries to add much more
> maintainable date handling to their scripts, but most people just
> stick with the date(1) they know rather than using one of the
> alternatives.)

But date(1) is fine as-is, as great now as 30 years ago - better even.
If newcomers would suggest grammar extensions (in BNF), then they could
perhaps be trialled.

Perl is the quintessential write-only language, which with a bit of luck
will die out before it catches on, and is python that monstrosity which
lacks code block delimiting, and so uses indenting in lieu?

Erik

-- 
> Am I correct that perl5-porters is the proper forum for submitting
> my ideas?
I think you didn't get a reply because you used the terms "correct" and
"proper", neither of which has much meaning in Perl culture. :-)
   -Larry Wall

Constatez vos déséquilibres métaboliques

[[Hippocrate]]

 

_ 

 _ Cliquez ici pour vous inscrire ou inviter vos amis à s'inscrire à
la Newsletter de Bertrand Canavy en leur transférant cet email
[http://links.learnymail.fr/c/i5_/F2Rb/T1rfnJt6dhPF0UBDkwI_Ey/mzY/LySD/60515edb


Bonjour 

Chère Lectrice, Cher Lecteur,
 

CONSTATEZ VOS DÉSÉQUILIBRES MÉTABOLIQUES

Avez-vous remarqué comme votre fatigue a le don de vous rendre
sourd(e) et aveugle au langage de votre corps ? Nous allons vous
aider à comprendre le langage de votre corps.

VÉRIFIEZ VOTRE PH URINAIRE

Il s’agit de recueillir une petite quantité de vos urines du matin
(ne pas récolter la première miction), du midi et du soir, d’y
plonger pendant quelques secondes une petite languette-test (marque
Biosana en magasins diététiques) et de vérifier leur taux
d’acidité en comparant la couleur du papier réactif à celle de
l’échelle-référence.

Normalement, votre taux de PH urinaire doit se situer entre 6,5 et
7,5. Au-dessous de 6,5, vous êtes en acidité et devenez la cible
potentielle de symptômes multiples et variés.

La malnutrition, la suralimentation, le stress, le manque
d’oxygénation, tout autant que les pensées négatives, sont les
grands responsables de ce déséquilibre. En facilitant la production
de ces acides, ils entraînent l’apparition d’une longue liste de
troubles plus ou moins associés, dont notamment : fatigabilité et
frilosité, manque chronique d’énergie, difficulté à récupérer,
tendance dépressive, douleurs musculaires et articulaires, grande
réceptivité aux infections, sensibilité accrue à la douleur, aux
variations de température, caries, cheveux ternes et chute, etc.

Comment venir à bout de cette acidité nocive ? Dans un premier
temps, adoptez un régime supprimant tous les aliments acidifiants,
privilégiez les aliments basiques et rééquilibrez vos habitudes
alimentaires. Et si ce n’est pas suffisant, prenez un complément
alimentaire spécifique (cf. Étape Nº 5).

– Notre conseil : poursuivez ce test pendant 15 jours, notez votre
taux des 3 prises et ce que vous avez mangé chaque jour et à chacun
des repas. C’est important car le PH varie selon votre alimentation.

Cette mesure est une bonne habitude à prendre, surtout dès que vous
ne vous sentez pas dans votre assiette.

 

ET QUE DIT LA LANGUE ?

La texture et la couleur de votre langue peuvent vous donner de
précieux renseignements sur votre état de santé. Observez si elle
est :

– Rose comme celle d’un bébé : vous pouvez dormir sur vos deux
oreilles, vous êtes en pleine forme.

– Blanche : elle peut révéler une anémie et une stagnation de
votre circulation sanguine (néanmoins, lors d’un jeûne ou d’une
mono-diète, elle se charge et indique que l’organisme se détoxine.
C’est donc normal).

– Épaisse et jaune : elle indique que votre foie et votre
vésicule biliaire dysfonctionnent.

– Avec des taches blanches : vous devriez normalement ressentir une
fatigue générale de vos fonctions digestives.

– Bleue ou violette : vous consommez trop de médicaments et de
produits chimiques.

– Notre conseil : lorsque vous vous lavez les dents, brossez-vous
la langue pour nettoyer son encrassement.

---

Ce message pourrait intéresser un de vos amis ami ou un de vos
proches? N'hésitez pas à le transférer.

Si vous n'êtes pas encore abonné et que vous souhaitez vous aussi
recevoir cette newsletter gratuitement, RENDEZ-VOUS ICI
[http://links.learnymail.fr/c/i5_/F2Ro/T1rfnJt6dhPF0UBDkwI_Ey/mzY/LySD/d5e56da2

---

Les informations données et les thérapies proposées ne constituent
jamais, en aucun cas, une démarche de diagnostic ou de traitement des
maladies. Elles sont données de bonne foi, dans le but d’être
utiles aux personnes capables d’autonomie, en quête de santé
naturelle, et sont mises à jour en fonction des expérimentations et
des informations progressivement disponibles. Ainsi, chaque personne
qui utilise à son profit les informations données, le fait sous sa
propre responsabilité et doit, à chaque fois, faire preuve du plus
grand discernement. Il est à noter également que les termes de
"diagnostic", de "patient", de "thérapie" ou de "guérison" ne
doivent pas être entendus dans le sens de la médecine allopathique.

_La Lettre de Bertrand Canavy _est un service d'information gratuit
du Groupe Hippocrate INC.

Pour toute question, contactez-nous : cli...@hippocrate.net
[http://links.learnymail.fr/c/i5_/F2RL/T1rfnJt6dhPF0UBDkwI_Ey/mzY/LySD/6b0bf94f

---

Chaleureusement,

L'équipe HIPPOCRATE
cli...@hippocrate.net
[http://links.learnymail.fr/c/i5_/F2Ri/T1rfnJt6dhPF0UBDkwI_Ey/mzY/LySD/50193b2f
http://links.learnymail.fr/c/i5_/F2R7/T1rfnJt6dhPF0UBDkwI_Ey/mzY/LySD/8cd74443
[http://links.learnymail.fr/c/i5_/F2R2/T1rfnJt6dhPF0UBDkwI_Ey/mzY/LySD/a66dbaa8

 

 

 [http://links.learnymail.fr/c/i5_/F2RX/T1rfnJt6dhPF0UBDkwI_Ey/mzY/LySD/c1e002e3
 [http://links.learnymail.fr/c/i5_/F2R6/T1rfnJt6dhPF0UBDkwI_Ey/mzY/LySD/e9eadc61
 [http://links.learnymail.fr/c/i5_/

Re: policy around 'wontfix' bug tag

[Richard Hector]

On 06/02/18 18:38, Erik Christiansen wrote:
> Perl is the quintessential write-only language, which with a bit of luck
> will die out before it catches on

Now you're getting to fighting talk ... :-)

Richard




signature.asc
Description: OpenPGP digital signature

Re: Frustration over Debian naming

[Paul Wise]

On Tue, Feb 6, 2018 at 6:17 AM, Jonathan de Boyne Pollard wrote:

> Tangentially to that, it seems that someone needs to pick up the dropped
> baton and update the pictures.

Those are all copies of a diagram by Claudio Filho, if anyone updates
it, please send him a pull request to update the official repository:

http://cfnarede.com.br/en/infographic-of-debian
https://github.com/filhocf/infographics

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [Was: Re: policy around 'wontfix' bug tag

[Glenn English]

>> I promise you, people ARE using date -d '...' in shell scripts.
>> LOTS of people.  Hell, I've done it.(*)

The Java Gregorian Calendar class was a delightful piece of software
when I last used it (15 or so years ago). It does know the difference
between the Julian and Gregorian calendars, among other things. I used
it in a lease generation program; the program is still in use, and
it's never made a mistake. AFAIK.

Not as easy to use as Bash, though...

-- 
Glenn English