[oi-dev] CoWorking Session Sunday 14th April 2024

[Till Wegmueller]

Hello all,

Another Week Another CoWorking Session is upon us join us today Sunday 
the 14th 17:00 CEST at 
https://meet.chaostreffbern.ch/OpenIndianaCoWorkingSessions


-Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] Coworking Session Sun 7. April 2024

[Till Wegmueller]

Hello All

The regular OpenIndiana snapshot is coming up soon, but even sooner we 
have another Coworking Session. Join us  this Sunday 17:00 CEST at 
https://meet.chaostreffbern.ch/OpenIndianaCoWorkingSession


-Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] OpenIndiana Coworking session March 17th 2024

[Till Wegmueller]

Hello all

And soon it is time again for the weekly CoWorking session. We are on 
this Sunday 17:00 CET at 
https://meet.chaostreffbern.ch/OpenIndianaCoWorkingSessions


-Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] CoWorking Session 10th March 2024

[Till Wegmueller]

Hello all

Want to work a bit on OpenIndiana? Our weekly CoWorking session is again 
tomorrow Sunday 10th 17:00 CET at


https://meet.chaostreffbern.ch/OpenIndianaCoWorkingSessions

-Till

___
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)

[Till Wegmueller]

Hey Goetz

On 24.02.2024 18:27, Goetz T. Fischer wrote:

hey all,

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.
obviously that wastes a lot of time and usually should be the other way around.
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
considered the default at the time. having a significantly smaller number of
packages with a fixed ssl version also makes switching to a different ssl
version at some point much nicer. the latter of course depending on how much
has been modified of each package to achieve the fixed ssl dependency.

right now 91 packages are affected. see attachment for the list. not counting
the ones which even need 0.9.8 :-O


Right now the list seems to fall into a couple categories of reasons why 
those dependencies exist in the repo.

1. Old Packages with newer versions available in the repo.
	In this case this will be solved if/when we do the next repo cleanup. 
(You could also clean them out of your list, we can ignore those)
2. Packages not being able to use the CFLAGS/LDFLAGS to define the 
openssl version. This can be fixed once we are certain all other 
packages build, once that is ensure we simply set the mediator to 
default to 3.x and run the prepared rebuild PR.
3. Packages that need updates to support openssl 3. This is the list we 
need to look into including the ones still needing 0.9.8.


Can you cleanup your list from packages in category 1? Then we can look 
at the rest. Can you also include the packages that require openssl 
0.9.8 and clean that from the ones in category 1?


Can you also check if the OPENSSL_DEFAULT mechanism suffices for the 
packages you wish to upgrade?



Greetings
-Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] CoWorking Session 25.02.2024

[Till Wegmueller]

Hello all,

Another week another CoWorking Session coming up as always join us 
tomorrow, Sunday 17:00 CET at 
https://meet.chaostreffbern.ch/OpenIndianaCoWorkingSessions


Other friends of illumos also heartly welcome :)

-Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] CoWorking Session 18.02.2024

[Till Wegmueller]

Another Sunday is approaching and the CoWorking sessions continue.

As usual join us this Sunday 17:00 CET at 
https://meet.chaostreffbern.ch/OpenIndianaCoWorkingSessions for 
collaborative Hacking on #OpenIndiana


- Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] SIMD support

[Till Wegmueller]

Hi

On 15.02.2024 18:18, Bill Sommerfeld via oi-dev wrote:

All amd64 processors have at least SSE2 available.


Well except that one old SmartOS KVM instance where the hoster cannot 
get SSE2 passed through to the Guests VCPU flags. Which unfortunately is 
the OpenIndiana Buildserver. Replacements are in the pipeline but we are 
again looking for people to help maintain that new infrastructure.
Currently we get support from the Hoster for problems on the older 
buildserver. The more modern PR build server that you can see when 
making PullRequests to the OpenIndiana Repo does have SSE2 support.


Hope this clears a few things up.
- Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] Coworking session 11.02.2024

[Till Wegmueller]

Hello everyone,

Late notice but, if you have some time and want to work on #OpenIndiana 
come to today's CoWorking session at 
https://meet.chaostreffbern.ch/OpenIndianaCoWorkingSessions


Sending this to multiple lists since some people mentioned that they did 
not get the info on openindiana-discuss.


-Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] package mtx

[Till Wegmueller]

Hi Carsten

It seems that media/ is more used for desktop CLI tools related to 
CDROM/DVD-ROM media. whereas storage/ and system/storage/ are used for 
various tools in the enterprise realm like mpathadm or stmf. I am 
ignoring lsof being under system/storage on purpose, I think. Your 
suggestion sounds reasonable. +1


-Till

On 10.01.2024 18:57, 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.
--
Carsten

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] OpenIndiana CoWorking Session

[Till Wegmueller]

Hello friends of illumos and OpenIndiana

After the Holiday I would like to continue the CoWorking sessions.

This weeks CoWorking Sessions are on this Sunday 17:00 CET at 
https://meet.chaostreffbern.ch/OpenIndianaCoWorkingSessions


Join us to collaborate on working on #OpenIndiana and bring your 
questions and tasks you got stuck on!


If you know other interested people, please forward this message so we 
can get a good reach of people knowing about these Sessions.


Hope to see you Sunday
-Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Fwd: [bugs] [illumos gate - Feature #15916] bhyve upstream sync 2023 September

[Till Wegmueller]

Hi, Stephan

The bHyve components are directly copied into illumos-gate and the 
repository you mentioned is just the UEFI Firmware/Bootloader where we 
seem to be up to date. All bHyve related parts get compiled with 
illumos-gate


-Till

On 23.12.2023 09:59, Stephan Althaus wrote:

Hello!


The OI bhyve firmware package seems to be outdated.

The related github has no more recent version, so it seems github has to 
be updated beforehand... (?)



$ pkg info system/bhyve/firmware
  Name: system/bhyve/firmware
   Summary: UEFI-EDK2(+CSM) firmware for bhyve
  Category: System/Core
     State: Installed
     Publisher: openindiana.org
   Version: 20210201
    Branch: 2022.0.0.2
    Packaging Date: March 25, 2022 at 06:39:30 AM
Last Install Time: December 23, 2023 at 08:13:52 AM
  Size: 7.88 MB
  FMRI: 
pkg://openindiana.org/system/bhyve/firmware@20210201-2022.0.0.2:20220325T063930Z

   Project URL: https://github.com/illumos/uefi-edk2
    Source URL: 
https://github.com/illumos/uefi-edk2/releases/download/il-udk2014.sp1-3/uefi-edk2-il-udk2014.sp1-3.tar.xz



GitHub:

https://github.com/illumos/uefi-edk2/releases


Regards,

Stephan



 Forwarded Message 
Subject: 	[bugs] [illumos gate - Feature #15916] bhyve upstream sync 
2023 September

Date:   Fri, 22 Dec 2023 22:10:32 +
From:   illumos project via illumos-bugs 
Reply-To:   illumos-bugs 



Issue #15916 has been updated by Andy Fiddaman.


The changes in the associated Gerrit review have been integrated in 
OmniOS bloody for a few weeks, and tested with a wide range of different 
VMs -- including illumos, FreeBSD, Windows and Linux -- in a range of 
configurations including pass-through of USB hubs, NICs and GPUs (many 
thanks due to Jorge Schrauen and Marco van Wieringen for helping out here).


Although this change includes new code to load ACPI tables into the 
guest via a fwcfg interface, this is not enabled by default. Enabling 
this appears to work but dumping ACPI tables from a guest running the 
old and new bits produces the same output in both cases.




Feature #15916: bhyve upstream sync 2023 September
https://www.illumos.org/issues/15916#change-43755

* Author: Andy Fiddaman
* Status: In Progress
* Priority: Low
* Assignee: Andy Fiddaman
* Category: bhyve
* Difficulty: Medium
* Gerrit CR: 3044

This is a set of merges from bhyve in FreeBSD, summarised in the 
following table.


There is very little change to the kernel components, we already had 
several of the fixes there.

The biggest set of changes are around:
- ACPI table generation and loading them into the guest via the fwctl 
interfaces;

- A basic emulated E820 device;
- TPM pass-through.

Each line is prefixed by a set of flags showing which action was taken. 
The key for these is:



S - skipped
U - updated to match upstream
~ - partially taken
* - merged
F - only freebsd-specific code changed
A - already had



* 1 bhyve: Avoid triggering false -Wfree-nonheap-object warnings.
* 2 bhyve: Remove vmctx argument from PCI device model methods.
*F 3 bhyve: Fix a global buffer overread in the PCI hda device model.
*F 4 bhyve: Fix a buffer overread in the PCI hda device model.
S 5 vmm: take exclusive mem_segs_lock when (un)assigning ppt dev
S 6 vmm: take exclusive mem_segs_lock in vm_cleanup()
S 7 vmm: fix use after free in ppt_detach()
S 8 vm: centralize VM_BATCHQUEUE_SIZE definition
* 9 53545967642d850eee4f2dd9fa27cae52ae981b9 vtd: Increase DRHD_MAX_UNITS
S 10 vmm: avoid spurious rendezvous
S 11 vmm: purge EOL release compatibility
S 12 vmm: Collapse identical case statements in vlapic_icrlo_write_handler()
S 13 vmm: Remove an unneeded initialization of "retu"
S 14 vmm: Fix AP startup compatibility for old bhyve executables
* 15 bhyve: add helper struct for acpi device handling
* 16 bhyve: add helper func to add acpi resources
* 17 bhyve: add helper func to write a dsdt entry
* 18 bhyve: maintain a list of acpi devices
* 19 bhyve: add basic qemu fwcfg implementation
* 20 bhyve: add emulation for the qemu fwcfg selector port
* 21 bhyve: add emulation for qemu's fwcfg data port
* 22 bhyve: add helper to add fwcfg items
* 23 bhyve: add common fwcfg items
S 24 vmm: fix restore of TSC offset
S 25 bhyve: fix restore of kernel structs
S 26 bhyve: fix resume for vms with guest_ncpus > 1
* 27 bhyve: remove redundant variable
* 28 bhyve: Remove useless return at the end of void function
* 29 bhyvectl: Address compiler warnings and bump WARNS
S 30 bhyvectl: do not return garbage from send_message
S 31 bhyvectl: correct socket_fd closing in send_message
S 32 bhyvectl: don't leak nvlist in send_message
S 33 libvmm: add missing ioctl's to vm_ioctl_cmds
S 34 bhyve: don't flush readonly device at blockif_pause
S 35 bhyve: add cap limits for ipc socket
S 36 bhyve: exit with EX_OSERR if init checkpoint or restore ti

Re: [oi-dev] Scrambled text when using text installer on qemu-kvm

[Till Wegmueller]

Hey Paul

It can sometimes happen with simple Graphics and the Virtual Graphics 
cards seems to have an impact.


To be able to make an assessment I would need the full config (libvirt 
or shell script) that launched the VM and the versions involved. Also 
was this via VNC/SPICE or SDL?


-Till

On 09.12.2023 13:36, John Paul Adrian Glaubitz wrote:

Hi!

I have been playing around with OpenIndiana inside qemu-kvm and I'm so
far very happy with what I am seeing.

However, I noticed that the text installer did not work properly inside
qemu-kvm since the text was not scrambled with some characters seemingly
using wrong encoding and also key code not working correctly.

I tried switching to a different terminal type but that did not help. I
eventually managed to install OpenIndiana without problems using the
grapical installer but I was wondering whether anyone else has seen these
issues with the text installer and whether these should be reported as
a bug.

Thanks,
Adrian



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] dlc.openindiana.org is down

[Till Wegmueller]

Hi Marcel

Sorry, I didn't see the mail.

It's back up and probably has been since the 11th.


-Till

On 11.10.2023 13:30, Marcel Telka wrote:

Hi,

The download server dlc.openindiana.org seems to be down.
Please fix it.


Thank you.



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] how to change local build repo prefix

