Re: [DNG] Thunderbird language packs outdated
Am 2017-11-12 08:53, schrieb Edward Bartolo: I would remove all languages that I do not need. Certainly, you do not know 45 languages! Why do you think I have 45 languages installed? You do not need to install thunderbird-l10n-all, there is a single package for every language. For example thunderbird-l10n-de. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On 12/11/17 04:24, Joerg Reisenweber wrote: On Tue 07 November 2017 17:50:27 John Hughes wrote: The separation of / and /usr is a relic of really, really tiny disk sizes. Like, for example, ARMv7 systems with a 128MB NAND to boot from, keeping /usr on a separate storage like SSD? Doesn't sound like an obsolete ancient relic I have a N900, that is not news to me and has already been addressed by Adam Borowski: https://lists.dyne.org/lurker/message/20171108.052040.5cb5ca3d.en.html In the last case I'm aware of where someone tried a stock system with a split, Maemo, the /usr split was deemed inadequate and they instead decided to move most stuff to /opt while stuffing the usual places with symlinks -- adapting packages enough to have / capable of booting would require too much work. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Thunderbird language packs outdated
Quoting J. Fahrner: "Why do you think I have 45 languages installed? You do not need to install thunderbird-l10n-all, there is a single package for every language. For example thunderbird-l10n-de." If that is the case, then, there is no need of hacks. -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) If you cannot make abstructions about details you do not understand the concepts underlying them. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
Quoting John Hughes (j...@atlantech.com): > I have a N900, that is not news to me and has already been addressed > by Adam Borowski: > https://lists.dyne.org/lurker/message/20171108.052040.5cb5ca3d.en.html Adam saying frequently 'There's no gain to put / and /usr on separate filesystem[s]' doesn't make it actually, y'know, correct. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Thunderbird language packs outdated
On Sun, Nov 12, 2017 at 07:41:09AM +0100, J. Fahrner wrote: > Am 2017-11-11 23:00, schrieb KatolaZ: > >You must use either packages.devuan.org, or auto.mirror.devuan.org, or > >pkgmaster.devuan.org. > > auto.mirror.devuan.org makes no difference, still version 45 language packs. > Please look at the package archive before you blame me! :-( > You are right. auto.mirror.devuan.org does not have version 52, and this is probably due to a mis-merge of jessie-security. We will have a look into that. The quick solution is to use pkgmaster.devuan.org then, which uses the new amprolla3. HND KatolaZ P.S.: there is no reason to be angry. I had looked at the package archive and found version 52 because I had also pkgmaster.devuan.org configured there. My mistake. The community is here to help, not to be yelled at :) -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Documentation format philosophies
Le 12/11/2017 à 00:39, Svante Signell a écrit : On Sat, 2017-11-11 at 13:33 -0500, Steve Litt wrote: We use LaTEX in technical documents, LaTeX is wonderful *for what it does*, which is make beautifully typeset documents whose linefeeds are determined at compile time, not at read time (like ePub, HTML or Xhtml). The problem is that you can't reasonably convert LaTeX to XML, HTML, Xhtml or the like. First of all, LaTeX is meant to produce paged documents while HTML hasn't the notion of a page. latex2html can be used to initiate the translation, but you will need to carefully edit the result. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Sun 12 November 2017 09:19:22 John Hughes wrote: > On 12/11/17 04:24, Joerg Reisenweber wrote: > > On Tue 07 November 2017 17:50:27 John Hughes wrote: > >> The separation of / and /usr is a relic of really, really tiny disk > >> sizes. > > > > Like, for example, ARMv7 systems with a 128MB NAND to boot from, keeping > > /usr on a separate storage like SSD? Doesn't sound like an obsolete > > ancient relic > I have a N900, that is not news to me and has already been addressed by > Adam Borowski: > https://lists.dyne.org/lurker/message/20171108.052040.5cb5ca3d.en.html > > > In the last case I'm aware of where someone tried a stock > > system with a split, Maemo, Incorrect, they had a heritage of all stuff living on 240MB root-/ and thus not really "tried" since the migration would have required a complete reflash (instead of a apt-get install update) A quote of well known infobot factoids: >>>optification is a inventive duct tape workaround to reclaim space in fs root, done due to the fact the systeminit *and* partitioning is FUBAR, http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs, or ""OMG - I wish they looked into FHS and moved /usr to eMMC"", http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE2 bullet1,2 and fhs-2.3.html#PURPOSE16 dot3"<<< > >the /usr split was deemed inadequate yes, "inadequate" for an OTA upgrade of a deployed productive system to get done without loss of user data, by push of a GUI button > >and they > > instead decided to move most stuff to /opt while stuffing the usual > > places > > with symlinks -- adapting packages enough to have / capable of booting > > would > > require too much work. The "too much work" argument is a very embarrassing one - it's the genuine duty of distro maintainers to take care of exactly such stuff. The argument that something was "too much work" (for the distro maintainers, or even the developers) is moot unless you're doing all that for yourself or for developers instead of your users. Claiming that a decision whether to put a package into /bin or /usr/bin (resp *sbin*) was "too much work" is also outright silly, there's zero additional workload in placing the package into the right location, except for the needed knowhow and decision itself. It's just for the laziness of developers of boot/init process when they demand to indiscriminately have access to *all* existing binaries in /usr /j ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Different philosophies
Le 10/11/2017 à 15:39, jack da a écrit : following your lead, I seem to be systematically replacing reliance on conventional tools with low-footprint alternatives. This does not mean low tech. Following your lead, I would like to both replace conventional tools with alternatives simpler to understand/amend and with as little entanglement as possible - this is my own view of low footprint, more important than ressource usage. I appreciate a lot your working towards simplification of init, replacing udev by mdev and trying to get rid of dbus. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?
If this is not your field of expertise the you should not call Intel's solution junk. It will not help with disks. What it helps with is applications that need properly independent random numbers often. A VPN server is such a case, it needs a few bits every time a client opens a connection and the clients may be enemies of each other, so it is preferable that each user's session keys have absolutely no relationship to those of other users. A VPN client does not have this need. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] (forw) Re: [skeptic] MINIX: ?Intel's hidden in-chip operating system
On 09-11-17 02:24, Rick Moen wrote: Vaughan-Nichols's article is at http://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/ - Forwarded message from Rick Moen - Date: Wed, 8 Nov 2017 17:19:35 -0800 From: Rick Moen To: skep...@linuxmafia.com Subject: Re: [skeptic] MINIX: ?Intel's hidden in-chip operating system Organization: If you lived here, you'd be $HOME already. Quoting Scott Peterson (scot...@mindspring.com), citing a mostly good Steven J. Vaughan-Nichols's ZDnet article: Buried deep inside your computer's Intel chip is the MINIX operating system and a software stack, which includes networking and a web server. It's slow, hard to get at, and insecure as insecure can be. [...] Garrett's AMT FAQ makes good reading for people wanting to know more. https://mjg59.dreamwidth.org/48429.html?thread=1840429 This includes the fact that by _no_ means do all Intel chipsets possessing ME firmware also have AMT code that runs on it -- and how to query your machine to find out if it does. Most Intel systems don't have AMT. Most Intel systems with AMT don't have it turned on. It also includes the fact that the biggest concern is remote access to the AMT. If that isn't enabled, and there are various ways to ensure that it isn't, that concern (a remote backdoor) goes away. ___ skeptic mailing list skep...@linuxmafia.com http://linuxmafia.com/mailman/listinfo/skeptic To reach the listadmin, mail r...@linuxmafia.com - End forwarded message - ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng When reading https://www.theregister.co.uk/2017/11/09/chipzilla_come_closer_closer_listen_dump_ime/ where some claim to be able to access ME via USB ports I wonder how long it takes before ME is enabled and abused by malware. Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?
One more. When we say entropy and random numbers, we generally mean completely unpredictable. Intel's RDRAND, ekey, presumably ID-Quantique's solution and others rely for their entropy on quantum physics. If our understanding of quantum physics is correct, then by constructing such and such circuits, a certain bit flickes unpredictably between 0 and 1. The linux kernels' u/random relies on math. According to fairly well understood areas of math, an observer who sees the output cannot predict future output. Havege relies on complexity. It says that somes system can be too complex to understand, that modern computers are such systems, and so measuring some aspects of the system produces a stream of completely unpredictable numbers. (It also uses testing to find out which aspects will do.) According to your descriptions of what you want (Taiidan), the middle is the right one for you: It's essentially 100% open source and the others require you to trust either quantum physics or that impossible complexity is commonly available. You may not understand either the math or the C but both are accessible to you. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi folks, I add the lvm source package to my debian unbreak repository[0][1]. Note that there is also a debian-security repository[2] that fixes some security problems introduced by debian (and refused upstream for security reason). Regards Klaus [0] ftp://ftp.ethgen.ch/pub/debian/pool/unofficial/l/lvm2 [1] deb ftp://ftp.ethgen.ch/pub/debian ceres unofficial [2] deb ftp://ftp.ethgen.ch/pub/debian-security ceres unofficial-secured - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Comment: Charset: ISO-8859-1 iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAloIO8cACgkQpnwKsYAZ 9qyCvgwAwrgyMVA3WdCM0DCbSsCfstx/6ifyK1xnuo6Cd4dSYwPUs5EYChvpiLWP 0+P6av64/NGzkHiL/MNyklB3Giej/Q89k0cFk6LlMSjKAnV9eIiJLt80D+3nQBK+ N55FHVfo9sDpKdUjic+4Jc3cGdxGHu89hKbR+p7TUQx+IgRis1GY9BLgvsFGRqYK 5gQlBvxx4lQCMMRyA0NEbQs11OBLNi2rlUjOsclLTwBYN+20wmfm5sNGngzruVVo OyQYEcTJwiqCIHvkypBv7P88IWQmaask/ov9k1z8Uphi+uKA4w+mmClhcxPcKgTe oXR+I0dTsQes5eBlY63v47R8KwjZ1N0NpIhkKKw83VRM64XYtB7g0QJqVdhX675X grdpNkaQxuoG8KRJxTsQZ1QXJ4VxEYNq4W4df06WsQ3Q3zmZmYjbYMvh1UX22hWy YVQOMmjGG+cGEKNQnvmSLgTcT8BHAC00uxGK3ImYg8KH3mJKXnpptgf26ek/E4G5 NFBZAXrb =1xuf -END PGP SIGNATURE- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Documentation format philosophies
On Sun, Nov 12, 2017 at 12:13:11PM +0100, Didier Kryn wrote: > Le 12/11/2017 à 00:39, Svante Signell a écrit : > >On Sat, 2017-11-11 at 13:33 -0500, Steve Litt wrote: > >>> We use LaTEX in technical documents, > >>LaTeX is wonderful *for what it does*, which is make beautifully > >>typeset documents whose linefeeds are determined at compile time, not > >>at read time (like ePub, HTML or Xhtml). The problem is that you can't > >>reasonably convert LaTeX to XML, HTML, Xhtml or the like. > First of all, LaTeX is meant to produce paged documents while HTML > hasn't the notion of a page. latex2html can be used to initiate the > translation, but you will need to carefully edit the result. And converting mathematics to images is significantly nonideal. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Photograph of Devuan servers.
I would like to ask whether it is possible for those who have access to Devuan's servers to post a photograph of those nice machines. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Photograph of Devuan servers.
hi Ed, On Sun, 12 Nov 2017, Edward Bartolo wrote: > I would like to ask whether it is possible for those who have access > to Devuan's servers to post a photograph of those nice machines. sometimes ago a fellow VUA sent me this picture, announcing the use of Devuan in production at a company: https://ibb.co/gXQgTG ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote:
> The "too much work" argument is a very embarrassing one - it's the genuine
> duty of distro maintainers to take care of exactly such stuff. The argument
> that something was "too much work" (for the distro maintainers, or even the
> developers) is moot unless you're doing all that for yourself or for
> developers instead of your users.
> Claiming that a decision whether to put a package into /bin or /usr/bin (resp
> *sbin*) was "too much work" is also outright silly, there's zero additional
> workload in placing the package into the right location, except for the
> needed
> knowhow and decision itself. It's just for the laziness of developers of
> boot/init process when they demand to indiscriminately have access to *all*
> existing binaries in /usr
The work involved is not just "zero", it's _massive_. Have you looked at
how extensive dependency chains can be for complex setups? Try mounting a
filesystem over wifi that requires a fancy authentication daemon. Every
involved package, and every library recursively depended upon by one of
those packages, would need to be moved to /{bin,sbin,lib}/.
Debian, with its north of 1000 developers, decided that, despite trying,
it's a lost cause. Do you think Devuan with 5 can do better?
And if all you want is merely separate /usr, the whole extra cost is
installing "tiny-initramfs" which includes a trivial initrd whose features
(and complexity) are limited to:
* CPU microcode
* /usr
* root=UUID
* root on nfs in some configurations
* _very_ minimal module loading, with no real automation. This is usually
inadequate for distribution kernels, you need to recompile your kernel
with required pieces statically.
At least microcode is mandatory on any modern x86 CPUs, or you risk severe
data loss issues that differ by CPU sub-model. You may think that just
because without microcode your machine boots, all is ok. It's not. Even
worse, the documentation for problems fixed by microcode updates is sparse
at best and non-existant in most cases.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U.
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Thunderbird language packs outdated
On Sun, Nov 12, 2017 at 08:53:57AM +0100, Edward Bartolo wrote: > I would remove all languages that I do not need. Certainly, you do not > know 45 languages! I suggest you to download the Debian sources (or > Devuanised source packages) if available, open the debian/control > file, and remove all those futile dependencies for all languages that > I don't use. In this particular case, translations come in separate packages so you're free to install just languages you want. In the general case, though, if you insist on micromanaging, there's "localepurge" which might save you a whole 100MB! Although I don't know where you can find a machine capable of running Thunderbird at an usable speed where 100MB can make a difference. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?
On Sun, Nov 12, 2017 at 12:16:33PM +, Arnt Gulbrandsen wrote: > When we say entropy and random numbers, we generally mean completely > unpredictable. > > Intel's RDRAND, ekey, presumably ID-Quantique's solution and others rely for > their entropy on quantum physics. If our understanding of quantum physics is > correct, then by constructing such and such circuits, a certain bit flickes > unpredictably between 0 and 1. This assumes it indeed works as advertised. It's too easy to subvert and to make your CPU produce a sequence that's fully predictable by Intel and anyone they share their secrets with (ie, three letter agencies) but which you can't distinguish from honest randomness. > The linux kernels' u/random relies on math. According to fairly well > understood areas of math, an observer who sees the output cannot predict > future output. > > Havege relies on complexity. It says that somes system can be too complex to > understand, that modern computers are such systems, and so measuring some > aspects of the system produces a stream of completely unpredictable numbers. > (It also uses testing to find out which aspects will do.) Both the kernel and havege are fully auditable code. While in principle the CPU can subvert any code it runs, this would be drastically harder than to alter a black box. > According to your descriptions of what you want (Taiidan), the middle is the > right one for you: It's essentially 100% open source and the others require > you to trust either quantum physics or that impossible complexity is > commonly available. You may not understand either the math or the C but both > are accessible to you. The best solution is to use two or three of these sources. As long as you mix them using an unbroken one-way function, a malicious entropy source can't do anything worse than supply 0 entropy. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] (forw) Re: [skeptic] MINIX: ?Intel's hidden in-chip operating system
I have Intel ME apparently enabled. lspci says: $ lspci | grep MEI 00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04) -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) If you cannot make abstructions about details you do not understand the concepts underlying them. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Sun 12 November 2017 19:45:02 Adam Borowski wrote:
> On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote:
> > The "too much work" argument is a very embarrassing one - it's the genuine
> > duty of distro maintainers to take care of exactly such stuff. The
> > argument
> > that something was "too much work" (for the distro maintainers, or even
> > the
> > developers) is moot unless you're doing all that for yourself or for
> > developers instead of your users.
> > Claiming that a decision whether to put a package into /bin or /usr/bin
> > (resp *sbin*) was "too much work" is also outright silly, there's zero
> > additional workload in placing the package into the right location,
> > except for the needed knowhow and decision itself. It's just for the
> > laziness of developers of boot/init process when they demand to
> > indiscriminately have access to *all* existing binaries in /usr
>
> The work involved is not just "zero", it's _massive_. Have you looked at
> how extensive dependency chains can be for complex setups? Try mounting a
> filesystem over wifi that requires a fancy authentication daemon.
Sorry, I think when you take up on the task to develop and maintain an init
system, and you want to mount a filesystem via WiFi (what a weird idea)
*before* you mounted /usr/, and then you claim that's *too much work* aka too
complicated for *you* to accomplish this the right way and thus you need all
/usr/ in root, then really so sorry to tell you I think you're simply not up
to the task at hand
Anyway thanks for proving my point that it's just about laziness (or - now I
have to add - maybe mere incompetence) of the systemd cabal and freedesktop
folks and other proponents of /usr( in rootfs.
> Every
> involved package, and every library recursively depended upon by one of
> those packages, would need to be moved to /{bin,sbin,lib}/.
>
> Debian, with its north of 1000 developers, decided that, despite trying,
> it's a lost cause. Do you think Devuan with 5 can do better?
Yes, since those 5 understand that the other 995+ don't give a damn about
where /usr/ lives since their apps get started *after* init and mount of
filesystems
stopping to read here...
>
> And if all you want is merely separate /usr, the whole extra cost is
> installing "tiny-initramfs" which includes a trivial initrd whose features
> (and complexity) are limited to:
> * CPU microcode
> * /usr
> * root=UUID
> * root on nfs in some configurations
> * _very_ minimal module loading, with no real automation. This is usually
> inadequate for distribution kernels, you need to recompile your kernel
> with required pieces statically.
>
> At least microcode is mandatory on any modern x86 CPUs,
>
...since this is *obviously* completely unrelated to mounting /usr/
Why don't systemd and "friends" mount /usr/ via such minimal ramdisk?
> or you risk severe
> data loss issues that differ by CPU sub-model. You may think that just
> because without microcode your machine boots, all is ok. It's not. Even
> worse, the documentation for problems fixed by microcode updates is sparse
> at best and non-existant in most cases.
>
>
> Meow!
catfood
whatever
/j
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
