LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-20-2018, 02:54 PM   #46
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware 14.2 || Slackware-current && CentOS
Posts: 1,322

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697

There is a new release of inxi, no longer named pinxi. See here: https://github.com/smxi/inxi

I assume the errors you are getting are due to the fact that you need to download the new release...

Code:
git clone https://github.com/smxi/inxi.git
cd inxi
perl inxi

Last edited by mralk3; 03-20-2018 at 02:57 PM.
 
Old 03-20-2018, 03:03 PM   #47
rokytnji
LQ Veteran
 
Registered: Mar 2008
Location: Waaaaay out West Texas
Distribution: AntiX 17
Posts: 5,587
Blog Entries: 20

Rep: Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664
As you can see. Root is not required for other pinxi commands

Code:
harry@biker:~
$ pinxi -SMG
System:
  Host: harry@biker:~
$ pinxi -SMG
System:
  Host: biker Kernel: 4.15.9-antix.1-amd64-smp x86_64 bits: 64 Desktop: IceWM 1.4.2 
  Distro: antiX-17_x64-full Heather Heyer 24 October 2017 
Machine:
  Type: Desktop System: Google product: Parrot v: 1.0 serial: N/A 
  Mobo: Google model: Parrot v: 1.0 serial: N/A BIOS: coreboot 
  v: 4.0-6588-g4acd8ea-dirty date: 09/04/2014 
Graphics:
  Card-1: Intel 3rd Gen Core processor Graphics Controller driver: i915 v: kernel 
  Display Server: X.Org 1.19.2 driver: modesetting unloaded: vesa,fbdev 
  resolution: 1366x768~60Hz 
  OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile version: 3.3 Mesa 13.0.6 
  direct render: Yes 

harry@biker:~
$ pinxi -N
Network:
  Card-1: Qualcomm Atheros AR9462 Wireless Network Adapter driver: ath9k 
  Card-2: Broadcom Limited NetLink BCM57785 Gigabit Ethernet PCIe driver: tg3

Edit: I went ahead and updated inxi . Now even though root still owns permission in pinxi folder

Code:
harry@biker:~
$ pinxi -xxx -W pecos,tx
Weather:
  Conditions: 57 F (14 C) - Clear Wind: From the North at 4 MPH Humidity: 32% 
  Pressure: 30.15 in (1021 mb) Dew Point: 28 F (-2 C) Location: Pecos, Tx 
  Altitude: 787.3 m Time: Tue 20 Mar 2018 07:11:56 PM CDT 
  Observation Time: March 20, 1:15 PM CDT
Learning that inxi and pinxi are tied together somehow. Now, a user, does not get permission denied.

Last edited by rokytnji; 03-20-2018 at 03:15 PM.
 
Old 03-20-2018, 03:19 PM   #48
mralk3
Senior Member
 
Registered: May 2015
Location: Utah, USA
Distribution: Slackware 14.2 || Slackware-current && CentOS
Posts: 1,322

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697
Quote:
Originally Posted by mralk3 View Post
There is a new release of inxi, no longer named pinxi. See here: https://github.com/smxi/inxi

I assume the errors you are getting are due to the fact that you need to download the new release...

Code:
git clone https://github.com/smxi/inxi.git
cd inxi
perl inxi
Quote:
Originally Posted by rokytnji View Post

..snip..

Edit: I went ahead and updated inxi . Now even though root still owns permission in pinxi folder

..snip..

Learning that inxi and pinxi are tied together somehow. Now, a user, does not get permission denied.
Delete all the files on your system related to pinxi and install inxi.
 
Old 03-20-2018, 03:27 PM   #49
rokytnji
LQ Veteran
 
Registered: Mar 2008
Location: Waaaaay out West Texas
Distribution: AntiX 17
Posts: 5,587
Blog Entries: 20

Rep: Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664Reputation: 2664
Scratches head because I brought everything back to stock after updating inxi. Maybe I should reboot or logout after this post.

