Devuan 2.0 Reaches Beta, Debian Without Systemd & Now Based On Stretch

[oiaohm]

This has nothing to do with debian maintainers (who were still there), but Consolekit's one.

There are 8 different packages used in a complete sysvinit solution that are missing maintainers in debian. The seats are open and no body is filling them. They were empty before debian changed to systemd. These 8 different packages chain on and effect deploying openrc.

Please note consolekit not current harms openrc and sysvinit and about 12 other init systems. It is a keystone.

1And that OpenRC is by far better than systemd or even sysVinit. But the thing is, people are still forcing systemd than OpenRC.

Go to debian

https://packages.debian.org/sid/openrc

Note the above version number

https://github.com/OpenRC/openrc

Note here that current releases .34 and debian only has 0.27-3. Also for full functionally depends on sysvinit project core utiles that are not maintained. I could just keep on listing and the maintainer-ship problem gets quite big.

So lets be real here debian cannot choose OpenRC because they don't have maintainers keeping the required sysvinit parts up to current or even maintainers keeping Openrc up to current.

Now lets look at systemd on debian.

https://packages.debian.org/sid/systemd

https://github.com/systemd/systemd/releases

Yes the development branch of debian has the absolute latest release of systemd. Yes not being on the current version if you check out devuan development branch has the same problem.

Complain all you like but the facts of the matter are simple. Debian has gone systemd because they have maintainers who in fact maintain systemd at current version. The other init options are not being maintained for debian so debian cannot choose them as default any more.

Debian story about lack of maintainers for other init systems is repeated in many distributions. Same thing use to happen when sysvinit was dominate.

I guess no one who is complain has ever bothered to check if the solution they want have the required maintainers.

[arokh]

Don't like my posts ? Don't come here then.

Why are you on a forum if you don't want to discuss things?

Either grow up, or either go Apple with that childish mindset.

Says the guy who is unable to answer a simple question, "who's stopping you from using something other than systemd". Go to a cabaret or something with your dramaqueen attitude.

[gerddie]

https://github.com/systemd/systemd/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen++timesyncd+

Does not appear here.

I wrote it in my first post in this thread https://github.com/systemd/systemd/issues/1143

Now this is a could case that you should have opened another bug. I had to do that twice on one bug in systemd to get it on the list to be fixed.

Technically the bug is not closed, it is only blocked for commenting.

So if it was a fault found in debian systemd a bug should be open on debian for it.

One problem here is that the system where I encountered the bug is not a plain Debian, specifically, the kernel is self-compiled and parts of the software are packages are specifically tailored by the device manufacturer, a situation it is a bit like the "tainted" flag in the linux kernel. Should I bother the Debian maintainers unless I can confirm that the bug is really in the original Debian packages? And since I didn't use the kernel provided by the Device manufacturer, should I report a bug there? The only thing that is sure is that the systemd developers admit that the problem as such exists.

As for my Debian maintainership: The packages I manage relate to specialized software, quite far from the system related stuff, I bug upstream when needed, and it usually they are responsive and nice.

[oiaohm]

I wrote it in my first post in this thread https://github.com/systemd/systemd/issues/1143

A rogue clock has a lot of lethal effects. Yes sysvinit would boot but at times you syslog logging solution would be DOA and anything time sensitive could also be destroying data. Reboot is not really a solution here. This is a class of error where halt is correct answer better to stop and you data be one piece and recoverable then go forward and destroy data.

https://www.kernel.org/doc/html/v4.1...arameters.html

Do note that they say kernel fix there are two fixs. For the 2038 problem the fix is update kernel and libc to support 64 bit time and its about the only valid fix for the 2038 problem.

For a malfunctioning RTC there is another option https://www.kernel.org/doc/html/v4.1...arameters.html clocksource=jiffies what forces Linux kernel to in kernel software clock and you will hope your solution can set time by network or some other means. I have had to use this one some old dell servers because their RTC has a really nasty fault. When you have a machines RTC spinning through a year in 2 seconds it does not take long to get to 2038 and loop the clock roughly every hour is fully been though every bit of the 32 bit number that the time is stored in of their RTC.

The bug you pointed to is not requesting that the system detects RTC problem and provides option to shutdown or to reboot into a mode using the software clock. Instead they are attempting to patch their way around a time issue. Time issues are data harmful the first thing that gets damaged is your logs. Next databases and Next is like network protocols that depend on sane time. A lot of things start malfunctioning when time is malfunctioning. Forcing timerfd to use relative time and leaving the RTC in place will just move the problem elsewhere in the system. Yes every method that makes systemd work with the defective RTC exposed to applications is just moving the problem elsewhere and not dealing with it.

