[oi-dev] JDK builds and crypto
As noted on IRC, there might be issues with JDK and crypto on OpenIndiana. The issue is that on Solaris/illumos (and only there) the jdk can offload crypto to the OS using the SunPKCS11 provider. That doesn't always work correctly, there's a flag: -Dsun.security.pkcs11.enable-solaris=false that just disables it so you should get the same behaviour as other platforms. In Tribblix I disable (in .../conf/security/sunpkcs11-solaris.cfg) the bits that I know don't work: https://github.com/tribblix/build/blob/master/patches/sunpkcs11-solaris.cfg.patch In OmniOS I think they change the preference order: https://github.com/omniosorg/omnios-build/blob/master/build/openjdk17/patches/security-pkcs11.patch I suggest you'll need to do one of those for the OI jdk builds too. -- -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
Re: [oi-dev] GCC rebuilds
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
Re: [oi-dev] GCC rebuilds
On Tue, Aug 1, 2023 at 6:41 AM Stephan Althaus < stephan.alth...@duedinghausen.eu> wrote: > Hello! > > 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. To get there would involve rebuilding the versioned runtime packages (make them empty) and creating an unversioned runtime package that they all depend on, but would obviate the need to rebuild any of the consumers, and would largely eliminate any pain in future. -- -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
Re: [oi-dev] Missing headerfiles for illumos-build in oi-userland
Alexander, That header is created by the build itself (if you look at the Makefile in usr/src/lib/libbsm you'll see it's created by running perl against the xml file that actually contains the definitions). So I would look at the nightly log file to work out why that perl invocation failed. On Fri, May 19, 2023 at 8:38 AM 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 l s 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 > -- -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
Re: [oi-dev] sqlite-3 mapfile needs API updates
For what it's worth, rather than try and continually chase the API changes,
in
Tribblix I recently dropped the mapfile entirely, and Solaris has done the
same
(the file is in the repo, but it's no longer used). I suggest you follow
that path too.
https://twitter.com/ptribble/status/1592625542435835905
On Fri, Mar 10, 2023 at 7:42 AM Tim Mooney via oi-dev <
oi-dev@openindiana.org> wrote:
>
> All-
>
> I think the mapfile that's being used with our sqlite-3 is out of date,
> and it's causing symbols that should be part of the public API to be
> tagged as 'local', rather than 'global'.
>
> The two I've noticed that should be 'global' are
>
> sqlite3_bind_pointer
> sqlite3_result_blob64
>
> but now that I know it's because of our mapfile, I've found many more,
> and I've only begun looking. Example:
>
> https://www.sqlite.org/bindptr.html
>
> Those functions were added at 3.20.0 in 2017, but are being marked 'local'
> by our mapfile.
>
> If I modify our mapfile so the most recent group:
>
> SYMBOL_VERSION sqlite_3.31.1 {
> global:
> sqlite3_column_origin_name;
> sqlite3_column_origin_name16;
> sqlite3_column_table_name;
> sqlite3_column_table_name16;
> sqlite3_drop_modules;
> sqlite3_filename_database;
> sqlite3_filename_journal;
> sqlite3_filename_wal;
> sqlite3_hard_heap_limit64;
> sqlite3_keyword_check;
> sqlite3_keyword_count;
> sqlite3_keyword_name;
> sqlite3_stmt_isexplain;
> sqlite3_uri_key;
> sqlite3_value_frombind;
> } sqlite_3.19.0;
>
>
> Becomes something like this:
>
> SYMBOL_VERSION sqlite_3.31.1 {
> global:
> # some symbols listed here
> } sqlite_3.28.0;
>
> SYMBOL_VERSION sqlite_3.28.0 {
> global:
> # some symbols listed here
> } sqlite_3.23.0;
>
> SYMBOL_VERSION sqlite_3.23.0 {
> global:
> # some symbols listed here
> } sqlite_3.22.0;
>
> SYMBOL_VERSION sqlite_3.22.0 {
> global:
> # some symbols listed here
> } sqlite_3.20.0;
>
> SYMBOL_VERSION sqlite_3.20.0 {
> global:
> # some symbols listed here
> } sqlite_3.19.0;
>
>
> is that going to break everything that uses symbols in the current
> sqlite_3.31.1 "block"? Obviously I would add blocks for function
> additions since 3.31.1.
>
> BTW, I looked at the Solaris userland mapfile for sqlite-3 and theirs
> differs significantly from ours, but it actually appears ours is more
> up to date.
>
> Tim
> --
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure /
> Division of Information Technology/701-231-1076 (Voice)
> North Dakota State University, Fargo, ND 58105-5164
>
> ___
> 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
Re: [oi-dev] strange compiler error
Hi, You're passing an option that's only valid for gnu ld, but the ld in use is the illumos one. Presumably you're picking up the gnu ld manual page because of the way your PATH is set, but gcc is explicitly configured to use a particular ld (and as - see the output of 'gcc -v' for how it's configured) rather than picking it out of the PATH. On Fri, Nov 4, 2022 at 8:14 PM Friedrich Kink via oi-dev < oi-dev@openindiana.org> wrote: > Hi all, > > I try to compile the newest asterisk version, but I get the following > linker error: > > /usr/gcc/7/bin/gcc -g -nostartfiles -nodefaultlibs -nostdlib -r -Wl,-b > binary -o res_geolocation/pidf_lo_test.o res_geolocation/pidf_lo_test.xml > ld: fatal: file binary: open failed: No such file or directory > > /usr/gcc/7/bin/gcc -g -nostartfiles -nodefaultlibs -nostdlib -r > -Wl,--format=binary -o res_geolocation/pidf_lo_test.o > res_geolocation/pidf_lo_test.xml > ld: fatal: unrecognized option '--format=binary' > ld: fatal: use the -z help option for usage information > > according to the man page (man ld) both variants are allowed, so I'd > assume that it works (s. below) > > .. > > > -b input-format > --format=input-format > ld may be configured to support more than one kind of object > file. > If your ld is configured this way, you can use the -b option to > specify the binary format for input object files that follow > this > option on the command line. Even when ld is configured to > support > alternative object formats, you don't usually need to > specify this, > as ld should be configured to expect as a default input > format the > most usual format on each machine. input-format is a text > string, > the name of a particular format supported by the BFD libraries. > (You can list the available binary formats with objdump -i.) > > You may want to use this option if you are linking files with > an > unusual binary format. You can also use -b to switch formats > explicitly (when linking object files of different formats), by > including -b input-format before each group of object files in > a > particular format. > > The default format is taken from the environment variable > "GNUTARGET". > > You can also define the input format from a script, using the > command "TARGET"; > > Any idea what else could be wrong? > > kind regards, > >Fritz > > > ___ > 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
Re: [oi-dev] oi-dev Digest, Vol 141, Issue 7
On Sun, May 29, 2022 at 1:47 PM Klaus Elsbernd wrote: > If someone is out there: > > since system/filesystem/usr:default "Completes a dependency cycle", the > internet gave me the hint to look at /var/adm/messages > > I think, I've found the problem, but not the solution: > Just run: /usr/sbin/svccfg delete svc:/system/metainit:default Easiest before the update, but if you've updated already just run that and reboot to clear it. The metainit service hasn't actually existed for years, but SMF still has a record of it, and it's injecting false dependencies. -- -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
Re: [oi-dev] Error building a zrepl package for OI
On Fri, Apr 15, 2022 at 6:53 PM Gary Mills wrote: > I'm attempting to build a "zrepl" package for OI. Zrepl is a "go" > application. It it even possible to package go applications for OI? > > On build, I'm getting this error: > > make[1]: Entering directory > '.../oi-userland-gh/components/sysutils/zrepl/build/amd64' > $GOPATH/go.mod exists but should not > ... > $GOPATH/go.mod exists but should not > GO111MODULE=on go build -mod=readonly -ldflags \ > "-X > github.com/zrepl/zrepl/version.zreplVersion=oi-20200504-2370-gd402c2588" \ > -o "artifacts/zrepl-illumos-" > $GOPATH/go.mod exists but should not > make[1]: *** [Makefile:228: zrepl-bin] Error 1 > make[1]: Leaving directory > '.../oi-userland-gh/components/sysutils/zrepl/build/amd64' > > What causes this error, and how can I prevent it? > The environment variable GOPATH is set to the root of the zrepl source. Any other value will work. If unset, then ~/go, but that's not always ideal. The common pattern in oi-userland (see eg components/sysutils/chezmoi/Makefile) is COMPONENT_BUILD_ENV += GOPATH="$(SOURCE_DIR)/gopath" COMPONENT_INSTALL_ENV += GOPATH="$(SOURCE_DIR)/gopath" -- -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
Re: [oi-dev] The end of python-27
On Thu, Mar 24, 2022 at 3:51 PM Gary Mills wrote: > As some of you may know, Nona and I have been working through a list > of packages that depend on python-27 . The list was originally > published by Aurlien Larcher, with a view to the removal of python-27 > from OI. > > With the integration of PR #7942, there are only two remaining > packages: > > developer/gnome/gnome-doc-utils > image/editor/gimp > > In both of these cases, python-2 is deeply embedded in the product, > and the upstream developers have not completed the conversion to > python-3 . Unless the conversion happens very soon, we have little > choice but to obsolete these two packages, and revive them later when > the conversion is ready. If anyone has a better alternative, please > let us know. > For gimp, can you not simply build with --disable-python? In Tribblix, I've largely eliminated python2. But there are still one or two things that need it (gnome-doc-utils being one, older Node.JS which will eventually go away, but also Pale Moon requires it for build). So I'm actually keeping a python2.7 package, but it only exists to meet a handful of build dependencies so doesn't get installed in the normal course of events, and I'm expecting to keep it that way for a while. -- -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
Re: [oi-dev] Future of PostgreSQL on OpenIndiana
On Sat, Feb 26, 2022 at 11:16 AM Andreas Wacknitz wrote: > Hi all, > > at the moment PostgreSQL 9.6 is our version that is being used for all > packages that need PostgreSQL. This version is not supported upstream > for some months now. The oldest supported version is 10 and this would > be the obvious new version to use for us. > Alas, obsoleting a PostgreSQL version in OpenIndiana means some work to > be done and it looks like nobody is interested enough to do this work > regularly. > > So, my question is how we should proceed with PostgreSQL. Obsoleting 9.6 > and using 10 as our default would mean that in less than 9 months > according to https://www.postgresql.org/support/versioning/ we will need > to touch PostgreSQL again. We will need a volunteer to do this or we > might think about skipping some versions of PostgreSQL now. > > What is your opinion? > I went from 9.6 to 11 in Tribblix some time ago. I'm now just about to go to postgres 13 or 14 (14 assuming I don't find any incompatibilities). I recommend you go forward as far as you can, otherwise you end up doing the migration over and over. -- -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
Re: [oi-dev] What to do with python module dependancies?
On Sun, Jul 18, 2021 at 2:59 PM Gary Mills wrote: > I'm working on a python package that imports many other python > modules. So far I've discovered two python modules that don't have > corresponding packages in OI. There should be dependancies on these > two packages, but the automatic mechanism seems not to add them. > How can I add them myself? Do I do it directly in the P5M file? > > The original package builds and installs with the setup.py method. > It doesn't check for dependancies at all. I don't notice missing > dependancies until I test the module and get an error message when > an "import" fails. I'd like to be able to build a package that does > not have this problem. > I've also noticed the setup.py builds quite happily whether dependencies are present or not. All I do is look at the requires.txt file. Usually present in the .egg-info directory, which may be present in the source or in the build tree. (Some modules are smart enough to handle the fact that dependencies vary between python versions, too.) -- -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
Re: [oi-dev] Let's Encrypt support in 2021.04?
On Mon, May 24, 2021 at 4:59 PM Klaus Elsbernd wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello, > > since this week, my old HP Gen7 server is up and running again and I > ported isfdb to it. > > Now I would like to add letsencrypt certificate to it. > > https://letsencrypt.org/getting-started/ suggested to use certbot. > > Is there any support for letsencrypt in OpenIndiana currently. I tried > to run certbot installation, but it ruined my USB-Installation. (My fault). > I use dehydrated on OmniOS and Tribblix. Works well, and it's just a shell script so very little dependency or installation involved. https://dehydrated.io/ -- -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
Re: [oi-dev] Trouble compiling Juci++ IDE
On Thu, Mar 25, 2021 at 9:09 AM Udo Grabowski (IMK) wrote: > On 25.03.21 07:31, cretin1997 via oi-dev wrote: > > The dependencies of it were listed there: > > > > https://gitlab.com/cppit/jucipp > > > > The problem is there is no gtksourceviewmm-3.0 on OpenIndiana. > > > > No ? Really ? > Yes, really. As stated, gtksourceview is present, but gtksourceviewmm isn't. -- -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
Re: [oi-dev] OpenIndiana 4 sun4u
On Tue, Feb 16, 2021 at 4:30 PM Klaus Ziegler - owner of sunfreeware.de <
kla...@haus-gisela.de> wrote:
> Hi,
>
> as you may know the latest OpenIndiana for SPARC does not run on
> sun4u systems, it always panics during the initial CD boot with:
>
> panic[cpu0]/thread=2a100301c80: vmem_xalloc(): size overflow
>
See:
https://www.illumos.org/issues/10326
I suspect it's unfortunate that Gary's build was from the time period that
had this particular bug.
> later on in the dump output one can see:
> 02a100300f50 zfs:aggsum_init+48 (701348e0, 0, 7b69bbe0, 7b77b3a0, 1, 3)
>%l0-3: 01824000 01814410 02a100300fe8
> 01824000
>%l4-7: 030001a82ee0 01834000
> 0090
> 02a100301000 zfs:arc_state_init+1ec (0, 3, 0, 0, 1, 701167b8)
>%l0-3: 70116898 70116800 70116800
> 70116800
>
> So for me it looks like the problem is the /kernel/drv/sparcv9/zfs module.
> The panic occures in:
> usr/src/uts/common/os/vmem.c line: 1085: panic("vmem_xalloc(): size
> overflow");
>
> enough now, about what isn't working, here's the way I got it working:
>
> 1. lofiadm mount Gary's iso to /mnt, can be done on x86.
> # lofiadm -a `pwd`/OI_2018_02_Text_SPARC.iso
> # mount -o ro -F hsfs /dev/lofi/1 /mnt
>
> 2. extract the boot_archive to a SPARC, must be a SPARC can't be x86!
> # cd /mnt/boot/platform/sun4u
> # ls -al boot_archive
> -rw-r--r-- 1 root root 197425152 Jan. 4 02:16 boot_archive
>
> 3. After you copied the archive to the SPARC system mount it using ufs
> filesystem format:
> # lofiadm -a `pwd`/boot_archive
> # mount -F ufs /dev/lofi/1 /mnt
> # cd /mnt/kernel/drv/sparcv9
> # rcp/scp .
> # ls -al zfs
> -rwxr-xr-x 2 root sys 2229424 Oct 30 2018 zfs
> # cd /
> # umount /mnt
>
> 4. My boot-server is x86, so I copied the modified boot_archive back to
> there.
> Setup tftpboot, the same way like s10s_u11wos_24a used to be booted over
> the net.
> I used the inetboot binary from v9os, but I also verified that it works
> with the
> inetboot from Gary's distribution.
> IMPORTANT: rename "boot_archive" to "sparc.miniroot" in the NFS share,
> which will be mounted for the initial boot via tftpboot.
>
> 5. On the system which you are going to install, insert the
> OI_2018_02_Text_SPARC
> CD and boot from the net:
> ok boot net -rv
> and then you will end up in the installer of Gary's wonderfull
> distribution.
>
> DRAWBACKS:
> 1.) you need an empty, but exsiting zpool "rpool" on the system you'll
> going to install.
> 2.) you have to choose "Install to existing Zpool" - and therfore create
> swap/dump
> devices after the install.
> 3.) you will not be able to create additional zpools on the system you
> have installed.
>
> I have successfully done this for a SunFire v240 and one Enterprise2 -
> works like
> a champ, if you create all your zpools before doing the install. Anyhow
> if you
> do have a CDrom in the target system you can always create additional
> zpools
> using the boot fro the v9os CD (be sure to use the correct drives).
>
> P.S. if the system to be installed is a BroadCom Gigabit based one, also
> exchange
> the bge driver in addition to the zfs module - the bge driver
> fro Gray's release
> didn't work for me - I also used the one fro v9os.
>
> Much Regards
> Klaus
>
> \\\
> (.. )
> =o00=(_)=00o=
>
>
> ___
> 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
Re: [oi-dev] brand10 support broken in OI
On Sat, Jan 30, 2021 at 11:58 AM Klaus Ziegler - owner of sunfreeware.de < kla...@haus-gisela.de> wrote: > Hi, > > Solaris10 branded zone support in Openindiana is broken likely since last > year July, because of the following undefined symbol in s10_brand.so.1: > November, when stack smashing protection was added to userland. https://www.illumos.org/issues/13274 My initial fix in Tribblix, like here, was to roll back the s10_brand pieces to a previous version. The brand code here isn't changing at all. This is a potential fix for illumos-gate: https://github.com/tribblix/tribblix-build/blob/master/illumos/s10-brand-ssp.patch (I have a successful build with it, but haven't installed it yet to test it.) root@myserver:~# zlogin myzone > [Connected to zone 'myzone' pts/2] > ld.so.1: s10_brand.so.1: fatal: relocation error: file > /.SUNWnative/usr/lib/s10_brand.so.1: symbol __stack_chk_guard: > referenced symbol not found > > [Connection to zone 'myzone' pts/2 closed] > > I tried to upgrade my main OI server several times last year, which > always ended > by booting into the previous BE and waiting another month for the next try. > Because this is not a really usefull approach, I went into detail > yesterday and got > the following workaround: mount your previous BE using beadm, copy over > 32/64 bit s10_brand.so.1 shared libraries to /usr/lib resp. /usr/lib/64 > and you are > able to use zlogin again. > The zone seems to be running fine directly after "pkg update" but I wasn't > able to log into it using zlogin. To prove this here are the nm outputs > of both > s10_brand.so.1 libraries: > > root@myserver:/usr/lib/64# ls -al s10_brand.so.1* > -rwxr-xr-x 1 root bin 125128 Juni 21 2020 s10_brand.so.1 > -rwxr-xr-x 1 root bin 125568 Jan. 29 09:57 > s10_brand.so.1.new_pkg_update > root@myserver:/usr/lib/64# nm s10_brand.so.1 | grep __stack_chk_guard > root@myserver:/usr/lib/64# nm s10_brand.so.1.new_pkg_update | grep > __stack_chk_guard > [318] | 0| 0|OBJT |GLOB |0 |UNDEF > |__stack_chk_guard > > Note: this fix is needed for both 32/64 bit libraries, the 32bit one > re-enables zlogin, >and the 64bit one, for example enables "uptime" inside the > zone again. > > I'm not new to SunOS/OI, but I never filled a bug against OI. > > Regards, > Klaus > > > ___ > 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] Writing the USB image
This is just a note I'm forwarding on. There's this thread on reddit: https://www.reddit.com/r/illumos/comments/jdpq5t/cant_live_boot_openindiana_hipster_getting_the/ The documentation should probably be improved - the "old" way to write the USB image should probably be removed or at least be well hidden. And I'm not sure what the currently correct way to write the image is on Windows (and I have no access to Windows either). Cheers, -- -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
Re: [oi-dev] Where should SPARC go?
ut, which I need to fix at some point.) > >> This thread has given me the impression that OpenIndiana has (some?) > >> SPARC support. However according to the OI FAQ I would have to run a > >> different illumos-derived OS for SPARC support ( > >> > https://www.openindiana.org/documentation/faq/#does-openindiana-provide-a-sparc-release > >> ). > > > > This FAQ does not reflect recent developments. Gary Mills has success- > > fully compiled a subset of OpenIndiana to run on SPARC. > > I will contact Gary and find out where this is at now. > > >> Please could somebody clarify for me? Also, would OpenIndiana run on > >> my T5140? > > > > That subset would, yes. > > I'm very interested to find out what this subset is. If the > documentation could be pulled up to date then I think this would help a > lot for new users to understand where SPARC is currently at re: support. > I think if you have a SunBlade desktop (UltraSPARC-III vintage), most of the volume servers (V-prefixed), or a T1/T2/T2+/T3 machine (and even the M3000), then you're in pretty good shape. Older (UltraSPARC-II) will struggle due to sheer age, although illumos should boot on machines like the Ultra 10 and 60. > I would suggest that you investigate LDOMs a.k.a. "Oracle VM for SPARC", > > and install Solaris 11.3 in a control domain on your T5140. Then, you > > can create LDOMs (= SPARC VMs) and install the Illumos-based OS of your > > choice inside those LDOMs. > > OK, so even though Solaris 11.3 is EOL and eventually even security > patches will stop being provided, this would still be the recommended > option? > > I tried reading the document in the 11.3 documentation library that > explains when various aspects of 11.3 will be EOL but unfortunately I > need a support contract to access it. Do you know when security updates > will stop being provided? > > > Currently, there are: > > > > - Solaris 11.3 > > > > - Tribblix (a minimal system using the SVR4 package format) > > > > - OpenIndiana (a subset of Openindiana using IPS packages) > > > > - v9os (an older version of OmniOS, using IPS packages) > > > > - Dilos, running Debian userland on an Illumos-based kernel > > > > Unfortuately, OpenSXCE is not developed any more. > > It seems to me that Tribblix and Dilos are the most actively developed > open source options for SPARC. Would this be an accurate assessment? > Yes. DilOS isn't really mainstream illumos. (Depending on your point of view, this could either be a good or bad thing, but it really is quite divergent.) Tribblix (of which I can speak with authority) is pretty well maintained, and I'm keeping packages up to date. The ISO is a bit old, but that matters less on SPARC than on intel because we don't keep adding support for new processors or technologies - the target platform is static. Tribblix is also what I use to ensure that illumos itself still supports SPARC (developers do keep breaking it - not their fault as they have no way at all to test their changes on SPARC most of the time). > Is OpenIndiana officially focused on x86 or do the development > priorities also include SPARC? (Assuming that the resources exist for > supporting SPARC.) > > > Feel free to ask any questions you might have. The Illumos mailing list > > is also worth joining, if you aren't on it already. > > For the base OS I think it would be wise to choose something well > documented and providing a reliable and robust user experience. > > I'll take your suggestion to start with Solaris 11.3. I will ask, other > people who know, what the EOL date for security updates is. > > I have also subscribed to various illumos lists and am heartened to see > so much development there. > > Thanks again for such a warm welcome. I'm looking forward to starting > work with this machine. > > Kind regards, > > Andrew > -- > OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 > > ___ > 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
Re: [oi-dev] Where should SPARC go?
On Fri, Nov 22, 2019 at 8:43 PM Gary Mills wrote: > On Thu, Nov 21, 2019 at 10:56:11PM +0100, Michal Nowak wrote: > > On 11/17/19 10:39 PM, Gary Mills wrote: > > > I have a series of questions to ask the members of this mailing list. > > > I have information to share with you as well. I already have partial > > > answers to most of the questions, but I'd still like to hear from you. > [...] > > There were 7 contributors to the OpenIndiana/oi-userland repo (which is > the > > bulk of OpenIndiana development) with more than 10 commits for the > 2019.10 > > release. I don't know how many OI users (be it long-term or accidental > ones) > > are out there for the same period of time but I guess it's in low > hundreds. > > I have no doubt that SPARC owners are in the minority. My estimate is > about 12 users and 6 developers. > That's probably slightly low in terms of users. There are currently about 6 active users of Tribblix for SPARC (other than myself). (For reference, there are 50-100 active users of Tribblix on x86.) I suspect the number would increase if illumos on SPARC were more mature. > > Although I consider Gary's OI on SPARC an interesting achievement, I > doubt > > there are enough potential users and developers to sustain any illumos > SPARC > > distro of the same (slow) pace of hipster development. E.g. looking at > > SPARC-related work in illumos, it's only Peter who contributes > significantly > > to this area (mostly by removing entirely obsolete platforms and by > ensuring > > illumos actually builds - and that's, I am afraid, revealing). > > That's partly because illumos already has SPARC support built in: > Peter only fixes things in illumos that are broken. It's not as if there's any hardware development going on that affects the supported SPARC platforms. (Yes, it would be nice to support more current hardware, but what we have is a static target.) Much of the cleanup work that I'm (very very slowly) doing is to try and reduce the blast radius of changes from x86. > I've submitted 14 > bug reports, with patches, to the OI project. I'm aware that the > patches need to be turned into PRs before OI developers will consider > them. Most of the bug reports are not SPARC-specific. I did not need > to submit any bug reports to the illumos project. > > > Given the tiny resources OI project has and can offer, I wish OI and > > "OI"-for-SPARC were independent and related to each other in the same > way OI > > currently relates to OmniOS CE and pkgsrc, that is by sharing knowledge, > > patches. > > Full independance is a good way to cripple SPARC development. OI > source archives, Makefiles, and package manifests are used to build > and publish OI SPARC packages, generally with no change. It's OI all > the way. The only thing that will change is the list of components to > build. > I wouldn't have expected full independence. I would have thought you want your own fork of oi-userland, though, so you can make whatever local changes necessary. One thing I'm finding is that the chance of something building on SPARC is going down over time, so I'm having to hold certain packages on SPARC at older revisions. -- -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
Re: [oi-dev] Where should SPARC go?
Gary, First of all, congratulations on getting this far! I know from experience that it's a non-trivial exercise :-( On Sun, Nov 17, 2019 at 9:39 PM Gary Mills wrote: > I have a series of questions to ask the members of this mailing list. > I have information to share with you as well. I already have partial > answers to most of the questions, but I'd still like to hear from you. > > First of all, how much interest do you have in OI on SPARC? My > interest is as a developer and tester. What is your interest? > I'd like to determine the size of the audience. > My interest is indirect; it's good to see that the illumos on SPARC ecosystem has more participants. > How should I contribute to OI on SPARC? I have plans to build more > packages, and to do so with fewer changes to the OI source. I also > have plans to update the distribution from the current 2018 to 2019 or > 2020. Does this sound reasonable to you? > I think you need to decide what the bounds are (in terms of exactly what packages you're going to include - I know that there's a reasonable number of packages I ignore because they are broken or not interesting, a lot of the desktop stuff seems less than worthwhile for example, and of course there's a whole pile of stuff like Go and Node that's never going to work). Keeping up to date is a good idea. From experience, if you start to drift, it's a devil to catch up. > How should you contribute to OI on SPARC? I've filed bug reports > for many of the changes I've made. They can be seen at: > > https://www.illumos.org/projects/openindiana/issues > > I've attached patches to each bug report, but in order for these > patches to be integrated into the OI source, the patches need to be > turned into PRs for github. They also need to be tested on x86 to > make sure they don't accidentally change anything there. Can you help > with any of this? Can you build packages for SPARC from OI source? > Can you help in any other way? > Generally I'm building a lot of stuff on both x86 and SPARC. If you come across problems, then I'm happy to help. (Although my normal response to anything that doesn't get along is to excise it for the time being and find something more cooperative to work on.) > What type of repository do you prefer? Should it be file-based, as it > is now, or should it be remote, as for OI x86? The repository will > only get larger, as people build more packages and publish them. Will > you download such a large file? I don't know of any way to merge > repositories, so there must be only one. > The one-file repo is fine for a single shot release, for people who only have one system. (Although I imagine that people who have multiple SPARC systems are thin on the ground, sadly.) But as soon as you start considering updates, the download a massive blob model is no longer viable. And I think you should keep the sparc repository (if any) completely separate from the x86 repo the project runs. You'll likely be looking at completely different needs and policies. > Finally, who should coordinate OI on SPARC? Should this be done by > the OI project, or should it be done separately? You're the one doing the work, so that's you. Having the project involved is a drag on their time and a blocker on yours; keeping it as loosely coupled as possible is best. (This is a general theme; generally the x86 and SPARC sides will want to avoid treading on each other's toes. And I occasionally find myself tripping over myself on Tribblix, where I'm both!) > Keep in mind that OI > SPARC uses OI source. Most of it builds and publishes with no > changes. When changes are necessary, my plan has been to introduce > them with no harm to x86 packages built from the same source. Indeed, > some of the changes fix bugs in the corresponding x86 packages. Also > keep in mind that IPS is designed to handle multiple architectures, > making it easy to integrate SPARC with x86. In fact, this is already > done for illumos. > -- -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
Re: [oi-dev] OI SPARC ISO and repository available for download
On Wed, Nov 13, 2019 at 1:38 AM Gary Mills wrote: > On Tue, Nov 12, 2019 at 07:44:35AM +0000, Peter Tribble wrote: > >On Mon, Nov 11, 2019 at 8:23 PM Olaf Bohlen <[1]olboh...@eenfach.de> > >wrote: > > > > A very first quick feedback: > [...] > > It has issues with with mpt_sas on the CD-ROM: > > > >That would be > >[5]https://www.illumos.org/issues/6481 > >which, fortunately, was easy to fix. > > Yes, I saw your changes. > > > --8<---cut here---start->8--- > > Boot device: disk File and args: > > SunOS Release 5.11 Version illumos-07ba7ce06c 64-bit > > Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights > > reserved. > > /kernel/drv/sparcv9/mpt_sas: undefined symbol 'sata_split_model' > > WARNING: mod_load: cannot load module 'mpt_sas' > > WARNING: mpt_sas: unable to resolve dependency, module 'misc/sata' > > not found > > Hostname: openindiana > > --8<---cut here---end--->8--- > > What does the mpt_sas driver do, anyway? I get this error message too, > but I don't notice anything that doesn't work on my T2000. My choices > are to fix it or remove it. > It's the driver for newer LSI cards. Pretty common on intel, less so on SPARC. The fact it was broken for years and nobody complained indicates it's not that heavily used by people running illumos on SPARC. Apart from people installing an add-on card, I think the only place this is used that's likely to affect us is as the main HBA on the T3 and T4 systems. (And we only really support up to T3 anyway, although T4 might mostly work.) -- -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
Re: [oi-dev] OI SPARC ISO and repository available for download
On Mon, Nov 11, 2019 at 8:23 PM Olaf Bohlen wrote: > Gary Mills writes: > > Hi, > > > https://apt.dilos.org/oi-sparc/OI_2018_Text_SPARC.iso.gz > > https://apt.dilos.org/oi-sparc/OI_2018_repository.tar.gz > > [...] > > > The ISO did boot and install on my T2000. I'd like to know if it > > boots on other SPARC machines, and also if it boots and runs in a > > zone. I only tested it on real hardware. > > A very first quick feedback: > > I used a LDOM on a T5220 with 10G RAM and 8 threads, a 100G vdisk > and a vnet. > > Installation went fine, booted right away on the first attempt. > It has issues with with mpt_sas on the CD-ROM: > That would be https://www.illumos.org/issues/6481 which, fortunately, was easy to fix. > --8<---cut here---start->8--- > Boot device: disk File and args: > SunOS Release 5.11 Version illumos-07ba7ce06c 64-bit > Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights > reserved. > /kernel/drv/sparcv9/mpt_sas: undefined symbol 'sata_split_model' > WARNING: mod_load: cannot load module 'mpt_sas' > WARNING: mpt_sas: unable to resolve dependency, module 'misc/sata' not > found > Hostname: openindiana > --8<---cut here---end--->8--- > > And when selecting "whole disk" the install fails being unable to > create the zpool (probably some naming issues with vdisks), but > worked fine on a slice install. > > Now it is installed and I'll install the repo software tomorrow > and give zones a spin. So far this looks amazing and I have to > congratulate you for this awesome result! > > Regards, > > -- > ~ Olaf Bohlen - olboh...@eenfach.de > |~~ Het > /| \Bruine > ___/_|___\ Leven > \__n/# DGCN2 > > ___ > 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
Re: [oi-dev] Hosting site for OI SPARC ISO and repository
Gary, On Fri, Nov 1, 2019 at 5:46 PM Gary Mills wrote: > I'm looking for a hosting site for my OI SPARC ISO and IPS repository. > I don't mind paying for space. All I need is a site that will allow > me to upload large files, so that I can publish the URLs where people > can download the same files. Can anyone recommend such a site? > If it's just the static files, you're more than welcome to use the Tribblix download server for this. Contact me directly if you're interested. > The compressed ISO file is less than 400 megs in size, although the > compressed repository is much larger, over 2 gigs in size. > > I may only need to use this site for a few weeks, as the OI project > will eventually be hosting these files. > > The source is OI with a few modification for SPARC hardware. I began > with v9os, but now it's entirely OI from 2018. I'll publish > information on how to use the ISO and repository as soon as I have > the files ready to download. > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, > Canada- > > ___ > 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
Re: [oi-dev] Weird man page construction
On Mon, Feb 18, 2019 at 11:36 AM Udo Grabowski (IMK) wrote: > Hi, > > I was wondering for a while now why I could not grep man pages anymore, > like 'man ftp|grep netrc', which was working a couple of OI versions > before. Try something like man ftp | col -x -b | grep netrc to strip the formatting. > Today I really got curious and found these weird constructions > in the man page output 'man ftp|od -tc' > > 0121460 \b ~ / \b / . \b . n \b n e \b e t \b > 0121500 t r \b r c \b c \n \n A \b A T \b T T > > That means: most of the characters are backspaced and written again ! > Checked a couple of man pages, most of them have these useless > sequences in them, so grepping man pages is mostly impossible now. > > Is this really intended, or produces some document tool this garbage > in the process of man page generation ? > -- > Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT > http://www.imk-asf.kit.edu/english/sat.php > KIT - Karlsruhe Institute of Technology http://www.kit.edu > Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 > > ___ > 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
Re: [oi-dev] OI Hipster 2018.10 snapshot
On Wed, Oct 31, 2018 at 3:15 PM Bob Friesenhahn < bfrie...@simple.dallas.tx.us> wrote: > On Wed, 31 Oct 2018, Volker A. Brandt wrote: > > > > John is absolutely right. The numbers speak for themselves. :-) > > I see only relatively small compression gains so the content must be > partially compressed already, or does not compress well. > If you look at the numbers, then the compressed sizes of the USB images are essentially the same as the ISO images. The reason is quite simple: the content is the same in both cases, and is compressed already. The USB image, however, has a reasonable amount of padding - and the padding compresses away almost completely. -- -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
Re: [oi-dev] Security patch for Xorg 19.x
On Tue, Oct 30, 2018 at 10:13 AM Udo Grabowski (IMK) wrote: > This Xorg patch should be immediately merged in Hipster: > It was merged and updated packages published last Thursday, by the looks of it: commit b694face8cd955399d90fae658d6a01fb1fa9c5b Author: Aurelien Larcher Date: Thu Oct 25 19:31:53 2018 +0200 xorg-server: CVE-2018-14665 > < > https://gitlab.freedesktop.org/xorg/xserver/commit/50c0cf885a6e91c0ea71fb49fa8f1b7c86fe330e > > > > That check had been part of older Xorgs ,e.g., on oi_151a9. > > See the really nasty CVE-2018-14665: > <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14665> > -- > Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT > http://www.imk-asf.kit.edu/english/sat.php > KIT - Karlsruhe Institute of Technology http://www.kit.edu > Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026 > > ___ > 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
Re: [oi-dev] Virtualbox
On Mon, May 29, 2017 at 8:10 PM, Harry Putnam <rea...@newsguy.com> wrote: > Far as I understood things... anything above 5.0.X, that is, any of > the 5.1.x series will not install due to requiring gt5 I think it was. > It includes its own private copy of Qt, rather than requiring the OS to have one (which in the case of Solaris it usually won't). Actually, I suspect the problem is more likely to be https://www.illumos.org/issues/5709 If you run VirtualBox with LD_DEBUG=versions you'll see (you have to do this as root otherwise setuid gets in the way) ... 19254: 1: version needed processing: file=/opt/VirtualBox/amd64/libQt5XcbQpaVBox.so.5 19254: 1: fileversion 19254: 1: libc.so.1 SUNW_1.22.7 19254: 1: 19254: 1: 19254: 1: ld.so.1: VirtualBox: fatal: libc.so.1: version 'SUNW_1.22.7' not found (required by file /opt/VirtualBox/amd64/libQt5XcbQpaVBox.so.5) ... A quick look at why it wants that version of libc using pvs pvs -vs libQt5XcbQpaVBox.so.5 ... libc.so.1 (SUNW_1.22.7): asprintf; -- -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
Re: [oi-dev] Discussing maintainers visibility in oi-userland
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. -- -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
Re: [oi-dev] XFCE
On Wed, May 10, 2017 at 4:07 PM, Aurélien Larcher < aurelien.larc...@gmail.com> wrote: > > À Mercredi 10 mai 2017, Dariusz Sendkowski a écrit : > > Hi, > > > > Has anybody ever tried to add XFCE desktop environment to oi-userland? > > Or maybe someone has been already working on it > > We decided to add only in oi-userland what could be supported reliably to > avoid packages becoming unmaintained. > Even Enlightenment turned out to be troublesome and was broken 6 months > until I figured the issue. > Even if XFCE is a nice DE, we have already a lot of work coping with Xorg > and MATE so I do not think we discussed it. > Our situation is different than Linux distributions since we need to patch > Linux-specific code, it requires more effort. The take is usually to focus > on integration of selected packages (example: Caja's ZFS snapshot browser > has no equivalent in XFCE). > In short, adding another big DE to oi-userland should come with the > guarantee that someone will maintain it. > I use MATE and Enlightenment only, and I have no tried building XFCE. > To be fair, Xfce take portability pretty seriously, they realise that running on non-Linux platforms is a good selling point and were more than happy to accept my porting patches. It's run on Solaris/illumos for many years and is the default DE on Tribblix. You shouldn't need any patches to get it to build, I just put in a couple of tweaks, nothing more. -- -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
Re: [oi-dev] FOSDEM 2017
On Wed, Nov 9, 2016 at 2:10 PM, Adam Števko <adam.ste...@gmail.com> 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'm interested in going again, this year was a good expereince, a decent mix of illumos people were present. -- -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
Re: [oi-dev] Hi all, please some patience: Just to let you know, VirtualBox-5.1.4 builds and almost packages in my local hipster userland
On Tue, Sep 13, 2016 at 5:27 PM, Мартин Бохниг via oi-dev < oi-dev@openindiana.org> wrote: > Hi all, please some patience: Just to let you know, VirtualBox-5.1.4 > builds > Brilliant! > and almost packages in my local hipster userland but so far without QT5 > frontend. I tried to make it use QT4 via configure, but although this is > still a supported configuration, in reality it is broken. That's why we > really need QT5. > > And atm I'm still waiting for QT5.5 to complete. > ... > Ouch, new problem in QT5.5: > > > Undefinedfirst referenced > symbol in file > qt_memfill16(...) > So I've got what appears to be a functional build of 5.6.1-1 on Tribblix. Which was a bit of a surprise as 5.6.0 didn't work at all last time I tried. Configure command: ./configure --prefix=/usr/versions/Qt-5 -opensource --disable-reduce-exports -no-sql-sqlite -confirm-license -platform solaris-g++ Only changes necessary were to qtbase/configure - first, force bash; second, set CFG_SSE2=yes instead of CFG_SSE2=auto. (The undefined symbols are because SSE2 autodetection is busted, some code thinks yes, some thinks no, so it gets confused and it's best to just force it.) -- -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
Re: [oi-dev] Mate is here (as well as new test ISOs)
Adam, Why prompt for language when there's only one option? > > > I think this has to do with the fact that we didn’t modify installer to > reflect this. Do you think we should ship more languages or it’s fine as it > is (+ language selection screen in that case)? > It just seems odd. I know in Tribblix I removed the prompt because I *know* there's only 1 choice. Bit trickier here because you're presumably also using the installer in cases where there would be multiple choices. > Calling it minimal doesn't quite seem right. It's got bits of X, tcl, tk, > cairo, > GL, berkelydb, mariadb, apr, apr-util, gdbm, graphite, openblas, cdrtools, > 2 copies of python, ruby, fortran, apache. One or two bits I can imagine > being pulled in via dependencies, but a lot of this seems wrong. > > Doesn't have the man command (although it does have a lot of man > pages). I would expect to be able to read man pages > > > Alexander and I worked on the minimal list and we put in there we though > was needed. The list is contained here: https://github.com/ > OpenIndiana/oi-userland/blob/6bb1bbacebdf2ae843ff749275ab6d > 9d45a81ad3/components/meta-packages/install-types/includes/minimal > So I had a quick eyeball of this, and the following notes: developer/dtrace/toolkit - not minimal, and has it been kept sufficiently up to date so that the scripts work? Do we need any/all of the fibre-channel stuff? Or infiniband? storage/svm - does anybody use this? system/management/intel-amt - how many people use this? system/library/storage/ima/header-ima - headers? (generally, I would expect a minimal install to not include any development packages) system/install/tests - tests? driver/network/ce - really? media/cdrtools - not minimal But I suspect the real issue is that the role of such a minimal iso hasn't yet been decided, so it's not clear what its target audience is. > I suppose the most of those packages where dragged in via dependencies. > For packages: > > - runtime/python-26 it is used by pkg/illumos-gate and unless pkg in > OmniOS is updated (we spoke to Dan about it already, but is busy with LX, > so we can’t drop the package. Some illumos-gate consumers also need python > 2.6) > - runtime/python-27 is provided for the userland and it also used > explicitly by the userland. > > We tried to minize the amount of packages depending on python-26, but the > packages coming of out illumos-gate are the main consumers, so there isn’t > really another right now. > > system/man was not omitted on purpose, I added it to the file list now. > > > > We'd like to hear your opinion, which images are necessary for next >> snapshot (supposedly, 2016.10). We think that minimal one, Mate and Gnome >> one are enough. We are going to avoid delivering Gnome ISO image after next >> snapshot (in 2017). >> > > Presumably minimal is the new "text" iso. > > > We don’t consider it to be a replacement for text as of this moment. It’s > just a much stripped down versions of text installer and in the future, > text installer might be deprecated. However, this hasn’t been decided yet. > > Cheers, > Adam > > > ___ > 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
Re: [oi-dev] Mate is here (as well as new test ISOs)
On Tue, Aug 16, 2016 at 4:10 PM, Alexander Pyhalov <a...@rsu.ru> wrote: > > Two new image types: OI_MATE - this is Mate-based LiveDVD and OI_minimal > (we tried to strip down OI a bit). One thing about minimal image - it > doesn't deliver sudo, so initial user just gets root role. Note, these are > test images and not official snapshots. > Well done on shifting to MATE. Some notes on the "minimal" iso: Why prompt for language when there's only one option? Calling it minimal doesn't quite seem right. It's got bits of X, tcl, tk, cairo, GL, berkelydb, mariadb, apr, apr-util, gdbm, graphite, openblas, cdrtools, 2 copies of python, ruby, fortran, apache. One or two bits I can imagine being pulled in via dependencies, but a lot of this seems wrong. Doesn't have the man command (although it does have a lot of man pages). I would expect to be able to read man pages We'd like to hear your opinion, which images are necessary for next > snapshot (supposedly, 2016.10). We think that minimal one, Mate and Gnome > one are enough. We are going to avoid delivering Gnome ISO image after next > snapshot (in 2017). > Presumably minimal is the new "text" iso. Thanks, -- -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
Re: [oi-dev] OpenIndiana Code of Conduct
Adam, I think somebody already mentioned this, but the address shouldn't be > abuse@ which is a well-known email address designed for something else. > > [...] > I replaced it with cond...@openindiana.org. Are you OK with that? > Yes, I'm happy with that. -- -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
Re: [oi-dev] OpenIndiana Code of Conduct
On Sat, Jul 23, 2016 at 6:30 AM, Nikola M <minik...@gmail.com> wrote: > On 07/22/16 02:00 PM, Peter Tribble wrote: > > Overall, I'm happy with most of this. It's about the right length, as well. > > What are you actually happy with? > I'm happy with the original document that Adam posted, with the caveat that I think the reporting mechanism can and should be tightened. > I can say I could be happy with the first affirmative part, that is from > the time of original posting changed, but not the second part with > restrictions and secrecy. > > Have you seen working version at: > http://wiki.openindiana.org/pages/viewpage.action?pageId=31391953 > because document is edited in open, not in closed and on Wiki instead on > the site. > Indeed I have. Your modified version is flawed in the following ways: 1. The title has been changed. "Code of Conduct" is the normal term, use it if that's what is intended 2. It conflates operational procedures and etiquette with conduct. (There may be a place for a "how we operate" document; this is not it.) 3. It does not make clear what is not tolerated (the list Adam gave covers the problems we see much more accurately) 4. It does not provide a mechanism to manage violations. Such a mechanism should be confidential. (Confidential, not secret.) Why? a. Problems can become acrimonious and turn into a flamewar b. People should be comfortable to report problems without fear of retribution 5. It fails to provide adequate attribution -- -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
Re: [oi-dev] OpenIndiana Code of Conduct
Adam, Thanks for doing this. In my view, it's long overdue. Comments below. As part of a larger effort at providing a more formal governance structure > for the OpenIndiana project, > So, there is a wider context to this. Which is a good thing, but it would be good to have that fleshed out. Not necessarily conclusions, but it would be good for the community at large to understand what's missing and what's being done about it. > I’d like to announce on the behalf of OI developers the adoption of an > OpenIndiana Code of Conduct. The draft text for this new document can be > found at http://www.openindiana.org/community/code-of-conduct/. > > We would also like to point out this draft document is open to discussion > and acceptance by the community. > Our desire is for the discussion to be civil and for it to center around > the verbiage of the Code of Conduct. > We do not wish for the discussion to go off topic, or question the need > for such a document. > > Please compose your thoughts and comment with as few replies as necessary > so the community may solidify the final text of this document. > Overall, I'm happy with most of this. It's about the right length, as well. I think you need an explicit reporting mechanism. Something like "email ab...@openindiana.org" or the like. (Of course, you need that to be routed somewhere.) And the first statement about confidentiality means that the 2nd part about not being made public is redundant. There's also no mention of consequences. -- -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
Re: [oi-dev] OpenJDK 8
> oppenjdk ? >> > > We currently ship openjdk 7 as the only Java implementation. > Sorry, what I meant was the typo "oppenjdk". At least, I presumae it's a typo. > >> As a matter of interest, what does the version string look like? >> (The output of 'java -version'; I had to play a bit with the options >> to get it into a format that a number of tools expected, although I >> don't appear to have made a note of which tools were particularly >> fussy about the exact layout of the version string.) >> > > $ /usr/jdk/openjdk1.7.0/bin/java -version > openjdk version "1.7.0_080-internal" > OpenJDK Runtime Environment (build > 1.7.0_080-internal-alp_2016_07_17_16_02-b00) > OpenJDK Server VM (build 24.80-b11, mixed mode) > > $ /usr/jdk/openjdk1.8.0/bin/java -version > openjdk version "1.8.0_92-internal" > OpenJDK Runtime Environment (build 1.8.0_92-internal-oi-1.8.92-b00) > OpenJDK 64-Bit Server VM (build 25.92-b00, mixed mode) > It's unfortunate that pkgsrc don't put the tag that the tarball matches in the file name. As it is, it's difficult to be sure exactly what they've checked out. You should probably set the build number, which ought to be b14 assuming the source matches the release. Eg, I have: # /usr/jdk/openjdk1.8.0_92/bin/java -version openjdk version "1.8.0_92" OpenJDK Runtime Environment (build 1.8.0_92-b14) OpenJDK 64-Bit Server VM (build 25.92-b14, mixed mode) -- -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
Re: [oi-dev] OpenJDK 8
On Mon, Jul 18, 2016 at 4:31 PM, Alexander Pyhalov <a...@rsu.ru> wrote: > Hi, people. > > Does someone want to review or test OpenJDK 8 changeset? > > I could run toy programs and build OpenJDK 8 with OpenJDK 8. > Additional testing is welcome. > > https://github.com/OpenIndiana/oi-userland/pull/2246 > That's quite a diff, although I guess that's because you're building with gcc rather than studio? > OpenJDK 7 stays default one for now. oppenjdk ? As a matter of interest, what does the version string look like? (The output of 'java -version'; I had to play a bit with the options to get it into a format that a number of tools expected, although I don't appear to have made a note of which tools were particularly fussy about the exact layout of the version string.) -- -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
Re: [oi-dev] Error Compiling marco
On Wed, Jul 6, 2016 at 10:33 AM, Till Wegmüller <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
Re: [oi-dev] Making VIM run in a modern mode by default
On Sat, May 21, 2016 at 5:21 PM, Volker A. Brandt <v...@bb-c.de> wrote: > Hello Denys! > > > > VIM runs in non-compatible mode by default on many if not all Linux > > distributions and frankly I see no reasons why would someone want to > > have it in "compatible" mode. > > Because this is not Linux, and the "system" vi should be as close to > the original Solaris vi it replaced. > > Why can't you just set that for your user account? What is the gain? > Remember that the system vi may be used in a limited environment, > such as a serial system console. Don't fix things that aren't broken. > If you want a true vi, why not use a true vi? (On OI, it seems to be in /usr/xpg6/bin/vi - or even /usr/has/bin/vi for the nostalgic.) -- -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
Re: [oi-dev] [OpenIndiana-discuss] OpenIndiana Docs - updated
On Mon, May 16, 2016 at 5:39 PM, Alexander Pyhalov <a...@rsu.ru> wrote: > ken mays via oi-dev писал 16.05.2016 18:19: > >> Hello, >> The 'default' minimal hardware requires =>768MB RAM. The achieved >> hardware minimum recently with the latest illumos kernel is 48MB RAM >> (i.e. in CLI mode). This was recently achieved by Peter Tribble. >> > > I suspect IPS alone will eat 1GB RAM without any issues... So if we speak > about minimum usable system, I'd say 768 RAM is not enough. > Quite, 1GB seems more realistic as a bare minimum. The current Oracle Solaris minimum has risen to 2GB. Those of us messing around at the 48MB point aren't actually expecting people to use such a system! Currently available new hardware is mostly 4GB or more, with a handful of systems (mostly cheap laptops) at 2GB. All my 2007/2008 vintage test boxes have at least 4GB. The interesting thing is people trying to re-use 10-year old boxes. It's probably worth clarifying 32-bit support. I recall Alexander saying recently that it had been effectively dropped, I'm not sure exactly what that means. (I know that OI hasn't really supported 32-bit for a while, I think 64-bit only X was the tipping point.) -- -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
Re: [oi-dev] glib changes review
On Fri, Mar 11, 2016 at 12:03 PM, Alexander Pyhalov <a...@rsu.ru> wrote: > Please, review: > https://github.com/OpenIndiana/oi-userland/compare/Openindiana:oi/hipster...pyhalov:pfexec > > Issues: https://www.illumos.org/issues/6728 > https://www.illumos.org/issues/5633 > > > The issue is that glib incorrectly detects pfexec usage as setuid program > (even when pfexec doesn't change euid). So, it refuses to launch dbus - > https://github.com/GNOME/glib/blob/master/gio/gdbusaddress.c#L1060 > > We heal it by falling back to euid/uid comparison. We also use pfexec to > launch brasero and sound-juicer. > After > https://github.com/OpenIndiana/oi-userland/commit/9f0f786ce02ff7a120952fa34888cdcca5b8469d > console user (Console User) should have "Desktop Removable Media User" > profile and have sys_devices privileges, necessary for brasero and sound > juicer (which uses brasero libraries) to work with CD devices. > > I'm a bit concerned about unexpected security issues which it could cause.. The problem I see with using pfexec is that bad things happen if the user has some other profiles or privileges, so you end up giving those programs rights they don't need. For example, if the user is Primary Administrator then pfexec usually equates to "run as root", which probably isn't what you intend. Generally, using pfexec assumes that the program being run is privilege aware (so it can drop any unexpected privileges). -- -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
Re: [oi-dev] nawk and awk
On Sun, Oct 11, 2015 at 8:41 PM, G B via oi-dev <oi-dev@openindiana.org> wrote: > What are the versions of nawk and awk in 1003 OI Hipster? > Whatever the version of illumos it was built from. Something like mcs -p /usr/bin/awk should give the illumos build the command matches. # pkg search '\*/usr/bin/nawk' > Try pkg search nawk or pkg search /usr/bin/nawk (Basically, either the last component, or full pathname.) > # pkg contents -o pkg.name,path -a ='\*/usr/bin/nawk' > That would be pkg contents -o pkg.name,path -a path=usr/bin/nawk (note, without the leading / this time) > None of them return a package. Also 'awk --version' or 'nawk --version' > doesn't retrun anything. > That's because illumos has its own awk and nawk, rather than gawk. (Unfortunately, the regular illumos awk - the one in /usr/bin/awk - is pretty terrible, and best avoided.) -- -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
Re: [oi-dev] Effort focus
That doesn't seem right. Dconf itself doesn't need gtk3, although dconf-editor does. Generally I've found those parts of MATE I've used to build fairly cleanly. -Peter Sent from my iPad On 27 Jul 2015, at 22:57, Aurélien Larcher aurelien.larc...@gmail.com wrote: Hi, OK, that is weird because altough I built part of MATE with GTK2, there is a dependency to dconf which requires GTK3. Maybe I missed some flag. Best Aurelien On Mon, Jul 27, 2015 at 11:38 PM, benta...@chez.com wrote: Hi Aurélien, I actually didn't meet this issue as I partially built MATE against GTK2. I supposed I assumed that building something that looks like Gnome 2 would be easier on a platform that supports Gnome 2 already. This was my first mistake learning wisdom is a long path. These dependencies are related to GTK3, when I come back in September I'll try to set up a GTK3 build. Then, I'll see what breaks. Desktop wise, I was thinking would it be wiser to keep a close look to what the BSD guys are doing as they have the same issue than OI which is more and more dependencies on linux core features (systemd, udev, authentication/authorisation mechanism,... ). Best regards. Ben - Mail original - De: Aurélien Larcher aurelien.larc...@gmail.com À: OpenIndiana Developer mailing list oi-dev@openindiana.org Envoyé: Mardi 28 Juillet 2015 02:20:24 Objet: Re: [oi-dev] Effort focus Hello, Welcome Ben ! I also tried to build MATE but I encountered dependency issues immediately. atk 2.14 would be a first target [2] but requires also building a newer gobject-introspection and make sure that nothing breaks. Best regards Aurelien [1] http://wiki.openindiana.org/oi/MATE+1.10+Sandbox [2] https://www.illumos.org/issues/6055 On Mon, Jul 27, 2015 at 11:39 AM, benta...@chez.com wrote: Having GTK3 spec files are a good news. I'll focus on that then so we got a GTK3 to build on. I'll leave MATE aside for the moment as we have a working desktop. GTK3 will open more option to desktops alternative or application. Best regards. Franck - Mail original - De: Alexander Pyhalov a...@rsu.ru À: OpenIndiana Developer mailing list oi-dev@openindiana.org Cc: benta...@chez.com Envoyé: Lundi 27 Juillet 2015 17:17:09 Objet: Re: [oi-dev] Effort focus benta...@chez.com писал 27.07.2015 07 :21: Hi, I've been trying for the last 2 month to get some updates to OI in particular Hipster. I tried to update the DE by compiling MATE, then I tried to get an alternative browser to work copnsidering the issue with Firefox and started to compile Midori. Of course, MATE is a hell to compile as it is fragmented all over the place with each modules having its on dependencies. But I reach an interesting point where quite a lot of application were compile but not the main modules (panel, ...) Midori is hard on dependencies as well (GTK+3 - Glib - automake,) I have a very limited time to dedicate (and skills, I have to admit) and would like to make the best out of it so I ask you. Does it make sense to try to get MATE up and running to replace GNOME 2, or get another type desktop, or keep the current one ? Midori has already moved to GTK+3 and more and more applications are designed on top of it, does it make sense to focus the effort on building a functionnal GTK+3 on OI as a starting point ? Hi. I think that MATE would be a valuable thing, and it worth to try making it work, but you can underestimate the work wich is necessary to make it functional. What about GTK3, you can look at https://java.net/projects/solaris-desktop/sources/spec-files/ , it has base-specs/gtk3.spec, SUNWgtk3.spec and SUNWgtk3-engines.spec. They are a valuable starting point. Note, that I couldn't find when you can witch branches int web ui, perhaps you'll have to clone the repo and switch manually to gnome-2-30-s12 branch to see the specs. --- System Administrator of Southern Federal University Computer Center ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- --- LARCHER Aurélien | KTH, School of Computer Science and Communication Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4 , 100 44 Stockholm, SWEDEN --- ___ 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 -- --- LARCHER Aurélien | KTH, School of
Re: [oi-dev] [developer] 2837 - remove print/lp* from gate and use CUPS from userland
What part of the lp stack actually uses apache? I suspect it's only ipp, mod_ipp specifically, and that the rest of the lp stack has no dependency at all. I would be perfectly happy to see all the ipp stuff ripped out (I've never used it, and my understanding is that CUPS provides a much better implementation anyway) especially if it allows us to eradicate apache-13. However., I'm not sure that this extends to the rest of the legacy lp stack. The argument that legacy stuff could simply be dropped off to one side in a legacy repo would be far stronger if we actually had such a repo in place. I regard creating that infrastructure as a necessary prerequisite to any significant pruning of the codebase. (Although I'm not sure it needs a full-blown repo. Tarballs of the source that's ripped out, placed in a well-known location, ought to be adequate.) On Tue, May 6, 2014 at 3:07 PM, Garrett D'Amore develo...@lists.illumos.org wrote: I'd love to see it go. But I will wait for others to complain first. One idea would be to eject it from the gate and put it into a new repo where it could also be updated if people still want it. Sent from my iPhone On May 6, 2014, at 12:48 AM, Alexander Pyhalov develo...@lists.illumos.org wrote: Hello. When I tried to rebuild apache 1.3 again I found out that mod_ssl doesn't like OpenSSL 1.0. Of course, I could look at it and try update it, but does someone really use apache 1.3? Now it's only used as illumos-gate build dependency. Last time the question of removing print/lp* from the gate was rejected partially because cups didn't provide trusted printing support. Our (OI /hipster) version of cups has TX patches. However, I haven't checked that it works. As I understand, most distributions have already stripped this code. Isn't it a good time to reconsider the question - either update dependency to apache 2 or remove it? -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21239177-3604570e Modify Your Subscription: https://www.listbox.com/member/?; Powered by Listbox: http://www.listbox.com --- illumos-developer Archives: https://www.listbox.com/member/archive/182179/=now RSS Feed: https://www.listbox.com/member/archive/rss/182179/21175229-59db2a15 Modify Your Subscription: https://www.listbox.com/member/?member_id=21175229id_secret=21175229-7dd7c4fa Powered by Listbox: http://www.listbox.com -- -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
Re: [oi-dev] oi_151a9 roadmap planning
On Wed, Feb 19, 2014 at 2:35 PM, Andy Stormont andyjstorm...@gmail.comwrote: I'd love to see an SVR4 distro that was actually supported by upstream illumos but I won't be the one to make it happen. Define supported. Tribblix is a pure SVR4 distro from a vanilla illumos-gate, really just a handful of scripts to build the distro. I didn't need anything on the illumos side to make it all work. -- -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
Re: [oi-dev] [discuss] Re: basis for better collaboration on illumos and OpenIndiana: small circle, Big circle
that do not cause incompatibilities. To make some examples from the SchilliX-ON development: The first of which is simply you trying to ram your own personal code down everybody else's throats, which I know I wouldn't accept. The other examples are really a simple case of filing a bug, having code review, and submitting an RTI. If you were actually interested in collaboration rather than criticising the rest of the community for failing to surrender to your every demand, you could do that today. -- -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
Re: [oi-dev] oi_151a9 roadmap planning
On Wed, Feb 12, 2014 at 10:34 AM, Alasdair Lumsden alasdai...@gmail.comwrote: TribbliX was a for fun desktop-oriented distro (correct me if I'm wrong) by someone that hates IPS and loves SVR4 packaging. I got the impression Peter never seemed to want to help OI out directly because of the IPS issue. That's partially true, but not entirely. It's true that I hate IPS, part of that is emotional and psychological scars that will probably never heal, and they run deep. I have no particular love for SVR4 - it's there, it's compatible with every other Solaris system I run, it's good enough (unlike IPS), it doesn't suffer from the crippling technical limitations of IPS, and I'm sufficiently familiar with it that I can use it with zero effort. For a hobby distro, minimizing effort is paramount. Had I come from a different background, I might have chosen rpm or dpkg. Tribblix is definitely for fun, and has the advantage that I completely understand the needs of its target audience. (Currently, just me.) Desktop orientation is a reflection of current state rather than future intentions, though. People naturally work on different things in different ways. If there's a net benefit to working together (and there are always costs to doing so - whether that be making a commitment, surrendering control, fitting in to alien processes, or having to support something you're opposed to) then people will do so; it gets much harder if there isn't a net benefit. I decided that the amount of effort I would have to expend to make another distro do what I want was far higher than the effort needed to directly build it from scratch, and I was right on that. And, just as importantly, I learnt far more from doing so than I would have otherwise. I suspect that there will always be multiple distros - we have multiple packaging systems, variant desktop philosophies, appliance vs server vs desktop vs general-purpose. The real focus ought to be illumos, and any distro adds to the overall ecosystem. Strengthening that ecosystem ought to be the goal, not picking a winning distro or forcing people with different aims and objectives to toe some common party line. In many ways, much of that work needs to be done outside our own community - by working with other communities to strengthen their support of illumos/Solaris based systems. (Ideally, you want other communities to build and distribute software for you. That's one area where IPS is a huge obstacle - all this repository stuff is an intolerable burden on third parties, pushes you in the direction of central control and bottlenecks, and discourages the long tail of drive-by contributors that is key to successful projects. [See what Linus was talking about recently, although that was about the problems with CLAs. Same issue of reducing barriers to participation, though.]) -- -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
Re: [oi-dev] /etc/profile.d and /etc/csh/login.d directories
On Fri, Nov 29, 2013 at 7:44 AM, Alexander Pyhalov a...@rsu.ru wrote: Good morning. On 11/28/2013 13:36, Jonathan Adams wrote: I know this sounds silly, because a standard of sorts already exists (other platforms use something similar), but can we not have a common subdirectory in /etc for these scripts, e.g. /etc/shell.d with the relevant shells/scripts as subdirectories. e.g. /etc/shell.d/profile and /etc/shell.d/login ? I don't think that this is a good idea. It would be confusing. I like /etc/profile.d . Perhaps, I'd prefer to use /etc/profile.d/*.sh for sh scripts and /etc/profile.d/*.csh for csh. But if /etc/csh/login.d is used by Debian, why not do it in a more widespread way? I've not got a debian box to check right now, but /etc/csh/login.d doesn't exist on the Ubuntu system I just checked, and it doesn't exist on Red Hat, which uses /etc/profile.d/*.csh - if you did want to adopt such a mechanism (and that's a good thing - remember my objections are to it being forced onto all users by default) then I would think that /etc/profile.d would be the place to choose. just as a suggestion, which you are free to ignore, when you get a new Apache2 server set up on an Ubuntu box, you get the sites-available and sites-enabled directories. All available scripts/setup are in sites-available, and if they are wanted they are soft-linked into the sites-enabled directory ... do we want to consider doing something like this for shell scripts? I don't know if IPS can deliver link on install. So, if admin later removes a link, it doesn't reappear on pkg update. The only way this could work is for everything to be disabled by default. If it's enabled by default, and you disable it, then IPS would fix it back to enabled, which would violate administrator intent. If you ship everything disabled, then IPS won't touch the enabling links made by an admin, and behaviour on fix or upgrade is safe. Just out of interest, how did you envisage sorting the run order for the scripts in the subdirectories? I think you have to assume that ordering is unspecified. In general, behaviour is badly defined for systems like this - even if the execution order is defined, any script can override or wreck the customizations in other scripts, and changes to any script (or addition or removal of any scripts) can cause random changes to system behaviour. Are we planning on instigating the 2 digit leading order, in a similar fashion to the rc.d scripts? if we were, then we could check for filenames beginning with numbers, which would allow README and other documentation to exist in those directories that isn't run automatically. Well, the systems I've seen use *.sh, so README would get skipped automatically in any case. By default, scripts are read in alphabetical order due to shell patterns expansion rule. I don't think that it has sense to support any particular execution order there. This is a place for additional customizations, which can be skipped/ignored (it seems that on Linux /etc/profile.d/* scripts are used mostly for different auto-completion rules). Not really. Under Red Hat it's mostly junk environment variables and aliases. Ubuntu seems to run a whole load of completions, which doesn't seem to be enabled by default on my Red Hat boxes, but is all specific to bash and doesn't seem to be implemented for other shells. -- -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
Re: [oi-dev] problem with firefox in hipster
On Fri, Jul 19, 2013 at 10:57 AM, Jim Klimov jimkli...@cos.ru wrote: On 2013-07-19 11:51, Udo Grabowski (IMK) wrote: Maybe indeed a C++ incompatibility ? Welcome to the world of binary incompatiblitly, now the last fortress has finally been conquered. Which moves me to think: would this example mean that legacy applications built for Solaris 10 and older, running now on obsolete deployments which might be targeted for upgrade to OI, would likely not run on newer hipster-based GCC-compiled OS releases? That shouldn't ever happen, binary compatibility (within the supported constraints) is a key attribute of Solarisness. There are a number of things here: 1. It's at the application level, not the OS. It shouldn't matter at all whether the underlying Illumos is built with gcc or studio. 2. If you introduce incompatibility, you ship the old library and bump the version number on the new one. 3. In practice, library incompatibility (and dependency hell) is deeply ingrained into many open source projects. Having many dependencies in the overall stack is likely to cause problems. (Interestingly, this means that older applications built for Solaris 9 and earlier are much safer, as they won't have pulled in any of the much larger stack of libraries that were introduced in Solaris 10.) This sort of breakage by changing 3rd-party libraries is excluded from the binary compatibility guarantee. 4. My own experience with Tribblix is that everything just worked even though Tribblix is all gcc. The actual problems I hit were when I built everything with gcc4.7 and then updated to gcc4.8 and things started breaking, so I was stumbling across odd compatibility issues there - I never distributed any of that stuff as a result and will try another gcc4 update later once I work out how to do later updates safely. -- -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
Re: [oi-dev] Bumping libxml2 to v2.9.1
On Fri, Jul 12, 2013 at 9:48 PM, Erol Zavidic ero...@gmail.com wrote: Good evening everybody, I managed to bump libxml2 to version 2.9.1. Please have a look at the changeset and review it please. Library built, tested, published and installed correctly. https://github.com/erolms/oi-userland/compare/libxml2 If all OK I can send pull request then for zlib and libxml2. Have you done a full build of illumos-gate on a system with the updated libxml2 and zlib? Illumos itself is critically dependent on libxml2, and having updates to libxml2 breaking the whole OS has happened in the past. Thanks, -- -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
[oi-dev] Stalled on getting LibreOffice to work
(a, 0, 0, 0) + 97 fea9e3fd _thrp_setup (f9e50240) + 88 fea9e590 _lwp_start (f9e50240, 0, 0, 0, 0, 0) - lwp# 4 / thread# 4 feaa2335 __so_accept (a, 0, 0, 1) + 15 fe82c469 accept (a, 0, 0, 17c0, feee8235, 8534a00) + 23 fef2c63b osl_acceptPipe (8534f88, 0, 0, 0, 0, 0) + 3b feee8235 _ZN7desktop15OfficeIPCThread7executeEv (8534a00, 85353b0, f9f8f600, 0, fef69b4c, 8534a08) + 25 fec73f8d _ZN9salhelper6Thread3runEv (8534a00, 85353b0, fef324ad, fef69b4c, 85353a0, 85353a0) + 2d fe5fc1c2 threadFunc (8534a08, 85353b0, f7a5ffc8, fea9d53b, feb17ac0, fa002000) + 12 fef32889 osl_thread_start_Impl (85353a0, 0, 0, 0) + 189 fea9e3fd _thrp_setup (f9e51a40) + 88 fea9e590 _lwp_start (f9e51a40, 0, 0, 0, 0, 0) - lwp# 5 / thread# 5 feaa2c75 __pollsys (f666ee38, 1, f666ee08, 0, 86f4e08, 2) + 15 fea3d196 poll (f666ee38, 1, 3e8, feb11000, 0, f6694a20) + 66 f9326f99 _ZN3x1116SelectionManager13dispatchEventEi (f6694840, 3e8, fef194f0, 0, f92e649b, f92c0018) + 129 f932715b _ZN3x1116SelectionManager3runEPv (f6694840, 8700348, fef324ad, fef69b4c, f93274b9) + 17b f93274cd call_SelectionManager_run (f6694840, 8700348, f666efc8, fea9d53b, feb17ac0, fa002000) + 1d fef32889 osl_thread_start_Impl (8700338, 0, 0, 0) + 189 fea9e3fd _thrp_setup (f9e52240) + 88 fea9e590 _lwp_start (f9e52240, 0, 0, 0, 0, 0) -- -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
Re: [oi-dev] Stalled on getting LibreOffice to work
On Thu, Jun 6, 2013 at 8:46 PM, Andy Stormont andyjstorm...@gmail.comwrote: Hi Peter. What problems are you using LD_ALTEXEC to sidestep? In my experience gnu ld will quite happily generate binaries which are broken, and while the illumos linker does like to complain a lot - most of the time it has a good reason. Thanks for chiming in. It doesn't work without :-( Bits of the build (which is some private build system that seems very complex and hard to get into the guts of to fix things) keep sending gnu-specific flags. It takes a few seconds to give up with [build LNK] Executable/cpp ld: fatal: unrecognized option '-O' ld: fatal: unrecognized option '-1' ld: fatal: use the -z help option for usage information collect2: error: ld returned 1 exit status not to mention things like [build DEP] LNK:CppunitTest/libtest_basic_vba.so But it's been a while. I've been bashing at this for 6 months on and off, certainly LibreOffice 4 is far cleaner than LibreOffice 3 ever was (thanks largely to some of the early efforts by Jonathan Adams and others) so it's possible that some of these options might be easier to work around now. I think that particular usage comes from solenv/gbuild/platform/solaris.mk so let me see what the build looks like now. (One thing I didn't mention - I've tried using gcc both with the illumos as and the gnu as, and that doesn't make any difference.) -- -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
Re: [oi-dev] OI project reboot required
On Sun, May 12, 2013 at 6:06 PM, Garrett D'Amore garrett.dam...@dey-sys.com wrote: On May 12, 2013, at 8:51 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: It has been a few years since Oracle upstream dropped 32-bit i386 support, so that's just one of the decisions OI has to make - track upstream as is or fork/patch as needed to continue to support 32-bit on i386. Yep. And that has sweeping consequences; lots of things depend upon it this decision. I'm of the opinion that enough time has passed that we should seriously consider doing the same. Its been about a decade since 64-bit x86 systems came on the scene (Opteron was released in June 2003). I seriously considered killing all support for 32-bit CPUs in Tribblix from the start. The main reason I didn't is that it's (currently) extra work to strip out 32-bit from the packages. I haven't seen a serious use of a 32-bit only CPU in production in over 5 years. My OI laptop is 32-bit only. It's on its deathbed, only waiting for me to find a newer one that Illumos will actually boot and install on. And I think most hobbyists upgrade their kit more frequently as well -- I have to believe almost everyone is on 64-bit kit these days. Furthermore, most interesting systems (based on illumos) require more memory than is practical with a 32-bit only CPU. I think that argument is specious, though. Tribblix gives you a fully functional graphical desktop in 512M (OK, so you're not going to run firefox for very long!). The other area is that test or play systems tend to be older ones that aren't in use for front-line service. That's also an interesting area for Illmuos distros, as we might be in better shape for driver support on something that isn't brand new. (As a case in point, none of my available sparc test systems will run S11, as support for all of them was dropped as well.) The same is true of people taking home retired office kit, it's not new. I have to believe we could eliminate a *lot* of baggage by nixing 32-bit support. I *know* we can, because I've nixed a bunch of system utilities in our DEY environment that were delivered in both 32 and 64 bit variants. Not to mention simplification by eliminating the isaexec dance. We're going to have to support a 32-bit userland for some time to come, unfortunately, but we should no longer make that the default, and we should deliver all of our system utilities in 64-bit only form, IMO; and we could entirely kill off the 32-bit kernel. Alternatively, if there is sufficient demand, one could imagine a separate architecture for ia32, that is the 32-bit variant port. I think the key there is to manage the transition. Provided those who want to continue with a 32-bit platform are able to do so, I don't see a problem. But I can imagine distros producing a final 32-bit release, and then moving on. I know I would. It just has to be announced and planned for - it's really a rather major flag day. -- -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
Re: [oi-dev] OI project reboot required
Hi, (Instead of replying to a message in one of the other threads I thought I will create a new one.) Just wanted to say that I don't see a future for the project in its current form. There is simply too many packages and too much baggage for a handful of people to look after. I think you need to go back a level further. What's the project for? Try to put together a quick mission statement (or even a mission word). And work on an elevator pitch that can grab any member of your potential audience. Part of that is thinking about your audience - both the providers (contributors/developers) and consumers (users/customers). And also what differentiates you from other offerings. Specifically, thinking about other similar projects, what would OI offer that you wouldn't get from OmniOS (which I regard as the closest distro)? I think the project needs a new vision and a reboot. If you have any ideas for the project and can write scripts/makefiles to generate a distro/live CDs/etc. - speak up! You don't have to be a leader if you don't want to :) Concentrate on the vision, and get people engaged. That'll give you a start on having manpower to do the work. I had a completely different vision - both directionally and technically - and ended up completely throwing away all the build system(s), and the entire packaging and install infrastructure. Having to largely reinvent a whole mass of functionality for Tribblix from scratch was orders of magnitude easier than using what was inherited from OpenSolaris. -- -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
Re: [oi-dev] Libreoffice status
On Fri, Jan 4, 2013 at 10:11 PM, Paolo Marcheschi paolo.marches...@ftgm.it wrote: Hi Thank you, very much, for sharing your notes. I will try as soon as possible into a clean developer zone. Some links I've found useful (one is a link to Jonathan's work) http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.devel/31802 http://www.linuxfromscratch.org/blfs/view/svn/xsoft/libreoffice.html http://lists.freedesktop.org/archives/libreoffice/2012-July/034802.html My attempts to build on Tribblix got sidetracked both by the holidays and by the release of Enlightenment E17 (finally!). Some comments: I'm using gcc 4.7.2; I've installed Java perl Archive::Zip ant autoconf automake zip (updated) unzip (updated) bison curl clucene hunspell I've found the build to be pretty broken, so if you can build something outside of the Libreoffice build and tell it to use that copy then the build goes much more smoothly. Both clucene and hunspell were built from the tarballs that Libreoffice uses. So disable everything possible and use --with-system if you can. I have the following configure flags --disable-cups --disable-gconf --disable-gtk --without-junit --without-doxygen --disable-mozilla --disable-odk --with-system-openssl --with-system-jpeg --with-system-zlib --with-system-libxml --without-stlport --disable-neon --disable-python --with-system-cairo --with-system-clucene --with-system-hunspell --disable-xmlsec --disable-postgresql-sdbc I've found both the Illumos ld and the gnu ld that come with OI to fail, so I upgraded to GNU coreutils 2.23.1 and set LD_ALTEXEC=/usr/gnu/bin/ld to use that. (This gets even worse with LO 4.0.0 - various pieces call ld with arguments that aren't compatible with any ld I can use.) I find that a regular make fails due to dependency errors. Running a make tail_build explicitly seems to get past that. -- -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