Code:
root@biker:/home/harry/.local/share/pinxi# chown root:root location-main.txt 
root@biker:/home/harry/.local/share/pinxi# chown root:root  weather-32.4331-97.5390.txt  
root@biker:/home/harry/.local/share/pinxi# ls -l
total 16
-rw-r--r-- 1 root root  255 Mar 20 10:42 location-main.txt
-rw-r--r-- 1 root root 3327 Mar 20 10:42 weather-32.4331-97.5390.txt
-rw-r--r-- 1 root root 1098 Mar 20 13:25 weather-79772.txt
-rw-r--r-- 1 root root 1098 Mar 20 13:33 weather-pecos-tx.txt
root@biker:/home/harry/.local/share/pinxi# exit
exit
harry@biker:~/.local/share/pinxi
$ pinxi -xxx -W pecos,tx
Weather:
  Conditions: 57 F (14 C) - Clear Wind: From the North at 4 MPH Humidity: 32% 
  Pressure: 30.15 in (1021 mb) Dew Point: 28 F (-2 C) Location: Pecos, Tx 
  Altitude: 787.3 m Time: Tue 20 Mar 2018 07:21:25 PM CDT 
  Observation Time: March 20, 1:15 PM CDT 
harry@biker:~/.local/share/pinxi
$ pinxi -W 79772
Error 45: Error opening file: /home/harry/.local/share/pinxi/weather-79772.txt 
Error: Permission denied
harry@biker:~/.local/share/pinxi
$ pinxi -xxx -W 79772
Error 45: Error opening file: /home/harry/.local/share/pinxi/weather-79772.txt 
Error: Permission denied
harry@biker:~/.local/share/pinxi
$ pinxi -W
Error 10: Unsupported value:  for option: W
Check -h for correct parameters.
harry@biker:~/.local/share/pinxi
$ pinxi -w
Error 45: Error opening file: /home/harry/.local/share/pinxi/location-main.txt 
Error: Permission denied
harry@biker:~/.local/share/pinxi
$ 
harry@biker:~/.local/share/pinxi
$ pinxi -xxx -w
Error 45: Error opening file: /home/harry/.local/share/pinxi/location-main.txt 
Error: Permission denied
harry@biker:~/.local/share/pinxi

After a reboot just to make sure.

Code:
harry@biker:~
$ sudo inxi -U
[sudo] password for harry: 
Starting inxi self updater.
Using curl as downloader.
Currently running inxi version number: 2.9.01
Current version patch number: 00
Current version release date: 2018-03-20
Updating inxi in /usr/local/bin using main branch as download source...
Successfully updated to main branch version: 2.9.01;
New main branch version patch number: 00;
New main branch version release date: 2018-03-20;
To run the new version, just start inxi; again.
----------------------------------------

Starting download of man page file now.
Skipping man download because branch version is being used.
harry@biker:~
$ sudo pinxi -U
Starting pinxi self updater.
Using curl as downloader.
Currently running pinxi version number: 2.9.00
Current version patch number: 457-p
Current version release date: 2018-03-20
Updating pinxi in /usr/local/bin using inxi-perl branch as download source...
Successfully updated to inxi-perl branch version: 2.9.00;
New inxi-perl branch version patch number: 457-p;
New inxi-perl branch version release date: 2018-03-20;
To run the new version, just start pinxi; again.
----------------------------------------

Starting download of man page file now.
Skipping man download because branch version is being used.
harry@biker:~
$ pinxi -W
Error 10: Unsupported value:  for option: W
Check -h for correct parameters.
harry@biker:~
$ pinxi -xxx -W 79772
Error 45: Error opening file: /home/harry/.local/share/pinxi/weather-79772.txt 
Error: Permission denied
harry@biker:~
$ pinxi -xxx -W pecos,tx
Error 45: Error opening file: /home/harry/.local/share/pinxi/weather-pecos-tx.txt 
Error: Permission denied
harry@biker:~
$ su
Password: 
root@biker:/home/harry# pinxi -xx -W
Error 10: Unsupported value:  for option: W
Check -h for correct parameters.
root@biker:/home/harry# pinxi -xx -W 79772
Weather:   Conditions: 61 F (16 C) - Clear Wind: From the SE at 6 MPH Humidity: 28% 
           Pressure: 30.12 in (1020 mb) Dew Point: 27 F (-3 C) Time: Tue 20 Mar 2018 07:32:28 PM CDT 