Not being able to boot into system when RTC is malfunctioning is a good thing so forced to disable RTC before it causes other harm. Now user friendliness is missing to allow automatic switching to RTC off. Remember the old MS dos on Xt that did not have a RTC where it would prompt you for current date and time.

Technically the bug is not closed, it is only blocked for commenting.

There are other ways to join blocked from random comments on systemd. I have had done it before. Yes IRC/Mailing list request to be added to bug to report fault and due to the fact your are monitoring issue. But you do have to understand problem properly and the risks. Not just saying this has to be made work when its something that should fail. The only question with the clock bug you are point to is how nicely should it fail.

Some of the things sysvinit and busybox init let happen are not right. Yes invalid handling of RTC issues effect both. Systemd is not invalid is just horrible from a user friendliness point of view. So not every time systemd refuses is it wrong.

I can also tell you why systemd halting and looping with a RTC issue. You see a few RTC out there inside 1min of boot they are not happy little campers after that they come good. So spamming time message "Time has been changed" when the RTC cannot make up it mind for a while what time to report is kind of correct. Yes the world of broken hardware in use. So there is so much tolerance required for part broken hardware and there need to be a line in sand where system says this is never coming good I have attempt reboot using other options including disabling as much hardware as possible the solution can attempt to live without.

Please note sysvinit and busybox init go forwards with these RTC problems is not right either and have been historic causes of data loss.

One problem here is that the system where I encountered the bug is not a plain Debian, specifically, the kernel is self-compiled and parts of the software are packages are specifically tailored by the device manufacturer, a situation it is a bit like the "tainted" flag in the linux kernel. Should I bother the Debian maintainers unless I can confirm that the bug is really in the original Debian packages? And since I didn't use the kernel provided by the Device manufacturer, should I report a bug there? The only thing that is sure is that the systemd developers admit that the problem as such exists.

Yes it is report to the device manufacturer and open a bug their system because what bug is the only correct way to address the 2038 problem is get a new kernel that supports 2038+ properly. If you don't report to them and no-one reports it to them how will they know they have anything to fix.

There is always a maintainers bug list that upstream bugs need to be duplicated on-to so maintainers know about the problem. In this case the maintainer of the third party kernel needs the bug on their bug list to be check and fixed.

As for my Debian maintainership: The packages I manage relate to specialized software, quite far from the system related stuff, I bug upstream when needed, and it usually they are responsive and nice.

The thing you have missed is duplication is a required evil. I guess when you are put bugs upstream you have not been mirroring bugs in debian buglist. You think about it the old saying about if person was hit by bus(yes anything that puts person out of action used here classic is hit by bus question) how will another person take over what that person have been doing. If you are logging you bugs upstream and in debian bug system if you have to be replaced a new debian maintainer looking after the project you take care of could look at your debian bug list and go these are confirmed to effected the debian packages. The reality is you have most likely been keeping all the same information in private the policy of placing the bugs in debian bug system as well as upstream is a very good policy. You do find some of the newer less up on policy debian maintainers do need a kick up ass on this point to start getting it right.

Yes its another thing make sure you have dotted your i's and crossed you t's before you start complaining about stuff.

[oiaohm]

https://github.com/systemd/systemd/issues/1143

Technically the bug is not closed, it is only blocked for commenting.

By the way that bug is technically closed because the action is kind of rigbt. The red closed at the top of the bug report is closed. You will see open with comments blocked. But this case it was closed with not our bug what is correct on one hand. So you are complaining about a closed bug. Of course the fault is never going to get fixed while its a closed bug.

https://github.com/systemd/systemd/issues/8247

And here is me doing what you should have done gerddie instead of complain about a closed bug all over the place. You need to think about why the bug was closed and what was the adverse side effects and what should be the correct system response. You cannot use this worked in sysvinit it should work in systemd because there are lot things sysvinit booting system allows that are pure wrong and dangerous. I will be truthful there are a lot things systemd does that are not quite right either but are more correct than sysvinit. This is a case of not quite right.

[gerddie]

... instead of complain about a closed bug all over the place.

You have an interesting definition of complain [...] all over the place. My initial comment was about attitude and not the contents of the bug, and I didn't complain anywhere else.

Anyway, thanks for making the RFE,

[arokh]

Your second post went into detail on the contents of the "bug", which people already had told you wasn't a bug but which you didn't accept.

[oiaohm]

You have an interesting definition of complain [...] all over the place. My initial comment was about attitude and not the contents of the bug, and I didn't complain anywhere else.

Anyway, thanks for making the RFE,

This is going to be like the like the systemd failure to process user so running service as root. So its not going to be 1 bug post and its not going to be just 1 message.

This will take few. i know this getting stuff fixed in systemd is not easy even when you understand the problem. But this is still better than sysvinit were I have a bug from 2006 that is still sitting open and never been processed.