[Till Wegmueller]

Hi Stephan

Soory did not get that it was about illumos-gate.
For illumos-gate there is a dedicated tool called onu that does all that 
for you. No need for oi-userland


https://illumos.org/man/1ONBLD/onu

Greetings
Till

On 30/10/2022 05.05, Stephan Althaus wrote:

On 10/29/22 17:25, Till Wegmueller wrote:
The publisher is set to userland for a specific reason. It makes it 
easy to tell pkg to install the package from the openindiana.org 
publisher if a newer version makes it there. If you change the 
publisher that prevents the you from being able to uninstall all 
userland publisher provided packages at once.


However here are two ways.

1. Set the environment variable PUBLISHER to "openindiana.org" the 
Makefiles respect what is inside this env variable while setting their 
variable.


2. Setup userland as publisher without source `pkg set-publisher 
--non-sticky userland` and then whenever you need to install a package 
you can do `pkg install -g $WS_TOP/i386/repo $PKG`



Hope this helps
-Till

On 29/10/2022 08.20, s...@pandora.be wrote:


There is a variable PUBLISHER and CONSOLIDATION in shared-macros.mk 
which is set to userland.


I haven't tried setting PUBLISHER to something else, or maybe I once 
tried, I can't remember,
perhaps setting PUBLISHER=squeak to publish in a repo specifically 
for squeak.


However I wonder why you'd want to set PUBLISHER to openindiana.org.

I suppose you could publish a custom package in userland and install 
it, or use a publisher name,

which is different in any case from openindiana.org.

If the package is 'locked' into openindiana.org consolidations you 
could try to change-facet


as reported by

  pkg facet

for example unlock squeak with 
version-lock.runtime.smalltalk.squeak=False


- Op 29 okt 2022 om 12:59 schreef Stephan Althaus 
stephan.alth...@duedinghausen.eu:



Hello!


I can't remember how to change the local repo prefix from userland to
openindiana.org

My goal is to build illumos-gate and install the packages to test a
patch for bug #15128

I've done that myself several years ago but it seems i can't find the
information :-/

Any hints are welcome :-)


Stephan


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


Hello Till!

I followed 1) and could install the patched kernel!

Thank you very much!

Stephan



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] how to change local build repo prefix

[Till Wegmueller]

The publisher is set to userland for a specific reason. It makes it easy 
to tell pkg to install the package from the openindiana.org publisher if 
a newer version makes it there. If you change the publisher that 
prevents the you from being able to uninstall all userland publisher 
provided packages at once.


However here are two ways.

1. Set the environment variable PUBLISHER to "openindiana.org" the 
Makefiles respect what is inside this env variable while setting their 
variable.


2. Setup userland as publisher without source `pkg set-publisher 
--non-sticky userland` and then whenever you need to install a package 
you can do `pkg install -g $WS_TOP/i386/repo $PKG`



Hope this helps
-Till

On 29/10/2022 08.20, s...@pandora.be wrote:


There is a variable PUBLISHER and CONSOLIDATION in shared-macros.mk which is 
set to userland.

I haven't tried setting PUBLISHER to something else, or maybe I once tried, I 
can't remember,
perhaps setting PUBLISHER=squeak to publish in a repo specifically for squeak.

However I wonder why you'd want to set PUBLISHER to openindiana.org.

I suppose you could publish a custom package in userland and install it, or use 
a publisher name,
which is different in any case from openindiana.org.

If the package is 'locked' into openindiana.org consolidations you could try to 
change-facet

as reported by

  pkg facet

for example unlock squeak with version-lock.runtime.smalltalk.squeak=False

- Op 29 okt 2022 om 12:59 schreef Stephan Althaus 
stephan.alth...@duedinghausen.eu:


Hello!


I can't remember how to change the local repo prefix from userland to
openindiana.org

My goal is to build illumos-gate and install the packages to test a
patch for bug #15128

I've done that myself several years ago but it seems i can't find the
information :-/

Any hints are welcome :-)


Stephan


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Can not install any gcc compiler

[Till Wegmueller]

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.


-Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] problems publishing rust

[Till Wegmueller]

Hello everyone

We now have support for CLONEY_MODE=hardlinks and CLONEY_MODE=copy in 
the makefiles


Would be a good chance to test those.

Alternatively COMPONENT_COPY_ACTION would be the proper variable to 
override instead of COMPONENT_PRE_CONFIGURE_ACTION


Greetings
Till

On 20/06/2022 17.07, Gary Mills wrote:

On Mon, Jun 20, 2022 at 09:21:58PM +0200, Andreas Wacknitz wrote:

We already had another guy trying to build a newer rust failing with the
same problem.
He found out that this is a known problem and there should already be a
fix (as far as I understood) but it hadn't been integrated in the release.
It looks like the situation didn't change in the last weeks.


Who is the other guy?  That makes three of us.

I had the same problem.  The solution is to copy the files in the
Makefile, instead of using symlinks or hard links:

   # Workaround the symlink name length 100 problem, but hope it is not 