root@biker:/home/harry# pinxi -xxx -W 79772
Weather:   Conditions: 61 F (16 C) - Clear Wind: From the SE at 6 MPH Humidity: 28% 
           Pressure: 30.12 in (1020 mb) Dew Point: 27 F (-3 C) Location: 79772 Altitude: 787.3 m 
           Time: Tue 20 Mar 2018 07:32:55 PM CDT Observation Time: March 20, 2:15 PM CDT 
root@biker:/home/harry# pinxi -xx pecos,tx
Error 22: Unsupported option: pecos,tx
Check -h for correct parameters.
root@biker:/home/harry# pinxi -xx -W pecos,tx
Weather:   Conditions: 61 F (16 C) - Clear Wind: From the SE at 6 MPH Humidity: 28% 
           Pressure: 30.12 in (1020 mb) Dew Point: 27 F (-3 C) Time: Tue 20 Mar 2018 07:33:35 PM CDT 
root@biker:/home/harry# pinxi -xxx -W 79772
Weather:   Conditions: 61 F (16 C) - Clear Wind: From the SE at 6 MPH Humidity: 28% 
           Pressure: 30.12 in (1020 mb) Dew Point: 27 F (-3 C) Location: 79772 Altitude: 787.3 m 
           Time: Tue 20 Mar 2018 07:33:54 PM CDT Observation Time: March 20, 2:15 PM CDT 
root@biker:/home/harry# exit
exit
harry@biker:~

Last edited by rokytnji; 03-20-2018 at 03:40 PM.
 
Old 03-20-2018, 03:48 PM   #50
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,426

Rep: Reputation: 833Reputation: 833Reputation: 833Reputation: 833Reputation: 833Reputation: 833Reputation: 833
rokytnji --

How did you start your root login session ?

Always be careful with a nekkid `su` command.

It will hand your environment ( harry ) over to root.

And the pinxi script is chock-full of $ENV{ 'blah' } references, including $ENV{'HOME'}/.local/share/$self_name/ # where $self_name == 'pinxi'

This will result in root writing / overwriting files in /home/harry/.local/share/pinxi/

Anyhow ... the punch line is, try: su - ( su dash ) instead of the nekkid su

Someone posted a link here on LQ that explains the differences between su and su - ... I can't find it but ...

HTH

-- kjh
 
Old 03-20-2018, 05:44 PM   #51
h2-1
Member
 
Registered: Mar 2018
Distribution: Debian Testing
Posts: 75

Original Poster
Rep: Reputation: Disabled
NOTE: because I was so overwhelmed by the response to pinxi beta tests, I've decided to permanently do all dev work on the pinxi branch of inxi from now on. So you can keep updating pinxi to test fixes.

============================

kjhambrick, thanks for the reminder. I actually split the units out, in the core data, and the original idea was in fact to offer a units config option. I just didn't get around to it. I think the code is partially done for that.

The entire process of rewriting and also refactoring inxi into Perl, and the subsequent beta tests and issues caused by moving from a super loose and sloppy set of languages to a very tight and disciplined one triggered a flood of errors and warnings, which basically meant checking every bit of data inxi had used previously for being valid, which inxi never needed. So I didn't get to finish everything on the todo list, which is one reason I did inxi as 2.9.01 and not 3.0.0.

So the answer is, yes, that was my intention to do that, but I had so much else to do that I didn't get around to it.

This would impact: hdd temp, sensors, and maybe also weather, though that data is messier.

The location comes from the ubuntu location server, and reflects not a sinister gps locator but simply what the isp you are using tells the ubuntu locator. You can try using your zipcode or long/lat to see if you get closer, but it's also a function of the nearest weather station being used.

