Becoming a Devuan Maintainer (cut)

ghaverla · 2017-12-17 02:05:58

I had a better Subject, but taking to long lost it.

I got involved with Linux at 1.2.13. At that time, I was already fed up with the M$ way of life. And many years later, to run into Lennart and systemd didn't impress me.

I am a number cruncher at heart. Inverting matrices, differential equations, curve fitting, splines and similar are what really interests me. But one often gets drug down into system and network things. So, I've patched kernel sources to support and Arc-net (I think) NIC, set up a HUGE swap file, because some GIS file had 2 or 3 points thousands of kilometers outside of the bounds, and so on.

If a problem I am interested in, needa solving (for different data) many times, I will still go to FORTRAN. Because that is what this language does. If I only need to solve it once or twice, I went to Perl (and not Perl data language). I don't think S or R were even a twinkle in those developer's eyes then (when I first went this way).

Having done so many things with Perl/CPAN, I started to learn a "preferred" way to develop Perl modules. Which probably means the developers didn't do this, but they thought it would work best for people just learning to make modules. I don't remember running across any Perl god (Larry Wall, ...) ever commenting on this.

But the idea was to develop from the beginning, by developing tests.

The only fault I've ever seen about this kind of process, is that it (with the modules Perl has) doesn't work with floating point. It pretty much assumes that no matter what you do, the pattern of bits of the result is an EXACT recreation of the operations performed on the arguments. And this is never true in floating point. One chip has one error, another chip has another error, are you using all 80 bits in registers or shifting 64 bits out to allow something else to use the register, and so on.

----

I compiled the fork of lm-sensors, and it compiles. But how do you test it? The system already has a libsensors4 library. And the executables that need libsensors4 have an assumption as to what the library will do.

While a person can play games with environment variables (I am thinking there are 2 environment variables which could be involved, one has RPATH in the name), libsensors is something which talks to the hardware. And do I want to screw up testing, and send some strange command which wipes all the data on my computer?

So what makes sense is to build a package based on this fork. Remove the existing lm-sensors packages, install the new packages based on this fork, and see what happens. Sure, I could toast my system, lm-sensors by design is meant to talk to hardware.

----

Debian (and Devuan) provide lm-sensors related packages (I think there are 4?). So, to do this, I need to learn how to build more than 1 package, from a fork of an existing package.

I'm sorry, I've looked and I am not seeing examples of how to do this. And in trying things, I am generating errors which prevent generating packages to install, just to try things. Maybe I am taking the wrong approach, in that I might at some point provide packages to Devuan.

----

In Perl, there are apparently packages which will test all the code snippets in the man page. And they will check for spelling mistakes and lots of other things.

I may learn more python, maybe it does more. Somehow I doubt it. I think that Perl was designed by a linguist is going to be a plus for a long time.

----

For years, I have had people I know (at one point I was the president of a LUG), complain to me about documentation. And yes, the man pages are not intended to help someone learning about a package. They are intended to refresh the memory of someone who is already familiar with the package.

And this is what I am running into.

You can find people writing about X, Y or Z packages. And they give documentation on what to do. And if you follow the documentation exactly (which is what newbies do), it doesn't work. Oh, it is obviously this, or obviously that; when people complain. It isn't obvious to a newbie.

And I don't think this will ever change. Developers don't want to write documentation.

But could it change, if the development process followed the Perl module (suggested in the literature, often ignored by the better developers) approach?

Can a person do:
make
make test

and see that things work?

I have not spent enough time to find all approaches to packaging some arbitrary source tree for Debian/Devuan. I know I am growing annoyed at error messages which I think means that better programming would mean the error message never comes up.

But I will try. The computer I am using has had nothing installed yet, other than what is needed to try and get it working. And I have 4GB of space to play with.

ghaverla · 2017-12-17 02:07:10

Sorry, that is 4TB to play with.

ghaverla · 2017-12-18 01:26:03

I played with qbp a bit, and also with quilt.

Nothing I had seen, impressed me with the idea that I needed to have the patch in question, installed on top of the stack for quilt. Fine, remove a bunch of directories of stuff.

