-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new package diagnostic/glances #9591
base: oi/hipster
Are you sure you want to change the base?
Conversation
Glances is a monitoring tool like htop, but provides many more features. It has a rich selection of plugins to extend its functionality.
COMPONENT_LICENSE_FILE=$(COMPONENT_SRC)/LICENSES/LGPL-3.0-only.txt | ||
#PYTHON_VERSIONS= $(PYTHON3_VERSIONS) | ||
PYTHON_VERSIONS= 3.9 | ||
PYTHON_VERSION= 3.9 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the build process will produce same results even with the above three lines removed. If so, then please remove them. If not, then please share the differences.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need either PYTHON_VERSIONS or PYTHON_VERSION, as I obtain this:
...>gmake env-prep
...
pkg install: No matching version of library/python/importlib-metadata-37 can be installed:
Reject: pkg://openindiana.org/library/python/[email protected]
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because you have library/python/importlib-metadata
in PYTHON_REQUIRED_PACKAGES
. I'm curious how it appeared there. It should list library/python/importlib_metadata
instead. Is your system up-to-date?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please check the output of "pkg info userland-incorporation". The latest is FMRI: pkg://openindiana.org/consolidation/userland/[email protected]:20221021T131054Z from a few minutes ago. It shouldn't be much older.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i had to update, am now at
FMRI: pkg://openindiana.org/consolidation/userland/[email protected]:20221021T131054Z
which is just a few hours old.
Now, gmake env-prep moans:
pkg list: no packages matching the following patterns are installed:
/library/python/importlib-metadata-37
Adding required packages to build environment...
This error is resolved by including:
PYTHON_VERSIONS= 3.9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the remove of PYTHON_VERSIONS= 3.9: There is a subtle difference between what happens with or without this: If you don't have it, there will be builds in the build folder for every python version (3.7 and 3.9 at the moment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...> pkg list -a | grep importlib
@mebenn: Your output is strange for several reasons.
First, there is (openindiana.org)
in the output so you very like have non-default/non-standard publisher setup (pkg publisher
output would tell us more).
Second, it miss some lines. The expected output should be something like this:
# pkg list -a | grep importlib
library/python/importlib-metadata-27 1.5.2-2020.0.1.2 --o
library/python/importlib-metadata-35 1.5.2-2020.0.1.1 i--
library/python/importlib-metadata-37 1.5.2-2020.0.1.2 i-r
library/python/importlib-metadata-39 1.5.2-2020.0.1.2 i-r
library/python/importlib_metadata 4.10.1-2022.0.0.0 i--
library/python/importlib_metadata-37 4.10.1-2022.0.0.0 i--
library/python/importlib_metadata-39 4.10.1-2022.0.0.0 i--
#
Third, even with your strange pkg list -a | grep importlib
output I do not understand how you got library/python/importlib-metadata
in PYTHON_REQUIRED_PACKAGES
. Is your workspace up-to-date (git pull
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the remove of PYTHON_VERSIONS= 3.9: There is a subtle difference between what happens with or without this: If you don't have it, there will be builds in the build folder for every python version (3.7 and 3.9 at the moment).
This is valid point. Yes, you are right. But that should be the only difference (plus a bit longer build time). The resulting package should be the same. If we want to avoid that right now I believe the best way is to set PYTHON_VERSIONS = $(PYTHON_VERSION)
.
This is also reason why we need to order builds for various Python versions. I removed this ordering recently (mistakenly) so I'll return it back for now until some better solution is implemented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but we have again some failing packages due to these changes. Furthermore, I found another difference (new vs. old):
< set name=pkg.fmri value=pkg:/$(COMPONENT_FMRI)-$(PYV)@$(IPS_COMPONENT_VERSION),$(BUILD_VERSION)
set name=pkg.fmri value=pkg:/$(COMPONENT_FMRI)@$(IPS_COMPONENT_VERSION),$(BUILD_VERSION)
The automatic addition of $(PYV) to package fmri could be suppressed using GENERATE_EXTRA_CMD=
in component's Makefile
.
BTW, I plan to implement better (and simpler) support for python components that do not need to be build for multiple pythons (like this one, or ansible, etc), but first I'd like to complete fully automatic integration of versioned python components.
OTOH, if these components (glances, ansible, and so on) are built as versioned python packages, then they would be easier to integrate now. AFAIK, versioned python packages have only one con I'm aware about: there is set of packages, instead of single package, but the main package name will stay, so no big difference for end users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's my current env:
I'm up-to-date...
...> git log
`...
commit 774110f (upstream/oi/hipster)
Author: Marcel Telka [email protected]
Date: Fri Oct 21 06:47:57 2022 +0200
perl/B-COW: update to 0.007
...
`
i.e., my (rebase) commits are above the the commit today at 6:47, and commits below I've omitted. So update looks ok.
# pkg list -a | grep importlib library/python/importlib-metadata-27 1.5.2-2020.0.1.2 --o library/python/importlib-metadata-35 1.5.2-2020.0.1.1 i-- library/python/importlib-metadata-37 1.5.2-2020.0.1.2 i-r library/python/importlib-metadata-39 1.5.2-2020.0.1.2 i-r library/python/importlib_metadata 4.10.1-2022.0.0.0 i-- library/python/importlib_metadata-37 4.10.1-2022.0.0.0 i-- library/python/importlib_metadata-39 4.10.1-2022.0.0.0 i-- #
...> uname -a
SunOS oi 5.11 illumos-ea524515bd i86pc i386 i86pc benn@oi:~/devl/oi/oi-userland/components$
I've also noticed a problem with glances-3.9 in the bin dir. I tried to resolve this by removing $(PYV) (in glances.p5m) from the fmri to obtain
set name=pkg.fmri value=pkg:/$(COMPONENT_FMRI)@....
and then coping /usr/bin/glances-3.9 to /usr/bin/glances in COMPONENT_POST_INSTALL_ACTIONS; but this is horrible.
So I still think that I require PYTHON_VERSION=3.9 to avoid different builds for different Python versions.
I'll have a look tomorrow and be on IRC if anyone happens to be about.
Cheers, thanks for the help
#https://github.com/nicolargo/glances/archive/refs/tags/v3.2.7.tar.gz | ||
#COMPONENT_ARCHIVE_URL=$(call pypi_url) | ||
COMPONENT_LICENSE= LGPL-3.0-only | ||
COMPONENT_LICENSE_FILE=$(COMPONENT_SRC)/LICENSES/LGPL-3.0-only.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you do not need the $(COMPONENT_SRC)/
part here.
@@ -0,0 +1,67 @@ | |||
[Desktop Entry] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where this file comes from? It lacks the copyright/license header.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know much about Mate. I copied /usr/share/applications/htop.desktop to glances.desktop and configured. Now the htop package self does not contain any htop.desktop, so I assume this was generated by Mate??
It would be even easier if I could generate a .desktop for glances.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then, maybe, it would be better to do not include this file? Since Glance seems to be a terminal utility we do not need desktop file for it, IMHO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW: This package is also a candidate as we don't want to have /usr/bin/glances-3.9
# | ||
|
||
BUILD_BITS=NO_ARCH | ||
BUILD_STYLE=setup.py |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmmm. This seems to be a nice candidate for python-integrate-project
integration. Did you try to integrate using $WS_TOOLS/python-integrate-project Glances
? It might be a bit harder to create the first integration, but all future maintenance and upgrades would be far far easier.
license $(COMPONENT_LICENSE_FILE) license='$(COMPONENT_LICENSE)' | ||
|
||
file path=usr/bin/glances | ||
file path=usr/lib/python$(PYVER)/vendor-packages/Glances-$(COMPONENT_VERSION)-py$(PYVER).egg-info/PKG-INFO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sample-manifest.p5m differs here: it contains usr/bin/glances-$(PYVER)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To get usr/bin/glances
in sample-manifest.p5m
too you need to add COMPONENT_POST_INSTALL_ACTION=
to Makefile
after the common.mk
include.
@mebenn: Does glances work on your system? It looks like there is a missing runtime dependency on defusedxml for which we need to have a package first. |
To create such package you could just run |
@AndWac ...> pip list | grep defusedxml So it is indeed on my system. So I'll try |
Is this still relevant? It looks like nobody cares anymore... |
@AndWac |
Glances is a monitoring tool like htop, but provides many more features. It has a rich selection of plugins to extend its functionality.