Re: [DNG] FSF, RMS and a danger to almost all GPL code

[John Morris]

On Sat, 2021-03-27 at 08:30 -0400, Steve Litt wrote:
> And now you're suggesting Devuan put that all at risk to take a stand
> on RMS. Well you know what? No distro should get involved with
> politics, and this RMS thing *is* politics. It cost Mint plenty of
> users when they said supporters of Israel shouldn't use Mint, and it
> just might destroy Devuan if they take a stand, on either side, on
> this RMS thing.

Something struck me as deeply wrong about your post but I couldn't
articulate it.  After much pondering it struck like a bolt and it was
the paragraph above that did it so thanks.  :)

The RMS thing is politics, that is why they want him gone, he won't
inject politics into the the FSF.  And we must fight because we are all
in extreme danger.  Apparently we all just assumed Richard Stallman was
immortal and would always lead the FSF or we wouldn't have done what we
all did.  We must save Richard's bacon long enough for everyone to fix
the problem.

Hang on for a brief diversion, the tale will get back on track.  CoCs. 
They are annoying but can't impact usage.  They can't be avoided in most
projects now because too many developers work for corporations and would
be fired for failure to demand them.  Because Free Software licenses
don't allow restrictions on field of use, they don't impact users at
all.  If enough productive developers decided they didn't like the CoC
they could easily smash it with a Libreoffice gambit.  One way gate. 
Fork a new project site under a new name with a one line CoC sayin "The
only code of conduct is be excellent and never propose editing this
file, it is the only mandatory banning offense."  The new fork can take
every patch from the original but the original can't touch the new site
lest they accept code from people who haven't agreed to the standard
pozzed CoC.  Checkmate, the second a critical mass of independent
developers decide to go for it.

Now imagine Stallman is out at the FSF and somebody tries this.  All
they need do is release the GPL4, allowing CoCs, field of use
restrictions and all the rest of the political nonsense be integrated
into the actual license, impacting developers AND users.  It was your
mentioning Mint's misguided (and certainly unenforcable) attempt to
impose field of use restrictions on their users that got the thought
train going.

It is vital that as many projects as possible get to work NOW to change
their license terms.  Corporate dominated projects are probably already
past the point where they can be saved.  Be prepared to grab the last
available version under a sane license when the time comes, and as
events are moving ever faster, it will come soon.  As of now there are
only three possibilities that are survivable.

GPL2, GPL3 and GPL2 or GPL3 at your option.  No "or later" ever again. 
BSD code of course has no defense when the corporate HR depts come
calling with demands. Nothing to be done about that.  Haven't had time
to look at the other licenses.  Anything with an "or later" clause, be
warned and pay attention to who you are giving unilateral authority to
rewrite the license to.


signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] adding raspi to sources.list

[Gregory Nowak via Dng]

On Tue, Mar 30, 2021 at 09:44:24PM +0200, d...@d404.nl wrote:
> For my regular Pi's i just have the following in my apt sources
> 
> deb http://deb.devuan.org/merged beowulf main
> deb-src http://deb.devuan.org/merged beowulf main
> deb http://deb.devuan.org/merged beowulf-security main
> 
> and this just works.

So, I see there is a linux-image-4.19.0-16-armmp package, which just
provides the kernel in /boot. I also see there is a raspi-firmware
package, which seems to work with the kernel and initramfs-tools to provide
firmware in /boot/firmware. It looks like /boot should be in the root
file system, and /dev/mmcblk0p1 should now be mounted as
/boot/firmware, correct? Does installing linux-image-4.19.0-16-armmp
and raspi-firmware in Beowulf provide the necessary kernel and
firmware to boot a raspberry pi, or are there more packages I need?
For completeness, I'm upgrading to Beowulf on a raspberry pi 2b. Thanks.

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [3.0] Time in AM/PM format ?? [SOLVED]

[Arnt Karlsen]

On Tue, 30 Mar 2021 19:13:00 +0200, Dario wrote in message 
<20210330171300.ga3...@darioniedermann.it>:

> Il 30/03/2021 alle 18:59, Adam Borowski ha scritto:
> 
> >I bet your locale is set to en_US.  
> 
> Indeed it is!
> 
> [...]
> >So in Buster (and thus Beowulf and Chimaera), meaning of "en_US" 
> >changed to include that silly 12-hour time.  
> 
> Surely they couldn't avoid fixing what wasn't broken. Thank you for 
> steering me in the right direction: I found that setting LC_TIME=C 
> is enough to get my 24 hours back.

..oneliner quickie fix: 
Paste the below into all xterms you want fixed:
date &_TIME=C.UTF-8 & LC_TIME &

..longer term fix: locale >>/etc/default/locale
then edit /etc/default/locale to your liking, 
then maybe do an export loop like: 
for i in $(cat /etc/default/locale ) ;do echo $i \
&& export $(echo $i |cut -d"=" -f1 ) & $i \
/etc/default/locale & |grep $i ;done

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] adding raspi to sources.list

