Re: [DNG] How long should I expect to wait for openrc to be ready in devuan ascii
On Sat, 1 Jul 2017 at 00:24:59 +0200 Didier Kryn wrote: > Le 30/06/2017 à 23:30, Vincent Bentley a écrit : > > Along time ago, well designed and well behaved software could be > > recognised by the number of years passed without changes. I worked at > > one place that was proud of release version birthdays. > > Agreed. That's why I'm always bothered with the fast release pace > of some essential pieces of software, with the fastest being the GCC and > the Linux kernel. Well, this is understandable: both the compiler and the kernel must keep up with the frantic rollout of new hardware from many vendors. You don't have to upgrade if you don't need support for the laters pieces of silicon the industry has churned out the past month. What matters is that older releases are still maintained and that they work, of course. From time to time support for a new protocol/filesystem is merged, too. This is not the case of init systems, as they are not supposed to be sensitive to the particular hardware/filesystem they are running on. I wonder why zap feels the need of a "regularly updated" init, are there issues in the current Devuan init that he feels are not being adequately addressed? Bye, Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How long should I expect to wait for openrc to be ready in devuan ascii
On Fri, 2017-06-30 at 20:12 -0400, zap wrote: > It is a little too confusing trying to install openrc at the moment > so I > will pass for now... > > It is just a shame that the runit-init package was taken down... The instructions are crystal clear... (And btw: Daniel Reurich is working hard to get util-linux built) Regarding runit-init Steve Litt will hopefully provide a Devuan package in due time. At least he is promoting it a lot. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] BUG (severe): chromium crashes
On Sat, 01 Jul 2017, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > > on devuan jessie (in chroot) chromium crashes immediately: chromium uses seccomp sandboxing internally which may fail to run inside a chroot. I run chromium regularly on jessie, also inside firejail (using https://github.com/dyne/tinfoil) so can confirm that at least outside of a chroot it works well. in general please consider these sort of reports should go to bugs.devuan.org (can be filed using reportbug) ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
On 30/06/17 08:56, Joachim Fahrner wrote: > It's driven by Red Hat to make money out of supporting their > development. > Hammer -> Nail signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
On June 30, 2017 1:14:24 AM CDT, Nate Bargmann wrote: ::* On 2017 30 Jun 00:55 -0500, Alessandro Selli wrote: :: ::> Maybe it's me, but what the hell is a DNS resolver doing inside an ::init ::> system? :: ::The same thing that a time sync (NTP) daemon is doing in there... :: ::- Nate :: ::-- :: ::"The optimist p -- Sent from a Mobile device. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
It makes more sense when you consider that systemd is a thinly veiled excuse for an init daemon which really wants to replace every distro out there with something red hat has more control over. On July 1, 2017 8:25:56 AM CDT, vmlinux wrote: :: :: ::On June 30, 2017 1:14:24 AM CDT, Nate Bargmann wrote: * On 2017 30 Jun 00:55 -0500, Alessandro Selli wrote: > Maybe it's me, but what the hell is a DNS resolver doing inside ::an init > system? The same thing that a time sync (NTP) daemon is doing in there.. -- Sent from a Mobile device. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How long should I expect to wait for openrc to be ready in devuan ascii
Le 01/07/2017 à 10:20, Alessandro Selli a écrit : On Sat, 1 Jul 2017 at 00:24:59 +0200 Didier Kryn wrote: Le 30/06/2017 à 23:30, Vincent Bentley a écrit : Along time ago, well designed and well behaved software could be recognised by the number of years passed without changes. I worked at one place that was proud of release version birthdays. Agreed. That's why I'm always bothered with the fast release pace of some essential pieces of software, with the fastest being the GCC and the Linux kernel. Well, this is understandable: both the compiler and the kernel must keep up with the frantic rollout of new hardware from many vendors. You don't have to upgrade if you don't need support for the laters pieces of silicon the industry has churned out the past month. What matters is that older releases are still maintained and that they work, of course. From time to time support for a new protocol/filesystem is merged, too. This is not the case of init systems, as they are not supposed to be sensitive to the particular hardware/filesystem they are running on. I wonder why zap feels the need of a "regularly updated" init, are there issues in the current Devuan init that he feels are not being adequately addressed? New hardware and language evolution are good reasons to continuously make limited upgrades, but these folks ar continuously reworking the internals of their machines, like if they were never happy with what they've done six months before - it's not only bug correction. They preserve the external API but change all the rest. I tell that because, a decade ago, I tried to write driver modules but the internal kernel API was never in sync with the doc, while there was a new edition of the doc every year; I stopped wasting my time. This might be a reason why hardware vendors don't provide drivers for Linux: big effort for a little market. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
* On 2017 01 Jul 08:49 -0500, vmlinux wrote: > It makes more sense when you consider that systemd is a thinly veiled > excuse for an init daemon which really wants to replace every distro > out there with something red hat has more control over. Certainly, that trend has been well established. What is troubling are all of the other distributions who treat it as fate accompli. My hope is that Devuan, Slackware, and other distributions that have staked out a position that seeks to maintain the traditional stack will maintain enough traction so that application writers won't adopt only SD APIs at the expense of anything else. I'll admit, there was one trick that SD did that I liked, and that was starting CUPS only when there was a call to print. I don't print often so bringing up CUPS on demand and then shutting it down later was nice. But then, SD was running all the time, so not much was gained. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Questions about Devuan installer
Hi all, I want to install a brand new, Devuan stable Qemu guest, so I have some questions: 1) What's the name of the current stable version? 2) At what URL can I download the latest network install ISO file for that version? 3) Are there any landmines when installing from this ISO file? 4) Is Amprolla OK now? Thanks, SteveT Steve Litt June 2017 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Questions about Devuan installer
On 07/01/2017 12:17 PM, Steve Litt wrote: > Hi all, > > I want to install a brand new, Devuan stable Qemu guest, so I have some > questions: > > 1) What's the name of the current stable version? jessie > 2) At what URL can I download the latest network install ISO file for >that version? files.devuan.org > 3) Are there any landmines when installing from this ISO file? That depends on what battles you've chosen. If you don't want your wireless firmware to be automatically installed, you must choose expert install to be asked what you want. > 4) Is Amprolla OK now? Yes, it was fixed, and it only affected ascii, not jessie. -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Questions about Devuan installer
On Saturday 01 July 2017 at 18:17:44, Steve Litt wrote: > Hi all, > > I want to install a brand new, Devuan stable Qemu guest, so I have some > questions: > > 1) What's the name of the current stable version? https://devuan.org/ - current stable is “Jessie” > 2) At what URL can I download the latest network install ISO file for >that version? Picking a mirror at random from the list at https://devuan.org/ Click on http://devuan.smallinnovations.nl Click on "devuan_jessie" Click on "installer-iso" Choose the one you need from the list http://devuan.smallinnovations.nl/?dir=devuan_jessie/installer-iso - either http://devuan.smallinnovations.nl/devuan_jessie/installer- iso/devuan_jessie_1.0.0_i386_NETINST.iso or http://devuan.smallinnovations.nl/devuan_jessie/installer- iso/devuan_jessie_1.0.0_amd64_NETINST.iso > 3) Are there any landmines when installing from this ISO file? Not in my experience, no. > 4) Is Amprolla OK now? Not my area of expertise - maybe someone else will answer this. Antony. -- Programming is a Dark Art, and it will always be. The programmer is fighting against the two most destructive forces in the universe: entropy and human stupidity. They're not things you can always overcome with a "methodology" or on a schedule. - Damian Conway, Perl God Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Questions about Devuan installer
On Saturday 01 July 2017 at 18:29:11, fsmithred wrote: > On 07/01/2017 12:17 PM, Steve Litt wrote: > > Hi all, > > > > I want to install a brand new, Devuan stable Qemu guest, so I have some > > questions: > > > > 1) What's the name of the current stable version? > > jessie > > > 2) At what URL can I download the latest network install ISO file for > > > >that version? > > files.devuan.org > > > 3) Are there any landmines when installing from this ISO file? > > That depends on what battles you've chosen. If you don't want your > wireless firmware to be automatically installed, you must choose expert > install to be asked what you want. Unlikely on a Qemu guest :) > > 4) Is Amprolla OK now? > > Yes, it was fixed, and it only affected ascii, not jessie. > > -fsr Antony. -- There's a good theatrical performance about puns on in the West End. It's a play on words. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
On Sat, 1 Jul 2017 10:25:20 -0500 Nate Bargmann wrote: > fate accompli "Fate" is very apposite in the circumstance Cheers, Ron. -- It is a typically Hohenzollern idea to believe that it is a crime for a country to defend itself after its army has been destroyed. -- Karl Marx -- http://www.olgiati-in-paraguay.org -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
Quoting Nate Bargmann (n...@n0nb.us): > I'll admit, there was one trick that SD did that I liked, and that was > starting CUPS only when there was a call to print. I don't print often > so bringing up CUPS on demand and then shutting it down later was nice. > But then, SD was running all the time, so not much was gained. CUPS is almost the only game in town, but there was a project I long admired a great deal, that ran a very lightweight print subsystem with no queuing, called PDQ (print, don't queue). It's been unmaintained for quite a few years, but is probably still practical. Because it has an interface to Foomatic, it supports all printers that work under CUPS or LPRng. (It still runs a daemon process but it's a small, simple one.) http://pdq.sourceforge.net/introduction.html https://sourceforge.net/p/pdq/news/2006/06/resurrect-pdq/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] BUG (severe): chromium crashes
On 07/01/17 09:37, Jaromil wrote: chromium uses seccomp sandboxing internally which may fail to run inside a chroot. I run chromium regularly on jessie, also inside firejail (using https://github.com/dyne/tinfoil) so can confirm that at least outside of a chroot it works well. Meanwhile found it out myself: it was missing /dev/shm. schroot didn't set it up automatically. Chromium should have printed a proper message. Filed upstream bug. in general please consider these sort of reports should go to bugs.devuan.org (can be filed using reportbug) Was down when I wrote the mail. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
On 07/01/17 15:25, Nate Bargmann wrote: Certainly, that trend has been well established. What is troubling are all of the other distributions who treat it as fate accompli. My hope is that Devuan, Slackware, and other distributions that have staked out a position that seeks to maintain the traditional stack will maintain enough traction so that application writers won't adopt only SD APIs at the expense of anything else. At that point I'm curious which fancy features of systemd are needed by applications at all ? --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] kernel drivers [WAS: How long should I expect to wait for openrc to be ready in devuan ascii]
On 07/01/17 14:43, Didier Kryn wrote: > They preserve the external API but change all the rest. Yes, that's the way we support zillions of different devices, especially in the embedded world, w/ relatively small efforts (OF was probably one of the most important steps) and still offer good performance and stability. The kernel internals aren't just made for anybody outside the kernel community - we care a great deal of not breaking userland APIs. I tell that because,a decade ago, I tried to write driver modules > but the internal kernel API was never in sync with the doc, > while there was a new edition of the doc every year; Yes, documentation is always a big problem for a moving target (which kernel internal APIs are by definition). This might be a reason why hardware vendors don't provide drivers > for Linux: big effort for a little market. It's simply not the jobs of HW vendors to provide drivers (like in the proprietary world), it's their job to give us the proper specs (assuming they even have one :o) and collaborate w/ us to develop drivers and get them mainline. OOT-drivers are a niche for special inhouse cases or really huge things that remain in beta phase for long time. Even that is mostly obsoleted by git. Proprietary drivers aren't supported at all. They shouldn't even exist. By the way: the problem also exists for vendors where whole product lines are *based* on Linux, eg. in embedded world. Often their images are built with the hot needle and not actually maintained once on the market (I'm currently writing IIO drivers for such a case). Special fun is w/ NI DAQ devices (especially the USB ones). They still don't wanna tell us how to drive them, and only offer their crappy kernel blobs. But the USB subsystem enforces gpl-only for quite a long time now, so they cant legally support usb devices w/ their kernel blobs anymore (BTW: i hope ioremap() becomes gpl-only in near future), leaving their customers (w/ *expensive* products) in the desert. They'll have to stick w/ ancient kernels to get it working. Lesson learned: never ever buy NI. Unless you wanna invest into proper reverse engineering, but then you're probably cheaper w/ creating your own HW. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How long should I expect to wait for openrc to be ready in devuan ascii
On 170630-13:16-0400, Steve Litt wrote: > On Fri, 30 Jun 2017 14:20:08 + > Miroslav Rovis wrote: > > > On 170629-19:34-0400, zap wrote: > > > not really complaining for the most part. But I am curious that's > > > all. > > I wish I knew better, but, for a simple question of mine today (see > > my other email of today, and the links to dev1galaxy.org post of > > mine) I only after some time waiting got a reply... > > Would it be possible for you to install OpenRC from upstream source? I > know that's easily doable with runit or s6, but I know little about > OpenRC. > Not without extended work. I'm still using Palemoon that I compiled a month and ten days ago, and grsec-kernel a month and twenty days ago. Those really need updating... And on top of that, I have these months been so unimaginative to, regardless of knowing well previously about it (I even wrote about it for newbies on grsec forums), only today remembered I could use corsac's grsec-kernel packages ( How to install TorBrowser in Ascii? NOT from Stretch backports! https://dev1galaxy.org/viewtopic.php?id=773#p2731 )... And I have been trying to fix: xserver won't start with ATI (AMD) card with xserver-org 1.19.3-1 https://dev1galaxy.org/viewtopic.php?id=781 for some two or three days now... And am nowhere near any solutions.. I can compile things, and more, but it's extended, prolonged, slow work, as I have to figure out for real, for myself, lots of details about how to do it... I've only been using OpenRC, not at all modifying it (i.e. developing in any way), but the compilations in Gentoo are kind of automatic. It's just emerge . It takes horrible time in comparison to apt-installing, and is probably easier for patching packages, or modifying them, then in Devuan, but as far as more advanced usage, the mere compiling with emerge does not teach a user so very much... Well it does teach you, because you often stand by and watch... but not soo very much... :) Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I have a question about libsystemd0 in devuan ascii,
On Tue, 27 Jun 2017 at 16:50:28 -0700 Bruce Perens wrote: > On Tue, Jun 27, 2017 at 4:35 PM, Enrico Weigelt, metux IT consult < > enrico.weig...@gr13.net> wrote: > >> >> By selling, I mean, you'll first have to pay before you get the code. >> But anybody republish it at will (as long as complying to GPL), so >> how can that business model work ? > > > It doesn't, unless you have understanding customers who just don't > redistribute because they want you to stay in business. But grsecurity > doesn't work that way, it is alleged. It is alleged that they tell > customers that if they redistribute, they will no longer be allowed to be a > customer or get the next version. > > IMO that's violating the GPL. I don't remember reading anywhere in the GPL a clause forcing someone to entertain a commercial relationship with someone they'd rather not. It is stated you are free to sell or give away GPL'ed code, but it does not say you must sell it to anyone who asks you to do so. I know of no licence that contains such a clause. Alessandro ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
"Enrico Weigelt, metux IT consult" wrote: > At that point I'm curious which fancy features of systemd are needed > by applications at all ? In general - none ! But, it seems that the technique being used by it's proponents is to substitute their stuff and "force" new APIs on developers. Ie, pick a target (whether that's DNS, NTP, Syslog, ...), roll their own substitute, include that substitute by default. So while applications might not actually need any feature in SystemD - over time the devs will find it harder and harder to not use the new systemd APIs (which will certainly be the case as distros switch more and more to default to systemd, and start dropping the traditional tools as "too much work"). Once the dev is using the new APIs, it then makes it harder for users to continue using the older (and more reliable ?) tools that we already know and that have stood the test of time. At some point, I can see some devs start to ask along the lines of "why continue supporting two APIs ?" and stop maintaining the code to use one of them - if the majority of distros are using systemd then we know which one will get dropped. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
Le 01/07/2017 à 18:46, Renaud (Ron) OLGIATI a écrit : On Sat, 1 Jul 2017 10:25:20 -0500 Nate Bargmann wrote: fate accompli "Fate" is very apposite in the circumstance Cheers, Ron. "Fait accompli" means "accomplished fact", something it's a nonsense to oppose to, because it's done. Period. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Error updating ascii today
I updated a 32-bit Devuan Jessie system today (Saturday) to Ascii. After rebooting I needed to fix a few package dependency problems and I got the following message when using aptitude to update. sudo aptitude -y update Get: 1 http://packages.devuan.org/merged ascii InRelease [113 kB] Err http://packages.devuan.org/merged ascii InRelease Couldn't create temporary file /tmp/apt.conf.0TEdzn for passing config to apt-key Fetched 113 kB in 9s (12.2 kB/s) W: GPG error: http://packages.devuan.org/merged ascii InRelease: Couldn't create temporary file /tmp/apt.conf.0TEdzn for passing config to apt-key E: The repository 'http://packages.devuan.org/merged ascii InRelease' is not signed. E: Failed to download some files W: Failed to fetch http://packages.devuan.org/merged/dists/ascii/InRelease: Couldn't create temporary file /tmp/apt.conf.0TEdzn for passing config to apt-key E: Some index files failed to download. They have been ignored, or old ones used instead. I use tmpfs for /tmp and it was set at 100MB. I get the same error with a 500MB tmpfs. Is this a problem related to the ascii repository problem earlier this week or is it a signing fault? smime.p7s Description: S/MIME Cryptographic Signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] kernel drivers [WAS: How long should I expect to wait for openrc to be ready in devuan ascii]
Le 01/07/2017 à 22:09, Enrico Weigelt, metux IT consult a écrit : On 07/01/17 14:43, Didier Kryn wrote: > They preserve the external API but change all the rest. Yes, that's the way we support zillions of different devices, especially in the embedded world, w/ relatively small efforts (OF was probably one of the most important steps) and still offer good performance and stability. The kernel internals aren't just made for anybody outside the kernel community - we care a great deal of not breaking userland APIs. I tell that because,a decade ago, I tried to write driver modules > but the internal kernel API was never in sync with the doc, > while there was a new edition of the doc every year; Yes, documentation is always a big problem for a moving target (which kernel internal APIs are by definition). This might be a reason why hardware vendors don't provide drivers > for Linux: big effort for a little market. It's simply not the jobs of HW vendors to provide drivers (like in the proprietary world), it's their job to give us the proper specs (assuming they even have one :o) and collaborate w/ us to develop drivers and get them mainline. OOT-drivers are a niche for special inhouse cases or really huge things that remain in beta phase for long time. Even that is mostly obsoleted by git. Proprietary drivers aren't supported at all. They shouldn't even exist. By the way: the problem also exists for vendors where whole product lines are *based* on Linux, eg. in embedded world. Often their images are built with the hot needle and not actually maintained once on the market (I'm currently writing IIO drivers for such a case). Precisely, the domain of embedded devices is one where HW vendors write drivers. Motorolla/Emerson used to provide VME drivers for free, but OOT despite the fact that the specs of the Tundra PCI-VME bridge were public. They didn't do it for all releases. Special fun is w/ NI DAQ devices (especially the USB ones). They still don't wanna tell us how to drive them, and only offer their crappy kernel blobs. But the USB subsystem enforces gpl-only for quite a long time now, so they cant legally support usb devices w/ their kernel blobs anymore (BTW: i hope ioremap() becomes gpl-only in near future), leaving their customers (w/ *expensive* products) in the desert. They'll have to stick w/ ancient kernels to get it working. Lesson learned: never ever buy NI. I learned that lesson. They provide proprietary drivers and Labview for some versions of RedHat or Suze and only Labview knows how to talk to them. The device was never used. Unless you wanna invest into proper reverse engineering, but then you're probably cheaper w/ creating your own HW. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I have a question about libsystemd0 in devuan ascii,
It is the fact that the two actions are connected that makes it a breach. There are very many actions that are legal in isolation, but not when one is carried out as a consequence of another. The most common instances are of course in anti-discrimination law. As an expert witness, I would have no trouble connecting them for a judge and showing how they were tantamount to an added term under section 6. On Sat, Jul 1, 2017, 13:49 Alessandro Selli wrote: > On Tue, 27 Jun 2017 at 16:50:28 -0700 > Bruce Perens wrote: > > > On Tue, Jun 27, 2017 at 4:35 PM, Enrico Weigelt, metux IT consult < > > enrico.weig...@gr13.net> wrote: > > > >> > >> By selling, I mean, you'll first have to pay before you get the code. > >> But anybody republish it at will (as long as complying to GPL), so > >> how can that business model work ? > > > > > > It doesn't, unless you have understanding customers who just don't > > redistribute because they want you to stay in business. But grsecurity > > doesn't work that way, it is alleged. It is alleged that they tell > > customers that if they redistribute, they will no longer be allowed to > be a > > customer or get the next version. > > > > IMO that's violating the GPL. > > I don't remember reading anywhere in the GPL a clause forcing someone to > entertain a commercial relationship with someone they'd rather not. It is > stated you are free to sell or give away GPL'ed code, but it does not say > you > must sell it to anyone who asks you to do so. I know of no licence that > contains such a clause. > > > Alessandro > ___ > 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] How long should I expect to wait for openrc to be ready in devuan ascii
On 07/01/2017 04:20 AM, Alessandro Selli wrote: > On Sat, 1 Jul 2017 at 00:24:59 +0200 > Didier Kryn wrote: > >> Le 30/06/2017 à 23:30, Vincent Bentley a écrit : >>> Along time ago, well designed and well behaved software could be >>> recognised by the number of years passed without changes. I worked at >>> one place that was proud of release version birthdays. >> Agreed. That's why I'm always bothered with the fast release pace >> of some essential pieces of software, with the fastest being the GCC and >> the Linux kernel. > Well, this is understandable: both the compiler and the kernel must keep > up with the frantic rollout of new hardware from many vendors. You don't > have to upgrade if you don't need support for the laters pieces of silicon > the industry has churned out the past month. What matters is that older > releases are still maintained and that they work, of course. From time to > time support for a new protocol/filesystem is merged, too. > This is not the > case of init systems, as they are not supposed to be sensitive to the > particular hardware/filesystem they are running on. I wonder why zap feels > the need of a "regularly updated" init, are there issues in the current > Devuan init that he feels are not being adequately addressed? > I was not aware of the lack of sensitivity for init systems. > ___ > 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] How long should I expect to wait for openrc to be ready in devuan ascii
On 07/01/2017 05:32 AM, Svante Signell wrote: > On Fri, 2017-06-30 at 20:12 -0400, zap wrote: >> It is a little too confusing trying to install openrc at the moment >> so I >> will pass for now... >> >> It is just a shame that the runit-init package was taken down... > The instructions are crystal clear... There were parts that didn't make sense to me though. I am using amd64 btw and I could not find all the requirements of this, maybe it is me, but I cannot find all the packages required in: debian/control as addressed below: 4) cd util-linux-2.29.2/ Install all packages needed in debian/control as root: see Build-Depends: entry > (And btw: Daniel Reurich is working hard to get util-linux built) > > Regarding runit-init Steve Litt will hopefully provide a Devuan package > in due time. At least he is promoting it a lot. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd: good riddance!
* On 2017 01 Jul 11:47 -0500, Renaud OLGIATI wrote: > On Sat, 1 Jul 2017 10:25:20 -0500 > Nate Bargmann wrote: > > > fate accompli > > "Fate" > is very apposite in the circumstance One misspell and a person's reputation is shot forever! :-) - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Why /command ?
Hi all, I'm writing a document on how to install runit on Devuan, with the hope that some day it will lead to a Devuan package that makes sense and to the best degree possible implements the goals of the software's author. Most of it's pretty straightforward, but the runit install scripts (package/upgrade to be specific) create /command right off the root, and the runit docs suggest I create /package right off the root. These are things that most distros would refuse to do. So I was wondering what the original intent was in having these two directories directly off the root? Is it so the init and supervision can proceed even before partition mounts are complete? Is there some other reason? Can anyone recommend setups that fulfill the reasons for the direct-off-root dirs without having direct-off-root dirs? By the way, if the runit docs go well, I'll do the same thing with s6. Thanks, SteveT Steve Litt June 2017 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How long should I expect to wait for openrc to be ready in devuan ascii
On 06/30/2017 04:21 PM, zap wrote: > > On 06/30/2017 11:21 AM, Svante Signell wrote: >> On Thu, 2017-06-29 at 19:34 -0400, zap wrote: >>> not really complaining for the most part. But I am curious that's >>> all. >>> >> Hi zap, >> >> As I wrote earlier, you can install openrc by: >> 0) Enable ascii in /etc/apt/sources.list >> deb http://auto.mirror.devuan.org/merged ascii main >> >> 1) add to /etc/apt/sources.list >> deb http://packages.devuan.org/devuan/ ascii-proposed main >> >> 2) apt-get update >> >> 3) apt-get download sysvinit-utils >> >> 4) Build* and install libfdisk1 and util-linux (2.29.21+devuan1). If >> you are in i386 I can send you them. Otherwise see below. >> >> dpkg -i libfdisk1_2.29.2-1+devuan1_i386.deb util-linux_2.29.2- >> 1+devuan1_i386.deb sysvinit-utils_2.88dsf-59.9+devuan2_i386.deb >> >> 5) apt-get upgrade: Installs latest initscripts: >> initscripts (2.88dsf-59.9+devuan2) >> >> 6) apt-get -s install openrc >> Check that all is OK, then remove the -s >> The following additional packages will be installed: >> libeinfo1 librc1 >> The following packages will be REMOVED: >> sysv-rc >> >> To build util-linux for your arch: >> 1) Add to sources.list >> deb-src http://packages.devuan.org/devuan/ ascii-proposed main >> >> 2) Download sources >> dget https://packages.devuan.org/devuan/pool/main/u/util-linux/util-lin >> ux_2.29.2-1+devuan1.dsc >> >> 3) Unpack sources >> dpkg-source -x util-linux_2.29.2-1+devuan1.dsc >> >> 4) cd util-linux-2.29.2/ >> Install all packages needed in debian/control as root: >> see Build-Depends: entry >> >> 5) dpkg-buildpackage 2>&1 | tee buildpackage-2.29.2-1+devuan1.log >> (see above at point 4) > Okay, this is a better way to know how to do so. I didn't understand the > instructions before. that's all... thanks Actually I have to make an edit, I am using an x86_64 bit machine. and some of the packages in the list for needed, debian/control, I cannot find. odd though it may be... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why /command ?
Le 02/07/2017 à 01:37, Steve Litt a écrit : Hi all, I'm writing a document on how to install runit on Devuan, with the hope that some day it will lead to a Devuan package that makes sense and to the best degree possible implements the goals of the software's author. Most of it's pretty straightforward, but the runit install scripts (package/upgrade to be specific) create /command right off the root, and the runit docs suggest I create /package right off the root. These are things that most distros would refuse to do. So I was wondering what the original intent was in having these two directories directly off the root? Is it so the init and supervision can proceed even before partition mounts are complete? Is there some other reason? Can anyone recommend setups that fulfill the reasons for the direct-off-root dirs without having direct-off-root dirs? By the way, if the runit docs go well, I'll do the same thing with s6. Sysvinit reads its configuration and scripts from directory trees in /etc. Therefore, why not put /command and /package somewhere there, eg in /etc/runit ? Everybody assumes /etc must be present when init starts. Just my first idea. There might be better ones... Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