I decided to try the d1h approach for the next try. No guarantee it works. The package I am playing with is not an established Debian package (it is a fork), and there are some big changes between the two.

The error messages one can get from some of these tools is simplistic. Quilt is not looking for debian/series (I think that is the file), it is looking for something else. Presumably something which will eventually write debian/series.

This fork has some big changes on what is in lm-sensors, and so the line number differences are not one or two, they are thousands or more.

But, I am learning things, which is all good. I've got a day where I won't have much time to work on this coming up.

I am seeing what lots of newbies report to me about when they do things. Instructions are not exact (but for me, I am not claiming there are instructions on how to import a fork of a supported package), but they are close.

Which goes back to how Perl can do testing (it assumes a scripting language, which isn't always possible when one has tom compile things in C or C++).

I've no idea how Perl is perceived here (Devuan). There seems to be more preference for solutions outside of Perl even within Debian.

My argument for Perl, goes back to it being designed by a linguist, not a computer scientist.

Have a great day!

golinux · 2017-12-18 03:20:28

I had a better Subject, but taking to long lost it.

If you click the option to stay logged in, you won't get bit by the timeout issue.

fsmithred · 2017-12-19 15:52:06

I haven't heard much discussion of perl among the devuan devs. Maybe it just hasn't come up, or maybe we don't have any avid perl programmers. I think a lot of the package management stuff in debian (and consequently in devuan) is written in perl.

You can do a ./configure and make on a source package. Then run it from there. Don't do a 'make install' or you may screw up the system and confuse apt. Figure out what you need to do to get it to work. If you have to install other libraries, you should install them from the repo. After that, you can figure out how to get it into a debian package. The basic steps for that are pretty simple. The devil is in the details. And looking at the current debian source to see how it was done should be helpful.

stanz · 2018-02-04 01:35:30

golinux wrote:

I had a better Subject, but taking to long lost it.
If you click the option to stay logged in, you won't get bit by the timeout issue.

Pray`Tell...where is that option to click?

golinux · 2018-02-04 01:53:59

stanz wrote:

golinux wrote:
I had a better Subject, but taking to long lost it.
If you click the option to stay logged in, you won't get bit by the timeout issue.
Pray`Tell...where is that option to click?

On the login screen just under where you enter your password. It says:

Log me in automatically each time I visit.

That keeps you logged in if you visit here regularly. I suppose there would eventually be a timeout but certainly not during a session.

stanz · 2018-02-04 02:02:57

Username (Required) Password (Required)
* Log me in automatically each time I visit.

Thats what I get. Is that not just a 'lifetime cookie' thing?
Never thought of it as keeping one logged in... ?
Will try it ~ Thx

Last edited by stanz (2018-02-04 02:17:29)

golinux · 2018-02-04 02:31:05

stanz wrote:

Username (Required) Password (Required)
* Log me in automatically each time I visit.
Thats what I get. Is that not just a 'lifetime cookie' thing?

Yes, it is a cookie. If you come regularly, I think it keeps renewing because I never get logged out of any of the forums I frequent daily.

Never thought of it as keeping one logged in... ?
Will try it ~ Thx

I hope that it works for you. Please let us know.

The officially official Devuan Forum!

#1 2017-12-17 02:05:58

Becoming a Devuan Maintainer (cut)

#2 2017-12-17 02:07:10

Re: Becoming a Devuan Maintainer (cut)

#3 2017-12-18 01:26:03

Re: Becoming a Devuan Maintainer (cut)

#4 2017-12-18 03:20:28

Re: Becoming a Devuan Maintainer (cut)

#5 2017-12-19 15:52:06

Re: Becoming a Devuan Maintainer (cut)

#6 2018-02-04 01:35:30

Re: Becoming a Devuan Maintainer (cut)

#7 2018-02-04 01:53:59

Re: Becoming a Devuan Maintainer (cut)

#8 2018-02-04 02:02:57

Re: Becoming a Devuan Maintainer (cut)

#9 2018-02-04 02:31:05

Re: Becoming a Devuan Maintainer (cut)

Board footer