neccessary
   # but also with patch src_tools_rust-installer_src_generator.rs.patch
   COMPONENT_PRE_CONFIGURE_ACTION = $(CP) -r $(SOURCE_DIR)/* $(@D)/





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] problems publishing rust

[Till Wegmueller]

Hey Fritz

That must be a syntax error in the Makefile. The resolver logic is built 
into OI-userland and should not get impacted by modifications to 
Makefile of a component. However for some reason 'RESOLVE_DEPS=' leaks 
into the final filepath. That should not happen.


Looking at you Makefile I think the culprit are the lines after 
'#COMPONENT_POST_INSTALL_ACTION= \' IIRC they need to be commented out 
too as they have a backslash thus parsing weirdness starts to happen.


Hope this helps
Greetings
Till

On 19/06/2022 06.05, Friedrich Kink via oi-dev wrote:
Thanks a lot for your response. Let me give some more information. This 
patch helped me to over come your issue:


--- rustc-1.61.0-src/src/bootstrap/builder.rs   2022-05-18 
03:29:36.0 +
+++ rustc-1.61.0-src/src/bootstrap/builder.rs.new 2022-06-06 
21:25:45.179276851 +

@@ -1304,7 +1304,7 @@
  Some("-Wl,-rpath,@loader_path/../lib")
  } else if !target.contains("windows") {
  rustflags.arg("-Clink-args=-Wl,-z,origin");
-    Some("-Wl,-rpath,$ORIGIN/../lib")
+   Some("-Wl,-rpath,/usr/clang/13.0/lib")
  } else {
  None
  };

Also I already use rustup (as suggested by Joshua, too) and this is my 
current Makefile (as metioned it gets compiled and installed but make 
REQUIRED_PACKAGES|publish stops immediately):


BUILD_BITS= 64
USE_OPENSSL11=  yes

include ../../../make-rules/shared-macros.mk

COMPONENT_NAME= rustc
COMPONENT_VERSION=  1.61.0
COMPONENT_FMRI= developer/lang/rustc
COMPONENT_SUMMARY=  Rust - Safe, concurrent, practical language
COMPONENT_CLASSIFICATION=   Development/Other Languages
COMPONENT_PROJECT_URL=  http://www.rust-lang.org
COMPONENT_SRC= $(COMPONENT_NAME)-$(COMPONENT_VERSION)-src
COMPONENT_ARCHIVE=  $(COMPONENT_SRC).tar.gz
COMPONENT_ARCHIVE_HASH= 
sha256:ad0b4351675aa9abdf4c7e066613bd274c4391c5506db152983426376101daed
COMPONENT_ARCHIVE_URL= 
https://static.rust-lang.org/dist/$(COMPONENT_ARCHIVE)

COMPONENT_LICENSE=  MIT or Apache-2.0
COMPONENT_LICENSE_FILE= LICENSE-APACHE

RUST_BOOTSTRAP_PATH=    $(BUILD_DIR)/$(MACH64)
#RUST_ARCH= x86_64-sun-solaris

include $(WS_MAKE_RULES)/common.mk

# GCC_VERSION =  7

# Put the bits cargo downloads in a private directory.  This could be 
cached

# somewhere more permanent, but it's important to make sure that a person's
# $HOME/.cargo isn't used.
RUST_VERSION=   $(COMPONENT_VERSION)
RUSTUP_HOME=    $(BUILD_DIR)/$(MACH64)
CARGO_HOME= $(BUILD_DIR)/$(MACH64)

PATH= $(CARGO_HOME)/bin:$(GCC_BINDIR):$(PATH.gnu)

#  workaround the symlink name lenght 100 problem, but hope it is not 
neccessary with

# but also with patch src_tools_rust-installer_src_generator.rs.patch
COMPONENT_BUILD_ENV+=   CARGO_HOME=$(CARGO_HOME)
COMPONENT_INSTALL_ENV+= CARGO_HOME=$(CARGO_HOME)
COMPONENT_TEST_ENV+=    CARGO_HOME=$(CARGO_HOME)
COMPONENT_BUILD_ENV+=   RUSTUP_HOME=$(RUSTUP_HOME)
COMPONENT_INSTALL_ENV+= RUSTUP_HOME=$(RUSTUP_HOME)
COMPONENT_TEST_ENV+=    RUSTUP_HOME=$(RUSTUP_HOME)
#   $(COMPONENT_DIR)/files/sym2hard.py; \

COMPONENT_PRE_CONFIGURE_ACTION += ( \
     $(CLONEY) $(SOURCE_DIR) $(@D); \
     cd $(@D); \
     export RUSTUP_HOME=$(RUSTUP_HOME); \
     export CARGO_HOME=$(CARGO_HOME); \
     export RUSTUP_INIT_SKIP_PATH_CHECK=yes; \
     curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh 
-s -- --no-modify-path --default-toolchain stable -y; \

     source $(CARGO_HOME)/env; \
     rustup install stable; \
     rustup default stable; \
     rustup show; \
     cargo install --root=$(CARGO_HOME) cbindgen; \
     );

PYTHON_VERSION= 3.9

# Need some help to pick the correct ar binary
GNUAR=$(GNUBIN)/ar
# getpwuid_r failure
CXXFLAGS += -D_POSIX_PTHREAD_SEMANTICS
CFLAGS += -D_POSIX_PTHREAD_SEMANTICS

# Add arch triplet to pkg macros
#PKG_MACROS+= RUST_ARCH="$(RUST_ARCH)"

# Rust expects the library path to be /usr/lib and is broken otherwise
RUSTC_LIBDIR= $(USRLIBDIR)
CLANG_ROOT= /usr/clang/13.0

CONFIGURE_OPTIONS = --prefix=$(CONFIGURE_PREFIX)
CONFIGURE_OPTIONS += --mandir=$(CONFIGURE_MANDIR)
CONFIGURE_OPTIONS += --bindir=$(CONFIGURE_BINDIR.$(BITS))
CONFIGURE_OPTIONS += --libdir=$(RUSTC_LIBDIR)
CONFIGURE_OPTIONS += --docdir=$(USRSHAREDOCDIR)/rust-$(COMPONENT_VERSION)
CONFIGURE_OPTIONS += --datadir=$(USRSHAREDIR)
CONFIGURE_OPTIONS += --sysconfdir=$(ETCDIR)
CONFIGURE_OPTIONS += --local-rust-root=$(RUST_BOOTSTRAP_PATH)
CONFIGURE_OPTIONS += --enable-extended   # Build and install cargo too.
CONFIGURE_OPTIONS += --default-linker=$(CC)
CONFIGURE_OPTIONS += --set rust.default-linker=$(CC)
CONFIGURE_OPTIONS += --enable-rpath
CONFIGURE_OPTIONS += --disable-codegen-tests
CONFIGURE_OPTIONS += --disable-dist-src
CONFIGURE_OPTIONS += --disable-llvm-static-stdcpp
CONFIGURE_OPTIONS += --enable-ninja
CONFIGURE_OPTIONS += --enable-vendor

Re: [oi-dev] oibuild server: someone working on this:maintenance Jun_06 svc:/application/pkg/server:PR-8313

[Till Wegmueller]

Hey Carsten

Looks like the Autocleanup in Jenkins is still broken. I noticed I 
forgot to add the cleanup script to the crontab. I did that now, so 
there will be fewer depotd when we work a lot. I ran the cleanup and all 
maintenance depotd servers are gone now.


Greetings
Till

On 15/06/2022 08.18, Carsten Grzemba via oi-dev wrote:

Hi,

there are a lot of pkg.depotd processes running on oibuild and a lot of 
SMF' pkg/server in maintenance state.
log reports: pkg.depotd: The path 
'/ws/jenkins/workspace/Organisation_oi-userland_PR-8303/i386/repo' does 
not contain a valid package repository.


--
Carsten

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] hipster 2021-10 failed to boot after pkg update

[Till Wegmueller]

Hey Klaus

svc:/system/metainit:default has been removed from the system, it can be 
deleted from the SMF database with svccfg


Recently the assumed independance from network and local filesystems has 
changed in illumos-gate dependency cycle with the Inclusion of Overlay 
networking. That has lead to dependency cycle problems one after updates 
(metainit). Please manually delete the metainit service. It should have 
been removed many updates ago but somehow did not.


Greetings
Till

On 28/05/2022 10.29, Klaus Elsbernd wrote:

Urgent help needed :-(

a server (supermicro/xeon) has been installed and upgraded to 2021-10. 
It was last updated on 2021:12:12. Today I updated the packages with


pkg update

Now the system failed to boot into multi-user/single-user mode with the 
following services not started:


Enter user name tor system maintenance (control-d to bypass): root
Enter root password (control-d to bypass): single-user privilege 
assigned to root on /dev/conso1e.

Entering System Maintenance Mode
May 28 14:47:56 su: ' su root' succeeded for root on /dev/console
The illumos Project illumos-b0d58672df May 2022 root@serv-1100:/root# 
svcs -x svc:/system/metainit:default (SVM initialization)

State: maintenance since Sat May 28 14:46:50 2022
Reason: Completes a dependency cycle.
See: http://i1lumos.org/msg/SMF-8000-HP
See: metainit(lM)
Impact: This service is not running.
root@serv-1100:/root# beadm list
BE    Active    Mountpoint    Space    Policy Created
openindiana-2020:06:11    -    -    62.03M    static 2020-06-11 16:53
openindiana-2020:08:10  -    -    11.97M    static 2020-08-10 16:44
openindiana-2020:12:29  -    -    46.41M    static 2020-12-29 13:54
openindiana-2021:01:29  -    -    22.00M    static 2021-01-29 12:37
openindiana-2021:05:06  -    -    11.88M    static 2021-05-06 19:01
openindiana-2021:05:06-backup-l  -    -    128K    static 2021-05-14 15:17
openindiana-2021:06:05  -    -    1.906    static 2021-06-05 12:21
openindiana-2021:06:05-1  -    -    16.68M    static 2021-06-05 20:08
openindiana-2021:12:12  -    -    14.90M    static 2021-12-12 17:40

open!ndiana-2022:05:28    NR    /  43.356    static 2022-05-28 11:01

The machine is booting OpenIndiana Hipster 2021.10 version 
illumos-b0d58672df 64-bit. Some notable errors


acpinex: cpu@0, cpudrv0
/fw/sb@0/socket@0/cpu@0 (cpudrv0) online
pseudo-device: cld0
cld0 is Zpseudo/cld@0
sorry, variable 'ip_squeue_worker_wait' is not defined in the 'ip' module
PCI Express-device: pci,3cB2@l. pcieb0

One message appeared on the console, indicating an error with a NVIDIA 
module. But there is no NVIDIA graphic card installed:


/kernel/drv/amd64l/nvidia.modeset: undefined symbol 'nvidia_get_rm_ops'
WARNING: mod_load: cannot load module 'nvidia.modeset'
WARNING: nvidia_modeset: unable to resolve dependency, module 'nvidia' 
not found


This is the second machine I lost. The only solution was then to boot 
the previous boot environment 2021:12:12.


Any ideas?

Klaus


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] What to do with clang-90?

[Till Wegmueller]

Hi Gary

Clang-13 is adequate for our needs and should be used for rust going 
forward.


Obsoleting clang-90 is a good option.

-Till

On 11/05/2022 18.53, Gary Mills wrote:

I'm investigating clang-90 with a view to removing python 3.5 from OI.
The version is already the latest of 9.0 that is available, making a
version upgrade impossible.  We already clang-13, a recent version of
the clang compiler.  I'm left with only two options.  Should I
obsolete clang-90, or should I leave it part of OI, but attempt to
upgrade the version of python that it uses?  If I obsolete clang-90,
is clang-13 already adequate in OI?




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] libxslt-1.1.35

[Till Wegmueller]

I can think of a few reasons the Automagic is messing things up here.

It could be a leftover from a previous generated version with different 
options or something that got installed between the generation of 
sample-manifest and the other publish run and the second run now picks 
that up.


Seeing that the libxsltmod.cpython-39.so is missing but libxsltmod.so is 
there I would try to understand how the Python Versions are set. Meybe 
something that got changed in the last rebase to oi-hipster? Maybe 
fixing python versions properly helps?



Thats all I can come up with at the moment. Good luck!
-Till

On 07.03.22 09:52, Klaus Ziegler wrote:

Hi,

I'm currently working on an update from libxslt-1.1.29 to 1.1.35,
so far I'm done, but at the time I try to publish I get the following 
error:


/usr/bin/pkgdepend generate -m -d 
/ws/oi-userland/components/library/libxslt/build/prototype/sparc/mangled 
-d /ws/oi-userland/components/library/libxslt/build/prototype/sparc -d 
/ws/oi-userland/components/library/libxslt/build -d 
/ws/oi-userland/components/library/libxslt -d libxslt-1.1.35 
/ws/oi-userland/components/library/libxslt/build/manifest-sparc-libxsl-39.mangled 
 >/ws/oi-userland/components/library/libxslt/build/manifest-sparc-libxsl-39.depend
Couldn't find 
'usr/lib/python3.9/vendor-packages/__pycache__/libxslt.cpython-39.pyc' 
in any of the specified search directories:

     /ws/oi-userland/components/library/libxslt
     /ws/oi-userland/components/library/libxslt/build
     /ws/oi-userland/components/library/libxslt/build/prototype/sparc
  /ws/oi-userland/components/library/libxslt/build/prototype/sparc/mangled
     /ws/oi-userland/components/library/libxslt/libxslt-1.1.35
Couldn't find 
'usr/lib/python3.9/vendor-packages/libxsltmod.cpython-39.so' in any of 
the specified search directories:

     /ws/oi-userland/components/library/libxslt
     /ws/oi-userland/components/library/libxslt/build
     /ws/oi-userland/components/library/libxslt/build/prototype/sparc
  /ws/oi-userland/components/library/libxslt/build/prototype/sparc/mangled
     /ws/oi-userland/components/library/libxslt/libxslt-1.1.35

indeed both files aren't in the proto area, when I remove these lines 
from the manifest:

file path=usr/lib/python3.9/vendor-packages/libxslt.py
file path=usr/lib/python3.9/vendor-packages/libxsltmod.so

I can publish, how can I get rid off this pkgdepend error?

Many Regards
Klaus


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Future of PostgreSQL on OpenIndiana

[Till Wegmueller]

To Clarify a bit about the Concerns here

We are actively participating in the PostgreSQL porting effort same as 
with the golang and Java one. So I would be very surprised if compiling 
fails :)



What is our concern is that when we compile Postgresql14 as default 
client lib for other consumers, those may not be backwards compatible 
with older Servers/libraries.


So if somebody needs to install postgresql 10 but we compile against 14 
they are in trouble.


I think Yes we should go to 14 this time and we should ensure that older 
PostgreSQL cannot override the default (14) or that we remove them from 
system and ask users to compile those versions that they need for long 
term support themselves. We are Rolling release afterall and even 
Archlinux only has 13. So when we do this now only providing 14 in the 
system pre packaged is the best option for our resources.


Continued participation in the CI and porting efforts of Postgres will 
ensure it will be able to compile it with enough certainty that people 
will be able to do it easily.


This should ensure that we only need to do less migration work per 
release we switch and that we need to switch fewer releases. Also I saw 
Citus Extension coming in with 14 which I would love to start to use :)


Greetings
Till

On 26.02.22 08:16, Andreas Wacknitz wrote:

Hi all,

at the moment PostgreSQL 9.6 is our version that is being used for all
packages that need PostgreSQL. This version is not supported upstream
for some months now. The oldest supported version is 10 and this would
be the obvious new version to use for us.
Alas, obsoleting a PostgreSQL version in OpenIndiana means some work to
be done and it looks like nobody is interested enough to do this work
regularly.

So, my question is how we should proceed with PostgreSQL. Obsoleting 9.6
and using 10 as our default would mean that in less than 9 months
according to https://www.postgresql.org/support/versioning/ we will need
to touch PostgreSQL again. We will need a volunteer to do this or we
might think about skipping some versions of PostgreSQL now.

What is your opinion?

Andreas


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] /usr/libexec/dovecot/anvil crashes immediately

[Till Wegmueller]

Hello

A quick quote I want to have people keep in mind from the epoll manpage 
'man epoll'


tl;dr epool is for compatibility purposes it is not intended as a full 
features replacement. Please do not use it if possible. It works but 
there will be dragons.


```
The epoll facility is implemented for purposes of offering
   compatibility to and portability of Linux-borne applications; native
   applications should continue to prefer using event ports via the
   port_create(3C), port_associate(3C) and port_getn(3C) 
interfaces.  In
   particular, use of epoll in a multithreaded environment is 
fraught with
   peril; even when using EPOLLONESHOT for one-shot events, there 
are race
   conditions with respect to close(2) that are unresolvable.  (For 
more

   details, see the aborted effort in Linux to resolve this via the
   proposed EPOLL_CTL_DISABLE operation.)  The event port facility 
-- like

   the BSD kqueue facility that inspired it -- is designed to deal with
   such issues via explicit event source dissociation.
```

Greetings
Till

On 12.02.22 17:37, Bob Friesenhahn wrote:

On Sat, 12 Feb 2022, Stephan Althaus wrote:


In the snipplet that Mr Al Slater communicated, it looks like there 
are linux-specific epoll details that are not working with illumos. 
Apples and apples can be different :-)


This is quite possible. I should mention that I am running Dovecot in a 
zone.  I am not quite sure if I am actually using chroot.



Have a nice day !
P.S. After several weeks of cloudy misty weather the sun is back again 
here in Germany. Welcome!!


Nice to hear.

Bob


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] /usr/libexec/dovecot/anvil crashes immediately

[Till Wegmueller]

Hello Fritz

It talks about a failed code assertion so something went out of expected 
bounds. Can you check if doevecot wrote something more usefull to syslog?


Here it just says "file %s: line %d (%s): assertion failed: (%s)"
But not the actual assertion failure message.

The one below that is
#8  0x7ffef056048b in io_loop_handle_add (io=0x42d7c0) at 
/usr/src/myoi-userland/components/mail/dovecot/dovecot-2.3.18/src/lib/ioloop-poll.c:94

ctx = 0x423180
condition = IO_READ
old_count = 3221223792
index = 0
old_events = 59
fd = 4
__func__ = "io_loop_handle_add"

But I can't tell if thats the panic or why dovecots panics here.

-Till

On 09.02.22 16:45, Friedrich Kink via oi-dev wrote:
Sent this already to dovecot mailinglist without response so far. Maybe 
someone reading this list can help. Unfortunately it did not show up 
during the test run of the package and I used earlier versions without 
this problem.



Dear list,

I built a dovecot package for openindiana (which is a Solaris 
derivative) from latest version 2.3.18. Everything compiles and builds 
fine without any issue. Even subsequent installation and startup of main 
dovecot process works as expected. But execution of 
/usr/libexec/dovecot/anvil immediately crashes. To get some more 
meaningful backtrace I compiled with -g. Below some facts of my 
environment and a backtrace. Maybe some of you are more familiar with 
this kind of issue as I, and can give some hint or share ideas how to 
nail down the problem. Or can it be a configuration issue? BTW it is 
running in a so-called zone. And former versions, I don't know exactly 
but I believe up to 2.3.17, did not show this crash.


gcc --version
gcc (OpenIndiana 7.5.0-il-0) 7.5.0

Configure parameters:

gcc_OPT = -g

CONFIGURE_OPTIONS+= --sysconfdir=/etc \
     --localstatedir=/var \
     --with-gssapi=plugin \
     --with-ldap=plugin \
     --with-sql=plugin \
     --with-lua=plugin \
     --with-ssl=openssl \
     --with-ioloop=poll \
     --with-notify=none \
     --with-sodium \
     --with-mysql \
     --with-pgsql \
     --enable-static=no \
     --without-systemd \
     SSL_CFLAGS=-I/usr/openssl/1.1/include \
     SSL_LIBS="-L/usr/openssl/1.1/lib/amd64 -lssl 
-lcrypto" \

     LDFLAGS="-lldap_r"

Backtrace:

(gdb) bt full
#0  0x7fff5d2e6f2a in _lwp_kill () from /lib/64/libc.so.1
No symbol table info available.
#1  0x7fff5d2dd7f0 in thr_kill () from /lib/64/libc.so.1
No symbol table info available.
#2  0x7fff5d27ae7e in raise () from /lib/64/libc.so.1
No symbol table info available.
#3  0x7fff5d254ad8 in abort () from /lib/64/libc.so.1
No symbol table info available.
#4  0x7ffef05367c0 in default_fatal_finish (type=LOG_TYPE_PANIC, 
status=0) at 
/usr/src/myoi-userland/components/mail/dovecot/dovecot-2.3.18/src/lib/failures.c:459
     backtrace = 0x4178b8 
"/usr/lib/amd64/dovecot/libdovecot.so.0.0.0'backtrace_append_libc+0x4c 
[0x7ffef0522042] -> 
/usr/lib/amd64/dovecot/libdovecot.so.0.0.0'backtrace_append+0x18 
[0x7ffef05221c5] -> /usr/lib/amd64/dovecot/li"...

     recursed = 0
#5  0x7ffef0536827 in fatal_handler_real (ctx=0x7fffb820, 
format=0x7ffef05d8730 "file %s: line %d (%s): assertion failed: (%s)", 
args=0x7fffb850)
     at 
/usr/src/myoi-userland/components/mail/dovecot/dovecot-2.3.18/src/lib/failures.c:471

     status = 0
#6  0x7ffef0536871 in default_fatal_handler (ctx=0x7fffb820, 
format=0x7ffef05d8730 "file %s: line %d (%s): assertion failed: (%s)", 
args=0x7fffb850)
     at 
/usr/src/myoi-userland/components/mail/dovecot/dovecot-2.3.18/src/lib/failures.c:479

No locals.
#7  0x7ffef0536aed in i_panic (format=0x7ffef05d8730 "file %s: line 
%d (%s): assertion failed: (%s)") at 
/usr/src/myoi-userland/components/mail/dovecot/dovecot-2.3.18/src/lib/failures.c:524
     ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0, 
timestamp_usecs = 0, log_prefix = 0x0, log_prefix_type_pos = 0}
     args = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 
0x7fffb930, reg_save_area = 0x7fffb870}}
#8  0x7ffef056048b in io_loop_handle_add (io=0x42d7c0) at 
/usr/src/myoi-userland/components/mail/dovecot/dovecot-2.3.18/src/lib/ioloop-poll.c:94

     ctx = 0x423180
     condition = IO_READ
     old_count = 3221223792
     index = 0
     old_events = 59
     fd = 4
     __func__ = "io_loop_handle_add"
#9  0x7ffef055c1ab in io_add_file (ioloop=0x423070, fd=4, 
condition=IO_READ, source_filename=0x7ffef05d9f48 
"/usr/src/myoi-userland/components/mail/dovecot/dovecot-2.3.18/src/lib/lib-signals.c",
     source_linenum=192, callback=0x7ffef05698f4 , 
context=0x0) at 

Re: [oi-dev] elegant way to get leaf packages?

[Till Wegmueller]

Hey Tim

You basically need to do what you are doing, but you can limit your 
search to local with -l parameter to pkg search. That would result in 
your local leaf packages. To get the full list for OI, the simplest way 
is to grep the Makefiles for 32bit builds. They are explicitly mentioned 
there. From what I remember it should only be library packages and big 
hitters like libreoffice.


There is a feature in omnios PKG which we could port at some point 
(autoremove) and one could use the python API to write a script to do 
that. But that would also call a lot of search queries.


-Till

On 26.12.21 15:20, Tim Mooney via oi-dev wrote:

In regard to: Re: [oi-dev] elegant way to get leaf packages?,...:


I am not sure I understand your question.  Please clarify.


I'm using "leaf" in the same sense as in a computer science tree
structure; a node that does not have any descendants.

 https://en.wikipedia.org/wiki/Tree_(data_structure)

A tree isn't the best model for package dependencies; a directed graph
is better, but the terminology for a node with no exiting vertices
isn't as clear, so I used "leaf" thinking everyone would understand
what I was asking for.  Sorry if that just made things worse.

A package like 'glib' or 'python-39' have many other packages that depend
upon them.  glib and python-39 are *not* leaf packages.

An example of a 'leaf' package would be 'media/vlc'.  There are
(currently) no other OI packages that list media/vlc as a dependency.
Leaf packages are typically "end user applications", but even something
like 'editor/vim' is not a leaf, because it has at least one real package
(editor/gvim and SUNWvim) that depends upon it.  The distinction is a
little fuzzy here because it also has 'mate_install' and 'server_install'
as dependencies, but for my purposes I wouldn't count those.

My reason for asking is that I wanted to get a complete list of all
leaf packages for OI, and then see which of those packages still ship
32 bit binaries.  I'm just trying to get an idea of easy components for
conversion to be 64 bit only.

pkg exact-install  installs a package but removes all 
"leaf packages" (?) that are not a dependency of the given package.


Thanks for the suggestion about exact-install, but for what I'm trying to
identify, it's not really an option.  It only looks at a portion of the
dependency graph.

As I said in my original question, I know how to generate the list using
a brute force method.  I was just wondering if there was a better method
that doesn't require running hundreds or thousands of 'pkg' commands to
find all the leaf nodes.

Thanks,

Tim


All-

Is there an elegant way using pkg (or some other method) to get all
OpenIndiana "leaf" packages, i.e. packages that are not a dependency of
some other package?

I know how to get this using a brute-force method that is essentially

all_packages=`pkg list -a | some filtering here`
for p in `echo $all_packages`
do
pkg search -r -o pkg.name "depend:require:$p" > depends-upon-$p
done

I'm just wondering if there is a more clever, or perhaps less intensive
on the publisher server, way to get the same info?




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Some packages did not build anymore in userland

[Till Wegmueller]

Hi Alexander

Yes this is known. We the Maintainers do not test full rebuild 
regularly. Is something blocking you from contributing your efforts? Can 
I help you get your results incorporated into userland? We would love to 
have oi-userland completely build again.


Greetings
Till

On 22.12.21 16:58, Alexander Jung wrote:

Hello,

i build the whole oi-userland from time to time, but in the last time 
there are many packages they did not build anymore. I tried a fresh 
install and fresh sync of oi-userland but it is the same.



For example glib stops with this message ...

Option buildtype is: plain [default: debugoptimized]
Found ninja-1.10.2 at /usr/bin/ninja
/usr/bin/touch 
/code/workspace/oi-userland/components/library/glib/build/i86/.configured
(/usr/bin/env LD_OPTIONS="-M /usr/lib/ld/map.noexstk -M 
/usr/lib/ld/map.noexdata -M /usr/lib/ld/map.pagealign -Bdirect -z 
ignore" LD_EXEC_OPTIONS="-z aslr=disable" 
PKG_CONFIG_PATH="/usr/openssl/1.0/lib/32/pkgconfig:/usr/lib/pkgconfig" 
DFLAGS= /usr/bin/ninja -C 
/code/workspace/oi-userland/components/library/glib/build/i86 -j2 )
ninja: Entering directory 
`/code/workspace/oi-userland/components/library/glib/build/i86'

[395/1081] Compiling C object gio/gresource.p/gresource-tool.c.o
FAILED: gio/gresource.p/gresource-tool.c.o
/usr/gcc/9/bin/gcc -Igio/gresource.p -Igio -I../../glib-2.66.8/gio 
-Igmodule -I../../glib-2.66.8/gmodule -I. -I../../glib-2.66.8 -Iglib 
-I../../glib-2.66.8/glib -Igobject -I../../glib-2.66.8/gobject 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
-std=gnu99 -O3 -D_GNU_SOURCE -fno-strict-aliasing 
-DG_DISABLE_CAST_CHECKS -Wduplicated-branches -Wimplicit-fallthrough 
-Wmisleading-indentation -Wstrict-prototypes -Wunused 
-Wno-unused-parameter -Wno-bad-function-cast -Wno-cast-function-type 
-Wno-pedantic -Wno-format-zero-length 
-Werror=declaration-after-statement -Werror=format=2 
-Werror=implicit-function-declaration -Werror=init-self 
-Werror=missing-include-dirs -Werror=missing-prototypes 
-Werror=pointer-arith -m32 -O3 -Wno-error=format-nonliteral 
-D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -MD -MQ 
gio/gresource.p/gresource-tool.c.o -MF 
gio/gresource.p/gresource-tool.c.o.d -o 
gio/gresource.p/gresource-tool.c.o -c 
../../glib-2.66.8/gio/gresource-tool.c

In file included from ../../glib-2.66.8/gio/gresource-tool.c:32:
/usr/include/libelf.h:43:2: error: #error "large files are not supported 
by libelf"

    43 | #error "large files are not supported by libelf"
   |  ^
[396/1081] Compiling C object gio/gio-querymodules.p/giomodule-priv.c.o
ninja: build stopped: subcommand failed.

Or another problem is that GCC-7 did not build the gobjc stuff.


Do i have messed something up?


Greetings an always thanx for that nice OS,
Alex



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Some packages did not build anymore in userland

[Till Wegmueller]

Hi Gary,

Can we have that Patch?

-Till

On 22.12.21 19:07, Gary Mills wrote:

On Wed, Dec 22, 2021 at 08:58:12PM +0100, Alexander Jung wrote:


i build the whole oi-userland from time to time, but in the last time there
are many packages they did not build anymore. I tried a fresh install and
fresh sync of oi-userland but it is the same.

For example glib stops with this message ...

[...]

/usr/gcc/9/bin/gcc -Igio/gresource.p -Igio -I../../glib-2.66.8/gio -Igmodule
-I../../glib-2.66.8/gmodule -I. -I../../glib-2.66.8 -Iglib
-I../../glib-2.66.8/glib -Igobject -I../../glib-2.66.8/gobject
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-std=gnu99 -O3 -D_GNU_SOURCE -fno-strict-aliasing -DG_DISABLE_CAST_CHECKS
-Wduplicated-branches -Wimplicit-fallthrough -Wmisleading-indentation
-Wstrict-prototypes -Wunused -Wno-unused-parameter -Wno-bad-function-cast
-Wno-cast-function-type -Wno-pedantic -Wno-format-zero-length
-Werror=declaration-after-statement -Werror=format=2
-Werror=implicit-function-declaration -Werror=init-self
-Werror=missing-include-dirs -Werror=missing-prototypes
-Werror=pointer-arith -m32 -O3 -Wno-error=format-nonliteral
-D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -MD -MQ
gio/gresource.p/gresource-tool.c.o -MF gio/gresource.p/gresource-tool.c.o.d
-o gio/gresource.p/gresource-tool.c.o -c
../../glib-2.66.8/gio/gresource-tool.c


I've seen that behavior too.  It's a bug in ninja, but the developer
refuses to accept complaints about it.  Ninja unconditionally defines
_FILE_OFFSET_BITS=64 .  The bug affects only 32-bit builds, but
sometimes you need a 32-bit build.  It's easily fixed on OI, by a
patch that removes the offending statement.  There's almost no way to
fix it when building with ninja, other than building some other way.




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Porting an exFAT driver

[Till Wegmueller]

Hello

Pr checker has been updated so this should no longer happen.

It's actually odd though that it happened in the first place. It wasn't 
happening on PR7389 Anyway fixed.


Let me know if you get another problem with that machine.

-Till

On 14.12.21 09:01, Andreas Wacknitz wrote:

Am 14.12.21 um 11:58 schrieb Jean-Pierre André:

I have been trying to package for OpenIndiana a driver and utilities
developed by Andrew Nayenko and licensed as GPL2 for the exFAT file
system promoted by Microsoft as a replacement for FAT.

The packaging went fine locally (by gmake publish), but the pull
request check fails on :

aclocal: error: aclocal: file '/usr/share/aclocal/wxwin.m4' does not
exist
(see https://github.com/OpenIndiana/oi-userland/pull/7389)

You can ignore this error. It's from our new build server which isn't
yet updated automatically and runs with old versions of wxwidgets and
wxwidgets-3.
This has been fixed but the test server needs to be updated manually
again and probably updates itself regularly like our main build server 
does.




I have no idea of what triggers this, and as this does not occur
locally, I cannot make my own tries. I suspect having a difference of
versions in my autotools (fully updated). I also suspected the use of
the deprecated macro AC_PROG_CC_C99 had something do do with that,
but removing it does not bring any change.

I am at a loss over what else I could try, so I am giving up until
somebody points me at what I am doing wrong.


You aren't doing anything wrong.

Andreas

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] upstreaming our libtool search_path patch

[Till Wegmueller]

No Objections here.

As Bob and you have stated it is easier. And I see no reason to 
complicate this.


-Till

On 24.11.21 19:26, Tim Mooney via oi-dev wrote:


All-

After years of being without one, libtool has a maintainer again.
The first step he or she is taking is to go through the backlog of patches
from the various Linux and BSD distros, to apply any that are generally
useful.

We're currently carrying two patches against libtool, while Oracle's
solaris-userland has just one:

 
https://github.com/oracle/solaris-userland/blob/master/components/libtool/patches/000-64-bit-sys_dlsearch_path.patch

Theirs appears to be just an alternate approach to solving the same
problem as our first patch.

Any objection to pointing the maintainer at the solaris-userland patch
and letting them know that that patch is beneficial for both commercial
Solaris and for OpenIndiana?  I would like to get one of the patches
into upstream, and it seems easiest to vote for the solaris-userland one
as acceptable to both OSes.

Tim


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Does OI use gtk+ or gtk+3, or both?

[Till Wegmueller]

An alternative Pragmatic approach would be to disable the GUI components 
and leave the CLI, Which is not python IIRC


-Till

On 09.11.21 19:44, Andreas Wacknitz wrote:


Am 11/9/21 um 17:56 schrieb Gary Mills:

On Sun, Nov 07, 2021 at 06:19:27PM -0800, Alan Coopersmith wrote:

On 11/7/21 3:43 PM, Gary Mills wrote:


Now, I've come to "nmap".  That package indeed depends on python 2.7

That's an upstream limitation:
https://github.com/nmap/nmap/issues/1176
https://github.com/nmap/nmap/pulls?q=is%3Apr+python3+is%3Aopen

Well, that solves that problem.  OI must remove nmap at the same time
as it obsoletes python 2.7 .  Nmap can return once it's able to be
built with python 3.7 or 3.9 .


Or, being pragmatic instead of dogmatic, we update whatever is possible
to python3 and keep python2 for packages that cannot be updated. Nmap
ist probably an important package for some users.

Cheers,
Andreas


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] gstreamer1 and OpenGL/EGL

[Till Wegmueller]

On 31.10.21 22:46, Tim Mooney via oi-dev wrote:


Since Alan sent this email, I have run into at least one component that
makes heavy use of meson's cpu_family().  If our meson included this
patch, I think it might help some components handle our multi-lib builds
better.

There's also a PR in meson's queue for rethinking meson's
host_machine/build_machine objects:

 https://github.com/mesonbuild/meson/issues/6361



Hey Tim

According to my Github feed Integration of the patch happened in #7238[0]


-Till

[0] https://github.com/OpenIndiana/oi-userland/pull/7238

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] gstreamer1 and OpenGL/EGL

[Till Wegmueller]

Ok, then it's a case of compilation Broken.

Please add a note to the makefile to note this finding about QT5 so we 
have it for posterity.


On 27.10.21 22:32, Tim Mooney via oi-dev wrote:
In regard to: Re: [oi-dev] gstreamer1 and OpenGL/EGL, Till Wegmüller 
said...:



Is there any big change if we let meson decide it itself?


Yes, unfortunately.  If I don't specify anything GL-related, it also finds
Qt5 and qmake, but it gets the ABI wrong (it's using qmake to build 64 bit
Qt5-related code during the 32 bit build) and linking fails.

There is no option to just disable qt5, at least for these plugins.  There
is for at least one of the later sets of plugins.

Limiting what it could select for OpenGL was the only built-in way I found
to avoid the Qt5 linking failures.

I could go back and try patch out the Qt5 code, instead, but that's likely
more work.


Usually we only disable stuff if compilation is broken, so there is no
feature limit on purpose in OI. Just things that are broken or need
additional deps nobody had the time for.


I'll keep that in mind for future components.

Thanks!

Tim



On 26.10.21 21:44, Tim Mooney via oi-dev wrote:


All-

I'm working my way through updating the gstreamer1 components to the
latest version (1.16.2 -> 1.18.5).  They've switched from autoconf to
meson, so the biggest hurdle has been converting the Makefile to use
the new configuration options.

With the current 1.16.2, gst-plugins-base1 specifies

 CONFIGURE_OPTIONS += --disable-gles2

but nothing else OpenGL related.

Unfortunately, gst-plugins-base1 for 1.18.5 with meson doesn't have
the same option meanings, so there's no one-to-one mapping between our
old configuration and the new.  The meson_options related to OpenGL are

 # OpenGL integration library options
 option('gl_api', type : 'array', choices : ['opengl', 'gles2', 
'auto'],

 value : ['auto'],
 description : 'A comma separated list of opengl APIs to enable
 building against'
 )

 option('gl_platform', type : 'array',
 choices : ['glx', 'egl', 'cgl', 'wgl', 'eagl', 'auto'],
 value : ['auto'],
 description : 'A comma separated list of opengl platforms to
 enable building against'
 )

 option('gl_winsys', type : 'array',
    choices : ['x11', 'wayland', 'win32', 'winrt', 'cocoa',
 'dispmanx', 'egl', 'viv-fb', 'gbm', 'android', 'auto'],
    value : ['auto'],
    description : 'A comma separated list of opengl windows systems
 to enable building against. Supported values are x11, 
wayland,
 win32, winrt, cocoa, dispmanx, egl, viv-fb, gbm, and 
android'

 )

 option('egl_module_name', type : 'string',
 value : '',
 description : 'The file to pass to g_module_open to open the
 libEGL library (default: libEGL)'
 )

 option('opengl_module_name', type : 'string',
 value : '',
 description : 'The file to pass to g_module_open to open the
 libGL library (default: libGL)'
 )

 option('gles2_module_name', type : 'string',
 value : '',
 description : 'The file to pass to g_module_open to open the
 libGLESv2 library (default: libGLESv2)'
 )


 #
 # Feature option for opengl plugin and integration library
 #
 option('gl', type : 'feature',
 value : 'auto',
 description : 'OpenGL integration library and OpenGL plugin'
 )

 option('gl-graphene', type : 'feature',
 value : 'auto',
 description : 'Use Graphene in OpenGL plugin'
 )

 option('gl-jpeg', type : 'feature',
 value : 'auto',
 description : 'Use libjpeg in OpenGL plugin'
 )

 option('gl-png', type : 'feature',
 value : 'auto',
 description : 'Use libpng in OpenGL plugin'
 )


Now, with the available meson options, what I have (so far) specified 
for the

updated build is

 CONFIGURE_OPTIONS += -Dgl_api=opengl
 CONFIGURE_OPTIONS += -Dgl_platform=glx,egl
 CONFIGURE_OPTIONS += -Dgl_winsys=x11,egl
 CONFIGURE_OPTIONS += -Dgl-graphene=disabled


With those options specified, the updated manifest isn't missing 
anything

that was present in the 1.16.2 component.

It seems like some new stuff is being added, though:

  file path=usr/lib/pkgconfig/gstreamer-gl-1.0.pc
+file path=usr/lib/pkgconfig/gstreamer-gl-egl-1.0.pc
+file path=usr/lib/pkgconfig/gstreamer-gl-prototypes-1.0.pc
+file path=usr/lib/pkgconfig/gstreamer-gl-x11-1.0.pc

There are also new GL-related header files and several files related to
introspection (for the 64 bit build; the 32 bit build has introspection
disabled):

+file path=usr/lib/$(MACH64)/girepository-1.0/GstGLEGL-1.0.typelib
+file path=usr/lib/$(MACH64)/girepository-1.0/GstGLX11-1.0.typelib

+file path=usr/share/gir-1.0/GstGLEGL-1.0.gir
+file path=usr/share/gir-1.0/GstGLX11-1.0.gir


I also note that the existing package has depend

Re: [oi-dev] update of ca-certificates ?

[Till Wegmueller]

PR is open at https://github.com/OpenIndiana/oi-userland/pull/7173

-Till

On 14.10.21 14:40, s...@pandora.be wrote:


Right, the issue seems not Squeak specific but I happen to see it in Squeak.

Note that the OpenSSL support in Squeak is not perfect so I don't claim that 
there are no problems with the SSL plugin of Squeak, but in this case, it seems 
more a lower level, general issue.

https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/

https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

Regards,
David Stes

- Op 14 okt 2021 om 19:29 schreef oi-dev oi-dev@openindiana.org:


On Thu, 14 Oct 2021 at 10:26, s...@pandora.be  wrote:

# cd /etc/certs/CA
# rm DST_Root_CA_X3.pem
# svcadm restart ca-certificates

at the OS level - without changing anything in Squeak.


I had to do this recently as well for another application.


So should there be an update of the ca-certificates package in OpenIndiana ?


Yes, I believe there needs to be an update.


Cheers.

--
Joshua M. Clulow
http://blog.sysmgr.org

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] oi-vagrantfiles

[Till Wegmueller]

Hello Everyone

Repository is now setup and ready for PR's

Greetings
Till

On 23.09.21 15:52, s...@pandora.be wrote:


I wrote :


I'm not sure why the port_forwarding does not work.


I found out that port_forwarding in the Vagrantfile does work fine.

The solution is very simple and documented in the note at
http://docs.openindiana.org/contrib/getting-started/#prerequisites

you have to run mkdocs serve --dev-addr=0.0.0.0:8000
or mkdocs serve -a 0.0.0.0:8000

in the Vagrant guest VM in order to connect to it by firefox or another 
webbrowser from the host.

by default it only listens on 127.0.0.1:8000

The vagrantfile is a nice way to deploy a VM for oi-docs contributions,
best of all, this kind of OpenIndiana VM can be deployed on Linux;
or some other host.

David Stes

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OpenIndiana on HP Microserver Gen10 Plus?

[Till Wegmueller]

Hey Klaus

I am running a HPE Proliant Gen10 with latest OI hipster bits for Years 
now and I am happy with it. The Gen8 Also works flawlessly, simply buy a 
NAS or simple AHCI Controller configuration without the RAID controller. 
RAID controllers are BAD for OI and ZFS. Even in AHCI mode it's hard to 
tell if the Firmware does the right thing.


-Till

On 22.09.21 11:40, Klaus Elsbernd wrote:

Hello,

Has someone tested OpenIndiana on HP Microserver Gen10 Plus?

running it on HP Microserver Gen8 was not successful, because 
RaidControler seems not to work.


Best regards

Klaus

"Everything has been said, provided words do not change their meanings, 
and meanings their words."

Alpha 60

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] oi-vagrantfiles

[Till Wegmueller]

Hey David

Yeah I can setup a repo where you can push to. I think that is worth it 
for the Vagrantfiles. Can you send me your Github username off list?


-Till

On 21.09.21 14:55, s...@pandora.be wrote:


As a generalisation of the idea to have a Vagrantfile for Cuis and Squeak,
I created an oi-vagrantfiles project to setup VM's with vagrant.

The ability to deploy OpenIndiana with/by vagrant can be used for example to 
create a VM to have oi-docs or oi-userland contributions, or for running 
Smalltalk in a VM.

The Vagrantfile project is at https://sourceforge.net/projects/oi-vagrantfiles/

Currently there is the excellent Vagrantfile in the oi-userland repo,
by Adam Stevko and Michael Nowak and I copied that file (while retaining the 
copyright of course),
to the oi-vagrantfiles repo.

The idea of oi-vagrantfiles is to collect all sorts of Vagrantfiles for 
OpenIndiana development.

If there is interest, this could perhaps also be hosted at 
https://github.com/OpenIndiana/

David Stes

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] ruby 3.0.2

[Till Wegmueller]

While I can see your logic, I am afraid there wont be a package unless 
we make one. For one that I doubt Hashicorp makes one without us asking, 
and on the other hand it is not that easy to build IPS packages outside 
OI-userland. Which defines a lot of build time variables and structure. 
Also all of the people needed to make a review and get the software 
tested are in this community.


In any case a build from source Article will help. Can you make that?

If you are still up to make a OI package I would definitely help testing it.

-Till

On 13.09.21 15:37, s...@pandora.be wrote:


Ruby 3.0.2 builds on OpenIndiana Hipster:

$ /scratch/ruby-30/bin/ruby --version
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [i386-solaris2.11]

The following config line works to build ruby 3.0.2:

./configure --disable-dtrace --with-gcc --prefix=/scratch/ruby-30 
BISON=/scratch/bison-35/bin/bison

This is with a custom bison instead of the currently OI installed bison 3.7.6.

There's some gar (gnu ar) errors when dtrace is enabled.

The gem ext/ripper grammar has a problem with bison 3.7.6 , the generated 
ripper.c is generated by the Ruby developers using bison 3.5.1.

However when I try to use vagrant with ruby 3.0.2 that poses a problem because 
the bundle --binstubs exec step from:

https://github.com/hashicorp/vagrant

is not working.  While with the tradition ruby-2.7.4 it works fine.

There may be more experimental features in ruby-3.0.2 compared to ruby-2.7.4 so 
2.7.4 is preferable anyway.

So for the moment probably it just needs some testing (or a lot of testing) 
before IPS packaging this.

In fact "vagrant" can be used perfectly well from source ...

There could just be a community documentation page on docs.openindiana.org that 
documents how to install vagrant from source.  I'll make a PR for oi-docs to 
document this.

If a 'vagrant' IPS package is to be made, this would be more logically 
something for hashicorp,
since it is hashicorp's product.

Regards,
David Stes

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] virtualbox 6.1.26 ?

[Till Wegmueller]

They are in the progress to rewrite it to golang. I saw the code some 
time ago on their Github. But they are fighting to keep the ruby codes 
somehow available. Interested how they end up doing the rewrite.


In Any case a vagrant package would be nice.

Good luck packaging.

-Till

On 12.09.21 14:15, s...@pandora.be wrote:


As far as I can see vagrant works fine.

OpenIndiana is an excellent platform for vagrant with provider VirtualBox.

Vagrant also supports other providers such as VMware but obviously I use 
VirtualBox as provider.

Vagrant currently requires ruby and bsdtar (libarchive.de).
The Vagrant README file encourages you to compile your own ruby version which 
makes some sense.

Vagrant 2.2.19dev installs on top of ruby 2.7.4 fine.  It also works with the 
system provided ruby-26.

Vagrant is installing additional 'gems' and vagrant script/executable.

However on the Hashicorp (makers of vagrant) community list I've been warned 
that they are redesigning vagrant (supposedly) not to use ruby any longer (they 
may switch language - somebody said there).

I could give it a try ruby-27 and ruby-30 and see how far I get.

Regards,
David Stes

- Op 12 sep 2021 om 18:17 schreef Till Wegmueller toaster...@gmail.com:


Hello

Last time I checked vagrant did not build but good to know it now does
:) Any package would be welcome. Want to do an update to virtualbox and
vagrant/ruby?

-Till

On 12.09.21 07:05, s...@pandora.be wrote:



As I have stated before: We need more people helping with OI Hipster. We
lack contributions in almost every area:
creating/updating packages, testing and documentation. Things don't
happen magically. Efforts and engagement by volunteers is needed.
The companies involved in illumos seem only be interested in its server
use. So, the complex part of creating a desktop is up to the community...


This is true, I've already contributed docs under
http://docs.openindiana.org/handbook/community/ for Smalltalk-80 and TexLive
2021.

But of course there's an enormeous amount of other work to be done ...

Also keeping the docs up to date is a lot of work, I just noticed that the
TexLive docs still refer to TL 2020 not to the current TL 2021 ...  Same thing
for Squeak / Smalltalk the docs should be updated as well.

Regards,
David Stes


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] virtualbox 6.1.26 ?

[Till Wegmueller]

Hello

Last time I checked vagrant did not build but good to know it now does 
:) Any package would be welcome. Want to do an update to virtualbox and 
vagrant/ruby?


-Till

On 12.09.21 07:05, s...@pandora.be wrote:



As I have stated before: We need more people helping with OI Hipster. We
lack contributions in almost every area:
creating/updating packages, testing and documentation. Things don't
happen magically. Efforts and engagement by volunteers is needed.
The companies involved in illumos seem only be interested in its server
use. So, the complex part of creating a desktop is up to the community...


This is true, I've already contributed docs under 
http://docs.openindiana.org/handbook/community/ for Smalltalk-80 and TexLive 
2021.

But of course there's an enormeous amount of other work to be done ...

Also keeping the docs up to date is a lot of work, I just noticed that the 
TexLive docs still refer to TL 2020 not to the current TL 2021 ...  Same thing 
for Squeak / Smalltalk the docs should be updated as well.

Regards,
David Stes


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Status of OpenIndiana Wiki (Atlassian Confluence)

[Till Wegmueller]

In my opinion I would put the HTML under wiki.openindiana.org or another 
space.


Docs should only be the migrated docs.

-Till

On 11.09.21 18:27, James Madgwick wrote:


It seems I cannot create an account. The 'Sign Up' option is not
available "This installation of Confluence is not set up to permit
public signup".



Andreas has kindly created an account for me and I've been able to
complete the export.



I'm happy to take on the work of understanding what has already been
migrated and continuing the migration. I just need someone with an
account to do the space export.



I'll now start to look into this.

Do we want to add all the exported Confluence pages directly into the
Docs repo under an "archived Wiki" folder (containing HTML directly)? I
think it would be best to migrate content if possible and leave only
historical info (where there is no reason to migrate) in an "archived"
section, instead of having outdated duplicates. If in future anyone
really wants to browse the Wiki as it is today they can always use the
waybackmachine.


James

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Status of OpenIndiana Wiki (Atlassian Confluence)

[Till Wegmueller]

Hi James

It's not Offline just because the Vulnerability. It crashes on an 
ongoing basis. I know Wacki has been starting it whenever somebody 
asked. But not recently.


Ist there a good way to get a HTML export of the WIKI for migration 
purposes? If so we could make one and then just dump that to a Webserver 
and continue to migrate to docs.


-Till

On 11.09.21 14:08, James Madgwick wrote:

Hi,

I notice the old Wiki (https://wiki.openindiana.org) is giving "503
Service Unavailable". Recently a major vulnerability in old versions of
Confluence, including the version used on the Wiki, has been in the
news. I'm wondering if this is why the Wiki is down?

In any case, I had been making a list of the pages in the Wiki and what
content needed to be migrated. The eventual goal being to decommission
the Wiki once everything useful had been migrated. The majority of the
Wiki's content was already migrated to the Docs website in the last few
years.

If the Wiki has been forced offline, it would probably be easiest to
restore it only briefly to perform a full HTML export and use that in
the interim. Patching the Confluence vulnerability probably wouldn't be
worth it.


James

Vulnerability details:
https://us-cert.cisa.gov/ncas/current-activity/2021/09/03/atlassian-releases-security-updates-confluence-server-and-data
https://confluence.atlassian.com/doc/confluence-security-advisory-2021-08-25-1077906215.html
https://www.zdnet.com/article/us-cybercom-says-mass-exploitation-of-atlassian-confluence-vulnerability-ongoing-and-expected-to-accelerate/

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] dlc-origin (rsync) EOL?

[Till Wegmueller]

Hi Marcel

I assume better means it can detect create a diff faster?

I can see the point. I also think a fast diff for mirroring is nice. 
I'll have a look in the future to see to get that going. For now please 
switch to HTTP(S)


-Till

On 30.07.21 11:43, Marcel Telka wrote:

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.



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] dlc-origin (rsync) EOL?

[Till Wegmueller]

Hi Marcel

Everything is still in migration. As ISO's are onetime download So 
having rsync servers is not very usefull, as there is not much of a 
delta for each ISO.


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.


-Till

On 30.07.21 05:35, Marcel Telka wrote:

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.



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] What to do with python module dependancies?

[Till Wegmueller]

Hey Gary

There is two ways for a IPS package to have dependencies.
One manual in the .p5m file in the folder. Simply define a dependency 
action to the FMRI and set the conditional level.


Two automatically. The .p5m file in the folder is taken as input to the 
Packaging process, so everything you put there is run through pkgmogrify 
and pkgdepend utilities. These modify the file with transforms and 
automatically detected dependencies in turn. Have a look at the 
pkgdepend man page for details how that utility works. So anyhting 
pkgdepend does not detect has to be added to the .p5m file to assist the 
process. Another thing you can do is to add the package FMRI's to the 
REQUIRED_PACKAGES variable in the Makefile which will install the 
packages in the system during packaging. This can help the pkgdepend 
utility to detect dependencies if they are conditional.


Also note that there have been problems in the past for pkgdepend to 
detect conditional imports in python. So Adding them manually to the 
.p5m file may be required.


Greetings
Till

On 18.07.21 13:01, Gary Mills wrote:

On Sun, Jul 18, 2021 at 03:08:38PM +0100, Peter Tribble wrote:


I've also noticed the setup.py builds quite happily whether
dependencies
are present or not.
All I do is look at the requires.txt file. Usually present in the
.egg-info
directory, which may be present in the source or in the build tree.
(Some modules are smart enough to handle the fact that dependencies
vary between python versions, too.)


Thanks for the information; it was quite helpful.  I found the file
that you mentioned.  It lists the two modules that I've already
discovered, and two others conditionally.

Do I need to create the IPS dependancies myself, or does this happen
automatically?




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Have we finished migrating to Libera Chat?

[Till Wegmueller]

Hi James

Updated the mentions on the Webpage.

-Till

On 02.07.21 06:25, James Madgwick wrote:

Hi,

Libera Chat has just marked their one month milestone -
https://libera.chat/news/one-month-of-libera-chat. OI has had channels
on Libera Chat for much of that time and the old freenode channels have
seen little activity* since.

All the documentation still refers to freenode. Now that Libera Chat is
established, it is possibly time to bring the documentation up to date.

I've proposed a PR to update the main docs site:
https://github.com/OpenIndiana/oi-docs/pull/190

The OI homepage has mentions of freenode on these pages:
https://www.openindiana.org/community/
https://www.openindiana.org/community/support/
https://www.openindiana.org/community/getting-involved/

Whomever is responsible for the website (?) will need to update them.

What does everything think about this? It would be good to poll the
community somehow. In case some people want to keep using freenode and
keep it mentioned in the documentation. That seems very unlikely, but
it would be wrong to simply merge these changes without any warning or
consultation.

It would be beneficial to continue logging IRC messages as these can be
good source for reference. Logbot have made their archives available:
https://archive.logbot.info/. We could extract the OI channel logs from
here and add them somewhere?

Thanks,
James



* According to logbot.info (now no longer operating), the last message
   posted to #openindiana on freenode was June 9 - nobody replied. The
   last message with replies was on June 6. My logs indicate much more
   activity on the libera.chat #openindiana channel - the last message
   was on June 27 and plenty of activity throughout June. For oi-dev,
   there's no human messages since June 7 on freenode. On libera.chat
   oi-dev had messages a few days ago.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Have we finished migrating to Libera Chat?

[Till Wegmueller]

Wacki and I can update the Website.

I need to go through it this month anyway.
I'll have a look into it.

-Till

On 02.07.21 06:25, James Madgwick wrote:

Hi,

Libera Chat has just marked their one month milestone -
https://libera.chat/news/one-month-of-libera-chat. OI has had channels
on Libera Chat for much of that time and the old freenode channels have
seen little activity* since.

All the documentation still refers to freenode. Now that Libera Chat is
established, it is possibly time to bring the documentation up to date.

I've proposed a PR to update the main docs site:
https://github.com/OpenIndiana/oi-docs/pull/190

The OI homepage has mentions of freenode on these pages:
https://www.openindiana.org/community/
https://www.openindiana.org/community/support/
https://www.openindiana.org/community/getting-involved/

Whomever is responsible for the website (?) will need to update them.

What does everything think about this? It would be good to poll the
community somehow. In case some people want to keep using freenode and
keep it mentioned in the documentation. That seems very unlikely, but
it would be wrong to simply merge these changes without any warning or
consultation.

It would be beneficial to continue logging IRC messages as these can be
good source for reference. Logbot have made their archives available:
https://archive.logbot.info/. We could extract the OI channel logs from
here and add them somewhere?

Thanks,
James



* According to logbot.info (now no longer operating), the last message
   posted to #openindiana on freenode was June 9 - nobody replied. The
   last message with replies was on June 6. My logs indicate much more
   activity on the libera.chat #openindiana channel - the last message
   was on June 27 and plenty of activity throughout June. For oi-dev,
   there's no human messages since June 7 on freenode. On libera.chat
   oi-dev had messages a few days ago.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI no longer automounts USB sticks

[Till Wegmueller]

Hi Gary

To understand which service might be affected by the problem, could you 
check if one either hal or rmvolmgr produce informative output?


Also another thing that might have changed is behaviour in the Mate 
components in the UI that control the mounting. What do the GUI tools 
say about mounting?


-Till

On 03.06.21 11:11, Gary Mills wrote:

A couple of weeks ago, I upgraded my OI systems to the current version
of OI.  Everything seemed to work, although I didn't test everything.
Yesterday, I inserted a USB stick into one of the systems, and was
surprised that it didn't mount.  It used to work.  This event start me
on an investigation.

All of my USB sticks use a FAT32 filesystem and one FDISK partition.
They all automount on Windows 10 and show no errors.  On my test OI
system, running the 2021-05-15 version of OI, they do not automount.
A reboot did not help.  The "fstyp" command for the :1 device shows a
"pcfs" filesystem.  I am able to mount and umount the device as root.
It shows the correct content.

When I booted the 2020-11-27 BE on that same system, the USB stick did
automount.  A window popped up showing the contents of the device.  It
also showed up in "mount | grep media".  Another USB stick also
automounted the same way.

I conclude that something happened between those two versions of OI
to prevent USB sticks from mounting.  I don't know what changed or
what is missing.  Has anyone else seen the same problem?

Automounting is complicated.  These are three services that have to
be operating properly for USB sticks to be automounted:

 $ svcs hal dbus rmvolmgr
 STATE  STIMEFMRI
 online 20:54:09 svc:/system/dbus:default
 online 20:54:11 svc:/system/hal:default
 online 20:54:11 svc:/system/filesystem/rmvolmgr:default

All three of them are online on all of my OI systems.



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [OpenIndiana-discuss] OI Foundation

[Till Wegmueller]

Ok, Just a quick Info mail before everybody gets attached to things.

In the Maintainer call the founding of a Foundation/ or Rather 
Association has been discussed quite a bit. And it's in fact a process 
that was started once but not with a high priority. Thus far getting in 
Volunteers has been a higher priority rather than Organising cash or 
governance.


I get the benefits of a Foundation and a central spot to look at in 
Governance, but thus far we are one core developer (Andreas Wacknitz) 
and supporting maintainers. I love the initiative and Engagement that 
people bring here. And it's needed. But we don't need an official 
Signoff space yet. If people are willing to invest into development, we 
are not holding you guys back. But please be aware who you are and how 
much you have to do with the OI and in fact illumos brand and if another 
name is not more appropriate for an outside initiated initiative. ;)


Greetings
- Till

On 26.05.21 18:32, Gerard Arthus wrote:

We can roll illumos into the foundation; we can keep the books ourselves,
just have to pay a cpa to sign off on it if that is desired. I would do the
tax preparation myself unless a large amount of money was involved. I would
only do this if the finances were completely transparent and everything was
posted on the Internet. The main point here should be to use donations
strictly for development and not sucking administrative cost which is quite
common in the nonprofit world.

Gerry
Gerard Arthus
409 Lowell Avenue East
Mishawaka, Indiana
United States
46545
Cell - 574-302-7731
Home - 574-520-1337 <574-217-8726>

Instructor ITT-Tech - Mathematics, Electrical Engineering, and Computer
Engineering.

garthus...@gmail.com
Notary The State of Indiana #685426
http://www.OpenEducation.org
http://openeducation.org/moodle/  (For Course Portal) Log In as Guest
http://www.linkedin.com/profile/edit?trk=tab_pro
http://www.facebook.com/gerard.arthus
https://archive.org/details/arthusgerardphilosophicalwritings (Philosophical
Discussions)
https://archive.org/details/arthusgerardpoems (Poems)
https://archive.org/details/arthusgerardzoe?sort=titleSorter (Zoe Book)
https://archive.org/details/@garthus1&tab=collections (Gerard Arthus
Collections Page)
https://archive.org/details/arthusgerardhack

(Hacking The World)
https://archive.org/details/arthusgerardmedical&tab=about
(Medical Records)
https://archive.org/details/arthusgerardrec&tab=collection
(Musical Recordings)

https://archive.org/details/arthusgerardpackagingandinstructionmanuals
(Packaging
Collection)
https://archive.org/details/@garthus1&tab=uploads  (All Items Uploaded to
Date)
https://archive.org/details/What_Have_We_Wrought_ (Selected Poem)
https://archive.org/details/A_World_Where_We_Consume_Our_Hearts_ (Selected
Poem)
https://archive.org/details/Here_There_Is_No_Lesson_To_Be_Learned_ (Selected
Poem)
https://archive.org/details/Deception_And_The_Self_Created_Terrorist_Threat_American_Complicity_In_World_W
(Selected
Poem)
https://archive.org/details/Solitary_Horsemen_Reflections_On_Life_In_Cyberspace
(Selected
Poem)


On Wed, May 26, 2021 at 5:21 PM Marc Lobelle 
wrote:


Yes, I too think it is a good idea and worth a try.

Marc Lobelle

Belgium


On 26/05/2021 20:40, Apostolos Syropoulos via openindiana-discuss wrote:

We can get this going with at least 3-4 individuals; if there is

interest I

can start putting something together.

This is definitely a great idea.
A.S.
--
Apostolos Syropoulos
Xanthi, Greece




___
openindiana-discuss mailing list
openindiana-disc...@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


--


Marc Lobelle
professeur émérite

ICTEAM
UCLouvain / SST / ICTEAM / INGI

Place Ste Barbe, 2, bte L5.02.01 - 1348 Louvain-la-Neuve
marc.lobe...@uclouvain.be 
Tél.+32 (0) 475 494 616
Fax +32 (0) 10 47 51 20
www.uclouvain.be 

___
openindiana-discuss mailing list
openindiana-disc...@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


___
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] Moving on with postgresql

[Till Wegmueller]

Hi Gary

LGTM.
Thanks for the initiative.

-Till

On 19.04.21 12:34, Gary Mills wrote:

On Sat, Apr 17, 2021 at 04:46:06PM -0500, Gary Mills wrote:

OI currently has postgresql versions: 95 96 10 11 12 .  The OI
default, in shared-macros.mk, is 95 .  However, the postgresql
developers report that 95 is unsupported, but 13 is available and
supported.  Something has to change in OI to move forward with
postgresql.


Thanks to all who responded to my original message.  Most people
wanted to use modern versions of postgres, including 13, which is not
packaged on OI.  Nobody wanted to use 95, which is an unsupported
version.  Unfortunately, 95 is still needed by many OI packages,
and cannot immediately be obsoleted.

Given these wishes and constraints, here is my proposal for postgres
packages in OI.  I will change the default to 10 or 11, and upgrade 95
and 96 to new minor versions, and to python-3.  After all, removing
python-2 is the whole reason for the current round of package
upgrades.

The result of this proposal is that package
database/postgres-95/library still exists, and that OI packages that
require these libraries will still work.  Because the postgres default
has changed, some packages may no longer build.  A short term fix for
these is to add this statement to Makefile:

 PG_VERSION=9.5

The proposal above is only the first step, but will get OI past the
python version update.  The next step for postgres will be to obsolete
95 and 96, and to add 13.  People upgrading postgres will need to dump
tables from the old version and load them in the new version, as
suggested in the postgres manuals.




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Moving on with postgresql

[Till Wegmueller]

The repo server needs the pkg client to report the statistics. They do 
not get calculated on the repository. The repo server does not care much 
for the client Version as the API, they communicate over has been stable 
and is versioned.


One could count the hits to the files from Webserver logs, but we can 
only track total installations of a particular manifest (package 
description file).


The Package is called postgres not postgresql.
Searching by posgres shows the packages

pkg search -rp postgres
PACKAGE PUBLISHER
pkg:/database/postgres-common@9.5.24-2020.0.1.0 openindiana.org
pkg:/service/database/postgres-10@10.16-2020.0.1.0  openindiana.org
pkg:/service/database/postgres-11@11.10-2020.0.1.0  openindiana.org
pkg:/service/database/postgres-12@12.5-2020.0.1.0   openindiana.org
pkg:/service/database/postgres-95@9.5.24-2020.0.1.0 openindiana.org
pkg:/service/database/postgres-96@9.6.20-2020.0.1.0 openindiana.org

I agree that the statistics will help, but for postgres we are outdated 
compared to most other conservative distros even.


-Till

On 17.04.21 21:13, Reginald Beardsley via oi-dev wrote:
Color me confused. Which server and which client are you talking about? 
I was referring to the IPS repository and it is not going to care about 
the age of a client.


I'm running 2017.10 on this system and can't install much, if anything, 
any more. Not sure if there is a way to do it, but with a new system on 
the way and my normal habit of building from source so I can debug if 
needed it's moot.


The only pkg I can find using "pkg search postgresql" before 10.x is

pkg: /database/postgres-96/mysql_fdw@2.5.3-2020.0.1.0

However, I don't use Postgres despite compiling it quite a few times. It 
just never fit something I needed to do. So it's likely that this is a 
more nuanced question than I thought.


But collecting install statistics on the repository servers seems to me 
an important tool for allocating manpower.


Reg




On Saturday, April 17, 2021, 06:25:30 PM CDT, Till Wegmueller 
 wrote:



Hi Reg

Unfortunately it does not. It never got that feature added.

It is a point for possible feature to add, but as many people are still
running old versions of the client, it will take quite a long time for
the statistics to get traction.

-Till

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Moving on with postgresql

[Till Wegmueller]

Hi Reg

Unfortunately it does not. It never got that feature added.

It is a point for possible feature to add, but as many people are still 
running old versions of the client, it will take quite a long time for 
the statistics to get traction.


-Till

On 17.04.21 20:15, Reginald Beardsley via oi-dev wrote:
Does the repository server collect information about installs? It seems 
to me it should and package and version support decisions based on that 
information. Without that information there is great potential to waste 
resources doing work which will never be used.


In the early 90's I was a big advocate for buying binary FOSS packages 
as compiling them for multiple platforms was not cheap unless it was 
done during idle time while waiting for another job to complete. I 
routinely did this on other systems while waiting for a compile and test 
to complete on the platforms we supported for our package.


As a practical matter, distribution of builds of FOSS was out of scope. 
I just did the 6 platforms which used our NFS server for our convenience 
and efficiency. No one asked me to do it. I just did it and everyone was 
very pleased that I did.


In order to better manage resource allocation of 3 people, I implemented 
a usage logger which collected usage data via UDP from all the business 
affiliates in a major oil company for the package we supported. Once a 
month I generated plots showing program usage by affiliate and 
cumulative usage worldwide. That allowed management to allocate 
resources to programs in widespread use and ignore programs only used by 
the scientist who wrote it. One individual was *very* noisy. It was 
extremely useful to be able to show he was the sole user and had run the 
program 1 or 2 times in the last year. As he had written it, he was 
quite capable of adding the "important" features himself.


I do not suggest collecting per use data, but per install data seems 
entirely sensible.


Reg

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Moving on with postgresql

[Till Wegmueller]

Hi Gary

I use Postgres and extensions for all Applications I develop 
professionally and privately.


We use mostly 12 and upwards 13 being the standard and I am waiting for 
14 to hit. The last Bugfix release for 9.5 was on 2021-02-11 so quite 
recently.


I would love to have 13 and modern 12 packaged, especially as we have a 
build server for them sponsored by the Oi community. So we know it 
builds even on current develop.


My preference for the record is to have 13, 12 and 11. Older ones should 
only be used for people still needing them. AWS only offers those in 
their offerings as well, so not many people will want 10 or older.


-Till

On 17.04.21 18:46, Gary Mills wrote:

OI currently has postgresql versions: 95 96 10 11 12 .  The OI
default, in shared-macros.mk, is 95 .  However, the postgresql
developers report that 95 is unsupported, but 13 is available and
supported.  Something has to change in OI to move forward with
postgresql.

Here are some actions that could be taken with OI.  We could change
the default version to 10.  I, myself, would prefer 11.  We could
obsolete 95.  I'd prefer obsoleting 95 and 96.  We could add version
13, but only after 96 is obsoleted.  We should limit the number of
postgresql versions in OI, after all.  Finally, we could make no
obsoletions or additions, retaining even the unsupported 95.  Which
would you prefer?

I have not investigated two questions.  Perhaps you can tell me?  What
are the consequences of obsoleting 95?  What are the consequences of
the default change?




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Virtual address space and Firefox

[Till Wegmueller]

I think we should also ask on illumos-developer for this.

Not many illumos devs are on this list that know this deep enough.

-Till

On 13.03.21 04:58, Carsten Grzemba via oi-dev wrote:

On building FF for OI I run in core dumps.

It seems that this are raised by MOZ_ASSERTION because the JS-engine 
(spidermonkey) expects that  addresses for JS Values are not in the 
upper memory area:


ptr must be a valid user-mode pointer, with the top 16 bits clear

The ptr is for example 0xfbffef120fb0 so the address is too high in 
this case. pmap shows the related range as mmap allocated area (anonymous)

Related the assertions there was a change in FF68.2

In solaris-userland Oracle has placed a patch but only for Sparc: 
sparc-47bit-VA-space.patch

This use a mapfile with
RESERVE_SEGMENT spidermonkey_reserve {
   VADDR = 0x8000;
   SIZE = 0x7fff;
};
Illumos ld don't know the option RESERVE_SEGMENT, but it is for Sparc 
how I already stated.


Do IllumOS use the whole 64bit address space and not only the expected 
47bit? Or I am completly wrong here in the maze of physical and virtual 
address spaces?

--
Carsten

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] No module named 'pkg'

[Till Wegmueller]

Hi

IPS itself https://github.com/OpenIndiana/pkg5/ or the path in the 
components directory


-Till

On 03.03.21 16:38, Klaus Ziegler wrote:

Hi,

I've been able to compile python3.5 on SPARC and wanted to decom
my workaround for building packages in oi-userland, unfortunately

gmake pre-publish still tells me:

Traceback (most recent call last):
   File "/ws/klausz/oi-userland/tools/userland-mangler", line 38, in 


     import pkg.fmri
ImportError: No module named 'pkg'

can anybody tell me where and what module I have to build to be able to use
python3.5 to build packages, I hope it's not in the illumos-gate :-(

Much Regards
Klaus

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] gcc builds - no cc1objplus

[Till Wegmueller]

Hello Everyone

After some quick searching, it looks like it's actually not it's own 
language, but part of the objective-c language, where only with that 
feature it can link against c++ libraries. Curious that we have not 
gotten any error from people trying to compile Objective-C because one 
would assume that there are some c++ libraries even they link against. 
But again it's probably such a small percentage of people using 
objective-C that we won't notice any change for very long.


If you are using it in parts of code we can add it, We are support the 
whole of GCC anyways so it's no additional burden but we probably don't 
have any consumers.


-Till

On 22.02.21 15:16, Andreas Wacknitz wrote:

Am 22.02.21 um 13:38 schrieb Klaus Ziegler - owner of sunfreeware.de:

Hi,

is there any reason why we don't provide cc1objplus compiler in gcc
builds?

Most probably because nobody uses it and if we merge it into OI Hipster
we will have to support it.
Thus, additional work and not much gain.


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] CVE-2021-3156 seems relevant for OI

[Till Wegmueller]

Yeah

People still don't inform us or the BSD's / Apple properly for these 
sorts of things, but we can scramble to address small patches like this 
very fast it turns out. Thankfully now a couple of people in the BSD's 
now ping us in tweets when this happens so we get the news very fast, 
although still post embargo and not pre.



-Till

On 28.01.21 04:36, Tony Brian Albers wrote:

On 01/28/21 07:14 AM, Tim Mooney via oi-dev wrote:

In regard to: [oi-dev] CVE-2021-3156 seems relevant for OI, Tony Brian...:


We might want to get sudo patched really, really quickly.


Rich Lowe had a PR for it last night, just a few hours after the
embargo lifted:

  https://github.com/OpenIndiana/oi-userland/pull/6456

Tim


Cool, that's what I call fast :)

/tony





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Porting of the Epiphany Browser

[Till Wegmueller]

Everyone starts like that.

The docs are designed to be read and used even by non developers. The 
point of this is to have more developers. The only way to have more 
developers and contributors, is to offer resources for training. By 
being able to compile software you are already quite far ahead on the 
journey to be a contributor. If you would contribute the software in the 
packages defined that is already a good step. If you are willing to 
maintain the things you use for yourself also for others that is the 
best way to begin contributing.


You are allowed to try and train here.

-Till

On 09.01.21 13:12, Hung Nguyen Gia wrote:

Maybe you are misunderstood. I'm not that powerful to be able to be a 
developer. All of what I did as I described is I trying to build this browser 
on OI. Porting is the wrong word. My bad. It's such a too big word to be used. 
I'm currently stuck at libdazzle, a dependency of Epiphany. It seemed the 
problem is with a compiler flag is wrongly defined. It will fail to build with 
this flag on. But I have no knowledge with the Meson build system they are 
using, so I posted here asking anyone interested or have time please have a 
look at it.

This browser is fairly portable (at least it's what I think), so if we could 
get this libdazzle it's very likely we would get the browser, too.


 On Sat, 09 Jan 2021 20:10:53 +0700 Till Wegmueller  
wrote 

  > Hi
  >
  > Thanks for the initiative. Will you stay around longer and package some
  > softwares?
  >
  > Have you had a look into http://docs.openindiana.org/dev/userland/ It
  > gives you instructions on how to properly build and package components
  > for OI. If you get stuck on something we can have a look at your logs
  > and console output, and help pointing you to the right direction, but we
  > won't run a second build setup on our side.
  >
  > BTW. also have a look into solaris-userland
  > https://github.com/oracle/solaris-userland and
  > https://github.com/joyent/pkgsrc-joyent if there is any patches needed
  > for the sources to compile.
  >
  > -Till
  >
  > On 09.01.21 05:15, Hung Nguyen Gia via oi-dev wrote:
  > > In no way I'm a professional developer. I just pulled the source of it 
from github and tried to compile it by following the instructions.
  > >
  > > https://github.com/GNOME/epiphany
  > >
  > > Currently, I'm stuck at libdazzle. I will not compile under OI.
  > >
  > > https://github.com/GNOME/libdazzle
  > >
  > > Any helps would be appreciated. Thanks.
  > >
  > > ___
  > > oi-dev mailing list
  > > oi-dev@openindiana.org
  > > https://openindiana.org/mailman/listinfo/oi-dev
  > >
  >
  > ___
  > oi-dev mailing list
  > oi-dev@openindiana.org
  > https://openindiana.org/mailman/listinfo/oi-dev
  >



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Porting of the Epiphany Browser

[Till Wegmueller]

Hi

Thanks for the initiative. Will you stay around longer and package some 
softwares?


Have you had a look into http://docs.openindiana.org/dev/userland/ It 
gives you instructions on how to properly build and package components 
for OI. If you get stuck on something we can have a look at your logs 
and console output, and help pointing you to the right direction, but we 
won't run a second build setup on our side.


BTW. also have a look into solaris-userland 
https://github.com/oracle/solaris-userland and 
https://github.com/joyent/pkgsrc-joyent if there is any patches needed 
for the sources to compile.


-Till

On 09.01.21 05:15, Hung Nguyen Gia via oi-dev wrote:

In no way I'm a professional developer. I just pulled the source of it from 
github and tried to compile it by following the instructions.

https://github.com/GNOME/epiphany

Currently, I'm stuck at libdazzle. I will not compile under OI.

https://github.com/GNOME/libdazzle

Any helps would be appreciated. Thanks.

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] How many CPUs does OI support?

[Till Wegmueller]

Hey Chris

Considering we are coming from the SPARC side which lately went beyond a 
thousand cores, I have never heard of us having a limit. And Joyent had 
some beasts of Xeon's with smartOS which we simply ride along for 
support as illumos-gate has those patches IIRC.


If you are using OLD KVM Vm's before 1.3 you will need to specify 
sockets instead of cores, due to a bug, but otherwise you are good.


And if there is a limit I think that classifies as bug! So I support 
upstreaming a fix to get that sorted.


-Till

On 08.01.21 04:53, Chris wrote:

I'm looking to help building packages. Both current, as
well as newer versions. I have a large server farm. But
primarily BSD based. As such I'm looking into a new build
box, based on an Opteron or Xeon. So before I take the
plunge. I was hoping to add as many CPU/cores as possible.
Which begs the question: haw many CPUs does OI support?

Thank you for all your time, and consideration.

--Chris



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev