Re: [oi-dev] [OpenIndiana-discuss] ANNOUNCE: gcc ported Firefox 37.0b3 now backported to snv_130 x86/x64, Should work on OI/Hipster/S11.[0-3]/S12 etc.

[Till Wegmüller]

On Thursday 26 March 2015 22.16:04 Andreas Wacknitz wrote:
 
 So the question is: how can we change the situation?

If we would want to involve Companies:
Desktop Products that use our Strengths in the Server field?
Zone Based VDI for example. A Fast to boot low profile vdi that could run on 
laptop or even phone hardware(given x86 architecture). Mixed in with a little 
bit of live migration and X11 remoting magic and you have a nice little 
product that a company could sell. 

Other than that:
Cooperation with a Desktop Project?
KDE has stated interest, but the have no idea how to approach a port to 
solaris based systems. Their biggest effort for a solaris port was one guy.
He did get KDE4 running on S10.
Enlightenment seems to have shown interest aswell.

On Thursday 26 March 2015 22.27:13 Aurélien Larcher wrote:
Maybe stop having one distribution per 10 users ? (only Linux can afford 
having distribution because one does not like the default wallpaper)

Defragmentation of used Package formats?
We not only have a different Package Manager for every Distro, we also have a 
different kind of Build description format per distro, or per community multi 
distro project.

A Merge of opencsw, SFE, openpkg and all the other multi distro packaging 
projects?

Pre packaged buildzone images(like smartos) or buildzone construction script ?

A how to build a buildzone guide without different options to choose?
As a Solaris Newbie i got very confused with that guide.

A unified buildserver for multiple distros(like OBS)?

Greetings
Till

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

Re: [oi-dev] Vagrant

[Till Wegmüller]

Hey Adam


I would very much like to have vagrant boxes of oi. this would make my 
development setup much easier.



There are already vagrant boxes on the community platform from a guy 
named dusank.


I would say they are hipster 2015.05

https://atlas.hashicorp.com/dusank/boxes/oi-server/versions/2015.05/providers/virtualbox.box

https://atlas.hashicorp.com/dusank/boxes/oi-desktop/versions/2015.05/providers/virtualbox.box

You may want to collaborate with him.

Also there are tamplates available for the vagrant box building tool veewee

https://github.com/jedi4ever/veewee/tree/master/templates/openindiana-151a7-text-x86

This may also be usefull.


Greetings

Toasterson


On 24.05.2016 13:03, Adam Števko wrote:

Hello guys,

while working on OI infra I came across a need to rapidly provision OI hipster 
boxes.

I'd be interested in how many people actually use vagrant and would do on Oi 
hipster. If there is enough interest, I might package it and bring it to Oi. 
I'll also need testers. We will be able to build VirtualBox base boxes only (I 
don't use vmware on OS X).

I'll also start producing official OI vagrant boxes.

Let me know the interest in the package and how many people are to help test 
vagrant on Oi.

Cheers,
Adam
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev



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

Re: [oi-dev] Looking for testers: OpenIndiana Hipster vagrant box

[Till Wegmüller]

Hi Adam


Thanks for your work this makes contributing from linux a lot easier.


I have tested the box now for a bit and found the following things:

It works very well when developing applications on linux and run them in 
the vagrant box to test. Especially when your IDE has integrations for that.



Building oi-userland inside the shared folder is not usable.

When using vboxsf the performance is slow and rsync deletes all files 
not on the host (build artifacts, pkgrepo, prototype dir)


Outside of the shared folder it works very well.


The biggest benefit is that when i need a clean new install to test i 
can just destroy the box and start it again. No installing new vm's no 
playing with zones etc.


And when you work on two different things at once you don't need to play 
with clones in virtualbox.



Greetings

Till


On 16.06.2016 12:26, Adam Števko wrote:

Hello,

I prepared OpenIndiana vagrant box from the latest hipster 2016.04 
snapshot. This is targeted mostly at users and developers, who do not 
run OI as their main platform, but use VirtualBox for developing 
software or doing illumos builds on OpenIndiana. This box is created 
from text installer. GUI variant can come at the later phase and I am 
willing to accept contributions for that. Also, this box comes only 
with virtualbox as I don’t have access to VMWare Fusion or Vagrant 
vmware provider. If somebody has access to it and is willing to 
contribute, I’d gladly appreciate it.


How to get started:

1) Download and install Vagrant from https://www.vagrantup.com
2) Download and Install VirtualBox
3) Run following commands:

vagrant init openindiana/hipster; vagrant up --provider virtualbox

This will download the hipster box, create Vagrantfile in the current 
directory and bring up the hipster vagrant box.


4) Do you development/test it.
5) After finished, run this command to destroy the instnace:

vagrant destroy

Please, test this box and let me know any issues. Once, bugs are 
removed, I will recreate the box and push the final build to 
Hashicorp’s Atlas.


I am aware of only these 2 minor bugs, which annoy me:

- grub timeout is set to 30 seconds, which will be lowered to 5 (no 
need to have it 30 seconds in this case)
- box size. The box is compressed and has around 1GB in size. This is 
rather more complicated, but I’d like to try to minimize the box size 
a little bit.


In the future, I’d like to start rolling out OI images for more 
platforms. I might do qcow2 image in near future (based on how fast I 
might come to KVM resources).


If there are any questions, just ask.

Cheers,
Adam



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



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

[oi-dev] pkgdepend can not find existing file

[Till Wegmüller]

Hi

While Packaging mate-screensaver i stumbled upon a funny error message

pkgdepend says:

>/root/workspace/oi-userland/components/mate/mate-screensaver/build/manifest-i386-mate-screensaver.depend
 has unresolved dependency '
>depend type=require fmri=__TBD pkg.debug.depend.file=libGL.so.1 \
> pkg.debug.depend.reason=usr/libexec/mate-screensaver-gl-helper \
>pkg.debug.depend.type=elf \
>pkg.debug.depend.path=lib \
>pkg.debug.depend.path=usr/lib'.

So as far as i understand it it cannot find libGL.so.1
Funny is that, this file exists in /usr/lib

>root@openindiana:/root/workspace/oi-userland/components/mate/mate-screensaver# 
ls -al /usr/lib | grep libGL
>lrwxrwxrwx   1 root root10 Mar 10 20:20 libGL.so -> libGL.so.1
>lrwxrwxrwx   1 root root13 Mar 10 20:20 libGL.so.1 -> 
GL/libGL.so.1

>

Using ldd on mate-screensaver-gl-helper also finds libGL.so.1
>root@openindiana:/root/workspace/oi-userland/components/mate/mate-screensaver# 
ldd build/prototype/i386/usr/libexec/mate-screensaver-gl-helper | grep libGL
>libGL.so.1 =>/usr/lib/libGL.so.1

libGL.so.1 is 32-bit mate-screensaver aswell.

Does pkgdepend want that libGL.so.1 is a file and not a link to 
/usr/lib/mesa/libGL.so.1 ?


Side note usr/lib/libGL is linked to usr/lib/GL/libGL which is linked to 
var/run/opengl/lib/libGL which finaly links to usr/lib/mesa/libGL.

Why do those links not directly link to usr/lib/mesa/libGL?
Can that trigger a max follow links limit in pkgdepend?

Thanks and Greetings
Till Wegmueller




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

Re: [oi-dev] MATE 1.14 Desktop for OpenIndiana

[Till Wegmüller]

Hi

with dconf installed i can run some of the applications from a gnome 
session via console. like mate-about


They also spam the same error nikolam mentioned.

Caja does not want to launch. it runs but does not show up the gui

When i modify the xsession desktop file to feature the fullapth, i can 
launch a mate session.


But all the Icons are missing and some applets that require libexec 
helpers do not run.



Greetings

Toasterson


On 12.05.2016 10:07, Nikola M wrote:


While in GNOME, mate-calc opens and seems to work, even if saying:
(mate-calc:7503): GLib-GObject-WARNING **: cannot register existing 
type 'AtkObject'
** (mate-calc:7503): CRITICAL **: atk_object_set_name: assertion 
'ATK_IS_OBJECT (accessible)' failed)

but when launced on gnome, caja died:
 ld.so.1: caja: fatal: libdconf.so.1: open failed: No such file or 
directory 



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

Re: [oi-dev] OpenIndiana Docs (proof of concept) - What is it all about?

[Till Wegmüller]

Hi Michael

First of thank you for your hard work on the Documentation thus far.

On 04.05.2016 07:00, Michael Kruger wrote:
This leads me to suggest there should be an OpenIndiana 'Code of 
Conduct' to help reign in people with troublesome behaviors
Here i would like to input a bit of my experiece as a Kaopilot Student. 
Kaospilots is a Business shool which works with community based 
organization models and frameworks. Thus we also study communities in a 
great detail. Ranging from 3500 Year old traditions to modern day 
Communities.


What I have learned from that, is that if you "reign in people with 
troublesome behaviours" you will only cause more hostility.
The best cause of action I find is to make people aware what their 
bevahiour causes. This gives those people the freedom to rethink their 
actions and handle how they see fit.
This also happened in this case. And that person rephrased their mail to 
be more objective.


If we want to write down some general rules about what we would like 
people to do when bringing critique about work done is another topic.
But what i have learned in the 7 months working in this way is, it is 
hard to give objective and nice formulated feedback if you have not 
trained it.

So whatever we write down. It does not work if people do not commit to it.



1) Place documentation under distributed version control.
2) Lower the bar of entry to the documentation process.
3) Make changes and quickly deploy those changes in some kind of 
automated fashion (e.g. continuous integration).
4) Present the documentation in an organized and aesthetically 
pleasing way. The current state of the wiki is quite poor. The content 
is poorly organized, largely outdated, and the navigation menus do not 
function at all on mobile devices (this included tablets). This is a 
real problem, especially if the project expects people to rely on the 
Wiki as the "go to" source of information about the OpenIndiana project.


Please make people aware of this as soon as you see it. I was not aware 
of how the wiki behaves on tablet devices.

Also you have a view of things that lang time project memebers do not have.
We would realy like to see your view. Your view is a resource to reach 
more people with similar views on documentation.


Thank you for sharing your View.

I can only conclude by saying this is quite unacceptable and something 
better is required. Whether that something better is my little 
project, or something else entirely, that's for the community to decide.


My proposal is on the table and I can only expect it to be fairly 
judged on it's technical merits. It should not however be frontally 
assaulted because it differs from the way things have always been done. 

On this point i agree.

I would like to aks the people from the community to share what they 
think is a documentation.

Or what they think a documentation requires.
And what they want to be the outcome of this documentation project.

Greetings Till







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

Re: [oi-dev] Mate 1.14

[Till Wegmüller]

Hi Alexander


Hi, Till.

Do we miss something big from Mate now?




As far as i can see No.
You assessment is pretty much complete.

I would like to have the ZFS integration in Caja as an extension. AFAIK 
extensions are less effort to maintain and can also be used in other 
systems that have the required libs (Linux, FreeBSD). Thus alowing other 
people than us to use ZFS integration and increasing the userbase of 
those pieces of code.


The same is true for the compiz integration into mate-control-center. 
Ubuntu-Mate has an integration. Our old one was from ubuntu too. I was 
however unable to find the newest version of the patch when i looked.


I agree that we should not patch mate to use old tools when we have 
plans to modify the new ones.



Greetings
Till

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

Re: [oi-dev] mate components

[Till Wegmüller]

Hi Alexander.

Current State is, MATE minimal is shipped. You can install and launch a 
MATE session. No Metapackage or mate-gate in userland yet.


I currently have mate-applets and mint-menu on my backlog.
Mint-menu is optional and has a problem starting which i haven't yet 
figured out.
Mate-applets is nearly ready for PR. I only need to look that we deliver 
both 32 and 64 bit libexec applets.


If you could look at the remaining components would be great.

Greetings
Till


On 17.07.2016 09:07, Alexander Pyhalov wrote:

Hi, Till.

I'd like to know current Mate state. Do you have more components ready?
If you do, what prevents us from shipping them? If you don't I'd like to
look at remaining mate components.



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

Re: [oi-dev] OpenIndiana Code of Conduct

[Till Wegmüller]

On 18.07.2016 23:35, Adam Števko wrote:


Please compose your thoughts and comment with as few replies as
necessary so the community may solidify the final text of this document.

Cheers,
Adam



Hi Adam, Hi Nikola

Thanks both of you for the work put into this.

Here are my thought and comments:
When reading Adams text it refers to a body of Leadership. Both source 
Projects (FreeBSD and FiFo) have such a Role defined. Do we have that?


Adams text is more worded towards being a set of rules. Nikolas more in 
the sense of expectations. I prefer expectations.


When I read the words "will not be tolerated" it imediatly raises the 
question what will hapen if i break those? Who punishes and how? In my 
opinion "Discouraged behaviour" is the better wording.


I prefer the managing misuse and escalation section over the reporting 
violations. We have a very friendly community. There should not be a 
need to involve a third party to resolve issues from the very beginning.


The very notion of twitter is that everything is public.

I find the point "Maintain welcoming environment for new contributors 
and guide them in contributions." very important. I would like to have 
that in.


What is the desired outcome of a code of conduct? Should it be a set of 
rules? Or a set of expectations from each other? Is it assumed to be the 
same for all codes of conducts? If so should we link to that definition? 
or do we need to define that?



Greetings
Till



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

Re: [oi-dev] Error Compiling marco

[Till Wegmüller]

On 06.07.2016 11:47, Peter Tribble wrote:

On Wed, Jul 6, 2016 at 10:33 AM, Till Wegmüller <toaster...@gmail.com
<mailto:toaster...@gmail.com>> wrote:

Hello Community.


I am currently trying to compile the mate window manager marco.
But unfortunatly i get the attached error.

Do you have any suggestions on how to fix it?


 I build marco with the following flags to configure:

CPPFLAGS=-D__EXTENSIONS__ CFLAGS=-std=gnu99

I also find that marco tends to make some random abuses of various
standards,
so you might also need

gsed -i '/_XOPEN_SOURCE/d' src/tools/marco-mag.c
gsed -i '/_POSIX_C_SOURCE/d' src/core/util.c
gsed -i '/_XOPEN_SOURCE/d' src/ui/preview-widget.c

--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/


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



Hi Peter

Thank you that worked.

Greetings
Till

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

Re: [oi-dev] AI ISO images

[Till Wegmüller]

Hi

I am currently experimenting with AI to get a boot_archive that can do 
netboot for netboot.xyz but its a side project atm.


Greetings
Till

On 07.07.2016 10:53, Alexander Pyhalov wrote:

Hi, people.
I want to ask if someone tried creating and using AI or AI ISO images
with OpenIndiana Hipster.
Do we want to start preparing them again? Has someone real need in such
images?


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

[oi-dev] Error Compiling marco

[Till Wegmüller]

Hello Community.


I am currently trying to compile the mate window manager marco.
But unfortunatly i get the attached error.

Do you have any suggestions on how to fix it?

