Re: [DNG] OpenPGP key for Devuan Release ISOs?
The problem is who signs, who is not someone whose signature is expected. wget https://files.devuan.org/devuan_chimaera/Release_notes.txt -q -O - | grep -A 4 'are signed' wget https://files.devuan.org/devuan_chimaera/installer-iso/SHA256SUMS https://files.devuan.org/devuan_chimaera/installer-iso/SHA256SUMS.asc gpg --verify SHA256SUMS.asc gpg --keyserver pgp.mit.edu --search-keys E93D7167A4F5FA9E9FED497770285BA5CF280BA4 Ralph Ronnquist (rrq) It would be expected that some...@devuan.org or similar, as on wget https://files.devuan.org/devuan-archive-keyring.gpg -q -O - | gpg PS: keys.gnupg.net closed down years ago (talked about here in the list when it happened), but the others (pgp.mit.edu, keys.openpgp.org,...) continue. Best regards. En viernes, 25 de febrero de 2022 19:06:27 CET, Lars Noodén via Dng escribió: I see that the ISO images are signed. I've tried to fetch the signing key[1] again, $ gpg --keyserver keys.gnupg.net \ --recv-key E032601B7CA10BC3EA53FA81BB23C00C61FC752C $ gpg --keyserver keys.gnupg.net \ --recv-key BB23C00C61FC752C $ gpg --keyserver keys.gnupg.net \ --search-keys BB23C00C61FC752C but get an error instead with each of the above methods: gpg: keyserver receive failed: Server indicated a failure What is the current / correct location to find the public key to check the releases with? /Lars [1] https://www.devuan.org/os/keyring ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenPGP key for Devuan Release ISOs?
The problem is who signs, who is not someone whose signature is expected. wget https://files.devuan.org/devuan_chimaera/Release_notes.txt -q -O - | grep -A 4 'are signed' wget https://files.devuan.org/devuan_chimaera/installer-iso/SHA256SUMS https://files.devuan.org/devuan_chimaera/installer-iso/SHA256SUMS.asc gpg --verify SHA256SUMS.asc gpg --keyserver pgp.mit.edu --search-keys E93D7167A4F5FA9E9FED497770285BA5CF280BA4 Ralph Ronnquist (rrq) It would be expected that some...@devuan.org or similar, as on wget https://files.devuan.org/devuan-archive-keyring.gpg -q -O - | gpg PS: keys.gnupg.net closed down years ago (talked about here in the list when it happened), but the others (pgp.mit.edu, keys.openpgp.org,...) continue. Best regards, En viernes, 25 de febrero de 2022 19:06:27 CET, Lars Noodén via Dng escribió: I see that the ISO images are signed. I've tried to fetch the signing key[1] again, $ gpg --keyserver keys.gnupg.net \ --recv-key E032601B7CA10BC3EA53FA81BB23C00C61FC752C $ gpg --keyserver keys.gnupg.net \ --recv-key BB23C00C61FC752C $ gpg --keyserver keys.gnupg.net \ --search-keys BB23C00C61FC752C but get an error instead with each of the above methods: gpg: keyserver receive failed: Server indicated a failure What is the current / correct location to find the public key to check the releases with? /Lars [1] https://www.devuan.org/os/keyring ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Pipewire and PulseAudio
> En lunes, 13 de diciembre de 2021 10:05:34 CET, Tomasz Torcz
> escribió:
> On Sun, Dec 12, 2021 at 09:40:20PM -0800, Marc Shapiro via Dng wrote:
>> I was scrolling though my e-mail from the debian user group and I saw
>> mention of pipewire, as a replacement for pulseaudio. It seemed to suggest
>> that it was in Testing, so would not be available on my Devuan Stable
>> (chimaera) system, but I took a look, anyway. It seems to be available,
>> and, in fact, installed on my system. It seems to have been brought in by
>> zoom.
>
> Are you sure you want pipewire? Looking at the code:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/commits/master
>
> Main contributor is from certain company associated with color red and
> a headgear. Given the sentiment on this list, you may want to think twice.
"pipewire" is not Red Hat's evil version of a supposedly innocent and
community-based "pulseaudio". In fact, knowing who is behind each, although I
distrust both, I think possibly more reliable the person behind "pipewire".
The creator of "pipewire" is Wim Taymans, Red Hat engineer, co-creator of the
"gstreamer" multimedia framework together with Erik Walthinsen.
On the other hand, Lennart Poettering, Red Hat engineer too, is the person
behind "pulseaudio" and "systemd". IMHO the pulseaudio design already subtly
shows the Potterings way of doing things, which later became very clear with
systemd: become not an alternative but the "de facto standard" of their area
(sound or init) with a very personal ("poetterings") "new way" of doing things
(but newer does not mean better) highly complex, intrusive,
compatibility-despising and hostile (WONTFIX to every bug report he doesn't
like), in confrontation with the "simpler and older" solution that works well
(alsa or sysv) (but older does not mean worse, and simple is usually much
better for auditing and fixing problems), in collusion with the company
promoting them that wants to be the "de facto standard" of GNU/Linux (RedHat).
RedHat is not an enemy, it contributes by developing interesting free software.
But RedHat is not a disinterested friend either, it is a company that seeks to
monopolize the GNU/Linux world as a way to strengthen its dominance of the free
software sector. It is a company so I understand that it cannot be asked to be
different or act as if it were a non-profit entity (SUSE is no different, just
smaller). RedHat is to be truly appreciated for developing free software, just
that its free software developments should be used with care and critical
approach. systemd as a complex that beyond being a simple init seeks to gobble
up all GNU/Linux (udev, logging daemon, cron & anacron, hostname, date, locale,
users accounts, groups and home directories, session management, network
configuration, name resolution,...) is an example of RedHat software to be
rejected by any GNU/Linux distro that is not made by RedHat (the serious Red
Hat Entreprise Linux, its proving ground named Fedora, and the
we-don't-know-how-to-manage-now, previously outside-RedHat RHEL
reimplementation, CentOS).
Best regards.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Report bugs
https://bugs.devuan.org/Reporting.html
remember that bugs in unforked packages (those that Devuan uses directly from
Debian) should usually be reported to Debian's BTS unless you think you have
found a Devuan specific problem.
Sometimes it is necessary to send a copy of a bug report to somewhere else
besides the mailing list and the package maintainer, which is where they are
normally sent.You could do this by CC'ing your bug report to the other
address(es), but then the other copies would not have the bug report number put
in the Reply-To field and the Subject line. When the recipients reply they will
probably preserve the sub...@bugs.devuan.org entry in the header and have their
message filed as a new bug report. This leads to many duplicated reports. The
right way to do this is to use the X-Debbugs-CC header. This will cause the bug
tracking system to send a copy of your report to the address(es) in the
X-Debbugs-CC line as well as to any mailing list.
In this case, Devuan's "dialog" version (1.3-20201126-1) is the Debian unforked
package, so it should be sent to Debian (view
https://www.debian.org/Bugs/Reporting ). Optionally you can CCed the upstream
author, although usually the package maintainer informs the upstream author.
Best regards.
En sábado, 27 de noviembre de 2021 19:14:39 CET, viverna via Dng
escribió:
I have found a bug in dialog.
How do I report a bug? Devuan, debian or to the author of the software?
--
_
< Viverna >
-
\ ^ /^
\ / \ // \
\ |\___/| / \// .\
\ /0 0 \__ / // | \ \ **
/ / \/_/ // | \ \ \ |
@_^_@`/ \/_ // | \ \ \/\ \
//_^_/ \/_ // | \ \ \ \
( //) | \/// | \ \ | |
( / /) | // | \ _\ | /
( // /) | ; -. | _ _\.-~ / /
(( / / )) | _ *-.|.-~-. .~ ~
(( // / )) \ / ~-. _ .-~ /
(( /// )) `. } { /
(( / )) .~-.\ \-` .~
///...< \ _ -~
///-._ _ _ _ _ _ _{^ - - - - ~
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
>> On 11/5/21 4:13 PM, Svante Signell via Dng wrote: >>> On Fri, 2021-11-05 at 18:50 +0000, Alexis PM via Dng wrote: >>>> Debian 11 Bullseye is the last Debian release that supports the >>>> non- >>>> merged-usr layout. It is therefore foreseeable that Devuan 4 >>>> Chimaera >>>> will also be. >>> >>> I'm not so sure Devuan has to follow Debian with respect to merged- >>> /usr. In my opinion it is more a policy decision to make for the >>> project. It is up to discussion though though. >>> Comments/arguments/opinions are very welcomed. In my previous post I merely quoted Debian's official position. I am not enthusiastic about the change of directory organization/layout, but unlike systemd or wayland, I see no real major problems (except unusual configurations, adapting some legacy code that calls binaries and libraries by their absolute path) and considering the big work that Devuan would imply to revert the adoption of usr-merge by Debian (in the next stables, more in testing, more in sid/ceres) I really prefer Devuan to dedicate its limited resources to offer an operating system that is clean of systemd, without forced dependencies (by window managers, desktops, web browsers and so on) of wayland, pulseaudio and "Poetterings", and as bug free as possible. Best regards. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
Debian 11 Bullseye is the last Debian release that supports the non-merged-usr layout. It is therefore foreseeable that Devuan 4 Chimaera will also be. Official Debian information: The historical justifications for the filesystem layout with /bin, /sbin, and /lib directories separate from their equivalents under /usr no longer apply today; see the Freedesktop.org summary. Debian bullseye will be the last Debian release that supports the non-merged-usr layout; for systems with a legacy layout that have been upgraded without a reinstall, the usrmerge package exists to do the conversion if desired. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841666 The Technical Committee resolves that Debian 'bookworm' should support only the merged-usr root filesystem layout, dropping support for the non-merged-usr layout. Until after the release of 'bullseye', any implementation of this resolution must be done in the 'experimental' distribution, or otherwise kept out of the critical paths for the release of 'bullseye'. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636 En viernes, 5 de noviembre de 2021 15:44:21 CET, Martin Steigerwald escribió: Hi Svante. No need to Cc me. I am subscribed. (I know there are different habits, so just a friendly information.) Svante Signell - 05.11.21, 11:26:52 CET: > On Fri, 2021-11-05 at 10:52 +0100, Martin Steigerwald wrote: > > Debian 11 defaults to usr merge. So the installed system used usr > > merge. > > > > I suppose Devuan is compatible and will remain compatible with that? > > I think it would be necessary as well some users may migrate from > > buster. Or one would have to find a way to undo the merge, but this > > I think is quite error prone. > > Devuan defaults to non-merged-/usr as far as I know. You can always > install with merged-/usr on Devuan too using the expert install > option. (Personally I prefer non-merged-/usr remains to be the > default.) Yeah… I always install Devuan them without merged-/usr. > > I like to avoid breaking the server VM by undoing usr merge, even > > tough I prefer systems without usr merge. It is easy to do with > > systems where I can use a Devuan ISO for installation, but for this > > system I had the Debian Netinstall ISO and it is what it is. > > You can use the dpkg-fsys-usrunmess, with a dpkg release later than or > equal to 1.20.6, see https://wiki.debian.org/Teams/Dpkg/MergedUsr > > "For already installed systems (since dpkg 1.20.6) you can also use > the dpkg-fsys-usrunmess program to revert the breakage from these > systems (but beware that it should not be used in systemd's emergency > mode)." > > (I've used that script on two Debian installations successfully > already.) Splendid. Thanks a lot for this. I hesitated, not wanting to cause any further hassle for the admins of the virtualization infrastructure the server VM runs on, but it indeed worked. It appears that… there is… some… discussion about the merged-/usr approach currently taken in Debian. What a mass. Happy I could undo it, although I am in awe for the developer of dpkg- fsys-usrunmess and it feels like I have used a magic wand of some kind. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Collaboration between distros [WAS: FSF and human rights]
>> Standardize the package format of the released versions of each free >> software project would be a total and desirable revolution. The burden >> of offering the available software would shift to software developers >> rather than distributions. > > I disagree. The rich variety of distros enables each of us to select > for our own set of priorities. > > As far as shifting the burden to the software developers, I was once > one of those software developers: The VimOutliner project. I *never* > would have created a package for VimOutliner. I had other stuff to do, > including improving VimOutliner. > > As a user of a minority packaging system (xbps), I get hurt more than > most by the lack of xbps packaged drivers and esoteric software, and > yet I'm still for distros choosing a packaging system or even > developing their own. > > Finally, one package manager is a single point of failure. Imagine if > systemd took over that one package manager, eliminating the possibility > of Linux without systemd? > > SteveT Standardise the format in which developers publicly offer for download the code for new versions of the software they create, would make packaging (or port/ebuild creation) easier for distros, freeing up time that can be spent on other things. Standardise the source files is not an obstacle for distros to customize the software they distribute, on the contrary it would make it easier to focus on customizations because the organization of the source file would be predictable. Obviously conforming to a standardised source file format means more burden for developers, it would help the spread of their software by making it easier for more distros to package it, although as I said it is already quite an effort for many developers to package their software code for download in whatever way they find easiest and let distros create ready-to-install packages (be it binaries or ports/ebuilds) for their distro users. Since I'm talking about how developers package their code to make it available for download either to users who compile personally or to distro maintainers who create ready-to-use packages and make them available in a repository for their users, this has nothing to do with the damn systemd wanting to contest the place occupied by deb, rpm, xbps and the bloated AppImage and Snap. Best regards ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Collaboration between distros [WAS: FSF and human rights]
There is also PcLinuxOS even if rpm based but they have the full stack systemd free and could be a source of code for devuan as they already solved somehow most of the problems. Systemd free distros should pool their efforts to avoid duplication and to gain critical mass. >>> >>> I'd like to put that onto a broader level: IMHO most of the work to do >>> for distros is about QM (testing, patching, bugfixing) - we should try >>> to consolidate that work, independent of individual distros and their >>> technology. >>> >>> For decades, whenever I package something for some distro, I try to >>> do most of the work in a distro agnostic way. (used to have my own >>> project, called "oss-qm", which collects patches ontop of upstream >>> releases to make up QM'ed branches - unfortunately no distro really >>> showed any interest in that). >>> >>> In essenence, I'm proposing fixing up packages (and individual >>> releases) >>> up to a point where the actual distro-packaging is pretty much >>> trivial. >>> For *most* SW out there we could even invent some universal packaging >>> metadata format, that could be automatically transformed into dist- >>> specific build files. Of course, that only works just *mostly*, since >>> there're still many exceptions. Dh (and its various helpers) is >>> already >>> a great step into that direction, but we could go some steps further >>> and make it useful for completely unrelated distros and even more >>> tricky >>> cases like crosscompiling and tiny embedded scenarios. >> >> >> Standardize the package format of the released versions of each free >> software project would be a total and desirable revolution. > > > Would it? Or would that standardization make Linux vulnerable to > malicious activity and misuse by those who want to control > "free-software" in oh so many ways? > > Christopher Barry's "Open letter to the Linux World"[1] concludes with > this: > > OneLinux == zero-choice > > [1] http://lkml.iu.edu//hypermail/linux/kernel/1408.1/02496.html > > golinux Please, be careful, I'm not saying that distros should disappear to create a single operating system, or anything like that. I am talking about the format in which developers publicly offer for download the code for new versions of the software they create. I do not see how standardizing the format of the "licenses" file or standardising the name of the folders within the source file could imply a security problem or cause the distros to disappear. I think that just the other way around, this would make packaging easier for distros, freeing up time that can be spent on other things. Regarding security, the vulnerable software is the installed and executable software, not the source file. Best regards. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Collaboration between distros [WAS: FSF and human rights]
>> There is also PcLinuxOS even if rpm based but they have the full stack >> systemd free and could be a source of code for devuan as they already >> solved somehow most of the problems. Systemd free distros should >> pool their efforts to avoid duplication and to gain critical mass. > > I'd like to put that onto a broader level: IMHO most of the work to do > for distros is about QM (testing, patching, bugfixing) - we should try > to consolidate that work, independent of individual distros and their > technology. > > For decades, whenever I package something for some distro, I try to > do most of the work in a distro agnostic way. (used to have my own > project, called "oss-qm", which collects patches ontop of upstream > releases to make up QM'ed branches - unfortunately no distro really > showed any interest in that). > > In essenence, I'm proposing fixing up packages (and individual releases) > up to a point where the actual distro-packaging is pretty much trivial. > For *most* SW out there we could even invent some universal packaging > metadata format, that could be automatically transformed into dist- > specific build files. Of course, that only works just *mostly*, since > there're still many exceptions. Dh (and its various helpers) is already > a great step into that direction, but we could go some steps further > and make it useful for completely unrelated distros and even more tricky > cases like crosscompiling and tiny embedded scenarios. Standardize the package format of the released versions of each free software project would be a total and desirable revolution. The burden of offering the available software would shift to software developers rather than distributions. However, unfortunately I see little viability to prosper in the current real world. Your "oss-qm" (it would be good to indicate the URL of the project) has not been the only initiative to create a standard of released software package for the software developers that allows to surpasses the diversity of packages formats. Even distros like Gentoo that don't compile but simply offer recipes that automate the download and compilation (which is a simplified version of the packaging task for distros that offer binaries, source-only distros only need to note in each recipe the download URL and build commands) have a hard time trying to achieve the role of distros: achieve that the set of software that constitutes the operating system run error-free on the computers of its users. A big problem is that many free software developers hardly take the time to publicly offer the code of their software organized according to their personal way of organizing the code without testing in the complex diversity of the universe beyond their computer (they know that their software runs fine in their operating system and development environment that is distro X version Y with versions of the dependencies A.B.C, D.E.F., G.H.I.), leaving the distros the role of compiling and packaging the software and dealing with what errors arise in architectures and combinations of versions of dependencies that are different from the software developer's computers. As a note of the difficulty of standardizing the content of the packages of released versions by the developers, even something that should be as simple as clearly indicating in a file the licenses of all the software contained in the package, is something that is usually done wrong. Best regards. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FSF and human rights
>>Hi All, >> >>Debian is engaging in a disgusting attack against RMS: >>https://www.debian.org/vote/2021/vote_002 >> >>Does Devuan have resolutions to sign open letters? >>I'd propose to sign this one instead: >>https://rms-support-letter.github.io/ > > I'd suggest nobody sign anything, and nobody respond to this email. > > If you believe that Stallman was removed, shunned and criticized > because of guilt by association, then it's not much of a stretch to > believe that you will suffer the same fate if you defend him. And then > any who defends *you* will suffer the same fate, ad infinitum. > > Before you sign anything or do anything, ask yourself if this is of top > importance to you. Are you willing to risk your career, your position > in your community, perhaps the positions of your family, to defend > Richard Stallman? Unless the answer is an unmitigated "yes", I'd advise > you to stay as far from this issue as you can. > > My response in no way implies my (very private) position on Stallman. > I'm just pointing out that unless you're willing to pay the freight, > and the payment may be a costly and may be immediate or delayed for > years, getting involved "for the principle of the thing" may cause you > later regret. Fear is the ally of injustice. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FSF and human rights
> Hi All, > > Debian is engaging in a disgusting attack against RMS: > https://www.debian.org/vote/2021/vote_002 > > Does Devuan have resolutions to sign open letters? > I'd propose to sign this one instead: > https://rms-support-letter.github.io/ > > See also: > An orthodox analysis entitled Justice for Dr. Richard Matthew Stallman, which > recaps the whole story. > https://jorgemorais.gitlab.io/justice-for-rms/ > > A post, written by Hannah Wolfman-Jones, with a response from civil-rights > expert Nadine Strossen, former president of the ACLU. > https://www.wetheweb.org/post/cancel-we-the-web > I propose to extend the Devuan (and personal) signature of the quoted letter ( https://rms-support-letter.github.io/index.html ) also to the other existing letter of support (more detailed but little known) https://gitlab.com/KenjiBrown/rms-open-letter/-/blob/master/index.md (replicated at https://github.com/KenjiBrown/rms-open-letter.github.io/blob/main/index.md ) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beowulf Beta is here!
I add other installer bug to the list: locales wrong configured.
In the installer, I choose Spanish (Spain). In the "additional locales" step, I
don't add any, the header of the dialog indicates that "es_ES.UTF-8" is already
selected, and "es_ES.UTF-8" is not in the list of additional locales, all seems
fine. But in the installed system, apt, lightdm, xfce... are all in English.
perl: warning: Setting locale failed.
LANGUAGE = (unset), LC_ALL = (unset), LANG = "es_ES.UTF-8"
perl: warning: Falling bak to the standard locale ("C").
The solution:
dpkg-reconfigure locales
and choose the (unselected) "es_ES.UTF-8"
Best regards!
PS: Thanks Mark for libsystemd0 explication!
En lunes, 20 de abril de 2020 15:04:08 CEST, Alexis PM via Dng
escribió:
Hello
Forgive the brief text and the insufficient review of whether what I indicate
has already been reported, but I have little time and wanted to indicate a few
things just in case:
devuan_beowulf_3.0.0_beta_amd64_netinstall.iso doesn't work:
Initramfs unpacking failed: write error
touch: /var/run/brltty-Xorg: No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory
touch: /var/run/brltty-Xorg: No such file or directory
...
devuan_beowulf_3.0.0_beta_i386_netinstall.iso works basically, but:
* the installer tasksel fails (I tried "printer server"), probably non-existent
packages or dependency errors.
* "none" instead of selected hostname at shell prompt, but /etc/hostname is
fine.
* libsystemd0 is installed. Note: it is a minimal installation (I didn't select
anything in installation tasksel).
* No "beowulf-updates" in /etc/apt/sources.list but I choose it in the
installation.
* "ceres" mention in /etc/devuan_version.
* Untranslated text into Spanish in some parts of the installer.
Best regards!
En jueves, 19 de marzo de 2020 15:24:57 CET, Rainer Weikusat via Dng
escribió:
goli...@devuan.org writes:
> Dear dev1ers,
>
> The Devuan 3 Beowulf Beta release is now ready for review.
[...]
> In solidarity,
>
> The Devuan Devs
Great news. Thanks a lot.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beowulf Beta is here!
Hello Forgive the brief text and the insufficient review of whether what I indicate has already been reported, but I have little time and wanted to indicate a few things just in case: devuan_beowulf_3.0.0_beta_amd64_netinstall.iso doesn't work: Initramfs unpacking failed: write error touch: /var/run/brltty-Xorg: No such file or directory touch: /var/run/brltty-Xorg: No such file or directory touch: /var/run/brltty-Xorg: No such file or directory touch: /var/run/brltty-Xorg: No such file or directory ... devuan_beowulf_3.0.0_beta_i386_netinstall.iso works basically, but: * the installer tasksel fails (I tried "printer server"), probably non-existent packages or dependency errors. * "none" instead of selected hostname at shell prompt, but /etc/hostname is fine. * libsystemd0 is installed. Note: it is a minimal installation (I didn't select anything in installation tasksel). * No "beowulf-updates" in /etc/apt/sources.list but I choose it in the installation. * "ceres" mention in /etc/devuan_version. * Untranslated text into Spanish in some parts of the installer. Best regards! En jueves, 19 de marzo de 2020 15:24:57 CET, Rainer Weikusat via Dng escribió: goli...@devuan.org writes: > Dear dev1ers, > > The Devuan 3 Beowulf Beta release is now ready for review. [...] > In solidarity, > > The Devuan Devs Great news. Thanks a lot. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Result of the Debian vote 'General Resolution: Init systems and systemd'
>Many years ago, on this mailing list, one of the VUAs mentioned that >the long term plan was to leave Debian behind and become the Devuan >independent distro. I am sorry to burst the soap bubble, I want Devuan to persist and that requires a realistic analysis. Cleaning up systemd dependencies to Debian packaging is child's play compared to creating and maintaining a large self-built distro in the long run. The idea of an independent Devuan not based on Debian may be the imaginary fantasy of some people (not me), but it is unrealistic. Creating, but more importantly maintaining, a medium or large distro over the years is a huge job. Debian is around 1500 maintainers and it is noticeable that more person-hours would be needed to maintain it (delays in packaging new versions, delays in attending to bug reports, ...). Devuan has 1/100 that number of maintainers, and its human capacity is limited to hardly achieve to modify a small number of packages of each Debian release (task that is delayed months). For experiments there are already other distros, like Hyperbola. If the name of Devuan ended up deriving to a Hyperbola type distro, it would be necessary to remake a new Devuan in the original (current) sense: based on the veteran and stable distro that Debian is but removing the systemd dependencies. Best regards! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Result of the Debian vote 'General Resolution: Init systems and systemd'
>Many years ago, on this mailing list, one of the VUAs mentioned that >the long term plan was to leave Debian behind and become the Devuan >independent distro. I am sorry to burst the soap bubble, I want Devuan to persist and that requires a realistic analysis. Cleaning up systemd dependencies to Debian packaging is child's play compared to creating and maintaining a large self-built distro in the long run. The idea of an independent Devuan not based on Debian may be the imaginary fantasy of some people (not me), but it is unrealistic. Creating, but more importantly maintaining, a medium or large distro over the years is a huge job. Debian is around 1500 maintainers and it is noticeable that more person-hours would be needed to maintain it (delays in packaging new versions, delays in attending to bug reports, ...). Devuan has 1/100 that number of maintainers, and its human capacity is limited to hardly achieve to modify a small number of packages of each Debian release (task that is delayed months). For experiments there are already other distros, like Hyperbola. If the name of Devuan ended up deriving to a Hyperbola type distro, it would be necessary to remake a new Devuan in the original (current) sense: based on the veteran and stable distro that Debian is but removing the systemd dependencies. Best regards! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Result of the Debian vote 'General Resolution: Init systems and systemd'
My comments:
A mediocre result, neither good nor bad.
The best option for people who don't want to use systemd, Option 6 "E: Support
for multiple init systems is Required", came in last.
But Option 1 "F: Focus on systemd" came in second place, if it had won it would
have been a tragedy.
We remain more or less as we are ("The Debian project recognizes that systemd
service units are the preferred configuration", "Packages may include support
for alternate init systems besides systemd and may include alternatives for any
systemd-specific interfaces they use", "Maintainers use their normal procedures
for deciding which patches to include", "Debian is committed to working with
derivatives that make different choices about init systems" as a simple
recommendation), now with the certainty that it will remain so for at least
some time. A project offering Debian packages free of systemd dependencies
remains necessary.
Best regards!
Miscelánea Natural http://www.miscelaneanatural.org
Anfibios de Asturias http://www.anfibiosdeasturias.org
HackLab Pica Pica http://www.picahack.org
Actividades de informática con software libre http://eslibreasturias.rf.gd
En sábado, 28 de diciembre de 2019 10:27:35 CET, Alexis PM via Dng
escribió:
Result of the Debian vote
'General Resolution: Init systems and systemd'
https://www.debian.org/vote/2019/vote_002
The voting period ended on Friday 2019-12-27 23:59:59 UTC
Result
https://vote.debian.org/~secretary/gr_initsystems/results.txt
The winners are:
Option 2 "B: Systemd but we support exploring alternatives"
Proposal B Proposer: Sam Hartman [hartm...@debian.org] [text of proposal]
[amendment]
Choice 2: B: Systemd but we support exploring alternatives
Using its power under Constitution section 4.1 (5), the project issues the
following statement describing our current position on Init systems, multiple
init systems, and the use of systemd facilities. This statement describes the
position of the project at the time it is adopted. That position may evolve as
time passes without the need to resort to future general resolutions. The GR
process remains available if the project needs a decision and cannot come to a
consensus.
The Debian project recognizes that systemd service units are the preferred
configuration for describing how to start a daemon/service. However, Debian
remains an environment where developers and users can explore and develop
alternate init systems and alternatives to systemd features. Those interested
in exploring such alternatives need to provide the necessary development and
packaging resources to do that work. Technologies such as elogind that
facilitate exploring alternatives while running software that depends on some
systemd interfaces remain important to Debian. It is important that the project
support the efforts of developers working on such technologies where there is
overlap between these technologies and the rest of the project, for example by
reviewing patches and participating in discussions in a timely manner.
Packages should include service units or init scripts to start daemons and
services. Packages may use any systemd facility at the package maintainer's
discretion, provided that this is consistent with other Policy requirements and
the normal expectation that packages shouldn't depend on experimental or
unsupported (in Debian) features of other packages. Packages may include
support for alternate init systems besides systemd and may include alternatives
for any systemd-specific interfaces they use. Maintainers use their normal
procedures for deciding which patches to include.
Debian is committed to working with derivatives that make different choices
about init systems. As with all our interactions with downstreams, the relevant
maintainers will work with the downstreams to figure out which changes it makes
sense to fold into Debian and which changes remain purely in the derivative.
Miscelánea Natural http://www.miscelaneanatural.org
Anfibios de Asturias http://www.anfibiosdeasturias.org
HackLab Pica Pica http://www.picahack.org
Actividades de informática con software libre http://eslibreasturias.rf.gd
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Result of the Debian vote 'General Resolution: Init systems and systemd'
Result of the Debian vote 'General Resolution: Init systems and systemd' https://www.debian.org/vote/2019/vote_002 The voting period ended on Friday 2019-12-27 23:59:59 UTC Result https://vote.debian.org/~secretary/gr_initsystems/results.txt The winners are: Option 2 "B: Systemd but we support exploring alternatives" Proposal B Proposer: Sam Hartman [hartm...@debian.org] [text of proposal] [amendment] Choice 2: B: Systemd but we support exploring alternatives Using its power under Constitution section 4.1 (5), the project issues the following statement describing our current position on Init systems, multiple init systems, and the use of systemd facilities. This statement describes the position of the project at the time it is adopted. That position may evolve as time passes without the need to resort to future general resolutions. The GR process remains available if the project needs a decision and cannot come to a consensus. The Debian project recognizes that systemd service units are the preferred configuration for describing how to start a daemon/service. However, Debian remains an environment where developers and users can explore and develop alternate init systems and alternatives to systemd features. Those interested in exploring such alternatives need to provide the necessary development and packaging resources to do that work. Technologies such as elogind that facilitate exploring alternatives while running software that depends on some systemd interfaces remain important to Debian. It is important that the project support the efforts of developers working on such technologies where there is overlap between these technologies and the rest of the project, for example by reviewing patches and participating in discussions in a timely manner. Packages should include service units or init scripts to start daemons and services. Packages may use any systemd facility at the package maintainer's discretion, provided that this is consistent with other Policy requirements and the normal expectation that packages shouldn't depend on experimental or unsupported (in Debian) features of other packages. Packages may include support for alternate init systems besides systemd and may include alternatives for any systemd-specific interfaces they use. Maintainers use their normal procedures for deciding which patches to include. Debian is committed to working with derivatives that make different choices about init systems. As with all our interactions with downstreams, the relevant maintainers will work with the downstreams to figure out which changes it makes sense to fold into Debian and which changes remain purely in the derivative. Miscelánea Natural http://www.miscelaneanatural.org Anfibios de Asturias http://www.anfibiosdeasturias.org HackLab Pica Pica http://www.picahack.org Actividades de informática con software libre http://eslibreasturias.rf.gd ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] INJ - Init Freedom inJector (was: cannot exist without the help of Debian)
>>> I propose this: a script called INJ - Init Freedom inJector >>> >>> I wrote this summer in this list about a possibility of inject init >>> run scripts (for example runit) in all Devuan packages automatically. >>> >>> I'm writing a simple script that inject init diversity in a single >>> package. >>> ... >>> I would like to release the script in the next days with AGPL3 but >>> tell me. >> >> >>Do you mean AGPL3 as in the GNU Affero General Public License? >> >> https://www.gnu.org/licenses/agpl-3.0.en.html >> >>If so, please don't use the language "AGPL3 or later" since the "or >>later" could be a sabotaged license in the future. >Yes, GNU Affero General Public License 3.0 (no later). >But i'm willing to choose other license if change is helpful to save >Devuan. GNU AGPL version 3 is the best. Init Freedom inJector is great, fantastic, wonderful, if that really achieves its goal (automatically introduce in all packages the necessary scripts to make any init work _without problems or bugs_). Best regards! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird problem with every kernel update
Hello Although update-initramfs should be done automatically after installing a new kernel, a update-initramfs -u -k all && update-grubdone manually just after installing a new kernel version and before shutting down / rebooting should prevent you from having that problem. It seems that update-initramfs does not recognize the newly installed kernel. A problem identifying which is the most current kernel version would cause what a wrong update-initramfs without using "all"... but with "all"? It is important that next time you inspect in detail the installation of the new kernel: see possible APT/DPKG errors when you upgrade, check that there is enough space in the partitions, see if an initramfs of the newly installed kernel is generated or not ( ls /var/lib/initramfs-tools ; ls /boot ; cat /etc/initramfs-tools/update-initramfs.conf ) both automatically and after a manual "update-initramfs -u -k all", see grub entries ( cat /boot/grub/grub.cfg ) both automatically and after a manual "update-grub". Best regards! De: Andrew McGlashan Para: Devuan DNG Enviado: Domingo 23 de junio de 2019 23:08 Asunto: [DNG] Weird problem with every kernel update -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Hardware NUC6i7KYK. Every time I do a kernel upgrade (Devuan ASCII), rebooting loses USB devices shortly after grub kicks in. I have to boot a USB stick, which (Devuan Jessie Live), start a rescue session and do all the following steps: 1. auto-detect RAID devices 2. enter a shell 3. unlock lvms LUKS encrypted volume (which has root and swap) 4. vgchange -ay 5. exit shell Back to the rescue: 6. start root shell choosing root volume from lv (mounting /boot). 7. /bin/bash 8. update-initramfs -u -k all Then, every single time I perform these steps, the NUC device will continue to find USB properly until the next kernel update and I've got to go through these specific steps again, every single time. If I do the update and perform step 8 above before rebooting, I still have a problem; I have to go via the USB live ISO to fix it. There are external USB disks that are a mirror, when these don't come up in the dropbear environment, then I know I have the problem. So, attaching a USB keyboard, I can see it turn off (lights out) when it gets past the grub stage of boot... so that's when I pull out the USB live ISO from Devuan Jessie. It has happened for quite a while now, but I know exactly how to fix it, but not why it is happening. - -- Kind Regards AndrewM -BEGIN PGP SIGNATURE- iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCXQ/mIgAKCRCoFmvLt+/i +/gZAP9v6QR3Cmvj331jkkknofxfUh+W6dnSu0BjDMUMnTeXSQEAnMm+GzpVaXnu +cyesqom1c/hIGUV+tqe8MuqxMeo1HY= =kOpl -END PGP SIGNATURE- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