[d...@d404.nl]

On 30-03-2021 00:20, Gregory Nowak via Dng wrote:
> On Mon, Mar 29, 2021 at 11:42:00AM +0300, Dimitris via Dng wrote:
>> this package is ascii (not beowulf), so you probably need :
>>
>> deb http://deb.devuan.org/merged ascii raspi
>>
>> d.
> I guess that would explain why it's not indexed in Beowulf. When I add
> the above to my sources.list and apt-get update, I get:
>
> W: Failed to fetch http://deb.devuan.org/merged/dists/ascii/InRelease
> Unable to find expected entry 'raspi/binary-armhf/Packages' in Release
> file (Wrong sources.list entry or malformed file)
>  
> Since this isn't a Beowulf package, I'm probably better off just
> fetching the latest firmware from Raspberry Pi's github repo, or cross
> compile my own from linux stable, since I seem to recall that the
> Raspberry Pi code made it into the main kernel.org source tree a while
> ago. Thanks to everyone for your help.
>
> Greg
>
>
For my regular Pi's i just have the following in my apt sources

deb http://deb.devuan.org/merged beowulf main
deb-src http://deb.devuan.org/merged beowulf main
deb http://deb.devuan.org/merged beowulf-security main

and this just works.

For my Pi 1's and Zero's i have to specify the armel architecture
because apparently Debian arm v6 does not exist.


Grtz.

Nick




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] [3.0] Time in AM/PM format ??

[karl]

Adam Borowski:
...
> The latter have weird customs like a medieval system of measurements, units
> that differ on dry-vs-liquid-vs-slightly-moist, or different distances by
> the same name on air vs land vs survey measurements.

Just go back 50-60years and you'll find that we used a lots of different
"thumb" and other units here also. And it's usage is still lingering although
diminishing. Sometimes it is used as an indication of a person who
"knows" his trade, like 5" nail instead of 125mm nail.

And regarding your last comment, here in Sweden we still use mil (=10km)
and distansminut (=1852m, nautical mile) as a complement to the boring km.

Doesn't the airplane etc. people all arond the globe talk about flying
heights in feet.

And annoyingly many persons excels in using mils (=1/1000 inch) instead 
of mm in the pcb industry even though components with pitch derived from
inch grids are quickly becoming obsolete.

Yea, thoose "medieval" units still has a somewhat strong hold on us all.

...
> And, also, a discontinuous system of time with four non-monotonic segments
> and ambiguous endpoints; marked with "am" and "pm".
...

Isn't it so that all (?) analogue clocks show 0-12 and you must infer
the "am" and "pm" part from context. And in informal situations you
(at least here) say five a'clock, not 17:00. The difference is we use
a 24h clock in formal situations or when we want to be more specific.

///

Upstream date (coreutils) has got a debug flag that might be useful:

$ LC_TIME=sv_SE ./date --debug
./date: output format: ?%a %e %b %Y %H:%M:%S %Z?
tis 30 mar 2021 18:39:34 UTC
$ LC_TIME=en_US ./date --debug
./date: output format: ?%a %d %b %Y %r %Z?
Tue 30 Mar 2021 06:39:38 PM UTC

Regards,
/Karl Hammar


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

Re: [DNG] [3.0] Time in AM/PM format ?? [SOLVED]

[Dario Niedermann]

Il 30/03/2021 alle 18:59, Adam Borowski ha scritto:


I bet your locale is set to en_US.


Indeed it is!

[...]
So in Buster (and thus Beowulf and Chimaera), meaning of "en_US" 
changed to include that silly 12-hour time.


Surely they couldn't avoid fixing what wasn't broken. Thank you for 
steering me in the right direction: I found that setting LC_TIME=C 
is enough to get my 24 hours back.


--
Dario Niedermann   -:-   finger my email address for PGP key, etc.

Also on the Internet at:

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

Re: [DNG] [3.0] Time in AM/PM format ??

[Adam Borowski]

On Tue, Mar 30, 2021 at 06:37:44PM +0200, Dario Niedermann wrote:
> `date` suddenly tells the time in 12-hour format, regardless of $TZ
> (be it empty or 'Europe/').
> 
> Who told it to do that? I certainly didn't.
> 
> I had already noticed this before the recent switch to DST.

I bet your locale is set to en_US.

This setting is used for two unrelated things:
* the default locale for anyone who wants English and doesn't live in
  Britfain or Down Under.
* inhabitants of a silly land to the left of a pond to the left of Europe

The latter have weird customs like a medieval system of measurements, units
that differ on dry-vs-liquid-vs-slightly-moist, or different distances by
the same name on air vs land vs survey measurements.

And, also, a discontinuous system of time with four non-monotonic segments
and ambiguous endpoints; marked with "am" and "pm".

So in Buster (and thus Beowulf and Chimaera), meaning of "en_US" changed to
include that silly 12-hour time.