Since the units would be a global change, I'd do that all at once as a new feature, not piecemeal. I'll start an issue on github that lists these things since I won't remember them.

Nice fix for SSD hdd temp, I'll have to give that a try, I thought they just didn't have it.

============================

mralk3, since I was one of those users who simply assumed that the full path would be given, I'm glad you noticed this. I was just handling the output file test with one simple test, but it looks like it should be using 2, starts with / or not. The basic test is, if only file name OR path is not writable, return false. It's not a granular test, that is, re the error message, but I can clearly improve the error message, so that's what I will do, to note it must be the full path. I'm changing it in pinxi 2.9.01-01 to include the information that the path must be full path, be writable, and include the file name.

Your observation that you are sure some user will try it is 100% correct. I've updated the error message and test to now check for: starts with /, has a directory, like /something/test.json, and has the file, test.json, and that the directory is writable. The error message alerts users to these requirements, and prints out their path, so that should cover that.

this will be in pinxi 2.9.01-01-p

Re packaging, you are certainly correct that you should not be using the arch packagers data.

Here are the options available to maintainers, they cover basically everything:

1. just track the master branch with git. I've just removed the .gz history, so it's now nice and small.

Code:
git clone https://github.com/smxi/inxi --branch master --single-branch
2. Get the commit tarball from github:

Code:
wget -O /path/master.zip https://github.com/smxi/inxi/archive/master.zip
To me, this seems like plenty of options, but there's always someone out there who wants it in some different format, but with 5, that really should be enough for anyone's needs.

To get the an Arch guy today who was wasting my time to leave me alone, I've changed how the repos work, I've removed the .gz files from history and cache, and now have autotagging for every release. The tags show version, date, and a random string so that I don't have to worry about having the same commit messages.

============================

FTIO, it all looks good.

============================

rokytnji, at first I scratched my head about your file issue, then I realized, oh, this must be a case where you have your system set to have:

$XDG_DATA_HOME with the same value for root and your user account, which means, root is writing to your user home directory:

~/.local/share/pinxi

because $XDG_DATA_HOME is the same for root and for user.

I'm not 100% positive, but I believe this is a configuration error, since ALL files created by root would be unwritable by user in that circumstance, and that circumstance is the only one that could have caused that issue.

If $XDG_DATA_HOME is not set, pinxi reverts first to $HOME/.local/share/pinxi/, if .local/share is present, and if not, to $HOME/.pinxi/

As you can see, the only possible way that root could own a file in this circumstance would be if $XDG_DATA_HOME was set to the same value for root and user, which I believe is an error, though I don't really know for sure since I don't use that method myself, and I only read up on it enough to be able to implement it. But that's what is going on.

If this is a default however it's something that might have to be handled. Since this issue will impact ALL files, not just weather, log pinxi.log, debugger data, whatever is in those data directories, this is an issue I'd like to have clarified. I believe it's a configuration error since it makes no sense to create files in user home that aren't writable by user.

Last edited by h2-1; 03-20-2018 at 07:53 PM.
 
Old 03-20-2018, 06:55 PM   #52
hydrurga
LQ Guru
 
Registered: Nov 2008
Location: Pictland
Distribution: Linux Mint 19 MATE
Posts: 6,403
Blog Entries: 2

Rep: Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060
Just a note that the Machine dates I've seen on here appear to be in either dd/mm/yyyy or mm/dd/yyyy format, hence leading to potential confusion. Are these generally hard-coded in that format on the various machines, or would it be possible to present them in yyyy-mm-dd or wordy format (e.g. "3 Sep 2010")?
 
Old 03-20-2018, 07:12 PM   #53
hydrurga
LQ Guru
 
Registered: Nov 2008
Location: Pictland
Distribution: Linux Mint 19 MATE
Posts: 6,403
Blog Entries: 2

Rep: Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060Reputation: 2060
I've also noticed that my hard disk is reported as 931.51 GB, whereas technically it is 935.51 GiB (in my current, old, inxi version it is reported correctly as 1000.2 GB). I assume that all the other GB in the inxi output are also meant to be GiB. I know it might seem petty, but imo it would lead to less confusion if IEC prefixes were used.
 
