Re: [oi-dev] pkgdepot data over rsync
On Thu, Jun 27, 2024 at 08:20:40PM +0200, Till Wegmüller wrote: > Permissions fixed, should work now. Let me know if some files still fail. Rsync passed with no other issue reported. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkgdepot data over rsync
Hi Till, Gentle ping... On Tue, Jun 25, 2024 at 10:07:11PM +0200, Marcel Telka wrote: > I noticed this issue: > rsync: [sender] send_files failed to open > "oi-sparc/backup/userland/gcc10.p5p" (in oirepo): Permission denied (13) > > Could you please check the oi-sparc/backup/userland/gcc10.p5p file > permissions at the server? -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkgdepot data over rsync
On Sun, Jun 23, 2024 at 05:48:48PM +0200, Till Wegmüller wrote: > rsync -zv openindiana.org::oirepo shows you all repos on this system hipser > is the main repo for OpenIndiana x86 hipster-encumbered is the encumbered > repo and oi-sparc is the Sparc package repository. I noticed this issue: rsync: [sender] send_files failed to open "oi-sparc/backup/userland/gcc10.p5p" (in oirepo): Permission denied (13) Could you please check the oi-sparc/backup/userland/gcc10.p5p file permissions at the server? Thank you. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkgdepot data over rsync
On Sun, Jun 23, 2024 at 05:48:48PM +0200, Till Wegmüller wrote: > I Created a rsync daemon that exposes two modules oirepo and oidlc. Both > give read-only access to the root of all repositories or dlc respectively. > > So to sync hipster repos use > > rsync -azv openindiana.org::oirepo/hipster > > For the Isos use: > rsync -azv openindiana.org::oidlc/isos > > rsync -zv openindiana.org::oirepo shows you all repos on this system hipser > is the main repo for OpenIndiana x86 hipster-encumbered is the encumbered > repo and oi-sparc is the Sparc package repository. Perfect. Thank you! -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkgdepot data over rsync
On Thu, Jun 20, 2024 at 08:30:06PM +0200, Till Wegmüller wrote: > Sorry about that, > We moved the Repository server to a new Machine. I never noticed that we > also had a public endpoint for rsync but I'll get it back online in the next > couple days. It is probably a lot faster than the pkgrecv endpoint. That would be great. Thank you. Could you please also consider rsync for (something that used to be) dlc-origin in past? We already discussed this three years ago[*], but there is still no satisfying solution available, AFAIK. [*] https://openindiana.org/pipermail/oi-dev/2021-July/032789.html Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] pkgdepot data over rsync
Hi, The pkgdepot data (the IPS server's packages) are supposed to be available via rsync at rsync://pkg-origin.openindiana.org/pkgdepot-hipster/ However I just noticed that since few days back the data are no longer updated there and so users are no longer able to create pkg publisher mirrors. Could you please fix the rsync repo? Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Heads-Up: Plan to obsolete application/cluster/pcs
Hi, We plan to obsolete the application/cluster/pcs package in OpenIndiana soon. There are at least following reasons for the obsoletion: - our current packaged version (0.10.1) is very old; this version was released upstream 5.5 years ago, - the pcs package is broken and does not work: https://openindiana.org/pipermail/oi-dev/2024-May/033632.html - it is hard to maintain pcs: https://openindiana.org/pipermail/oi-dev/2024-May/033633.html - there are no known pcs users If you believe the application/cluster/pcs package should not be obsoleted then please adopt the package and start to maintain it. Thanks for understanding. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pcs problems
On Thu, May 23, 2024 at 06:19:55PM +0200, Andreas Wacknitz via oi-dev wrote: > The fact that nobody detected the problem before showed me that we don't > have pcs users and thus I am not sure whether the needed work is worth > to spend. +1 I propose to declare the pcs package EOLed in OI and remove it in few weeks, unless somebody interested in it does the needed maintenance work. BTW, the application/cluster/pcs package is needed by metapackages/hacluster and metapackages/hacluster-remote packages. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Package problems
On Wed, Apr 10, 2024 at 12:24:57PM +0200, Udo Grabowski (IMK) wrote: > On 10/04/2024 12:19, Udo Grabowski (IMK) wrote: > > Today, two packages flag problems, which should be sorted out on the package > > server: > > > > pkg update: The following packages all deliver file actions to > > usr/lib/perl5/i86pc-solaris-thread-multi-64/perllocal.pod: > > > > > > pkg://openindiana.org/communication/im/pidgin@2.14.13,5.11-2024.0.0.0:20240225T225916Z > > > > > > pkg://openindiana.org/image/imagemagick@7.1.1.30,5.11-2024.0.0.0:20240409T205447Z > > > > These packages cannot be installed together. Any non-conflicting subset > > of the above packages can be installed. > > > > The following packages deliver conflicting action types to usr/man: > > > > dir: > > > > pkg://openindiana.org/image/imagemagick@7.1.1.30,5.11-2024.0.0.0:20240409T205447Z > > link: > > > > pkg://openindiana.org/system/man@0.5.11,5.11-2024.0.0.22136:20240410T010818Z > > > > These packages cannot be installed together. Any non-conflicting subset > > of the above packages can be installed. > > > > The new imagemagick package has 2 spurious /usr/man/man3/ entries > which should be /usr/share/man/man3, as the other man pages: > > usr/man/man3/Image::Magick.3perl > usr/man/man3/Image::Magick::Q16HDRI.3perl It looks like both issues were solved here: https://github.com/OpenIndiana/oi-userland/pull/16858 -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Tue, Feb 20, 2024 at 09:58:02AM +0100, Marcel Telka wrote: > the couchdb-31 package is broken at the ips server: > > Errors were encountered while attempting to retrieve package or file data for > the requested operation. > Details follow: > > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > Invalid content: manifest hash failure: fmri: > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > > expected: 28185b5f27c3c0ce9ea1d8f129e0e5763f53e8ae computed: > b371cc90d6fd42c5bafa55f85afb183b59c23960. (happened 4 times) The package is okay since 2024-03-14. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Missing packages from IPS repo
Hi, After the IPS repository cleanup on 2024-03-14 there are following packages missing in the repo: pkg://openindiana.org/diagnostic/iftop@0.17-2020.0.1.1:20200330T152104Z pkg://openindiana.org/library/math/gts@0.7.6-2020.0.1.0:20200330T161435Z Please add them back. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Heads-Up: building with libjpeg is broken
On Mon, Mar 04, 2024 at 09:46:59AM +0100, Marcel Telka wrote:
> If your installation is older than 2024-03-03 or you do not build using
> libjpeg then you can safely skip this message.
>
>
> If your system is up-to-date and you are building anything that requires
> libjpeg then please be aware that under some circumstances your build
> bits could be broken.
>
> Simple test case showing the problem:
>
>
> $ cat > jpeg.c < #include
> #include
> #include
> #include
>
> int
> main(void)
> {
> struct jpeg_decompress_struct info;
> struct jpeg_error_mgr err;
>
> info.err = jpeg_std_error();
> jpeg_create_decompress();
>
> return 0;
> }
> EOF
> $ gcc -Wall -ljpeg -ojpeg jpeg.c
> $ ./jpeg
> Wrong JPEG library version: library is 62, caller expects 80
> $ echo $?
> 1
> $
>
>
> If the above is tested on an older system, then the ./jpeg command
> completes successfully.
>
>
> Please note that this depends on how exactly you integrate support for
> the libjpeg library, so it is possible that you are not affected.
>
> It is not recommended to merge any PRs for oi-userland that could cause
> rebuild of components depending on libjpeg (either ijg or turbo) until
> this issue is solved.
>
> Please also note that binaries built before 2024-03-03 that use libjpeg
> are not affected.
This issue has been fixed. So if your system is up-to-date as of now
then you are safe to build with libjpeg again.
--
+---+
| Marcel Telka e-mail: mar...@telka.sk |
|homepage: http://telka.sk/ |
+---+
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI Mate clock-applet crashes
On Sun, Mar 03, 2024 at 02:36:37PM +0100, Andreas Wacknitz via oi-dev wrote: > Am 03.03.24 um 14:13 schrieb Stephan Althaus: > > $ /usr/libexec/mate/clock-applet > > > > ** (clock-applet:9178): WARNING **: 13:29:39.524: Call can set time > > zone dbus method: > > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > > org.mate.SettingsDaemon.DateTimeMechanism was not provided by any > > .service files > > > > (clock-applet:9178): Gtk-WARNING **: 13:29:39.526: Negative content > > width -9 (allocation 1, extents 5x5) while allocating gadget (node > > button, owner GtkToggleButton) > > terminate called after throwing an instance of 'std::runtime_error' > > what(): Unable to read configuration > > Abort (core dumped) > > > Please create a fresh account and try with it whether you'll get similar > results. It may be you personal configuration forcing this error. Yes, I agree. There is possibly a remnant from older MATE in your configuration that is no longer supported or valid in recent MATE 1.28. If that's the case then there are few possible options: - it is a bug in MATE, so it should be reported upstream, - there is some (official) upgrade path from older MATE and we didn't follow that, - MATE does not support upgrades between versions without the user's config cleanup. Either way, this should be analyzed deeper and root caused. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Heads-Up: building with libjpeg is broken
Hi,
If your installation is older than 2024-03-03 or you do not build using
libjpeg then you can safely skip this message.
If your system is up-to-date and you are building anything that requires
libjpeg then please be aware that under some circumstances your build
bits could be broken.
Simple test case showing the problem:
$ cat > jpeg.c <
#include
#include
#include
int
main(void)
{
struct jpeg_decompress_struct info;
struct jpeg_error_mgr err;
info.err = jpeg_std_error();
jpeg_create_decompress();
return 0;
}
EOF
$ gcc -Wall -ljpeg -ojpeg jpeg.c
$ ./jpeg
Wrong JPEG library version: library is 62, caller expects 80
$ echo $?
1
$
If the above is tested on an older system, then the ./jpeg command
completes successfully.
Please note that this depends on how exactly you integrate support for
the libjpeg library, so it is possible that you are not affected.
It is not recommended to merge any PRs for oi-userland that could cause
rebuild of components depending on libjpeg (either ijg or turbo) until
this issue is solved.
Please also note that binaries built before 2024-03-03 that use libjpeg
are not affected.
Regards.
--
+---+
| Marcel Telka e-mail: mar...@telka.sk |
|homepage: http://telka.sk/ |
+---+
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Heads-Up: Motif obsoletion
Hi, I plan to obsolete the Motif library (together with the cde-incorporation) because it is: - very old - the package is more than 10 years old - not maintained - we have no knowledge how to build it (there is no build recipe for it in oi-userland) - not needed - nothing in OpenIndiana depends on it Namely, the following two packages will be obsoleted: pkg://openindiana.org/consolidation/cde/cde-incorporation@0.5.11-2013.0.0.0 pkg://openindiana.org/library/motif@0.5.11-2013.0.0.0 If you believe we should not obsolete Motif then please package it and contribute to oi-userland. It was open sourced and LGPLed more than 10 years ago. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Heads-Up: Obsoletion of 39 old packages
On Sat, Feb 03, 2024 at 08:52:51PM +0100, Marcel Telka wrote: > On Thu, Jan 18, 2024 at 06:06:20PM +0100, Marcel Telka wrote: > > On Tue, Jan 09, 2024 at 04:24:42PM +0100, Marcel Telka wrote: > > > I propose obsoletion of following 39 OpenIndiana packages: > > > > I'm happy to let you know that the list now contains 38 entries only. > > Matthew R. Trower packaged text/dwdiff so the list is down to 37 entries > only. FYI: https://github.com/OpenIndiana/oi-userland/pull/16318 When anything from the list gets packaged, then it simply would need to be removed from the history file too. Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] phasing out openssl 1.0.2 (mostly)
On Sun, Feb 25, 2024 at 02:32:14AM +0100, Goetz T. Fischer wrote: > On Sat, 24 Feb 2024 19:23:33 +0100, Marcel Telka wrote: > > Hi, > > > > On Sat, Feb 24, 2024 at 06:27:30PM +0100, Goetz T. Fischer wrote: > >> as you know there're still some packages in the repo that use openssl > >> 1.0.2. > >> so > >> far this had the unpleasant implication that all new packages had to be > >> hardcoded to newer ssl versions one way or the other, because the > >> buildsystem's > >> ssl mediator had to remain at 1.0. > > > > Sorry, this is not true. > > see ##1 below ... Sorry. I proved that you need to do exactly _nothing_ to get OpenSSL 3.1 for a component and your argument is ... that's the (potentially unnecessary) work i refered to. Huh? > > > It is already the other way around because the default OpenSSL version > > in the build framework is 3.1: > > > > $ grep OPENSSL_DEFAULT make-rules/shared-macros.mk > > OPENSSL_DEFAULT = 3.1 > > OPENSSL_VERSION ?= $(OPENSSL_DEFAULT) > > $ > > > > So in other words when a component needs non-default OpenSSL then it > > needs to specify the desired version via the OPENSSL_VERSION macro in > > its Makefile. > > which can be omitted if the desired version is the default 3.1 according to > https://github.com/OpenIndiana/oi-userland/pull/16202#discussion_r1496941478 Sorry, I do not understand what is your argument here. I said: OpenSSL 3.1 is default and you need to do nothing to get it. If you need non-default, you need to specify one. So what exactly can be ommitted? Specification of non-default? Really? At the URL you are referring to is stated the same: OpenSSL 3.1 is default. > > > And, in an ideal world this should be all that is needed re the OpenSSL > > support and versions for a component (see cryptography above for an > > example). > > as we all know, the ideal case is not the case all the time. hence ... I agree. Some software does not do proper detection of OpenSSL so we need to help them. > > >> i.e. only hardcoding the handful of packages which, for whatever reason, > >> still > >> need 1.0.2 and having the buildsystem's ssl mediator set to whatever is > > > > The openssl mediator (on build machine) is orthogonal to that. All > > components builds should produce same results with any openssl mediator > > setting. > > ... exactly that's what i wanted to "optimize out" so to speak. Sorry, no way. That would not be an optimization, but step back. We worked hard in past to be mediator agnostic as much as possible and this is the right way to go. Actually, I like to see the default openssl mediator to be set to so ancient OpenSSL version because it clearly shows all components that do not have proper OpenSSL integration. > my recent tries with userland showed that the mentioned shared macros are not > enough to make the buildsystems of various programs recognize an ssl version, > other than what the mediator is set to, as default. therefore having the > mediator set to whatever is considered the default at the time would be the > most efficient option, because it requires the least extra work for each > package. As I already said that's the problem with such programs and should be addresses there. See also below for a case study. > > > Provided the OpenSSL support in a packaged component is done > > properly. > > ##1 that's the (potentially unnecessary) work i refered to. > > > A package needing old(er) OpenSSL is not a problem > > oh that depends on the package. having nginx still use 1.0.2 for example is > not > good for more than just one reason. This opens an interresting question: How should a software detect OpenSSL and everything related (paths to include files, libraries, compliler flags, etc.)? We are not first humans who asked this question and ... voila ... some wise people developed pkg-config more than 20 years ago to solve this problem. Any random software have basically two ways how to get required information regarding other libraries they wish to use: either to use pkg-config (or something similar) or try to do the hard work on their own. Failures of the pkg-config way are extremely rare (guess why), but the "on their own" way failiures are common (guess why). And the only way how to make such failing software to build properly is to do some more manual work. What way uses nginx to build with OpenSSL? You can guess. Why they do so? I do not know. You can try to ask them. Maybe they didn't notice pkg-config yet, maybe they hate it for some reason, or maybe they just need somebody to do the work to use pkg-config. In any case, yes, we need to do some m
Re: [oi-dev] phasing out openssl 1.0.2 (mostly)
On Sun, Feb 25, 2024 at 02:36:29AM +0100, Goetz T. Fischer wrote: > yes, going with 3.0 is the best choice. but i guess that ship has sailed for > indiana already. No, it didn't. If there is a PR with OpenSSL 3.0 addition then it would get my full +1. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] phasing out openssl 1.0.2 (mostly)
> each program's code is concerned. if doing that by mediator causes too many > problems, using $(OPENSSL_INCDIR) and $(OPENSSL_LIBDIR) in the Makefile could > be an alternative for those programs/packages where that's sufficient. > having a peek at other repos shows that e.g. the solaris userland has sort of > a > compromise solution. they do set the ssl version explicitly. however, their > package names only contain the major version like "openssl-3" and the same > goes > for the install paths like "/usr/openssl/3/". that's not as flexible as > having > $(OPENSSL_INCDIR) and $(OPENSSL_LIBDIR) only or having it sorted by the > mediator but at least allows all 3.x versions without code changes. Please do not look at solaris-userland too much. We already diverged significantly so very often what you see in oi-userland or in solaris-userland makes no sense in the other project. > regardless of the mediator, selecting and updating the packages for which > $(OPENSSL_INCDIR) and $(OPENSSL_LIBDIR) is enough can be done anyaway. > > [1] slightly modified loki reference I hope this explained at least something regarding out build framework. Should you have more question, just ask. Regards. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Fri, Feb 23, 2024 at 01:02:52AM +0100, Marcel Telka wrote:
> On Tue, Feb 20, 2024 at 09:58:02AM +0100, Marcel Telka wrote:
> > the couchdb-31 package is broken at the ips server:
> >
> > Errors were encountered while attempting to retrieve package or file data
> > for
> > the requested operation.
> > Details follow:
> >
> > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z
> > Invalid content: manifest hash failure: fmri:
> > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z
> >
> > expected: 28185b5f27c3c0ce9ea1d8f129e0e5763f53e8ae computed:
> > b371cc90d6fd42c5bafa55f85afb183b59c23960. (happened 4 times)
>
> The problem is in the publisher/openindiana.org/catalog/catalog.base.C
> file. However I do not know what is the proper way to fix it.
> Maybe simple sed would be enough?
>
> sed -i -e \
>
> 's/28185b5f27c3c0ce9ea1d8f129e0e5763f53e8ae/b371cc90d6fd42c5bafa55f85afb183b59c23960/'
> \
> publisher/openindiana.org/catalog/catalog.base.C
No, sed it not the proper way to fix this, because the file seems to
contain a signature (see below).
I ran `pkgrepo rebuild -s REPO -p openindiana.org --no-index` and I
found that it:
* removed the publisher/openindiana.org/index directory (a bit
unexpected)
* removed all publisher/openindiana.org/catalog/update.* files
* modified publisher/openindiana.org/catalog/catalog.summary.C - with
mostly not very importand changes
* updated publisher/openindiana.org/catalog/catalog.attrs - because
other files in catalog changed/removed
* updated publisher/openindiana.org/catalog/catalog.base.C
and this revealed that there are six corrupted packages in the repo (the
list is below) and the corruption happened after 2023-10-11 21:22:16+.
Please note that luckily most corruptions are hidden because we do have
newer correct version of affecter packages in the repo, except
database/couchdb-31.
Here are differences between the old catalog.base.C and the new one:
$ diff -u <(jq < catalog.base.C-old) <(jq < catalog.base.C)
--- /dev/fd/63 2024-02-23 12:57:39.795696894 +0100
+++ /dev/fd/62 2024-02-23 12:57:39.795705684 +0100
@@ -66832,7 +66832,7 @@
],
"database/couchdb-31": [
{
-"signature-sha-1": "28185b5f27c3c0ce9ea1d8f129e0e5763f53e8ae",
+"signature-sha-1": "b371cc90d6fd42c5bafa55f85afb183b59c23960",
"version": "3.1.2,5.11-2023.0.0.0:20230609T222502Z"
}
],
@@ -121060,7 +121060,7 @@
],
"developer/golang-119": [
{
-"signature-sha-1": "a22c9e5526b28eeb356a019a170848dd9cff0028",
+"signature-sha-1": "84d0f3564243569662206ff01060c1d85a19060e",
"version": "1.19.13,5.11-2023.0.0.0:20230907T190550Z"
},
{
@@ -121070,7 +121070,7 @@
],
"developer/golang-120": [
{
-"signature-sha-1": "cefb854835a501b27a457630019ebc73cb3c099d",
+"signature-sha-1": "e3d9c336f4cb17b3e0a8ea59c8a2003c4eae6db1",
"version": "1.20.10,5.11-2023.0.0.0:20231011T212216Z"
},
{
@@ -121092,7 +121092,7 @@
],
"developer/golang-121": [
{
-"signature-sha-1": "08961188c8156f97513be69282778fce0dea5ecd",
+"signature-sha-1": "a19e750d1baa659c68c26e98ab65dcdad8990a15",
"version": "1.21.3,5.11-2023.0.0.0:20231011T212236Z"
},
{
@@ -212320,7 +212320,7 @@
],
"editor/codeblocks": [
{
-"signature-sha-1": "6ec033933597a8540df2a2948648736769fbf62a",
+"signature-sha-1": "292dbc04410f76a4722345133e6a71c5a5e77423",
"version": "20.3,5.11-2023.0.0.3:20230511T194351Z"
},
{
@@ -441060,7 +441060,7 @@
],
"library/readline": [
{
-"signature-sha-1": "cb02cbdaa6cda8a1ed1915185fe38015a6dce552",
+"signature-sha-1": "a159de951797140d09295c42401e58092f2c8fd9",
"version": "6.3,5.11-2023.0.0.5:20230906T050309Z"
},
{
@@ -747074,6 +747074,6 @@
]
},
"_SIGNATURE": {
-"sha-1": "d7273c3ee40be8cd541f8993658d7f0412648005"
+"sha-1": "5007481277faa15f0386f02ad58a7b3511ee50a9"
}
}
$
--
+---+
| Marcel Telka e-mail: mar...@telka.sk |
|homepage: http://telka.sk/ |
+---+
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Tue, Feb 20, 2024 at 09:58:02AM +0100, Marcel Telka wrote: > the couchdb-31 package is broken at the ips server: > > Errors were encountered while attempting to retrieve package or file data for > the requested operation. > Details follow: > > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > Invalid content: manifest hash failure: fmri: > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > > expected: 28185b5f27c3c0ce9ea1d8f129e0e5763f53e8ae computed: > b371cc90d6fd42c5bafa55f85afb183b59c23960. (happened 4 times) The problem is in the publisher/openindiana.org/catalog/catalog.base.C file. However I do not know what is the proper way to fix it. Maybe simple sed would be enough? sed -i -e \ 's/28185b5f27c3c0ce9ea1d8f129e0e5763f53e8ae/b371cc90d6fd42c5bafa55f85afb183b59c23960/' \ publisher/openindiana.org/catalog/catalog.base.C -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Thu, Feb 22, 2024 at 12:04:51AM +0100, Marcel Telka wrote: > It means that all files above are okay and the problem seems to be somewhere > else. It is a `pkgrepo verify` bug: https://www.illumos.org/issues/16317 -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Wed, Feb 21, 2024 at 08:27:20PM +0100, Marcel Telka wrote: > On Tue, Feb 20, 2024 at 09:54:27PM +0100, Marcel Telka wrote: > > The proper command is `pkgrepo verify -s $PATHTOREPO` (i.e. without > > ending publisher/openindiana.org). > > I'm running the `pkgrepo verify` on my local copy of the (official) ips repo > and so far I found this: > >ERROR: Invalid file hash: > cf6524e84f049ec7cb31c4c92a7fa26ca75c96be8e157fbfc974bc7bfa2f99a1 > Package: > pkg://openindiana.org/library/mozjs-60@60.8.0,5.11-2022.0.0.0:20220201T120214Z > Repository path: > /data/openindiana-hipster/publisher/openindiana.org/file/07/07ef492f49d4c8c1bea8b3e0866fee55f55577f6 >Computed hash: > 7d5235341152834147cf4f1ab9faff37ea87a69b073fbc05fda67cc3b8cd0510 > Path: usr/lib/amd64/libjs_static.ajs > > > pkg://openindiana.org/library/mozjs-60 > 61864/177684 - >ERROR: Invalid file hash: > fbad1dc5c42245c1b5f2e98f245d71e805e4831433fd9e67328f95ef5ee05b57 > Package: > pkg://openindiana.org/library/mozjs-60@60.8.0,5.11-2024.0.0.2:20240214T134119Z > Repository path: > /data/openindiana-hipster/publisher/openindiana.org/file/70/705f771bc438735598ad0fe6392de3eda4e1154a >Computed hash: > bde010709020fe01decf06ca9603bf18e6cbae7b4a814f34fa16d4e24fe56e91 > Path: usr/lib/amd64/libjs_static.ajs > > > pkg://openindiana.org/library/mozjs-60 > 61865/177684 \ >ERROR: Invalid file hash: > bfb4acb866f48aefe6c93a3ebe4f9ae97637a5e740693f31fe5904c1e2b64583 > Package: > pkg://openindiana.org/library/mozjs-60@60.8.0,5.11-2023.0.0.1:20231103T152741Z > Repository path: > /data/openindiana-hipster/publisher/openindiana.org/file/b2/b2f40c59259c4ad119f4d01af675d5c63bf2fea6 >Computed hash: > f59c371196e96a5c9b69e483a521068f7165d1bc2cd72c530c1789988ab02b04 > Path: usr/lib/amd64/libjs_static.ajs > > > pkg://openindiana.org/library/mozjs-60 > 61866/177684 | >ERROR: Invalid file hash: > bfb4acb866f48aefe6c93a3ebe4f9ae97637a5e740693f31fe5904c1e2b64583 > Package: > pkg://openindiana.org/library/mozjs-60@60.8.0,5.11-2023.0.0.1:20231103T151901Z > Repository path: > /data/openindiana-hipster/publisher/openindiana.org/file/b2/b2f40c59259c4ad119f4d01af675d5c63bf2fea6 >Computed hash: > f59c371196e96a5c9b69e483a521068f7165d1bc2cd72c530c1789988ab02b04 > Path: usr/lib/amd64/libjs_static.ajs > > > And yes, those files seems to be corrupted in the repo, for example: > > $ sha1sum > /data/openindiana-hipster/publisher/openindiana.org/file/70/705f771bc438735598ad0fe6392de3eda4e1154a > 33471d5fa1a25ab740a84c720f5875147ee1c42d > /data/openindiana-hipster/publisher/openindiana.org/file/70/705f771bc438735598ad0fe6392de3eda4e1154a > $ > > While the installed file is correct: > > $ sha1sum /usr/lib/amd64/libjs_static.ajs > 705f771bc438735598ad0fe6392de3eda4e1154a /usr/lib/amd64/libjs_static.ajs > $ I need to correct myself. Those files are stored gzipped, so they should be checked like this: $ gzcat /data/openindiana-hipster/publisher/openindiana.org/file/70/7a6b63ecd35872b258d8a0852aede43d94e3 | sha1sum 7a6b63ecd35872b258d8a0852aede43d94e3 - $ It means that all files above are okay and the problem seems to be somewhere else. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Tue, Feb 20, 2024 at 09:54:27PM +0100, Marcel Telka wrote: > The proper command is `pkgrepo verify -s $PATHTOREPO` (i.e. without > ending publisher/openindiana.org). I'm running the `pkgrepo verify` on my local copy of the (official) ips repo and so far I found this: ERROR: Invalid file hash: cf6524e84f049ec7cb31c4c92a7fa26ca75c96be8e157fbfc974bc7bfa2f99a1 Package: pkg://openindiana.org/library/mozjs-60@60.8.0,5.11-2022.0.0.0:20220201T120214Z Repository path: /data/openindiana-hipster/publisher/openindiana.org/file/07/07ef492f49d4c8c1bea8b3e0866fee55f55577f6 Computed hash: 7d5235341152834147cf4f1ab9faff37ea87a69b073fbc05fda67cc3b8cd0510 Path: usr/lib/amd64/libjs_static.ajs pkg://openindiana.org/library/mozjs-6061864/177684 - ERROR: Invalid file hash: fbad1dc5c42245c1b5f2e98f245d71e805e4831433fd9e67328f95ef5ee05b57 Package: pkg://openindiana.org/library/mozjs-60@60.8.0,5.11-2024.0.0.2:20240214T134119Z Repository path: /data/openindiana-hipster/publisher/openindiana.org/file/70/705f771bc438735598ad0fe6392de3eda4e1154a Computed hash: bde010709020fe01decf06ca9603bf18e6cbae7b4a814f34fa16d4e24fe56e91 Path: usr/lib/amd64/libjs_static.ajs pkg://openindiana.org/library/mozjs-6061865/177684 \ ERROR: Invalid file hash: bfb4acb866f48aefe6c93a3ebe4f9ae97637a5e740693f31fe5904c1e2b64583 Package: pkg://openindiana.org/library/mozjs-60@60.8.0,5.11-2023.0.0.1:20231103T152741Z Repository path: /data/openindiana-hipster/publisher/openindiana.org/file/b2/b2f40c59259c4ad119f4d01af675d5c63bf2fea6 Computed hash: f59c371196e96a5c9b69e483a521068f7165d1bc2cd72c530c1789988ab02b04 Path: usr/lib/amd64/libjs_static.ajs pkg://openindiana.org/library/mozjs-6061866/177684 | ERROR: Invalid file hash: bfb4acb866f48aefe6c93a3ebe4f9ae97637a5e740693f31fe5904c1e2b64583 Package: pkg://openindiana.org/library/mozjs-60@60.8.0,5.11-2023.0.0.1:20231103T151901Z Repository path: /data/openindiana-hipster/publisher/openindiana.org/file/b2/b2f40c59259c4ad119f4d01af675d5c63bf2fea6 Computed hash: f59c371196e96a5c9b69e483a521068f7165d1bc2cd72c530c1789988ab02b04 Path: usr/lib/amd64/libjs_static.ajs And yes, those files seems to be corrupted in the repo, for example: $ sha1sum /data/openindiana-hipster/publisher/openindiana.org/file/70/705f771bc438735598ad0fe6392de3eda4e1154a 33471d5fa1a25ab740a84c720f5875147ee1c42d /data/openindiana-hipster/publisher/openindiana.org/file/70/705f771bc438735598ad0fe6392de3eda4e1154a $ While the installed file is correct: $ sha1sum /usr/lib/amd64/libjs_static.ajs 705f771bc438735598ad0fe6392de3eda4e1154a /usr/lib/amd64/libjs_static.ajs $ Andreas please recover above three corrupted files from backup. Thank you. PS: Please note the verify progress is very slow here. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Tue, Feb 20, 2024 at 09:28:50PM +0100, Marcel Telka wrote: > On Tue, Feb 20, 2024 at 09:19:24PM +0100, Marcel Telka wrote: > > On Tue, Feb 20, 2024 at 09:06:53PM +0100, Andreas Wacknitz via oi-dev wrote: > > > Am 20.02.24 um 20:52 schrieb Bill Sommerfeld via oi-dev: > > > > On 2/20/24 11:27, Andreas Wacknitz via oi-dev wrote: > > > > > Am 20.02.24 um 18:49 schrieb Marcel Telka: > > > > > > BTW, the issue above should be fixable by replacing a file (or two, > > > > > > or > > > > > > so) from the backup. > > > > > > > > > > > I have tried pkgrecv but it skipped the couchdb-31 package because > > > > > it's > > > > > already there. > > > > > How can I find the necessary files to copy over? > > > > > > > > Start with the manifest file itself - that's what I believe it's > > > > failing the checksum for. > > > > > > > > Look inside the repo directory, in: > > > > > > > > publisher/openindiana.org/pkg/database%2Fcouchdb-31 > > > > > > > > For > > > > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > > > > > > > > there should be a file in that directory named > > > > > > > > 3.1.2%2C5.11-2023.0.0.0%3A20230609T222502Z > > > > > > > > that contains the package manifest. > > > > > > > > Once a manifest file is in place that has the right checksum it may or > > > > may not complain about other missing files. > > > I have checked both manfests (actual and old repo). They don't differ > > > and seem to be complete and thus should be correct. > > > > Then some suggestions: > > pkgrepo verify > > Unfortunately, the verify will likely fail with the following error :-(: > > # pkgrepo verify -s $PATHTOREPO/publisher/openindiana.org/ > Initiating repository verification. > pkgrepo: The repository at '$PATHTOREPO/publisher/openindiana.org' is version > '3'; only version 4 repositories are supported. > # > > But maybe there is older pkgrepo command on the server supporting ver 3? The proper command is `pkgrepo verify -s $PATHTOREPO` (i.e. without ending publisher/openindiana.org). -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Tue, Feb 20, 2024 at 09:29:09PM +0100, Andreas Wacknitz via oi-dev wrote: > Am 20.02.24 um 21:21 schrieb Bill Sommerfeld via oi-dev: > > On 2/20/24 12:06, Andreas Wacknitz via oi-dev wrote: > > > Am 20.02.24 um 20:52 schrieb Bill Sommerfeld via oi-dev: > > > > On 2/20/24 11:27, Andreas Wacknitz via oi-dev wrote: > > > > > Am 20.02.24 um 18:49 schrieb Marcel Telka: > > > > > > BTW, the issue above should be fixable by replacing a file (or > > > > > > two, or > > > > > > so) from the backup. > > > > > > > > > > > I have tried pkgrecv but it skipped the couchdb-31 package because > > > > > it's > > > > > already there. > > > > > How can I find the necessary files to copy over? > > > > > > > > Start with the manifest file itself - that's what I believe it's > > > > failing the checksum for. > > > > > > > > Look inside the repo directory, in: > > > > > > > > publisher/openindiana.org/pkg/database%2Fcouchdb-31 > > > > > > > > For > > > > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > > > > > > > > > > > > there should be a file in that directory named > > > > > > > > 3.1.2%2C5.11-2023.0.0.0%3A20230609T222502Z > > > > > > > > that contains the package manifest. > > > > > > > > Once a manifest file is in place that has the right checksum it may or > > > > may not complain about other missing files. > > > I have checked both manfests (actual and old repo). They don't differ > > > and seem to be complete and thus should be correct. > > > > Then maybe the hash for the manifest file in the repo's catalog is > > wrong. Not sure what the best way to correct it is, though. > > > > Perhaps removing the broken package from the repo with pkgrepo remove > > and then using pkgrecv to restore it it in from the old repo? > Removing packages from the repo is a little bit tedious as the repo is > served on an old zone and remove is not supported by its pkgrepo. > So I have to copy several GB to another system, remove the package > there, and copy everything back. I suspect this operation corrupts the repo. It is not the first time. Similar corruptions happens regularly :-(. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Tue, Feb 20, 2024 at 09:19:24PM +0100, Marcel Telka wrote: > On Tue, Feb 20, 2024 at 09:06:53PM +0100, Andreas Wacknitz via oi-dev wrote: > > Am 20.02.24 um 20:52 schrieb Bill Sommerfeld via oi-dev: > > > On 2/20/24 11:27, Andreas Wacknitz via oi-dev wrote: > > > > Am 20.02.24 um 18:49 schrieb Marcel Telka: > > > > > BTW, the issue above should be fixable by replacing a file (or two, or > > > > > so) from the backup. > > > > > > > > > I have tried pkgrecv but it skipped the couchdb-31 package because it's > > > > already there. > > > > How can I find the necessary files to copy over? > > > > > > Start with the manifest file itself - that's what I believe it's > > > failing the checksum for. > > > > > > Look inside the repo directory, in: > > > > > > publisher/openindiana.org/pkg/database%2Fcouchdb-31 > > > > > > For > > > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > > > > > > there should be a file in that directory named > > > > > > 3.1.2%2C5.11-2023.0.0.0%3A20230609T222502Z > > > > > > that contains the package manifest. > > > > > > Once a manifest file is in place that has the right checksum it may or > > > may not complain about other missing files. > > I have checked both manfests (actual and old repo). They don't differ > > and seem to be complete and thus should be correct. > > Then some suggestions: > pkgrepo verify Unfortunately, the verify will likely fail with the following error :-(: # pkgrepo verify -s $PATHTOREPO/publisher/openindiana.org/ Initiating repository verification. pkgrepo: The repository at '$PATHTOREPO/publisher/openindiana.org' is version '3'; only version 4 repositories are supported. # But maybe there is older pkgrepo command on the server supporting ver 3? -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Tue, Feb 20, 2024 at 09:06:53PM +0100, Andreas Wacknitz via oi-dev wrote: > Am 20.02.24 um 20:52 schrieb Bill Sommerfeld via oi-dev: > > On 2/20/24 11:27, Andreas Wacknitz via oi-dev wrote: > > > Am 20.02.24 um 18:49 schrieb Marcel Telka: > > > > BTW, the issue above should be fixable by replacing a file (or two, or > > > > so) from the backup. > > > > > > > I have tried pkgrecv but it skipped the couchdb-31 package because it's > > > already there. > > > How can I find the necessary files to copy over? > > > > Start with the manifest file itself - that's what I believe it's > > failing the checksum for. > > > > Look inside the repo directory, in: > > > > publisher/openindiana.org/pkg/database%2Fcouchdb-31 > > > > For > > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > > > > there should be a file in that directory named > > > > 3.1.2%2C5.11-2023.0.0.0%3A20230609T222502Z > > > > that contains the package manifest. > > > > Once a manifest file is in place that has the right checksum it may or > > may not complain about other missing files. > I have checked both manfests (actual and old repo). They don't differ > and seem to be complete and thus should be correct. Then some suggestions: pkgrepo verify pkgrepo fix pkgrepo rebuild -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] couchdb-31 is broken
On Tue, Feb 20, 2024 at 09:31:03AM -0800, Bill Sommerfeld via oi-dev wrote: > On 2/20/24 00:58, Marcel Telka wrote: > > the couchdb-31 package is broken at the ips server: > > > > Errors were encountered while attempting to retrieve package or file data > > for > > the requested operation. > > Details follow: > > > > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > >Invalid content: manifest hash failure: fmri: > > pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z > > expected: 28185b5f27c3c0ce9ea1d8f129e0e5763f53e8ae computed: > > b371cc90d6fd42c5bafa55f85afb183b59c23960. (happened 4 times) > > > > I tried rebuilding but it fails because our Erlang is too new: > > ==> config (compile) > ERROR: OTP release 24 does not match required regex 19|20|21|22 > ERROR: compile failed while processing > /z/ws/oi-userland-alt/components/database/couchdb-31/build/amd64/src/config: > rebar_abort > make: *** [Makefile:125: couch] Error 1 > gmake: *** [/z/ws/oi-userland-alt/make-rules/justmake.mk:62: > /z/ws/oi-userland-alt/components/database/couchdb-31/build/amd64/.built] > Error 2 We apparently need newer couchdb, since couchdb 3.1 is no longer supported. OTOH, we do not have any consumer for couchdb-31 in OI so we could simply just obsolete it and do not bother packaging newer one. BTW, the issue above should be fixable by replacing a file (or two, or so) from the backup. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] couchdb-31 is broken
Hi, the couchdb-31 package is broken at the ips server: Errors were encountered while attempting to retrieve package or file data for the requested operation. Details follow: pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z Invalid content: manifest hash failure: fmri: pkg://openindiana.org/database/couchdb-31@3.1.2,5.11-2023.0.0.0:20230609T222502Z expected: 28185b5f27c3c0ce9ea1d8f129e0e5763f53e8ae computed: b371cc90d6fd42c5bafa55f85afb183b59c23960. (happened 4 times) -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SIMD support
On Thu, Feb 15, 2024 at 05:09:12PM +0100, Marcel Telka wrote: > On Thu, Feb 15, 2024 at 06:01:16PM +0200, Toomas Soome via oi-dev wrote: > > > > > > > On 15. Feb 2024, at 17:47, Marcel Telka wrote: > > > > > > Hi, > > > > > > There[1] is this comment: > > > > > > # We cannot build sbcl on our build server because it lacks SIMD support. > > > > > > > > > How can I check a machine does have SIMD support? > > > > > > > > > Thank you. > > > > > > > $ isainfo -v > > 64-bit amd64 applications > > fsgsbase rdseed adx avx2 fma bmi2 bmi1 rdrand f16c vmx avx xsave > > pclmulqdq aes movbe sse4.2 sse4.1 ssse3 amd_lzcnt popcnt tscp cx16 > > sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu > > 32-bit i386 applications > > rdseed adx avx2 fma bmi2 bmi1 rdrand f16c vmx avx xsave pclmulqdq > > aes movbe sse4.2 sse4.1 ssse3 amd_lzcnt popcnt tscp ahf cx16 sse3 > > sse2 sse fxsr mmx cmov sep cx8 tsc fpu > > There is no 'simd' in your output. Does it mean you do not have simd > support? The initial comment I was referring to is misleading. It should say AVX2 instead of SIMD. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SIMD support
On Thu, Feb 15, 2024 at 06:01:16PM +0200, Toomas Soome via oi-dev wrote: > > > > On 15. Feb 2024, at 17:47, Marcel Telka wrote: > > > > Hi, > > > > There[1] is this comment: > > > > # We cannot build sbcl on our build server because it lacks SIMD support. > > > > > > How can I check a machine does have SIMD support? > > > > > > Thank you. > > > > $ isainfo -v > 64-bit amd64 applications > fsgsbase rdseed adx avx2 fma bmi2 bmi1 rdrand f16c vmx avx xsave > pclmulqdq aes movbe sse4.2 sse4.1 ssse3 amd_lzcnt popcnt tscp cx16 > sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu > 32-bit i386 applications > rdseed adx avx2 fma bmi2 bmi1 rdrand f16c vmx avx xsave pclmulqdq > aes movbe sse4.2 sse4.1 ssse3 amd_lzcnt popcnt tscp ahf cx16 sse3 > sse2 sse fxsr mmx cmov sep cx8 tsc fpu There is no 'simd' in your output. Does it mean you do not have simd support? -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] SIMD support
Hi, There[1] is this comment: # We cannot build sbcl on our build server because it lacks SIMD support. How can I check a machine does have SIMD support? Thank you. [1] https://github.com/OpenIndiana/oi-userland/blob/dbaa9a28b594d970f75d4ab50bf0a70a8006427a/components/components.ignore#L31 -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Library load error in package perl-5/tk
On Tue, Feb 13, 2024 at 03:20:54PM +0100, Udo Grabowski (IMK) wrote:
> should be
>
> # This is a workround for Solaris X11 locale handling
> Preload(DynaLoader::dl_findfile('-L/usr/openwin/lib/64','-lX11'))
> if (NeedPreload() && -d '/usr/openwin/lib/64');
New package with the fix should be available soon:
https://github.com/OpenIndiana/oi-userland/pull/16113
See also:
https://github.com/eserte/perl-tk/issues/99
--
+-------+
| Marcel Telka e-mail: mar...@telka.sk |
|homepage: http://telka.sk/ |
+---+
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Library load error in package perl-5/tk
On Tue, Feb 13, 2024 at 03:20:54PM +0100, Udo Grabowski (IMK) wrote:
> # This is a workround for Solaris X11 locale handling
> Preload(DynaLoader::dl_findfile('-L/usr/openwin/lib/64','-lX11'))
> if (NeedPreload() && -d '/usr/openwin/lib/64');
The comment says it is a workaround. Any idea it is still needed?
> otherwise it tries to load the 32bit libX11.so library, which fails.
Thank you for report.
--
+-------+
| Marcel Telka e-mail: mar...@telka.sk |
|homepage: http://telka.sk/ |
+---+
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Heads-Up: Obsoletion of 39 old packages
On Thu, Jan 18, 2024 at 06:06:20PM +0100, Marcel Telka wrote: > On Tue, Jan 09, 2024 at 04:24:42PM +0100, Marcel Telka wrote: > > I propose obsoletion of following 39 OpenIndiana packages: > > I'm happy to let you know that the list now contains 38 entries only. Matthew R. Trower packaged text/dwdiff so the list is down to 37 entries only. $ pkg list -afv text/dwdiff FMRI IFO pkg://openindiana.org/text/dwdiff@2.1.4-2024.0.0.0:20240201T182637Z i-- pkg://openindiana.org/text/dwdiff@1.5.2-2013.0.0.0:20151027T080702Z --- $ Thank you, Matthew. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [OpenIndiana-discuss] Heads-up: Python 3.7 reached EOL, please uninstall it
On Mon, Jan 29, 2024 at 06:53:39PM +, Apostolos Syropoulos via openindiana-discuss wrote: > I have entered the command mentioned in your message and here is what I get: > # pkg uninstall -v runtime/python-37 'library/python/*-37' > web/server/apache-24/module/apache-wsgi-37 > > pkg uninstall: 'web/server/apache-24/module/apache-wsgi-37' matches no > installed packages > # pkg uninstall -v runtime/python-37 'library/python/*-37' > Creating Plan (Solver setup): \ > pkg uninstall: Unable to remove 'runtime/python-37@3.7.16-2023.0.0.2' due to > the following packages that depend on it: > developer/dtrace/toolkit@0.99-2022.0.0.6 Your system is apparently not up-to-date. There is already developer/dtrace/toolkit@0.99-2023.0.0.7 that does not depend on runtime/python-37. So to solve, just update. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Heads-up: Python 3.7 reached EOL, please uninstall it
Hi, Python 3.7 reached end of life[1] in June 2023 (7 months ago). Currently there is no OpenIndiana package that depends on Python 3.7, except some Python modules that are otherwise unused. They are still sitting in the IPS package repository waiting for their obsoletion. We are slowly obsoleting them but since there are hundreds of such packages the process is slow. The slowness of the process does have some negative side effects for end users so here is the heads up and a suggestion how to solve such issues. The issue you could encounter is a failure when you try to install or upgrade some packages, for example: # pkg install library/python/rbtools Creating Plan (Running solver): - pkg install: No matching version of library/python/rbtools can be installed: Reject: pkg://openindiana.org/library/python/rbtools@4.1-2023.0.0.0:20230525T122724Z Reason: No version matching 'conditional' dependency library/python/rbtools-37@4.1-2023.0.0.0 can be installed Reject: pkg://openindiana.org/library/python/rbtools-37@4.1-2023.0.0.0:20230525T122701Z Reason: All acceptable versions of 'require' dependency on library/python/certifi-37 are obsolete # Please note that not only library/python/* packages are affected. Basically any package that depends on any Python-related package could be affected similarly. When you see similar failure stating that some package ending with '-37' cannot be installed, then you are affected by this. How to solve the issue? The solution is easy: Uninstall all Python 3.7 related packages from your system using command like: # pkg uninstall -v runtime/python-37 \ 'library/python/*-37' \ web/server/apache-24/module/apache-wsgi-37 The removal of Python 3.7 packages is recommended even if you currently do not see any issue related to Python 3.7. Please ask if you are experiencing any unforeseen issue related to this. Thank you. [1] see https://devguide.python.org/versions/#versions -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] create/use physical ethernet interface BCMS7416
On Mon, Jan 22, 2024 at 02:24:56PM +, Klaus Elsbernd wrote: > I got a supermicro with an BCMS7416 Ethernet Interface (10GB), which isn't > reorganized immediately. prtconf -v shows this device as an > Ethernet-controller: "BCS7416 NetXtreme-E Dual-Media 10G RDMA Ethernet > Controller' > > Is there any sequence of commands to use this interface? https://www.illumos.org/issues/13306 -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Heads-Up: Obsoletion of 39 old packages
On Tue, Jan 09, 2024 at 04:24:42PM +0100, Marcel Telka wrote: > I propose obsoletion of following 39 OpenIndiana packages: I'm happy to let you know that the list now contains 38 entries only. The media/mtx package is no longer on the list thanks to Carsten Grzemba and his work here: https://github.com/OpenIndiana/oi-userland/pull/15685 $ pkg list -afv media/mtx FMRI IFO pkg://openindiana.org/media/mtx@1.3.12-2024.0.0.0:20240118T153158Z i-- pkg://openindiana.org/media/mtx@1.3.11-2013.0.0.0:20151027T071736Z --- $ Thank you, Carsten. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] package mtx
On Wed, Jan 10, 2024 at 06:57:01PM +0100, Carsten Grzemba via oi-dev wrote: > I want to provide an updated build recipe of the tool mtx, where ever the > former package was come from. > I am wondering if the current FMRI > > > media/mtx > > is a name which we should kept. Or is > > system/storage/mtx > > a better choice? Or keep it simple and leave everything as it is. Chose whatever fmri you want. Since no other package in OpenIndiana depends on it the actual fmri does not matter much. If it will differ from media/mtx, then you'll just need to create a history file with the package rename rule. Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Heads-Up: Obsoletion of 39 old packages
On Tue, Jan 09, 2024 at 09:14:39AM -0800, Alan Coopersmith wrote: > https://lore.kernel.org/distributions/1ea25603-171c-062e-bc02-bcdfc3acd...@oracle.com/T/#u > is the advice I gave distros last year on unmaintained packages from X.Org. This is great info. It will allow us to start to work on obsoletion of few more packages, for example x11/library/libxevie. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Heads-Up: Obsoletion of 39 old packages
On Tue, Jan 09, 2024 at 08:41:14AM -0800, Alan Coopersmith wrote: > On 1/9/24 07:24, Marcel Telka wrote: > > All of them are: > > - very old - they are more than 10 years old > > - not maintained - we have no knowledge how to build them (there are no > >build recipes for them in oi-userland) > > A fair number of them are actually impossible for you to maintain as we > never released the sources for them (things like the Solaris CDE & Motif > packages), and are likely just repackaging of the redistributable binaries > from OpenSolaris, complete with the bugs and security holes they had back > in 2010. > > A few are open source - for instance, I could point you to the sources for > x11/network/x11-network-proxies - but no one uses that in a world where > ssh X11-Forwarding is prevalent, which is why I removed that package from > Solaris and declared the upstream sources unmaintained and suggested that > distros remove them. Thanks for insights. This caused I looked closer at x11/network/rstart which is still required by mate_install and I noticed it is deprecated too, so I created https://github.com/OpenIndiana/oi-userland/pull/15571 . -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Heads-Up: Obsoletion of 39 old packages
Hi, I propose obsoletion of following 39 OpenIndiana packages: pkg://openindiana.org/benchmark/iozone@3.323-2013.0.0.0 pkg://openindiana.org/cde/calendar-manager-server@0.5.11-2013.0.0.0 pkg://openindiana.org/cde/cde-runtime@0.5.11-2013.0.0.0 pkg://openindiana.org/cde/cde-utilities@0.5.11-2013.0.0.0 pkg://openindiana.org/cde/help-viewer@0.5.11-2013.0.0.0 pkg://openindiana.org/consolidation/dbtg/dbtg-incorporation@0.5.11-2013.0.0.0 pkg://openindiana.org/consolidation/jdmk/jdmk-incorporation@0.5.11-2013.0.0.0 pkg://openindiana.org/editor/jedit@4.3-2013.0.0.0 pkg://openindiana.org/library/java/activation@1.1.1-2013.0.0.0 pkg://openindiana.org/library/java/commons-collections@3.2.1-2013.0.0.0 pkg://openindiana.org/library/java/javadb@10.6.2.1-2013.0.0.0 pkg://openindiana.org/library/java/javamail@1.4.1-2013.0.0.0 pkg://openindiana.org/library/java/jdmk-runtime@0.5.11-2013.0.0.0 pkg://openindiana.org/library/java/jrexx@1.1.1-2013.0.0.0 pkg://openindiana.org/library/java/qdox@1.9-2013.0.0.0 pkg://openindiana.org/library/java/saaj@1.3.2-2013.0.0.0 pkg://openindiana.org/library/java/trove@2.0.4-2013.0.0.0 pkg://openindiana.org/library/libosip2@3.3.0-2013.0.0.0 pkg://openindiana.org/library/medialib@0.5.11-2013.0.0.0 pkg://openindiana.org/library/motif/libdpstkxm@0.5.11-2013.0.0.0 pkg://openindiana.org/library/tooltalk@0.5.11-2013.0.0.0 pkg://openindiana.org/media/mtx@1.3.11-2013.0.0.0 pkg://openindiana.org/service/network/load-balancer/pen@0.18.0-2013.0.0.0 pkg://openindiana.org/system/kernel/hardware-cursor@0.5.11-2013.0.0.0 pkg://openindiana.org/system/library/iconv/utf-8/manual@0.5.11-2013.0.0.0 pkg://openindiana.org/system/library/liblayout@0.5.11-2013.0.0.0 pkg://openindiana.org/system/locale/support/belarusian@0.1-2013.0.0.0 pkg://openindiana.org/system/locale/support/english@0.1-2013.0.0.0 pkg://openindiana.org/system/locale/support/sanskrit@0.1-2013.0.0.0 pkg://openindiana.org/system/storage/vdiskadm@0.5.11-2013.0.0.0 pkg://openindiana.org/system/test/sunvts@0.5.11-2013.0.0.0 pkg://openindiana.org/system/test/sunvts/manual@0.5.11-2013.0.0.0 pkg://openindiana.org/terminal/conman@0.2.4.1-2013.0.0.0 pkg://openindiana.org/terminal/roxterm@1.18.5-2013.0.0.0 pkg://openindiana.org/text/auto_ef@0.5.11-2013.0.0.0 pkg://openindiana.org/text/dwdiff@1.5.2-2013.0.0.0 pkg://openindiana.org/x11/library/dps@7.5-2013.0.0.0 pkg://openindiana.org/x11/library/libowconfig@0.5.11-2013.0.0.0 pkg://openindiana.org/x11/network/x11-network-proxies@7.5-2013.0.0.0 All of them are: - very old - they are more than 10 years old - not maintained - we have no knowledge how to build them (there are no build recipes for them in oi-userland) - not needed - nothing in OpenIndiana depends on them If you have a machine where any of them are installed I suggest to uninstall them ASAP to see if their absence affects you somehow. If I hear nothing in next few weeks I'll create a PR with obsoletion of these packages. Any questions? Thanks. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] OI 2023.10 release notes (Python and Perl)
Hi, I just opened the OpenIndiana Release 2023.10 announcement[1] and I found the following paragraph there: -- Python packages are now imported into the package manager by script and usually very up to date. Generally if you need to install a python based app, then the package manager offers the latest versions. If you need specific versions try to use the C bindings from the openindiana.org repos and only install pure python software via pip and virtualenvs. There are plans to make this happen for ruby and perl as well. -- I've no idea who wrote that but the first and last sentences there are misleading. Python packages are not imported into the package manager by script. Scripts are used just to check if there are new versions available and to prepare changesets with the package update (or rebuild). Everything beyond that is just a manual work: the changeset check for correctness and completeness is done manually, the PR submission is done manually, and the PR merge is done manually as well. Also, if automatic changeset creation fails then manual work is needed to get the integration fixed. Roughly half of new Python PRs needs this. Because of that we are not fully up-to-date with Python and its related packages yet. The other misleading in the announcement is a claim that there are plans to do the same for Perl. No, there are no such plans and never will be. Why? Because it makes no sense to plan something that is already done. :-) Since summer 2022 (yes, for more than a year now) everything related to Perl in OpenIndiana is always[2] up to date. The rate of failed automatic integrations[3] is far less for Perl than for Python. Actually, such failures are rare. Any questions? Regards. PS: If you are interested to help in this area then you are very welcome. Just let me know. Especially Python developers and testers are needed to help with some annoying bugs in upstream Python projects, but not only that. Thank you. [1] https://www.openindiana.org/announcements/openindiana-hipster-2023-10-announcement/ [2] all updates for CPAN modules or Perl itself are in almost all cases published to our IPS repo in less than 48 hours after they are released. [3] automatic changeset creations -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] newbie help needed build errors pkg nut
On Fri, Nov 10, 2023 at 09:10:06AM +0100, Stephan Althaus wrote: > #pkg install -nv nut > > I get an error: > > . pkg install: The following packages all deliver driver actions to ugen: > . > . > pkg://openindiana.org/system/management/nut/drivers/usb@2.8.1,5.11-2023.0.0.0:20231109T161519Z > . > pkg://openindiana.org/driver/usb/ugen@0.5.11,5.11-2023.0.0.21867:20231110T011306Z > . > . These packages cannot be installed together. Any non-conflicting subset > . of the above packages can be installed. This is known issue: https://github.com/OpenIndiana/oi-userland/pull/14630#issuecomment-180306 > -> can ugen be uninstalled savely ? No idea. I recommend to wait until the problem is solved. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] newbie help needed build errors pkg nut
On Wed, Nov 08, 2023 at 02:55:01PM +0100, Stephan Althaus wrote: > So i decided to update the package to 2.8.5. After patching the Makefile > with version and SHA, deleting the 'old' patches which are not working > anymore (maybe obsolete by now), > configure fails because neon lib is not found Maybe this will solve your problem (should be integrated soon): https://github.com/OpenIndiana/oi-userland/pull/14630 -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Perl DBD::mysql will be obsoleted soon, use DBD::MariaDB
Hi all, After 10 years of DBD::mysql Perl module available in OpenIndiana we need to obsolete it. If you need similar functionality you should switch to DBD::MariaDB. The DBD::MariaDB Perl module is available in the library/perl-5/dbd-mariadb package. Starting with version 5.001 of DBD::mysql released on 2023-10-04 it is no longer possible to build it on OpenIndiana because MySQL 8.x is required for building. We do not have MySQL packaged for OpenIndiana. If DBD::mysql is a must for you and you cannot switch to DBD::MariaDB then you should contribute and package MySQL for OpenIndiana. Regards. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] rebuilding system/xvm/xvmstore ?
On Thu, Oct 19, 2023 at 01:27:31PM -0500, Tim Mooney via oi-dev wrote: > Both my workstation and my Virtualbox OI build box have > system/xvm/xvmstore installed, I think because it's listed as part > of the 'server_desktop_amd64' meta package. Just FYI, system/xvm/xvmstore is needed by following packages (this is complete list): system/xvm/ipagent mate_install server_install > > From what I can tell, system/xvm/xvmstore hasn't been rebuilt since 2013, > and I haven't been able to find the component for it in oi-userland. It > doesn't appear to contain any metadata for Illumos either, so I don't > think it comes from illumos-gate. It does not. > xvmstore is the only thing on my system that depends upon > system/library/gcc-3-runtime. > > I would be willing to do the work to trigger a rebuild against a newer > GCC runtime, if someone could clue me in on where the actual component is. We do not have a recipe for this component in oi-userland. So it needs to be created from scratch (or the package should be obsoleted if we no longer need it). HTH. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] dlc.openindiana.org is down
On Sun, Oct 15, 2023 at 05:34:04PM +0200, Till Wegmueller wrote: > It's back up and probably has been since the 11th. Yes, it is. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] dlc.openindiana.org is down
Hi, The download server dlc.openindiana.org seems to be down. Please fix it. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Purpose of PACKAGE_NAMES
On Fri, Sep 29, 2023 at 02:13:42PM +0200, Aurélien Larcher wrote: > On Fri, Sep 29, 2023 at 10:15 AM Marcel Telka wrote: > > > Hi, > > > > I noticed there are PACKAGE_NAMES macros set for few components in the > > oi-userland git repo. Namely here: > > > > components/meta-packages/history/Makefile > > components/openindiana/gfx-drm/Makefile > > components/openindiana/pkg/Makefile > > components/openindiana/slim_source/Makefile > > > > They were added in October 2018 by following commits: > > > > c7b5e23fc94 > > 2e3897664af > > ac1196a7cb0 > > a4bb6ce259f > > > > I'm curious what is the purpose of these macros. As far as I know there > > is no known consumer for them. They looks like some attempt to list > > packages generated by a component before we had support for pkg5 files > > (introduced in 2020). > > > > If PACKAGE_NAMES are unused then I plan to simply remove them once I > > touch those Makefiles. > > > > If I remember correctily they were introduced to produce package names used > in dependency resolution in the external python scripts, for components > that generate packages internally and then copy them rather than the usual > procedure. Okay, thanks. I translate the above as: yes, PACKAGE_NAMES was a predecessor of pkg5. > The goal was to trigger rebuild of dependencies based on this information > and avoid publication of broken repositories e.g. when ABI is broken and > the update is split in several PRs due to our flawed CI. If I'm not mistaken the same could be done using the (modern) pkg5 files. > Without these definitions print-package-names would produce an incomplete > list of packages provided by the component and the graph will have dangling > dependencies. I just tried `gmake publish` and then `gmake print-package-names` in openindiana/pkg and this is the result: Makefile:45: warning: overriding recipe for target 'update' /data/builds/ul-workspace/make-rules/component.mk:49: warning: ignoring old recipe for target 'update' package-names= (origin: undefined, flavor: undefined) So PACKAGE_NAMES is useless there these days. Also, `gmake update-metadata` in openindiana/pkg does strange things, so apparently there is something else broken. Anyway, if `gmake update-metadata` is able to work for openindiana/illumos-gate without PACKAGE_NAMES, then we should be able to make it working for other components too wihout PACKAGE_NAMES. > However I am not sure if the bass/component.py script still relies on these > definitions (there is also a build-plan branch that attempts to automate > rebuild of dependencies). I'm unable to find PACKAGE_NAMES in bass/component.py so it apparently does not rely on it. And looking at the history it never did. Quick look at your build-plan branch shows there is no PACKAGE_NAMES mentioned there. So the result so far is: PACKAGE_NAMES is unused nad useless and we should simply remove it. Thanks Aurélien for information. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Purpose of PACKAGE_NAMES
Hi, I noticed there are PACKAGE_NAMES macros set for few components in the oi-userland git repo. Namely here: components/meta-packages/history/Makefile components/openindiana/gfx-drm/Makefile components/openindiana/pkg/Makefile components/openindiana/slim_source/Makefile They were added in October 2018 by following commits: c7b5e23fc94 2e3897664af ac1196a7cb0 a4bb6ce259f I'm curious what is the purpose of these macros. As far as I know there is no known consumer for them. They looks like some attempt to list packages generated by a component before we had support for pkg5 files (introduced in 2020). If PACKAGE_NAMES are unused then I plan to simply remove them once I touch those Makefiles. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Virtualbox crash
On Fri, Sep 15, 2023 at 10:29:20AM +0300, Toomas Soome via oi-dev wrote: > we are planning gcc 13 (C23 features), This one? https://github.com/illumos/gcc/tree/il-13_1_0 > unfortunately oi does not provide it yet, does it? Yep, OI does not have gcc-13 yet. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] gcc version for kernel modules
On Wed, Aug 30, 2023 at 10:49:53AM +0200, Jean-Pierre André wrote: > I am preparing an update to the fuse kernel module. Best if using > the same compiler as the kernel, and gcc7 is currently enforced. > > Is this still the correct version ? https://illumos.topicbox.com/groups/developer/Tc01851d253a5fd32-M7c815b3587c70b506af8de8f -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] GCC rebuilds
On Tue, Aug 01, 2023 at 02:38:32PM +0100, Peter Tribble wrote: > On Tue, Aug 1, 2023 at 6:41 AM Stephan Althaus < > stephan.alth...@duedinghausen.eu> wrote: > > We are stumbling over some faults with regard to the GCC Version change. > > Perhaps this would be an opportune moment to reconsider the way that > libstdc++ > (and generally the whole gcc/g++ runtime) is packaged, and to go for the > obvious > and supported route of only shipping one copy of the runtime - the one > corresponding to > the latest version of the compiler that you ship (gcc11 ?), and putting it > directly in > /usr/lib. The obvious question now is: Why it was not done that way since beginning? -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] inkscape calls gcc7 and 10
On Tue, Jul 04, 2023 at 10:20:32AM +0200, Udo Grabowski (IMK) wrote: > Hi, > the story with the mixup continues, this time inkscape. > Crashes, shows both gcc/7 and gcc/10 The inkscape's problems are basically these: $ ldd $(which inkscape) | egrep 'not found|gcc' libstdc++.so.6 =>/usr/gcc/10/lib/amd64/libstdc++.so.6 libgsl.so.23 => (file not found) libgomp.so.1 => /usr/gcc/10/lib/amd64/libgomp.so.1 libgcc_s.so.1 => /usr/gcc/10/lib/amd64/libgcc_s.so.1 libstdc++.so.6 =>/usr/gcc/7/lib/amd64/libstdc++.so.6 libgcc_s.so.1 => /usr/gcc/7/lib/amd64/libgcc_s.so.1 $ The gcc/7 requirement is caused by the library/c++/libwpd package and the missing libgsl.so.23 library is caused by the image/editor/inkscape package. Both packages needs to be rebuild. PRs are welcome. HTH. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Heads Up: Parallel build of single component
Hi, With the PR#12528 merged[1] the oi-userland now support parallel builds of single omponents. If you are updating a build recipe (the Makefile) for some big beasts (for example compilers, firefox, etc.) and you want to use parallel build for it to shrink down the component build time, please add this before the shared-macros.mk include: USE_PARALLEL_BUILD = yes Please note: 1) parallel builds are currently supported for following build styles only: - cmake - configure (this is the default build style) - justmake - makemaker - setup.py 2) many components does not support parallel builds properly so we cannot turn this on by default for all components; pleae test this carefully, 3) for small components (with `gmake build` taking up to few minutes only) it makes no sense to turn this on; it likely won't save much time, with a risk of strange builds failures (see #2 above), 4) please never set PARALLEL_JOBS in component's Makefile; this is intended to be a global setting done by a build server (like jenkins). Questions? Thanks. [1] https://github.com/OpenIndiana/oi-userland/pull/12528 -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] gcc: error: -pie is not supported in this configuration
On Thu, Jun 01, 2023 at 03:53:05PM +0200, Udo Grabowski (IMK) wrote: > On 01/06/2023 15:49, Marcel Telka wrote: > > I just noticed this: > > > > $ /usr/gcc/11/bin/gcc -pie a.c > > gcc: error: -pie is not supported in this configuration > > $ /usr/gcc/10/bin/gcc -pie a.c > > gcc: error: -pie is not supported in this configuration > > $ /usr/gcc/7/bin/gcc -pie a.c > > gcc: error: -pie is not supported in this configuration > > $ > > > > Any idea what is wrong wit -pie at OI? > > Is it possible to make it working? > > > > Isn't it -fpie ? No, on Rocky Linux 8 it works: $ gcc -pie a.c $ echo $? 0 $ gcc --version gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-18) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] gcc: error: -pie is not supported in this configuration
Hi, I just noticed this: $ /usr/gcc/11/bin/gcc -pie a.c gcc: error: -pie is not supported in this configuration $ /usr/gcc/10/bin/gcc -pie a.c gcc: error: -pie is not supported in this configuration $ /usr/gcc/7/bin/gcc -pie a.c gcc: error: -pie is not supported in this configuration $ Any idea what is wrong wit -pie at OI? Is it possible to make it working? Thanks. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Missing headerfiles for illumos-build in oi-userland
On Fri, May 19, 2023 at 09:32:45AM +0200, Alexander Jung wrote: > i can not build illumos-gate anymore in oi-userland, it fails because of > missing headerfiles like adt_event.h. > On > https://github.com/illumos/illumos-gate/tree/master/usr/src/lib/libbsm/common > there are alo not includet but on > https://hipster.openindiana.org/jenkins/job/illumos-gate/ws/components/openindiana/illumos-gate/illumos-gate/usr/src/lib/libbsm/common/ > there are still there. > > Can someone help me out. Is library/perl-5/xml-parser package installed? -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkg update failed during update from August 2022 to feruary 2023
Hi Klaus, On Fri, Feb 24, 2023 at 04:52:07PM +, Klaus Elsbernd wrote: > pkg image update didn't help: > > > pkg image-update -v > > Packages to update: 4 > > Estimated space available: 774.31 GB > > Estimated space to be consumed: 1.80 GB > > Create boot environment: No > > Create backup boot environment: Yes > > Rebuild boot archive: No > > > > Changed packages: > > openindiana.org > > consolidation/l10n/l10n-incorporation > > 0.5.11-2023.0.0.21504 -> 0.5.11-2023.0.0.21507 > > consolidation/sfw/sfw-incorporation > > 0.5.11-2015.0.2.0:20230217T134221Z -> > > 0.5.11-2015.0.2.0:20230223T130235Z > > consolidation/sunpro/sunpro-incorporation > > 0.5.11-2023.0.0.21504 -> 0.5.11-2023.0.0.21507 > > consolidation/xvm/xvm-incorporation > > 0.5.11-2015.0.2.0:20230217T134223Z -> > > 0.5.11-2015.0.2.0:20230223T130237Z > > Any ideas? Do you have nvidia driver installed? If so, then https://www.illumos.org/issues/15161 might help you. If not, then please share the output of 'pkg update -v' and 'pkg publisher' commands. Please note that 'image-update' is obsoleted and everybody should use 'update' instead. HTH. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] perl and Symbol.3 manpage
Hi David, On Sat, Feb 11, 2023 at 06:01:40PM +0100, s...@pandora.be wrote: > > I believe that the runtime/perl-534 and package runtime/perl-536 package a > file > > /usr/share/man/man3/Symbol.3 > > This can be verified with : pkg contents runtime/perl-534 | grep Symbol This was so till Sep 12th, 2022 only. After that perl man pages were moved to the 3perl section, including the Symbol man page. Please see https://github.com/OpenIndiana/oi-userland/pull/9203 Now you can still find some perl man pages in section 3 (if such a package was not rebuilt after Sep 12th) or section 3perl (if it was rebuilt). If you see the Symbol man page in section 3, then simply update your runtime/perl-534 and/or runtime/perl-536 packages. > Should this file be in man3 ? > > There also exists a /usr/share/man/man3perl > > But that directory seems to be empty for me. Please update. Currently the directory contains 2k+ man pages (while section 3 still contains ca 850 perl man pages). HTH. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] $WS_TOOLS/python-integrate-project
On Mon, Nov 28, 2022 at 05:16:47PM +0100, Nona Hansel wrote: > However, updating texttable, I ran > > > $WS_TOOLS/python-integrate-project texttable > > in oi-userland/components/python/texttable directory or in oi-userland/ and > got this mesage: > > -bash: /python-integrate-project: No such file or directory You need this first: WS_TOOLS=$(git rev-parse --show-toplevel)/tools or alternatively (the above one is more reliable) WS_TOOLS=$(gmake print-value-WS_TOOLS) Anyway, I assume the texttable update will fail now using the python-integrate-project tool, because the tool is very strict. It requires really _all_ declared dependencies by a project, and it also requires all tests to pass. This was usually not the case earlier where testing was usually simply skipped. I'm currently in a middle (or at beginnig? :-)) of converting all Python projects to python-integrate-project and to include all dependencies for them, also for testing. I now have ca 80 Python projects in the queue waiting for something (usually for other projects to get integrated first). I started with handfull already integrated Python projects to convert them to python-integrate-project (and possibly update them), but because of dependencies I'm now at vastly higher number :-). The texttable is not in my queue yet, so you can try to convert it to use python-integrate-project (and let me know the result). > How do I use this command? And is it usable for every python component? You can try to read draft of documentation for perl-integrate-module at: https://github.com/mtelka/oi-userland/blob/pim-doc/doc/perl-modules.md The perl-integrate-module is similar tool as python-integrate-project but targetting Perl. The usage of both tools should be as similar as possible (modulo differences caused by Perl and Python itself; for example Python have no problem with versions, while Perl does). HTH. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Error message after gmake test
On Mon, Nov 07, 2022 at 03:33:15PM +0100, Nona Hansel wrote: > I copied the contents of build/test/amd64/results-64.snapshot into test/ > results-64.master because I thought that the build system would compare > those files, yet I get the above message. Please run 'gmake print-value-COMPONENT_TEST_MASTER' in the components/text/sed directory and you'll see the problem. In short, 'mv test/results-64.master test/results-all.master' should do the trick. HTH. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] slim_source rebuild
Hi Andreas, I noticed we do miss the slim_source rebuild after the PR #70 (Switch to Python 3.9) merge: https://github.com/OpenIndiana/slim_source/pull/70 It was merged on 2022-09-24, but the latest (re)build of slim_source is from 2022-09-17: # pkg list -afv system/install FMRI IFO pkg://openindiana.org/system/install@0.5.11-2022.0.0.1061:20220917T092724Z i-- # Could you please look at it? Is change in components/openindiana/slim_source/Makefile needed to make the slim_source automatically rebuilt by jenkins? Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Can not install any gcc compiler
On Fri, Oct 21, 2022 at 07:01:56PM +0200, Udo Grabowski (IMK) wrote: > Thanks for the fast help, update did fix the situation. So before > installing larger amounts, a 'pkg update -n' should become a > regular habit in the morning... the wonders of rolling releases. In this case it was not caused by rolling release, but by simple fact that too many packages at pkg server slows down everything[*] so the pkg server needs to be cleaned from time to time. The current way to do so is roughly this: keep latest version of every package and drop everything else. And this, obviously, causes problems like you faced. But, at least, it should be always possible to do 'pkg update' to get back on track (unless your system is veeery veeery old). [*] okay, not literally everything :-) -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Can not install any gcc compiler
On Fri, Oct 21, 2022 at 12:10:36PM -0300, Till Wegmueller wrote: > > > On 21/10/2022 11.50, Marcel Telka wrote: > > On Fri, Oct 21, 2022 at 04:44:54PM +0200, Udo Grabowski (IMK) wrote: > > > On 21/10/2022 16:14, Udo Grabowski (IMK) wrote: > > > > On 21/10/2022 15:59, Udo Grabowski (IMK) wrote: > > > > > ... > > > > > ro sunts /tmp # pkg install developer/gnu-binutils > > > > > Creating Plan (Solver setup): \ > > > > > pkg install: No matching version of developer/gnu-binutils can be > > > > > installed: > > > > > Reject: > > > > > pkg://openindiana.org/developer/gnu-binutils@2.39-2022.0.0.0 > > > > > > > > > > pkg://openindiana.org/developer/gnu-binutils@2.39-2022.0.0.1 > > > > > Reason: This version is excluded by installed incorporation > > > > > consolidation/userland/userland-incorporation@0.5.11-2022.0.0.16641 > > > > > ... > > > > The facet version locks are: > > > > > > > > ro sunts /tmp # pkg contents -m > > > > consolidation/userland/userland-incorporation@0.5.11-2022.0.0.16641|grep > > > > binut > > > > depend facet.version-lock.SUNWbinutils=true fmri=SUNWbinutils@2.19-0.133 > > > > type=incorporate > > > > depend facet.version-lock.developer/gnu-binutils=true > > > > fmri=developer/gnu-binutils@2.38-2022.0.0.0 type=incorporate > > > > > > > > and SUNWbinutils is shown as 'renamed'. 'pkg install SUNWbinutils' > > > > leads to the same error. > > > > > > And another such instance: pkg install system/header > > > > > > pkg install: No matching version of system/header can be installed: > > >Reject: pkg://openindiana.org/system/header@0.5.11-2022.0.0.21284 > > > to > > > pkg://openindiana.org/system/header@0.5.11-2022.0.0.21323 > > >Reason: This version is excluded by installed incorporation > > > consolidation/osnet/osnet-incorporation@0.5.11-2022.0.0.21248 > > > > > > ro sunts /tmp # pkg contents -m > > > consolidation/osnet/osnet-incorporation@0.5.11-2022.0.0.21248|grep > > > system/header > > > > > > depend fmri=pkg:/system/header@0.5.11,5.11-2022.0.0.21248 type=incorporate > > > > > > 21284 vs. 21248 typo ? random coincidence ? > > > > I'm sorry, but you need to update the whole system (pkg update). > > > > Packages you try to install (at version locked by your old > > incorporations) are no longer in the pkg repo so you simply cannot > > install them. ... and newer versions cannot be installed because your > > old incorporations rejects them. > > > > > > HTH. > > > > A small addition at the moment is, that illumos-gate has a small bug in the > osnet-incorporation. you will need to uninstall system/library/processor as > it still has an incorporate entry in osnet-incorporation but has been > obsoleted. Than make an update and then you are able to install as > previously. A small addition to what Till said: the problem he is referring to is fixed since yesterday. So if you update to pkg://openindiana.org/consolidation/osnet/osnet-incorporation@0.5.11-2022.0.0.21322:20221020T010421Z or pkg://openindiana.org/consolidation/osnet/osnet-incorporation@0.5.11-2022.0.0.21323:20221021T010028Z you should no longer need to manually uninstall system/library/processor before the update. So, basically, simple 'pkg update' should now work again. If it does not then please let me know. Regards. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Can not install any gcc compiler
On Fri, Oct 21, 2022 at 04:44:54PM +0200, Udo Grabowski (IMK) wrote: > On 21/10/2022 16:14, Udo Grabowski (IMK) wrote: > > On 21/10/2022 15:59, Udo Grabowski (IMK) wrote: > > > ... > > > ro sunts /tmp # pkg install developer/gnu-binutils > > > Creating Plan (Solver setup): \ > > > pkg install: No matching version of developer/gnu-binutils can be > > > installed: > > > Reject: pkg://openindiana.org/developer/gnu-binutils@2.39-2022.0.0.0 > > > pkg://openindiana.org/developer/gnu-binutils@2.39-2022.0.0.1 > > > Reason: This version is excluded by installed incorporation > > > consolidation/userland/userland-incorporation@0.5.11-2022.0.0.16641 > > > ... > > The facet version locks are: > > > > ro sunts /tmp # pkg contents -m > > consolidation/userland/userland-incorporation@0.5.11-2022.0.0.16641|grep > > binut > > depend facet.version-lock.SUNWbinutils=true fmri=SUNWbinutils@2.19-0.133 > > type=incorporate > > depend facet.version-lock.developer/gnu-binutils=true > > fmri=developer/gnu-binutils@2.38-2022.0.0.0 type=incorporate > > > > and SUNWbinutils is shown as 'renamed'. 'pkg install SUNWbinutils' > > leads to the same error. > > And another such instance: pkg install system/header > > pkg install: No matching version of system/header can be installed: > Reject: pkg://openindiana.org/system/header@0.5.11-2022.0.0.21284 > to >pkg://openindiana.org/system/header@0.5.11-2022.0.0.21323 > Reason: This version is excluded by installed incorporation > consolidation/osnet/osnet-incorporation@0.5.11-2022.0.0.21248 > > ro sunts /tmp # pkg contents -m > consolidation/osnet/osnet-incorporation@0.5.11-2022.0.0.21248|grep > system/header > > depend fmri=pkg:/system/header@0.5.11,5.11-2022.0.0.21248 type=incorporate > > 21284 vs. 21248 typo ? random coincidence ? I'm sorry, but you need to update the whole system (pkg update). Packages you try to install (at version locked by your old incorporations) are no longer in the pkg repo so you simply cannot install them. ... and newer versions cannot be installed because your old incorporations rejects them. HTH. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-dev Digest, Vol 146, Issue 6
On Mon, Oct 10, 2022 at 10:44:28AM +, Klaus Elsbernd wrote: > > root@openindiana:/export/home/isg# pkg list -afv > > library/python/importlib-metadata-35 > > FMRI IFO > > pkg://openindiana.org/library/python/importlib-metadata-35@1.5.2-2020.0.1.2:20221003T163227Z > > --o > > pkg://openindiana.org/library/python/importlib-metadata-35@1.5.2-2020.0.1.1:20210118T123359Z > > --- > > root@openindiana:/export/home/isg# > should I remove the version @1.5.2-2020.0.1.1? No. Please try this: pkg install -v pkg://openindiana.org/library/python/importlib-metadata-35@1.5.2-2020.0.1.1:20210118T123359Z If it succeeds, then please try the update again. Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-dev Digest, Vol 146, Issue 6
On Sun, Oct 09, 2022 at 10:00:23PM +0200, Stephan Althaus wrote: > On 10/9/22 19:39, Marcel Telka wrote: > > pkg list -afv library/python/importlib-metadata-3 > Just to add further info, on my system which i upgraded on September 19th, i > have packages from 2021: > > $ pkg list -afv library/python/importlib-metadata-35 > FMRI IFO > pkg://openindiana.org/library/python/importlib-metadata-35@1.5.2-2020.0.1.1:20210118T123359Z > i-- > > $ pkg list -afv library/python/importlib-metadata-39 > FMRI IFO > pkg://openindiana.org/library/python/importlib-metadata-39@1.5.2-2020.0.1.1:20210118T123411Z > --- The above outputs are either not complete, or not up-to-date. Please run 'pkg refresh' to update your list of available packages. > The packages on pkg.openindiana.org are recent, so why the difference ? > > library/python/importlib_metadata-37@4.10.1,5.11-2022.0.0.0:20221003T163139Z > <http://pkg.openindiana.org/hipster/info/0/library%2Fpython%2Fimportlib_metadata-37%404.10.1%2C5.11-2022.0.0.0%3A20221003T163139Z> Difference between what and what? Above you listed these packages: importlib-metadata-35 importlib-metadata-39 Here you are talking about: importlib_metadata-37 They are three different packages. Regards. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-dev Digest, Vol 146, Issue 6
On Sun, Oct 09, 2022 at 12:23:04PM +, Klaus Elsbernd wrote: > Am 09.10.2022 um 14:00 schrieb oi-dev-requ...@openindiana.org: > > What 'pkg list -afv library/python/importlib-metadata-35' shows? > > pkg list: no know packages matching: > > library/python/import-metadata-35 Please copy'n'paste the command. Typing sometimes does not work well. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkg update failed in virtualbox 6.1 after clean install hipster-gui-20211031
On Sun, Oct 09, 2022 at 02:43:39AM +, Klaus Elsbernd wrote: > > root@openindiana:/export/home/isg# pkg update > > Creating Plan (Running solver): / > > pkg update: No solution was found to satisfy constraints > > No solution found to update to latest available versions. > > This may indicate an overly constrained set of packages are installed. > > > > latest incorporations: > > > > pkg://openindiana.org/consolidation/install/install-incorporation@0.5.11,5.11-2022.0.0.1061:20220917T092526Z > > pkg://openindiana.org/consolidation/osnet/osnet-incorporation@0.5.11,5.11-2022.0.0.21286:20221009T011330Z > > pkg://openindiana.org/consolidation/userland/userland-incorporation@0.5.11,5.11-2022.0.0.16868:20221008T150443Z > > > > The following indicates why the system cannot update to the latest > > version: > > > > Reject: > > pkg://openindiana.org/consolidation/osnet/osnet-incorporation@0.5.11-2022.0.0.21286:20221009T011330Z > > Reason: No version for 'incorporate' dependency on > > system/library/processor@0.5.11-2022.0.0.21286 can be found > > Reject: > > pkg://openindiana.org/consolidation/userland/userland-incorporation@0.5.11-2022.0.0.16868:20221008T150443Z > > Reason: No version matching 'incorporate' dependency > > library/python/jsonschema-35@3.2.0-2021.0.0.3 can be installed > > > > Reject: > > pkg://openindiana.org/library/python/jsonschema-35@3.2.0-2021.0.0.3:20211217T174053Z > > Reason: All acceptable versions of 'require' dependency on > > library/python/importlib-metadata-35 are obsolete > > > > Reject: > > pkg://openindiana.org/consolidation/osnet/osnet-incorporation@0.5.11-2022.0.0.21284:20221007T010842Z > > Reason: No version for 'incorporate' dependency on > > system/library/processor@0.5.11-2022.0.0.21284 can be found > > Reject: > > pkg://openindiana.org/consolidation/osnet/osnet-incorporation@0.5.11-2022.0.0.21286:20221008T074057Z > > Reason: No version for 'incorporate' dependency on > > system/library/processor@0.5.11-2022.0.0.21286 can be found > > any ideas? What 'pkg list -afv library/python/importlib-metadata-35' shows? -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pkg update Problems with python 3.5
On Wed, Oct 05, 2022 at 01:16:38PM +, Klaus Elsbernd wrote: > I setup a virtual machine running OpenIndiana with installation image > OI-hipster-gui-20211031.iso. (the latest) > > After setup I started pkg update. Since I follow the mailing list, I heard > that python has been updated. Is this a problem? And where is the solution? I do not think your problem is related to python version. I see a lot of "MemoryError" lines in your log. Maybe you have not enough RAM assigned to your virtual machine? > Rem.: I used to download/intall a copy of isfdb.org, which uses python 2.7. > I am a little sad that this version is no longer included, and or > uninstalled. The runtime/python-27 package is still available in OI repos. HTH. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Fri, Sep 30, 2022 at 07:16:18PM +0200, s...@pandora.be wrote: > > Part of the problem is, I think, that there is no maintainer any longer, as > far as I know, for the mkdocs component in oi-userland. > > If someone knows how to build mkdocs with python 3 (which is perhaps > possible, I don't know, I have no experience with building python components) > then this would solve most of the problem, I think ... > > Thanks for your work on this, because as I confirmed, there are indeed really > issues with the mkdocs python2.7. > > Several people related to the oi-docs are aware that we have a Python 2.7 > problem, but we are unsure how to fix it, I think. > > For example in my Vagrantfile I have a comment about a missing 2.7 'futures' > component: > > https://github.com/OpenIndiana/vagrantfiles/blob/main/oi-docs/Vagrantfile > > # there used to be a futures package in the repo ... > # library/python/futures seems to have a problem now > pfexec pkg install -v \ > git lynx links\ > library/python/futures \ > library/python/mkdocs \ > developer/documentation-tool/mdl > # as of 21/9/2021 futures IPS is missing so install by pip > pfexec pip install futures > > Because such "pip install" actions print a clear warning by Python that we > are using an unsupported Python 2.7, it is clear that something must be done. The futures python package was obsoleted in May 2021 in OpenIndiana. The reason is, apparently, this - see https://pypi.org/project/futures/: It does not work on Python 3 due to Python 2 syntax being used in the codebase. Python 3 users should not attempt to install it, since the package is already included in the standard library. Regards. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 06:46:40PM +0200, s...@pandora.be wrote: > > > Based on the rule above we already obsoleted following packages > > recently: > > > ... > > library/python/mkdocs > ... > > see http://docs.openindiana.org/contrib/getting-started/ > > that page says for installing mkdocs: > > "For OpenIndiana Hipster, MKDocs and all of it's dependencies have been > packaged and are available in the OI Hipster repository. So, if you're > already running Hipster, installing MKDocs is as simple as: pkg install > mkdocs" Okay, I'll add mkdocs back. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 04:36:15PM +0200, Aurélien Larcher wrote: > On Thu, Sep 29, 2022 at 4:30 PM Marcel Telka wrote: > > > On Thu, Sep 29, 2022 at 04:18:01PM +0200, Aurélien Larcher wrote: > > > We could define some rules or information depending on the nature of the > > > package to mark which dependencies are expected. > > > Some python modules have been added for the sake of resolving a > > dependency > > > while others have no consumer in userland but are expected to be > > installed > > > as "standalone" and consumed by users directly. > > > > > > Also I am not sure I understood which type of dependencies are considered > > > here: > > > - resolved within userland either directly or added explicitly in the > > > manifest > > > - build requirements > > > - dependencies detected by pipdeptree (which are a superset of what > > > pkg/userland detects) > > > > > > I just want to make sure that we do not miss some border effects. > > > > Okay, I'll stop to obsolete more python related packages and leave it as > > it is for now so everybody have a chance to add back packages that were > > obsoleted, but they are needed for any reason. > > > > I am not asking you to stop anything at all, I am just asking questions to > understand if this will not bite us back at some point. I won't obsolete any package from the list below until end of October 2022. If I see no PR trying to rebuild them to support python 3.7+ till end of October 2022, then I might propose to obsolete them. library/python/backport_abc library/python/backports.functools_lru_cache library/python/backports.ssl_match_hostname library/python/colorama library/python/decorator library/python/enum library/python/flamegraph library/python/funcsigs library/python/ipaddress library/python/ipython library/python/ipython_genutils library/python/notify2 library/python/pickleshare library/python/prompt-toolkit library/python/pyatspi2 library/python/pycups library/python/pygobject library/python/pygtk2 library/python/python-compizconfig library/python/python-xdg library/python/python-xlib library/python/rbtools library/python/simplegeneric library/python/traitlets Thanks. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 04:36:15PM +0200, Aurélien Larcher wrote: > At least maybe some indications on how to add the packages back and make > sure there is no mistake or loss of consistency with the location/naming > etc.. If anybody wants to re-add some obsoleted package back, or rebuild some package to support python 3.7/3.9 properly and have some questions, issues, problems, etc. feel free to ask me. I'll try to help. Thanks. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 04:18:01PM +0200, Aurélien Larcher wrote: > We could define some rules or information depending on the nature of the > package to mark which dependencies are expected. > Some python modules have been added for the sake of resolving a dependency > while others have no consumer in userland but are expected to be installed > as "standalone" and consumed by users directly. > > Also I am not sure I understood which type of dependencies are considered > here: > - resolved within userland either directly or added explicitly in the > manifest > - build requirements > - dependencies detected by pipdeptree (which are a superset of what > pkg/userland detects) > > I just want to make sure that we do not miss some border effects. Okay, I'll stop to obsolete more python related packages and leave it as it is for now so everybody have a chance to add back packages that were obsoleted, but they are needed for any reason. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Thu, Sep 29, 2022 at 03:18:29PM +0200, Aurélien Larcher wrote: > I do not understand the need for obsoleting the entire package and removing > all the files instead of updating on the go. > > Could you explain the motivation? There is no particular need. It is just simpler to obsolete than to update. And since there is no known consumer, then the obsoletion is the obvious option chosen. > To me this seems a bit of overhead, like removing the mkdocs, cython, numpy > packages completely from the tree instead of updating them. Feel free to create PRs to get them back. > We therefore lose track of what was in the tree and people may start from > scratch all over again. > > Maybe you intend to provide some level of automation later? Maybe. If I find it easy to do I'll do so, but I've no immediate plan to do so. > An earlier heads-up before starting to remove everything could have been > nice to have a chance to update a few components in advance and avoid the > mumbo-jumbo. Sorry. I try to do my best. Nothing is perfect. Anyway, an earlier update/rebuild of those packages for non-EOLed python would be nice from you before you left them fall out of support and be surprised that they are disappearing. Sorry, talking is easy. Thank you. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
Hi, Currently we provide Python versions 2.7, 3.5, 3.7, and 3.9 for OpenIndiana, while version 3.9 is the default version. Both Python 2.7 and 3.5 are no longer supported for two or almost three years now respectively - see https://devguide.python.org/versions/#versions for details, so we started to obsolete them. Since there are many related packages that needs to be rebuilt to get python 2.7 and 3.5 obsoleted, this transition is expected to take long time (probably weeks, maybe months). There are basically two sets of related packages: #1 software that uses python (e.g. gimp), and #2 packages that provide some enhancement to python; these are usually python modules, for example cherrypy. For #1 we just need to rebuild packages that require python 2.7 or 3.5 so they start to require either python 3.7, or python 3.9. Volunteers are welcome! For #2 the situation is a bit more complex. The name of all packages in this set is starting with 'library/python'. There is usually a basic package (e.g. library/python/cherrypy) and few version specific packages (e.g. library/python/cherrypy-35, library/python/cherrypy-37, library/python/cherrypy-39). Another example is library/python/pycups and its library/python/pycups-27 and library/python/pycups-35. For such packages we will slowly obsolete their -27 and -35 variants. In a case there is neither -37 nor -39 variant already available, nor it is needed for some other package, we will end up with all package variants obsoleted. If this happens, then in addition to obsolete of both -27 and -35 we will obsolete the base package too. For example, cherrypy. There are already -35, -37, and -39 variants. We will obsolete the -35 variant and both -37 and -39 will be kept, so we will keep the basic library/python/cherrypy too. When looking at pycups, we will obsolete both -27 and -35 variants. Let's assume there is currently no other package that needs pycups, so we would end with orphaned library/python/pycups, so we will obsolete the library/python/pycups package too. Based on the rule above we already obsoleted following packages recently: library/python/augeas library/python/backports.shutil_get_terminal_size library/python/backports.tempfile library/python/cheetah library/python/click library/python/cssutils library/python/cython library/python/dulwich library/python/geoip library/python/elixir library/python/import-profiler library/python/kafka-python library/python/livereload library/python/m2crypto library/python/mkdocs-bootstrap library/python/mkdocs-bootswatch library/python/mkdocs library/python/netaddr library/python/netifaces library/python/numpy library/python/pygtksourceview library/python/pymongo library/python/pyorbit library/python/pyrex library/python/pyro library/python/python-ldap library/python/python-memcached library/python/python-mysql library/python/python-notify library/python/python-sexy library/python/pywbem library/python/scientific-py library/python/sqlalchemy library/python/typing library/python/unittest2 Here is a list of packages that could get possibly obsoleted soon: library/python/backport_abc library/python/backports.functools_lru_cache library/python/backports.ssl_match_hostname library/python/colorama library/python/decorator library/python/enum library/python/flamegraph library/python/funcsigs library/python/ipaddress library/python/ipython library/python/ipython_genutils library/python/notify2 library/python/pickleshare library/python/prompt-toolkit library/python/pyatspi2 library/python/pycups library/python/pygobject library/python/pygtk2 library/python/python-compizconfig library/python/python-xdg library/python/python-xlib library/python/rbtools library/python/simplegeneric library/python/traitlets If you need any package from these lists then please create a pull request (see https://github.com/OpenIndiana/oi-userland/pulls) to get the package back and built for python 3.7 and/or 3.9 (in a case it is on the first list of already obsoleted packages), or either let us know or create a pull request to rebuild the package for python 3.7 and/or 3.9 (if it is on the second list of packages we could possibly obsolete). Any help with this task is very welcome (for example pull requests to get software in set #1 rebuilt). Please note that support for building python modules for python 2.7 and 3.5 was already dropped from oi-userland. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Who is using WBEM?
On Sat, Sep 17, 2022 at 03:18:20PM +0200, Marcel Telka wrote: > I plan to propose obsoletion of cimple, sblim-cim-client, and wbemcli > soon, so please speak up if you are not okay with that. The proposal is here: https://github.com/OpenIndiana/oi-userland/pull/9315 Once it is merged all three wbem packages will be obsoleted. Thanks. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Who is using WBEM?
Hi all, I noticed we do have following WBEM packages in the OI pkg repo: system/management/wbem/cimple system/management/wbem/data-management system/management/wbem/resource-management system/management/wbem/sblim-cim-client system/management/wbem/wbemcli The system/management/wbem/resource-management package is obsoleted. The system/management/wbem/data-management package comes from illumos-gate and there is no immediate problem with it. The rest three packages (cimple, sblim-cim-client, and wbemcli) are not fully and properly integrated to OI, because we have no recipe in oi-userland how to build them. In addition, cimple is currently not installable because it requires system/management/cim/pegasus, which we do not have in our repo. We need to do something with them because this is not sustainable in long term. There are basically two options how to proceed: 1) obsolete cimple, sblim-cim-client, and wbemcli, or 2) add them to oi-userland so we can build them. Option 1 is simple to do, but will remove some functionality from OI. Option 2 is harder (I do not know how hard), but will preserve the WBEM support in OI. The main questions are: - Is option 2 worth doing? - Is somebody using cimple, sblim-cim-client, and/or wbemcli? If the answer to either question above is "yes", then: - Who volunteers to do the integration to oi-userland? I plan to propose obsoletion of cimple, sblim-cim-client, and wbemcli soon, so please speak up if you are not okay with that. Thank you. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libstdc++.so version
On Wed, Sep 14, 2022 at 05:17:05PM +0200, Andreas Wacknitz wrote: > > Am 14.09.22 um 16:49 schrieb Alexander Jung: > > > > Hello, > > > > what version of libstdc++.so should be in current OI under > > /usr/lib/amd64 ? > > > None. libstdc++.so are under /usr/gcc//lib/ (32 bit) and > /usr/gcc//lib/amd64/ (64 bit), eg. > /usr/gcc/10/lib/amd64/libstdc++.so. ... with one exception: system/library/g++-4-runtime # pkg contents -r system/library/g++-4-runtime | grep libstdc++ usr/lib/amd64/libstdc++.so usr/lib/amd64/libstdc++.so.6 usr/lib/amd64/libstdc++.so.6.0.20 usr/lib/libstdc++.so usr/lib/libstdc++.so.6 usr/lib/libstdc++.so.6.0.20 # -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] FLAG DAY: Default Perl in OpenIndiana is 5.36 now
Perl 5.36 is default now The default Perl in OpenIndiana switched from version 5.34 to version 5.36. Perl 5.36 is fully supported now and all additional Perl modules were rebuilt to properly support Perl 5.36. OpenIndiana currently provides over 210 additional Perl modules in the package repository. Perl 5.34 is still available in repository for your convenience to allow smooth transition to Perl 5.36. All other Perl versions, namely 5.22 and 5.24, were obsoleted because they reached End of life several years ago. Perl is first class citizen now --- Perl became first class citizen and commands like `man perl` or `pod2man` now works by default without any additional tweaks with PATH and/or MANPATH. This change affects additional Perl modules too but it will become visible only after they are rebuilt. Please note that only handful of additional Perl modules were rebuilt so far. Other modules will be rebuilt either when they are upgraded, or when new major Perl version is integrated to OpenIndiana. For example, `man Type::Tiny` already works, but `man Mojo` does not (yet) and you still need to invoke something like `MANPATH=/usr/perl5/5.36/man man Mojo` to read the man page. In addition, we introduced unversioned runtime/perl package. If you need any Perl version installed, just install runtime/perl and you are done. The runtime/perl package will always point to the default Perl version. Currently it is 5.36. system-perl mediator Unless you really knows what you are doing your system-perl mediator should be unset. Before update to latest bits your system-perl mediator should look like this (if your system is recent): # pkg mediator system-perl MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION system-perl vendor5.34vendor # or like this (if your system is older than ca 2 months): # pkg mediator system-perl MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION system-perl vendor5.22vendor # If this is not the case and the output of the above command looks differently, it is higly recommended to switch the system-perl mediator back to its default state using this command: # pkg unset-mediator system-perl After you update your machine to latest bits, the system-perl mediator should automatically switch to version 5.36: # pkg mediator system-perl MEDIATORVER. SRC. VERSION IMPL. SRC. IMPLEMENTATION system-perl vendor5.36vendor # illumos-gate nightly The change of default Perl version constitutes a flag-day for people building illumos-gate on OpenIndiana. You should update your env file (illumos.sh) to contain following lines so runtime/perl-536/module/sun-solaris package is properly built during illumos-gate nightly: export PERL_VERSION="5.36" export PERL_VARIANT="-thread-multi" export PERL_PKGVERS="-536" export BUILDPERL32="#" Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ openindiana-discuss mailing list openindiana-disc...@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Miscellaneous component fixes and migrations
On Sat, Aug 06, 2022 at 09:50:15PM +0200, Marcel Telka wrote: > On Sat, Aug 06, 2022 at 08:06:55PM +0200, s...@pandora.be wrote: > > I think that the last good changeset was 522d32b5 and the first bad > > changeset for me was de49ed8c. > > Thanks for this. I'll look at it and propose a fix. I apparently > missed something there. Sorry for that. The fix is waiting for integration: https://github.com/OpenIndiana/oi-userland/pull/8988 It turned out that my move of prep.mk include was wrong, so I basically returned it back where it was all the time and where it have to be. The problem was that $(BUILD_STYLE).mk files expects some variables to be properly set by prep.mk (for example SOURCE_DIR) so prep.mk must be included before $(BUILD_STYLE).mk. This affected components with complex build recipes only (like squeak). As a side effect I fixed few minor annoying issues in the prep*.mk files while root causing this :-). Thanks for reporting the issue and sorry for inconvenience. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Miscellaneous component fixes and migrations
On Sun, Aug 07, 2022 at 09:10:17PM +0200, s...@pandora.be wrote: > I was thinking that I had to update the runtime/perl-524 dependency, > to runtime/perl-534, now that perl is version 5.34 by default. For pari it is no longer needed. OTOH, there are still ca 30 components that are waiting for the rebuild to have the perl dependency updated/fixed so we can obsolete both perl 5.22 and 5.24. > > But for some reason (which I suspect may be due to the ongoing fixes and > migrations), > "gmake REQUIRED_PACKAGES" is now producing a runtime/perl dependency, > which is better than the runtime/perl-524 that it produced in the past. The "some reason" is this: Regular packages should depend on runtime/perl instead of runtime/perl-$(PLV) https://github.com/OpenIndiana/oi-userland/commit/9bec6142781527d49dc39813df2b259ef37c645c > OpenIndiana also offers perl 5.36 optionally. Yes. The addition was announced more than month ago: https://www.mail-archive.com/openindiana-discuss@openindiana.org/msg26335.html -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Miscellaneous component fixes and migrations
On Sun, Aug 07, 2022 at 03:50:44PM +0200, s...@pandora.be wrote: > However I think that PARI does not require an update because the dependency > is simply: > > depend fmri=pkg:/runtime/perl type=require > > which I believe will work automatically for any Perl version, including the > new Perl 5.36. ... and this is since ca 2 days ago when I triggered the pari rebuild to update the perl deps from runtime/perl-524 to runtime/perl: https://github.com/OpenIndiana/oi-userland/commit/ec4124604353044e317334b9b12533a9746d37fb :-) -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Miscellaneous component fixes and migrations
On Sat, Aug 06, 2022 at 08:06:55PM +0200, s...@pandora.be wrote: > I'm no Perl expert and I'm not sure whether I had to do this but I manually > set the perl mediator to perl 5.34. > So the "pkg mediator" for perl reports a "local" VER.SRC for version 5.34. This is basic rule of thumb: Your "pkg mediator" output should never show "local" unless you have good reason to use non-default mediator setup. If you are unsure, or do not know, then you should revert back to system/vendor defaults (using "pkg unset-mediator ..."). This is true always and for all mediators. Especially on machines that are used for oi-userland development and/or building. In this particular case I recommend to run "pkg unset-mediator -v perl". Your current perl setup (mediator manually set to perl 5.34) could cause some unexpected results in future when we change the default perl to 5.36, but your system will stay with perl 5.34 even after update. > I think that the last good changeset was 522d32b5 and the first bad changeset > for me was de49ed8c. Thanks for this. I'll look at it and propose a fix. I apparently missed something there. Sorry for that. Regards. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Miscellaneous component fixes and migrations
On Sun, Jul 31, 2022 at 06:36:49PM +0200, s...@pandora.be wrote: > Unfortunately today when I ran 'gmake build' or 'gmake install' in the > components/runtime/smalltalk/squeak directory, > I get an error : > >No rule to make target ... squeak/build/i86/.configured needed by ... > build/i86/.built > > I have tried to check some commits and when I go back in time and checkout > older versions, I am able to build again. > > If I go back to 'git checkout a847fb267' it works again. I assume it will work with the next changeset (20542be0f) too. It changed makemaker.mk only and squeak does not use makemaker build style. It would be great if you try to bi-sect to find the exact changeset that caused the build problem. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Perl 5.34
On Thu, Jun 30, 2022 at 04:33:29PM +0200, Andreas Wacknitz wrote: > Am 30.06.22 um 16:14 schrieb Gordon Ross: > > After a "pkg image-update" today I see complaints from intrd that it > > can't find these perl modules: > > > > Can't locate Sun/Solaris/Kstat.pm in @INC (you may need to install the > > Sun::Solaris::Kstat module) (@INC contains: > > /usr/perl5/site_perl/5.34/i86pc-solaris-thread-multi-64 > > /usr/perl5/site_perl/5.34 > > /usr/perl5/vendor_perl/5.34/i86pc-solaris-thread-multi-64 > > /usr/perl5/vendor_perl/5.34 > > /usr/perl5/5.34/lib/i86pc-solaris-thread-multi-64 /usr/perl5/5.34/lib) > > at /usr/lib/intrd line 66. > > > > Did I miss a step? I looked for a "heads up" but don't see any > > relevant instructions. > > > You didn't miss a step. The actual problems are due a failed > illumos-gate build tonight. > We need to fix it and rerun the jenkins job. This will pronably take > another 3 to 4 hours. And here are steps how to workaround the problem with intrd in the meantime: https://openindiana.org/pipermail/openindiana-discuss/2022-June/025646.html Regards. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What changed between glib versions?
On Fri, Apr 01, 2022 at 11:24:40PM +0200, Stephan Althaus wrote: > I have a local problem on my more recently updated machines not showing > "developer/java/jdk" - my older machine does list this package. https://www.illumos.org/issues/14583 -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] The end of python-27
On Thu, Mar 24, 2022 at 10:51:26AM -0500, Gary Mills wrote: > With the integration of PR #7942, there are only two remaining > packages: > > developer/gnome/gnome-doc-utils > image/editor/gimp > > In both of these cases, python-2 is deeply embedded in the product, > and the upstream developers have not completed the conversion to > python-3 . Unless the conversion happens very soon, we have little > choice but to obsolete these two packages, and revive them later when > the conversion is ready. If anyone has a better alternative, please > let us know. You cannot obsolete gnome-doc-utils right now because the following components lists it in REQUIRED_PACKAGES: multimedia/totem desktop/gparted desktop/gnome2/zenity desktop/stardict Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] dlc-origin (rsync) EOL?
On Fri, Jul 30, 2021 at 06:05:32PM +0200, Marcel Telka wrote: > On Fri, Jul 30, 2021 at 12:02:13PM -0300, Till Wegmueller wrote: > > have a look in the future to see to get that going. For now please switch to > > HTTP(S) > > Sure, will do. I tried that, but no way. At least with https://dlc.openindiana.org/. The index.html page have hardcoded urls to dlc.openindiana.org, so wget won't download isos. Also, old ISOs are not reachable that way. Yes, I could switch to https://dlc.openindiana.org/isos/ as my mirror source, but that will skip other dirs (closed, dlc.sun.com). So without rsync (or ftp) the mirror seems to be very hard. :-( Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] dlc-origin (rsync) EOL?
On Fri, Jul 30, 2021 at 12:02:13PM -0300, Till Wegmueller wrote: > I assume better means it can detect create a diff faster? No, this is not about the speed (primarily). Just about the quality of data published via the protocol. For example, with rsync I can be sure that timestamps are okay, for example. With ftp it usually works too, but http is not so good and there is possibility that I might end up re-downloading the same content again and again just because http might fail to advertise mtime change (or no change, to be precise). Over the years I switched all my mirrors to rsync from initial ftp (or http) just because of this. > I can see the point. I also think a fast diff for mirroring is nice. I'll Thanks. Please let me know once there is rsync back. > have a look in the future to see to get that going. For now please switch to > HTTP(S) Sure, will do. Thank you. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] dlc-origin (rsync) EOL?
Hi Till, On Fri, Jul 30, 2021 at 10:46:40AM -0300, Till Wegmueller wrote: > I am afraid you have to migrate. What are the benefits of having rsync for > you? If i know what the idea is, I can see if we get something similar on > the New Infrastructure. I used to use the dlc-origin rsync server as a source for my local mirror copy. After many years I do mirroring of various repos (various linux distros, OI, etc) I found that rsync is far far better than either http(s) or ftp as a mirror source. That said, the OI ISO rsync server is not critical for me, but it is really nice to have. OTOH, if there is no other way I can more or less easily switch to https://dlc.openindiana.org/ as my mirror source (although ftp would be better than http(s), but AFAIK there is no ftp for OI ISOs). Thanks. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] dlc-origin (rsync) EOL?
On Sun, Jul 04, 2021 at 08:23:49AM +0200, Marcel Telka wrote: > That's sad because I used it for rsync mirror of ISOs. Is there any > plan to provide (new) rsync server for ISOs? Does the silence means "no"? Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] dlc-origin (rsync) EOL?
Hi, I noticed that dlc-origin.openindiana.org disappeared from DNS some time ago (2 months or so) so it looks like it was EOLed. That's sad because I used it for rsync mirror of ISOs. Is there any plan to provide (new) rsync server for ISOs? Thanks. PS: rsync server at pkg-origin.openindiana.org still works. -- +---+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Obstacle to GPT label boot?
On Fri, Mar 19, 2021 at 09:34:01AM +0200, Toomas Soome wrote: [...snip...] Thanks for all those commands and references! > To install on slice, you would need to select GPT partitioning and > *not* select whole disk setup. However, I have not used OI installer > for a long time, therefore I can not recall what exactly are on those > screens:D Also it is very likely, some improvements can be made there > (like for >2TB disks we should only offer GPT). IIRC, this is not possible with Hipster 2020.10 installer. > Yes, this BIOS does see all 4 disks, therefore I can boot from this > rpool. We have been able to do this since loader was integrated.. hm, > log is telling… Then it must be just my stupid BIOS that does not allow me to boot from NVMe when I try legacy BIOS boot :-(. Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Obstacle to GPT label boot?
On Fri, Mar 19, 2021 at 08:17:44AM +0200, Toomas Soome via oi-dev wrote: > root@beastie:/code/illumos-gate# zpool status rpool > pool: rpool > state: ONLINE > scan: resilvered 1,68T in 0 days 10:10:07 with 0 errors on Fri Oct 25 > 05:05:34 2019 > config: > > NAMESTATE READ WRITE CKSUM > rpool ONLINE 0 0 0 > raidz1-0 ONLINE 0 0 0 > c3t0d0 ONLINE 0 0 0 > c3t1d0 ONLINE 0 0 0 > c3t3d0 ONLINE 0 0 0 > c3t4d0 ONLINE 0 0 0 > > errors: No known data errors What is the slice layout at those disks? Is it one small EFI boot slice (pcfs) + one big slice covering the rest of the disk and used for rpool? If I'm not mistaken this is the default layout created by the OI installer when installed on GPT/EFI disk (without MBR). Is there a way to install OI on a GPT disk in a slice not covering the whole disk? > I can tell, this system does boot just fine with both UEFI and BIOS firmware. Legacy BIOS? Is your system really able to boot in legacy BIOS mode with the rpool as outlined above? Thanks. -- +-------+ | Marcel Telka e-mail: mar...@telka.sk | |homepage: http://telka.sk/ | +---+ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
