Re: [oi-dev] pigz wants higher zlib version
On Thu, 21 Sep 2023, Udo Grabowski (IMK) wrote: On 21/09/2023 15:30, Bob Friesenhahn wrote: On Thu, 21 Sep 2023, Udo Grabowski (IMK) wrote: pigz complains about a too old zlib version: pigz: abort: zlib version less than 1.2.3 Is that for real? OpenIndiana is using a zlib from 2006 or earlier? As I recall, zlib did change its ABI. The version is /usr/lib/libz.so.1.3 , so I suspect that this actually means version 1.3. So probably there's a really stupid "version check" in pigz itself. Zlib seems to march to the beat of a different drummer. In zlib 1.2.11 Makefile.in says SHAREDLIBV=libz.so.1.2.11 Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] pigz wants higher zlib version
On Thu, 21 Sep 2023, Udo Grabowski (IMK) wrote: pigz complains about a too old zlib version: pigz: abort: zlib version less than 1.2.3 Is that for real? OpenIndiana is using a zlib from 2006 or earlier? As I recall, zlib did change its ABI. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] GDL chokes on semaphore (GraphicsMagick)
On Fri, 27 Jan 2023, Udo Grabowski (IMK) wrote: pkg:/scientific/gdl@0.9.7-2020.0.1.4 (OI hipster illumos-aa33dce46b and older) for user and root: /usr/bin/gdl stops on assertion test in GraphicsMagick (semaphore.c): With almost 100% certainty this is because the dependent program has not invoked InitializeMagick() before using other GraphicsMagick APIs. It is acceptable to invoke this function any number of times and InitializeMagick(NULL) is OK for dynamically linked programs. A very long time ago (since 1.3.8 in 2010) GraphicsMagick initialization was changed to require InitializeMagick() to be invoked first. Before it was just recommended. OpenIndiana recently stepped forward from using a very old version of GraphicsMagick, so that may be what provoked this issue. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Gimp and G++10 issue
On Fri, 20 Jan 2023, Carsten Grzemba via oi-dev wrote: If libc.so.1 the only involved C code shared object, would that mean that libc has to build with gcc10 and option -fexceptions? That would depend on who is calling who. Normally the C/C++ run-time arranges to call a main() routine which is not part of libc. If a shared library is involved then shared library initializer functions may be called and I am not sure what code is responsible for that. If the C++ code has static objects then the C++ run-time needs to assure that those are constructed before main() is called. Regardless, GraphicsMagick has a test in its C++ component (Magick++) because this failure to catch exceptions used to be a common problem. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Gimp and G++10 issue
On Fri, 20 Jan 2023, Carsten Grzemba via oi-dev wrote: and compile the test source with g++ 7 it works: ./jens Caught error No namespace info available for XMP prefix `gnome' http://www.gnome.org/xmp/ and if I compile the test source with g++ 10 it crashes: ./jens terminate called after throwing an instance of 'Exiv2::BasicError' what(): No namespace info available for XMP prefix `gnome' Abort (core dumped) Anyone how have an idea what the problem here? A problem like this seems most likely to be a mixup of C++ run-time libraries. If any C code is involved in the exception path, then GCC needs to have exceptions enabled while compiling the C code (-fexceptions), except that it may be that GCC for some systems has this option enabled by default. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] FLAG-DAY: We started to obsolete python 2.7 and 3.5
On Fri, 30 Sep 2022, s...@pandora.be wrote: For example in my Vagrantfile I have a comment about a missing 2.7 'futures' component: https://github.com/OpenIndiana/vagrantfiles/blob/main/oi-docs/Vagrantfile # there used to be a futures package in the repo ... # library/python/futures seems to have a problem now pfexec pkg install -v \ git lynx links\ library/python/futures \ library/python/mkdocs \ developer/documentation-tool/mdl # as of 21/9/2021 futures IPS is missing so install by pip pfexec pip install futures Because such "pip install" actions print a clear warning by Python that we are using an unsupported Python 2.7, it is clear that something must be done. The "futures" package is intended to allow Python 2.7 code to be "soft" ported to Python 3. It is a bridge to Python 3. As such, it is important for any Python code yet to be ported to Python 3, or might execute with either version. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Linker error while compiling a new QT creator
On Thu, 28 Apr 2022, Stephan Althaus wrote: Hello! I get an error, and i don't know how and where to search for a solution. I generally don't expect linking errors of this type. Please give me some hints where to start looking for... You should filter this output through 'c++filt' to see what the missing symbol names are. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] /usr/libexec/dovecot/anvil crashes immediately
On Sat, 12 Feb 2022, Stephan Althaus wrote: In the snipplet that Mr Al Slater communicated, it looks like there are linux-specific epoll details that are not working with illumos. Apples and apples can be different :-) This is quite possible. I should mention that I am running Dovecot in a zone. I am not quite sure if I am actually using chroot. Have a nice day ! P.S. After several weeks of cloudy misty weather the sun is back again here in Germany. Welcome!! Nice to hear. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] /usr/libexec/dovecot/anvil crashes immediately
On Sat, 12 Feb 2022, s...@pandora.be wrote: I don't know what the issue or problem with "dovecot" is, but regarding Illumos/OpenIndiana epoll support, epoll(5) in OpenIndiana/Illumos seems to work. The problem appeared to be related to being used in conjunction with chroot(). Have you tried that? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] /usr/libexec/dovecot/anvil crashes immediately
On Thu, 10 Feb 2022, Stephan Althaus wrote: o support your investigation, I tried mdb and it says mdb: target performed exec of /usr/libexec/dovecot/anvil *Panic: epoll_ctl(add, 4) failed: Not owner (fd doesn't support epoll)* The last time I built dovecot under OmniOS (quite some time ago), it picked up Linux compatibility functions such as epoll() which were implemented for Linux system call emulation but did not work in dovecot. So the solution was to force using the more native poll(2) instead. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] upstreaming our libtool search_path patch
On Wed, 24 Nov 2021, Tim Mooney via oi-dev wrote: Any objection to pointing the maintainer at the solaris-userland patch and letting them know that that patch is beneficial for both commercial Solaris and for OpenIndiana? I would like to get one of the patches into upstream, and it seems easiest to vote for the solaris-userland one as acceptable to both OSes. A possible complexity is that contributions to libtool which are more than a few lines (non-trivial) need to have signed copyright-assignment paperwork with the FSF. This is because the FSF is the copyright holder for libtool. Due to this, it may be necessary to find the original author and get them to go through the paperwork process (if they have not), or have someone (who already has done the paperwork) write a similar patch. If the original author is "Oracle" then Oracle can assure that the paperwork is in place and submit the patch. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] crypto/ca-certificates
On Fri, 29 Oct 2021, s...@pandora.be wrote: The next release of OpenSSL 1.0.2 (1.0.2zb - available to premium support customers only) will make it possible to build the release with added -DOPENSSL_TRUSTED_FIRST_DEFAULT on the build configuration command line. That will make the -trusted_first option enabled by default by the OpenSSL library. So an upgrade of OpenIndiana openssl 1.0.2 to 1.0.2zb if that is possible could be another approach. Does OpenIndiana have "premium support"? How could it be possible for an open source system to offer closed "premium support" sources? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] valgrind and epoll(5) illumos issue
On Sun, 11 Apr 2021, s...@pandora.be wrote: However does OpenIndiana really have to ship /usr/include/sys/epoll.h ? The sys/epoll.h header file could be split from SUNWcs package, and provided in an optional header file package for epoll compatibility. There are some implications to shipping the header file sys/epoll.h by default. Some software may require epoll. Epoll seems to be more efficient than other Linux API alternatives given many open file descriptors. It is unfortunate that some software will enable use of a feature because its configure script detects that it exists. Usually it is possible to force that a feature will not be used (e.g. by providing a cache value which says it is not available) when running a configure script. The only real solution is to make sure that applications are using the most appropriate APIs under Illumos given their actual requirements. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] valgrind and epoll(5) illumos issue
On Sat, 10 Apr 2021, Andreas Wacknitz wrote: If almost nobody cares for packages on OI enough to update them then sooner or later OI will be dead. Eg. you state on your signature that you are a graphicsmagic maintainer, yet our graphicsmagic version is 1.3.26 while the latest is 1.3.36 according to https://repology.org/project/graphicsmagick/versions That is strange. Why is it so old? A huge raft of security fixes went in after 1.3.26. The level of effort to update should be as simple as changing 26 to 36 in whatever files reference it, and rebuilding, and publishing. Obviously that does take time and work. Some sort of script to automatically update release versions based on upstream releases would surely be helpful. The software is still upward binary compatible with previous releases. Obviously, not all software is so sensible. I don't build the many packages listed at repology.org. As clarification, I am effectively the only maintainer for GraphicsMagick since the last contribution by someone else was in 2018 (which actually resulted in massive work on my part). Meanwhile I have a demanding unrelated full-time job and work on GraphicsMagick (for free) in my spare time. During my time continually contributing to the code base (since 1995 or 1996) it has primarily been edited on SunOS-based systems and currently I am using OpenIndiana for my desktop. Releases are currently cut using a OmniOSce zone fortified with OpenBSD Pkgsrc packages. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] valgrind and epoll(5) illumos issue
On Sat, 10 Apr 2021, s...@pandora.be wrote: valgrind seems to work on the squeak VM runtime (which was a surprise to me, since the squeak VM runtime is not exactly simple). It's a nice tool - and a good/excellent package in the OI repository. Probably the valgrind I have on my machine is out of date. It identifies itself as version 3.15.0 and the timestamp on the executable is April 20, 2020. It does not work at all for testing GraphicsMagick and ends in a core dump. It would be good to have Clang or GCC ASAN working as well. One of the main reasons why I continually turn to a Linux system is a working valgrind and ASAN/UBSAN. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] valgrind and epoll(5) illumos issue
On Sat, 10 Apr 2021, s...@pandora.be wrote:
int
epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
{
dvpoll_epollfd_t epoll[2];
res = write(epfd, epoll, sizeof (epoll[0]) * (i + 1));
I am not sure but valgrind may be complaining about passing epoll argument to
write().
Perhaps this could be patched at the OpenIndiana level,
but ideally the Illumos contributors could contact valgrind.org to patch
valgrind,
and/or the illumos sources (if required).
Also that would fix the issue for all Illumos based distributions, not just for
OpenIndiana,
provided OpenIndiana would then incorporate/update its valgrind package.
It is nice to hear that valgrind is working at all. It is necessarily
for a knowledgeable volunteer to study the interface between the C
library and the kernel and write the valgrind extension code to handle
it. It is unlikely that the primary Valgrind developers care to
support Illumos directly but they will accept good patches. People
interested in Illumos need to do the work and take care of themselves.
In the mean time, you could configure the program not to use epoll and
valgrind could be useful for the rest of the program.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Could I reuse the Linux crt headers for OpenIndiana?
On Thu, 25 Mar 2021, cretin1997 via oi-dev wrote: The current crt headers of FreeBASIC is exclusively based on Linux: https://github.com/freebasic/fbc/tree/master/inc/crt In order to build GTK based FreeBASIC application, one has to have a working crt headers set, too. There is no such thing for OpenIndiana. I and other FreeBASIC users decided to just copy the Linux crt headers and modify them to use with OpenIndiana. The result is we could build the application successfully but unfortunately this application can't run. I think there could be two potential problems: First, it could be my removing of --export-dynamic caused the FreeBASIC compiler to generate a not working shared library. This seems like the most unlikely cause. :-) Second, it could be the Linux crt headers are incompatible with OpenIndiana, the C standard functions are the same but the platform specific details (#define bla bla) are different, so the application could be compiled, but it used the wrong details so it can't run. This is exceedingly likely. Although Linux is originally modelled on SunOS (a clone of Unix), it did not directly copy it. The GNU libc (much of what you call a "CRT") is independent of Linux, so it also makes its own decisions. From looking at the translated ".bi" files (e.g. https://github.com/freebasic/fbc/blob/master/inc/crt/io.bi), there are many arbitrary constant values which were translated from system headers. An API may be the "same" (be compliant to a standard) even if the integer values representing it are different. At the top of the referenced header I see "io -- header translated with help of SWIG FB wrapper". It seems that the methodology used to create this files needs to be replicated in order to produce similar files for Illumos. Please note that the application could be launched, but it just sit there idle and doesn't print any output on the terminal. I have to use Ctrl+C to cancel it. This is not surprising. What means "start" in Linux may very well mean "stop" in Illumos. It does not appear that the git structure of the FreeBASIC files is designed to support porting since it does not even mention that these files are translations of Linux/glibc header content. Python does similar things, but it is designed for porting. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fw: Re: What is the equivalent for GNU ld's --export-dynamic?
On Thu, 25 Mar 2021, cretin1997 via oi-dev wrote: How did I test the library? The VisualFBEditor IDE was based on MyFbFramework from the same author. I compile MyFbFramework into a shared library and VisualFBEditor will load this library on startup. The library will be loaded dynamically, it was not linked with the binary VisualFBEditor_gtk3 itself. This is the reason why now I think it's more likely the side effect when I removed --export-dynamic more than the Linux crt headers being incompatible with OpenIndiana. It seems that you are making mere assumptions here. Surely it is not difficult to find the actual cause? Properly written software will self-diagnose if something as simple as failing to resolve a symbol occurs. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What is the equivalent for GNU ld's --export-dynamic?
On Wed, 24 Mar 2021, cretin1997 via oi-dev wrote: I know the Solaris linker is what caused all of the trouble. FreeBASIC expects a GNU linker. This time is the same. The Solaris ld doesn't support --export-dynamic. The Solaris linker has not caused a problem. It seems like the Linux linker has caused the problem! :-) I suggest trying without the option. If there is some problem later with resolving symbols while actually running the program, then return to the issue. If one looks at the Linux dlopen(3) manual page, there is a RTLD_GLOBAL option. Apparently this used to be the Linux default, then but then RTLD_LOCAL became the default due to security concerns. It is my experience that Illumos will still behave as described for RTLD_GLOBAL: "The symbols defined by this shared object will be made available for symbol resolution of subsequently loaded shared objects." Put this shit aside, what I do is I just removed the problematic option. FreeBASIC does turn on it option for Linux. I don't know what it does, nor I wanted to know, I only wanted to know the equivalent option for the Solaris linker. If no such equivalent option available, does the shared library produced by FreeBASIC with --export-dynamic removed work? What is the side effect if without --export-dynamic? This is the only thing I wanted to know! The one most qualified to answer such question should be the FreeBASIC developers, but, as you already known... do it yourself and you could submit the code to us! Since you are porting the code, you will soon learn if it works. Trial and error is a valid approach. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Tasks to focus on
On Sun, 24 Jan 2021, Gary Mills wrote: First, though, there has to be demand for the software product. I, myself, have no interest in Tex. In fact, I don't even know what Tex is, except that it's used by mathematicians. I'm not one of those. I have some doubts about the demand. While I did buy a couple of books on TeX a long time ago (and even wrote a resume in it once) it did not catch on for me. However, I have learned that TeX is a wonderful typesetting/publishing system (with fonts!) which can be taken advantage of by other software. This means that if you want to produce a PDF, or Postscript for a printer, may be useful to have TeX available. For example, I have written documentation using the reStucturedText text format, and used reStucturedText tools which themselves used TeX under the covers to produce nice PDF output. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Plan for openssl update
On Thu, 14 Jan 2021, Chris wrote: However do you see any package that we could happily deprecate in the process? ;) I'm not sure what IO's policy is. But, given python2x went EOL upstream. You could eliminate python/python27 from the list. Which, given all the packages that _depend_ on it, would make the list even smaller. ;-) Regardless of Python 2x going EOL upstream, there is a remarkable amount of Python 2 code continuing to be used in the world. People did not necessarily rush to convert their software so that it would work with Python 3 even if they had heard repeated mentions that they should do so. In somecases the port forward to Python 3 is easy and in other cases it is a nightmare. The '2to3' helper tool only goes so far. Problems often remain and can only be discovered by exercising every code path. OpenIndiana should not be the first to remove Python 2x entirely. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Shipping the nano editor alongside with vi
On Tue, 12 Jan 2021, Jim Klimov wrote: Bob, FWIW I think you can generally copy-paste in terminals with mouse if you hold SHIFT while click-dragging to select the text. Usually the problem I encounter is with a paste over a ssh login. The source system has either already been dealt with or I am not using vim on the source system. I don't think that vim is going to detect SHIFT if used over a ssh login. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Shipping the nano editor alongside with vi
On Mon, 11 Jan 2021, Chris wrote: While vim(1) is my "goto" editor, and vi(1) really isn't difficult. My frustration comes in the fact that each OS implements a different version, with different keyboard macros. Which quickly made ee(1) my goto when I was working in a "constrained" env (like dropping to single-user), and just needed to make some simple edit(s). BTW I'm the maintainer for ee(1) on FreeBSD. ;-) I have not tried 'ee'. The biggest gripe I have with 'vim' is that it is way too fancy by default. For example, I often copy and paste using the mouse (especially for system administration purposes) but 'vim' detects a mouse and prevents simple copy and paste of text from one window to another. The wiz-bang features can be disabled but this is problematic when one is configuring a new system. It is necessary to fix the editor configuration (perhaps using cat to a file rather than an editor) before the editor is usable. Other problems I have is with editors (e.g. vim) and commands which "colorize" everything. There seems to be an implicit assumption regarding the background color (maybe black?). But I have already set my default background color to a light background which is pleasing for my old eyes and then I can barely make out the text on the screen. It would be good if fresh systems would default to fewer quirky wiz-bang features yet allow them to easily be enabled for a Linux-like experience. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] How many CPUs does OI support?
On Fri, 8 Jan 2021, Chris wrote: TBH the only reason I brought it up was that we had a similar question on one of the FreeBSD lists. Where they had difficulty exceeding 96 on a 128. I've forgotten whether it turned out to be config of (actual) limitation. Mind you that was BSD. But given the shared heritage, it seemed an appropriate question. A shared heritage of SunOS BSD-derived code ported into a System V base (and first released to the world as 'Solaris' in 1992) does not seem very applicable after so many years. Sun did massive work to be able to scale on large systems. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Praise for Firefox
On Tue, 4 Aug 2020, Gary Mills wrote: I'm very pleased with Firefox. It's version 60.9.0esr (64-bit). I assume that's newer than the 2018 version. In any case, it's certainly faster on some web pages than the old version. Everything seems to work as I expected. So far, I have no complaints. Firefox itself works pretty good now, but it is still not new enough to produce results from a web site which is very important to me for the past couple of years. This page does not show any results in its issues list. A few weeks ago they had an 'old-ui' link which produced pages which did work but they decided to remove it: https://bugs.chromium.org/p/oss-fuzz/issues/list Naturally, this web site is originally about bugs in Chrome. They are very hostile about older browsers. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenSSL-1.0.2 deprecated
On Fri, 10 Jan 2020, Andreas Wacknitz wrote: According to https://www.openssl.org/policies/releasestrat.html LTS for OpenSSL 1.0.2 ended 31/12/2019. Do we need work on Version 1.1.1? It will be supported until 2023-09-11 (LTS). Updating should be done, but expect that it will be rather painful. The updated version has deprecated and removed interfaces which were often used before. For example, previously code would instantiate a structure (e.g. on the stack, or using malloc()), initialize it, and use it directly, but now the interface structure definitions are opaque (only forward declared) and one must use constructor/destructor functions provided by OpenSSL. Luckily, other interfaces appear to be mostly unchanged. Updating OpenSSL will likely require updating dependent applications to versions which are new enough to already be ported to 1.1.1. The alternative is to port older applications to work with 1.1.1. Porting applications is not hard, but it is tedious. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Would OI be interested in Pale Moon?
On Wed, 11 Dec 2019, Matt A. Tobin wrote: So here we are, I am writing to all of you because someone I have come to know and who worked very hard to bring his chosen software to his chosen OS for all to use and enjoy has been crushed. What does this say about the Open Source community and more importantly about people in general these days? I have no idea what correspondence occured outside of this list, but absolutely none of what you said in this email has been mentioned before on this list as far as I can see. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Would OI be interested in Pale Moon?
On Wed, 11 Dec 2019, Volker A. Brandt wrote: Till Wegmüller writes: I concur. Some politeness goes a long way. This problem with the license requirements however stems from firefox originally. Only that in firefox'es case they fought with the debian community and lost. It seems like the Palemoon community needs to have the same experience. Sadly To me, the problem looks slightly different: The Pale Moon devs insist on having private copies of a huge number of libraries in their source tree. If a distro changes that to use the system version of those libs instead, the PM people consider that a license violation. IIRC the original Debian ./. Firefox dispute was about logos and icons. I don't see a statement about that in the extensive license text. It is clear that any modifications to executable and logo content provided by Pale Moon are not allowed. I don't think that this means that code independently compiled under the Mozilla license is not allowed to be modified and distributed. Indeed, it must be modified to use alternate branding and logos. It is understandable that OpenBSD does not want apps to be using separate non-audited and possibly outdated copies of system libraries. The arrogant and high-handed way in which the PM people phrased their demands were no help either. They have not realized that they are driving users away, a very stupid thing to do. Not sure if Jeremy should continue calling his build "Pale Moon". Maybe "New Moon" would be better, just to avoid sudden abuse coming from the PM people over some build flag. Obviously, every trace of Pale Moon and standard logos, as well as HTML style sheets are required to be changed. The name of the distribution package can not include the phrase "Pale Moon". To me, it seems like the many requirements are rather onerous and it is thus not surprising that this software is not going anywhere fast even though it does appear to offer the experience that people used to enjoy from the original Mozilla (and later Mozilla SeaMonkey after FireFox emerged). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Nginx missing IPv6 Configuration
On Tue, 15 Oct 2019, Tim Mooney wrote: Also, pkg.openindiana.org doesn't currently have an advertised IPv6 address. Did it have one earlier when you were testing? Otherwise, I don't understand how your examples could even be using IPv6. The IPv4 space is subordinate to the IPv6 space. In other words, there is a mapping of IPv4 addresses into IPv6 addresses. This makes some IPv6 addresses more equal than others. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] LD_LIBRARY_PATH and Runpath issues.
On Sat, 12 Oct 2019, Jeremy Andrews wrote: I can get it to find the dist/bin libraries by hardcoding that path, but ideally I'd want to use something like $ORIGIN so the program doesn't have to rely on a hardcoded install path. I can't seem to get that flag working. I just want the binary to search the directory it's currently located in for libraries. I've tried -Wl,-R,\$$ORIGIN and -Wl,-R,\$ORIGIN, and neither one seems to work. When I run elfdump, I see that it keeps mangling the $ORIGIN flag in various ways... giving me RIGIN with the O cut off, or a string of numbers before ORIGIN, etc. Maybe a linker script would work better? It seems like layers of shell script must be trashing this option. And it is being exceptionally stubborn about GCC libraries. It simply won't look for them in /usr/bin/gcc/7/lib/amd64 even if that path is hardcoded in, requiring an LD_LIBRARY_PATH as an override. I'm using GCC 7 because the application apparently doesn't support GCC 6, and the system seemingly just won't have it without an explicit override. This seems like a strange path (under /usr/bin) to compiler run-time libraries. Hard coding paths to compiler-specific libraries may be avoided by using 'crle' to set system-wide search paths. This way, if the compiler run-time library is installed somewhere else on a somewhat different system, it may be found due to this local configuration. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Clang and GCC6 runtime
On Wed, 31 Jul 2019, Alexander Pyhalov via oi-dev wrote: No, -fopenmp seems to be implemented wrong. _REENTRANT is not defined, libgomp is not linked. If we specify "clang++ omp.cc -fopenmp=libgomp -o omp", application is linked, but pragma parallel uses just one thread. When -pthreads is used, _REENTRANT is undefined. -pthread seems to work as expected. There is an implementation of OpenMP for Clang which is independent of GOMP. Regardless of current shortcomings, it is exciting that Clang is coming as an alternative to GCC. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Clang and GCC6 runtime
On Wed, 31 Jul 2019, Alexander Pyhalov via oi-dev wrote: OK I have almost working Clang 8.0.1. Do the normal -pthreads and -fopenmp (OpenMP) options work with this build? I was excited when I found Clang 8 available from pkgsrc but was disappointed when I found that GCC options normally available from Solaris are not working. It may be that Clang is lacking customizations necessary to emulate GCC under Solaris-derived systems. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Openindiana on Laptop: touchpad not working
On Tue, 21 May 2019, Carsten Grzemba via oi-dev wrote: With newer releases I have the problem, that touchpad is not working anymore. You forgot to provide any useful information, such as what hardware you are using. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] build issue in percona-server-57
On Mon, 5 Nov 2018, Rich Reynolds wrote: [ 32%] Building CXX object sql/CMakeFiles/binlog.dir/binlog_crypt_data.cc.o /codebase/oi-userland/components/database/percona-server-57/percona-server-5.7.22-22/sql/binlog_crypt_data.cc: In member function 'void Binlog_crypt_data::free_key(uchar*&, std::size_t&)': /codebase/oi-userland/components/database/percona-server-57/percona-server-5.7.22-22/sql/binlog_crypt_data.cc:62:37: error: 'memset_s' was not declared in this scope memset_s(key, 512, 0, key_length); ^ make[3]: *** [sql/CMakeFiles/binlog.dir/build.make:336: sql/CMakeFiles/binlog.dir/binlog_crypt_data.cc.o] Error 1 this a patching, upstream or makefile issue? ill investigate if no one knows off the top of head This appears to be a C'11 function. See https://en.cppreference.com/w/c/string/byte/memset. Depending on C'11 at this time is very optimistic. What version of GCC are you using? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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, 31 Oct 2018, gon...@comcast.net wrote: It is hard to compare compression savings without specifying the data set used.The Silesia or Calgary corpus could be used as the reference set. Both the compressibility ratio and the compression performance is highly data content dependent. In this case the "corpus" is quite well defined, and in fact has already been enumerated in a prior email. The value obtained can be easily verified. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ 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, 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. Lzma type compression (e.g from xz, lzip, or 7z) will do better than zip for this purpose. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] prep failure in /oi-userland/components/developer/libtool
On Wed, 24 Oct 2018, Andreas Wacknitz wrote: diff configure.ac configure.ac.orig 27c27 < AC_PREREQ([2.63]) --- AC_PREREQ(2.62) Why did that used to work before? libtool-2.4.6 ist more than three years old. Do you want to create a PR for this? It looks like gnulib is being pulled from upstream using git and upstream gnulib is a moving target. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Please Zip compress the USB downloads from OI
On Fri, 10 Aug 2018, John Howard wrote: Yesterday I downloaded the minimal USB. I am in USA, not Europe or Asia, so I did not choose an alternative mirror for the download. Average speed was modem circa 1990 around 56 Kb/s. It took almost 3 hours. Okay, if that is how it is now. The problem is, out of curiousity, I compressed the downloaded minimal USB file 25% using Zip. Similar savings result for the 2 GiB Live USB down to 1.6 GiB. If the image is to be compressed, then it is likely that there is a popular compression algorithm (e.g. xz or 7zip) which is more effective than gzip. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] weird flock problem
On Mon, 13 Nov 2017, Carsten Grzemba wrote: This compiles on Openindiana without an error, but if it runs throws the error: Invalid argument (os error 22) If I copy this on Openindiana compiled code to Smartos it runs correctly. Are you using the same filesystem on both systems? For example, zfs vs tmp on swap could make a difference. Or something to do with filesystem paths. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] "Fixed Enlightenment" or "Beware of epoll"
On Tue, 11 Apr 2017, Joshua M. Clulow wrote: If there's real software that requires things we're not implementing, we may well need to fix the emulation layer. After all, it forms the foundation of epoll support in the LX brand as well. I learned the hard way that emulated epoll fails if the program subsequently does a chroot(). This causes troubles for some server software. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] illumos-gcc and mpc/mpfr/gmp
On Tue, 24 Jan 2017, Aurélien Larcher wrote: Hi, I am packaging GNU UPC right now for work and it requires mpc/mpfr/gmp. The issue at hand is that while we have packages for them, they are quite old and used by illumos-gcc. For each flavour of GCC in oi-userland we download and rebuild these libraries locally. Questions: - Should I compile locally these 3 libraries for GNU UPC? - Should illumos-gcc use its own version of these libraries? - Should we update our antiquated versions in oi-userland? Sharing is good unless it causes harm so the third option seems preferable. When I was building GCC myself under OpenIndiana for personal use, I believe that these libraries were shared by multiple GCC builds and I did not encounter a problem. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Sun SSH has gone
On Wed, 24 Aug 2016, Nikola M wrote: On 08/23/16 07:40 PM, Bob Friesenhahn wrote: On Tue, 23 Aug 2016, Nikola M wrote: Only problem I have seen very recently (under a month) is that it takes quite some time to log into other OI machine from laptop, after I started using that machine again as a router for wireless connection. For some reason, i get ssh prompt faster, if I firstly log into the console, but that could be for a number a reasons. Is it possible that ident protocol (to identify the user id on the machine doing the connecting) is being used? For some reason I somehow got some routing rules active form previous configuration, even after 'route flush'. Adding route for another ip subnet somehow made ti log in faster, even still slow, but within minute. This sounds like a network configuration problem and perhaps ICMP redirects are fixing the routing. I think those are defaults in OI, if I am right, where in /etc/ssh/sshd_config : IgnoreRhosts yes RhostsAuthentication no , RSAAuthentication yes This is different than IDENT protocol. Another potential source of strange delays has been DNS reverse lookups, with the delay being temporarily cured by caching the negative result. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Sun SSH has gone
On Tue, 23 Aug 2016, Nikola M wrote: Only problem I have seen very recently (under a month) is that it takes quite some time to log into other OI machine from laptop, after I started using that machine again as a router for wireless connection. For some reason, i get ssh prompt faster, if I firstly log into the console, but that could be for a number a reasons. Is it possible that ident protocol (to identify the user id on the machine doing the connecting) is being used? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenIndiana Code of Conduct
On Thu, 21 Jul 2016, Nikola M wrote: You can change it further, but the whole point is you can't know what you want if you don't even look at things that are wrong with the current one. It is regarding whole section for "retributals"/tirany-inspired/not tolerable unprecise part. I see no problems with lack of precision as long as there are trusted people (sufficiently empowered) identified in advance who communicate amongst themselves when there is a claimed problem and come to a decision based on the facts at hand. This small group of selected people then act like a judicial panel. It is impossible to foresee every circumstance. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OpenIndiana Code of Conduct
On Mon, 18 Jul 2016, Adam Števko wrote: Hello, As part of a larger effort at providing a more formal governance structure for the OpenIndiana project, 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/ <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. This looks really good to me except that there needs to be some definition of 'We' somewhere (perhaps elsewhere on the site) as well as some identification of who will decide what is not tolerated and who will enact enforcement actions. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] first steps at compiling libvirt
On Sat, 21 May 2016, Denys Rtveliashvili wrote: The linking command looks OKish to me. The only thing I managed to find about _fini and _init is that they are related to initialisation and shutting down of shared libraries. Also, -nostdlib option seems to "fix" the problem but I am not sure if it is what really should be done. And I have never seen this on Linux. Does the linking problem go away if you remove the '-Wl,now'? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] gcc 5.3 testing
On Fri, 13 May 2016, Alexander Pyhalov wrote: On 05/11/2016 22:22, Alexander Pyhalov wrote: Hi. I'm trying to build several components in oi-userland with gcc 5.3 to find out which ones need fixing. One more issue we have to discuss... Updating gcc to 5.3 significantly breaks C++ ABI - https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html. As I understand, this means, C++ libraries should be recompiled to be used with new code. What are we going to do with this? Mass recompilation and message to the users "hey, we've broken ABI again..."? Do I understand this correctly? The way I read this, the old ABI is still supported by the 5.1+ library, GCC defaults to use the new ABI, but can be requested (or configured/hacked) to use the old ABI. I also read that both ABIs can be supported simultaneously at the module level. This assumes that ABIs can interoperate and it assumes that C++ code already built with an older GCC will continue to work without re-compilation with code compiled by GCC 5.1+. If GCC 5.1+ is told to use the old ABI, it seems doubtful that C++ programs built with the new GCC will run with the standard C++ libraries supplied by earlier GCCs. OmniOS has already introduced GCC 5.1 starting with r151016. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] demonstration docs website
On Mon, 2 May 2016, Nikola M wrote: On 05/ 2/16 08:56 AM, Alan Coopersmith wrote: On 05/ 1/16 10:48 PM, Nikola M wrote: *You aether accept open documentation license including Contributor agreement to OI or you contribute your time at somewhere else.* Why don't you let the people who run the project decide whether or not to accept contributions before you chase everyone away? There is no one who "runs the project" except us all, here and now, together. Everyone is free to contribute in all possible ways he seems fit. Support proprietary projects is not very high on my list. You made a lot of good points but in total it felt hostile. It seems like you are saying that if perfection is not possible, then the work is not worth doing. It seems most important that the license for the documentation (regardless of where it is initially developed) is suitable for other uses in OpenIndiana and that it can be incorporated in OpenIndiana documentation (or cut/pasted as part of blogs) as maintainers/athors see fit. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [OpenIndiana-discuss] Updated OpenIndiana FAQ
On Sun, 31 Jan 2016, Michael Kruger wrote: Both OpenIndiana and BSD are true unix operating systems, whose roots trace back to the original AT Unix. Linux in contrast, was created from scratch to provide a free and open source alternative to Minix, which at the time, was licensed for educational uses only. The Linux origin as relates to Minix seems completely irrelevant now. Linux was clearly inspired/guided more by SunOS in its development than it was by Minix. Minix was merely the OS that Linus was playing with prior to starting Linux. The fact that Linux started from scratch is important. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Security update: Update to LibreOffice 4.4.7
On Fri, 25 Dec 2015, Nikola M wrote: Also, information about CVEs that are not released yet does not requre to be public before package maintainer fixes it. That is what I think understand thus far, am I right? This depends on who reports and manages it. To get advance notice of CVEs then one must agree to the terms of whomever is proving the advance notice. For a "zero-day" type exploit which can be expected to exploited immediately (but are not publically known), it is common for fixes to be intentionally held back so that they are released to all operating systems on the same day. Many/most CVS are assigned for issues which are already publically known. Many security issues are found and fixed without any formal security report. For example, the application developer might find that reading a particular file causes the application to core dump. So they fix the bug and move on. If someone else had noticed the problem, it may have been formally reported, with an assigned CVE id. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libjpeg6 & libjpeg-turbo & VLC
On Sat, 12 Dec 2015, Aurélien Larcher wrote: Do I understand correctly that after integration of these change we still ship libjpeg6 as default and libjpeg-turbo in alternative paths? As it is yes, that's why I wanted feedback. The manifest components/libjpeg6-ijg/libjpeg6.p5m delivers symlinks to libjpeg6-ijg so as to provide the same path (/usr/lib) as before. So all are installed in alternated directories but IJG 6b is the only visible in /usr/lib. That said, we can then migrate slowly components to use libjpeg-turbo with version 8 support by altering the CFLAGS like I did with VLC. We can have shared macros to provide the relevant C*FLAGS. Also the symlinks to provide backward compatibility to IJG 6b could be listed under a legacy SUNWjpg package in libjpeg6.p5m. What do you think ? This sounds like a reasonable plan to me. I am not aware of build/packaging consequences though. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libjpeg-turbo and VLC
On Fri, 11 Dec 2015, benta...@chez.com wrote: Hi Aurélien, This is great news. I tried myself and my results are way less optimistic than yours. How did you compiled the libraries necessary for VLC ? After installing all I could from repo, I'm still left to compile the following : a52 bluray caca chromaprint dca dvbpsi dvdcss dvdnav dvdread faad2 \ ffmpeg fluid gme goom gsm jpeg kate \ lame libmpeg2 live555 mad matroska modplug mpcdec nettle \ postproc shout sidplay2 taglib twolame upnp vncserver vpx x264 x265 zvbi I know I can live without the blueray support even if it would be nice to have but DVD/x264 seem to me quite important. It seems easiest to find a way to compile applications with both JPEG 6b and libjpeg turbo. The main problem is if an application tries to load both libraries due to intertwined library dependencies. Debian used versioned library symbols (directly supported by libjpeg under Linux and FreeBSD) and a slow transition to allow migrating to the JPEG v8 ABI. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libjpeg-turbo and VLC
On Wed, 2 Dec 2015, Aurélien Larcher wrote: Hi, ABI 6b, 7 and 8 are apparently backward compatible but not 9. The ABI for 6b, 7, 8, and 9 are all different. There is a way to compile libjpeg-turbo to provide either a 6b or 8 ABI. I don't think it actually offers any more features when built to emulate IJG JPEG 8 since it does not provide the additional features added by IJG JPEG 8 (only interface structures are changed). So should I start by adding a libjpeg-turbo component and add possibly a symlinks like libjpeg.so.8.0.0 and libjpeg8.so (could do that to tell which lib to use given an ABI) ? It should be possible for the existing libjpeg and libjpeg8.so to co-exist, but only one can be used for development. Please note that the results from IJG JPEG and libjpeg-turbo are not always identical and libjpeg-turbo has had some issues with edge-cases (e.g. small accesses outside of initialized or even allocated memory) in the past, and possibly the present. As a result, I can't use libjpeg-turbo when doing memory testing (valgrind or ASAN) under Linux for GraphicsMagick tests since these tests exercise edge cases. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Security awareness: Update to Firefox 38.2.1 ESR or greater
On Sat, 24 Oct 2015, Nikola M wrote: I tested it on OI Hipster 201510, BE date 2015-10-19 and found it doesn't recognize my saved usernames/passwords I have in 24.8.1 (And of course, I can't live without my saved passwords :) ) I notice that with the Solaris 10 build, I also get an empty list when I visit the Saved Passwords section. However, I also notice that it still manages to auto-login using the saved user name and password so this may be a UI issue rather than an actual inability to replay login information. The CNN web site looks even more crappy than before and the Yahoo web site assumes that Firefox under Solaris must be some primitive cell phone browser (as it temporarily did with Linux some time ago). However, other web sites seem fine. Given that the Flash plugin is gone, web sites may look better with the Flash Block add-on removed. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Openindiana hipster source code on OI servers to fulfill licensing requirements.
On Wed, 14 Oct 2015, Nikola M wrote: It is a good question weither Oi got to have it's own source code repositories to match every Oi hipster 'snapshot' release. it does because source code distribution must be provided together with binary distribution, per licensing requirements of free software. I don't recall seeing a definition for how source code must be distributed in any free software license. If the server is open for all and the source is properly managed (e.g. clear release notes and repository tags and or branches), is that necessarily inferior to tarballs provided by ftp or http? There does need to be a precise way to obtain the exact sources used to build any binary release and it should be documented. Regardless, directories of tarballs seem best since they are easiest to copy and therefore less likely to be lost. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] LibreOffice: libmspub, libwps
On Thu, 30 Jul 2015, Aurélien Larcher wrote: Hi Bob, What would be your opinion about bumping ImageMagick in oi-userland at the same time ? LCMS2 cflags are not passed properly with 6.8.3 it seems. I don't have any opinion regarding the best version of ImageMagick. It competes against my own project. :-) It is wise to execute its test suite and make sure that it seems to be working. I have encountered versions which exhibit huge problems on Solaris type systems. Is there a preferred version and incompatiblities to be expected or it is just about pushing 6.9.1 (and making sure nothing breaks) ? ImageMagick is continually in flux so it is best to try to stick with similar versions as popular Linux distributions in order to improve compatability with applications using it, and access to any security patches which are posted. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] LibreOffice: libmspub, libwps
On Wed, 29 Jul 2015, Alexander Pyhalov wrote: Hi. Aurelian, do I understand correctly that lcms and lcms2 can co-exist? They are able to co-exist. Due to the continuing progress of the technology, API improvements of lcms2, and likely security issues, lcms1 should be ditched as soon as possible. All Linux and *BSD OS distributions have ditched lcms1 over the past two years. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] LibreOffice: libmspub, libwps
On Wed, 29 Jul 2015, Aurélien Larcher wrote: Hi, these 2 libraries are in the pipe. I also tried to compile libcdr but it requires lcms2 to be added first, if there is any interest. Lcms2 is an easy compile and useful for color management. There is a spec file for it. See SFElcms2-gnu.spec. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] ImageMagick *.pc issue
On Sat, 25 Jul 2015, Aurélien Larcher wrote: -lMagick\+\+6-Q16 -lm -lMagickCore-6.Q16 -lgc -llcms -lpoppler -lpoppler-glib -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lcairo CXXLD inkscape ld: fatal: library -lMagick++6-Q16: not found ld: fatal: file processing errors. No output written to inkscape collect2: error: ld returned 1 exit status That is interesting. On my OpenIndiana oi_151a9 system, I do have a library named libMagick++-6.Q16.so. Even a more recent ImageMagick install (6.9.0-0) I did by hand at the end of last year does provide a libMagick++-* file. Bob (Magick++ author) -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Stats
On Sat, 13 Dec 2014, Alexander Pyhalov wrote: OI Hipster change log can be found here: http://wiki.openindiana.org/oi/oi_hipster I think that this looks impressive. The main issue (feature-wise) seems to be the loss of SFE binary packages, and that SFE packages are not yet ready for GCC (mostly a build-options problem). There has recently been some minor discussion of OI Hipster on the SFE development list. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SSD-based pools
On Mon, 29 Sep 2014, Andrew M. Hettinger wrote: Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote on 09/29/2014 05:57:26 PM: On Mon, 29 Sep 2014, Schweiss, Chip wrote: And in case anyone is wondering, no I don't care about the data on the scratch pool, its always transient and reproducible. Performance is the objective. ZFS will tell me if it is incorrect and I will know it needs regenerated. How would ZFS know if the data stored is incorrect from the user's perspective? Presumably because the checksum is wrong. If by turning off 'sync' it is meant that the zil is disabled, then that has nothing to do with zfs checksums being wrong. If drive cache flush is disabled for async transaction groups, then nothing but problems can result (e.g. failure to import the pool at all). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] SSD-based pools
On Mon, 29 Sep 2014, Schweiss, Chip wrote: And in case anyone is wondering, no I don't care about the data on the scratch pool, its always transient and reproducible. Performance is the objective. ZFS will tell me if it is incorrect and I will know it needs regenerated. How would ZFS know if the data stored is incorrect from the user's perspective? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On Sun, 7 Sep 2014, Peter Firmstone wrote: Hi, It appears your developer has reached the point where he must quit to get his point accross. As best I can tell (based only on mailing list postings), Milan's main concerns were the marginal support for multimedia in the OpenIndiana desktop, and packages dissappearing from Illumos (e.g. OpenSSL) or being significantly altered (e.g. 'man') which then necessitate creating/rebuilding more base OpenIndiana packages, which ripple through the package dependency chain. The lack of a working Adobe Flash player in Firefox on OpenIndiana is surely a major part of the multimedia issue. Illumos doesn't have any stable releases and it sounds like developers are having issues with that. The lack of stable Illumos releases really does not seem like a big deal. In fact, most of the stresses on the OpenIndiana project seem like they are caused by other factors. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On Wed, 12 Feb 2014, Alasdair Lumsden wrote: There is no community. Only self centered individuals who think their way is best. Fragmentation was inevitable. I stated very clearly that I thought fragmentation would kill illumos. I still feel that today - fragmentation is killing illumos. Instead of one strong OS, we have a dozen fringe ones. I think that you must be biased due to your background. I am on almost all the mailing lists (including Illumos) and I do see plenty of collaboration and contributions to Illumos. In fact, there is considerable recent activity and contributions from many parties. Illumos contributions seem to be rather well managed and tracked. Some fragmentation is a good thing because it proves that multiple parties can deal with the code base and allows people to explore their own ideas. TribbliX is an excellent example of that. There is a rather similar situation with Linux. There is (mostly) one Linux kernel and baseline environment but many different Linux distributions which construct different application frameworks on top. OpenIndiana is like a Linux distribution. Regardless, I don't see this discussion has anything to do with 16 Gbit FC support (a driver/enumeration issue) and I don't see how an opinion from someone who starts off like I haven't kept track how build 134 metamorphosed into build 151a9 today can have much merit when he then produces a long opinion on the very topic he claims he has not paid any attention to. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [OpenIndiana-discuss] Studio future in OI (Re: )
On Sun, 13 Oct 2013, Dave Koelmeyer wrote: state of OI in the recent past, pre-Hipster. With respect, the fact that you're getting upset about Flash player (!!) breaking - a near dead technology on a platform with a miniscule installed base - indicates to me The near dead technology is in fact quite widely used. Until HTML 5 support has been reliably available for several years, web sites will continue to depend on Flash. It costs money to develop new web sites. Sites catering the cell phones are the ones which will dump Flash first. Regardless, there are still many things more important than the Flash support. Assuring that basic desktop features work and that recent versions of popular applications work with the desktop is more important. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On Sun, 1 Sep 2013, ken mays wrote: Add more...or less... Was ksh93 ever updated to fix known bugs (e.g. 'rm -f' with no argument produes error) which were fixed in upstream? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Libtool 2.4.2 and several questions (nvidia, build process)
On Sat, 27 Jul 2013, Jim Klimov wrote: On 2013-07-27 22:27, Alexander Pyhalov wrote: 3) gmake clean fails on components/nvidia. Does someone have any idea why it needs this ( https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/nvidia/Makefile ): clean:: [ -d $(BUILD_DIR) ] rm -rf $(BUILD_DIR) Shouldn't this be transformed just to clean:: rm -rf $(BUILD_DIR) While IMHO this can be replaced, as long as rm on a missing target does not return an error, note that gmake interprets the Makefile The default shell in current 'dev' OpenIndiana does throw an error (when it should not). This problem occurs when 'rm' is reported as /usr/xpg4/bin/rm rather than /usr/gnu/bin/rm. The xpg4 version is emulated as a shell built-in (which is broken). The next release of Automake has been declared to require correct behavior so I hope that someone fixes this (updates the ksh93 shell) in 'dev' OpenIndiana. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] imagemagick
On Wed, 10 Jul 2013, Alexander Pyhalov wrote: Hello all again. Now I have (it seems) working imagemagick update : https://github.com/pyhalov/oi-userland/compare/imagemagick However, it can break a lot, because imagemagick library names, so numbers and so on changed. So it seems to integrate it we need to rebuild all dependent packages (including other gates, e.g. JDS). ImageMagick can be configured to use subsets of its dependencies. Someone should decide which dependencies are actually worth using and which can be mapped out without excessive loss of functionality. For example, a dependency on cairo pulls in quite a lot of other stuff. This means that any software which links with ImageMagick then becomes dependent on this other stuff. It would also mean that the ImageMagick binaries would not run without X11 client libraries and the other dependencies installed. Besides changes to library names, the ImageMagick APIs and ABI are not terribly stable. Care needs to be taken to avoid ripple effects which result in rebuilding the world. ImageMagick APIs have changed (even the name of the function to call to initialize the library) since the version in OpenSolaris so dependent apps/libraries may need to be patched to compile and work properly. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] hipster
On Thu, 30 May 2013, G B wrote: I apologize for not following the 'hipster' thread more closely, but is 'hipster' intended to be 151a8, meaning that doing a standard `pkg image-update` from the default publisher will never get bumped to 151a8 or future releases? I did try once to update with hipster and has error/warnings galore scroll past and then failed to update. Is that going to be fixed? I applaud the efforts of those working on it, but with OI already on life support, hurdles in the road like this will only frustrate users more and cause them to abandon it altogether. Maybe you should follow that thread more closely. After initial reports of failures now there are many reports of complete success. It is an on-going process. Otherwise, I am also curious to see if 'hipster' becomes the next formal 151a8 and perhaps leading to an official OI release. At first I thought there was hope with hipster, but then had those errors and have mostly decided at this point to use SmartOS for my web/mail servers. Although last night when I logged into 151a7 and did a little work I had a thought that perhaps I should just stay on OI because I like it, but then logged onto my SmartOS machine and wondered why should I keep using or wanting ot use OI? If all you need is web and mail, then almost any distribution will do. SmartOS and OI target completely different usage models (light/heavy), although OI can support most functionalities offered by SmartOS. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] hipster
On Thu, 30 May 2013, G B wrote: I don't know where you get that SmartOS is for light loads and OI is for heavy loads, but on OI I can run DB2 while I can't on SmartOS because of a SUNW error. I did not use the term 'loads'. By light vs heavy I am talking about the size of the OS install footprint. OmniOS also offers a smaller OS footprint. Bob _ From: Bob Friesenhahn bfrie...@simple.dallas.tx.us To: OpenIndiana Developer mailing list oi-dev@openindiana.org Sent: Thursday, May 30, 2013 8:33 AM Subject: Re: [oi-dev] hipster On Thu, 30 May 2013, G B wrote: I apologize for not following the 'hipster' thread more closely, but is 'hipster' intended to be 151a8, meaning that doing a standard `pkg image-update` from the default publisher will never get bumped to 151a8 or future releases? I did try once to update with hipster and has error/warnings galore scroll past and then failed to update. Is that going to be fixed? I applaud the efforts of those working on it, but with OI already on life support, hurdles in the road like this will only frustrate users more and cause them to abandon it altogether. Maybe you should follow that thread more closely. After initial reports of failures now there are many reports of complete success. It is an on-going process. Otherwise, I am also curious to see if 'hipster' becomes the next formal 151a8 and perhaps leading to an official OI release. At first I thought there was hope with hipster, but then had those errors and have mostly decided at this point to use SmartOS for my web/mail servers. Although last night when I logged into 151a7 and did a little work I had a thought that perhaps I should just stay on OI because I like it, but then logged onto my SmartOS machine and wondered why should I keep using or wanting ot use OI? If all you need is web and mail, then almost any distribution will do. SmartOS and OI target completely different usage models (light/heavy), although OI can support most functionalities offered by SmartOS. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On Sun, 12 May 2013, Garrett D'Amore wrote: 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. If 32-bit userland is no longer the default, then GCC should start producing 64-bit code by default. Currently GCC does not seem to support being compiled to produce 64-bit code by default (at least last I tried doing that). GNU libtool needs a small patch to compile 64-bit C++ code with working exceptions support. Probably quite a lot of Solaris-targeted user-space code has issues when compiled for 64-bit because it was not compiled that way before. The GCC that comes with 64-bit Linux systems produces 64-bit code by default, but is capable of compiling 32-bit code. The OpenIndiana/Illumos folks would need to work with the GCC folks to make sure that a GCC can be built which produces 64-bit by default. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On Thu, 9 May 2013, Peter Tribble wrote: 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)? The main differentiators appear to be the ability to log into a graphical multimedia desktop (similar to Linux) and the ability to install and execute most existing Solaris binaries. 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. The Tribblix approach is likely a good one. Start off with a good smaller core and then add more sophisticated features via packages. This requires a new distribution though. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI project reboot required
On Thu, 9 May 2013, Garrett D'Amore wrote: Upshot, *today* anyone who thinks there is a commercial future in illumos on the desktop is probably smoking something. There are a few people who would be willing to pay for it, but it needs more than a few dozen people willing to pay a couple hundred dollars (more often substantially less) to make this a viable and interesting (economically) venture. There is little commercial future in the desktop for Linux distributions as well yet almost all of them have a graphical desktop. Availability of a graphical desktop is seen as a requirement for common acceptance. Much/most of the graphical desktop development taking place for Linux does not seem to be done by the companies which popularly peddle it (e.g. Canonical has been more of a desktop packager except for its useless Unity). The argument about no commerical future is becoming worn out and tired since that (commercial purpose) is not why OpenIndiana/Illmos users want to log into a graphical desktop. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Compiler migration #2
On Sun, 27 Jan 2013, Luca De Pandis wrote: For practical purposes, the important thing is to get OI repos to build with *any* relatively recent free compiler (be it GCC or clang). From GCC website: 3.4.3 November 4, 2004 --- (~8 years and 9 months ago) It's not relatively recent. It's paleolithic, man. The only possible workarounds are build a recent gcc version yourself or use SFEgcc package, but the last option is not a viable alternative if your CPU is not SSE2-capable. SSE2 appeared with the Pentium 4 in 2001. It is not likely that OI users will be encountering CPUs which don't support SSE2. Besides that, in Illumos-list discussions I have heard mention that the Illumos kernel requires SSE2. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Compiler migration #2
On Sat, 26 Jan 2013, Peter Tribble wrote: Adam, I am continuing on completing studio - gcc compiler migration. As this is something, which will take a century to complete, I have come to a conclusion that I will directly update stuff and make sure it is buildable by gcc44. Just one question - why gcc44? In other words, why not jump straight to gcc 4.7? I agree that there is no (or should be no) technical reason to prefer 4.4.4 (4.4.0 was released on April 21, 2009) for user-space code outside of core Illumos. In fact, there is good reason to keep up with GCC major releases and use a similar GCC for building user-space code as popular stable Linux distributions use. This would ease porting of Linux applications which are typically developed/tested with the GCC provided with Linux. On open-source development lists, I am seeing considerable interest from developers to use the latest C and C++ standards which implies that the code they write will prefer compilers implementing those standards. The main concern is with C++ ABIs, which may require that libraries/applications depending on a particular C++ standard library and ABI be updated in a consistent way on a periodic basis (e.g. every two years). If there is actual instability (yet to be demonstrated), then this has consequences for independently packaged software. Illumos uses (patched) 4.4.4 because that is what there was available developer time to use and the kernel has special needs. GCC 4.4 does not produce code for modern CPUs whereas GCC is continually enhanced to be able to produce code which targets modern CPUs. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
On Wed, 5 Sep 2012, Joerg Schilling wrote: As a nice hint: The new Bourne Shell compiles and runs on Cygwin (thanks to no longer depending on sbrk(2)) and if you use it to interpret autoconf scripts, this is 3x faster than bash. This sounds great. How does its performance compare with 'dash'? Are the various issues described in the GNU Autoconf portability notes (http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Portable-Shell.html#Portable-Shell) avoided/fixed by this shell? SunOS's stagnant /bin/sh has been a continuing issue with POSIX shell script portability. As a result, Autoconf configure scripts typically elect to re-run themselves with bash (the World's Slowest Shell) on Solaris sytems. If this shell is indeed good enough for Autoconf configure scripts, then it would be good to submit an Autoconf patch so that future configure scripts know how to detect and use it. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Schily shell as /bin/sh
On Wed, 5 Sep 2012, Joerg Schilling wrote: Given the fact that GNU autoconf has been more or less destroyed after release 2.13, so I personally base my work on an extremely enhanced gnu autoconf 2.13. The timing tests I did run, have been run with my enhanced autoconf-2.13 It was temporarily destroyed but then it was undestroyed so things are ok again (while you were sleeping). However, work is required in order to catch up. Autoconf 2.13 works with all known shells - I have no idea why the FSF stopped to support this. I suspect that this is just a bash marketing action. The problem why newer GNU autoconf versions are so slow may be that they call a bew bash for each single test unless /bin/sh is bash - what you don't like to have on a POSIX compliant system. Try invoking like it like CONFIG_SHELL=/usr/bin/dash /usr/bin/dash ./configure If the starting shell and the official configure shell are the same, then it should avoid the paranoid behavior that you describe. This is totally off topic for this discussion thread. A new discussion thread should be started for the possibility of replacing /bin/sh with your Schily shell. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Desktop Illumos Still Matters
On Wed, 5 Sep 2012, Andrew Stormont wrote: The only thing you really need for extensions to build is the -I bit. The rest is Sun Studio pedantry. These sorts of scripts are just broken. What it really should do is check the value of CC before adding any compiler specific flags. Patching it to do that would be my preferred way of solving the problem. Things get complicated because it might not even be possible to combine code compiled by two different C compilers. Some compiler-specific options might be needed in order to obtain special compilation modes and secret library dependencies (especially for threads and OpenMP). There are also explicit library dependencies to get right. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