Old 03-20-2018, 07:56 PM   #54
h2-1
Member
 
Registered: Mar 2018
Distribution: Debian Testing
Posts: 75

Original Poster
Rep: Reputation: Disabled
kjhambrick, just a quick note, I checked this, and that's not correct, HOME belongs to the user, and if the user used su he's now root. I verified this by running as root: pinxi --debug 10

this resulted in the expected /root/.local/share/pinxi/pinxi.log generation. No such log file appeared in my user .local/share/pinxi/ directory, nor should it have, since root home is /root

I believe the $XDG path is probably correct, and that path is being used for both, but I'll double check.

inxi for 10 years used these methods, and I never once saw a user's files get written to their home directory when they were root, which makes me suspect that it's a specific thing to this install.

Last edited by h2-1; 03-20-2018 at 07:58 PM.
 
Old 03-20-2018, 11:09 PM   #55
h2-1
Member
 
Registered: Mar 2018
Distribution: Debian Testing
Posts: 75

Original Poster
Rep: Reputation: Disabled
hydrurga, sorry, I had to deal with some real bs, couldn't get back until now.

Re dates, pinxi isn't currently touching them, they are strings, and it prints whatever is given it. Dates are kind of a pain, the classic example being: 12/12/12 - where in the world does it come from? is it mm/dd/yy is it dd/mm/yy?

So guessing at string value dates that come from different sources has always been a bit risky. I also prefer the iso standard date format, and use it in my work always, because it's sortable, consistent, and not ambiguous, but it's slightly risky converting dates of unknown date time format to iso dates without knowing the format.

I've honestly never seen GiB for size, and having done tech a long time, that's saying something. I've seen G gB and GB, so I opted for the latter. That's one I think may be subjective.

But man df was helpful here, it looks like you are right:

Quote:
The SIZE argument is an integer and optional unit (example: 10K is 10*1024). Units are K,M,G,T,P,E,Z,Y

(powers of 1024) or KB,MB,... (powers of 1000)
so yes, I was wrong there, thank you for correcting me. I think I would prefer the less verbose form that df has, KMGTPE over the more verbose: KiB, hmm, though the latter looks nice, and might be educational.

I'm going to do some pinxi fixes then roll those all into inxi 2.9.02 to avoid too many master commits.
 
Old 03-20-2018, 11:41 PM   #56
h2-1
Member
 
Registered: Mar 2018
Distribution: Debian Testing
Posts: 75

Original Poster
Rep: Reputation: Disabled
https://ux.stackexchange.com/questio...ib-vs-kb-vs-kb

Re sizing, there's some pertinent comments there:

