Re: [DNG] UPS Upgrade for Amprolla
On Tue, 11 Jul 2017, Linux O'Beardly wrote: >The amprolla UPS upgrade has been completed without issue. Here's >to more stability. man, many thanks! your solid support is very helpful and reassuring. greets ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UPS Upgrade for Amprolla
On Tue, Jul 11, 2017 at 02:19:50AM -0400, Linux O'Beardly wrote: > The amprolla UPS upgrade has been completed without issue. Here's to more > stability. > > Take care, > Great O'Beardly! Thanks KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- 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] You know, isn't ascii being more stable ironic to anyone?
On Tue, 11 Jul 2017 00:29:51 +0200 Adam Borowski wrote: > On Mon, Jul 10, 2017 at 10:35:27PM +0100, Rowland Penny wrote: > > On Mon, 10 Jul 2017 16:17:40 -0500 goli...@dyne.org wrote: > > > > > ascii,samba-libs > > > > Don't understand why this is on the list, surely this will be built > > with the other Samba packages (they get built from the same source > > code), so why does this still have a systemd dependancy ? > > I guess no one got around to adjusting the packaging. > > Here's a debdiff (attached) from my repository -- I've got no upload > rights in Devuan (other than to ceres in a roundabout way :p), but > someone can apply this; should be good enough. > You seem to be missing my point, there are a lot more Samba packages than 'samba-libs', they all get built from the same tarball, so why is there only 'samba-libs' on that list ? By the way, you do not have to do anything to the Samba code to stop the systemd bits being added, you just have to make sure that the systemd development files are not installed. Rowland ___ 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, 2017-07-11 at 03:56 +, Miroslav Rovis wrote: > On 170710-23:39+0200, Svante Signell wrote: > > On Mon, 2017-07-10 at 14:12 +, Miroslav Rovis wrote: > > > Hi Svante and everybody! > > > > > > (and zap, to whom you right as second person in the email I'm > > > replying to. zap > > > might give useful advice, since he --later-- reported he > > > successfully > > > installed > > > OpenRC) > > > > > > Svante, I'm taking your suggestion in the other thread some three > > > days ago now, > > > or so. > > > > > > I want to try OpenRC in my Devuan. > > > > Ok, let's see if I can help you. > > Svante, I got packages from zap. zap, I got your email, it's just the > Lurker > that is limited to 40k (which means you can only send some 30k > (because mail > encodes in base64) in one email As written by later mails on this thread, the email limit should stay as it is. Larger files should be uploaded and hosted somewhere to download. > ...but I got them: > > $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \ This one is not OK, see below. This is the Debian (unpatched version) > > > > Did you see my mail? I can send you the packages > > > > libfdisk1 2.29.2-1+devuan1 > > > > util-linux2.29.2-1+devuan1 > > > > > > I believe/hope all that is necessary is now in these repos that > > > you > > > wrote below (but is it so?): No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and you get them by adding to sources.list: (+ apt-get update) sysvinit-core sysvinit-utils initscripts bootlogd (optional) > > > > > > deb http://packages.devuan.org/devuan ascii-proposed main > > > I hope that is fine. > > > > Yes you need that line for the latest version of sysvinit* and > > initscripts (2.88dsf-59.9+devuan2) > > sysvinit-utils_2.88dsf-59.9_amd64.deb is what I got from zap (see > above) You should apt-get download sysvinit-utils and then (as I wrote to zap) (version 2.88dsf-59.9+devuan2, not 2.88dsf-59.9): 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 (in one line, the mailer might wrap) Then you can apt-get install -s openrc and only sysvinit-rc will be removed in addition to libeinfo1 librc1 openrc (0.23-1+b1) being installed. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
...on Mon, Jul 10, 2017 at 05:33:26PM -0400, Miles Fidelman wrote: > There's a point at which this all becomes unstoppable, unless some equally > well-placed & influential folks start pushing back VERY hard. That would certainly help, but I also think that it's much more important that someone has started actually doing something in terms of infrastructure and development, instead of spending that time on convincing others to do something. So here we are, and after following this thing for the past two years, I have no doubt that moving all my Debian systems to Devuan has been the right choice. So, thank you for making that possible, everyone. At the same time I have no illusions where the market is going - my employer now happily buys SuSE and Red Hat licenses instead of Solaris or HP-UX, and I won't get them to pick up Devuan (except maybe for some fringe stuff under my direct control). Which really doesn't matter though - it's just the same as in the early Debian days, with different roles... Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On 10.07.2017 23:10, Steve Litt wrote: Remember, we're fighting a huge and well funded opponent, possessing the money to throw at programmers to keep the systemd mess running, as well as money for publicity to counter common sense with neverending bulldroppings. Seen in that context, what we've accomplished is a miracle. We don't need to fight anything. Just concentrate on the stuff *we* need (seriously, does anybobdy here need gnome3 ?) and patch out the crap when neccessary. And just not caring about that lennartware crap at all. Not even wasting time w/ debates about that crap, over and over again. (and yes: that's really annying me) Why do you waste your precious lifetime w/ lennartware at all ? --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
"Enrico Weigelt, metux IT consult" wrote: > We don't need to fight anything. Just concentrate on the stuff *we* > need (seriously, does anybobdy here need gnome3 ?) and patch out the > crap when neccessary. > > And just not caring about that lennartware crap at all. Not even wasting > time w/ debates about that crap, over and over again. (and yes: that's > really annying me) > > Why do you waste your precious lifetime w/ lennartware at all ? There are (IMO) three things needed : 1) Have an alternative - ie Devuan. In that, I salute those who are actually doing the hard stuff I wouldn't know where to start with. 2) Make people aware that there is an alternative. 3) Explain (in rational, technical, non-political) terms why people should care that there is a choice - and why we think they would be wise to take it. Without 2 and 3, there won't be large scale adoption of the alternatives - and without that, there is distinctly less incentive for the upstream devs to keep support for the alternatives. As has been mentioned before, part of the "battle plan" for systemd seems to be to keep taking more and more "standard stuff", deprecate it, and introduce new systemd versions with a new API. Thus, a package they needs to run on a systemd infested system has to support the "new improved" API. This means that the dev now faces a choice - do they keep support for the old API ? To do so means more work - effectively they have to maintain two bits of code everywhere they use that function, and that means more work. If they perceive that "hardly anyone" still needs the old API - then there's a temptation to drop the old code, or stop maintaining it. If that happens, then the job of maintaining that package in a non-systemd distro becomes harder. Ideally, projects like Devuan need to get enough users that they can entice package maintainers over from Debian. Wouldn't it be wonderful if Devuan were able to take the lead, and Debian end up having to port packages from it - yes that's pie in the sky thinking at the moment, but if you don't have ambition then ... So yes, I agree that "discussing" it time and time again (especially in a "preaching to the converted" forum) isn't helpful - but just ignoring it isn't going to work either. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On 11.07.2017 13:55, Simon Hobson wrote: There are (IMO) three things needed : > 1) Have an alternative - ie Devuan. And there're other non-systemd-Distros out there. Just collaborate with them and ignore the others. (we could also set up some tiny patch- sending bots that penetrate nasty upstreams w/ patches ...) In that, I salute those who are actually doing the hard stuff I wouldn't know where to start with. ACK. 2) Make people aware that there is an alternative. A bit media appearance is fine, but I wouldn't waste too much resources with that. Better be present on various upstream maillists and post systemd-removing patches there. 3) Explain (in rational, technical, non-political) terms why people should care that there is a choice - and why we think they would be wise to take it. I wouldn't waste time on that. They have to learn by themselves - preaching doesn't help. Without 2 and 3, there won't be large scale adoption of the alternatives NAK. 1) is enought. In the past we fought bigger dragons, eg. getting free from M$. - and without that, there is distinctly less incentive for the upstream devs to keep support for the alternatives. Optional. We patch out the crap for packages we need, and drop those we don't need. Forget about Gnome3 - let it die alone and silent, as it deserves. As has been mentioned before, part of the "battle plan" for systemd > seems to be to keep taking more and more "standard stuff", deprecate > it, and introduce new systemd versions with a new API. Thus, a package they needs to run on a systemd infested system has to support the > "new improved" API. Just patch out the crap. And ignore the totally broken packages that aren't worth the effort. do they keep support for the old API ? To do so means more work - > effectively they have to maintain two bits of code everywhere they use that function, and that means more work. Not, quite. Just rapair and support the original API - drop the systemd crap entirely. If that happens, then the job of maintaining that package in a > non-systemd distro becomes harder. Well, partial / downstream fork is more work, but all we need is to be consequent. Of course, we should directly cooperate w/ other systemd-free distros. --mtx ___ 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]
On 05.07.2017 23:30, Didier Kryn wrote: > And there are a whole menagerie of addressing and transfer protocols, > including chained dma transfers Especially things like DMA are naturally kernel domain. I wouldn't ever allow any direct access to dma controllers from userland. > In our case it is waveform digitizers and the interaction is so > complex that it cannot be done in a kernel module What exactly is so complex about that ? Smells like a typical task for IIO to me. Some others consider there should be one driver per VME device you > want to talk to, on top of the raw VME driver. Exactly. These people only ever had to deal with simplistic devices. Gabriel Paubert has never seen an application transfering more than a few bytes, while we are transferring data at 320MB/s. Those kind of things usually involve proper timing, caring about caching, etc, etc. Natural kernel domain. Which absurdities, exactly ? Bus errors were not reported to the application but instead caused a message to syslog! This makes it hard to use; or your application should monitor the log files! Yes, that's hackish, of course. This isn't the case here. AFAIU, their BSP contains a VME driver and a device tree. I think it's all GPL. Their buzyness is to send hardware and they make sure their clients can use it. Looks like your vendor is an exception. These are SBCs with everything soldered: VME, flash memory, UARTs, USB hub, Sata controllers, Ethernet ports etc... And you just plug it into a VME crate. It makes no sense to develop a board like this to use a dozen of them. We made the digitizers and it was already a big deal for our small team. Could you develop what is IIO for DAQ devices? What's the difference between you digitizes and usual DAQ devices ? What do you actually do with them ? Some clear requirements on the table, please ;-) Is it something allowing to write drivers in user space? What kind of drivers do you wanna have in userland ? And why ? --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On 7/11/17 7:55 AM, Simon Hobson wrote: "Enrico Weigelt, metux IT consult" wrote: We don't need to fight anything. Just concentrate on the stuff *we* need (seriously, does anybobdy here need gnome3 ?) and patch out the crap when neccessary. And just not caring about that lennartware crap at all. Not even wasting time w/ debates about that crap, over and over again. (and yes: that's really annying me) Why do you waste your precious lifetime w/ lennartware at all ? There are (IMO) three things needed : 1) Have an alternative - ie Devuan. In that, I salute those who are actually doing the hard stuff I wouldn't know where to start with. 2) Make people aware that there is an alternative. 3) Explain (in rational, technical, non-political) terms why people should care that there is a choice - and why we think they would be wise to take it. Without 2 and 3, there won't be large scale adoption of the alternatives - and without that, there is distinctly less incentive for the upstream devs to keep support for the alternatives. As has been mentioned before, part of the "battle plan" for systemd seems to be to keep taking more and more "standard stuff", deprecate it, and introduce new systemd versions with a new API. Thus, a package they needs to run on a systemd infested system has to support the "new improved" API. This means that the dev now faces a choice - do they keep support for the old API ? To do so means more work - effectively they have to maintain two bits of code everywhere they use that function, and that means more work. If they perceive that "hardly anyone" still needs the old API - then there's a temptation to drop the old code, or stop maintaining it. If that happens, then the job of maintaining that package in a non-systemd distro becomes harder. Ideally, projects like Devuan need to get enough users that they can entice package maintainers over from Debian. Wouldn't it be wonderful if Devuan were able to take the lead, and Debian end up having to port packages from it - yes that's pie in the sky thinking at the moment, but if you don't have ambition then ... So yes, I agree that "discussing" it time and time again (especially in a "preaching to the converted" forum) isn't helpful - but just ignoring it isn't going to work either. ___ Exactly. The issue isn't whether we have systemd-free distros - there are more than Devuan (gentoo, the BSDs come to mind) - it's how the developer community moves forward. Do we start seeing important packages come out as requiring systemd. -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
"Enrico Weigelt, metux IT consult" wrote: >> 3) Explain (in rational, technical, non-political) terms why people should >> care that there is a choice - and why we think they would be wise to take it. > > I wouldn't waste time on that. They have to learn by themselves - > preaching doesn't help. Preaching is probably the wrong word to have used. But it clear from reading comments on any article mentioning systemd that a great many people really have no idea why they should care. it's not uncommon to see one comment saying why one person doesn't want to run it (perhaps to do with debuggability when it won't boot), to get a reply along the lines of "I use and it works just fine - what's the problem ?" So there really is a problem to solve there. People are using it, many don't know, but of those who are, they don't see why it's a problem (and in particular, why someone should want to/be able to not use it) because "it works" for them. >> Without 2 and 3, there won't be large scale adoption of the alternatives > > NAK. 1) is enought. > In the past we fought bigger dragons, eg. getting free from M$. I don't think that's comparable. >> - and without that, there is distinctly less incentive for the upstream devs >> to keep support for the alternatives. > > Optional. We patch out the crap for packages we need, and drop those we > don't need. But it's a lot less ongoing effort to keep that support in upstream. Yes you can patch it, but the more embedded systemd becomes, the more patching is needed. Keep/get a critical mass so that upstream devs see a case for keeping the non-systemd stuff, and maintaining the non-systemd distro is less work. I cannot see a case for saying that (in total) it's less work to patch a package after the fact than it would be to maintain that package in a compatible state to start with. >> do they keep support for the old API ? To do so means more work - > > effectively they have to maintain two bits of code everywhere >> they use that function, and that means more work. > > Not, quite. Just rapair and support the original API - drop the > systemd crap entirely. I think you've missed the point. "Repair and support the original API" isn't an option if the upstream dev wants his package to be runable on a systemd system - because systemd dev policy appears to be deliberately forcing that binary choice of "systemd APIs or nothing" into anything it can. And the team behind systemd have shown that they have no intension of fixing anything when they can better support their aims by deprecating it and bringing something new (and in their eyes, improved) to the table. If the systemd devs showed the sort of attitude to the rest of the world (devs and users) that others espouse, then there'd be no problem. It's the very fact that they appear to be forcing this binary choice (systemd or nothing) is why we're having this discussion. That's why I suggest it's important to keep the upstream devs onside - because it's a lot easier to keep support for the traditional APIs etc as an integral part of a package than it is to go through patching after the fact. And it's easier to keep them onside if we can show that there's a large (ie significant) user base for the non-systemd version. At present it's (I assume) fairly easy to patch out systemd-isms as it's not been around long enough to get major tentacles into most stuff. Over time that will change - systemd will get deeper and deeper into packages, and it will get harder and harder to remove it, and to add in the now missing parts. ___ 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 07/11/2017 06:01 AM, Svante Signell wrote: > On Tue, 2017-07-11 at 03:56 +, Miroslav Rovis wrote: >> On 170710-23:39+0200, Svante Signell wrote: >>> On Mon, 2017-07-10 at 14:12 +, Miroslav Rovis wrote: Hi Svante and everybody! (and zap, to whom you right as second person in the email I'm replying to. zap might give useful advice, since he --later-- reported he successfully installed OpenRC) Svante, I'm taking your suggestion in the other thread some three days ago now, or so. I want to try OpenRC in my Devuan. >>> Ok, let's see if I can help you. >> Svante, I got packages from zap. zap, I got your email, it's just the >> Lurker >> that is limited to 40k (which means you can only send some 30k >> (because mail >> encodes in base64) in one email > As written by later mails on this thread, the email limit should stay > as it is. Larger files should be uploaded and hosted somewhere to > download. > >> ...but I got them: >> >> $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \ > This one is not OK, see below. This is the Debian (unpatched version) > > Did you see my mail? I can send you the packages > libfdisk1 2.29.2-1+devuan1 > util-linux2.29.2-1+devuan1 I believe/hope all that is necessary is now in these repos that you wrote below (but is it so?): > No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and you get > them by adding to sources.list: (+ apt-get update) > sysvinit-core > sysvinit-utils > initscripts > bootlogd (optional) My bad, I forgot a few important packages to mention... xD deb http://packages.devuan.org/devuan ascii-proposed main I hope that is fine. >>> Yes you need that line for the latest version of sysvinit* and >>> initscripts (2.88dsf-59.9+devuan2) >> sysvinit-utils_2.88dsf-59.9_amd64.deb is what I got from zap (see >> above) > You should apt-get download sysvinit-utils and then (as I wrote to zap) > (version 2.88dsf-59.9+devuan2, not 2.88dsf-59.9): > > 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 > > (in one line, the mailer might wrap) > > Then you can apt-get install -s openrc and only sysvinit-rc will be > removed in addition to libeinfo1 librc1 openrc (0.23-1+b1) being > installed. > ___ > 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] Linus can no longer trust "init"
gnome 3 is crap, need I say more? On 07/11/2017 07:39 AM, Enrico Weigelt, metux IT consult wrote: > On 10.07.2017 23:10, Steve Litt wrote: > >> Remember, we're fighting a huge and well funded opponent, possessing >> the money to throw at programmers to keep the systemd mess running, as >> well as money for publicity to counter common sense with neverending >> bulldroppings. Seen in that context, what we've accomplished is a >> miracle. > > We don't need to fight anything. Just concentrate on the stuff *we* > need (seriously, does anybobdy here need gnome3 ?) and patch out the > crap when neccessary. > > And just not caring about that lennartware crap at all. Not even wasting > time w/ debates about that crap, over and over again. (and yes: that's > really annying me) > > Why do you waste your precious lifetime w/ lennartware at all ? > > > --mtx > ___ > 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] Linus can no longer trust "init"
Quote: "gnome 3 is crap" Nah, Gnome 3 is a The Brand that must be shoved down people's throats. Systemd, is the 'invisible' 'string puller' that lurks behind the scenes. -- 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] Linus can no longer trust "init"
On Tue, 11 Jul 2017 14:02:47 +0100, Simon wrote in message <98028782-f385-412e-aeab-2edf14663...@thehobsons.co.uk>: > "Enrico Weigelt, metux IT consult" wrote: > > >> 3) Explain (in rational, technical, non-political) terms why > >> people should care that there is a choice - and why we think they > >> would be wise to take it. > > > > I wouldn't waste time on that. They have to learn by themselves - > > preaching doesn't help. > > Preaching is probably the wrong word to have used. But it clear from > reading comments on any article mentioning systemd that a great many > people really have no idea why they should care. it's not uncommon to > see one comment saying why one person doesn't want to run it (perhaps > to do with debuggability when it won't boot), to get a reply along > the lines of "I use and it works just > fine - what's the problem ?" So there really is a problem to solve > there. People are using it, many don't know, but of those who are, > they don't see why it's a problem (and in particular, why someone > should want to/be able to not use it) because "it works" for them. ..we _could_ "preach" by testing for systemd features and throw warning screens in the faces of the downstream etc users, and offer info links (and/or buttons) and an "I know WTF I am doing."-button to click thru. > >> Without 2 and 3, there won't be large scale adoption of the > >> alternatives > > > > NAK. 1) is enought. > > In the past we fought bigger dragons, eg. getting free from M$. > > I don't think that's comparable. > > >> - and without that, there is distinctly less incentive for the > >> upstream devs to keep support for the alternatives. > > > > Optional. We patch out the crap for packages we need, and drop > > those we don't need. > > But it's a lot less ongoing effort to keep that support in upstream. ..sometimes, with certain people, this is not a viable option, that's _when_ we need to fork these packages. > Yes you can patch it, but the more embedded systemd becomes, the more > patching is needed. Keep/get a critical mass so that upstream devs > see a case for keeping the non-systemd stuff, and maintaining the > non-systemd distro is less work. I cannot see a case for saying that > (in total) it's less work to patch a package after the fact than it > would be to maintain that package in a compatible state to start with. > > >> do they keep support for the old API ? To do so means more work - > > > effectively they have to maintain two bits of code everywhere > >> they use that function, and that means more work. > > > > Not, quite. Just rapair and support the original API - drop the > > systemd crap entirely. > > I think you've missed the point. "Repair and support the original > API" isn't an option if the upstream dev wants his package to be > runable on a systemd system - because systemd dev policy appears to > be deliberately forcing that binary choice of "systemd APIs or > nothing" into anything it can. ..that's _why_ these upstream packages needs to be forked, by us. > And the team behind systemd have shown > that they have no intension of fixing anything when they can better > support their aims by deprecating it and bringing something new (and > in their eyes, improved) to the table. If the systemd devs showed the > sort of attitude to the rest of the world (devs and users) that > others espouse, then there'd be no problem. It's the very fact that > they appear to be forcing this binary choice (systemd or nothing) is > why we're having this discussion. > > That's why I suggest it's important to keep the upstream devs onside > - because it's a lot easier to keep support for the traditional APIs > etc as an integral part of a package than it is to go through > patching after the fact. And it's easier to keep them onside if we > can show that there's a large (ie significant) user base for the > non-systemd version. > > At present it's (I assume) fairly easy to patch out systemd-isms as > it's not been around long enough to get major tentacles into most > stuff. Over time that will change - systemd will get deeper and > deeper into packages, and it will get harder and harder to remove it, > and to add in the now missing parts. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On Tue, Jul 11, 2017 at 02:10:04PM +0200, Enrico Weigelt, metux IT consult wrote: > On 11.07.2017 13:55, Simon Hobson wrote: > > > >3) Explain (in rational, technical, non-political) terms why people > >should care that there is a choice - and why we think they would be > >wise to take it. > > I wouldn't waste time on that. They have to learn by themselves - > preaching doesn't help. There are those who feel uneasy, but need the rhetoric to know just what it is that make them uneasy. They are the ones the ratonal, technical, nonpolitical terms will reach. Conclusions about such matters are often obvious only when they have been pointed out. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] 404.
Hi there, On Tue, 11 Jul 2017, KatolaZ wrote: Please have a look at: https://dev1galaxy.org/viewtopic.php?id=589 for a list of ways in which everybody can help Devuan. ... I did that. And I also looked at https://dev1galaxy.org/viewtopic.php?id=549 and I followed the instructions as far as installing d1h, and getting an account on git.devuan.org, and then I got as far as https://git.devuan.org/devuan/devuan-maintainers where it says I can [Adopt a package] or I can [create an issue] but I don't seem to be able to do any of those things, because all the links on that page seem to be dead. Am I missing something? I want to adopt the openvpn package, because I've used it for fifteen years and I really can't work without it. -- 73, Ged. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] 404.
On Tue, Jul 11, 2017 at 03:41:08PM +0100, G.W. Haywood wrote: > Hi there, > > On Tue, 11 Jul 2017, KatolaZ wrote: > > >Please have a look at: > > > > https://dev1galaxy.org/viewtopic.php?id=589 > > > >for a list of ways in which everybody can help Devuan. ... > > I did that. And I also looked at > > https://dev1galaxy.org/viewtopic.php?id=549 > > and I followed the instructions as far as installing d1h, and getting > an account on git.devuan.org, and then I got as far as > > https://git.devuan.org/devuan/devuan-maintainers > Is the step "go to https://git.devuan.org/devuan/devuan-maintainers"; mentioned in the d1h guide? :) Some of the documentation currently present in git.devuan.org is not updated. Please stick to the walkthrough I sent you. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- 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] Linus can no longer trust "init"
On 11.07.2017 15:02, Simon Hobson wrote: But it clear from reading comments on any article mentioning > systemd that a great many people really have no idea why > they should care. Just pointing out some fundamental problems (especially on bug or problem reports) and let them learn by own experience. it's not uncommon to see one comment saying why one person > doesn't want to run it (perhaps to do with debuggability when it won't boot), to get a reply along the lines > if "I use and it works just fine - > what's the problem ?" It's the same as "windows run fine". Maybe for them it really is, I couldn't care less. Just ignore these folks - they won't help us in any way - we don't need them, they're just irrelevant. So there really is a problem to solve there. It's their problem, not yours, not mine. So, just don't care, unless they really ask for help. And if they do, there's a simple and efficient answer: get rid of systemd. Period. NAK. 1) is enought. In the past we fought bigger dragons, eg. getting free from M$. I don't think that's comparable. You're right. The MS dragon was magnitudes bigger. Optional. We patch out the crap for packages we need, and drop those we don't need. But it's a lot less ongoing effort to keep that support in upstream. Yes, that's why we'd regularily post our patches to upstreams (more precisely: let some scripts do that - don't waste precious life time on dumb people) Yes you can patch it, but the more embedded systemd becomes, the > more patching is needed. Maybe, maybe not, we'll see. Challenge accepted. And it only affects packages we really need, anyways. Do we have any real trouble maker on the table right now ? If so, do we need it or is it just useless toy like gnome3 ? Keep/get a critical mass so that upstream devs see a case for > keeping the non-systemd stuff, and maintaining the non-systemd distro > is less work. In worst case, we can become our own upstream. Of course taking folks from all the other non-systemd distros aboard. Not, quite. Just rapair and support the original API - drop the systemd crap entirely. I think you've missed the point. "Repair and support the original API" > isn't an option if the upstream dev wants his package to be runable > on a systemd system Seems you missed my point, so to make it crystal clear: fuck off the upstream. Collect the folks from the other distros, fork off and also make big noise about that. Including using social technics to make those upstreams feel really bad about their choice (at that point, we're in the political sphere, so use political tools). And the team behind systemd have shown that they have no intension of > fixing anything when they can better support their aims by deprecating it and bringing something new (and in their eyes, improved) to the table. We all know that, had been said a thousand times, no need to repeat it again and again. We all know that Lennartism is an ugly totalitarian ideology. But as long as they're not making chaos in the streets and start actually hurting people, we can easily ignore them (and even if they did, we'd take care of that). Those psychopaths live from our attention (because they just don't have anything else in their petty miserable lifes) - don't give them this energy anymore, and they'll sooner or later die. Alone. The (few) Lennartists are not the folks we should care about, just like w/ Fascists, Socialists, Satanists, and all the other insane ideologies. Instead we should care about their blind followers. And most of them only learn by pain. If the systemd devs showed the sort of attitude to the rest of the world If we ever invest energy into these folks, then make they look as what they really are: ridiculous petty psychopaths. We should never engage them, just laugh about them. It's the very fact that they appear to be forcing this binary choice > (systemd or nothing) is why we're having this discussion. No, it's the fact that they have so many dumb, brainwashed followers. That's why I suggest it's important to keep the upstream devs onside Depends on what you exactly mean by "onside". If it's about feeding them with bugfixes (and systemd dependency *is* a bug, a critical one), then we aggree. But we should make it crystal clear, that we'll do whatever it takes to keep our systems free from Lennartware. Especially including the option of a fork. (and that, of course, also includes eradicating libsystemd0) Yet again, we're in the area of politicts. Actually on the geopolitical scale. So, we gotta act like that. We'll defend our homeland by any means necessary - no surrender, no retreat. > Over time that will change - systemd will get deeper and deeper into packages, and it will get harder and harder to remove it, and to add > in the now missing parts. On any such patch, fire back. And don't miss a chance to put lots of salt in the wound. To be more practical: I'd suggest spinning off a (distro agnost
Re: [DNG] I have a question about libsystemd0 in devuan ascii,
On 170711-09:13-0400, zap wrote: > > > On 07/11/2017 06:01 AM, Svante Signell wrote: > > On Tue, 2017-07-11 at 03:56 +, Miroslav Rovis wrote: > >> On 170710-23:39+0200, Svante Signell wrote: > >>> On Mon, 2017-07-10 at 14:12 +, Miroslav Rovis wrote: > Hi Svante and everybody! > > (and zap, to whom you right as second person in the email I'm > replying to. zap > might give useful advice, since he --later-- reported he > successfully > installed > OpenRC) > > Svante, I'm taking your suggestion in the other thread some three > days ago now, > or so. > > I want to try OpenRC in my Devuan. > >>> Ok, let's see if I can help you. > >> Svante, I got packages from zap. zap, I got your email, it's just the > >> Lurker > >> that is limited to 40k (which means you can only send some 30k > >> (because mail > >> encodes in base64) in one email > > As written by later mails on this thread, the email limit should stay > > as it is. Larger files should be uploaded and hosted somewhere to > > download. > > > >> ...but I got them: > >> > >> $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \ > > This one is not OK, see below. This is the Debian (unpatched version) > > > > Did you see my mail? I can send you the packages > > libfdisk1 2.29.2-1+devuan1 > > util-linux2.29.2-1+devuan1 > I believe/hope all that is necessary is now in these repos that > you > wrote below (but is it so?): > > No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and you get > > them by adding to sources.list: (+ apt-get update) > > sysvinit-core > > sysvinit-utils > > initscripts > > bootlogd (optional) > My bad, I forgot a few important packages to mention... xD The bootlogd is only suggested. Ah, first thing to say is: I've successfully installed and rebooted a couple of times each: my clone (which I use also for testing, and which is the only that sees ever any internet), and my master Air-Gap system. And maybe the second thing to say is. If anyone needs the packages that ( if those are, and I think they are; they worked for me ) are needed to install OpenRC, get them at: https://lists.dyne.org/lurker/message/20170711.035614.33ea6395.en.html They are also hashed by me in my email in this very thread that we are writing our discussions about OpenRC --under bad subject, but it's really too late now to correct that-- I think its previous mail of mine that I sent, or whatever, my Palemoon still crashes unpredictably, and can't open huge threads, and that one is a huge thread where this new discussion belongs to... The instructions how to get the packages are: OpenRC installation in Devuan Ascii https://dev1galaxy.org/viewtopic.php?id=1128#p3286 And of course, you can also get them directly: https://www.croatiafidelis.hr/foss/Devuan-OpenRC/ Pls., guys, I think all went correctly, but I think I should leave the report there, at: ( same topic as linked a few lines up ) https://dev1galaxy.org/viewtopic.php?id=1128 and not repeat it here... > > deb http://packages.devuan.org/devuan ascii-proposed main > I hope that is fine. > >>> Yes you need that line for the latest version of sysvinit* and > >>> initscripts (2.88dsf-59.9+devuan2) > >> sysvinit-utils_2.88dsf-59.9_amd64.deb is what I got from zap (see > >> above) > > You should apt-get download sysvinit-utils and then (as I wrote to zap) > > (version 2.88dsf-59.9+devuan2, not 2.88dsf-59.9): > > > > 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 > > > > (in one line, the mailer might wrap) > > > > Then you can apt-get install -s openrc and only sysvinit-rc will be > > removed in addition to libeinfo1 librc1 openrc (0.23-1+b1) being > > installed. > > ___ Thanks Svante, thanks zap, thanks also Rick Moen (I even mentioned you in that Dev1Galaxy topic linked above when I saw full shouting at me that ugly message that you wrote about), and Adam Borowski... -- 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
[DNG] PulseAudio (was: Re: Linus can no longer trust "init")
On Tue, Jul 11, 2017 at 01:39:11PM +0200, Enrico Weigelt, metux IT consult wrote: > And just not caring about that lennartware crap at all. Not even wasting > time w/ debates about that crap, over and over again. (and yes: that's > really annying me) > > Why do you waste your precious lifetime w/ lennartware at all ? Because so many upstreams of valuable software not only migrate to it but also make it mandatory. It's all of lennartware, not just systemD. I have been lucky to not need anything that uses to be infested with Avahi (they say it's "needed" for printers), but PulseAudio puts its tentacles everywhere. You do know the story with Firefox; this time this happened to my favourite audio player Clementine. The version in stretch/ascii is broken, I've had the package on hold, and only now got around to investigate the issue. In the WONTFIXed report, there's this gem: hatstand commented Apr 19, 2016 I'd be happy if we just removed all of it tbh and just used pulseaudio with no options. Seriously, an audio player which doesn't care at all whether sound actually works?! Especially that there's NOT A SINGLE REASON to ever use PulseAudio instead of ALSA: it used to be that "cheap" sound cards could be opened only once; this applies to basically all modern cards: they consist of just a DAC these days -- but ALSA has a software mixer for more than a decade now. Some desktop environments have a newbie-friendly setup widget that's PulseAudio only but that's self-inflicted damage. As PA uses and requires ALSA as the backend, it is not possible to have working PA but not ALSA -- while the converse is damn widespread. Let's look at all machines with a monitor attached that I have: * amd64 desktop. PA kind of works, except that when there's no sound, it produces a noise, quiet but noticeable enough to be infuriating. It tends to not be a concern during the day as there's enough noise from the outside, but if I dare to have the speakers on during the night... Problem 2: after suspend, all sound is high-pitched and clippy until "killall pulseaudio". Problem 3: current version of PA wastes 12% of a core even when idle. Not a show stopper, but on a laptop it'd be quite nasty for the battery. Obviously, everything works perfectly with bare ALSA. * armhf laptop. Starting PA causes a kernel OOPS that also kills most GUI. This is a kernel bug but one I can't fix -- it's stuck on a 3.0 sourceless vendor kernel. Nasty but that's widespread in the ARM world. Obviously, ALSA works just fine. * arm64 laptop. No sound with PA, I did not waste time to investigate. * amd64 desktop. Just compare it yourself: https://angband.pl/tmp/clem/ -- the samples have been recorded over a jack-to-jack analog cable (happens not just with clementine, also with mplayer, mpg123 and probably everything else). You can call both ARM boxes "unusual", but what about two ordinary x86 ones? With a 4-of-4 statistic, I guess such problems can't be rare for others. Thus, inflicting PulseAudio even on non-technical users is sabotage. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates. ___ 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, 2017-07-11 at 15:35 +, Miroslav Rovis wrote: > > > > > > > > > $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \ > > > > > > This one is not OK, see below. This is the Debian (unpatched > > > version) > > > No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and > > > you get > > > them by adding to sources.list: (+ apt-get update) > > > sysvinit-core > > > sysvinit-utils > > > initscripts > > > bootlogd (optional) > are needed to install OpenRC, get them at: > https://lists.dyne.org/lurker/message/20170711.035614.33ea6395.en.htm > l Please provide version 2.88dsf-59.9+devuan2 of sysvinit-utils on your web page. Version 2.88dsf-59.9 is not Devuanized!! And update https://dev1galaxy.org/viewtopic.php?id=1128 correspondingly. All the above packages are available at ascii-proposed: deb http://packages.devuan.org/devuan ascii-proposed main Depending on your pinning apt-get install ... or apt-get install -t ascii-proposed ... sysvinit-core sysvinit-utils initscripts bootlogd (optional) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] 404.
Hello again, On Tue, 11 Jul 2017, KatolaZ wrote: Is the step "go to https://git.devuan.org/devuan/devuan-maintainers"; mentioned in the d1h guide? :) Ah, I see. Thanks. Well, it sort of is mentioned, yes. :) It says: " * a working account on git.devuan.org" and I was trying to find out if it was working. At least that's my story, and I'm sticking to it. :) I'll press on - doubtless back with more dumb questions presently. -- 73, Ged. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] 404.
Hello yet again, On Tue, 11 Jul 2017, G.W. Haywood wrote: ... back with more dumb questions presently. laptop3:/opt/ged/git/devuan/pkg_openvpn/openvpn$ >>> d1h link g...@git.devuan.org:Ged/openvpn On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean The authenticity of host 'git.devuan.org (188.165.53.255)' can't be established. ECDSA key fingerprint is a8:8d:25:ac:eb:84:80:a4:52:05:84:27:23:de:8c:ce. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'git.devuan.org,188.165.53.255' (ECDSA) to the list of known hosts. Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ? -- 73, Ged. ___ 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 Mon, Jul 10, 2017 at 10:40:43PM -0700, Rick Moen wrote: > I do have an ongoing interest in, and gratitude for, the progress > towards robust OpenRC support in Devuan. As it happens, today I > was spending a while polishing up my 2016 page about converting Debian 8 > 'Jessie' to use either OpenRC or any of the four other packaged init > systems other than systemd > (http://linuxmafia.com/faq/Debian/openrc-conversion.html) -- fixing a > few nits and noting options for getting a _better_ OpenRC than the > half-assed Debian package. The package in jessie is meh, but do you have any particular criticism about the ones in stretch and unstable? They're not ideal, but anything that I noticed is quite cosmetic. I'd be very interested in making it full-assed. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates. ___ 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 11/07/2017 à 14:30, Enrico Weigelt, metux IT consult a écrit : On 05.07.2017 23:30, Didier Kryn wrote: > And there are a whole menagerie of addressing and transfer protocols, > including chained dma transfers Especially things like DMA are naturally kernel domain. I wouldn't ever allow any direct access to dma controllers from userland. The system isn't a server open to the public. It's a kind of industrial process (though it's for fundamental research). Only a limited number of users have an account on the hosts and only members of the vme group are given permission to access the devices associated to VME. In production, only one user runs a few applications (essentially one), some automatically on reboots and some under remote control. A whole library written in Ada comes between the applications and the driver; it adds a sufficient level of abstraction and a few facilities and takes care of safety controls. The applications are all written in Ada, of course. We don't fear malevolent actions, and, IMHO, safety is better granted by an Ada library than by any driver written in C. > In our case it is waveform digitizers and the interaction is so > complex that it cannot be done in a kernel module What exactly is so complex about that ? Smells like a typical task for IIO to me. The waveform digitizers boards have 8 channels of 8-bit 500MSPS flash-ADCs, each with 1024 buffers of 4096 bytes (samples). The (external) trigger comes after the data has been recorded; the many buffers grant asynchronism between data taking and read-out. The VME master can skip buffers (events) or read them, totally or partially. The VME master (the single-board computer) monitors the status of buffers and must free them before the digitizers can overwrite them. Before data transfer, the range of samples from the selected channels are arranged into a special buffer of the WFD boards, following detailed instructions from the VME master, before they are transferred using the 2eSST320 protocol (currently the fastest VME64x protocol). The amount of data transferred for each buffer depends on external conditions comming from a 16-bit binary input present on each board and part of meta-data associated to each trigger; the VME master decides what to do based on metadata assembled from 4 WFD boards. These metadata are generated by a set of very fast measurements associated to the triggering system (another subsystem of our set-up). Some others consider there should be one driver per VME device you > want to talk to, on top of the raw VME driver. Exactly. These people only ever had to deal with simplistic devices. Gabriel Paubert has never seen an application transfering more than a few bytes, while we are transferring data at 320MB/s. Those kind of things usually involve proper timing, caring about caching, etc, etc. Natural kernel domain. It's a little more complicated, as explained above :-) Which absurdities, exactly ? Bus errors were not reported to the application but instead caused a message to syslog! This makes it hard to use; or your application should monitor the log files! Yes, that's hackish, of course. This isn't the case here. AFAIU, their BSP contains a VME driver and a device tree. I think it's all GPL. Their buzyness is to send hardware and they make sure their clients can use it. Looks like your vendor is an exception. These are SBCs with everything soldered: VME, flash memory, UARTs, USB hub, Sata controllers, Ethernet ports etc... And you just plug it into a VME crate. It makes no sense to develop a board like this to use a dozen of them. We made the digitizers and it was already a big deal for our small team. Could you develop what is IIO for DAQ devices? What's the difference between you digitizes and usual DAQ devices ? What do you actually do with them ? Some clear requirements on the table, please ;-) We have two detectors running. On each of them, a sophisticated trigger logic decides when interesting data has been seen and triggers 400 channels of waveform digitizers (like 400 synchronous oscilloscope channels). 64 bit of trigger-related meta-data are transmitted to the read-out subsystem by the trigger system via the waveform digitizers digital input. There are a few hundreds triggers per second. The data are collected from 5 VME masters (in 5 VME64x crates) through 1gb/s ethernet by a Dell Poweredge server, re-arranged, compressed and written to disk before further transmission to a big computer center. Compression must be done before writing to avoid saturate the disk bandwidth. Is it something allowing to write drivers in user space? What kind of drivers do you wanna have in userland ? And why ? I think what I would do now would be to mmap() the VME bridge from userspace right away (I've read it's possible with /dev/mem). This way it would work with any kernel release
Re: [DNG] I have a question about libsystemd0 in devuan ascii,
On 170711-18:12+0200, Svante Signell wrote: > On Tue, 2017-07-11 at 15:35 +, Miroslav Rovis wrote: > > > > > > > > > > > > $ ls -ltr sysvinit-utils_2.88dsf-59.9_amd64.deb \ > > > > > > > > This one is not OK, see below. This is the Debian (unpatched > > > > version) > > > > > No, the sysvinit packages you need are 2.88dsf-59.9+devuan2 and > > > > you get > > > > them by adding to sources.list: (+ apt-get update) > > > > sysvinit-core > > > > sysvinit-utils > > > > initscripts > > > > bootlogd (optional) > > > are needed to install OpenRC, get them at: > > https://lists.dyne.org/lurker/message/20170711.035614.33ea6395.en.htm > > l > > Please provide version 2.88dsf-59.9+devuan2 of sysvinit-utils on your > web page. Version 2.88dsf-59.9 is not Devuanized!! And update > https://dev1galaxy.org/viewtopic.php?id=1128 correspondingly. I understand. And will follow your kind and urgent orders, Sir! :) ( except that I'm slow, been so slow all this time... But also, have a look at how thoroughly I work! Just look! In this file: /var/lib/apt/lists/packages.devuan.org_devuan_dists_ascii-proposed_main_binary-amd64_Packages I just found your name. What're you doing in there ;) ... Sorry, no more jokes. ( I wish I were a developer... Maybe some day... ) But details are nice to paste now, from that file, again: $ cat /var/lib/apt/lists/packages.devuan.org_devuan_dists_ascii-proposed_main_binary-amd64_Packages ... Package: sysvinit-utils Source: sysvinit Version: 2.88dsf-59.9+devuan2 Essential: yes Installed-Size: 137 Maintainer: Daniel Reurich , Svante Signell Architecture: amd64 Replaces: initscripts (<< 2.88dsf-59.5) Depends: libc6 (>= 2.14), init-system-helpers (>= 1.25~), util-linux (>> 2.28-2~) Breaks: systemd (<< 215) Description: System-V-like utilities This package contains the important System-V-like utilities. . Specifically, this package includes: killall5, pidof Multi-Arch: foreign Homepage: http://savannah.nongnu.org/projects/sysvinit Section: admin Priority: required Filename: pool/main/s/sysvinit/sysvinit-utils_2.88dsf-59.9+devuan2_amd64.deb Size: 67750 MD5sum: ec5f996f4407c0c170c365a116a8c17a SHA1: a6aa73e620fec56119e0e75168a03b8f429d2513 SHA256: acaf8504b3f54d20611d98107670c26aaa5bb2a9c36f85d528bff54c5fe1f36d ... $ The above paste is featuring: Filename: pool/main/s/sysvinit/sysvinit-utils_2.88dsf-59.9+devuan2_amd64.deb (the maybe not necessary to post elsewhere because it is in ascii-proposed repo, see below, file) Right, but it then, it then is really not even needed to be replaced on my website. But only removed, if I understand correctly. and explained on Dev1Galaxy OpenRC topic of mine, explained there why it is removed... (which explanation will consist of just the link to this email, when it is on the web),. I really set up that temporary dir on my website only because I wanted people to have those packages that one can only get if they would only be able to get it from you, or Daniel Reurich or from me (now) by email. This would be much cleaner, and it is no fuss like sending email attachments, I thought... Do I understand correctly that only these two packages it would be useful that they remain posted there on my website temporarily: -rw-r--r-- 1 210960 2017-07-11 03:30 libfdisk1_2.29.2-1+devuan1_amd64.deb -rw-r--r-- 1 979112 2017-07-11 03:30 util-linux_2.29.2-1+devuan1_amd64.deb But then, can you, or Daniel Reurich (CC'ing him too), send me then also i386 packages, so I can provide those in this interim before none of it is needed any more. Pls., guys, do correct me if I'm wrong in any of my understanding above. > All the above packages are available at ascii-proposed: > deb http://packages.devuan.org/devuan ascii-proposed main > > Depending on your pinning > apt-get install ... or > apt-get install -t ascii-proposed ... > sysvinit-core > sysvinit-utils > initscripts > bootlogd (optional) I see. 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] PulseAudio (was: Re: Linus can no longer trust "init")
On Tue, 2017-07-11 at 18:03 +0200, Adam Borowski wrote: > > * amd64 desktop. Just compare it yourself: https://angband.pl/tmp/cl > em/ > -- the samples have been recorded over a jack-to-jack analog cable > (happens not just with clementine, also with mplayer, mpg123 and > probably > everything else). Just listened to your samples. If the recordings are alsa and PA, no doubt which one I'd choose. What is the problem with alsa? And why to people need to add PA on top of alsa. (personally i never got PA to work, just googled and tried until alsa worked). ___ 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,
Quoting Adam Borowski (kilob...@angband.pl): > On Mon, Jul 10, 2017 at 10:40:43PM -0700, Rick Moen wrote: > > I do have an ongoing interest in, and gratitude for, the progress > > towards robust OpenRC support in Devuan. As it happens, today I > > was spending a while polishing up my 2016 page about converting Debian 8 > > 'Jessie' to use either OpenRC or any of the four other packaged init > > systems other than systemd > > (http://linuxmafia.com/faq/Debian/openrc-conversion.html) -- fixing a > > few nits and noting options for getting a _better_ OpenRC than the > > half-assed Debian package. > > The package in jessie is meh, but do you have any particular criticism about > the ones in stretch and unstable? They're not ideal, but anything that I > noticed is quite cosmetic. Honestly, I've not yet had a chance to try those out, having been stretched too thin, lately, by $DAYJOB and other matters. So, I've been lately relying on details provided by others. When I have a chance, I will indeed see about a fresh experiment using Stretch and its official packages (before, no doubt, fooling around with it and transforming it past recognition ;-> ). Anyway, if you see any blunders I made in that page, I'd be grateful to hear about it, as always. FWIW, I also long past stopped wanting to stick with Official Debian, anyway. The systemd / freedestkop.org nuisance is just one more reason to seek better ways to install / maintain a debianesque system. Back a in the early 2000s, I got so tired of hearing people complain about the Official Debian d-i images (with the implication that it was the only way to install a Debian-type system) that I compiled a list of alternative installer images / methods, by way of response: http://linuxmafia.com/faq/Debian/installers.html (It's now a decade out of date.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On 07/11/2017 05:28 PM, Enrico Weigelt, metux IT consult wrote: make it crystal clear: fuck off the upstream. Do you want to say that devuan users do not need any upstream that recommends systemd? For example, Postgresql? *** With PostgreSQL 9.6 or newer, it is recommended to build with --with-systemd and use the unit file shown in the documentation... *** https://wiki.postgresql.org/wiki/Systemd ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
> I no longer feel like I can > trust "init" > https://lkml.org/lkml/2017/7/6/577 This is getting scary - last time I remember something along these lines, something called git seemed to be the end result. And I think git has taken over the world from emacs! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
Am 2017-07-11 20:35, schrieb Dragan FOSS: Do you want to say that devuan users do not need any upstream that recommends systemd? For example, Postgresql? *** With PostgreSQL 9.6 or newer, it is recommended to build with --with-systemd and use the unit file shown in the documentation... *** https://wiki.postgresql.org/wiki/Systemd And what recommends Postgresql for BSD systems? "Don't install it"? Free unix software should run on ANY unix system, not only Poetteringware. Jochen ___ 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 11/07/2017 à 14:30, Enrico Weigelt, metux IT consult a écrit : > We have two detectors running. On each of them, a sophisticated > trigger logic decides when interesting data has been seen and triggers > 400 channels of waveform digitizers (like 400 synchronous oscilloscope > channels). 64 bit of trigger-related meta-data are transmitted to the > read-out subsystem by the trigger system via the waveform digitizers > digital input. There are a few hundreds triggers per second. The data > are collected from 5 VME masters (in 5 VME64x crates) through 1gb/s > ethernet by a Dell Poweredge server, re-arranged, compressed and written > to disk before further transmission to a big computer center. > Compression must be done before writing to avoid saturate the disk > bandwidth. That sounds suspiciously like you're working on the LHC! Or perhaps the VLA... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] What is GNU/Linux?
My understanding is, that Linux is the kernel, and GNU is the userland. Is systemd part of GNU/Linux? If not, how do we call a systemd Linux? Jochen ___ 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, 2017-07-11 at 17:26 +, Miroslav Rovis wrote: > > > Please provide version 2.88dsf-59.9+devuan2 of sysvinit-utils on > > your > > web page. Version 2.88dsf-59.9 is not Devuanized!! And update > > https://dev1galaxy.org/viewtopic.php?id=1128 correspondingly. > Do I understand correctly that only these two packages it would be > useful that they remain posted there on my website temporarily: > > -rw-r--r-- 1 210960 2017-07-11 03:30 libfdisk1_2.29.2- > 1+devuan1_amd64.deb > -rw-r--r-- 1 979112 2017-07-11 03:30 util-linux_2.29.2- > 1+devuan1_amd64.deb Yes, they are useful until the build problems are solved. > But then, can you, or Daniel Reurich (CC'ing him too), send me then > also i386 packages, so I can provide those in this interim before > none of it is needed any more. Attached in a separate mail to you only. Especially since the mailing list attachment size is limited (as it should be) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On Tue, Jul 11, 2017 at 05:28:39PM +0200, Enrico Weigelt, metux IT consult wrote: > To be more practical: I'd suggest spinning off a (distro agnostic) > non-systemd maintenance project. We'll collect repos w/ depotterization > patches for all packages (and upstream releases) we're interested in. > And any distro can easily join in. > > Just created a github org for that: > https://github.com/depotter > > Started w/ a pretty trivial case: samba > https://github.com/depotter/samba Uhm, but what's the point in _this_? Samba does the right thing: builds systemdD support if and only if its configure script detected the headers (which can usually also be forced by --enable-foo or --disable-foo). It's Debian/Devuan packaging that needs fixing, the upstream project is fine. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On Tue, 11 Jul 2017 23:23:59 +0200 Adam Borowski wrote: > On Tue, Jul 11, 2017 at 05:28:39PM +0200, Enrico Weigelt, metux IT > consult wrote: > > To be more practical: I'd suggest spinning off a (distro agnostic) > > non-systemd maintenance project. We'll collect repos w/ > > depotterization patches for all packages (and upstream releases) > > we're interested in. And any distro can easily join in. > > > > Just created a github org for that: > > https://github.com/depotter > > > > Started w/ a pretty trivial case: samba > > https://github.com/depotter/samba > > Uhm, but what's the point in _this_? Samba does the right thing: > builds systemdD support if and only if its configure script detected > the headers (which can usually also be forced by --enable-foo or > --disable-foo). Yes, there is 'with-systemd' and 'without-systemd', not that either are really needed, the systemd parts will only be built if the systemd development libs are installed. I cannot see anybody trying to make it mandatory to build Samba with systemd, but if anybody tries, I will just 'NACK' the patches ;-) Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is GNU/Linux?
On Tue, 2017-07-11 at 21:36 +0200, Joachim Fahrner wrote: > My understanding is, that Linux is the kernel, and GNU is the > userland. > Is systemd part of GNU/Linux? If not, how do we call a systemd Linux? lendows (tm) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On 07/11/2017 09:11 PM, Joachim Fahrner wrote: And what recommends Postgresql for BSD systems? "Don't install it"? Free unix software should run on ANY unix system, not only Poetteringware. I never tried on BSD, but on UNIX Pg runs fine :) https://www.postgresql.org/download/solaris/ Btw...Linux Is Not UniX ;) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is GNU/Linux?
On 07/11/2017 11:38 PM, Svante Signell wrote: lendows (tm) Not alone.. :) http://news.softpedia.com/news/canonical-windows-10-loves-ubuntu-516922.shtml ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is GNU/Linux?
On Wed, Jul 12, 2017 at 12:03:30AM +0200, Dragan FOSS wrote: > On 07/11/2017 11:38 PM, Svante Signell wrote: > > > lendows (tm) > > Not alone.. :) > http://news.softpedia.com/news/canonical-windows-10-loves-ubuntu-516922.shtml Phoning home with all your searches via Unity Lenses, remote ads in etc/motd Ubuntu is quite a good fit for Windows 10, yeah. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is GNU/Linux?
On 07/11/2017 03:36 PM, Joachim Fahrner wrote: > My understanding is, that Linux is the kernel, and GNU is the > userland. Is systemd part of GNU/Linux? If not, how do we call a > systemd Linux? > Nah, Gnu/systemd makes more sense if your going down that road... but I would much prefer keeping systemd out of my devuan install. though... I do have to say, systemd pulls off quite a remarkable feat. systemd is considered libre... yet... it is extremely poorly made for something that is libre... Microsoft must be pleased as is apple and google. Yes I made a thread about this in devuan galaxy forums, but I decided I should share this observation with the entire devuan mailing list. ;) > Jochen > ___ > 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] What is GNU/Linux?
On 07/12/2017 12:12 AM, Adam Borowski wrote: remote ads in etc/motd rm /etc/update-motd.d/* :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is GNU/Linux?
Quoting Joachim Fahrner (j...@fahrner.name): > My understanding is, that Linux is the kernel, and GNU is the > userland. Is systemd part of GNU/Linux? If not, how do we call a > systemd Linux? 'systemd'. ;-> ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On Tue, Jul 11, 2017 at 11:23:59PM +0200, Adam Borowski wrote: > On Tue, Jul 11, 2017 at 05:28:39PM +0200, Enrico Weigelt, metux IT consult > wrote: > > To be more practical: I'd suggest spinning off a (distro agnostic) > > non-systemd maintenance project. We'll collect repos w/ depotterization > > patches for all packages (and upstream releases) we're interested in. > > And any distro can easily join in. > > > > Just created a github org for that: > > https://github.com/depotter > > > > Started w/ a pretty trivial case: samba > > https://github.com/depotter/samba > > Uhm, but what's the point in _this_? Samba does the right thing: builds > systemdD support if and only if its configure script detected the headers > (which can usually also be forced by --enable-foo or --disable-foo). > > It's Debian/Devuan packaging that needs fixing, the upstream project is > fine. > and the de-systemd-ised packages for samba are already in Devuan, BTW. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - GLUGCT -- 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] Linus can no longer trust "init"
On Tue, 11 Jul 2017 20:35:45 +0200 Dragan FOSS wrote: > On 07/11/2017 05:28 PM, Enrico Weigelt, metux IT consult wrote: > > make it crystal clear: fuck off the > > upstream. > > Do you want to say that devuan users do not need any upstream that > recommends systemd? > For example, Postgresql? > *** > With PostgreSQL 9.6 or newer, it is recommended to build with > --with-systemd and use the unit file shown in the documentation... > *** > https://wiki.postgresql.org/wiki/Systemd I'm on the Postgres list, and after confirming the contents of your abovereferred URL, I wrote them asking to not put in init-specific code, and to take out what's already there. Thanks for the info. SteveT Steve Litt July 2017 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is GNU/Linux?
On Tue, 11 Jul 2017 21:36:29 +0200 Joachim Fahrner wrote: > My understanding is, that Linux is the kernel, and GNU is the > userland. Is systemd part of GNU/Linux? If not, how do we call a > systemd Linux? Merde SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
On 12/07/17 02:35, Dragan FOSS wrote: On 07/11/2017 05:28 PM, Enrico Weigelt, metux IT consult wrote: make it crystal clear: fuck off the upstream. Do you want to say that devuan users do not need any upstream that recommends systemd? For example, Postgresql? *** With PostgreSQL 9.6 or newer, it is recommended to build with --with-systemd and use the unit file shown in the documentation... *** https://wiki.postgresql.org/wiki/Systemd I read that page but my interpretation is different to yours. I read it as "If you want to run PG 9.6 or newer with systemd, use this option and the unit file we include. If you want to run an older version the recommended approach is to write a unit file using Type=forking and use pg_ctl for ExecStart and ExecStop." There is absolutely nothing there that is mandating systemd in any way, shape or form. They've just included code to make it behave better with systemd if that is how you choose to build it. Did I miss something or are you fearmongering? Brad ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linus can no longer trust "init"
Am 2017-07-12 00:00, schrieb Dragan FOSS: Btw...Linux Is Not UniX ;) Then replace "unix" in my post with "un*x" ;-) https://en.wikipedia.org/wiki/Unix-like Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
