Unsubscribe
On Tue, Apr 20, 2021 at 1:50 PM <debian-user-digest-requ...@lists.debian.org>
wrote:
> Content-Type: text/plain
>
> debian-user-digest Digest Volume 2021 :
> Issue 410
>
> Today's Topics:
> Re: Postfix configuration on Bullsey [ Darac Marjal <
> mailingl...@darac.org ]
> Buster Apache php website in other l [ john doe <johndoe65...@mail.com>
> ]
> Re: Strange emacs behavior after upg [ Rainer Dorsch <m...@bokomoko.de> ]
> Re: Strange emacs behavior after upg [ Rainer Dorsch <m...@bokomoko.de> ]
> Re: Strange emacs behavior after upg [ <to...@tuxteam.de> ]
> Re: Buster Apache php website in oth [ IL Ka <kazakevichi...@gmail.com>
> ]
> Apology; misleading statement about [ rhkra...@gmail.com ]
> Re: Strange emacs behavior after upg [ Greg Wooledge <g...@wooledge.org>
> ]
> Date: Tue, 20 Apr 2021 08:51:29 +0100
> From: Darac Marjal <mailingl...@darac.org.uk>
> To: debian-user@lists.debian.org
> Subject: Re: Postfix configuration on Bullseye
> Message-ID: <d068f714-181d-8be3-211b-362d0b9b5...@darac.org.uk>
> Content-Type: multipart/signed; micalg=pgp-sha256;
> protocol="application/pgp-signature";
> boundary="cXiLyYr1h7hktnun1qRKqfgTA5kxJnbj7"
>
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --cXiLyYr1h7hktnun1qRKqfgTA5kxJnbj7
> Content-Type: multipart/mixed;
> boundary="vaHTE3qsZ9Kr7kII2tmvpoZf3QCu1zFL7";
> protected-headers="v1"
> From: Darac Marjal <mailingl...@darac.org.uk>
> To: debian-user@lists.debian.org
> Message-ID: <d068f714-181d-8be3-211b-362d0b9b5...@darac.org.uk>
> Subject: Re: Postfix configuration on Bullseye
> References: <20210419170855.3e7a4b3d@hawk.localdomain>
> In-Reply-To: <20210419170855.3e7a4b3d@hawk.localdomain>
>
> --vaHTE3qsZ9Kr7kII2tmvpoZf3QCu1zFL7
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
> Content-Language: en-GB
>
>
> On 20/04/2021 00:08, Charles Curley wrote:
> > On installing on Bullseye, I usually install postfix, then configure it=
>
> > with "dpkg-reconfigure postfix".
> >
> > I use postfix here only for logwatch and other system emails, so the
> > setup isn't concerned with the Internet at large.
> >
> > The default list of systems to accept mail for doesn't look right to me=
> :
> >
> > grissom.localdomain, grissom.localdomain, localhost.localdomain, , loca=
> lhost
> >
> > * Why is the fully qualified host name in there twice, but not the
> > hostname alone ("grissom")? (localdomain is my local TLD on a private=
>
> > network.)
> >
> > * What with the two commas toward the end?
> >
> > Shouldn't that be
> >
> > grissom.localdomain, grissom, localhost.localdomain, localhost
>
> This looks to come from the debian/postfix.config file, and is thus part
> of the Debian packaging of postfix, rather than an upstream thing. In
> that file, at line 228, we see:=C2=A0
>
> if ($mailertype eq "Internet Site") { if ($mailname eq $hostname) {
> $destinations =3D join ", ",("\$myhostname", $mailname, "localhost." .
> $domain, ", localhost"); } else { $destinations =3D join ",
> ",("\$myhostname", $mailname, $hostname, "localhost." . $domain . ",
> localhost"); } } else { # don't accept mail for $mailname by default if
> we have a relayhost or local only mail, # unless the mailname bears no
> resemblance to $myorigin. $destinations =3D join ", ",("\$myhostname",
> $hostname, "localhost." . $domain . ", localhost" ); unless ( $hostname
> =3D~ m/(^|[\.])$mailname$/ ) { $destinations =3D $mailname . ", " .
> $destinations; } }
>
> [ Taken from
> https://sources.debian.org/src/postfix/3.5.6-1/debian/postfix.config/#L22=
> 8,
> which might be easier to read if that wraps ]
>
> This is perl, so the join() function takes a string and an array and
> delimits the array with the string. So, if we take the first one as an
> example, the literal string "$myhostname" is followed by a comma-space,
> then the value in the "mailname" variable, then the literal string
> "localhost." with the "domain" variable appended, then another
> comma-space. Finally, the last element to be added to the list is ",
> localhost". I don't know why this was written this way, but it means
> that in every case, the "destinations" variable will end with ", ,
> localhost"
>
> Sadly, the earliest revision I can find of this file on salsa.debian.org
> (https://salsa.debian.org/postfix-team/postfix-dev/-/commit/a0577ca96dda9=
> c4e5e5bc9dd0c5b7cfc545c5804#ac03215119d5f2efaeb830653c7f84124ceed640_0_19=
> <https://salsa.debian.org/postfix-team/postfix-dev/-/commit/a0577ca96dda9=c4e5e5bc9dd0c5b7cfc545c5804#ac03215119d5f2efaeb830653c7f84124ceed640_0_19=>
> 2)
> already has the ", localhost" code in it, so I can't say why it was
> written like that.
>
> On the upside, though, this is an allowlist of domains postfix will
> accept mail for. If there are duplicates, it shouldn't REALLY make much
> difference. It's a nice to fix (just because, if you can't explain why
> the code is doing something weird, you can't adequately say whether it's
> a problem or not).
>
>
>
>
>
> --vaHTE3qsZ9Kr7kII2tmvpoZf3QCu1zFL7--
>
> --cXiLyYr1h7hktnun1qRKqfgTA5kxJnbj7
> Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="OpenPGP_signature"
>
> -----BEGIN PGP SIGNATURE-----
>
>
> wsF5BAABCAAjFiEE1A0c5XWknk+U2MemZUdBNabqRbUFAmB+iAEFAwAAAAAACgkQZUdBNabqRbVI
>
> /w//Qbu4LUw6DrwoeLlbbcu4tu1VEsWxxZwTnbnfuY8LA136ZbvokL1A893us9RN8O4UBm1gL7Ma
>
> WstUSFRcEszytml2hO2oF2vxQ3gQoLf9qyvqdwa2XDpga78bkX+iKX1gVzIE0Q09q5EMiS3PyjP8
>
> qzYoUZO1TSAxYQxRvZzG3cqBRavOWqZ57Ck/dtEXvMrqbXLhF+HI3KGdyXqu/5MtigSaHR/YHB2K
>
> ejvhbOI6FpFGdcsS1oZwNBgI8dHYyHOpcgwUOPFZ7uZ4GLEmzJ93AiTo32ML5C7K47J0HOaaiX3q
>
> BB2VqgHqWNUSUla4/sU3YBeCIk4MK/AZXQ3igKh4jq3Z65hYX+tFOtDJDCVHBR2mZUyme1Dw8Aw5
>
> wT4zfxkdsUvwp/dxUIKKDZz4B94ZRmACn8uOLjnCh4dEyTYIYmmv3S2D0Uu32tJ3s56qzepbw9yT
>
> RbJ7TGdtM5a9/JxRo68OMDy+TpC8jh7k7buKdE72MpH8CVag7d0/9meN2z40+VkihPUZgZnsONej
>
> VzkS9dxEhNzeoF+PyKMYS7LIaYXVtt01dT0TPQbIJk6vC/wGESA+cYW8n3FX6dDZHgHWftCRlPzC
>
> 9CUOOjEUfigJjl2ceqw1SuGm8r7gxh+t1vqypatDJFq0Dm5v32NF/tw9kijU/jRT8Ma2aul6uf1q
> xhY=
> =hYQh
> -----END PGP SIGNATURE-----
>
> --cXiLyYr1h7hktnun1qRKqfgTA5kxJnbj7--
> Date: Tue, 20 Apr 2021 10:48:01 +0200
> From: john doe <johndoe65...@mail.com>
> To: debian-user@lists.debian.org
> Subject: Buster Apache php website in other lang than os
> Message-ID: <cd884d0b-fcd1-bcb0-4bb0-3bf05070f...@mail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> Hello all,
>
> I'm playing with Apache2 and php.
>
> I'm making a website in an other language than the one Debian Buster is
> using.
>
> That is, Buster is in English but the website is written in Duch or any
> other language then English.
>
> What do I need to do in Apache and in PHP for it to properly render the
> language the website is written in?
>
> Do I need to generate the locales for the desired languages?
> Do I need to also do something in Apache?
>
> Any help is appriciated.
>
> =2D-
> John Doe
> Date: Tue, 20 Apr 2021 12:00:05 +0200
> From: Rainer Dorsch <m...@bokomoko.de>
> To: debian-user@lists.debian.org
> Cc: r...@defaultvalue.org
> Subject: Re: Strange emacs behavior after upgrade to bullseye
> Message-ID: <2471421.Vo8s8j03hE@h370>
> Content-Transfer-Encoding: 7Bit
> Content-Type: text/plain; charset="us-ascii"
>
> Am Montag, 19. April 2021, 22:25:44 CEST schrieb to...@tuxteam.de:
> > On Mon, Apr 19, 2021 at 06:48:41PM +0200, Rainer Dorsch wrote:
> > > Hello,
> > >
> > > I hit a strange emacs issue, which appeared after upgrading to
> bullseye (I
> > > think):
> > >
> > > I have a virtualbox filesystem mounted using the standard virtualbox
> > > mechanisms:
> > >
> > > rd@Testing:~$ mount |grep dor1rt
> > > dor1rt on /mnt/dor1rt type vboxsf (rw,nodev,relatime)
> > > rd@Testing:~$
> > >
> > > rd@Testing:~$ ls -l /mnt/dor1rt/Local/Managed/sb.blog
> > > -rwxrwxrwx 1 root root 47086 Apr 19 13:40
> > > /mnt/dor1rt/Local/Managed/sb.blog
> > > rd@Testing:~$
> >
> > Perhaps Emacs is trying to write a backup file to the directory.
> > Does it have write access to the containing directory?
> >
> > Cf. the variable `make-backup-files' and those linked in its doc
> > (for this, do C-h v make-backup-files).
> >
>
> There is nothing which would not allow emacs to write a backup file in
> that
> directory
>
> rd@Testing:~/local/Managed$ touch test.txt
> rd@Testing:~/local/Managed$ ls -l test.txt
> -rwxrwxrwx 1 root root 0 Apr 20 11:48 test.txt
> rd@Testing:~/local/Managed$ rm -rf test.txt
> rd@Testing:~/local/Managed$
>
> For me the crucial message is
>
> basic-save-buffer-2: Unlocking file: Operation not permitted,
> /mnt/dor1rt/Local/
> Managed/sb.blog
>
> (~/local is a symlink to /mnt/dor1rt/Local/)
>
> What does this message exactly mean and what is emacs trying to do here?
>
> Other editors (vi, kate) don't report any issue when performain an edit
> operation. Is emacs trying to derive permissions in a different way?
>
> Thanks
> Rainer
>
> --
> Rainer Dorsch
> http://bokomoko.de/
> Date: Tue, 20 Apr 2021 12:06:10 +0200
> From: Rainer Dorsch <m...@bokomoko.de>
> To: debian-user@lists.debian.org
> Cc: r...@defaultvalue.org
> Subject: Re: Strange emacs behavior after upgrade to bullseye
> Message-ID: <3383343.QosJHDYyhU@h370>
> Content-Transfer-Encoding: 7Bit
> Content-Type: text/plain; charset="us-ascii"
>
> Just another update which makes emacs behavior even stranger:
>
> Even though emacs reports when saving
>
> basic-save-buffer-2: Unlocking file: Operation not permitted,
> /mnt/dor1rt/Local/ Managed/sb.blog
>
> the file gets saved!
>
> I think somehow emacs gets out of sync with the real system.
>
> Rainer
>
>
> Am Dienstag, 20. April 2021, 12:00:05 CEST schrieb Rainer Dorsch:
> > Am Montag, 19. April 2021, 22:25:44 CEST schrieb to...@tuxteam.de:
> > > On Mon, Apr 19, 2021 at 06:48:41PM +0200, Rainer Dorsch wrote:
> > > > Hello,
> > > >
> > > > I hit a strange emacs issue, which appeared after upgrading to
> bullseye
> > > > (I
> > > > think):
> > > >
> > > > I have a virtualbox filesystem mounted using the standard virtualbox
> > > > mechanisms:
> > > >
> > > > rd@Testing:~$ mount |grep dor1rt
> > > > dor1rt on /mnt/dor1rt type vboxsf (rw,nodev,relatime)
> > > > rd@Testing:~$
> > > >
> > > > rd@Testing:~$ ls -l /mnt/dor1rt/Local/Managed/sb.blog
> > > > -rwxrwxrwx 1 root root 47086 Apr 19 13:40
> > > > /mnt/dor1rt/Local/Managed/sb.blog
> > > > rd@Testing:~$
> > >
> > > Perhaps Emacs is trying to write a backup file to the directory.
> > > Does it have write access to the containing directory?
> > >
> > > Cf. the variable `make-backup-files' and those linked in its doc
> > > (for this, do C-h v make-backup-files).
> >
> > There is nothing which would not allow emacs to write a backup file in
> that
> > directory
> >
> > rd@Testing:~/local/Managed$ touch test.txt
> > rd@Testing:~/local/Managed$ ls -l test.txt
> > -rwxrwxrwx 1 root root 0 Apr 20 11:48 test.txt
> > rd@Testing:~/local/Managed$ rm -rf test.txt
> > rd@Testing:~/local/Managed$
> >
> > For me the crucial message is
> >
> > basic-save-buffer-2: Unlocking file: Operation not permitted,
> > /mnt/dor1rt/Local/ Managed/sb.blog
> >
> > (~/local is a symlink to /mnt/dor1rt/Local/)
> >
> > What does this message exactly mean and what is emacs trying to do here?
> >
> > Other editors (vi, kate) don't report any issue when performain an edit
> > operation. Is emacs trying to derive permissions in a different way?
> >
> > Thanks
> > Rainer
>
>
> --
> Rainer Dorsch
> http://bokomoko.de/
> Date: Tue, 20 Apr 2021 12:39:13 +0200
> From: <to...@tuxteam.de>
> To: Rainer Dorsch <m...@bokomoko.de>
> Cc: debian-user@lists.debian.org, r...@defaultvalue.org
> Subject: Re: Strange emacs behavior after upgrade to bullseye
> Message-ID: <20210420103913.ga26...@tuxteam.de>
> Content-Type: multipart/signed; micalg=pgp-sha1;
> protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/"
> Content-Disposition: inline
>
> --pWyiEgJYm5f9v55/
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Apr 20, 2021 at 12:00:05PM +0200, Rainer Dorsch wrote:
> > Am Montag, 19. April 2021, 22:25:44 CEST schrieb to...@tuxteam.de:
>
> [...]
>
> > > Perhaps Emacs is trying to write a backup file to the directory.
> > > Does it have write access to the containing directory?
>
> [...]
>
> > There is nothing which would not allow emacs to write a backup file in
> th=
> at=20
> > directory
> >=20
> > rd@Testing:~/local/Managed$ touch test.txt
> > rd@Testing:~/local/Managed$ ls -l test.txt
> > -rwxrwxrwx 1 root root 0 Apr 20 11:48 test.txt
> > rd@Testing:~/local/Managed$ rm -rf test.txt
> > rd@Testing:~/local/Managed$
>
> Strange setup: How does test.text belong to root if you are not root?
> I'd understand that it belongs to group root, that's what the setgid
> bit is for. But _user_ root?
>
> > For me the crucial message is
> >=20
> > basic-save-buffer-2: Unlocking file: Operation not permitted,
> /mnt/dor1rt=
> /Local/
> > Managed/sb.blog
>
> Anyway, this is a good hint. See
>
> "18.3.4 Protection against Simultaneous Editing"
>
> in the Emacs user manual (or, if you prefer reading in a browser,
> here [1].
>
> But your permissions set up is... strange. The above behaviour
> doesn't look plausible to me. Unless rd is actually root.
>
> Cheers
>
> [1]
> https://www.gnu.org/software/emacs//manual/html_node/emacs/Interlocking=
> =2Ehtml
> <https://www.gnu.org/software/emacs//manual/html_node/emacs/Interlocking==2Ehtml>
>
> - t
>
> --pWyiEgJYm5f9v55/
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAmB+r1EACgkQBcgs9XrR2kZhmwCfZuPxU5Al2LpOj1fp2+1x5XvX
> KXoAn0Ziz2uxpo5CSCLhhus/tSpcXlPz
> =fpOo
> -----END PGP SIGNATURE-----
>
> --pWyiEgJYm5f9v55/--
> Date: Tue, 20 Apr 2021 14:15:00 +0300
> From: IL Ka <kazakevichi...@gmail.com>
> To: Debian Users <debian-user@lists.debian.org>
> Subject: Re: Buster Apache php website in other lang than os
> Message-ID: <CAHv=
> rm3jojrbg29h3bnslsynd1srxna9kj1oehmwy0jc5h+...@mail.gmail.com>
> Content-Type: multipart/alternative;
> boundary="0000000000004a1a2405c0658f99"
>
> --0000000000004a1a2405c0658f99
> Content-Type: text/plain; charset="UTF-8"
>
> >
> >
> > What do I need to do in Apache and in PHP for it to properly render the
> > language the website is written in?
> >
> > Do I need to generate the locales for the desired languages?
> > Do I need to also do something in Apache?
> >
>
> Just write your document and save it in utf-8. Be sure to include
> <meta charset="UTF-8">
> tag.
>
> This should be enough to display this page in the modern browser.
>
> If you want to serve different pages based on user language, you can use
> mod_mime
> https://httpd.apache.org/docs/2.4/mod/mod_mime.html#addlanguage
>
> You may also want to set locale: some PHP functions may use it for sorting
> etc.
> https://www.php.net/manual/ru/function.setlocale.php
>
> Generate locale first (see ``locale-gen(8)``) and set its name using
> ``setlocale`` in php.
>
> --0000000000004a1a2405c0658f99
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote
> class=3D"gmail_quot=
> e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid
> rgb(204,204,204)=
> ;padding-left:1ex"><br>What do I need to do in Apache and in PHP for it to
> =
> properly render the<br>
> language the website is written in?<br>
> <br>
> Do I need to generate the locales for the desired languages?<br>
> Do I need to also do something in Apache?<br>
> </blockquote><div><br></div><div>Just write your document and save=C2=A0it
> =
> in utf-8. Be sure to include</div><div>=C2=A0 <meta
> charset=3D"UTF-=
> 8"><br></div><div>tag.</div><div><br></div><div>This should be
> enou=
> gh to display this page in the modern browser.</div><div><br></div><div>If
> =
> you want to serve different pages based on user language, you can use
> mod_m=
> ime</div><div><a href=3D"
> https://httpd.apache.org/docs/2.4/mod/mod_mime.htm=
> l#addlanguage
> <https://httpd.apache.org/docs/2.4/mod/mod_mime.htm=l#addlanguage>">
> https://httpd.apache.org/docs/2.4/mod/mod_mime.html#addlangu=
> age</a><br></div><div><br></div><div>You may also want to set locale: some
> =
> PHP functions may use it for sorting etc.</div><div><a href=3D"
> https://www.=
> php.net/manual/ru/function.setlocale.php">
> https://www.php.net/manual/ru/fun=
> ction.setlocale.php</a><br></div><div><br></div><div>Generate locale first
> =
> (see ``locale-gen(8)``) and set its name using ``setlocale`` in
> php.</div><=
> div>=C2=A0</div></div></div>
>
> --0000000000004a1a2405c0658f99--
> Date: Tue, 20 Apr 2021 07:26:15 -0400
> From: rhkra...@gmail.com
> To: debian-user@lists.debian.org
> Subject: Apology; misleading statement about 64 GB being sufficient
> Message-Id: <202104200726.15758.rhkra...@gmail.com>
> Content-Type: multipart/alternative;
> boundary="Boundary-01=_XprfgzD6rCILWUz"
> Content-Transfer-Encoding: 7bit
>
> --Boundary-01=_XprfgzD6rCILWUz
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> Not too long ago, I made a statement like "64 GB should be enough for
> anybody
> ;-)" (when talking about a new Lenovo micro computer).
>
> It turns out I was wrong, Over on the "Libre-Soc General Development"
> <libre-
> soc-...@lists.libre-soc.org> maillist (where they are working on building
> a
> new basically "open source" microprocessor, iiuc), they have been talking
> about the requirements to compile the Verilog source for part of the
> project.
> Here are some quotes:
>
> <quotes from various emails>
> <from the project lead:>
> as an experiment i extracted the vhdl using yosys, into a verilog file for
> compilation with verilator, which is over 1,000,000 lines long.
>
> from that 1,000,000 line file verilator has produced 3,000 sub-files.
> compiling even the ones with a #include and nothing else takes 10 minutes
> each. estimates for completion of compilation is therefore several weeks.
>
> this is not reasonable unless we have access to a beowulf cluster with
> distcc.
>
> <next>
>
> > > about 200 cores across dozens of machines, each with between 128 and
> 512
> > GB
> > > of RAM.
>
> <next -- this is for a local machine to link those binaries after
> compilation>
>
> > > if you do not have a machine with absolutely mental amounts of RAM
> (like,
> 64 GB or above) we may be able to arrange something.
>
> do not under any circumstances try linking massive binaries once distcc
> gets the object files onto your machine. if you go into swap space
> (during linking), by mistake it will cause your machine to melt. loadavg
> 120 or above is not uncommon.
>
> </quotes from various emails>
>
> I hope I have not caused anyone problems by my misleading statement.
>
>
>
>
> --Boundary-01=_XprfgzD6rCILWUz
> Content-Type: text/html;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "
> http://www.w3.org/TR/REC-html40/strict.dtd";>
> <html><head><meta name="qrichtext" content="1" /><style type="text/css">
> p, li { white-space: pre-wrap; }
> </style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt;
> font-weight:400; font-style:normal;">
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">Not too long ago, I made a statement like "64 GB
> should be enough for anybody ;-)" (when talking about a new Lenovo
> micro computer).</p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">It turns out I was wrong, Over on the "Libre-Soc
> General Development" <libre-soc-...@lists.libre-soc.org>
> maillist (where they are working on building a new basically "open
> source" microprocessor, iiuc), they have been talking about the
> requirements to compile the Verilog source for part of the project. Here
> are some quotes:</p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;"><quotes from various emails></p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;"><from the project lead:></p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">as an experiment i extracted the vhdl using yosys, into
> a verilog file for</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">compilation with verilator, which is over 1,000,000
> lines long.</p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">from that 1,000,000 line file verilator has produced
> 3,000 sub-files.</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">compiling even the ones with a #include and nothing else
> takes 10 minutes</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">each. estimates for completion of compilation is
> therefore several weeks.</p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">this is not reasonable unless we have access to a
> beowulf cluster with</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">distcc.</p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;"><next></p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">> > about 200 cores across dozens of machines,
> each with between 128 and 512</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">> GB</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">> > of RAM.</p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;"><next -- this is for a local machine to link those
> binaries after compilation></p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">> > if you do not have a machine with absolutely
> mental amounts of RAM (like,</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">64 GB or above) we may be able to arrange something.</p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">do not under any circumstances try linking massive
> binaries once distcc</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">gets the object files onto your machine. if you go
> into swap space</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">(during linking), by mistake it will cause your machine
> to melt. loadavg</p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;">120 or above is not uncommon.</p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px;
> -qt-user-state:0;"></quotes from various emails></p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
> margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">I
> hope I have not caused anyone problems by my misleading statement.</p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p>
> <p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px;
> margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;
> "> </p></body></html>
> --Boundary-01=_XprfgzD6rCILWUz--
> Date: Tue, 20 Apr 2021 07:28:19 -0400
> From: Greg Wooledge <g...@wooledge.org>
> To: debian-user@lists.debian.org
> Subject: Re: Strange emacs behavior after upgrade to bullseye
> Message-ID: <yh6606azqevs1...@wooledge.org>
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Apr 20, 2021 at 12:39:13PM +0200, to...@tuxteam.de wrote:
> > On Tue, Apr 20, 2021 at 12:00:05PM +0200, Rainer Dorsch wrote:
> > > For me the crucial message is
> > >
> > > basic-save-buffer-2: Unlocking file: Operation not permitted,
> /mnt/dor1rt/Local/
> > > Managed/sb.blog
> >
> > Anyway, this is a good hint. See
> >
> > "18.3.4 Protection against Simultaneous Editing"
> >
> > in the Emacs user manual (or, if you prefer reading in a browser,
> > here [1].
> >
> > But your permissions set up is... strange. The above behaviour
> > doesn't look plausible to me. Unless rd is actually root.
>
> Or /mnt/dor1rt/Local/ is on a non-Unix file system. Perhaps it's a
> removable USB device with an NTFS or FAT type file system. Or perhaps
> it's some sort of network file system whose underlying implementation
> is not Unix-based.
>