Thanks and Greetings
Till
(cd /export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86 ; 
/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"  "ac_cv_func_realloc_0_nonnull=yes" CC="/usr/gcc/4.9/bin/gcc" 
CFLAGS="-m32 -O3 " \
/usr/gnu/bin/make   \
)
make[1]: Entering directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86'
/usr/gnu/bin/make  all-recursive
make[2]: Entering directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86'
Making all in src
make[3]: Entering directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86/src'
/usr/gnu/bin/make  all-recursive
make[4]: Entering directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86/src'
Making all in wm-tester
make[5]: Entering directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86/src/wm-tester'
depbase=`echo main.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
/usr/gcc/4.9/bin/gcc -DHAVE_CONFIG_H -I. 
-I/export/home/vagrant/oi-userland/components/desktop/mate/marco/marco-1.14.2/src/wm-tester
 -I../..  -D_REENTRANT -DMESA_EGL_NO_X11_HEADERS -D_REENTRANT -D_PTHREADS 
-D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz 
-I/usr/include/startup-notification-1.0 -I/usr/include/libgtop-2.0 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include-m32 -O3  -Wall 
-Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs 
-Wpointer-arith -Wcast-align -Wsign-compare -Wall -ansi -MT main.o -MD -MP -MF 
$depbase.Tpo -c -o main.o 
/export/home/vagrant/oi-userland/components/desktop/mate/marco/marco-1.14.2/src/wm-tester/main.c
 &&\
mv -f $depbase.Tpo $depbase.Po
In file included from /usr/include/glib-2.0/glib/gbacktrace.h:33:0,
 from /usr/include/glib-2.0/glib.h:34,
 from /usr/include/glib-2.0/gobject/gbinding.h:28,
 from /usr/include/glib-2.0/glib-object.h:23,
 from /usr/include/glib-2.0/gio/gioenums.h:28,
 from /usr/include/glib-2.0/gio/giotypes.h:28,
 from /usr/include/glib-2.0/gio/gio.h:26,
 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
 from /usr/include/gtk-2.0/gdk/gdk.h:32,
 from /usr/include/gtk-2.0/gtk/gtk.h:32,
 from 
/export/home/vagrant/oi-userland/components/desktop/mate/marco/marco-1.14.2/src/wm-tester/main.c:22:
/usr/include/signal.h:144:26: error: unknown type name ‘sigset_t’
 extern int sigwait(const sigset_t *_RESTRICT_KYWD, int *_RESTRICT_KYWD);
  ^
Makefile:464: recipe for target 'main.o' failed
make[5]: *** [main.o] Error 1
make[5]: Leaving directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86/src/wm-tester'
Makefile:1188: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86/src'
Makefile:674: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86/src'
Makefile:456: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86'
Makefile:388: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86'
/export/home/vagrant/oi-userland/make-rules/configure.mk:167: recipe for target 
'/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86/.built'
 failed
gmake: *** 
[/export/home/vagrant/oi-userland/components/desktop/mate/marco/build/i86/.built]
 Error 2
___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Why are Firefox and Thunderbird built with jemalloc?

[Till Wegmüller]

On 20.02.2017 23:01, Aurélien Larcher wrote:



On Mon, Feb 20, 2017 at 4:32 PM, Aurélien Larcher
> wrote:

Hi,
This is just a simple and honest question.
I have rebuilt Firefox and Thunderbird with jemalloc disabled and
linked to libumem.
I am not sure if the behaviour is related to adjusting
layout.frame_rate=24 or the memory alloc but Thunderbird seems less
"bloated".
Any experience?



(the underlying question being about memory fragmentation and such)



Do we have this kind of Situation ?
https://bugzilla.mozilla.org/show_bug.cgi?id=422055

Greetings
Toasterson

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

[oi-dev] Netboot on OpenIndiana

[Till Wegmüller]

Hello fellow Community

So i have been working with netboot today and would like to give you a 
rundown of what works/what not and would like to ask you how you see 
this project going forward.


So the basic idea was that Users new to OI could use the service 
netboot.xyz to easily launch the installer of OI and Install.


However it turns out that the boot_archive included in the Hipster Isos 
is not usable for netboot.


While investigating the boot process it also turns out that someone 
built many safeguards into the SMF Install scripts that would need to be 
changed.


Due to the fact that distro constructor takes 2+ hours to build an iso 
on every change and my need for some experimentation, I built some 
scripts based on alhazred's Firefly Recovery Image, Jimklimov's make 
firefly from root and Peter Tribbles minimal viable Illumos.


you can find the code here: https://github.com/Toasterson/firefly

The Script's are capable of making a boot_archive from your System. and 
a Bootable ISO from a boot_archive.


The mkfirefly.sh script has an -i switch where you can choose a root 
directory from where to take the files.


I tried this with a properly mounted Hipster ISO but that produces a 
unbootable Image.


Given the restrictions of the Installation process I will probably have 
to change some bits in that process in order to make netboot work. I yet 
don't know which.


Thus i would like to ask for some feedback from the Community.

I would like to know what you think about the scripts. How could I 
improve them? What would you use them for? Does that need some change to 
the script(e.g additional commandline option)?


I would also like to know what about the Installation Process would you 
like to see changed and how?


What's your opinion about AI (Automated Installer)?
Would you rather like Jumpstart as installer automation solution?


Looking forward for your feedback
Greetings
Till

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

Re: [oi-dev] Netboot on OpenIndiana

[Till Wegmüller]

Hi Gordon

Yes. The goal is to have a boot_archive that can download the 
CD-Contents via web into RAM. Or make basic recovery tasks when Disk 
id's change etc. Like the original Firefly. but with extensions.



Greetings
Till

On 08.09.2016 17:08, Gordon Ross wrote:

Just to be clear, you're trying to netboot a mini-root image, right?
(like the CD/ISO image, Not booting onto an NFS mounted root)

On Thu, Sep 8, 2016 at 10:57 AM, Alexander <alexander.r.ere...@gmail.com> wrote:

Hey Till,
good start!


On 06 Sep 2016, at 20:14, Till Wegmüller <toaster...@gmail.com> wrote:

...
I would like to know what you think about the scripts. How could I improve 
them? What would you use them for? Does that need some change to the script(e.g 
additional commandline option)?



Some tips:
Would be nice to add dynamic boot_archive size calculation (populate image 
stage fails for me with “no space left on device”).
You probably would like to cleanup kernel and platform directories in 
boot_archive for  32-bit drivers (or add an option and produce separate 32 and 
64 images if you like).
SMF repository probably will not be happy and it will try to run some stuff 
which is not exist in boot_archive, so you will need to modify smf database and 
may be some scripts.

Hope this helps,
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] Netboot on OpenIndiana

[Till Wegmüller]

Hey Alex
thanks for the tips.



Some tips:
Would be nice to add dynamic boot_archive size calculation (populate image 
stage fails for me with “no space left on device”).
Huh. In that case I still copy some junk to the Image that should not be 
there. Generally the Image should never grow past 300M because we have 
to transport it uncompressed via network.


Could you send the output of find fom you image?
I would like to compare that with my image contents to see the difference.


You probably would like to cleanup kernel and platform directories in 
boot_archive for  32-bit drivers (or add an option and produce separate 32 and 
64 images if you like).


I yet don't know if i want one Image for each bitness or one for 32 and 
64 bit.

But it's definately on the todo.


SMF repository probably will not be happy and it will try to run some stuff 
which is not exist in boot_archive, so you will need to modify smf database and 
may be some scripts.


Have you any docs that show how that is done?

I use the manifest-import with -f and -d to populate the Database from a 
directory. I could prepare a special manifest directory but would need 
to experiment a bit.


The thing that im currently unsure about is how do i deactivate or 
activate a service without using svcadm.


Greetings
Till

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

Re: [oi-dev] Netboot on OpenIndiana

[Till Wegmüller]

Hi Adam

On 09.09.2016 09:57, Adam Števko wrote:


Do you know why it takes so long? Do you know if the problem is IO bound and a 
SSD might help speed this up? Or is something else?


Well it builds more than what i need for one.
Everytime distro_const runs it runs pkg/mkboot_archive/mk_solaris.zlib 

As I only need the Boot_archive there is no need to wait for steps i 
don't need.


Taking out the steps did also not work really.
They are split in such a way that it's hard to find out where the 
boot_archive part is. Thus I used some scripts from Tribblix and 
Firefly. Was much easier.


As for distro_const taking 2+ hours. Alp and ptribble analyzed this some 
time ago aswell.


IIRC distro_const makes some very funny things like 10'000 Symlinks into 
/opt/misc which then is linked to /mnt/misc etc...


For more details i would need to take a deeper look at distro_const

but it looks like the way we build ISO's at the moment is the main 
reason for the time it takes.


Oh one thing that I remember taking ages is lofiadm -d. Thats for 
distro_const but also my scripts. And probably others too.


Greetings
Till

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

Re: [oi-dev] FOSDEM 2017

[Till Wegmüller]

On 09.11.2016 15:10, Adam Števko wrote:

Hello,

how mahy people will attend FOSDEM 2017? If there is enough people, we could 
possibly have a hackathon organized.

Let us know your interest.



I could make it.
Would love to help Organize a Hackathon. We just had large group 
Facilitation in School. And I already thought about using that knowledge 
to Organize a Hackathon.



Greetings
Till

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

Re: [oi-dev] clang open source packages and nightly binaries

[Till Wegmüller]

On 23.10.2016 04:49, C Bergström wrote:




OSX and Linux Power8 are coming soon (few days)


Can you give some deatils what you mean with Linux Power8?
I was planing to adapt the ARM Toolchain Rmustacc and jperkin have 
deveopled for POWER8 sometime next Year (probably Spring to Summer). 
Which is for the Illumos kernel.


Most important are you planing that Power8 Build for userland use only 
or are you considering Kernel building too?


Greetings
Till

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

Re: [oi-dev] Updated OpenIndiana-Welcome

[Till Wegmüller]

On 25.10.2016 02:16, Michael Kruger wrote:

Suggestions incorporated.

See attached file

Michael



Nice I like it.
On the ZFS Feature you only have the link and not the Text as Link. I 
guess thats a typo?


Other than that great work thanks.

Greetings
Till

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

Re: [oi-dev] Updated OpenIndiana-Welcome

[Till Wegmüller]

Hi Michael

I like it.
The only thing that could be improved is the Enterprise Class Features 
Section.


Compared to the other Sections it looks a little Bare bones.
Maybe one or two Sentences per Feature.
Or like Alexander Mentioned you could also use links to other Sites.


Greetings
Till

On 24.10.2016 04:54, Michael Kruger wrote:

This is a request for comments for an updated OpenIndiana-Welcome doc...

Did a quick update of the doc which ships with OI and is presented the
first time Firefox is run.

Please review and if you have suggestions for what else should be added
to this, or would like to see something changed, please let me know.

Feel free to turn on change tracking and send me back an edited copy.

but please no bike-shedding.as I would like to see this get shipped
with the next release.

ODT file is attached.

thanks,

Michael


___
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] Discussing maintainers visibility in oi-userland

[Till Wegmüller]

If we talk bigger components like XFCE i would say that this is pretty 
much how we are handeling them right now. We only take in these when we 
know that a Contributor is able to support them over a period of time. 
Otherwise we leave try to put stuff like this into SFE or pkgsrc where 
there are people (and buildservers) providing packages for many things.

I would say that this seems the way to go with the bigger Components.


---
Greetings
Till

On 12.05.2017 09:27, Dariusz Sendkowski wrote:

In my opinion, the current system looks fine.
Having a maintainer per component could be a nightmare for both 
maintainers and contributors. Maintainers are usually bottlenecks for 
various reasons no matter how hard they try not to be.
It could slow down the whole process significantly. Right now, it seems 
to run pretty flawlessly.


But how does it work for big and complex components (like desktop 
environments)? Should they be rejected due to the lack of the 
contributor's maintenance guarantee?
When I look at the contributors' list I see that people appear and 
disappear and that's a natural process.
This implies that nobody can guarantee that they will maintain 
components they add (I mean the bigger ones).




2017-05-12 6:22 GMT+02:00 Alexander Pyhalov >:


On 11.05.2017 22:13, Peter Tribble wrote:

On Thu, May 11, 2017 at 6:56 PM, Aurélien Larcher <
aurelien.larc...@gmail.com >
wrote:


The question raised is whether we should formalize a
maintaining process
for some important components or groups of components.

At some point I joked about a campaign going like "Adopt a
package".


There are downsides to having a formal owner: they can become a
bottleneck, and it might discourage others to contribute in an area
where there's an individual (or individuals) listed. Also,
people may be
reluctant to contribute if there's a prospect of being lumbered with
the responsibility going forward.

But, if you can avoid that, then there are benefits to having
what we
would call "Subject Matter Experts" for components or groups. Having
someone who is reasonably familiar with the component, preferably
someone who uses it, is useful as a source of help and advice, and
having a list of such people and their specialities would be
useful to
other contributors.

Putting such a list on display would also show that OI wasn't just a
one or two person effort, which would be good.


Yes, this idea seems reasonable. BTW, recently github started
suggesting reviewers
and it does it rather well.
---
System Administrator of Southern Federal University Computer Center



___
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] Components archive url availability

[Till Wegmüller]

Hello.

Yes IPS uses precompiled Packages. However it does not distribute them 
as tarball archives but as seperate files. These fiels are Linked 
together by the manifests of a Package. Which is a Textfile describing 
all files, symlinks, mediators, etc. of a package.


IPS itself does not use the source archive property. This is only 
relevant for OI-userland.


OI userland is our version of Ports and also our Buidl system for packages.

You can grab yourself the latest git revision of oi-userland and compile 
every package for yourself localy with it. Once you have installed 
build-essential package.


Our Jenkins build servers do the same.

Have a look at http://docs.openindiana.org/dev/userland/ for more 
details on how to get started with oi-userland



Greetings
Till

On 11.05.2017 13:28, Aurélien Larcher wrote:



On Thu, May 11, 2017 at 12:18 PM, Dariusz Sendkowski 
> wrote:


I guess that is exactly how it is done in OpenBSD. You have
precompiled binaries, which you can fetch and install. You can also
build them by yourself using OpenBSD ports system. If the original
site is unavailable, the sources are downloaded directly from
OpenBSD servers, for example:

# cd /usr/ports/x11/libxdg-basedir/
# make fetch
===>  Checking files for libxdg-basedir-1.2.0p0
>> Fetch http://nevill.ch/libxdg-basedir/downloads/libxdg-basedir-1.2.0.tar.gz 

ftp: connect: Connection refused
>> Fetch 
https://ftp.openbsd.org/pub/OpenBSD/distfiles//libxdg-basedir-1.2.0.tar.gz

libxdg-basedir-1.2.0.t... 100%

Well, of course one can always clone oi-userland and build the
packages by oneself.

Anyway, I just wanted to know how exactly it is done in OI.

Btw, I wanted to add libxdg-basedir to oi-userland but as you can
see, the original site is not available any more.


There is a mirror with archived tarballs at:

http://dlc.openindiana.org/oi-userland/source-archives/

which can be used automatically if you set the EXTERNAL_ARCHIVE_MIRROR 
variable.


I do not know what you mean exactly by "precompiled package".
IPS is not based on "tarballs" and you can create pkg(5) archives for a 
given package version just by pkgrecv from the publisher, this seems a 
bit redundant.


HTH


regards,
Darek



2017-05-11 11:49 GMT+02:00 Nikola M >:

On 05/11/17 10:53 AM, Dariusz Sendkowski wrote:
> Hi,
>
> What happens when a component archive url points to a web resource
> that is unavailable temporarily or, even worse, permanently? How does
> it impact the package availability?
>
> Are all these oi-userland components precompiled and stored somewhere
> on the publisher server along with the sources? So when users install
> some packages they fetch the precompiled packages regardless of the
> corresponding archive urls availability?

I asked that 3+ years ago and i think they are stored on Oi build
servers, but not accessible from outside.

It would be the best to always have all sources available at any
time,
so all source is fetched from OI servers, but it could be a
project for
itself to make upstream sources available locally on OI servers.

Maintainers didn't like this, because fetching source archives from
remote server is more simple for a building process.

I also used to point out the legality of even distributing
precompiled
binaries before, without providing sources at any time. (and for any
distributed binary).
Having local store of source archives from the upstream projects,
having all sources always available at OI site, would fix both
legal and
build problems and elevate problem if network source is not
available.
Maybe just make local source code archives on Oi servers,
visible to all
users?




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





--
---
Praise the Caffeine embeddings


___
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] Providing icinga2 package

[Till Wegmüller]

Hi Marianne

To get started grab yourself a copy of
https://github.com/OpenIndiana/oi-userland

The Best Way is to clone this repo and setup a fork in your own github
profile. You can then make a remote and push to your profile.

Make a Feature branch for every componetn you want to package. A
component is the software itself and not all packages built from that
component. In your case it should be icinga and maybe if another
dependecy is needed one more component. The reason for that is that we
want seperate pull-request per component so it is more easily to check
what has been done.

The readme gives you a good starting point for building components that
already exist.

A compoent itself consists of a manifest and a makefile which controls
the build

The makefile is documented at:
https://wiki.openindiana.org/oi/oi-userland+Makefile+targets+and+variables

I think the best component to orient yourself when building icinga will
be zabbix. Also have a look at the pull requests if any of them help you
with your work.

If you have further questions don't hesitate to write to the ML or drop
by in #oi-dev on freenode

Hope this helps
Greetings
Till
On 29.11.2017 13:22, Marianne Spiller wrote:
> Hi there,
> 
> I successfully compiled icinga2-2.8.0 on OpenIndiana Hipster 2017.10,
> we're running it on several machines without any problems. So the
> community asked me to publish it as a package for the official repo -
> I'm willing to do so, but I'll need some assistance from more
> experienced users (I tried RTFM like that:
> https://wiki.openindiana.org/oi/Building+with+oi-userland, but it seems
> outdated).
> 
> So any help would be appreciated: I'd like to provide icinga2 as a
> package, what's best practice?
> 
> Cheers,
>   Marianne
> 
> 
> 
> ___
> 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] weird flock problem

[Till Wegmüller]

On 13.11.2017 15:59, Carsten Grzemba wrote:
> 
> 
> On 13.11.17 15:16, *Bob Friesenhahn *  wrote:
>> On Mon, 13 Nov 2017, Carsten Grzemba wrote:
>> >
>> >This compiles on Openindiana without an error, but if it runs throws
>> the error: Invalid argument (os error 22)
>> >
>> >If I copy this on Openindiana compiled code to Smartos it runs correctly.
>>
>> Are you using the same filesystem on both systems?  For example, zfs
>> vs tmp on swap could make a difference.  Or something to do with
>> filesystem paths.
> Thats the clue:
> it fails on NFS, but works on ZFS and TMPFS

Doesn't NFS require a special lock daemon to be setup between server and
client? AFAIk NFS locking is quite limted when i last tried it years ago.

Greetings
Till

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

Re: [oi-dev] Building install medium with custom illumos

[Till Wegmüller]

Hi Michael

The Problem is that you are using packages from OI-Userland to define
the installed packges.

You will need to use packages inside your depotd inside the xml tags.
I do not beleive that you have a package called minimal_install in your
repo. That package is from OI-Userland.

My guess would be to use SUNWcs or system/kernel and system/library as
packges names to install. They should grab enough other components for
you to have a runnable testable system.


Greetings
Till

On 08.12.2017 12:38, Michal Nowak wrote:
> Hello.
> 
> How do I create OpenIndiana install medium with custom illumos packages?
> 
> I built illumos with two Xen patches sent to illumos devel ml for a
> review and pointed pkd.depot to the built packages (/usr/lib/pkg.depotd
> -d /ws/illumos-gate/packages/i386/nightly/repo.redist -p 1).
> 
> These are the changes I did in slim_minimal_X86.xml
> :
> 
> 
>              url="http://localhost:1/;
>         authname="on-nightly"/>
> 
> 
> and
> 
> 
>     
>     
>     
>     
>     
> 
> 
> I can see some interaction with pkg.depot:
> 
> 127.0.0.1 - - [08/Dec/2017:12:00:42] "GET /versions/0/ HTTP/1.1" 200 177
> "" "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
> 127.0.0.1 - - [08/Dec/2017:12:00:42] "GET
> /on-nightly/catalog/1/catalog.attrs HTTP/1.1" 200 732 "" "pkg/31801149
> (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
> 127.0.0.1 - - [08/Dec/2017:12:00:42] "GET
> /on-nightly/catalog/1/catalog.summary.C HTTP/1.1" 200 193511 ""
> "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
> 127.0.0.1 - - [08/Dec/2017:12:00:42] "GET
> /on-nightly/catalog/1/catalog.dependency.C HTTP/1.1" 200 258218 ""
> "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
> 127.0.0.1 - - [08/Dec/2017:12:00:42] "GET
> /on-nightly/catalog/1/catalog.base.C HTTP/1.1" 200 70279 ""
> "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
> 127.0.0.1 - - [08/Dec/2017:12:00:49] "GET /versions/0/ HTTP/1.1" 200 177
> "" "pkg/31801149 (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
> 127.0.0.1 - - [08/Dec/2017:12:00:49] "GET
> /on-nightly/catalog/1/catalog.attrs HTTP/1.1" 200 732 "" "pkg/31801149
> (sunos i86pc; 5.11 illumos-68d7704518; full; pkg)"
> 
> But the build process eventually fails (full log
> )
> with:
> 
> ...
> pkg install: No matching version of minimal_install can be installed:
>   Reject:  pkg://openindiana.org/minimal_install@0.1-2017.0.0.17
>   Reason:  No version matching 'require' dependency SUNWcs can be installed
>     
>     Reject:  pkg://on-nightly/SUNWcs@0.5.11-2017.3.0.0
> pkg install: No matching version of minimal_install can be installed:
>   Reject:  pkg://openindiana.org/minimal_install@0.1-2017.0.0.17
>   Reason:  No version matching 'require' dependency SUNWcs can be installed
>     
> *    Reject:  pkg://on-nightly/SUNWcs@0.5.11-2017.3.0.0**
> **    Reason:  Higher ranked publisher openindiana.org was selected**
> **    Reject:  pkg://openindiana.org/SUNWcs@0.5.11-2017.0.0.16768**
> **   to**
> ** pkg://openindiana.org/SUNWcs@0.5.11-2017.0.0.16893**
> **    Reason:  Excluded by proposed incorporation
> 'consolidation/osnet/osnet-incorporation'*
>     
>     Reason:  Higher ranked publisher openindiana.org was selected
>     Reject:  pkg://openindiana.org/SUNWcs@0.5.11-2017.0.0.16768
>    to
>  pkg://openindiana.org/SUNWcs@0.5.11-2017.0.0.16893
>     Reason:  Excluded by proposed incorporation
> 'consolidation/osnet/osnet-incorporation'
>     
>   Reject:  pkg://openindiana.org/minimal_install@0.1-2017.0.0.18
>  to
>    pkg://openindiana.org/minimal_install@0.1-2017.0.0.22
>   Reason:  No version matching 'require' dependency SUNWcs can be installed
> ...
> 
> Thanks,
> Michal
> 
> 
> 
> ___
> 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] gmake sample-manifest Replaces to many strings with $(COMPONENT_VERSION) in sample-manifest

[Till Wegmüller]

Hi fellow developers

I found a bug in our Makefile script sample-manifest.

It replaces to many string with $(COMPONENT_VERSION) even those which
are not equal to $(COMPONENT_VERSION) it looks like it treats the . _
and nospace characters as equal.

This causes problems currently with golang-19 and golang-110 packaging.
COuld somebody with Makefile knowledge check that script out and see if
it's fixable?

Thanks and greetings
Till

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

[oi-dev] Alpha Release of OpenSource Cloud Authoring tools

[Till Wegmüller]

Hello fellow Community

We have often heard about the lackings of our zone management tools. So
I figured I could try and port the ACI and Jetpack code from Freebsd to
OI. A fun side project for myself which could also be usefull for others.

Now It brings me great pleasure to release the first tools as alpha.
[1]

The first tool in the series is my version of imgadm. The Image creation
and management tool.

It supports the ACI image format for easy exchange of images.

If you want to build a custom Image try the sample build file in the README.

You can find all the supported command in the buildfile and a
description what they do at. [2]

[1] https://git.wegmueller.it/opencloud/opencloud
[2]
https://git.wegmueller.it/opencloud/opencloud/src/master/Imagefile.markdown

Enjoy

Greetings
Till

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

Re: [oi-dev] Please Zip compress the USB downloads from OI

[Till Wegmüller]

Hi

The Image itself is compressed. However not the USB part but the LOFI
File representing /usr on the Live system.

What you compressed was the Sparse part of the image. I.e the Allocated
but not used USB Image Parts.

As soon as we have the combined image that will be solved.

What will help however Especially for people in the US is to pick a
local mirror. AFAIK the main Server is in the UK not US.


Greetings
Till

On 10.08.2018 19:22, Bob Friesenhahn wrote:
> On Fri, 10 Aug 2018, John Howard wrote:
> 
>> Yesterday I downloaded the minimal USB.  I am in USA, not Europe or Asia,
>> so I did not choose an alternative mirror for the download.  Average
>> speed
>> was modem circa 1990 around 56 Kb/s.  It took almost 3 hours.  Okay, if
>> that is how it is now.
>>
>> The problem is, out of curiousity, I compressed the downloaded minimal
>> USB
>> file 25% using Zip.
>> Similar savings result for the 2 GiB Live USB down to 1.6 GiB.
> 
> If the image is to be compressed, then it is likely that there is a
> popular compression algorithm (e.g. xz or 7zip) which is more effective
> than gzip.
> 
> Bob

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

Re: [oi-dev] Rust in userland?

[Till Wegmüller]

Hi

Could you use an earlier version of Rust as bootstrap for the current rust?

There should be a guide for rust bootstraping around on the internet.

You can look at golang 1.8 how bootstraping with an earlier version works.

The Reason for that is, that we build all packages on a buildserver with
jenkins. Where we will not install pkgsrc packages.

Can you also check platform support? Last I remember solarish systems
where a secondary platform and required patches.

In any case when you need a reviewer just tag me on github i'll gladly
take a look.

Thanks and Greetings
Till

On 13.08.2018 22:39, Michal Nowak wrote:
> Hi,
> 
> it seems that rust lang is needed for compilation of Thunderbird 60 and
> Firefox 60 ESR. Did anyone worked on rust component for userland?
> 
> If not, I thought on packaging it (and cargo) from scratch using
> pkgsrc's Makefile and Joyent's rust in binary pkgsrc as rust is needed
> for building itself.
> 
> Michal
> 
> ___
> 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 kill old sfe package meta-data?

[Till Wegmüller]

did you try http://sfe.opencsw.org/localhostoih ?
On 8/30/18 11:08 PM, Gordon Ross wrote:
> Yeah, thought to try that, but can't find an origin URI that works for this.
> 
> 
> On Thu, Aug 30, 2018 at 5:03 PM Till Wegmüller  <mailto:toaster...@gmail.com>> wrote:
> 
> Hi Gordon
> 
> You will need to add sfe as publisher for IPS to be happy.
> After uninstall you can remove sfe again.
> 
> Have you deleted the /var/pkg/cache by any chance?
> 
> Greetings
> Till
> 
> On 8/30/18 10:49 PM, Gordon Ross wrote:
> > People will probably want to see:
> >
> > # pkg -R /mnt publisher
> > PUBLISHER                   TYPE     STATUS P LOCATION
> > userland                    origin   online F
> > file:///tank/ws/oi-userland/i386/repo/
> > openindiana.org <http://openindiana.org> <http://openindiana.org>
> (non-sticky) origin   online F
> > http://pkg.openindiana.org/hipster/
> >
> >
> > On Thu, Aug 30, 2018 at 4:46 PM Gordon Ross
> mailto:gordon.w.r...@gmail.com>
> > <mailto:gordon.w.r...@gmail.com <mailto:gordon.w.r...@gmail.com>>>
> wrote:
> >
> >     I have a system that apparently had an sfe publisher at some
> point.
> >     Now attempts to update userland components run into problems:
> >
> >         # pkg -R /mnt install system/virtualization/open-vm-tools
> >         system/virtualization/open-vm-tools-desktop
> >         Creating Plan (Evaluating mediators): -
> >         Errors were encountered while attempting to retrieve
> package or
> >         file data for
> >         the requested operation.
> >         Details follow:
> >
> >         The requested operation requires that one or more package
> >         repositories are
> >         configured for publisher 'sfe'.
> >         Use 'pkg set-publisher' to add new package repositories or
> >         restore previously
> >         configured package repositories for publisher 'sfe'.
> >
> >
> >     I tried to get rid of the sfe stuff but can't figure out how. 
> Ideas?
> >
> >         root@vm530gwr# pkg list |grep sfe
> >         driver/network/sfe                              
> >          0.5.11-2017.0.0.16842      i--
> >         sfe/library/gmp (sfe)                            
> >         5.0.5-0.151.1.5            i--
> >         sfe/library/mpc (sfe)                            
> 1.0-0.151.1.5
> >                      i--
> >         sfe/library/mpfr (sfe)                          
> >          3.1.1-0.151.1.5            i--
> >
> >         root@vm530gwr# pkg uninstall sfe/library/mpc sfe/library/gmp
> >         sfe/library/mpfr
> >         Creating Plan (Finding local manifests): |
> >         Errors were encountered while attempting to retrieve
> package or
> >         file data for
> >         the requested operation.
> >         Details follow:
> >
> >         The requested operation requires that one or more package
> >         repositories are
> >         configured for publisher 'sfe'.
> >         Use 'pkg set-publisher' to add new package repositories or
> >         restore previously
> >         configured package repositories for publisher 'sfe'.
> >         #
> >
> >
> > ___
> > oi-dev mailing list
> > oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
> > https://openindiana.org/mailman/listinfo/oi-dev
> >
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org <mailto: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] How to kill old sfe package meta-data?

[Till Wegmüller]

Hrmm ips does aparently not keep any Manifests locally. Which is not
nice. One would assume that IPS would keep more data in it's sate
database. Considering it always tries to ensure the system is in a
specific state.

I think there might be a way IPS could continue working even if the
remote deletes manifests.

try pkg update first before installing or uninstalling anything

lets see if the makers of IPS had the same Idea i just had.

On 8/30/18 11:23 PM, Gordon Ross wrote:
> root@vm530gwr# pkg -R /mnt publisher
> PUBLISHER                   TYPE     STATUS P LOCATION
> userland                    origin   online F
> file:///tank/ws/oi-userland/i386/repo/
> openindiana.org <http://openindiana.org> (non-sticky) origin   online F
> http://pkg.openindiana.org/hipster/
> sfe            (disabled)   origin   online F
> http://sfe.opencsw.org/localhostoih/
> root@vm530gwr# pkg -R /mnt uninstall library/mpc
> 
> Errors were encountered while attempting to retrieve package or file
> data for
> the requested operation.
> Details follow:
> 
> http protocol error: Unknown error code: 404 reason: Not Found
> URL:
> 'http://sfe.opencsw.org/localhostoih/manifest/0/sfe%2Flibrary%2Fmpc@1.0%2C5.11-0.151.1.5%3A20120727T204712Z'
> (happened 4 times)
> 
> root@vm530gwr# 
> 
> 
> On Thu, Aug 30, 2018 at 5:12 PM Till Wegmüller  <mailto:toaster...@gmail.com>> wrote:
> 
> 
> did you try http://sfe.opencsw.org/localhostoih ?
> On 8/30/18 11:08 PM, Gordon Ross wrote:
> > Yeah, thought to try that, but can't find an origin URI that works
> for this.
> >
> >
> > On Thu, Aug 30, 2018 at 5:03 PM Till Wegmüller
> mailto:toaster...@gmail.com>
> > <mailto:toaster...@gmail.com <mailto:toaster...@gmail.com>>> wrote:
> >
> >     Hi Gordon
> >
> >     You will need to add sfe as publisher for IPS to be happy.
> >     After uninstall you can remove sfe again.
> >
> >     Have you deleted the /var/pkg/cache by any chance?
> >
> >     Greetings
> >     Till
> >
> >     On 8/30/18 10:49 PM, Gordon Ross wrote:
> >     > People will probably want to see:
> >     >
> >     > # pkg -R /mnt publisher
> >     > PUBLISHER                   TYPE     STATUS P LOCATION
> >     > userland                    origin   online F
> >     > file:///tank/ws/oi-userland/i386/repo/
> >     > openindiana.org <http://openindiana.org>
> <http://openindiana.org> <http://openindiana.org>
> >     (non-sticky) origin   online F
> >     > http://pkg.openindiana.org/hipster/
> >     >
> >     >
> >     > On Thu, Aug 30, 2018 at 4:46 PM Gordon Ross
> >     mailto:gordon.w.r...@gmail.com>
> <mailto:gordon.w.r...@gmail.com <mailto:gordon.w.r...@gmail.com>>
> >     > <mailto:gordon.w.r...@gmail.com
> <mailto:gordon.w.r...@gmail.com> <mailto:gordon.w.r...@gmail.com
> <mailto:gordon.w.r...@gmail.com>>>>
> >     wrote:
> >     >
> >     >     I have a system that apparently had an sfe publisher at some
> >     point.
> >     >     Now attempts to update userland components run into
> problems:
> >     >
> >     >         # pkg -R /mnt install
> system/virtualization/open-vm-tools
> >     >         system/virtualization/open-vm-tools-desktop
> >     >         Creating Plan (Evaluating mediators): -
> >     >         Errors were encountered while attempting to retrieve
> >     package or
> >     >         file data for
> >     >         the requested operation.
> >     >         Details follow:
> >     >
> >     >         The requested operation requires that one or more
> package
> >     >         repositories are
> >     >         configured for publisher 'sfe'.
> >     >         Use 'pkg set-publisher' to add new package
> repositories or
> >     >         restore previously
> >     >         configured package repositories for publisher 'sfe'.
> >     >
> >     >
> >     >     I tried to get rid of the sfe stuff but can't figure out
> how. 
> >     Ideas?
> >     >
> >     >         root@vm530gwr# pkg list |grep sfe
> >     >         driver/network/sfe                              
> >     >          0.5.11-2017.0.0.16

Re: [oi-dev] How to kill old sfe package meta-data?

[Till Wegmüller]

Hi Gordon

You will need to add sfe as publisher for IPS to be happy.
After uninstall you can remove sfe again.

Have you deleted the /var/pkg/cache by any chance?

Greetings
Till

On 8/30/18 10:49 PM, Gordon Ross wrote:
> People will probably want to see:
> 
> # pkg -R /mnt publisher
> PUBLISHER                   TYPE     STATUS P LOCATION
> userland                    origin   online F
> file:///tank/ws/oi-userland/i386/repo/
> openindiana.org  (non-sticky) origin   online F
> http://pkg.openindiana.org/hipster/
> 
> 
> On Thu, Aug 30, 2018 at 4:46 PM Gordon Ross  > wrote:
> 
> I have a system that apparently had an sfe publisher at some point.
> Now attempts to update userland components run into problems:
> 
> # pkg -R /mnt install system/virtualization/open-vm-tools
> system/virtualization/open-vm-tools-desktop
> Creating Plan (Evaluating mediators): -
> Errors were encountered while attempting to retrieve package or
> file data for
> the requested operation.
> Details follow:
> 
> The requested operation requires that one or more package
> repositories are
> configured for publisher 'sfe'.
> Use 'pkg set-publisher' to add new package repositories or
> restore previously
> configured package repositories for publisher 'sfe'.
> 
> 
> I tried to get rid of the sfe stuff but can't figure out how.  Ideas?
> 
> root@vm530gwr# pkg list |grep sfe
> driver/network/sfe                              
>  0.5.11-2017.0.0.16842      i--
> sfe/library/gmp (sfe)                            
> 5.0.5-0.151.1.5            i--
> sfe/library/mpc (sfe)                             1.0-0.151.1.5
>              i--
> sfe/library/mpfr (sfe)                          
>  3.1.1-0.151.1.5            i--
> 
> root@vm530gwr# pkg uninstall sfe/library/mpc sfe/library/gmp
> sfe/library/mpfr
> Creating Plan (Finding local manifests): |
> Errors were encountered while attempting to retrieve package or
> file data for
> the requested operation.
> Details follow:
> 
> The requested operation requires that one or more package
> repositories are
> configured for publisher 'sfe'.
> Use 'pkg set-publisher' to add new package repositories or
> restore previously
> configured package repositories for publisher 'sfe'.
> #
> 
> 
> ___
> 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 #4075?

[Till Wegmüller]

Hi

Small fact about these cases in Java.
It is actually quite common for Javabindings to distribute their shared
object files for multiple platforms within the jar. I know OpenGL
bindings do so.

So if you leave them out the jar would just unpack them again and maybe
even fail with permission denied or worse when launching (Depending how
intelligent the libraries unpack routine is.) At it would result in
leftover files after deinstallation.

I favour leaving them in.

Greetings
Toast

On 9/10/18 9:29 AM, Carsten Grzemba wrote:
> 
> 
> On 08.09.18 20:22, *Andreas Wacknitz *  wrote:
>>
>> Hi,
>>
>> #4075 is stalled for some time now. It won't publish in its current
>> state because of the jansi-native files from other OS's.
>> I don't know whether removing them will be enough and the jansi plugin
>> will be sufficient. As I don't use maven I don't
>> have that much knowledge. Maybe we should update to the latest version
>> in the 3.2 branch which does not use jansi-native I guess.
>> As Olaf doesn't seem to be interested anymore I am willing to close
>> this PR. What do you think?
>>
> Shortly I used mavem on Joyents Java VM image which also provide the
> linux, freebsd and OSX libs only. I guess these are useless, but I
> havn't seen any issuses.
> So, simply remove libjansi.so files, keep the README.txt only.?
> The native code is packaged in the jansi.jar file anyway.
> 
> 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] Lenovo N580 Wireless WiFi Card AR5B125

[Till Wegmüller]

Hi

Unfortunately Atheros Support on Illumos is rather tiny. We have some
Atheros Cards supported until 84xx but after that you are out of luck.
The only thing one could do to make the Situation better is to port over
the freebsd dirvers. I was told it was not that difficult compared to
linux but might still be quite the chellenge if you have never done it
before. I think the current driver might also be related to the FreeBSD
one. Unless it is still from SUN times.

It might even be that the wrong driver attaches to the card.

What you could also try is http://freenicdrivers.la.coocan.jp/

Which might have some drivers for your card/series.

Greetings
Toast

On 09/10/18 07:04 PM, G B via oi-dev wrote:
> That is an Atheros.
> 
> On Monday, September 10, 2018, 11:59:55 AM CDT, G B via oi-dev
>  wrote:
> 
> 
> I have a Lenovo N580 laptop with a /Wireless WiFi/ Card AR5B125.  With
> OI Hipster, I can scan and see my WiFi and even connect to it, but it is
> a very inconsistent connection.  Usually I can't even ping my gateway. 
> Even If I move the laptop next to the router it will have a much better
> connection, but even it fails.
> 
> Using the same laptop and FreeBSD the connection never fails.  Not once.
> 
> Is there something I can try?  Otherwise, I'll have to reinstall with
> FreeBSD.
> ___
> 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] How to kill old sfe package meta-data?

[Till Wegmüller]

Hi

Oh thanks for noticing. Yes they should be there.

If they are not one would most probably need to reinstall the os.

I made a script that should be able to do that online :)

#!/usr/bin/bash

IMG_NAME="online_reinstall"
IMG_MNT="/mnt"

beadm create ${IMG_NAME}
beadm mount ${IMG_NAME} ${IMG_MNT}

rm -rf ${IMG_MNT}/*

pkg image-create --full -p
openindiana.org=http://pkg.openindiana.org/hipster/ ${IMG_MNT}

cp -a /var/pkg/pkg5.image ${IMG_MNT}/var/pkg/pkg5.image

pkg -R ${IMG_MNT} install -v $(pkg list -H 'pkg://openindiana.org/*' |
awk '{printf "pkg://openindiana.org/%s ", $1}')

rsync -x -avp /etc/ ${IMG_MNT}/etc

beadm unmount ${IMG_NAME}
beadm activate ${IMG_NAME

If you have something installed under bootenv which is not in it's own
dataset you will need to copy that over too. Or reinstall the svr4
package if there are any.

Greetings
Till

On 8/31/18 9:22 AM, Alexander Pyhalov via oi-dev wrote:
> ____
> От: Till Wegmüller 
> Отправлено: 31 августа 2018 г. 0:43
> Кому: oi-dev@openindiana.org
> Тема: Re: [oi-dev] How to kill old sfe package meta-data?
> 
>> Hrmm ips does aparently not keep any Manifests locally. Which is not
>> nice. One would assume that IPS would keep more data in it's sate
>> database. Considering it always tries to ensure the system is in a
>> specific state.
> 
> 
> Hi. This is not true. 
> When you do pkg unset-publisher, you can see at 
> https://github.com/OpenIndiana/pkg5/blob/oi/src/modules/client/image.py#L3391 
> that pkg builds a list of manifests to keep and doesn't remove them.
> 
> Gordon, does /var/pkg/publisher/sfe/pkg/ contain manifests of installed 
> packages?
> 
> ___
> 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] PostFix with SASL

[Till Wegmüller]

Hello Fellow Community Members.


Is anybody using Postfix with SASL on Openindiana?

I havew a case where I need it. I thus have added the Compile option to
the Package in oi-userland. It compiles but I am still unable to
authenticate against our mail relay.

I have generated the config via Puppet and the same config works on CentOS.

I am wondering if our libsasl from illumos-gate may be incompatibly old.
Does anybody know If that is the case or if I it is more probably a
configuration Problem.


I am thankfull for any hints.
Greetings
Till

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

Re: [oi-dev] OI Hipster 2018.10 snapshot

[Till Wegmüller]

Hi

They actually are already compressed. Just not wrapped into a compressed
archive. Both the USB and ISO files are just a container for the
compressed files. for e.g. solaris.zlib or the Boot Archive. These
Compressed files will be decompressed on load by the Boot loader or OS
respectively.

Greetings
Till
On 31.10.18 04:33, John Howard wrote:
> The USB files should be compressed for downloads to save gigabytes of
> bandwidth.  On an individual basis it amounts to hundreds of megabytes
> and time saved for each person downloading.  I am not interested in
> arguments about which compression alg. to use because currently there is
> NO COMPRESSION.  Obviously compress them to save time for the people
> that download these files, and for the people that extract the
> contents.  Zip's alg. are good enough and Zip is faster than bzip or
> lzma variants.  Use gzip if you want.  Something is better than nothing.
> 
> On Wed, Oct 24, 2018 at 1:32 AM Alexander Pyhalov via oi-dev
> mailto:oi-dev@openindiana.org>> wrote:
> 
> Hi.
> 
> OI Hipster 2018.10 snapshot is ready.
> 
> Images:
> 
> 
> http://dlc.openindiana.org/isos/hipster/20181023/OI-hipster-gui-20181023.iso
> 
> http://dlc.openindiana.org/isos/hipster/20181023/OI-hipster-gui-20181023.usb
> 
> 
> http://dlc.openindiana.org/isos/hipster/20181023/OI-hipster-text-20181023.iso
> 
> http://dlc.openindiana.org/isos/hipster/20181023/OI-hipster-text-20181023.usb
> 
> 
> http://dlc.openindiana.org/isos/hipster/20181023/OI-hipster-minimal-20181023.iso
> 
> http://dlc.openindiana.org/isos/hipster/20181023/OI-hipster-minimal-20181023.usb
> 
> 
> SHA 256 checksums are available at ${link}.sha256sum
> Signed SHA 256 checksums are available at ${link}.sha256sum.asc
> The OpenIndiana Release Engineering key has key id 0x3a021afadbe31887 (
> https://sks-keyservers.net/pks/lookup?op=get=0x3A021AFADBE31887
> ).
> 
> Release notes: http://wiki.openindiana.org/oi/2018.10+Release+notes
> 
> Best regards,
> Alexander Pyhalov,
> system administrator of Southern Federal University IT department
> 
> ___
> 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] Python Ctypes only working on certain machines

[Till Wegmüller]

Hello Fellow Community

I am getting a weird behaviour from python ctypes recently. On some
machines I can find Libraries with the find_library() function on some I
can not. I narrowed it down to something that is in the dependency list
of build_essential. However I can not narrow it down to a Package. One
can test by using the following code in python console.

from ctypes.util import find_library
find_library("socket")

This should print 'libsocket.so.1' if it works.
Also saltstack needs to use FFI and this function. So if somebody uses
Saltstack the package must be in the list. Although not yet in the
package I made :)

Thanks for any pointers.
Till

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

[oi-dev] Whitespace in Makefiles in oi-userland keep causing Problems

[Till Wegmüller]

Hello Fellow developers.

I have a confusing Problem with our buildsystem.
Since today it keeps behaving Inconsistently when I have a Whitespace in
a Value of a variable.

A Makefile like so:


COMPONENT_NAME=salt
COMPONENT_VERSION=2018.3.2
COMPONENT_SUMMARY='Portable, distributed, remote execution and
configuration management system'
COMPONENT_PROJECT_URL=http://saltstack.com
COMPONENT_FMRI=system/management/$(COMPONENT_NAME)
COMPONENT_CLASSIFICATION='System/Administration and Configuration'


Something like COMPONENT_CLASSIFICATION would break pkgmogrify with:
pkgmogrify: File
/export/home/toast/workspace/openindiana/userland/components/python/salt/build/manifest-i386-salt-27.p5m
line 18: Malformed action at position: 90: whitespace in key:
set name=info.classification
value=org.opensolaris.category.2008:System/Administration and Configuration

I could manage to supress this by using escape characters like " or '.
But not in all cases. And with the Classification the Whitespaces are
required as that Category has Whitespaces in their name. Thus it won't
publish.

I remember that Whitespaces where no problem not long ago. How will we
handle this? Packages like puppet and many others have also Whitespaces
in the Makefiles.

Greetings
Till

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

Re: [oi-dev] Whitespace in Makefiles in oi-userland keep causing Problems

[Till Wegmüller]

No Unfortunately not...
And yes it seems to be a complete mess with whitespaces

And it is pkgmogrify which complains. not Make itself

On 09/28/18 10:03 AM, Alexander Pyhalov via oi-dev wrote:
> Does
> COMPONENT_CLASSIFICATION=   System/Administration and Configuration
> work?
> 
> С уважением,
> Александр Пыхалов,
> программист отдела телекоммуникационной инфраструктуры
> управления информационно-коммуникационной инфраструктуры ЮФУ
> 
> 
> ____
> От: Till Wegmüller 
> Отправлено: 27 сентября 2018 г. 22:03:14
> Кому: OpenIndiana Developer mailing list
> Тема: [oi-dev] Whitespace in Makefiles in oi-userland keep causing  
> Problems
> 
> Hello Fellow developers.
> 
> I have a confusing Problem with our buildsystem.
> Since today it keeps behaving Inconsistently when I have a Whitespace in
> a Value of a variable.
> 
> A Makefile like so:
> 
> 
> COMPONENT_NAME=salt
> COMPONENT_VERSION=2018.3.2
> COMPONENT_SUMMARY='Portable, distributed, remote execution and
> configuration management system'
> COMPONENT_PROJECT_URL=http://saltstack.com
> COMPONENT_FMRI=system/management/$(COMPONENT_NAME)
> COMPONENT_CLASSIFICATION='System/Administration and Configuration'
> 
> 
> Something like COMPONENT_CLASSIFICATION would break pkgmogrify with:
> pkgmogrify: File
> /export/home/toast/workspace/openindiana/userland/components/python/salt/build/manifest-i386-salt-27.p5m
> line 18: Malformed action at position: 90: whitespace in key:
> set name=info.classification
> value=org.opensolaris.category.2008:System/Administration and Configuration
> 
> I could manage to supress this by using escape characters like " or '.
> But not in all cases. And with the Classification the Whitespaces are
> required as that Category has Whitespaces in their name. Thus it won't
> publish.
> 
> I remember that Whitespaces where no problem not long ago. How will we
> handle this? Packages like puppet and many others have also Whitespaces
> in the Makefiles.
> 
> Greetings
> 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
> 

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

Re: [oi-dev] 2018.10 targets

[Till Wegmüller]

Hi

My personal target would be to have saltstack packaged and some
tutorials written how to use it.

As for KVM Zones. If we modify IPKG Brand and inject the appropriate
permissions and devices it should work. Although I would prefer it being
a fork of Tribblixes Sparse Brand. Also have a look into kvmadm what it
does to prepare KVM in zone setup. It has that capability but i did not
manage to make it work.

Greetings
Till

On 09/28/18 10:41 AM, Alexander Pyhalov via oi-dev wrote:
> Hi, folks.
> 
> We are approaching October.
> While I have limited time now, I want to coordinate priorities and targets, 
> what should we do till end of October (and due to personal reasons, I'd 
> better announce snapshot till 20 October or earlier or allow someone else to 
> do this).
> 
> We have several regressions and problems, which would be good to fix.
> 
> 1) Virtualbox failure after FPU changes https://www.illumos.org/issues/9761 , 
> https://www.virtualbox.org/ticket/17947 is a serious one, but I'm afraid I 
> lack skills to fix it in reasonable time. The stack trace itself doesn't seem 
> related to illumos-gate changes, but likely it is. In KVM Joyent fixed this 
> using new hma_fpu_* API, but Virtualbox structures to store VM registers 
> differ and from brief overlook it has several asm functions to store/restore 
> Host/Base registers state. So far I don't have an idea how convert one to 
> another. So, this likely will be broken in 2018.10 unless someone skillful 
> dig into this.
> 
> 2) sbcl issues - threaded sbcl can not be built after KPTI changes, it fails 
> FLOCK and posix tests. Needs investigation. It's a serious issue, because 
> threaded sbcl is needed to build pgloader.
> 
> 3) Our Mate is a bit old, but newer Mate requires updated GTK3 .  Updated 
> GTK3 IIRC has dropped support for theme engines, and so our Nimbus theme 
> based on unico engine doesn't work. Also I've heard there were issues with 
> new mate-terminal. 
> Michal, do you have some comments here?
> 
> 4) As for new features, I really want to see KVM zones, perhaps, I'll dig 
> into this shortly.
> 
> Does somebody have another targets/comments? 
> 
> Please, avoid turning this topic in bike-shedding, I want to hear OI 
> developers in a way "I ll take item #N" or "I expect to finish feature A 
> before snapshot", not "please, also fix this and that". 
> 
> Best regards, 
> Alexander Pyhalov, 
> system administrator of Southern Federal University IT department
> 
> 
> 
> ___
> 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] Fixing Virtualbox on recent kernels

[Till Wegmüller]

Hi

These are the changes to KVM Required.
https://github.com/OpenIndiana/oi-userland/commit/620e42a5024070a4653c325f9003e901946db706#diff-130072402c38c7577007683d0753a56f

Virtualbox will need the same.

I doubt we have communicated that to them.
You are welcome to do so.

Greetings
Till

On 09/20/18 11:38 PM, Geoff Nordli wrote:
> Hi.
> 
> From what I know, it looks like vbox is going to need some source
> changes in order to have it work on recent kernel versions.
> 
> Does anyone know what those changes look like and if they have been
> communicated to the vbox team?
> 
> thanks,
> 
> Geoff
> 
> 
> ___
> 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] Slow Loader on Samsung 950 Pro

[Till Wegmüller]

Hello

Has anybody tested loader on an NVME Disk? I have two Samsung 950 Pro in
a mirror Zpool Configuration. They are nicely fast but not during boot.
To be more precise loader requires more than 20minutes to get to the
point at which it has loaded the kernel and Ramdisk into memory. From
there the Kernel requires about 10-20 seconds to boot to graphical desktop.

I would like to start debugging that issue. Where can I start?

Thanks and Greetings
Till

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

Re: [oi-dev] Slow Loader on Samsung 950 Pro

[Till Wegmüller]

Hi Setup is most recent Hipster installed two weeks ago.

Greetings
Till
On 9/24/18 1:44 PM, Toomas Soome via oi-dev wrote:
> What version, or how old is the setup? The older ones had some cases where 
> the read past disk end and with some systems this can cause slowdown as 
> described.
> 
> Rgds,
> Toomas
> 
> Sent from my iPhone
> 
>> On 24 Sep 2018, at 13:03, Till Wegmüller  wrote:
>>
>> Hello
>>
>> Has anybody tested loader on an NVME Disk? I have two Samsung 950 Pro in
>> a mirror Zpool Configuration. They are nicely fast but not during boot.
>> To be more precise loader requires more than 20minutes to get to the
>> point at which it has loaded the kernel and Ramdisk into memory. From
>> there the Kernel requires about 10-20 seconds to boot to graphical desktop.
>>
>> I would like to start debugging that issue. Where can I start?
>>
>> Thanks and Greetings
>> 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
> 

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

Re: [oi-dev] Slow Loader on Samsung 950 Pro

[Till Wegmüller]

Hi Toomas

The system was installed two weeks ago and updated about one week ago.
What I noticed when booting is:
The first spinner already akes a couple of seconds to load loader wheras
on the iso it takes at most one second.

What takes most time is Display of available memory after displaying the
seem bios drives.

Loading things like the string class is fast as expected.
Loading menu config and boot_archive from disk is what takes most time.

Your dev version of loader gets as far as printing the system bios
drives on white background and then stops.

Loader on Hipster takes some time to print the bios memory then it
continious.

Loader from your dev link also sees a fd device which current stable
loader does not. I have no Floppy disk device in that computer.

Does this help?
Greetings
Till


On 09/24/18 02:55 PM, Toomas Soome via oi-dev wrote:
> Forgot to note, you should also be able to boot usb/iso, press esc from menu. 
> Then use beadm list zfs:rpool and beadm activate zfs:rpool and then enter boot
> 
> Sent from my iPhone
> 
>> On 24 Sep 2018, at 15:40, Toomas Soome via oi-dev  
>> wrote:
>>
>> Installed or pkg update is also done?
>>
>> I am on the trip this week and can not help with code, but from 
>> http://148.52.235.80.sta.estpak.ee you can find iso/usb image, and from it 
>> you can copy the dev version of loader binary. You can copy it with new name 
>> and if you press the space just when the first spinner, you can enter the 
>> new name.
>>
>> Basically I’d like to establish if the error is actually fixed...
>>
>> Sent from my iPhone
>>
>>> On 24 Sep 2018, at 15:18, Till Wegmüller  wrote:
>>>
>>> Hi Setup is most recent Hipster installed two weeks ago.
>>>
>>> Greetings
>>> Till
>>>> On 9/24/18 1:44 PM, Toomas Soome via oi-dev wrote:
>>>> What version, or how old is the setup? The older ones had some cases where 
>>>> the read past disk end and with some systems this can cause slowdown as 
>>>> described.
>>>>
>>>> Rgds,
>>>> Toomas
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On 24 Sep 2018, at 13:03, Till Wegmüller  wrote:
>>>>>
>>>>> Hello
>>>>>
>>>>> Has anybody tested loader on an NVME Disk? I have two Samsung 950 Pro in
>>>>> a mirror Zpool Configuration. They are nicely fast but not during boot.
>>>>> To be more precise loader requires more than 20minutes to get to the
>>>>> point at which it has loaded the kernel and Ramdisk into memory. From
>>>>> there the Kernel requires about 10-20 seconds to boot to graphical 
>>>>> desktop.
>>>>>
>>>>> I would like to start debugging that issue. Where can I start?
>>>>>
>>>>> Thanks and Greetings
>>>>> 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
>>>>
>>>
>>> ___
>>> 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] Slow Loader on Samsung 950 Pro

[Till Wegmüller]

Hi Tomas

> A bit,  but we definitely need to investigate it further.  Anyhow, I only can 
> check email this week, I left my laptop home on purpose:)
> 
> Rgds,
> Toomas
>>

I know these kinds of holidays :)

Have fun and enjoy yourself. I can wait a bit to get it fixed. The Boot
time is quite ideal to get a coffe and chat with people while it does
it's thing.

Lets cotinue this next week.

Greetings and an enjoyable holiday to you.
Till

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

Re: [oi-dev] Whitespace in Makefiles in oi-userland keep causing Problems

[Till Wegmüller]

I managed to get it Working by hardcoding every Value with a Whitespace
inside it in the Package manifest.

Looks like the problem seems to be the way gmake passes Variables to
pkgmogrify. It usualy does so by specifying -D $VARIABLE on the command
line. That seems not to be working consistently.

So lesson from that seems to be that we need to hardcode values with
whitespace into the manifest.

Thanks for the pointers.

Greetings
Till

On 09/28/18 12:23 PM, Joerg Schilling wrote:
> Till Wegmüller  wrote:
> 
>> A Makefile like so:
>>
>> 
>> COMPONENT_NAME=salt
>> COMPONENT_VERSION=2018.3.2
>> COMPONENT_SUMMARY='Portable, distributed, remote execution and
>> configuration management system'
>> COMPONENT_PROJECT_URL=http://saltstack.com
>> COMPONENT_FMRI=system/management/$(COMPONENT_NAME)
>> COMPONENT_CLASSIFICATION='System/Administration and Configuration'
>> 
>>
>> Something like COMPONENT_CLASSIFICATION would break pkgmogrify with:
>> pkgmogrify: File
>> /export/home/toast/workspace/openindiana/userland/components/python/salt/build/manifest-i386-salt-27.p5m
>> line 18: Malformed action at position: 90: whitespace in key:
>> set name=info.classification
>> value=org.opensolaris.category.2008:System/Administration and Configuration
> 
> It would help if you could investigate and report on what happenes that causes
> your problem and whether you are unhappy with "make" or with the called 
> program... 
> 
> BTW: do you use "gmake" or make?
> gmake is known to have a buggy white space handling.
> 
> Jörg
> 

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

Re: [oi-dev] (no subject)

[Till Wegmüller]

I think those are the ones that have been replaced.
But there are still some in the Closed bins tarball

Of the top of my head I know the ipsec daemon was such a case.

Greetings
Till

On 22.12.18 18:49, Echedey López Romero wrote:
> Are these all the private binaries inherited from Solaris when OpenSolaris 
> came out and need to be replaced?
> 
> https://github.com/illumos/illumos-gate/blob/master/exception_lists/closed-bins
>  
> 
> Regards,
> Echedey, López Romero
> ___
> 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] should packages have a pkg.description or not?

[Till Wegmüller]

Hi Tim

Welcome to the community.

pkg.description is a longer version of pkg.summary. In OpenIndiana we
use highlevel scripts to write these attributes.

Looking at our standard templates under templates directory in
oi-userland I see that they are not using any Property for the
Description. But some components do. But it does not seem to translate
into the final manifest.

We have a documentation of these highlevel scripts under
https://wiki.openindiana.org/oi/Building+with+oi-userland

The scripts themselves are at https://github.com/openindiana/oi-userland

Have a look around.

I would say that if we use pkg.description additionally to pkg.summary
then we would just need to fix oi-userland scripts. There are a lot of
COMPONENT_DESCRITION variables already in oi-userland. It should stay
optional though as The Disgners has designed the Property to be optional.

Greetings
Till
On 01/11/19 08:08 PM, Tim Mooney wrote:
> 
> All-
> 
> I'm new to oi-dev, though I've been on oi-discuss for years and have done
> a little bit with oi-userland in the past.
> 
> My basic question is: Should we be including a package description
> (pkg.description) in new packages we contribute, or should it
> intentionally be left un-set?  Currently, some packages have a
> pkg.description, but many do not.  I want to do it the "right" way, but
> it's not clear to me which way that is.
> 
> I've done some searching of the oi-dev archives, but I don't see any
> threads that discuss pkg.description.
> 
> Thanks,
> 
> Tim

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

Re: [oi-dev] Out of memory when trying to compile icinga2 with gcc6 - problem persists

[Till Wegmüller]

Hi Marianne

I have a quite beefy Machine with 32Gb RAM. If you send me the Link to
your Git Fork/Branch I could try to compile and see if It works on my
machine. Our Buildserver also has enough RAM as Rust was similarly
stupid with allocation.

Greetings
Till

On 14.01.19 10:37, Marianne Spiller wrote:
> Hi all,
> 
> nearly 1 year ago I asked the same and was not able to resolve this issue…
> 
> https://openindiana.org/pipermail/oi-dev/2018-March/005802.html
> 
> Now I’m back with a freshly updated hardware host and trying to compile
> icinga2-2.10.2. I made a change in my Makefile: |COMPONENT_BUILD_ARGS+=
> -j1|, but in comparison with the -j4 default the only difference are
> different values when crashing with out of memory. RAM consumption
> nearly 1.9GB when |Building CXX object
> lib/icinga/CMakeFiles/icinga.dir/icinga_unity.cpp.o|, swap leaving
> untouched.
> 
> It would be really nice to get some help on this ‘cause I’m stucked like
> I was last year at this point ;)
> 
> Cheers,
> Marianne
> 
> |$ uname -a SunOS zfs-2011 5.11 illumos-9c7c0c4b59 i86pc i386 i86pc $
> ulimit unlimited $ swap -lh swapfile dev swaplo blocks free
> /dev/zvol/dsk/rpool/swap 302,2 4K 31.9G 31.9G $ prtconf | grep Memory
> Memory size: 196495 Megabytes
> root@zfs-2011:/scratch/oi-userland/components/sysutils/icinga2# gmake
> sample-manifest /scratch/oi-userland/tools/userland-fetch --file
> /scratch/oi-userland/archives/icinga2-2.10.2.tar.gz --url
> https://github.com/Icinga/icinga2/archive/v2.10.2.tar.gz --hash
> sha256:99ab0c511a8a7014b9cf9467fe126d4a369026e9353f6e64c05ae39a15b32ad9
> Source /scratch/oi-userland/archives/icinga2-2.10.2.tar.gz... validating
> signature... skipping (no signature URL) validating hash... ok
> /usr/bin/touch /scratch/oi-userland/archives/icinga2-2.10.2.tar.gz
> /bin/rm -f -r
> /scratch/oi-userland/components/sysutils/icinga2/icinga2-2.10.2
> /usr/bin/env RUBY_VERSION=2.3 /scratch/oi-userland/tools/userland-unpack
> /scratch/oi-userland/archives/icinga2-2.10.2.tar.gz /usr/bin/touch
> /scratch/oi-userland/components/sysutils/icinga2/icinga2-2.10.2/.unpacked 
> /usr/bin/touch
> /scratch/oi-userland/components/sysutils/icinga2/icinga2-2.10.2/.prep
> (/bin/rm -f -rf
> /scratch/oi-userland/components/sysutils/icinga2/build/amd64 ;
> /bin/mkdir -p
> /scratch/oi-userland/components/sysutils/icinga2/build/amd64) (cd
> /scratch/oi-userland/components/sysutils/icinga2/build/amd64 ;
> /usr/bin/env CONFIG_SHELL="/bin/bash" CC="/usr/gcc/6/bin/gcc"
> CXX="/usr/gcc/6/bin/g++" F77="/usr/gcc/6/bin/gfortran"
> FC="/usr/gcc/6/bin/gfortran" CFLAGS="-m64 -O3 " CXXFLAGS=" -m64 -O3 "
> FFLAGS=" -m64 -O3 " FCFLAGS="-m64 -O3 " LDFLAGS="-m64"
> PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig" \ cmake
> -DCMAKE_C_COMPILER:STRING="/usr/gcc/6/bin/gcc"
> -DCMAKE_CXX_COMPILER:STRING="/usr/gcc/6/bin/g++"
> -DCMAKE_Fortran_COMPILER:STRING="/usr/gcc/6/bin/gfortran"
> -DCMAKE_C_FLAGS:STRING="-m64 -O3 " -DCMAKE_CXX_FLAGS:STRING=" -m64 -O3 "
> -DCMAKE_Fortran_FLAGS:STRING="-m64 -O3 " LDFLAGS="-m64"
> PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig"
> -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_INSTALL_BINDIR:PATH=bin
> -DCMAKE_INSTALL_LIBDIR:PATH=lib/amd64 -DCMAKE_INSTALL_SBINDIR:PATH=sbin
> -DCMAKE_INSTALL_DATAROOTDIR:PATH=share
> -DCMAKE_INSTALL_DATADIR:PATH=share
> -DCMAKE_INSTALL_INFODIR:PATH=share/info
> -DCMAKE_INSTALL_LOCALEDIR:PATH=share/locale
> -DCMAKE_INSTALL_MANDIR:PATH=share/man
> -DLIBEXEC_INSTALL_DIR="/usr/lib/amd64"
> -DLIB_INSTALL_DIR="/usr/lib/amd64" -DLIB_SUFFIX="/amd64"
> -DCMAKE_INSTALL_PREFIX="/usr" -DICINGA2_GIT_VERSION_INFO=OFF
> -DICINGA2_USER=icinga -DICINGA2_GROUP=icinga
> -DICINGA2_COMMAND_GROUP=icingacmd -DICINGA2_RUNDIR="/var/lib"
> -DCMAKE_INSTALL_SYSCONFDIR="/etc"
> -DICINGA2_SYSCONFIGFILE="/usr/lib/icinga2/icinga2"
> -DCMAKE_INSTALL_LOCALSTATEDIR="/var"
> -DICINGA2_PLUGINDIR="/usr/lib/nagios/plugins" -DICINGA2_UNITY_BUILD=ON
> -DICINGA2_LTO_BUILD=OFF -DUSE_SYSTEMD=OFF
> -DINSTALL_SYSTEMD_SERVICE_AND_INITSCRIPT=OFF -DICINGA2_WITH_CHECKER=ON
> -DICINGA2_WITH_COMPAT=ON -DICINGA2_WITH_DEMO=OFF
> -DICINGA2_WITH_HELLO=OFF -DICINGA2_WITH_LIVESTATUS=ON
> -DICINGA2_WITH_NOTIFICATION=ON -DICINGA2_WITH_PERFDATA=ON
> -DICINGA2_WITH_STUDIO=OFF -DICINGA2_WITH_TESTS=ON
> -DICINGA2_WITH_MYSQL=OFF -DICINGA2_WITH_PGSQL=OFF
> /scratch/oi-userland/components/sysutils/icinga2/icinga2-2.10.2) -- The
> C compiler identification is GNU 6.4.0 -- The CXX compiler
> identification is GNU 6.4.0 -- Check for working C compiler:
> /usr/gcc/6/bin/gcc -- Check for working C compiler: /usr/gcc/6/bin/gcc
> -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI
> info - done -- Detecting C compile features -- Detecting C compile
> features - done -- Check for working CXX compiler: /usr/gcc/6/bin/g++ --
> Check for working CXX compiler: /usr/gcc/6/bin/g++ -- works -- Detecting
> CXX compiler ABI info -- Detecting CXX compiler ABI info - done --
> Detecting CXX compile features -- Detecting CXX compile features - done
> -- Prefixing 

Re: [oi-dev] fmemopen not found for compiling samba-4.10.0

[Till Wegmüller]

Hi

fmemopen Seems to be only from the newest iteration of the Posix
Standard. We do not support that yet.

If I look into pkgsrc I see quite a few Patches you might want to look
at[0]. Pkgsrc being SmartOS package management wich is also available on
OI as addition to IPS. [1]

We would welcome any Makefiles and manifests under [2]. Have a look at
[3] for instructions on how to make one.

Greetings
Till


[0] https://github.com/joyent/pkgsrc/tree/trunk/net/samba4/patches
[1] https://pkgsrc.joyent.com/
[2] https://github.com/OpenIndiana/oi-userland
[3] https://wiki.openindiana.org/oi/Building+with+oi-userland
On 3/20/19 9:07 PM, Rouven WEILER wrote:
> I am trying to create the IPS package for samba-4.10.0.
> 
> The samba team changed a lot there and introduced a tool that needs fmemopen. 
> Compinling on OI shows an error with an unknown linker reference to the 
> respective symbol.
> As of now I just pathed the source code for avoiding the build of that tool 
> as recommended by the samba team.
> 
> But now the question:
> How do I get the respective library that includes this symbol?
> fmemopen seems to be kind of a posix standard and is included in glibc.
> 
> 
> ___
> 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] pulseaudio issues

[Till Wegmüller]

A PR does not mean you are done.

In fact the Github workflow does not specify in which state your changes
have to be to be discussed/shared. A PR would help a lot in seeing that
you are working on It and anybody that wants to play around with it can
pull your changes.

You can annotate that you are still working on it by Prefixing "WIP:" on
the PR. A PR will be Automagically updated with any changes you push to
the source branch during the PR's Lifetime.

I am doing the same for the Zabbix PR.

Greetings
Till
On 18/04/2019 15.49, Gary Mills wrote:
> On Thu, Apr 18, 2019 at 06:26:55AM +, Alexander Pyhalov wrote:
> 
>> Thank you for your work. Can you open GitHub pull request against
>> http://github.com/OpenIndiana/oi-userland/ with proposed changes?
> 
> I'm not finished yet and not satisfied yet.  All I can do now is to
> file a bug report for the newly-discovered bug.
> 
> 

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

Re: [oi-dev] Toward a SPARC distro of OI

[Till Wegmüller]

Hi Gary

Thank you so much for this Work. I don't personaly use sparc but ir is
good to see people doing this kinds of projects.

Do you know about Agnar's Project to get OI building on SPARC? I can't
remember if I ever pointed you towards him and his OI on Sparc work. His
angle was to jump from an existing OI distro to current packages and
later looking in V9OS.

Greetings
Till

On 17.06.19 13:26, Aurélien Larcher wrote:
> 
> 
> On Mon, Jun 17, 2019 at 11:59 AM Gary Mills  > wrote:
> 
> I'm part way through this long project now.  I began with v9os
> installed on a Sun T2000.  v9os is a SPARC distribution that uses IPS
> packages.  I've been building IPS packages from oi-userland source.
> This process has gotten easier now that all the build tools I need are
> in IPS packages.  I've been replacing v9os packages with oi-userland
> packages.  My goal is to replace all of them, and finally to produce a
> text ISO and package repository for SPARC that's entirely based on
> oi-userland.
> 
> So far, I've built and packaged versions 5, 6, and 7 of the gcc
> compiler.  The commands for IPS packages are all packaged for python
> 2.7.  My system now has 106 packages installed from oi-userland,
> versus 343 packages from v9os.  Most of the oi-userland products
> required very few or no changes to build and package for SPARC.
> 
> For perl, I've removed the 5.16.1 version from v9os and installed
> versions 5.22 and 5.24 from oi-userland.  Likewise, for python, I've
> removed 2.6 and installed 2.7 and 3.4.  Perl libraries are all
> packaged for 5.22.  Python libraries are all packaged for 2.7.
> 
> I'm submitting this message to the mailing list mostly as a progress
> report.  I would, of course, appreciate a bit of help with this
> project.
> 
> 
> Congratulations Gary this is great :)
> If we get to the point that we can setup a build machine this would
> secure your work.
> Kind regards
> 
> Aurélien
> 
>  
> 
> 
> 
> -- 
> -Gary Mills-            -refurb-                -Winnipeg, Manitoba,
> Canada-
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org 
> https://openindiana.org/mailman/listinfo/oi-dev
> 
> 
> 
> -- 
> ---
> Praise the Caffeine embeddings
> 
> ___
> 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] Image Packaging Developer's Guide

[Till Wegmüller]

This guide was very helpful in making the Go version of the IPS
Repository server. I would very much like to preserve this.

So +1 for initiating that effort.

As to merging into oi-docs I would like to get the opinion of the Omnios
People about the docs. I don't think it to be wise to diverge IPS
versions between the two illumos distros seing how little manpower we
have. I would thus argue towards a shared documentation in a repository
where both teams work with or regularly update/merge/fork.

Greetings
Till

On 22.05.19 08:53, Alexander Pyhalov via oi-dev wrote:
> Also after fixing a bit more issues, I've got
> 
> http://buildzone.oi-build.r61.net/dev-guide/
> 
> Looks like real 'Packaging and Delivering Software with the Image Packaging 
> System' guide :)
> 
> С уважением,
> Александр Пыхалов,
> программист отдела телекоммуникационной инфраструктуры
> управления информационно-коммуникационной инфраструктуры ЮФУ
> 
> 
> 
> От: Andreas Wacknitz 
> Отправлено: 22 мая 2019 г. 9:25:34
> Кому: oi-dev@openindiana.org
> Тема: Re: [oi-dev] Image Packaging Developer's Guide
> 
> Am 22.05.19 um 06:57 schrieb Michal Nowak:
> On 05/22/19 06:23 AM, Alexander Pyhalov via oi-dev wrote:
> Hi.
> 
> We have CDDL-licensed Image Packaging Developer's Guide sources under 
> https://github.com/OpenIndiana/pkg5/tree/oi/doc .
> 
> After small changes ( https://github.com/pyhalov/pkg5/tree/dev-guide ) I even 
> could generate http://buildzone.oi-build.r61.net/pkg-guide/ .
> 
> I'm just interested, what do you think? Does it worth fixing/supporting this 
> guide in this format or should we just merge relevant information to oi-docs?
> 
> Best regards,
> Alexander Pyhalov,
> system administrator of Southern Federal University IT department
> 
> Hi,
> 
> it looks like interesting documentation. We don't actually have abundance of 
> IPS documentation. I think it should be merged with oi-docs.
> 
> Michal
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
> +1
> 
> Regards,
> 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] SMF service enabled by default in global zone

[Till Wegmüller]

Hi

The only way I know in the IPS framework is to use variants and two
seperate xml files for zone.global and zone.nonglobal environment

Greetings
Till

On 07.05.19 22:12, Michal Nowak wrote:
> Hi,
> 
> I want to modify a SMF service so it's enabled by default once it's
> installed in global zone. In non-global zone the service must be
> disabled by default and may be enabled by admin manually (e.g. by
> setting SMF prop value).
> 
> How do I do that in SMF? Is there an example of such a service already?
> 
> I figured out that '' does the
> enablement, but how to limit this to global zone?
> 
> Thanks,
> Michal
> 
> ___
> 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] Pecular dependancies in publishing print/cups-filters

[Till Wegmüller]

Hi Gary

PKG uses it's own PATH variable to find libraries. Think of -I for GCC
for example. And that has been modified to include
usr/lib/libjpeg6-ijg/lib already but now also needs usr/gcc/6/lib to be
added.

You can override that by either:
- Setting the dependency in the manifest manually and add
pkg.depend-bypass to the files that complain or
- Modify the Include path PKG searches. I am however unsure which exact
knob in oi-userland to tweak here.

You should see the override either in the Makefile or the Manifest look
for "usr/lib/libjpeg6-ijg/lib" mentioned there.


Hope this Helps
Greetings
Till

On 2019-08-14 02:46, Gary Mills wrote:
> I'm attempting to publish the print/cups-filters package.  The build
> and install were successful, but I get these peculiar errors with the
> publish stage:
> 
> .../components/print/cups-filters/build/manifest-sparc-cups-filters.depend 
> has unresolved dependency '
> depend type=require fmri=__TBD \
> pkg.debug.depend.fullpath=usr/lib/libjpeg6-ijg/lib/libgcc_s.so.1 \
> pkg.debug.depend.reason=usr/lib/cups/filter/pdftopdf \
> pkg.debug.depend.type=elf'.
> .../components/print/cups-filters/build/manifest-sparc-cups-filters.depend 
> has unresolved dependency '
> depend type=require fmri=__TBD \
> pkg.debug.depend.fullpath=usr/lib/libjpeg6-ijg/lib/libgcc_s.so.1 \
> pkg.debug.depend.reason=usr/lib/cups/filter/rastertopdf \
> pkg.debug.depend.type=elf'.
> .../components/print/cups-filters/build/manifest-sparc-cups-filters.depend 
> has unresolved dependency '
> depend type=require fmri=__TBD \
> pkg.debug.depend.fullpath=usr/lib/libjpeg6-ijg/lib/libgcc_s.so.1 \
> pkg.debug.depend.reason=usr/lib/cups/filter/urftopdf \
> pkg.debug.depend.type=elf'.
> 
> The RUNPATH for all three filters is like this:
> 
> /usr/gcc/6/lib:/usr/lib/libjpeg6-ijg/lib
> 
> The libgcc_s.so.1 module is, of course, in /usr/gcc/6/lib .  The
> runtime linker finds it there.  Only libjpeg.so.62 and friends are in
> /usr/lib/libjpeg6-ijg/lib , but the three filters are not using any
> jpeg libraries.  That particular element of the path is unused.  The
> GCC libraries are certainly not there.
> 
> So, what is this error message really telling me?  I can remove the
> unused path element with elfedit, if that will help.  Will it?
> 
> 

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

Re: [oi-dev] Would OI be interested in Pale Moon?

[Till Wegmüller]

I concur. Some politeness goes a long way. This problem with the license
requirements however stems from firefox originally. Only that in
firefox'es case they fought with the debian community and lost. It seems
like the Palemoon community needs to have the same experience. Sadly

Anyhow. Thanks for the work on Palemoon and bringing it to the point of
being distributed as binary. If you would like to contribute more to
OpenIndiana and learn how the oi-userland build system works have a look
at the developers corner in the docs [0]

Manifest files (p5m) are usually genered with the make target
"sample-manifest" and then have some small changes added on top. If any
special cases are required we point them out during Merging of the Pull
Request.

We would greatly welcome if you worked on more packages.

Greetings
Till


[0] http://docs.openindiana.org/dev/userland/

On 11.12.19 09:40, Alexander Pyhalov via oi-dev wrote:
> Hi.
> I was a bit of uncomfortable to point to this issue, but as others already 
> mention this, let this be settled. We will not distribute Pale Moon via OI 
> infrastructure. If someone has free cycles, I'd advice him to look at FF 
> component, which needs some love.
> 
> Best regards,
> Alexander Pyhalov,
> system administrator of Southern Federal University IT department
> 
> 
> От: Adam Števko 
> Отправлено: 11 декабря 2019 г. 11:36
> Кому: OpenIndiana Developer mailing list
> Тема: Re: [oi-dev] Would OI be interested in Pale Moon?
> 
> Thanks Michal for pointing that out. I wasn’t aware of that. Additional 
> reason to avoid it then :)
> 
>> On 11 Dec 2019, at 09:22, Michal Nowak via oi-dev  
>> wrote:
>>
>> On 12/11/19 07:38 AM, Jeremy Andrews wrote:
>>> I ported UXP to illumos and Solaris recently, and I got them to take the
>>> code upstream. I'm pretty anxious about the process now honestly, and
>>> really want everything to work out. There are a few things I'm worried
>>> about, though.
>>> 1. I'm not very familiar with how packages are actually packaged for OI,
>>> and the p5m file for Firefox in particular is... so complicated that
>>> I've been holding off creating a Pale Moon system package for OI until
>>> now, when they're pushing me to try. I was hoping that the subject
>>> wouldn't come up and they'd just want to distribute a binary .tar.xz
>>> file like they do for other operating systems (that kind of package is
>>> very easy to create with a single command). I'm so mixed up because the
>>> .p5m file for Firefox 52 looks so different from the one for Firefox 60,
>>> and includes all these header files, is for 32-bit, etc. And I'm trying
>>> to figure out which differences are due to a change in package design,
>>> and which are due to actual differences in Firefox.
>>> 2. Pale Moon has some unusual requirements. For one thing, it can't use
>>> the system NSS because Mozilla has changed the API somewhat since they
>>> forked. In general, they're leery of using system libraries over the
>>> ones in their own tree because sometimes those libraries have to be
>>> modified in specific ways for the browser. On top of that, they seem to
>>> have a problem with distributing the langpacks with the browser. They
>>> have a site where you can download a langpack of your choice, but you
>>> can't ship it with the browser for some reason.
>>> I'm kind of afraid now that I've done all this for nothing. I'm worried
>>> that their packaging requirements and our packaging requirements may not
>>> line up, and I'll wind up only being able to distribute a tarball on my
>>> own web space that no one will ever download. It's a very good browser,
>>> and the people behind it are actually decent people, but... I'm
>>> overwhelmed with the sense that I've gotten in over my head.
>>
>> Given the hostility Pale Moon developers showed towards a license 
>> non-complying OpenBSD port at 
>> https://github.com/jasperla/openbsd-wip/issues/86, I'd rather avoid this 
>> community at all.
>>
>> The other reason is maintenance cost on the OpenIndiana project. We already 
>> have Firefox and due to it's complexity it gives us hard time to keep-up 
>> even with ESR releases (currently we are stuck at version 60, 68 is the 
>> latest one; the story for the 52->60 transition was the same). Same with 
>> Thunderbird. I am afraid Pale Moon would be another chapter of the very same 
>> story.
>>
>> Michal
>>
>> ___
>> 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

Re: [oi-dev] Nginx missing IPv6 Configuration

[Till Wegmüller]

Hi Tim

No they are dual stack but use ipv6 by default if it is configured as
far as I can see. However it looks like to be something broken with my
router. I sat together with a friend from work a few minutes ago and the
symptoms look weird. I don't even know if I landed on the correct server
or on a proxy from the provider.

I'll have a look with the provider and friends here who know more about
this router and ipv6 set-up until I figure out what it is. Most probably
a misconfiguration on my router.

I got confused by the 404 return code of curl. Should have checked Host
record.

Thanks for the answer.
I'll write again if we find something wrong with pkg.openindiana.org.
Most probably not. Sorry for the noise.

Greetings
Till

On 15.10.19 20:41, Tim Mooney wrote:
> In regard to: [oi-dev] Nginx missing IPv6 Configuration, Till Wegmüller...:
> 
>> Hello fellow developers
>>
>> Today I have configured IPv6 on my servers. Unfortunately now I cannot
>> install any more zones or packages because Our nginx reverse proxy at
>> pkg.openindiana.org is not configured to handle IPv6.
> 
> I'm confused, Till.  Are you saying your servers are now only IPv6, with
> no IPv4?
> 
> I've run my hipster workstation dual-stack (IPv4 and IPv6) for several
> years,
> and the presence of an IPv6 address (actually, several IPv6 addresses) on
> my workstation has never caused any issues communicating with
> pkg.openindiana.org.
> 
> Also, pkg.openindiana.org doesn't currently have an advertised IPv6
> address.  Did it have one earlier when you were testing?  Otherwise,
> I don't understand how your examples could even be using IPv6.
> 
> $ host -t any pkg.openindiana.org
> pkg.openindiana.org descriptive text "91.194.74.133-10"
> pkg.openindiana.org has address 91.194.74.133
> pkg.openindiana.org has SOA record ns1.openindiana.org.
> support.bitnames.com. 2012060801 5400 5400 2419200 300
> pkg.openindiana.org name server ns2.openindiana.org.
> pkg.openindiana.org name server ns1.openindiana.org.
> pkg.openindiana.org name server ns3.openindiana.org.
> 
> Tim
> 
> ___
> 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] Nginx missing IPv6 Configuration

[Till Wegmüller]

Hello fellow developers

Today I have configured IPv6 on my servers. Unfortunately now I cannot
install any more zones or packages because Our nginx reverse proxy at
pkg.openindiana.org is not configured to handle IPv6.

> root@node01:~# curl -6 https://pkg.openindiana.org/hipster/
> curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
> root@node01:~# curl -6 http://pkg.openindiana.org/hipster/

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
http://www.w3.org/1999/xhtml; xml:lang="en" lang="en">
 
  404 Not Found
 
 
  404 Not Found
 

> root@node01:~# curl -4 http://pkg.openindiana.org/hipster/
> This resource can be found at http://pkg.openindiana.org/hipster>/en/index.shtml.root@node01:~#


Could one of the Admins add the required definitions? Otherwise I will
have to remove IPv6 support for the time being.

Or does IPS have a ipv4 only switch like curl has?

Thanks and Greetings
Till

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

Re: [oi-dev] GOCACHE for Jenkins jobs

[Till Wegmüller]

Hi Aurelien

Yes you must define GOCACHE. Go modules requires this path to download
and unpack/compile Build dependencies. It will also speed up any
subsequent runs if this Cache is globally.

Here is my Jenkins config for go 1.11+

environment {
 GOCACHE = "${WORKSPACE}/gocache"
 GO111MODULE = "on"
 GOPATH = "${WORKSPACE}/../gopath"
}

GO111MODULE might not be necessary depending on the Software you are
building but they have to include a note if they do not support go
modules yet. Acording to the Go community it is advised to file a
upstream bug of Go modules are not yet supported.

If you need any Help with Go let me know. I Programm with it as my Day
Job and maintain the OpenIndiana Packages. Chances are I have come
accross an issue before :)

Greetings
Till


On 26.01.20 23:49, Aurélien Larcher wrote:
> Hi,
> it seems that MongoDB 3.4 fails to build on Jenkins because Go 1.12
> requires a path used for caching files.
> 
> "build cache is required, but could not be located: GOCACHE is not
> defined and neither $XDG_CACHE_HOME nor $HOME are defined Error building
> bsondump"
> 
> As a workaround I defined a GOCACHE variable in the Jenkins
> configuration but that is probably not suitable in the long run.
> 
> Kind regards,
> 
> Aurelien
> 
> -- 
> ---
> Praise the Caffeine embeddings
> 
> ___
> 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] vfio / gpu passthrough for Windows 10

[Till Wegmüller]

Hi

Unfortunately not now. The Bhyve work is still very fresh and not
upstreamed yet. I am guessing it will be a couple of months until we
have the first bits. VFIO might not be included in those.

The fastest workaround for that would be to get
https://github.com/OpenIndiana/oi-userland/pull/5528 working on your
machine. Until Bhyve is upstreamed. Alternatively you can use OmniOS
with a desktop installed via pkgsrc.

Greetings
Till

On 08.03.20 23:13, Brandon Philander wrote:
> Does OpenIndiana support vfio / gpu passthrough for Windows 10 in a
> virtual machine, I would like to do some serious gaming. 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] pkg broken after recent pkg update?

[Till Wegmüller]

Ah it is a problem with your version of
/usr/gcc/6/lib/amd64/libstdc++.so.6 being to old.

Can you revert to the BE before the update and run the pkg commands again?

If your version of system/library/g++-6-runtime is below
6.5.0-2019.0.0.2 you must update that manually first before updating pkg.

That should solve your problem. I have
pkg list system/library/g++-6-runtime
NAME (PUBLISHER)  VERSION
 IFO
system/library/g++-6-runtime  6.5.0-2019.0.0.2
 i--

and my pkg works.

Greetings
Till
On 13.03.20 14:00, Predrag Zecevic - Unix Systems Administrator wrote:
> 
> 
> On 03/13/20 13:55, Till Wegmüller wrote:
>> Hi Stephan
>>
>> Thanks for the notice.
>>
>> @Predrag looping you in as you have the same problem.
>>
>> Unfortunately you will need to revert to a previous BE to fix it.
>>
>> This seems to be a wird one. The missing symbol ist part of
>> /usr/gcc/6/lib/amd64/libstdc++.so.6 which is installed by
>> system/library/g++-6-runtime. The dependencies of the packages are
>> sound. Which version of library/python/rapidjson-35 have you installed?
>> Do you have packages from other publishers?
>>
>> I just updated a zone to test and have system/library/g++-6-runtime
>> properly installed. No problem with pkg for me.
>>
>> What is the output of the following commands on your systems?
>> ldd /usr/lib/python3.5/vendor-packages/rapidjson.cpython-35m.so
>>
>> nm /usr/gcc/6/lib/amd64/libstdc++.so.6 | grep __gxx_personality_v0
>>
>> pkg contents -m library/python/rapidjson-35 | grep
>> system/library/g++-6-runtime
>>
>> Greetings
>> Till
>>
> 
> Thanks Till,
> 
> here we go:
> 
> :; ldd /usr/lib/python3.5/vendor-packages/rapidjson.cpython-35m.so
>     libpython3.5m.so.1.0 =>  /usr/lib/64/libpython3.5m.so.1.0
>     libstdc++.so.6 =>    /usr/gnu/lib/amd64/libstdc++.so.6
>     libstdc++.so.6 (GLIBCXX_3.4.21) =>   (version not found)
>     libstdc++.so.6 (CXXABI_1.3.9) => (version not found)
>     libm.so.2 => /lib/64/libm.so.2
>     libgcc_s.so.1 => /usr/gnu/lib/amd64/libgcc_s.so.1
>     libc.so.1 => /lib/64/libc.so.1
>     librt.so.1 =>    /lib/64/librt.so.1
>     libintl.so.1 =>  /lib/64/libintl.so.1
>     libdl.so.1 =>    /lib/64/libdl.so.1
>     libsendfile.so.1 =>  /lib/64/libsendfile.so.1
> 
> :; nm /usr/gcc/6/lib/amd64/libstdc++.so.6 | grep __gxx_personality_v0
> 000dadd0 T __gxx_personality_v0
> 001c31e0 d DW.ref.__gxx_personality_v0
> 
> :; pkg contents -m library/python/rapidjson-35 | grep
> system/library/g++-6-runtime
> Traceback (most recent call last):
>   File "/usr/bin/pkg", line 87, in 
>     import pkg.actions as actions
>   File "/usr/lib/python3.5/vendor-packages/pkg/actions/__init__.py",
> line 68, in 
>     globals(), locals(), [modname])
>   File "/usr/lib/python3.5/vendor-packages/pkg/actions/hardlink.py",
> line 33, in 
>     from . import generic, link
>   File "/usr/lib/python3.5/vendor-packages/pkg/actions/generic.py", line
> 49, in 
>     import pkg.variant as variant
>   File "/usr/lib/python3.5/vendor-packages/pkg/variant.py", line 36, in
> 
>     from pkg.misc import EmptyI
>   File "/usr/lib/python3.5/vendor-packages/pkg/misc.py", line 76, in
> 
>     import pkg.json as json
>   File "/usr/lib/python3.5/vendor-packages/pkg/json.py", line 24, in
> 
>     from rapidjson import loads, load, dumps, dump, JSONDecodeError
> ImportError: ld.so.1: python3.5: fatal: relocation error: file
> /usr/lib/python3.5/vendor-packages/rapidjson.cpython-35m.so: symbol
> __gxx_personality_v0: referenced symbol not found
> 
> 
> Regards.
>> On 13.03.20 10:13, Stephan Althaus wrote:
>>> Hi!
>>>
>>> I did a "pkg update" some minutes ago,
>>> now "pkg" is broken (??)
>>> 
>>> $ sudo pkg refresh
>>> Traceback (most recent call last):
>>>    File "/usr/bin/pkg", line 87, in 
>>>  import pkg.actions as actions
>>>    File "/usr/lib/python3.5/vendor-packages/pkg/actions/__init__.py",
>>> line 68, in 
>>>  globals(), locals(), [modname])
>>>    File "/usr/lib/python3.5/vendor-packages/pkg/actions/group.py", line
>>> 33, in 
>>>  from . import generic
>>>    File "/usr/lib/python3.5/vendor-packages/pkg/actions/generic.py",
>>> line
>>> 49, in 
>>>  import pkg.variant as

Re: [oi-dev] pkg broken after recent pkg update?

[Till Wegmüller]

Hi Stephan

Thanks for the notice.

@Predrag looping you in as you have the same problem.

Unfortunately you will need to revert to a previous BE to fix it.

This seems to be a wird one. The missing symbol ist part of
/usr/gcc/6/lib/amd64/libstdc++.so.6 which is installed by
system/library/g++-6-runtime. The dependencies of the packages are
sound. Which version of library/python/rapidjson-35 have you installed?
Do you have packages from other publishers?

I just updated a zone to test and have system/library/g++-6-runtime
properly installed. No problem with pkg for me.

What is the output of the following commands on your systems?
ldd /usr/lib/python3.5/vendor-packages/rapidjson.cpython-35m.so

nm /usr/gcc/6/lib/amd64/libstdc++.so.6 | grep __gxx_personality_v0

pkg contents -m library/python/rapidjson-35 | grep
system/library/g++-6-runtime

Greetings
Till

On 13.03.20 10:13, Stephan Althaus wrote:
> Hi!
> 
> I did a "pkg update" some minutes ago,
> now "pkg" is broken (??)
> 
> $ sudo pkg refresh
> Traceback (most recent call last):
>   File "/usr/bin/pkg", line 87, in 
>     import pkg.actions as actions
>   File "/usr/lib/python3.5/vendor-packages/pkg/actions/__init__.py",
> line 68, in 
>     globals(), locals(), [modname])
>   File "/usr/lib/python3.5/vendor-packages/pkg/actions/group.py", line
> 33, in 
>     from . import generic
>   File "/usr/lib/python3.5/vendor-packages/pkg/actions/generic.py", line
> 49, in 
>     import pkg.variant as variant
>   File "/usr/lib/python3.5/vendor-packages/pkg/variant.py", line 36, in
> 
>     from pkg.misc import EmptyI
>   File "/usr/lib/python3.5/vendor-packages/pkg/misc.py", line 76, in
> 
>     import pkg.json as json
>   File "/usr/lib/python3.5/vendor-packages/pkg/json.py", line 24, in
> 
>     from rapidjson import loads, load, dumps, dump, JSONDecodeError
> ImportError: ld.so.1: python3.5: fatal: relocation error: file
> /usr/lib/python3.5/vendor-packages/rapidjson.cpython-35m.so: symbol
> __gxx_personality_v0: referenced symbol not found
> 
> 
> Did i miss something?
> 
> 
> Greetings,
> Stephan
> 
> 
> On 03/12/20 21:31, Alexander Pyhalov via oi-dev wrote:
>> Hi.
>>
>> I need reviewers and testers for
>> https://github.com/OpenIndiana/oi-userland/pull/5600. I personally
>> have no means to test it. Basic motivation for me was to switch it to
>> Python 3.5.
>> To build it you'll need 64-bit sane-backends:
>> https://github.com/OpenIndiana/oi-userland/commit/a793b0414355f0925b42c8ac67a4ef116698c3d7
>>
>>
>> С уважением,
>> Александр Пыхалов,
>> программист отдела телекоммуникационной инфраструктуры
>> управления информационно-коммуникационной инфраструктуры ЮФУ
>>
>>
>> ___
>> 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] Binary-only packages

[Till Wegmüller]

Hi Alexander

On 29.03.20 16:12, Alexander Pyhalov via oi-dev wrote:
> documentation/gnome/gnome-user-docs   2.32.0-2018.0.0.0  
> i--

Apart from this one all packages are from 2013.

Are they even installable? My guess is the incorporations would block
them from being installed at all.

Looks like a leftover from an older build system.

Greetings
Till

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

[oi-dev] Incorporation version constraints

[Till Wegmüller]

Good evening folks

I was trying to install a current revision of library/gmp with "pkg
install pkg:/library/gmp@6.1.2-2020.0.1.2" and got the following error

Reason:  This version is excluded by installed incorporation
consolidation/userland/userland-incorporation@0.5.11-2020.0.0.12833
  Reject:
pkg://openindiana.org/system/library/gcc-7-runtime@7.5.0-2020.0.1.1:20200330T115834Z
  Reason:  No version matching 'require' dependency
system/library@0.5.11-2020.0.1.19548 can be installed
  Reason:  This version is excluded by installed incorporation
consolidation/userland/userland-incorporation@0.5.11-2020.0.0.12833
  Reject:
pkg://openindiana.org/system/library/gcc-7-runtime@7.5.0-2020.0.1.2:20200414T194235Z
  Reason:  No version matching 'require' dependency
system/library@0.5.11-2020.0.1.19563 can be installed
  Reason:  This version is excluded by installed incorporation
consolidation/userland/userland-incorporation@0.5.11-2020.0.0.12833


The Interesting part is
Reason:  No version matching 'require' dependency
system/library/g++-7-runtime@7.5.0-2020.0.1.1 can be installed

and indeed pkg contents -m consolidation/userland/userland-incorporation
| grep 'g++' shows:

depend facet.version-lock.system/library/g++-7-runtime=true
fmri=system/library/g++-7-runtime@7.5.0-2020.0.0.1 type=incorporate

notice the 0.1 instead 1.1 at the end.

Is this an artefact because we are preparing for the next snapshot or a
bug in the incorporation? If the later could somebody trigger the
buildserver to bump the incorporation properly?

Thanks and greetings
Till

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

Re: [oi-dev] Incorporation version constraints

[Till Wegmüller]

Yeah that VM seems to have had a hiccup in resolving. most probably due
to it being a build machine. I had to completely recreate it. But as
it's a Vagrant box, that is not an issue.

Thanks for having a look though.
Greetings
Till
On 04.05.20 07:51, Andreas Wacknitz wrote:
> Am 03.05.20 um 23:24 schrieb Till Wegmüller:
>> Good evening folks
>>
>> I was trying to install a current revision of library/gmp with "pkg
>> install pkg:/library/gmp@6.1.2-2020.0.1.2" and got the following error
>>
>> Reason:  This version is excluded by installed incorporation
>> consolidation/userland/userland-incorporation@0.5.11-2020.0.0.12833
>>    Reject:
>> pkg://openindiana.org/system/library/gcc-7-runtime@7.5.0-2020.0.1.1:20200330T115834Z
>>
>>    Reason:  No version matching 'require' dependency
>> system/library@0.5.11-2020.0.1.19548 can be installed
>>    Reason:  This version is excluded by installed incorporation
>> consolidation/userland/userland-incorporation@0.5.11-2020.0.0.12833
>>    Reject:
>> pkg://openindiana.org/system/library/gcc-7-runtime@7.5.0-2020.0.1.2:20200414T194235Z
>>
>>    Reason:  No version matching 'require' dependency
>> system/library@0.5.11-2020.0.1.19563 can be installed
>>    Reason:  This version is excluded by installed incorporation
>> consolidation/userland/userland-incorporation@0.5.11-2020.0.0.12833
>>
>>
>> The Interesting part is
>> Reason:  No version matching 'require' dependency
>> system/library/g++-7-runtime@7.5.0-2020.0.1.1 can be installed
> The problem is probably only on your side. I have checked two of my
> systems, both have
> system/library/g++-7-runtime 7.5.0-2020.0.1.2   i--
> consolidation/userland/userland-incorporation 0.5.11-2020.0.1.12898 
> i--
> 
> and my build server also
> library/gmp 6.1.2-2020.0.1.2   i--
> 
> Regards
> Andreas
>>
>> and indeed pkg contents -m consolidation/userland/userland-incorporation
>> | grep 'g++' shows:
>>
>> depend facet.version-lock.system/library/g++-7-runtime=true
>> fmri=system/library/g++-7-runtime@7.5.0-2020.0.0.1 type=incorporate
>>
>> notice the 0.1 instead 1.1 at the end.
>>
>> Is this an artefact because we are preparing for the next snapshot or a
>> bug in the incorporation? If the later could somebody trigger the
>> buildserver to bump the incorporation properly?
>>
>> Thanks and greetings
>> 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

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

Re: [oi-dev] Build server repeatedly failed on bhyve-fw

[Till Wegmüller]

Jenkins has the habbit of cleaning all env vars. It looks more like
something that all Unix systems have per default like $HOME is set. We
may choose to set EDK_TOOLS_PATH in Makefiles instead to overwrite this
error.

-Till

On 07.05.20 02:05, Alexander Pyhalov via oi-dev wrote:
> It failed with
> 
> gmake[4]: Leaving directory 
> '/jenkins/jobs/oi-userland/workspace/components/openindiana/bhyve-fw/build/DEBUG/BaseTools/Tests'
> gmake[3]: Leaving directory 
> '/jenkins/jobs/oi-userland/workspace/components/openindiana/bhyve-fw/build/DEBUG/BaseTools'
> BaseTools not found in your tree, and EDK_TOOLS_PATH is not set.
> Please check that WORKSPACE is not set incorrectly in your
> shell, or point EDK_TOOLS_PATH at the directory that contains
> the EDK2 BuildEnv script.
> Restoring files...
> gmake[2]: *** [/jenkins/jobs/oi-userland/workspace/make-rules/justmake.mk:62: 
> /jenkins/jobs/oi-userland/workspace/components/openindiana/bhyve-fw/build/DEBUG/.built]
>  Error 1
> 
> It publishes when run manually.
> 
> Can it be due to WORKSPACE jenkins variable ?
> 
> Strange,
> С уважением,
> Александр Пыхалов,
> программист отдела телекоммуникационной инфраструктуры
> управления информационно-коммуникационной инфраструктуры ЮФУ
> 
> 
> 
> От: Andreas Wacknitz 
> Отправлено: 6 мая 2020 г. 23:20
> Кому: OpenIndiana Developer mailing list
> Тема: [oi-dev] Build server repeatedly failed on bhyve-fw
> 
> Hi all,
> 
> for an unknown reason the jenkins build repeatedly failed on the new
> bhyve-fw package. This is probably because of a local problem pn the
> server as the package gets successfully published on other systems. Is
> there anybody left with access rights to fix this?
> 
> Regards
> 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
> 

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

Re: [oi-dev] IPS package

[Till Wegmüller]

My usual workflow diverges from your at the "pkg set-publisher" stage.

I do. 'pkg set-publisher --sticky --search-before openindiana.org -g
file://$ABSPATHTOREPO userland'

Where userland is the publisher and ABSPATHTOREPO is the absolute path
to the repository including the starting /.


Hope this helps
Greetings
Till

On 11.05.20 14:00, G B via oi-dev wrote:
> I attempted to create an IPS package of Racket, the programming
> language, and everything seemed to have worked correctly.  But when I
> tried to install it from my local repository it fails.
> 
> root@pluto:/# pkg install racket
> 
> pkg install: The following pattern(s) only matched packages that are not
> available
> for the current image's architecture, zone type, and/or other variant:
>     racket
> 
> These are the steps I used:
> 
> # pkgsend generate racket | pkgfmt > racket.p5m.1
> # cat racket_manifest
> set name=pkg.fmri value=racket@7.7,5.11-0
> set name=pkg.description value="Racket programming language"
> set name=pkg.summary value="Racket is a general-purpose programming
> language as well as the world’s first ecosystem for language-oriented
> programming."
> set name=variant.arch value=$(ARCH)
> 
> # pkgmogrify racket.p5m.1 racket_manifest | pkgfmt > racket.p5m.2
> 
> # pkgdepend generate -md racket racket.p5m.2 | pkgfmt > racket.p5m.3
> 
> # pkgdepend resolve -m racket.p5m.3
> 
> # pkglint racket.p5m.3.re
> 
> # pkgrepo create local-repository
> 
> # pkgrepo -s local-repository set publisher/prefix=localpublisher
> 
> # pkgsend -s local-repository publish -d racket racket.p5m.3.res
> 
> # pkg set-publisher -p local-repository
> 
> # pkg install racket
> 
> Then I get the error shown above.  This is on OpenIndiana 2020504.  The 
> working directory is racket and the tree is /racket/opt/racket-7.7
> 
> 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] Missing package library/demo/audio-samples

[Till Wegmüller]

Hi Gary

We dont do it regularly, and it is a workaround until I manage to get
IPS fixed. But it is a complex beast. I am working on porting parts to
rust to speedup things. Another angle of attack is to look into our
development process to see if we can organise ourselves better without
userland-consolidation. But nobody had the time for a deepdive into that
right now.

-Till

On 02.09.20 02:24, Gary Mills wrote:
> On Tue, Sep 01, 2020 at 09:03:10AM +0200, Till Wegmüller wrote:
>>
>> We did a cleanup 2-3 Weeks ago as memory consumption from pkg client was
>> getting out of hand. Probably only the two most modern versions are left
>> on the repo right now.
> 
> If you are doing the cleanup regularly, that means that users have to
> add additional packages immediately after an OI update.  A month is
> too late.  That restriction is difficult for users to understand or
> follow.
> 
> 

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

Re: [oi-dev] Missing package library/demo/audio-samples

[Till Wegmüller]

On 31.08.20 23:59, Gary Mills wrote:
> 
> It's the usual dependancy.  When I try to install it now, I get this:
> 
> # pkg install -n library/demo/audio-samples
> Creating Plan (Solver setup): \
> pkg install: No matching version of library/demo/audio-samples can be 
> installed:
>   Reject:  
> pkg://openindiana.org/library/demo/audio-samples@0.5.11-2020.0.1.19915
>  to
>
> pkg://openindiana.org/library/demo/audio-samples@0.5.11-2020.0.1.19994
>   Reason:  This version is excluded by installed incorporation 
> consolidation/osnet/osnet-incorporation@0.5.11-2020.0.1.19874
> 
> I last did an update on 2020-07-06 .  I suppose I have to do it again.
> That's pretty quick, considering that the package is identical, except
> for the name.
> 
> 

We did a cleanup 2-3 Weeks ago as memory consumption from pkg client was
getting out of hand. Probably only the two most modern versions are left
on the repo right now.

Greetings
Till

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

Re: [oi-dev] Missing package library/demo/audio-samples

[Till Wegmüller]

Hi Gary

I am getting:
pkg info -r library/demo/audio-samples
  Name: library/demo/audio-samples
   Summary: Audio Sound Files
   Description: SunOS audio sound files
  Category: System/Media
 State: Not installed
 Publisher: openindiana.org
   Version: 0.5.11
Branch: 2020.0.1.19994
Packaging Date: August 31, 2020 at 01:24:46 AM
  Size: 450.72 kB
  FMRI:
pkg://openindiana.org/library/demo/audio-samples@0.5.11-2020.0.1.19994:20200831T012446Z

So your version seems out of date. I have no clue why pkg wants to query
that specific version. Can you query with the full version? Is there
still a dependant keeping you locked into the old version?

Greetings
Till

On 31.08.20 19:46, Gary Mills wrote:
> Whenever I attempt to examine the package library/demo/audio-samples,
> I get this result:
> 
> # pkg info -r library/demo/audio-samples
> pkg: 
> pkg://openindiana.org/library/demo/audio-samples@0.5.11,5.11-2020.0.1.19874:20200704T015908Z
>   http protocol error: Unknown error code: 404 reason: Not Found
> URL: 
> 'http://pkg.openindiana.org/hipster/openindiana.org/manifest/0/library%2Fdemo%2Faudio-samples@0.5.11%2C5.11-2020.0.1.19874%3A20200704T015908Z'
>  (happened 4 times)
> 
> That's an old version of the package.  Last time I did an update, I
> got library/demo/audio-samples@0.5.11-2020.0.1.19947:20200802T012509Z.
> That one seem to not exist.
> 
> 

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

Re: [oi-dev] I'm taking a break

[Till Wegmüller]

Hey Alexander

First of all, thank you so much for your contributions thus far and
congratulations on your new Position. You definitely deserve yourself a
break so go and enjoy it.

It is of course sad to see you go, but that's how life is, we will
prevail :)

Greetings
Till

On 08.09.20 17:36, Alexander Pyhalov via oi-dev wrote:
> Hi, guys.
> 
> I wasn't sure if this should be a public message, but when I understood that 
> CC list reached > 5 persons, decided to send it here.
> 
> Briefly, I'm taking a break.
> This doesn't mean that I'll not be able to answer your questions or that I 
> will not commit anything to OI repos - I don't know. But for now I'm changing 
> my job and likely will relocate to Moscow in near future. Given that's new 
> position is a new area for me, I'll just have  no time for such 
> time-consuming hobby as OI. 
> 
> I'm still excited about OI and illumos. It was a wonderful experience, but 
> for now our ways parted.
> Good luck. You can always reach me via my gmail account.
> 
> Best regards, 
> Alexander Pyhalov, 
> (still) system administrator of Southern Federal University IT department
> 
> ___
> 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.org WWW site

[Till Wegmüller]

Hi

The webpage has no repository it's a Wordpress installation.
If you have some fixes you can send them as text to this list and so we
can add them. Not ideal but it works for what we have now.


Greetings
Till

On 13.10.20 05:56, Австин Ким wrote:
> Hi,
> 
> How do you submit patches to the content of the main OpenIndiana WWW site at 
> www.openindiana.org and/or where is the GitHub repository for this?
> 
> Thanks,
> Austin
> 
> “We are responsible for actions performed in response to circumstances for 
> which we are not responsible.”  —Allan Massie, _A Question of Loyalties_, 1989
> ___
> 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] Anybody else running named on OI

[Till Wegmüller]

Hey Gary

I think what happened is that the service manifest has gotten an update
between you last updated and now.

I see two user options. One in the Propval and one for the launch script
/lib/svc/method/dns-server. That script takes in the user parameter but
I can't find a line that changes the working directory for non chroot
installations. So that might break the installation for you.
method_credential can have a working directory parameter so the service
does not start in /root. Unfortunately I can't remember or find in my
notes how to do that in the XML. As a workaround I sometimes modified my
smf method scripts with a cd command.

Hope this helps
Till
On 18.10.20 21:36, Gary Mills wrote:
> On Sun, Oct 18, 2020 at 05:25:49PM +0200, Till Wegmüller wrote:
>>
>> Looks like a config error to me.
> 
> Maybe I am the only person running named on OI.
> 
>> Your named was trying to run in the working directory /root as user
>> named. That of course will not work :)
> 
> /root is root's home directory.  All SMF services start there unless
> a different user is specified in the XML file.  So, that's the default
> configuration.  Of course it won't work if the process runs as a
> non-root user.
> 
>> Once a package has been installed it's config is not updated by the
>> distribution, as most people run their own config and IPS's behaviour
>> tends to break configs more than helping make things work.
> 
> That's what I would expect.  My /etc/named.conf file has not been
> changed in the past nine years.  It's the only configuration file
> for named.
> 
>> Whats the content of named.conf?
> 
> All 89 lines?  The only thing of interest is this line:
> 
> options {
>   directory "/var/named";
>   ...
> };
> 
> That's where all my zone files reside.  Them, I do change occasionally.
> 
>> What does /usr/sbin/named-checkconf say
>> about config errors?
> 
> I haven't run named-checkconf lately, but named runs normally and
> serves all my zones when it runs as root.  It used to do that before
> the update too.
> 
> 

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

Re: [oi-dev] pkg -- huge RSS

[Till Wegmüller]

Well yes, that aswell. To be more precise we will at some point need a
way to make IPS more compatible with rolling-release. Everytime we do
spring cleaning people cannot install software until they do an upgrade.
So it's a way to fix one issue but cause another. IPS should be capable
of not needing spring cleaning this often. Rotating consolidations out
after a year or so is ok. preferably 2 years. But not 2 or 3 times every
snapshot.


-Till

On 09.06.20 00:55, Aurélien Larcher wrote:
> Also our pkg repository needs some belated spring cleaning...
> 
> On Tue, Jun 9, 2020 at 12:39 AM Till Wegmüller  <mailto:toaster...@gmail.com>> wrote:
> 
> Hi Gordon
> 
> Unfortunately yes. We included a patch on the 7th of March which should
> make things a little bit better. There is still work needing to be done
> though. We are approaching this from a few angles but it's going to take
> time to replace components with more efficient ones. And find the things
> which are causing this exactly If you want to see some detailed
> benchmarks how we did it for the Update in march you can find them in
> the PR here [0]. If I know which specific thing is eating RSS I can work
> on replacing that with a bit of Rust code. That works well together with
> python and I know some people which can help make it work.
> 
> If you are interested in helping, I can add documentation to my quite
> extensive experiments with the IPS formats. I have a almost working repo
> server (only search is missing) and pkgrepo in Go [1]. And I am working
> on getting it ported to Rust [2].
> 
> Greetings
> Till
> 
> [0] https://github.com/OpenIndiana/pkg5/pull/75
> [1] https://git.wegmueller.it/Illumos/pkg6
> [2] https://github.com/OpenFlowLabs/libips
> 
> On 08.06.20 18:20, Gordon Ross wrote:
> > Is this normal?
> >
> >    PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU
> PROCESS/NLWP
> >   1289 root     3574M 3489M cpu3    60    0   0:07:10 2.0% pkg/1
> >
> > I bumped up the RAM in this VM to 6GB and it's still struggling to
> complete...
> >
> > root@oi-tank:/export/home/gwr# pkg info package/pkg
> >                 Name: package/pkg
> >              Summary: Image Packaging System
> >          Description: The Image Packaging System (IPS), or pkg(5),
> is the
> >                       software delivery system used on
> OpenIndiana.  This
> >                       package contains the core command-line
> components and
> >                       pkg.depotd server.
> >             Category: System/Packaging
> >                State: Installed
> >            Publisher: openindiana.org <http://openindiana.org>
> >              Version: 0.5.11
> >               Branch: 2019.0.0.5528
> >       Packaging Date: September 25, 2019 at 02:40:19 PM
> >    Last Install Time: November  6, 2019 at 09:26:38 AM
> >                 Size: 14.30 MB
> >                 FMRI:
> >
> pkg://openindiana.org/package/pkg@0.5.11-2019.0.0.5528:20190925T144019Z
> <http://openindiana.org/package/pkg@0.5.11-2019.0.0.5528:20190925T144019Z>
> > Repository Changeset: a6bfc17b
> >           Source URL: https://github.com/OpenIndiana/pkg5/
> >
> > ___
> > oi-dev mailing list
> > oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
> > https://openindiana.org/mailman/listinfo/oi-dev
> >
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
> https://openindiana.org/mailman/listinfo/oi-dev
> 
> 
> 
> -- 
> ---
> Praise the Caffeine embeddings
> 
> ___
> 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] pkg -- huge RSS

[Till Wegmüller]

Hi Gordon

Unfortunately yes. We included a patch on the 7th of March which should
make things a little bit better. There is still work needing to be done
though. We are approaching this from a few angles but it's going to take
time to replace components with more efficient ones. And find the things
which are causing this exactly If you want to see some detailed
benchmarks how we did it for the Update in march you can find them in
the PR here [0]. If I know which specific thing is eating RSS I can work
on replacing that with a bit of Rust code. That works well together with
python and I know some people which can help make it work.

If you are interested in helping, I can add documentation to my quite
extensive experiments with the IPS formats. I have a almost working repo
server (only search is missing) and pkgrepo in Go [1]. And I am working
on getting it ported to Rust [2].

Greetings
Till

[0] https://github.com/OpenIndiana/pkg5/pull/75
[1] https://git.wegmueller.it/Illumos/pkg6
[2] https://github.com/OpenFlowLabs/libips

On 08.06.20 18:20, Gordon Ross wrote:
> Is this normal?
> 
>PID USERNAME  SIZE   RSS STATE  PRI NICE  TIME  CPU PROCESS/NLWP
>   1289 root 3574M 3489M cpu3600   0:07:10 2.0% pkg/1
> 
> I bumped up the RAM in this VM to 6GB and it's still struggling to complete...
> 
> root@oi-tank:/export/home/gwr# pkg info package/pkg
> Name: package/pkg
>  Summary: Image Packaging System
>  Description: The Image Packaging System (IPS), or pkg(5), is the
>   software delivery system used on OpenIndiana.  This
>   package contains the core command-line components and
>   pkg.depotd server.
> Category: System/Packaging
>State: Installed
>Publisher: openindiana.org
>  Version: 0.5.11
>   Branch: 2019.0.0.5528
>   Packaging Date: September 25, 2019 at 02:40:19 PM
>Last Install Time: November  6, 2019 at 09:26:38 AM
> Size: 14.30 MB
> FMRI:
> pkg://openindiana.org/package/pkg@0.5.11-2019.0.0.5528:20190925T144019Z
> Repository Changeset: a6bfc17b
>   Source URL: https://github.com/OpenIndiana/pkg5/
> 
> ___
> 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 Wegmüller]

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

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.


-Till

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 dependency skips for libGL and
libEGL:

file path=usr/lib/$(MACH64)/libgstgl-1.0.so.0.1602.0 \
     pkg.depend.bypass-generate=libGL\.so\.1 \
     pkg.depend.bypass-generate=libEGL\.so\.1


This leads me to wonder whether the set of meson options I chose are
what we want.  Would it be better if I dropped "egl" from gl_platform
and gl_winsys?

If I include stuff by mistake that we later decide we don't want, it's
going to be more difficult to get rid of it later than it is to get the
right stuff selected now.

Tim


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

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

[Till Wegmüller]

Just from memory and looking at that patch i think this will be needed 
for oi-userland. If meson during the calling of the proceses eats CFLAGS 
and other env variables then thats the problem with qmake. But also in 
general meson should honor CFLAGS set by other tools.

On 28.10.21 00:22, Alan Coopersmith wrote:

On 10/27/21 2:50 PM, Gary Mills wrote:

On Tue, Oct 26, 2021 at 02:44:25PM -0500, Tim Mooney via oi-dev wrote:


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.


Meson is somewhat broken, except when Unix=Linux.  It also does not
work well for 32 and 64-bit builds.  One solution is to omit the
32-bit build.  If it's really needed, you must find another solution.


Meson has been working pretty well for us for building GNOME & X.Org
packages on Solaris 11.4, though admittedly we are phasing out 32-bit
builds and do carry an extra patch we've never upstreamed to help with
things:

https://github.com/oracle/solaris-userland/blob/master/components/python/meson/patches/013-environment.patch 





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

Re: [oi-dev] crypto/ca-certificates

[Till Wegmüller]

I don't know how open that Release will be. OpenSSL1.0.2 za was included 
into Chef and other softwares. It could be that they just say that, to 
force people to upgrade. But we will have to see. We should have 1.1 or 
be close to that.



-Till
On 29.10.21 15:23, Bob Friesenhahn wrote:

On Fri, 29 Oct 2021, s...@pandora.be wrote:


The next release of OpenSSL 1.0.2 (1.0.2zb - available to premium 
support customers only) will make it possible to build the release 
with added -DOPENSSL_TRUSTED_FIRST_DEFAULT on the build configuration 
command line. That will make the -trusted_first option enabled by 
default by the OpenSSL library.



So an upgrade of OpenIndiana openssl 1.0.2 to 1.0.2zb if that is 
possible could be another approach.


Does OpenIndiana have "premium support"?  How could it be possible for 
an open source system to offer closed "premium support" sources?


Bob


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

Re: [oi-dev] Logitech C930e

[Till Wegmüller]

Hi

I know Firefox's WebRTC is disabled but would only need a couple more 
libraries to enable during build. Then all Web based conferencing tools 
would work. But it is a bit of work to get going.



-Till


On 07.11.21 12:35, s...@pandora.be wrote:


Hi,

I have attached meanwhile a Logitech C930e webcam to the USB 3.1 ports (some 
docs refer to these ports as USB 3.2) on my OpenIndiana system.

This seems to work.  I can record audio with "audacity" so that's already 
working.  The microphone of the webcam works and functions fine.

I have not actually been using the webcam video because there seems no "cheese" package 
in the OpenIndiana repository and I haven't figured out how to capture video with 
"ffmpeg".

So the USB 2.0 device seems to function on the xhci driver for the USB 3.1/3.2 
ports:

# modinfo | grep xhci
103 f7cf5000   e8f0 251   1  xhci (USB xHCI Driver)

# cfgadm -lv usb1/6
Ap_Id  Receptacle   Occupant Condition  Information
When Type Busy Phys_Id
usb1/6 connectedconfigured   ok Mfg:   
Product: Logitech Webcam C930e  NConfigs: 1  Config: 0  
unavailable  usb-miscell  n/devices/pci@0,0/pci1028,98d@14:6

# modinfo usbvc
7e73000   7bf8 303   1  usbvc (USB video class driver)

Cheese is "obsoleted" in the OI repository.  The latest cheese-41 seems to use 
"meson" and doesn't build for me, neither do old versions seem to build.

Perhaps it makes more sense to capture video with "ffmpeg".

But I think ffmpeg is currently built on OpenIndiana without  --enable-libv4l2 
configure option:

https://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2

So the video4linux2 options do not seem to work.

$ ffmpeg -list_formats all
ffmpeg version 3.2.14 Copyright (c) 2000-2019 the FFmpeg developers
   built with gcc 7.5.0 (OpenIndiana 7.5.0-il-0)
   configuration: --prefix=/usr --mandir=/usr/share/man --bindir=/usr/bin 
--libdir=/usr/lib/amd64 --cc=/usr/gcc/7/bin/gcc --enable-runtime-cpudetect 
--enable-mmx --enable-sse --enable-ssse3 --disable-debug --enable-nonfree 
--enable-gpl --enable-postproc --enable-avfilter --enable-swscale 
--enable-libgsm --enable-libxvid --enable-libx264 --enable-libx265 
--enable-libtheora --enable-libmp3lame --enable-libvorbis --enable-libvpx 
--enable-x11grab --enable-libspeex --enable-pthreads --enable-libass 
--enable-openssl --enable-openal --enable-avresample --enable-libschroedinger 
--enable-libopenjpeg --enable-librtmp --enable-vdpau --enable-shared 
--disable-static
   libavutil  55. 34.101 / 55. 34.101
   libavcodec 57. 64.101 / 57. 64.101
   libavformat57. 56.101 / 57. 56.101
   libavdevice57.  1.100 / 57.  1.100
   libavfilter 6. 65.100 /  6. 65.100
   libavresample   3.  1.  0 /  3.  1.  0
   libswscale  4.  2.100 /  4.  2.100
   libswresample   2.  3.100 /  2.  3.100
   libpostproc54.  1.100 / 54.  1.100
Unrecognized option 'list_formats'.

The option list_formats seems not to be supported although according to the 
docs if --enable-v4l2 would be used, it could perhaps work.

The /dev/video0 device is there.

Has anyone suggestions on what other application could be used to test the 
/dev/video0 device ?

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] libpulsecore error

[Till Wegmüller]

Hi Gary

Sounds like an actuator did not run correctly:

We have a couple SMF services that need to be restarted after updates 
one of the needs to be restarted after glib-2.0 files got updated.


Check out the sources here for reference 
https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/transforms/actuators#L46-L79


The FMRI I suspect has an issue is 
svc:/application/desktop-cache/gconf-cache:default and or 
svc:/application/desktop-cache/dconf-update:default


The Patterns ins the Transforms is a standard python regex match of the 
file actions in the manifest. `pkg contents -m`


You may also want to check if the package has the actuator set properly. 
pkg contents .m should output restart_fmri 
svc:/application/desktop-cache/gconf-cache:default as part of the file 
action.


Greetings
Till


On 08.03.23 15:32, Gary Mills wrote:

On Mon, Mar 06, 2023 at 05:19:34PM -0600, Gary Mills wrote:

On Mon, Mar 06, 2023 at 02:27:31PM -0600, Tim Mooney via oi-dev wrote:


What does:

gsettings get org.mate.panel.menubar max-recent-items

report?


   $ gsettings get org.mate.panel.menubar max-recent-items
   No such key “max-recent-items”


The problem seems to be that two keys are missing from the schema.  It
seems simple at first, but the XML files in
/usr/share/glib-2.0/schemas do contain the apparently missing keys.

There are other locations searched, though.  One is
/usr/share/glib-2.0/schemas/gschemas.compiled .  I have not figured
how examine that file.  It may well be correct.  There is also a
".cache" directory in my home directory.  I suppose I can remove or
rename it, and it will be rebuilt.  I haven't tried that yet.




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

Re: [oi-dev] inkscape calls gcc7 and 10

[Till Wegmüller]

On 07.07.23 07:20, Tim Mooney via oi-dev wrote:

> The old all-in-one source is no longer a thing, so if we build from
> released tarballs, we'll potentially need to fetch and extract multiple
> components.

That has been done before and one component can handle multiple sources. 
Worst case one can use a shellscript to handle the download and placing 
of all sources.



1) lib2geom is required, but it could be built and packaged separately.
Nothing else (other than inkscape) that I'm aware of uses it currently.

Would it be preferable to have it as a separate package, or just build it
and package it in the same package as inkscape?
lib2geom would be preferable seperate. Just because it's the first 
consumer it wont mean it's the last.





2) some of the extensions require low-use libraries, like the 'libwpd'
that Udo mentioned.

Should the inkscape extensions that require these esoteric libraries be
split into separate packages, so 'image/inkscape' has fewer dependencies,
but 'image/inkscape/extension/wordperfect' (or whatever) can optionally
be installed to get support for that legacy format?


Yes spilitting things up is a good idea. A base set can always be 
bundled via requirements via a meta package.




Next, 1.2.2 actually builds without *any* of the local patches, though I 
still

need to look through them to see if there are any OI-customization patches
that we still need.

Many of the existing patches are for math library functions like
log(), sin(), pow(), etc. where integers rather than doubles were being
passed.  I can update these so they apply to 1.2.2, but they seem to be
no longer required (probably because of gcc/g++ 10.x).


With int -> double convertions it is simply a build issue.



Question:

3) is it worth updating these patches, if they're not needed to actually
build any more?  I'm tempted to say no, but I'm willing to update them
if Andreas or others have strong feelings about keeping as many  > possible.


As Udo mentioned runtime is most problematic.


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

Re: [oi-dev] GCC rebuilds

[Till Wegmüller]

Hi Stephan

Your idea is sound. The pkg file next to a Makefile in the same 
directory indicate a component.


The pkg file contains a json with all required packages so the grep 
trick works, you can also use jq to filter out the json syntax cleanly.


The rebuild is one thing we should do yes, so if you can bump the 
version numbers I can run it through CI.


It's a good idea! keep going.

-Till

On 01.08.23 07:40, Stephan Althaus wrote:

Hello!

We are stumbling over some faults with regard to the GCC Version change.

i had the idea of a half-automation of these steps:
- find packages that need a rebuild
- patch Makefile and pkg5
- git checkout -b , git add, git commit, etc..

How to identify the appropriate packages ?
When i select packages by " (grep gcc-7-runtime" pkg) == true " i get 
some candidates..


-> Do we have to rebuild all other packages that have been build prior 
to the commit "switch default gcc to version 10"

because of the "ABI change" ??

That would be >200 packages..

Or is my idea "stupid" in the end?

Regards,
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] GCC rebuilds

[Till Wegmüller]

This is what it was in the past and what is currently achieved by 
mediating links to /usr/lib. We had to change it because we could not 
resolve the openssl version problem with a little enough effort for us 
to achieve. So the proble is not the runtime changing places its 
application being compiled explicitly against gcc-7 in the outside of 
/usr/lib location. And somehow loading in the gcc7 runtime. So the only 
thing left to do is to bump the packages and try to fix them until it is 
fixed. Unfortunately with this specific version of virtualbox we the 
maintainers cannot test as we are missing hardware. So for some reason 
virtualbox and some other libs are still missing and it would be 
wonderfull if some people could bump the Revision if they find such 
libraries.


-Till

On 01.08.23 19:25, Peter Tribble wrote:



On Tue, Aug 1, 2023 at 5:28 PM Thomas Wagner > wrote:


On Tue, Aug 01, 2023 at 05:09:26PM +0200, Marcel Telka wrote:
 > On Tue, Aug 01, 2023 at 02:38:32PM +0100, Peter Tribble wrote:
 > > On Tue, Aug 1, 2023 at 6:41 AM Stephan Althaus <
 > > stephan.alth...@duedinghausen.eu
> wrote:
 > > > We are stumbling over some faults with regard to the GCC
Version change.
 > >
 > > Perhaps this would be an opportune moment to reconsider the way
that
 > > libstdc++
 > > (and generally the whole gcc/g++ runtime) is packaged, and to
go for the
 > > obvious
 > > and supported route of only shipping one copy of the runtime -
the one
 > > corresponding to
 > > the latest version of the compiler that you ship (gcc11 ?), and
putting it
 > > directly in
 > > /usr/lib.
 >
 > The obvious question now is:
 > Why it was not done that way since beginning?

Placing a library in /usr/lib/ that caused version incompatibilties
in the past
and most likely will continue to do so every now an then is not the
best idea.
Despite the promised compatibility in newer versions of the runtime
libs.
In rare cases we've seen binaries compiled with an old gcc version
not being
compatible with the latest gcc runtime libs. Especially for C++.


That would be a plain and simple bug; the gcc team take binary 
compatibility very seriously,
and actually understand things like shared library versioning properly. 
To the extent that we
have had a forward-compatible libstdc++ that manages to cleanly handle 
the fact that the
C++ ABI itself changed (leading to the library transparently handling 
the dual ABI from gcc
5.1 onwards) along with multiple versions of the C++ language since 
about GCC 3.4.


Therefore the SFE packaging project points libs and binaries to a
versioned directory to get the version of runtime libs loaded they have
been compiled with.
e.g. binaries look first in /usr/gcc-sfe/4.9/lib and /usr/gcc-sfe/11/lib
for the runtime libs in an early stage.

Regards
Thomas


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




--
-Peter Tribble
http://www.petertribble.co.uk/  - 
http://ptribble.blogspot.com/ 


___
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-dev Digest, Vol 154, Issue 9

[Till Wegmüller]

Hi Clark

That is a known issue at them moment yes.
You will have ti use the mail method to unsibscribe.

Send a mail to mailto:oi-dev-le...@openindiana.org and you are unsubscribed.

Till

On 23.07.23 18:40, clark k weeks wrote:

To Whom It May Concern,

In an effort to unsubscribe from the oi-dev mailing list, I proceeded to 
the https://openindiana.org/mailman/listinfo/oi-dev 
 URL and received 404 
status code, informing me "File not found.”


Therefore, I’m sending this email to inform you that I do wish to be 
removed from the oi-dev mailing list, and, there appears to be an issue 
with the correctness of the specified URL listed in the email I received 
from said mailing list.



Thank you,

Clark K Weeks



On Jul 23, 2023, at 8:00 AM, oi-dev-requ...@openindiana.org 
 wrote:


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] Missing headerfiles for illumos-build in oi-userland

[Till Wegmüller]

Hi Alexander

Are build-essentials installed and what illumos-gate are you trying to 
build? People outside of us are building illumos gate quite often and 
Issues would not hit users considering how often it gets built.


The files can be laying around on the build server after builds thats 
normal. As they are not available inside illumos-gate I would assume 
they are not needed.


What are you trying to build? If you want to contribute to illumos-gate 
it might be better to ask on that list about those files.


Hope this helps
Greetings
Till

On 19.05.23 09:32, Alexander Jung wrote:

Hi,

i can not build illumos-gate anymore in oi-userland, it fails because of 
missing headerfiles like adt_event.h.
On 
https://github.com/illumos/illumos-gate/tree/master/usr/src/lib/libbsm/common there are alo not includet but on https://hipster.openindiana.org/jenkins/job/illumos-gate/ws/components/openindiana/illumos-gate/illumos-gate/usr/src/lib/libbsm/common/ there are still there.


Can someone help me out.


Best regards,
Alex

--
*s c i ls e t*
Alexander Jung
Sohlberg 5
77883 Ottenhöfen

*MOBIL:* (0 17 6) 47 16 6195
*E-MAIL:* a.j...@scilset.de 
*INTERNET:* www.scilset.de 

___
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] phasing out openssl 1.0.2 (mostly)

[Till Wegmüller]

Hello

On 24.02.24 19:23, Marcel Telka wrote:

Sorry, this is not true. Proof:

$ pkg contents -mr library/python/cryptography-39 | grep ^depend.*openssl
dependfmri=pkg:/library/security/openssl-31@3.1.5-2024.0.0.0  type=require
$ grep -i ssl components/python/cryptography/Makefile
REQUIRED_PACKAGES += library/security/openssl-31
$

Please note that you said "all" so single counter example is enough to
prove your statement is not true.


As mentioned on the list some old components landed in that list which 
we can ignore, that does however not proof that the Mechanism we use to 
configure componentes works for each and every component. One such 
component which Goetz and I can see on the list that is actually not per 
default building agianst openssl 3.1 in ist's non default location is 
nginx. It requires script specific settings to properly link to 
openssl3.1. As this is a Hobbyist driven non payed OpenSource project, 
reducing churn is a very sensible idea. These small script changes can 
take many compile cycles af trial and error and thus we loose 
contributors either to frustration or simply them giving up on trying to 
fix the component. We will not be able to catch the people falling 
through the net so we need to make it easy for contributors to help.


Long story short I agree with Goetz suggestion and that mediator change 
was planned once we had a suitably small list of packages we can merge 
in a time window where we can tell people not to update and thus kill 
their system. With the current CI we have to use non default locations 
so it's always a question of picking your poison when we do. Linux 
distros have updated their CI to be able to make these changes, but we 
still need such an infrastructure change. I have as project to add such 
a feature to the infrastructure but that will only start showing up 
during this year.


-Till

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

Re: [oi-dev] OI Mate clock-applet crashes

[Till Wegmüller]

Hi Stephan

> ** (clock-applet:9178): WARNING **: 13:29:39.524: Call can set time zone
> dbus method: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The
> name org.mate.SettingsDaemon.DateTimeMechanism was not provided by any
> .service files

Ths is the info we need to have in these cases. It shows that the dbus 
service `org.mate.SettingsDaemon.DateTimeMechanism` is missing. Some 
googleing from other Operatingsystems shows that this service is 
probably provided by mate-settings-daemon unfortunately in this case the 
service shows also missing on my system `gdbus introspect --system 
--dest org.mate.SettingsDaemon.DateTimeMechanism --object-path /` and my 
mate-clock applet is working. Is your applet charshing only on shutdown?


In the other case I fixed dconf-editor provided the service but here it 
seems more complicated to figure out which mate package should provide 
this service. Can you do a pkg list on all mate packages?


Till

On 03.03.24 14:13, Stephan Althaus wrote:

On 3/3/24 14:10, Stephan Althaus wrote:

Hello!

My clock-applet crashes regularily.

With the latest occurence, i started /usr/libexec/mate/clock-applet 
before i pressed the reload button...


Now i have a core file:

https://duedinghausen.eu/OI/core.clock-applet.gz

Maybe this part of the pstack shows the reason (?)


- thread# 1391 / lwp# 1391 [pool-clock-appl] -
 7fffaf40aa6a _lwp_kill () + a
 7fffaf39b982 raise (6) + 22
 7fffaf375128 abort () + 58
 7fffaa1eb491 _ZN9__gnu_cxx27__verbose_terminate_handlerEv.cold () 
+ 65

 7fffaa1e8376 _ZN10__cxxabiv111__terminateEPFvvE () + 6
 7fffaa1e83d1  ()
 7fffaa1e864c  ()
 7fff9cc2f092 
_ZN23envvar_config_extension10get_configERKN8libproxy3urlE () + 4b2
 7fff9cc252d3 
_ZN8libproxy13proxy_factory10get_configERNS_3urlERSt6vectorIS1_SaIS1_EERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE () + 253
 7fff9cc255a7 
_ZN8libproxy13proxy_factory11get_proxiesERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE () + f7

 7fff9cc25bd2 px_proxy_factory_get_proxies () + 92


What should i do now to narrow it down what the reason is (?)

BTW i don't use any proxy settings that i know of :-/


Regards,

Stephan





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


Hello!

i forgot, this is the console output of the command:

$ /usr/libexec/mate/clock-applet

** (clock-applet:9178): WARNING **: 13:29:39.524: Call can set time zone 
dbus method: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The 
name org.mate.SettingsDaemon.DateTimeMechanism was not provided by any 
.service files


(clock-applet:9178): Gtk-WARNING **: 13:29:39.526: Negative content 
width -9 (allocation 1, extents 5x5) while allocating gadget (node 
button, owner GtkToggleButton)

terminate called after throwing an instance of 'std::runtime_error'
   what():  Unable to read configuration
Abort (core dumped)

Regards,

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] OI Mate clock-applet crashes

[Till Wegmüller]

Hi Stephan

Ok, So it can not be a missing package this time. Did The new user 
account also get this error?


Does manually triggering 
svc:/application/desktop-cache/gio-module-cache:default help?


-Till

On 05.03.24 06:52, Stephan Althaus wrote:

On 3/4/24 11:17, Till Wegmüller wrote:


In the other case I fixed dconf-editor provided the service but here 
it seems more complicated to figure out which mate package should 
provide this service. Can you do a pkg list on all mate packages?


Hello!

I hope this is what you thought of:

$ pkg list|grep mate
desktop/mate/caja 1.28.0-2024.0.0.0  i--
desktop/mate/caja/caja-extensions 1.28.0-2024.0.0.0  i--
desktop/mate/control-center 1.26.0-2024.0.0.2  i--
desktop/mate/marco 1.28.1-2024.0.0.0  i--
desktop/mate/mate-applets 1.28.0-2024.0.0.0  i--
desktop/mate/mate-backgrounds 1.28.0-2024.0.0.0  i--
desktop/mate/mate-calc 1.28.0-2024.0.0.0  i--
desktop/mate/mate-dictionary 1.28.0-2024.0.0.0  i--
desktop/mate/mate-disk-usage-analyzer 1.28.0-2024.0.0.0  i--
desktop/mate/mate-icon-theme 1.28.0-2024.0.0.0  i--
desktop/mate/mate-media 1.28.1-2024.0.0.0  i--
desktop/mate/mate-notification-daemon 1.28.0-2024.0.0.0  i--
desktop/mate/mate-panel 1.28.0-2024.0.0.0  i--
desktop/mate/mate-power-manager 1.26.1-2024.0.0.1  i--
desktop/mate/mate-screensaver 1.28.0-2024.0.0.0  i--
desktop/mate/mate-screenshot 1.28.0-2024.0.0.0  i--
desktop/mate/mate-search-tool 1.28.0-2024.0.0.0  i--
desktop/mate/mate-session-manager 1.28.0-2024.0.0.0  i--
desktop/mate/mate-settings-daemon 1.28.0-2024.0.0.0  i--
desktop/mate/mate-system-log 1.28.0-2024.0.0.0  i--
desktop/mate/mate-themes 3.22.24-2023.0.0.1 i--
desktop/mate/mate-user-guide 1.28.0-2024.0.0.0  i--
desktop/system-monitor/mate-system-monitor 1.26.0-2024.0.0.6  i--
library/desktop/mate/libmatekbd 1.28.0-2024.0.0.0  i--
library/desktop/mate/libmatemixer 1.28.0-2024.0.0.0  i--
library/desktop/mate/libmateweather 1.28.0-2024.0.0.0  i--
library/desktop/mate/mate-common 1.28.0-2024.0.0.0  i--
library/desktop/mate/mate-desktop 1.28.1-2024.0.0.1  i--
library/desktop/mate/mate-menus 1.28.0-2024.0.0.0  i--
terminal/mate-terminal 1.28.1-2024.0.0.0  i--


Regards,

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] No CoWorking session this week due to easter

[Till Wegmüller]

Hello all

We will not have a CoWorking Session tomorrow due to easter :) Enjoy the 
time with the family and don't hack too much. Burnouts are literally a 
Risk to national security!


Sorry had to make that pun
/shows himself out to easter

Happy easter
Till/Toasterson

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

[oi-dev] CoWorking Session 24.03.2024

[Till Wegmüller]

Hello all

Just a quick late reminder.
Don't forget this weeks #OpenIndiana CoWorking Session today 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

Re: [oi-dev] phasing out openssl 1.0.2 (mostly)

[Till Wegmüller]

On 19.04.24 03:43, Goetz T. Fischer wrote:

a few updates here ...

i've been going through the list and picked the ones which are reachable from 
the outside first but
also gave gftp a try. gftp and rsync turned out to be cases which don't take 
openssl 3 by just
settings the usual as well as specific environment variables and don't offer 
related build options
either. with the mediator set to 3.1 however they worked fine. of course that's 
a flaw in the
buildsystem somewhere but these are 2 examples where the additional effort 
wouldn't be justified as
far as i'm concerned.
uw imap and mongodb 4.4 don't support ssl 3 and uw imap's last releaase was in 
2011 anyway. mongodb
would have to be updated to at least 6.0.7 for ssl 3 support.
Which would be good since 4.4 is EOL end of October anyway. Jumping a 
couple of major versions is no problem with a restore procedure. In 
Place it will refuse to start and people will have to revert to older 
boot environments to start it. It is however a package we need to build 
manually as it requires AVX support in the System which our current 
buildserver does not have. But we can work around that.

the last relevant one from the list was proftpd. however, the current version 
1.3.8b uses dprintf()
There is a pending patch or even RTI for that open, 
https://www.illumos.org/issues/16151 WOuld be a good reason to push the 
illumos people a bit :)

which indiana doesn't have so that would have to be patched first before trying 
ssl things. the
buildsystem though, like gftp and rsync, only has a general --enable-openssl 
option which could
cause similar problems as with rsync and gftp.
also on the list is tor. that i didn't try because i'm not sure how much that's 
actually used and
whether we wanna keep it given its reputation. personally i like tor and use it 
quite often for
"normal" browsing just because of the anonymity. but that's not my call so ...

If you use it on OpenIndiana that is good enough for me to keep it :)



--
R-A-C
Götz T. Fischer CertIT
+49(0)7225/98 98 79
g.fisc...@r-a-c.de
r-a-c.de

___
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] Co Working Session Sunday April 28th 2024

[Till Wegmüller]

Hello all,

The work on OpenIndiana continues. Join us tomorrow Sunday at 17:00 CEST 
at https://meet.chaostreffbern.ch/OpenIndianaCoWorkingSessions there are 
rumblings of people working on software and we want to look again into 
package quality.


-Till

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