Ways to fix include:
* C.UTF-8
* en_DK.UTF-8 (for some reason, only Denmark is available -- but it's
  identical for all ways that matter)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] [3.0] Time in AM/PM format ??

[Dario Niedermann]

`date` suddenly tells the time in 12-hour format, regardless of $TZ
(be it empty or 'Europe/').

Who told it to do that? I certainly didn't.

I had already noticed this before the recent switch to DST.

--
Dario Niedermann   -:-   finger my email address for PGP key, etc.

Also on the Internet at:

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

[DNG] No Subject

[dvalin]

On Tue, Mar 30, 2021 Fernando M. Maresca wrote: 
On Tue, Mar 30, 2021 at 07:49:32PM +1030, dva...@internode.on.net
wrote:   > A "locate exim | more" does not elicit anything resembling
a mail
  > destination.
   
  If exim is configured for local delivery (see
  /etc/exim4/update-exim4.conf.conf and read the corresponding man
page
  for /usr/sbin/update-exim4.conf) your mail probably is in
  /var/mail/
   
Many thanks, your email ended up there, and procmail distributed
others.But the emails are not in mbox format, so mutt does not see
them. I can 
find them only by examining the mailbox with vim.
I'll have to find some way to convert those already there, but more
importantly,stop it happening on future fetchmail runs - after
figuring out why it does. :(
On the old host, I run postfix, and that works fine. It's late here.
I'll attack ittomorrow.

Erik

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

[DNG] Air-gapped Beowulf install w/ runit as init

[Olaf Meeuwissen via Dng]

Hi all,

I previously mentioned here[1,2] that the netinst ISO images are no use
for air-gapped installs.  That was for Beowulf beta images and has been
addressed (at least partially, IIRC).  Besides, it *is* documented[3].

So I have been using the server image.  That claims to allow

  for a *complete* off-line server/minimal installation

where the emphasis is mine.

Now the Beowulf 3.1.0 point release announcement[4] says that

  [t]he installer now offers a choice of three init systems. `runit` has
  been added, along with `sysvinit` and `openrc`.

Cool!  Downloaded the 3.1.1 server image and installed, selecting runit
as my init.  No warnings, everything installs fine, system reboots okay,
but ... no runit :-o

What gives?

The installer logs mention that some `runit*` package is not available
(sorry, forgot which one and the logs are gone :-().  Poking around in
the Packages file and pool/ directory on the image, I *think* that may
have been `runit-init`.  A regular, non-air-gapped install has that
package installed and the installer logs show it getting installed in
the `choose-init` "stage" and downloaded from deb.devuan.org.

Considering that `runit-init` is about 40KB and the ISO images are

 netinst  309MB
 server   590MB
 desktop 3658MB

(for amd64) I would prefer to see `runit-init` added to the server image
over downloading the desktop image for air-gapped installs.

It makes a 3GB difference :-o
# But I'll be working around with the desktop image for the time being.

 [1]: https://lists.dyne.org/lurker/message/20200320.010518.98571ef6.en.html
 [2]: https://lists.dyne.org/lurker/message/20200322.113542.8f9ac3d5.en.html
 [3]: https://devuan.org/get-devuan
 [4]: https://devuan.org/os/announce/beowulf-point-release-announce-021421

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Where would exim have put the emails?

[Fernando M. Maresca via Dng]

On Tue, Mar 30, 2021 at 07:49:32PM +1030, dva...@internode.on.net wrote:
 
> A "locate exim | more" does not elicit anything resembling a mail
> destination.

If exim is configured for local delivery (see
/etc/exim4/update-exim4.conf.conf and read the corresponding man page
for /usr/sbin/update-exim4.conf) your mail probably is in
/var/mail/

Regards,
Fer
-- 
Fernando M. Maresca
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Where would exim have put the emails?

[dvalin]

My regrettable rashness in leaving "fetchall" in .fetchmailrc during
the first mail fetch on my new beowulf install has me chasing 91 
lost or mislaid emails.
I also had no "mda" option in .fetchmailrc, so delivery to port
25should feed them to exim, I figure:
# lsof -i4:25
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF NODE
NAME
exim4   2278 Debian-exim    3u  IPv4   1545  0t0 
TCP greipner:smtp (LISTEN)
Although I had:$ more .forward
"|exec /usr/bin/procmail -t"
procmail does not appear to have run, as the .procmailrc from theold
host has not led it to disperse emails to any of a dozen mailboxes,and
there's no mail/log file.A It is there:
$ ls -l /usr/bin/procmail
-rwsr-sr-x 1 root mail 104404 Nov 17  2017 /usr/bin/procmail*

A "locate exim | more" does not elicit anything resembling a mail
destination.
Have I lost 'em, or are there still places to look?
In the interim, I'll ditch the "fetchall" and give "mda procmail" in
.fetchmailrca go Now I remember why I'm reluctant to update stuff.
Erik


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