Re: [DNG] Beowulf; Increasing the number of boot options under grub. How To?
On Wed, May 19, 2021 at 12:15:50PM +1000, terryc wrote: > I understand the easiest method to install chimaera is a minimal > beowulf install and the the usual dist-grade route. As outline by > Florian about a month ago. (TY) There is a netinst image available for both amd64 and x86 of Chimaera on files.devuan.org. Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beowulf; Increasing the number of boot options under grub. How To?
On Tue, 18 May 2021 11:38:50 +0200 Ludovic Bellière wrote: > On mar, 18 mai 2021, onefang wrote: > > I recently bought an AMD Radeon RX 5700 XT card. Your 5700 might > > be too new for Beowulf, I had to jump through some hoops te get my > > 5600 working fully. Using the 5.10 kernel from Beowulf-backports, > > Mesa drivers and a bunch of related libraries from a third party > > PPA, and a hack. I now have 3D virtual worlds and dual screen > > working fine. No idea if any of that will work for a 5700, since I > > don't have one. > > It has to be underlined that beowulf's mesa packages are two years > old! As such, your somewhat recent graphic card will not have any > recent fixes, or might not enable access to all the features of your > hardware. > > If you want OpenGL 4.6, you're out of luck. > > Switching to devuan testing, chimaera, will solve most issue without > resorting to the usage of ppa and other foolishness. Normally I wouldn't consider it(risk a working system), but having recently received two new boxen following the release of majic smoke from the mail server, I'm actually in the position to do this on new naked hardware. The global chip shortage meant I had to order over-spec for a headless server, so the CFO/SWMBO'd's system was migrated to one and the other now has the 5700 XT in it( the PS is sufficient X). I understand the easiest method to install chimaera is a minimal beowulf install and the the usual dist-grade route. As outline by Florian about a month ago. (TY) ___ 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]
On 17.05.21 21:35, Alexis PM via Dng wrote: 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. Yes, but we should take a closer look on what exactly to standardize and how to do that exactly. Some wishes I've got at this point: * source shall be available via git * releases shall be tagged using some defined naming scheme (hopefully semver) * it use one of the common build systems (make, cmake, autotools, etc) or provide some compatible frontend (eg. configure script that behaves similar to the autools-generated ones) * no prebuilt binaries * only one package per source tree (no 3rdparty stuff) * only one license per source tree / package * important build / install pathes, as well as toolchain commands, can be overwritten via environment or ./configure script args in a standard way (eg. $DESTIR, $PREFIX, $BINDIR, ...) * library lookup only via pkg-config (no own scripts, cmake magic, etc) * supports DESTDIR installation * no external communication (eg. downloads) during build process * source tree does not contain any auto-generated files * overwrite toolchain commands by standard env vars ($CC, etc) --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ 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]
On 17.05.21 02:32, Steve Litt wrote: Imagine if > systemd took over that one package manager, eliminating the possibility> of Linux without systemd? uh, dont say it too loud - Lennart could get bad ideas ;-) --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ 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]
On 17.05.21 20:39, Alexis PM via Dng wrote: I am talking about the format in which developers publicly offer for download the code for new versions of the software they create. Actually, that had been one of the original topics of the OSS-QM project: a database of packages, releases, download urls and some canonical url (redirector) scheme. Part of that meanwhile had been obsoleted by the use modern SCMs like Git. But still there should be some canonicalization of things like branch/tag names, etc. This doesn't mean everybody should use exactly the same conventions, but rather formally described transformation rules, so we can do fully automatic imports. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ 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]
On 16.05.21 22:35, Alexis PM via Dng wrote: Hi, Standardize the package format of the released versions of each free software project would be a total and desirable revolution. Note that I'm *no way* proposing some standardized package format, especially NOT for binary distribution/deployment. We just could introduce some standardized *source* metadata that covers the most common things (eg. standard build systems like automake, cmake, etc, description of simple daemons, ...). But some "universal package format" is deemed to fail. The burden of offering the available software would shift to software developers rather than distributions. Absolutely NOT. They're are the totally wrong parties for doing that. We've seen that over decades, when upstreams (especially commercial ones) publish binary packages for some hand picked distros. It just doesn't work. They don't, and they practically can't, care of all the specialities of distros - which DO have their justification. The success of FOSS (especially GNU/Linux) comes exactly from the huge diversity of the dozens distros that all have their own scope and audience. A communist equilibrium that some folks (eg. the Lennartists) would be killing this prolific diversity of distros. We need clear borders between the realms of upstreams and distros as well as an vivid collaboration between them. Your "oss-qm" (it would be good to indicate the URL of the project) What's left of it can be found on github: https://github.com/oss-qm 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. No, that never has been the goal of oss-qm. It does NOT attempt any unification of actual package formats. Just a pool for collecting fixes and cleanups onto upstream releases, so individual distros don't need to carry huge patch queues and heavily package specific build instructions anymore. 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. This isn't so hard to solve, when upstreams and distro maintainers closely work together, use CIs (that automatically build/deploy/test on many distros). One vital point missing in most of the upstreams: stable maintenance branches, where bugfixes (eg. coming from distros) quickly move in. Other is general awareness of the needs of distros (eg. customizability, standardized build systems, etc) 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. Right. Part of the problem is that many packages are just too huge and should be splitted into several smaller ones. And the worst problems of all is "vendoring" - bundling 3rdparty code into some package. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beowulf; Increasing the number of boot options under grub. How To?
On 17/5/21 9:31 pm, terryc wrote: > I am hoping there is a simple config/number change in the grub > config files, but I can not find it in the doco I've read. > > In the past, the list of kernel images just grew each time you > loaded/updated the linux-image files. But the current system > automatically trims it to just two, with normal and recovery versions of > each. > I'm pretty sure you want to enable : GRUB_DISABLE_SUBMENU in /etc/default/grub before doing an update-grub. Backup your grub.cfg, make the change and then diff with the new one to see if it does what you want before rebooting. I can't verify that locally anymore as I've moved all my machines to boot with rEFInd, but I used grub for years. Regards, Brad ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Beowulf; Increasing the number of boot options under grub. How To?
On mar, 18 mai 2021, onefang wrote: > I recently bought an AMD Radeon RX 5700 XT card. Your 5700 might be too > new for Beowulf, I had to jump through some hoops te get my 5600 working > fully. Using the 5.10 kernel from Beowulf-backports, Mesa drivers and a > bunch of related libraries from a third party PPA, and a hack. I now > have 3D virtual worlds and dual screen working fine. No idea if any of > that will work for a 5700, since I don't have one. > It has to be underlined that beowulf's mesa packages are two years old! As such, your somewhat recent graphic card will not have any recent fixes, or might not enable access to all the features of your hardware. If you want OpenGL 4.6, you're out of luck. Switching to devuan testing, chimaera, will solve most issue without resorting to the usage of ppa and other foolishness. Cheers, Ludovic signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
