Re: [oi-dev] clamav update
On 2022-01-11 10:02, Chris wrote: On 2022-01-11 09:16, Friedrich Kink via oi-dev wrote: Hi all, I prepared the clamav update to the latest version and everything works fine as expected. But one of out of all tests is failing with this error: 99%: Checks: 1175, Failures: 1, Errors: 0 /usr/src/oi-userland/components/sysutils/clamav/clamav-0.104.1/unit_tests/check_clamav.c:1707:F:assorted functions:test_cli_codepage_to_utf8_jis:0: test_cli_codepage_to_utf8: Failed to convert CODEPAGE_JAPANESE_SHIFT_JIS to UTF8: ret != SUCCESS! NOTICE: Use the 'T' environment variable to adjust testcase timeout Does anyone have experience Japanese code pages? Is this something which needs more detailed investigation? Just a hunch here; but don't Japanese characters use joiners to combine 2 utf8 symbols? IOW shouldn't that be uft16? Ahem... I meant utf16, not uft. Sorry. :-/ HTH -- Chris kind regards, Fritz ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX 0xBDE49540.asc Description: application/pgp-keys ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] clamav update
On 2022-01-11 09:16, Friedrich Kink via oi-dev wrote: Hi all, I prepared the clamav update to the latest version and everything works fine as expected. But one of out of all tests is failing with this error: 99%: Checks: 1175, Failures: 1, Errors: 0 /usr/src/oi-userland/components/sysutils/clamav/clamav-0.104.1/unit_tests/check_clamav.c:1707:F:assorted functions:test_cli_codepage_to_utf8_jis:0: test_cli_codepage_to_utf8: Failed to convert CODEPAGE_JAPANESE_SHIFT_JIS to UTF8: ret != SUCCESS! NOTICE: Use the 'T' environment variable to adjust testcase timeout Does anyone have experience Japanese code pages? Is this something which needs more detailed investigation? Just a hunch here; but don't Japanese characters use joiners to combine 2 utf8 symbols? IOW shouldn't that be uft16? HTH -- Chris kind regards, Fritz ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX 0xBDE49540.asc Description: application/pgp-keys ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] dlc-origin (rsync) EOL?
On 2021-07-30 09:05, Marcel Telka wrote: On Fri, Jul 30, 2021 at 12:02:13PM -0300, Till Wegmueller wrote: I assume better means it can detect create a diff faster? No, this is not about the speed (primarily). Just about the quality of data published via the protocol. For example, with rsync I can be sure that timestamps are okay, for example. With ftp it usually works too, but http is not so good and there is possibility that I might end up re-downloading the same content again and again just because http might fail to advertise mtime change (or no change, to be precise). I can't help but add, that rsync is far more efficient overall. As it is only interested in differences (as already mentioned). Which results in less bytes transferred on both sides. Are the OI servers paying for bytes transferred (have a cap/limit)? This will also leave more bandwidth available for all. OK I don't run or manage the OI servers. But couldn't help myself. ;-) --Chris Over the years I switched all my mirrors to rsync from initial ftp (or http) just because of this. I can see the point. I also think a fast diff for mirroring is nice. I'll Thanks. Please let me know once there is rsync back. have a look in the future to see to get that going. For now please switch to HTTP(S) Sure, will do. Thank you. -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX 0xBDE49540.asc Description: application/pgp-keys ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] I'd like to help out.
On 2021-05-28 10:05, James Madgwick wrote: On Fri, 28 May 2021 08:27:11 -0400 Austin Kim wrote: (Any doc contributions I could make will be few and far between due to time, but, maybe something > nothing?) Also, y’all’s thoughts about possibly setting up an “oi-doc” mailing list in the future for the OI documentation project? I'm not sure there's a need for a documentation list at the moment. I have suggested some meta improvements to the existing docs - fixing PDF generation (https://github.com/OpenIndiana/oi-docs/issues/181). Andreas said I should post on here so the community can have full sight of this proposal. So far I've had a look at how the documentation can be cleaned up to allow a useful conversion to PDF. This will require lots of small edits to replace any existing HTML markup with markdown (where this is possible). At the moment there's a few places where HTML has been used instead of markdown and this doesn't work with Pandoc (the program used to create PDF from markdown). Having taken a closer look what is involved, I'm happy to do the work I've suggested in the GitHub issue. Hopefully this will get the docs into a bit of a better state, ready for new/improved/updated content to be added. Any thought's about the PDF docs themselves? I know BSDs have a single PDF manual, which is one file, as well as an HTML website. Currently OI has only a website (plus - if the work I suggest is done - PDFs for each page of the website). The docs -- their various locations && inconsistencies, has been a *huge* peav of mine. I'd *love* to attack that problem. To that end && as a response to this thread; If someone has an archive of all the docs. I can easily script out /all/ the (HTML/CSS) tags from the documents. Making them all plain text. Where they can then be easily loaded into any MARKDOWN savvy (on||off)line editor to introduce the desired markdown markup. I can process hundreds of (X)HTML/CSS documents in seconds. I just need physical access to them to do it.. Thanks. --Chris James ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev -- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI Foundation
On 2021-05-27 21:42, Tony Brian Albers wrote: Gerard Arthus wrote: Should it be Illumos or Open Indiana; I guess the name has to be decided upon first . Gerry Gerard Arthus 409 Lowell Avenue East Mishawaka, Indiana United States 46545 Cell - 574-302-7731 Home - 574-520-1337 Instructor ITT-Tech - Mathematics, Electrical Engineering, and Computer Engineering. On Thu, May 27, 2021 at 11:54 PM Joshua M. Clulow via oi-dev mailto:oi-dev@openindiana.org>> wrote: On Thu, 27 May 2021 at 20:50, Gerard Arthus mailto:garthus...@gmail.com>> wrote: > I would actually be for Open Solaris and would prefer to see Solaris associated with the branding. What do others think? Solaris is a trademark or registered trademark of Oracle and/or its affiliates in the United States and other countries. illumos and Solaris diverged a decade ago; we're a different operating system now. Using "Solaris" anywhere near the software will only confuse people into thinking it's compatible with Oracle Solaris in some way, which it is not. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org <mailto:oi-dev@openindiana.org> https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev Just brainstorming here: How about just Indiana or jONEs(hehe, from Sun ONE and Indiana Jones) or OpenSun or SunOp(as in dawn, but referring to Operating system) or SolsticeOS(yup, Sun actually had Solstice Backup and other stuff, but AFAIK not an OS with that name). If we're voting here. I'd like to cast a vote for Solstice. OS just seems redundant. The beauty of it; is that you're calling it Sun, without doing it. ;-) Ooo, how 'bout Solstice Microsystems. --Chris I've actually always thought that OpenIndiana was a good name, but way too long. /tony -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI Foundation
On 2021-05-27 19:44, John Howard wrote: Might I suggest the OpenSolaris brand that Oracle seems to be exterminating. The fact people cannot use the brand Unix to identify a Linux distro further isolates the spread of Unix. FreeBSD and OpenSolaris derivatives are essentially the only Unix systems. MacOS is from FreeBSD but it is not popularized as a Unix. OpenSolaris is the origin of OI and Illumos. Illumos Foundation surprisingly does not exist. The purpose of a Foundation is to enable unifying support for a brand product. The first step is owning the brand name for products. Project OpenIndiana is not a brand name that makes sense. I still see no connection to Indiana. When the general public thinks of Ada, it is not the computer language but a group of dentists. I would say you're very much on target here. The only "hitch" I see here; is that when Oracle bought SUN, they also bought all the Sun brands. One of which is OpenSolaris. As you say, they clearly give a shit about it. But unless asked, they might throw a fit. If anyone attempted to use it without their "expressed permission". --Chris ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev -- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What is the equivalent for GNU ld's --export-dynamic?
On 2021-03-24 21:27, cretin1997 via oi-dev wrote: ‐‐‐ Original Message ‐‐‐ On Thursday, March 25, 2021 1:43 AM, Bob Friesenhahn wrote: 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 No. The GNU linker is not a problem. It is widely used across platforms. It's nothing wrong for the developers to insist it's the default. Even on platform doesn't use the GNU linker by default like FreeBSD, it's easily installed from ports/packages and it will just work. It is you, a weirded platform, with it incompatible linker, that caused the problem. As I said many times before and being hated because of this but I will not afraid said it again: software developers will just skip your platforms and support other platforms that they will have the least effort to support, that is platforms that behave almost identical to their first class platform, usually be Linux. Perhaps you didn't read my last email. OK, it's too long, I myself tired to read it, too. I did try to remove --export-dynamic and after that I could have the compiler to generate a shared library (.so file). And you are right, trial and error is the only solution, because I have no one to mentor, no one to ask for. But unfortunately, it seemed the produced shared library doesn't work. The program linked with it will just sit there but do nothing, it doesn't even seem to be launched, indicating that it failed to load the shared library or the shared library simply doesn't work. Someone on the internet said I should run truss on the binary, I did and I found after a while the program just sit there idle. No outputs were even printed by this program to the terminal. It just stuck and needs to be canceled with Ctrl+C. Regarding your FreeBASIC adventure; It sounds like your lib (.so file) is blocking on something. Is it possible to build it again with DEBUG symbols? This would cause it to be more informative during load/execution and that would tell us where it's blocking, and what it's expecting, or waiting for. Also, does it allow starting in a VERBOSE mode? Maybe a -v , -V or --verbose switch? This may also provide the clues needed to resolve the problem. Congrats on your progress so far with it! --Chris Sent with ProtonMail Secure Email. -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Is it possible for OpenIndiana and DilOS to cooperate together?
On 2021-03-24 05:59, cretin1997 via oi-dev wrote: I'm honest, I liked DilOS more than OpenIndiana. But OI is the only working graphical Illumos and I have no other choices. DilOS wanted to support graphical environment, too. I asked Igor about that and he gave me the milestones. The day DilOS will have a desktop is too far in the future. So what about the possibility of cooperating between two projects? DilOS will give OpenIndiana a much better base and OpenIndiana could help a graphical DilOS possible. Imagine, DilOS is Debian and OpenIndiana is Ubuntu. Both sides will win, and the users will win, too. Sort of. I'm not keen on the idea of ZoL (ZFSonLinux) the OI version is better. :-) Package management; while I suppose it's easy to use a DEB package manager, and import a bunch of Linux based applications. In the short run, it'd be a LOT of work, and a seemingly good amount of Linux shims for OI to introduce. Is this the best plan for the long run? OTOH if their graphics stack is better/more polished. Hijacking for OI seems tempting. :-) Mind you these are *my* opinions, and may, or may not be shared by others. :-) --Chris Please let me know what the two sides think about this. Sorry Igor, I know I should ask you first but I posted there anyway and waiting for the answers from both of you. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Geany problem
On 2021-03-24 05:23, cretin1997 via oi-dev wrote: I was shut up from the oi-discuss mail list so hopefully I still allowed to post here freely. I don't attempt to hide my identity so don't even call me as a troll, it's an serious insult to me. NP ;-) On latest OI, the Geany program has problem displaying the underscores on code. The underscores will be invisible even though they are still there. Saving the file confirmed that it's a display problem because it didn't remove the underscores from the file. I've run into this several times in the past in other situations. The cure for me was simply to change/choose a different font and/or scaling of said font. While it's no guarantee for your situation. I thought I'd mention it, as it WFM. :-) Good luck! --Chris BTW, I wanted to kindly remind you of the problem with Pluma crashing frequently I reported on the oi-discuss mail list. I have never received any news about it since then. I still watch the mail list archive by date so even though I'm unsubscribed from it I still not missed anything. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Tasks to focus on
On 2021-01-24 08:29, Gary Mills wrote: On Sat, Jan 23, 2021 at 02:35:01PM -0700, Nelson H. F. Beebe wrote: I'm part of the TeX Live team that every (northern) winter produces a new release; many O/S distributions then take up that release and repackage it according to their preferences. That's probably what Openindiana would do too. All software products installed on OI systems are installed from IPS packages, the same as on Solaris. The packages are built from source. Binaries are of no use for OI packages. 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. Type1 fonts are made available. Type1 fonts are often also embedded in PDF files, and other places where fonts can be embedded. IMHO Tex to be a valuable addition to OI. [...] However, at Utah, I make a point of doing test builds for many more, and I can report that this year, with newer compilers on Oracle Solaris 11.4, there were few problems in building a complete TeX Live 2021 set of binaries. The current status report is here: http://www.math.utah.edu/pub/texlive-utah/ I've read this quickly, and already see obstacles. OI packages have some restrictions that may not arise when the software is installed directly. o All software is installed in system locations, mostly under /usr . Configuration files go under /etc . Log files go under /var . PID files are installed in /var/run . o There are no private libraries, and no static libraries. All libraries are shared, in both senses of the word. Libraries are often supplied by other packages, and often other products. o User software does not distinguish between Intel, AMD, or other compatible CPUs. o 32 and 64-bit binaries go in the same package, although omitting the 32-bit versions is acceptable too. o Packages cannot interfere with each other unless they are alternative versions of similar products. The package build process installs the files into a prototype directory. Then the publish process builds the actual package from files in the prototype directory. Packages are made available by a package server, from which users can install them on their own systems. --Chris -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Plan for openssl update
On 2021-01-14 14:09, Bob Friesenhahn wrote: 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. LOL. Trust me. I'm *well* familiar with the "challenges" involved porting forward. A real PITA. But was forced to do so with all the ports I maintain w/FBSD. Whom dropped the last nail in the Python2 coffin 12-31-20202. :-( TBH I'm more the type; if it ain't broke. Don't fix it. But not everyone shares my policy. ;-) So. Just in case you thought otherwise. I am in no way lobbying for the removal of Python2. I (with tongue-in-cheek) suggested it, because it would have easily been the shortest route to a smaller list. :-) All the best. Bob --Chris -- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Plan for openssl update
On 2021-01-14 12:33, Aurélien Larcher wrote: Hello, I have just run the tool for creating a build plan for openssl. The stages, with each -- denoting a required intermediate update, are: narval> gmake print-dependents-plan FMRI=library/security/openssl library/openssl/openssl-1.0.2 -- cluster/libesmtp database/freetds database/mariadb-101 database/mariadb-103 database/mongodb-34 desktop/gftp desktop/hexchat desktop/pulseaudio desktop/synergy encumbered/rtmpdump library/botan library/gnome-vfs library/gsoap library/ldns library/libarchive library/libcouchbase library/libneon library/libp11 library/libssh2 library/libtorrent library/libvncserver library/trousers library/uwimap library/xmlsec mail/isync mail/mutt mail/postfix network/bind network/irssi network/lftp network/ntp network/openldap network/openssh network/openvpn network/proftpd network/rsync network/slrn network/socat network/vpnc openindiana/ca-certificates perl/net-ssleay print/cups python/python27 python/python35 python/python37 python/python39 ruby/ruby-23 ruby/ruby-26 runtime/erlang shell/mosh sysutils/borgbackup sysutils/ipmitool sysutils/snort sysutils/stunnel tcl/tcltls web/ejabberd web/elinks web/haproxy web/httping web/links web/lynx web/nginx web/php/php-7_0-ext-mongodb web/php/php-7_3-ext-mongodb web/w3m web/wget x11/mesa -- database/postgresql-10 database/postgresql-11 database/postgresql-12 database/postgresql-95 database/postgresql-96 desktop/e/efl desktop/freerdp encumbered/ffmpeg library/lasso library/libevent2 library/libgit2 library/serf mail/fetchmail mail/sendmail network/openconnect network/samba python/cryptography python/m2crypto python/pyopenssl runtime/squeak4 runtime/squeak5 runtime/squeak5c sysutils/net-snmp sysutils/nmap web/apache24 web/curl web/lighttpd x11/x11vnc -- database/couchdb-21 database/mongodb-40 database/percona-server-56 database/percona-server-57 database/pgadmin database/pgbouncer database/postgresql-11-citus database/postgresql-12-citus desktop/libreoffice desktop/remmina desktop/transmission developer/rust encumbered/gst-plugins-bad1 library/libetpan network/asterisk network/pdns-recursor network/tor python/pycurl sysutils/bacula sysutils/clamav sysutils/nut sysutils/virtualbox web/apache2-modules/mod_auth_mellon web/php/php-7_0 web/php/php-7_3 -- Required installation: [] 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. ;-) Kind regards, Aurélien --Chris -- ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] boot problems: KPTI enabled (PCID in use, INVPCID not supported)
OK I've been attempting to install the MATE desktop. I used pkg install mate_install. Which (seemingly) gave me everything I required. I created /etc/X11/xorg.conf.d/driver-intel.conf with everything required to get X to find the card. X starts, and Xorg.0.log seems to indicate everything is recognized. So I created a ~/.xinitrc file containing: mate-session I fired off a startx which gave me a light grey screen and nothing else. I waited some 4 minutes, then tapped the power button to signal OI to kill everything, and reboot. Upon reboot I encounter a stalled boot at: KPTI enabled (PCID in use, INVPCID not supported) hardware: i5 3360 3rd gen Ivy Bridge Thanks in advance for any insight into this. --Chris -- ___ 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 2021-01-11 12:59, Bob Friesenhahn wrote: 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. Editors, like DEs (Desktop Environments) are a *very* personal thing. Getting it right for *everyone* is a lost cause. ;-) OTOH importing all your dot files immediately after an install, can go a long way to getting it right. I like Bright on Dark for my old eyes. ;-) 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. I just this moment completed a fresh OI install, and lo-and-behold, there was a copy of nano available. Without requiring a pfexec pkg install nano. :-() --Chris Bob -- ~40yrs of UNIX and counting ___ 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 2021-01-11 12:36, Gary Mills wrote: On Mon, Jan 11, 2021 at 09:54:23AM -0800, 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. ;-) Shall I start editor wars? LOL. No. Please don't. :-) I'm can just as easily get by with cat(1), awk(1) and sed(1). I use ex, which is almost always there, until I can install emacs. Then I'm much happier. Even though ex is just a command-line version of vi, I've never learned vi. PS: Nano seems to be installed on all of my OI systems. I didn't install it, so it must have come with the OS just like vi. --Chris -- ___ 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 2021-01-11 08:23, Hung Nguyen Gia via oi-dev wrote: I know how to install nano, sir. ... I can't deal with vi at all. Not the modern VIM let alone your old vi. Without nano, I can't do text editing. Yes, vi is historically part of any Unix. But at least, on FreeBSD, they have a fallback, the ee editor, included by default. 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. ;-) It's basically what I'm asking for. IMHO ee/nano doesn't seem an unreasonable request as an addition to $BASE. ee(1) weighs in at 1k. I don't use nano, so am unsure of it's exact size. But I don't have a commit bit on OI so am only to express an opinion. :-) --Chris -- ~40yrs of UNIX and counting ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What's wrong with Pale Moon?
On 2021-01-09 04:19, v...@bb-c.de wrote: Hung Nguyen Gia via oi-dev writes: Our Firefox is way too outdated. Pale Moon is the only browser working well on OI. I came across a page on their site but can't find it again, it basically stated that the packaging of Pale Moon on OI was resisted by OI developers. So what's wrong with Pale Moon? I know their branding issue. But we could easily overcome it by not build with their official branding, our browser will be named New Moon and everything is fine. Please let me know more about your decision. Thanks. There was a long discussion on this mailing list in December 2019. Please check the list archives for details. Basically, the Pale Moon developers insist that one use private copies of a large number of libraries. If the system version of these libs are used instead, the Pale Moon devs consider that a license violation. Also, they came across as arrogant and high-handed, which was not well- received in the OI community. I can also say that the same was perceived by those (of which I'm one) attempting to make it available on FreeBSD. Regards -- Volker -- Volker A. BrandtConsulting and Support for Solaris-based Systems Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt "When logic and proportion have fallen sloppy dead" ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev -- ~40yrs of UNIX and counting ___ 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 2021-01-08 08:39, Andreas Wacknitz wrote: Am 08.01.21 um 17:15 schrieb Chris: On 2021-01-08 01:17, Joshua M. Clulow via oi-dev wrote: On Thu, 7 Jan 2021 at 23:53, Chris wrote: I'm looking to help building packages. Both current, as well as newer versions. I have a large server farm. But primarily BSD based. As such I'm looking into a new build box, based on an Opteron or Xeon. So before I take the plunge. I was hoping to add as many CPU/cores as possible. Which begs the question: haw many CPUs does OI support? I don't think you'll be able to buy a machine with more CPUs than we support in illumos. I've personally used older HP machines with 4 CPU sockets and thus a lot of cores, and modern AMD systems which have a still surprising number of cores in one or two packages. In the unlikely event that you hit a problem based on core count, I am sure it will just be a bug that can be fixed. OK so 4 sockets @16 cores/ea, or 2 sockets @64 cores/ea won't be a problem then. Thanks for the reply! :-) Time to go shopping. --Chris Cheers. Tell us when your server exceeds 384 Cores / 3072 Threads. AFAIK that's what actual Fujitsu/Oracle M12 provide at max. :D Sweet! :-) 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. Thanks for the stats. Maybe I should give Fujitsu a look. :-) --Chris ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev -- ~40yrs of UNIX and counting ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] How many CPUs does OI support?
I'm looking to help building packages. Both current, as well as newer versions. I have a large server farm. But primarily BSD based. As such I'm looking into a new build box, based on an Opteron or Xeon. So before I take the plunge. I was hoping to add as many CPU/cores as possible. Which begs the question: haw many CPUs does OI support? Thank you for all your time, and consideration. --Chris -- ~40yrs of UNIX and counting ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] New SPARC ISO for testing
On 2021-01-07 15:01, Gary Mills wrote:
This ISO is the same as the previous 2018 ISO except for two bug
fixes. If the last one didn't work for you, this one might.
One of the fixes is for one of disk drivers, one that's only used on
newer systems. It happens because driver is in two parts, causing the
boot to fail. It stops with this error:
undefined symbol 'sata_split_model'
The other is for the bash shell. The problem in this case, is that
it needs a library. If it's missing, the single-user console fails,
resulting in this error:
bash: fatal: libncurses.so.5: open failed
To use the new ISO, first download it from this location:
https://apt.dilos.org/oi-sparc/OI_2018_02_Text_SPARC.iso.gz
Then, check it's integrity like this:
$ digest -a sha256 OI_2018_02_Text_SPARC.iso.gz
9ea289ef064e320200ae979dae25e0c2aa8846fa57f033d742c0612cd654397f
Next, uncompress it with a command like this:
$ gunzip OI_2018_02_Text_SPARC.iso.gz
First off; thanks for your work! :-)
Then, burn it to a DVD. Note that the file OI_2018_02_Text_SPARC.iso
is a bootable DVD image. There's no known way to transfer it to a USB
stick. You must create and boot a DVD.
My OI box isn't in front of me ATM. But on the *BSDs I'm able to dump a
bootable CD/DVD image (iso) to a USB device/stick with dd(1) eg;
dd if=iso-image.iso of=/dev/ bs=1m conv=sync
I'm not sure there's that much difference in that regard between
BSD vs OI. But I'll download your image and give it a go. Then report my
findings.
Thanks again!
--Chris
As well, only the text DVD
image is available for the SPARC platform.
Next, boot the DVD on your SPARC machine. This OBP command worked for
me, although I had to do it twice:
{0} ok boot cdrom
When the text boot is successful, it will guide you through the
process of configuring and installing OI. Near the end, it will ask
you to select a disk to receive the OI installation.
Finally, boot the disk that contains the newly-installed copy of OI.
It can be used with the original repository to install new packages.
I'd like to get your reports on this new ISO. Both it and the
original ISO boot and run correctly on my T2000 system. However, it
may not run on different SPARC systems. In particular, I'd like to
know if the new ISO boots and runs on newer hardware. Please report
your hardware, and whether it succeeded or failed. If it failed, I'd
like to see the error messages. If the new ISO is successful, I will
be uploading a newer matching repository.
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Tasks to focus on
On 2021-01-07 13:39, Aurélien Larcher wrote: Hi, since I have now more or less recovered from Covid I can be active to some extent. Back in March I was working on: - building oi-userland with GCC-10 (everything was built except ~10 packages). - providing Python 3.8 and 3.9. - migrating pkg5 to Python 3.7. - updating Boost. - updating Clang. - updating Rust. - updating libdrm to 2.4.100. - bringing automated rebuild of oi-userland packages and dependencies in order. However priorities should be set as I cannot dedicate too much time... - What do you think should be prioritized? - Is anybody interested in picking up one of the tasks? I can assist and provide some guidance. Congrats on your Covid recovery! I can relate, as I got it bad back in late December. It's no picnic; that's for sure. While I'm not attempting to create your priority list. As the maintainer of some 160 FreeBSD ports, and a happy OI user. I'd like to pitch in, and offer time, and CPU cycles to help out. I'm afraid I wouldn't know where to start. Or rather; I'm well familiar with setting up build farms (jails) and building/fixing rebuilding everything. I'm really just looking for a list of things to start with. Feel free to contact me off list if you like. All the best! --Chris Kind regards, Aurelien ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Garrett D'Amore interview
Hi Garrett. Our interview has been published at Unixmen. See here. http://www.unixmen.com/exclusive-interview-garrett-damore/ Regards Chris Jones -- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQENBFGj7+QBCACrid2HxXC3oIVuFwr2S52IYVLzYqx9Wf1vi9I4Q4IM/JWcnTRe JfU2NEZt5qszQMCWrbPRPmZMbWJ006flV0yju7LlJYRrXOiJj/Fs3LXYuhIiDz2i 4A/TLldgUMiWXlqymDMhKf2vBRoLOzyuxW25YMOVoUj1mXiXj00L+ThihtGnG6pT t6Z59bVmMc2Gwghx7EEzt4OSrksciTVfx5/9QPb9byDp4HGiLR9FfEeFFYsk1ALC ULNzakqoEvYSxVQ0DwtIJSA3JwOKN4N4yti1FS+EKYwWG+Cw6M47a/iy/BllwiL4 xadus05sYTAWRDrldQ2ktVotEZ1T0P1xVJPBABEBAAG0JENocmlzIEpvbmVzIDxj aHJpc2pvbmVzQHVuaXhtZW4uY29tPokBPgQTAQIAKAUCUaPv5AIbAwUJAChVfAYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQBGN2ZNrtceiC4wgAn0qej/x6w8vT sAXxLUD594d0BtiL59OXU0zQWNiHYvg+jkYxW9KaFHV3Asy2EBK+z8V6y9OtFo0S VSxQcOcYFc/XrwdinF5ckFf6XdobvAY+mJlt0zTM12WXwOoh45/Nbkp9EuzBLYwr K+h/FeK/tyBN11L+mzC0hQ4x8G3U5WGbrbdA+PYlTYyPJOu5Sku75oWzCDXof3bI saO6ZkTm6iagnfVEJvH2zqMk+VeqmFNxiAMYYLB7dMdisikffHEMjUp6ipASRgwU LguDQUvy1umPoVDYMsIeUDlTi7aXyMIc2J+afDOwNYIaEHnku85s9w61cXvL8e53 0Qy+Hf/Ztg== =UxXQ -END PGP PUBLIC KEY BLOCK- ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Garrett D'Amore interview
As the interviewer, I feel I should clear things up here. At Unixmen, we had already interviewed Alasdair regarding his resignation. That was a good interview and Alasdair was very open and honest with us. I expected the same from Garrett. Instead, his responses were short and straight to the point. Nothing more, nothing less. And that is fine because I think it really shows how Garrett Feels about OpenIndiana. I admit the original questions were worded different, but my intention of the resulting answer was identical. It was a small mistake of words and lack of understanding of Garrett's position (or lack of) within the OI project which prompted me to reword the questions prior to publishing the interview, as the original questions just didn't make sense to the given answers. I really thank Garrett for his answers given because he was obviously smart enough to understand what I was really trying to ask. I hope this puts the whole thing in to perspective and clears up any confusion. Regards Chris Jones Chief Editor - Unixmen -- Sent from my Android TouchTAB II with K-9 Mail.___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Orange Indiana?
Wow, there is some incredibly interesting reads in the mailing list lately. I have been following it with great interest. I have been giving it a lot of thought lately. And especially OpenIndiana. Let's begin with saying Illumos is great. And OpenIndiana has the potential of being great. But at the moment, it's clearly stale and needs some serious action to be revived. I strongly suggest either a re-branding of the name and a complete re-shuffle of management etc. Or the alternative is to fork the project (or someone to fork it) and call it something different. Because at the moment, OpenIndiana is simply dying a slow and painful death. Personally, I am seriously considering setting up a git tree locally, pulling in Illumos and getting to work on something new that could someday continue on where OpenIndiana failed. Because it's not only sad to see such good code wasted, but it's becoming offensive to fans of Illumos. Regards Chris Jones -- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.13 (GNU/Linux) mQENBFF6JoQBCADvrA07ocG4OJBaRfb3RkAQUlfadrW4wyT5jTWv8SY0tDVZsGqa zvsmpIm0pAA4/FtFb70Lo1c7DzITjPFw+iDhzL3sVKpHuvdl141EwtZobI0pYC8q LVDQI/3BQCNapiIaHCSPDtQnqa02hdiaFB2iaFfNU0MHVYqGRxfydn4Dpoocexn7 c4qFs6Fgz25WOcJ4tiRRyj8KZrfc2E8DRj5u4HNy1uBDp4Yl73PIActUySUbVsOx 4ZeO0dx7ODIDqtxxCG9mEmXJZzRUtIDdXlzztsE7ITSmysPVq65MAjeAOIG8Z0lp t0/KlMacKYb6HDEWLhnjNeHYlkZ54Kb1MnfxABEBAAG0JENocmlzIEpvbmVzIDxj aHJpc2pvbmVzQHVuaXhtZW4uY29tPokBPgQTAQIAKAUCUXomhAIbAwUJACdGHAYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQK91yhbSfkL+MaAgAgLWkxQqcc+V0 NkmkLtzb/Bb5XS23tarz08iY7GPimmWIQmWulrORT+JVmBVkg7MRzcvVEOXrlZcE Ttth/+sPDFufHXAE5bC4XDuSIcE7U2J4AOKKFyGfYnC220qXk+MHdBgfphtuagEH Lq8UN/od0t9cNrEnCLjRNm/lpu+R+JHW/6/C+Bd2PAHZ22ib1PfIIT8CM4oPs3lR ItZwzqjSlPZb4RP6i190mcLippJHFzCWdiQG03yI8+UIFj42gsJ8jGMfXOvSEt+J gcgXB2EnZfVFPLM5zkjsehxfjn0gB1SFML5i5ig40GKivKE3UhX5nv4gupGfrGGj xl4XGTaS3A== =sDOZ -END PGP PUBLIC KEY BLOCK- ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Support OI and illumos for GSoC 2012
On 17 Mar 2012, at 13:04, Bayard Bell wrote: If you have a copy of VMWare, it would be much appreciated if you could contact me directly and/or join the oi-dev mailing list and work with us to provide an appliance distribution. The latter's not difficult, but the development team has so much else on at the moment that we really need someone to step up for this. I've got VMware here and at work, so am happy to help providing a VMware appliance distribution. This is to allow GSOC-type work, right? Or a GSOC project all by itself? Chris ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Supplying packages..
On 9 Dec 2011, at 03:34, Jorgen Lundman wrote: In the past, I have always done pkgadd style packages of my own work for Solaris. Recently we have started using oi-IPS repository at work, so I thought it might be worth upgrading my own packages to IPS-style, as well. But I assume I can't just pkgsend publish to OI's repo. What is the policy here, what is the procedure? I could set up a new repository on my own server, and ask any users to set-publishers to get my application, but that does seem a tad silly for just the one package (at the moment). The last part is correct - create your own IPS server, and users will need to add your publisher to their machine to see your package(s). You may also want to look into securing your IPS server so that only the expected users machines can add new packages to it. Chris ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fwd: [OpenIndiana-discuss] Documentation-Project
On 30 May 2011, at 16:49, Ken Gunderson wrote: On Mon, 2011-05-30 at 08:24 +0400, Garrett D'Amore wrote: Switching to another less popular doc format doesn't seem like a great idea. I don't work with the documentation frequently, but I'd ask people that do. One thing is that some of these formats are like fads... they come and go. I remember not long ago when SGML was all the rage. :-) From my perspective it would be good to have a format that has good tools available (multiple implementations, at least some of which are portable to other platforms), displays nicely, and provides some basic structure capabitilities to assist in parsing for content or format conversion (e.g. to HTML). If you make me install a bunch of new tools, or learn a format that nobody else uses, I probably will be less inclined to write documentation. (That said, I've not written much except a few man pages, and the format of *those* is relatively constrained by the need to be able to display them with the man command. :-) -- Garrett D'Amore I would think Docbook would be the way to go. Yeah, it's going to require some specific libraries and tools but it's transformable to many different formats. I haven't dealt with it for a while now but easily to morph to man, text, html, and pdf, which I think pretty much covers all reasonable bases. Yes, and epub. RTFM on your iPhone :-) XML situps are a pain after the first few thousand. Last I looked most good XML editors out there were proprietary. All fine and dandy if you're a commercial corp with a documentation staff but such would seem to raise the bar w/o much of any real gain for a small FOSS project. There are reasonable docbook-aware editors around which work on Solaris, and which are free for use by non-commercial outfits. Most are Java. XXE (www.xmlmind.com) is the one I use, based on our tech author's recommendation. The fact there *are* many ways to maintain Docbook content is a point in its favour. Are the Solaris man pages still authored in some kind of customized Docbook? Chris ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Distribution build system
On 16 Mar 2011, at 15:43, Andrzej Szeszo wrote: On 03/16/11 13:34, Chris Ridd wrote: On 16 Mar 2011, at 12:12, Deano wrote: A laudable aim but do we have the man power to do it, without negatively affecting our existing schedules for illumos and stable releases? Can we afford *not* to do it? Anything to make it easier and more practical for contributions the better... We could start from the top, automate distro-importer and distro-constructor first while using pre-compiled components. Then gradually add consolidation build systems to the tree. This is just one of the possible approaches. We definitely need automation/repeatability if we are thinking about maintaining stable release. I completely agree. FWIW at work we have an XML file describing each release as (essentially) a number of git repos + tags to checkout, and then what script to run to build each given repo. Our overall build script goes through that XML in order, and is able to do the right thing. This gives us pretty reproducible releases. Chris ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Developer meeting
On 1 Dec 2010, at 17:01, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/11/10 20:48, Guido Berhoerster wrote: I'd like to propose that we hold developer meetings regular basis either on IRC I would rather prefer to use XMPP/Jabber. We don't need to use a centralized infraestructure we don't own at all. I agree - there's no reason not to run an XMPP server on openindiana.org, just like it runs an MTA for mail. There are free XMPP servers (ejabberd is one I've heard most about, and would probably be fine for a small group like this) and commercial ones (my company sells the one used at jabber.org for example). We'd be able to keep chat transcripts centrally, that sort of thing. Using irc.freenode.net feels a bit like us choosing to email using Lotus Notes instead of SMTP :-) BTW, my JID is j...@jabber.org. I would like to add presence subscription to/from OpenIndiana/Illumos interested people. Good idea. My JID is chris.r...@isode.com. PS: If you use Gmail, you automatically are in the XMPP network. Accounts at jabber.org are also free. Cheers, Chris ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