Quote:
"1 KB" means 1024 bytes (as Windows would report it, traditional usage)
"1 kB" means 1000 bytes (as Mac OS would report it, IEC usage)
"1 KiB" means 1024 bytes (unambiguous, but perhaps unfamiliar terminology)
## and as a commenter astutely points out:
Pretty much 0% of non-technical users will know what a KiB is, and the large majority are going to think what Windows reports (1024) is correct (if anything). KiB is more "technically" correct but in reality it's just a great way to confuse your users for no reason. To my knowledge the only non-Mac people to use 1000 bytes as a KB are Hard Drive manufacturers, who of course use the smallest possible definition of a kilobyte.
## and another, these roughly echo my feelings by the way
I agree that "KiB" is a little obscure; I'm not crazy about it (although perhaps non-technical user wouldn't think that much about it if they saw an extra "i" in the middle)
##
Even technical users sometimes mix these up. Case in point: before I read the definition above, I was pretty sure KiB = 1000 bytes. (and I'd never seen it or heard of it, which I think says something about how rarely this syntax is used out in the wilds)

## The accepted answer is quite complete:
The IEC standard names are useless: As Jeff Atwood notes there is simply no industry acceptance of KiB/MiB/GiB. Hard drive manufacturers and Macs are the only major players using the 1000 bytes definition and hard drive manufacturers have absolutely no incentive to differentiate KiB from KB; it makes their drives sound smaller. Macs and Windows have no incentive to use KiB because it's an unnecessary complication for the user. Note that it's been 12 years since the definitions were created, and they're not being adopted anytime soon.

## this is actually a very good discussion, people make good points all around
The KiB has been introduced not because of a whim but because some quantities are measured that way and others the kB way, and that it's not convenient to speak of "multiple of 1000 kilometers per hour" and "multiple of 1024 kilobytes". For another example, communication rates (what many erroneously call speed) are measured in kbps = 1000 bps (bits/sec) while one speaks of kBps = 1024 Bps (bytes/sec) where it should be KiBps. One does not multiply KiBps by just 8 to obtain kbps.
The reason why some persons did not notice that communication rates kbps are multiple of 1000 instead of 1024 is that they use k for 1024 in computer science which generally counts by powers of 2.

## and a comment, which highlights that despite the best intentions, this standard has totally failed to take hold
According to Wikipedia, in the JEDEC standard, 1000 bytes is 1 kB, and 1024 bytes is 1 KB en.wikipedia.org/wiki/Kilo- but 1024 bytes is also known as a kibibyte, 1 KiB
So the basic notion is, hdd makers like gB because it makes their disks sound bigger, Data is stored in XiB units, and reported that way to users. I notice for example that pcmanfm is opting for the non ambiguous unit of KiB, and since I've always liked their approach to software, that's a good argument for it. Apple uses the same units HDD makers do, but I don't care about what apple does because inxi isn't made for apple users.

Upon further reading, I've realized the bigger risk is actually the data in /proc/partitions, which is not at all clear, and was an issue report to Debian, though it has nothing to do with Debian:
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=666972

Quote:
A. Costa: From scanning the source code (where the count of blocks is
"part_nr_sects_read(part) >> 1" in block/genhd.c::show_partition() --
I assume a sector is 512 B), I'm reasonably sure that /proc/partitions
is giving us 1024-byte blocks. Here's my experiment:
Since HDD size data comes from there, and appears to be in KiB, assuming this is correct, and since inxi is using KiB as the internal unit, I think the precision and lack of ambiguity of KiB type measurement is worth it.

Oddly most of these discussions ignore the even more common form, K/M/G/T which I believe refer to XiB.

So we have a really strange situation where most users see GB as GiB, many systems reflect that, but it actually means 1000^x bytes.

So I'll try with the slightly awkward GiB/MiB for the time being, but it's worth keeping in mind that what those thread discussions said is absolutely correct, if users see that, they will absolutely not know what it means unless they are real tech pro types. So in terms of clarifying I believe it will not achieve that goal. Once it's settled in, I can have the man page reflect that fact more clearly.

However, it's often useful to take off our tech hats, which like precise things, and put on our usability hats. HDD makers use as noted, the smallest kb unit to make their disks seem the biggest. Software uses KiB type units usually. Users believe their 1000 GB hdd is 1000 GiB, and don't realize when you show them the real size in GiB, that it's smaller because the hdd makers have always kind of used this white lie to make disks seem bigger re storage, but of course, good luck trying to fit 1000 GiB of data on a 1 TB disk, lol. So I believe that technically speaking, re telling users what is useful, using the GiB is confusing but also clear, though I may use the KMGTPE without the Byte, which is short and from what I gather, means GiB etc, not GB. the only non ambiguous part of this is that kB means 1000 bytes.

Last edited by h2-1; 03-21-2018 at 02:26 AM.
 
Old 03-20-2018, 11:52 PM   #57
h2-1
Member
 
Registered: Mar 2018
Distribution: Debian Testing
Posts: 75

Original Poster
Rep: Reputation: Disabled
mralk3, re pinxi vs inxi, I decided last night to do the following, and I believe I'm going to stick with it:

1. pinxi will always be the development branch for inxi
2. Once I've collected a set of fixes, I'll copy over pinxi to inxi, and each will operate separately.

So for debugging, testing, the pinxi branch will basically always be either the same or ahead of inxi. inxi will not have any fixes or updates until pinxi has tested them. This lets me run both programs on one machine with no conflicts.

I was very happy with how using pinxi to dev inxi perl turned out, and I've internally written inxi now to detect based on its $self_name value, inxi, binxi, or pinxi, what to do with updates to itself. No conflicts will occur between the versions, they share no data, no configs, nothing.

Going forwards, I feel pretty comfortable with this solution. I used to always develop svn inxi back in svn days that way, and I've missed it ever since.
 
Old 03-20-2018, 11:56 PM   #58
h2-1
Member
 
Registered: Mar 2018
Distribution: Debian Testing
Posts: 75

Original Poster
Rep: Reputation: Disabled
mralk3, by the way, re the tarball release, the Arch packagers were complaining about that, because, well, inxi has always had a tarball release, inxi.tar.gz, which led to bloat of git. So I'm kind of at a loss. github itself always has a tarball release, it's a github feature for all repos. It's I believe a static url, but since I am adding tagging, though still experimenting with it to see how to best handle it, hopefully most people will be ok with no gz files, the built in github gz tarball, and the tagged every release thing.
 
Old 03-21-2018, 12:33 AM   #59
h2-1
Member
 
Registered: Mar 2018
Distribution: Debian Testing
Posts: 75

Original Poster
Rep: Reputation: Disabled
https://superuser.com/questions/1179...output-meaning

has more questions on sizes, this time about the sizes of ps aux VSZ RSS size columns, as you will see there, the initial reply believed the units were bytes, which was obviously absurd, then the next pointed out that the units are in KiB.

So you can certainly see the utility of being precise when KB means 1024 and 1000 depending on your usage and habits. It appears to me that so far, GNU/Linux seems to be working KiB internally as well, so I feel comfortable doing that in pinxi as well, though it's good to be precise to avoid confusion.

next pinxi will have these updates, and inxi 2.9.02 will have them, thanks for such close scrutiny, it's very useful.
 
Old 03-21-2018, 05:23 AM   #60
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,426

Rep: Reputation: 833Reputation: 833Reputation: 833Reputation: 833Reputation: 833Reputation: 833Reputation: 833
Quote:
Originally Posted by h2-1 View Post
kjhambrick, just a quick note, I checked this, and that's not correct, HOME belongs to the user, and if the user used su he's now root. I verified this by running as root: pinxi --debug 10

this resulted in the expected /root/.local/share/pinxi/pinxi.log generation. No such log file appeared in my user .local/share/pinxi/ directory, nor should it have, since root home is /root

I believe the $XDG path is probably correct, and that path is being used for both, but I'll double check.

inxi for 10 years used these methods, and I never once saw a user's files get written to their home directory when they were root, which makes me suspect that it's a specific thing to this install.
Thanks h2-1

I saw your explanation for rokytnji's permissions issue in the other post and it makes perfect sense.

His issue did make me look at the weather-related code in pinxi and I found an minor typo ( head -vs- heat ):

Unified diff is below my sig.

Thanks !

-- kjh

Code:
# diff -Naur a/pinxi b/pinxi

--- a/pinxi     2018-03-20 08:04:37.338588642 -0500
+++ b/pinxi     2018-03-21 04:21:23.131221434 -0500
@@ -12915,7 +12915,7 @@
                        $weather{'pressure'} = $working[1];
                }
                elsif ( $working[0] eq 'heat_index_string' ){
-                       $weather{'head-index'} = $working[1];
+                       $weather{'heat-index'} = $working[1];
                }
                elsif ( $working[0] eq 'windchill_string' ){
                        $weather{'windchill'} = $working[1];
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Firefox: are we its informal beta-testers? FeyFre Slackware 29 11-21-2011 03:15 AM
Beta Testers Needed msound General 18 07-28-2006 11:22 AM
looking for beta testers grizzly General 5 03-20-2004 12:24 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:13 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration