No problem.

Have a great day!

I suppose I have seen it, since I have a comment in that thread.  :-)  But, it looks like guayadeque (or however it is spelled) is being dropped by Debian, and I got busy and never finished things.

Having read a bunch of things in the Debian world about building packages, d1h makes a little more sense.  It still looks like there are a lot of fidlly little details to catch the newbie at.

But, what I am working with is not strictly speaking, lm-sensors.  It is a fork of lm-sensors (and it isn't my fork).  I have a source tree from the Devuan package of lm-sensors, and I have a source tree of the git fork.  So I could make a unified diff (or other variation on diff) between the two.

I am NOT an expert at git.

There seem to be many tools which will take an upstream tarball and start a git archive.  I guess you then want to start a branch (NAME-fork ?, where NAME, is the name of the person who forked lm-sensors).  You then apply the diff (using patch) to this new git controlled source tree, producing your modified source files.  The apt-get source command produces a Devuan source tree, which could be built.  It has a debian/ subdirectory with things like a rules file.

I don't believe it produces a dsc file (but if one visits the Debian package webpage, you can get the tarball, the diff and the dsc file).  I have a copy of the Debian (not Devuan) dsc file, and it is a signed ASCII file with key information in it.

I was just looking into whether there is a tool to produce this dsc file, as it appears to me that git-buildpackage needs the dsc file to do its magic (in a cow).  I can believe that if I was a Devuan developer/maintainer/person who makes the coffee, I probably already have an account at the Devuan git (I don't) and probably has set up keys with gpg (it was a couple of years ago I last made keys, and someone monitoring the MIT keyserver(?) noticed my key was about to expire a couple of weeks ago).

I am hoping that these tools will allow me to make an unsigned package for my own use.  I can then install it and see if it works.

If it works, then I think I could/should/might look into the get an account on the Devuan git.

Living in an agricultural area (I'm on 40 acres), cows are typically things like black or red angus.  I am personally looking at Dexter, should I get a few cows.  Cows don't build anything, they just leave these paddys all over the place.  I think the complexity in this could make someone chicken.  And once you start generating errors to really learn about packaging, you might duck when typing command lines, or go horse yelling at the computer for answers to why the errors?  Or is that rye the errors?  :-)

And yes, I will add experimental to my sources.list and install d1h.

Moooo!  (That's COW for have a great day!)

That's wonderful to hear (well, read)!

I've spent too much time in gyms, rehabbing soccer injuries.  I got to be pretty good at weightlifting.  I ran across a "girl" a few years younger than me (I was probably 45 at the time, she might have been 35).  She was a farm girl (not surprising up here).  We talked about things, and picking rocks came up.  I think this girl could probably deadlift about as much as I could.  And she wasn't even on the East German weightlifting team.

Physical strength tends to be a place where this dumb hierarchy plays out, but it isn't even guaranteed there.  My Mom used to help me carry 5/8 inch fire rated drywall into the basement when we finished her basement.  She was mid 70's at that point.  She is an avid golfer, and can put the ball on the green of a par 3, from the men's tees (she is now 85).

Best of luck in whatever you do!

I did use apt-get to get the lm-sensors source package, so it would have been a Devuan source package.

You didn't miss anything, I normally talk to people who are not pedantic enough, and stuff slipped.

What differences can be realised between a Debian package, and a Devuan package?

I can put this in context.  As I mentioned above, I am interested in helping with Perl.  One thing that has always bothered me about perl modules in Debian, is that the package pages seldom tell you what the CPAN name of the package is.  Another is that tests and examples (from CPAN) often go missing.  So if you are trying to figure out how to use a Perl package, none of this is there to help you.

I am not an expert at XS (or SWIG?).  I suppose I will have to develop that.  At heart, I am a FORTRAN person.  But, I have written something that was like RATFOR for FORTRAN-77, and I once ported most of Perl-4 to QNX-2.x (nothing related to networking).  Nothing ever published on the Internet, but the Perl port to QNX-2.x was used for production where I was working (at a research nuclear reactor).

I cloned the git tree, and then downloaded (apt-get source) the Debian source tree (or more properly, the devuan source tree).  There are probably differences in some include files, but I did a diif -u of the Debian lib/ subtree and the git lib/ subtree.  Ignoring things only found in the git subtree (because I had compiled the package, and hence had all those files present), the diff -u file is 158 lines long.

A lot of differences are of the form
-ifdef BLAH
+ifdef BLAH_H
which are philosophical/cosmetic in nature.

There is a different kind of sensor which this git fork has in it, which is not present in the Debian code.  I don't (yet) know if this new sensor on AM4 motherboards is of this type or not.

I'm guessing what I do, is that I make the changes to the Debian source tree, and build a package with is incrementally greater in version number than what I have installed.  I install the new package to test it, and afterwards I revert things to what was there before.

How can this work be made available to others?

libsensors4/lmsensors reads almost nothing.  Looking at development information on these packages, there have been no updates for months.

There is a fork by groeck at github, which among other things has tackled the new sensor (ITE8665E) which is in many AM4 motherboards.  Supposedly it is working for many people.

I can try this fork here.  What is the best way to handle this?  Download the source tree for libsensor4/lmsensors as well as this fork, and if it works make a diff of the 2 trees?  (Probably someone knows magic to get git to do that directly?)

I do see that I forgot to hook up one connector in this build.  The power supply is a Corsair RM750i, and so I need to connect the power supply to a USB2 header.  There is at least one open source package now that can read data from these Corsair digital power supplies.

I'm still looking into the nomodeset "problem".  I now have a 4.13 kernel also installed, which works well with RX460 and RX550 using amdgpu, so I'll try editing the grub boot line to remove it and see what happens.  Some people thought that Linux Mint might be a good test for screen resolution abilities, so I have that LiveCD here too.

I hope I didn't offend fsmithred.  I said I was teasing about emacs.  I also reported a couple of things I noticed about the refracta CD (well for me it was a DVD, but ...).

It looks like nomodeset is not exactly the answer I am looking for, but I have an idea where to look.  With nomodeset, it appears that amdgpu is not loaded as a module, and what I end up with are VESA graphics.  Which is probably okay.  The problem is that without amdgpu loaded, the GPU won't work.  So finding an alternative to nomodeset to allow booting is needed.

I installed a bunch of mesa stuff (and llvm-5) to use the GPU at some point.  I also loaded a bunch of BOINC packages.  But, I forgot to add vsyscall=emulate to the bootline before, so the first job downloaded from SETI@Home died.  Eventually they are supposed to move away from needing vsyscall, and then a person can drop this from the boot line (it is supposed to be a security problem).  The kernel does report the 1600X as having 12 cores (it is 6 cores, but they are dual threaded).  So allowing BOINC to use 90% of the CPUs, means 10 jobs are running at the same time.

Hmm, I should load some sensors packages, to see what the temperature is doing.

Anyway, I am making headway with getting this machine going.  Thanks to fsmithred.

I added nomodeset to /etc/default/grub  and update-grub

The name of the wired interface in /etc/wicd/manager-settings.conf was wrong.  DHCP now runs and gets an IP,and ping works.

Thanks for the help!

There is a virtualization option.  In the CPU configuration, it is called SVM mode.  It was disabled, so I enabled it.  Tried to reboot, picked the first option in the grub menu, and again the boot hangs about 8 seconds (or is it 8 milliseconds?) in.  Last line printed  has something like

sp5100_tco: I/O address 0x0cd6 already in use

It seems to have been a UEFI issue again.  Now that device is presented with 2 options in the BIOS boot menu, by itself, and as a parenthesissed string after "devuan".  The second one causes a UEFI boot.

I see a grub menu, and choose the default (top) option.  The boot starts, and then ends with a message about kvm being disabled by bios (at about 8 seconds?).  And it just sits there.

So, go dig into BIOS and see if there is some kind of KVM setting.