Github messages for voidlinux
 help / color / mirror / Atom feed
From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: [Package Request] SeaMonkey
Date: Sun, 29 Dec 2019 12:29:42 +0100	[thread overview]
Message-ID: <20191229112942._Gu3Em5szdbgvTZCfy9613HqMqGDLIJxKsjwNgmR_3c@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-17772@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 4567 bytes --]

New comment by rubyFeedback on void-packages repository

https://github.com/void-linux/void-packages/issues/17772#issuecomment-569496749

Comment:
I agree only partially with q66.

I agree in the sense that mozilla has lost it completely some years ago, so I would be sceptical of their code (actually including FF, so I am not sure why FF should be treated differently to seamonkey here; I'd be wary of anything mozilla touches these days).

HOWEVER had, I disagree on this part:

> make it worth packaging

IMO that should not be up to you, or anyone else to decide, for OTHERS whether their use case includes wanting to use seamonkey or not. If someone wants to use seamonkey, why should you or anyone else forbid this? It's fine if you can not do so or do not want to do so; lack of time is a completely valid reasons. I just disagree that it should be up to others to dictate use cases onto others when it comes to any general purpose linux distribution.

It's perfectly fine to tell people that there are security issues (and this is the case for other projects too, by the way, so I don't see why this arbitrary distinction should exist). You are not responsible for their own actions. That can be handled in a generic manner by labeling packages as "secure" or "not secure" etc...

Building seamonkey, as it is with everything else Mozilla dishes out, is hugely annoying though. I can understand people not being extremely eager to go through it:

http://www.linuxfromscratch.org/blfs/view/cvs/xsoft/seamonkey.html

I typically need either python-2, and/or autoconf-2.13. What madness is this? This madness comes from a code base that has not been maintained in many years really. Other projects transitioned to cmake or meson/ninja and they, for the most part, work fine. Mozilla on the other hand has given up many years ago, and it shows.

I tried to compile the latest /seamonkey-2.49.5 and it fails at this point:

rm -f libmozsandbox.so

/seamonkey-2.49.5/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /Depot/jjj/seamonkey-2.49.5/mozilla/config/expandlibs_exec.py --uselist --  /usr/bin/g++ -std=gnu++11  -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wc++1z-compat -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -fno-lifetime-dse -fPIC -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -pthread -pipe  -g -O2 -fomit-frame-pointer  -fPIC -shared -Wl,-z,defs -Wl,-h,libmozsandbox.so -o libmozsandbox.so  logging.o at_exit.o callback_internal.o lazy_instance.o ref_counted.o singleton.o safe_sprintf.o string16.o string_piece.o string_util.o string_util_constants.o stringprintf.o utf_string_conversion_utils.o utf_string_conversions.o condition_variable_posix.o lock.o lock_impl_posix.o waitable_event_posix.o icu_utf.o platform_thread_internal_posix.o platform_thread_linux.o platform_thread_posix.o thread_collision_warner.o thread_id_name_manager.o thread_local_posix.o thread_restrictions.o time.o time_posix.o bpf_dsl.o codegen.o dump_bpf.o policy.o policy_compiler.o syscall_set.o die.o syscall.o trap.o syscall_wrappers.o LinuxCapabilities.o Sandbox.o SandboxBrokerClient.o SandboxChroot.o SandboxFilter.o SandboxFilterUtil.o SandboxHooks.o SandboxInfo.o SandboxLogging.o SandboxUtil.o SandboxBrokerCommon.o   -lpthread  -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -B /Depot/jjj/seamonkey-2.49.5/obj-x86_64-pc-linux-gnu/build/unix/gold    -Wl,-rpath-link,/Depot/jjj/seamonkey-2.49.5/obj-x86_64-pc-linux-gnu/dist/bin -Wl,-rpath-link,/home/Programs/Seamonkey/2.49.5/lib         -ldl  -lrt 
chmod +x libmozsandbox.so
strip  libmozsandbox.so
../../../config/nsinstall -R -m 644 'libmozsandbox.so' '../../../dist/bin'
make[4]: Leaving directory '/Depot/jjj/seamonkey-2.49.5/obj-x86_64-pc-linux-gnu/security/sandbox/linux'
make[3]: Leaving directory '/Depot/jjj/seamonkey-2.49.5/obj-x86_64-pc-linux-gnu'
make[2]: *** [/Depot/jjj/seamonkey-2.49.5/mozilla/config/recurse.mk:33: compile] Error 2
make[2]: Leaving directory '/Depot/jjj/seamonkey-2.49.5/obj-x86_64-pc-linux-gnu'
make[1]: *** [/Depot/jjj/seamonkey-2.49.5/mozilla/config/rules.mk:523: default] Error 2
make[1]: Leaving directory '/Depot/jjj/seamonkey-2.49.5/obj-x86_64-pc-linux-gnu'
make: *** [client.mk:397: build] Error 2

Mozilla is dead IMO. Perhaps others have more luck though; I am using an outdated glibc.

  parent reply	other threads:[~2019-12-29 11:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-25 17:36 [ISSUE] Seamonkey voidlinux-github
2019-12-28  1:35 ` [Package Request] SeaMonkey voidlinux-github
2019-12-29 11:29 ` voidlinux-github [this message]
2020-01-06 17:48 ` voidlinux-github
2020-01-29 14:28 ` voidlinux-github
2020-01-29 14:29 ` voidlinux-github
2020-01-29 16:46 ` voidlinux-github
2020-02-01 17:20 ` voidlinux-github
2020-02-01 20:50 ` voidlinux-github
2020-02-29 22:23 ` userabc123xyz
2020-05-06 22:56 ` userabc123xyz
2020-05-06 23:00 ` userabc123xyz
2020-05-06 23:00 ` userabc123xyz
2020-05-06 23:00 ` userabc123xyz
2020-05-06 23:03 ` userabc123xyz
2020-07-19 16:57 ` xianwenchen
2021-03-03  6:01 ` rogerxxxx

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191229112942._Gu3Em5szdbgvTZCfy9613HqMqGDLIJxKsjwNgmR_3c@z \
    --to=voidlinux-github@inbox.vuxu.org \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).