Re: [oi-dev] Would OI be interested in Pale Moon?
On 12/11/19 07:38 AM, Jeremy Andrews wrote: I ported UXP to illumos and Solaris recently, and I got them to take the code upstream. I'm pretty anxious about the process now honestly, and really want everything to work out. There are a few things I'm worried about, though. 1. I'm not very familiar with how packages are actually packaged for OI, and the p5m file for Firefox in particular is... so complicated that I've been holding off creating a Pale Moon system package for OI until now, when they're pushing me to try. I was hoping that the subject wouldn't come up and they'd just want to distribute a binary .tar.xz file like they do for other operating systems (that kind of package is very easy to create with a single command). I'm so mixed up because the .p5m file for Firefox 52 looks so different from the one for Firefox 60, and includes all these header files, is for 32-bit, etc. And I'm trying to figure out which differences are due to a change in package design, and which are due to actual differences in Firefox. 2. Pale Moon has some unusual requirements. For one thing, it can't use the system NSS because Mozilla has changed the API somewhat since they forked. In general, they're leery of using system libraries over the ones in their own tree because sometimes those libraries have to be modified in specific ways for the browser. On top of that, they seem to have a problem with distributing the langpacks with the browser. They have a site where you can download a langpack of your choice, but you can't ship it with the browser for some reason. I'm kind of afraid now that I've done all this for nothing. I'm worried that their packaging requirements and our packaging requirements may not line up, and I'll wind up only being able to distribute a tarball on my own web space that no one will ever download. It's a very good browser, and the people behind it are actually decent people, but... I'm overwhelmed with the sense that I've gotten in over my head. Given the hostility Pale Moon developers showed towards a license non-complying OpenBSD port at https://github.com/jasperla/openbsd-wip/issues/86, I'd rather avoid this community at all. The other reason is maintenance cost on the OpenIndiana project. We already have Firefox and due to it's complexity it gives us hard time to keep-up even with ESR releases (currently we are stuck at version 60, 68 is the latest one; the story for the 52->60 transition was the same). Same with Thunderbird. I am afraid Pale Moon would be another chapter of the very same story. Michal ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Where should SPARC go?
Thanks for your answers, Gary. One point of clarification below: On 11/27/19 03:58 PM, Gary Mills wrote: * we don't test that changes build the less work on SPARC I don't understand this condition. "It's not required to test update (PR) on SPARC for it to be merged." Is this wording clearer? Currently it's required minimal testing to be done for a PR to be accepted. I am basically not expecting PR to be tested on SPARC for it to be integrated. Michal ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Where should SPARC go?
On 12/12/19 03:13 PM, Gary Mills wrote: On Wed, Dec 11, 2019 at 09:34:03AM +0100, Michal Nowak via oi-dev wrote: Thanks for your answers, Gary. One point of clarification below: On 11/27/19 03:58 PM, Gary Mills wrote: * we don't test that changes build the less work on SPARC I don't understand this condition. "It's not required to test update (PR) on SPARC for it to be merged." Is this wording clearer? Yes, that's clear to me. Currently it's required minimal testing to be done for a PR to be accepted. I am basically not expecting PR to be tested on SPARC for it to be integrated. I assume that a PR will always be tested on x86. That's fine with me. Thanks. This arrangement should work for me. Feel free to come-up with SPARC-related PRs in GitHub. Michal ___ 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 12/11/19 12:51 PM, Jeremy Andrews wrote: This is an interesting discussion, and I did want to address some additional comments... Actually, the restrictions they have are on the use of the official branding. They are saying you have to build it a specific way if you want to use their official branding, and they have very specific requirements to get permission to use official branding that I've managed to comply with thus far. However, if you were to use alternative branding like IceWeasel-UXP does: https://wiki.hyperbola.info/doku.php?id=en:project:iceweasel-uxp Then you don't have to follow those requirements. I assumed since you weren't interested in Pale Moon, you weren't interested in anything like this at all, but I heard someone talk about issues with Rust and then someone else mention IceWeasel which reminded me there was an alternative. The big advantages of the UXP platform are that it supports more modern websites than older Firefox does, doesn't have Rust or telemetry, and still supports XUL extensions and NPAPI plugins. The irony of all this is, the reason Pale Moon has the branding restrictions is because they haven't tested any system libraries other than their own internal ones, they don't want to provide support for custom builds, and they're worried about their browser getting a bad reputation for being buggy due to being built in an unsupported configuration. But now their browser apparently has a bad reputation because of their licensing restrictions. Jeremy, thank you for the explanation. We value your work and interest. Even-though we won't accept Pale Moon, I hope this whole exercise helped you understand web browser's internals. As others I invite you to work with us on bringing Firefox 68 ESR to OpenIndiana. Your skill-set looks right for the task. Currently we update LLVM (https://github.com/OpenIndiana/oi-userland/pull/5389) so we can build newer Rust, and thus build new Firefox (https://github.com/OpenIndiana/oi-userland/pull/4999). Talk to us on #openindiana Freenode channel if this suits your interests. Michal ___ 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 12/11/19 08:37 PM, Matt A. Tobin wrote: BUT, that isn't what has happened this day. No, this day did not turn out as hoped for by the young programmer. Something very different happened. He, and by extension, all of us who work on the Unified XUL Platform and the projects, Pale Moon included, that build on it have been rejected out of hand. We don't reject Jeremy, he is warmly welcome to work with and in our community (as stated before). Pale Moon is what we rejected. Not only from the reason you concentrate your reply around, but also from the other reason - we are a small community and we need to focus our efforts in a certain way, that's why we e.g. don't have desktop environments other than MATE. 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. It may have played out differently if Jeremy talked to us about possible Pale Moon integration months ago when he started the work, because the position of at least one of our developers was clear back then and is on record at https://alp-notes.blogspot.com/2018/02/a-brief-story-of-how-you-shouldnt.html. Michal ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] No rsync at dlc-origin?
On 02/02/20 08:15 AM, Marcel Telka wrote: Hi, I noticed that rsync at dlc-origin stopped to work about 4 days ago: rsync: failed to connect to dlc-origin.openindiana.org (91.194.75.37): Connection timed out (145) rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3] Is this intentional? Thanks I think it's just down for some reason. Thanks for letting us know. Michal ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] No rsync at dlc-origin?
On 02/07/20 06:46 AM, Marcel Telka wrote: On Sun, Feb 02, 2020 at 01:28:12PM +0100, Michal Nowak via oi-dev wrote: On 02/02/20 08:15 AM, Marcel Telka wrote: I noticed that rsync at dlc-origin stopped to work about 4 days ago: rsync: failed to connect to dlc-origin.openindiana.org (91.194.75.37): Connection timed out (145) rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3] Is this intentional? I think it's just down for some reason. Thanks for letting us know. ... and will somebody make it working again? Thanks. Ticket to our provider was filed, WIP. Michal ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] GOCACHE for Jenkins jobs
We came across this problem before and therefor added
COMPONENT_BUILD_ENV += GOCACHE="$(SOURCE_DIR)/gocache"
to golang-11{2,3} packages.
Any idea why this still failed?
Michal
On 01/27/20 09:37 AM, Till Wegmüller wrote:
Hi Aurelien
Yes you must define GOCACHE. Go modules requires this path to download
and unpack/compile Build dependencies. It will also speed up any
subsequent runs if this Cache is globally.
Here is my Jenkins config for go 1.11+
environment {
GOCACHE = "${WORKSPACE}/gocache"
GO111MODULE = "on"
GOPATH = "${WORKSPACE}/../gopath"
}
GO111MODULE might not be necessary depending on the Software you are
building but they have to include a note if they do not support go
modules yet. Acording to the Go community it is advised to file a
upstream bug of Go modules are not yet supported.
If you need any Help with Go let me know. I Programm with it as my Day
Job and maintain the OpenIndiana Packages. Chances are I have come
accross an issue before :)
Greetings
Till
On 26.01.20 23:49, Aurélien Larcher wrote:
Hi,
it seems that MongoDB 3.4 fails to build on Jenkins because Go 1.12
requires a path used for caching files.
"build cache is required, but could not be located: GOCACHE is not
defined and neither $XDG_CACHE_HOME nor $HOME are defined Error building
bsondump"
As a workaround I defined a GOCACHE variable in the Jenkins
configuration but that is probably not suitable in the long run.
Kind regards,
Aurelien
--
---
Praise the Caffeine embeddings
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Building openjdk-8-162 with gcc-6 on SPARC
On 01/12/20 04:03 PM, Gary Mills wrote:
I'm attempting to build openjdk-8-162 with gcc-6 on SPARC hardware. I
finally got a successful gmake build, but a failure with gmake
install. The error was this one:
Error occurred during initialization of VM
java.lang.StackOverflowError
at java.lang.Object.(Object.java:41)
All newly-build java applications produce the same error. With a
search on the web, I found exactly the same error for linux. The bug
apparently affected all architectures except x86. It appeared because
of increased optimization in later versions of gcc. This is the linux
patch:
diff --git a/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
b/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
--- jdk8/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
+++ jdk8/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
@@ -55,8 +55,8 @@
#include "utilities/vmError.hpp"
address os::current_stack_pointer() {
- address dummy = (address)
- return dummy;
+ // return the address of the current function
+ return (address)__builtin_frame_address(0);
}
frame os::get_sender_for_C_frame(frame* fr) {
This, of course, has no effect on OI. During the build, OI is
detected as solaris. The equivalent function for solaris-sparc, in
openjdk/hotspot/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp,
has this code:
address os::current_stack_pointer() {
volatile int dummy;
address sp = (address) + 8; // need to confirm if this is
right
return sp;
}
I assume that it's also compiled incorrectly because of the increased
optimization, but I don't know how to correct it. I'm also concerned
about the comment. Is it right?
Has anybody else built openjdk for SPARC with gcc? How did you fix
this bug?
Does building with lesser optimization level than the present one make
the problem go away? Look for 'gcc_OPT' in make-rules/shared-macros.mk
and use it in the component's Makefile.
Michal
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
