GNU logs - #73093, boring messages

Message sent to bug-gnuzilla@HIDDEN:

Subject: bug#73093: Shouldn't Icecat should be moving to the 128.x.x branch?
Resent-From: Nin Gen <0xningen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnuzilla@HIDDEN
Resent-Date: Sat, 07 Sep 2024 07:47:02 +0000
Resent-Message-ID: <handler.73093.B.17256951967594 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 73093 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Nin Gen <0xningen@HIDDEN>
Date: Sat, 7 Sep 2024 01:13:22 +0000
Message-ID: <CALwzZ+dvdkSOc+SFa39C0LKVNLmcaGLgd7=UpTZ0niNP_-U3Zg@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000097768206217d3bda"
Received-SPF: pass client-ip=2607:f8b0:4864:20::112c;
 envelope-from=0xningen@HIDDEN; helo=mail-yw1-x112c.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Mailman-Approved-At: Sat, 07 Sep 2024 03:46:33 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

--00000000000097768206217d3bda
Content-Type: text/plain; charset="UTF-8"

Hi all,

I am just wondering shouldn't icecat be moving to 128.x.x now? There are
already esr release builds for this branch
https://ftp.mozilla.org/pub/firefox/releases/128.2.0esr/ and the 115.x.x
branch will be moving to deprication.

The main reason why I bring this up is because on rolling release distros
like ArchLinux, we are unable to compile Icecat 'cleanly as is' due to
clang17/llvm17 being required to build Icecat since 115.13.0 onwards, and
since the current version of clang/llvm is 18 which seems not backwards
compatible we cannot compile Icecat without compiling an older
clang17/llvm17 independently which is very troublesome and problematic.

Thank you,

--00000000000097768206217d3bda
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi all,<br><br>I am just wondering shouldn&#39;t=
 icecat be moving to 128.x.x now? There are already esr release builds for =
this branch <a target=3D"_blank" href=3D"https://ftp.mozilla.org/pub/firefo=
x/releases/128.2.0esr/" rel=3D"noopener noreferrer" class=3D"gmail-u-link">=
https://ftp.mozilla.org/pub/firefox/releases/128.2.0esr/</a> and the 115.x.=
x branch will be moving to deprication.<br><br></div>The main reason why I =
bring this up is because on rolling release distros like ArchLinux, we are =
unable to compile Icecat &#39;cleanly as is&#39; due to clang17/llvm17 bein=
g required to build Icecat since 115.13.0 onwards, and since the current ve=
rsion of clang/llvm is 18 which seems not backwards compatible we cannot co=
mpile Icecat without compiling an older clang17/llvm17 independently which =
is very troublesome and problematic.<br><br></div>Thank you,<br>

</div>

--00000000000097768206217d3bda--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Nin Gen <0xningen@HIDDEN>
Subject: bug#73093: Acknowledgement (Shouldn't Icecat should be moving to
 the 128.x.x branch?)
Message-ID: <handler.73093.B.17256951967594.ack <at> debbugs.gnu.org>
References: <CALwzZ+dvdkSOc+SFa39C0LKVNLmcaGLgd7=UpTZ0niNP_-U3Zg@HIDDEN>
X-Gnu-PR-Message: ack 73093
X-Gnu-PR-Package: gnuzilla
Reply-To: 73093 <at> debbugs.gnu.org
Date: Sat, 07 Sep 2024 07:47:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnuzilla@HIDDEN

If you wish to submit further information on this problem, please
send it to 73093 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
73093: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D73093
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnuzilla@HIDDEN:

Subject: bug#73093: Shouldn't Icecat should be moving to the 128.x.x branch?
Resent-From: bill-auger <bill-auger@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnuzilla@HIDDEN
Resent-Date: Mon, 16 Sep 2024 05:11:02 +0000
Resent-Message-ID: <handler.73093.B73093.172646345124380 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Nin Gen <0xningen@HIDDEN>
Cc: 73093 <at> debbugs.gnu.org
Date: Mon, 16 Sep 2024 01:06:19 -0400
From: bill-auger <bill-auger@HIDDEN>
Message-ID: <20240916010619.5c504622@HIDDEN>
In-Reply-To: <CALwzZ+dvdkSOc+SFa39C0LKVNLmcaGLgd7=UpTZ0niNP_-U3Zg@HIDDEN>
References: <CALwzZ+dvdkSOc+SFa39C0LKVNLmcaGLgd7=UpTZ0niNP_-U3Zg@HIDDEN>
Organization: parabola gnu/linux
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

you may not need LLVM/clang - GCC also works most of the time - both will
often fail depending on the version, arch, and available dependencies - in some
cases, only LLVM can compile mozilla; and in some cases, only GCC can - it is
one of those cases so often that the parabola mozilla PKGBUILDs ('iceweasel',
icecat', 'icedove', etc) have switches to quickly swap compilers and linkers

from https://git.parabola.nu/abslibre.git/tree/libre/icecat/PKGBUILD

  if   (( _USE_ALT_COMPILER ))
  then cat >> ../mozconfig <<END
export CC=gcc
export CXX=g++
export AR=gcc-ar
export NM=gcc-nm
export RANLIB=gcc-ranlib
END
  fi

  if   (( _USE_ALT_LINKER ))
  then sed -i '/cargo_rustc_flags += -Clto/d' config/makefiles/rust.mk
       cat >> ../mozconfig <<END
ac_add_options --disable-linker=lld
ac_add_options --enable-linker=bfd
ac_add_options --disable-lto
ac_add_options --disable-rust-simd
ac_add_options --disable-debug
ac_add_options --disable-debug-symbols
END
  fi

with one known caveat: for v128 and later, the behavior of $_SKIP_PGO in the
parabola PKGBUILD (skip the PGO build stage) will also be necessary when
$_USE_ALT_COMPILER and the --enable-profile-generate=cross options are both
enabled

> ac_add_options --enable-profile-generate=cross
->
> ERROR: Cannot use cross-language PGO with GCC.

so the current 'iceweasel' PKGBUILD (and the next 'icecat' PKGBUILD) define
_SKIP_PGO to account for that

> readonly _SKIP_PGO=$(
>   case "${CARCH}" in
>     armv7h|i686) echo 1                    ;;
>     *)           echo ${_USE_ALT_COMPILER} ;; 
>   esac
> )


On Sat, 7 Sep 2024 01:13:22 +0000 Nin wrote:
> the current version of clang/llvm is 18 which seems not backwards compatible

o/c it may not be forward-compatible either - this is a general concern which
all distros must manage routinely - it is typical of software like mozilla,
which supports it's deps so narrowly, releases too often, and has the public
convinced they they must always be running the latest _upstream_ release
- for example, the current LLVM in debian and trisquel is v14, which means that
rolling distros could compile icecat 128; but LTS distros (the greatest
user-base) could not compile it, even if it was ready

the version of LLVM in the distro repos (or any other build dep) is as likely
to be too new as it is to be too old - i think that mozilla targets the latest
ubuntu, which means that LTS distros (eg: debian, trisquel) will normally have
older versions of build deps than the ones tested against by mozilla; and
rolling distros (eg: arch, parabola, guix) will normally have newer versions of
build deps than those mozilla used - the build deps may be incompatible for
either reason; though both use-cases are equally common and legitimate - at any
point in time, it is probably not possible to easily compile every release of
any mature software on every distro - generally, upstreams favor LTS distros
in such cases


> the current version of clang/llvm is 18

feel free to ignore the remainder of this message - it is just to unpack
"the current version" as an absolute concept - that requires a relative
qualifier at least - it is important to dispel the "current" qualifier WRT
compilers - it breaks-down to:

* the version of LLVM currently available in repos of rolling distros is v18
* the version of LLVM currently available in repos of LTS distros is v14
* the version of LLVM required by mozilla v115+ is v17+

which suggests the more refined question, to answer "Shouldn't Icecat should be
moving to the 128.x.x branch?":

* which distros should gnuzilla support, given that some distros are often
  or always unable to compile the latest versions of mozilla?

generally, the latest upstream release of any software is _not_ the one which
users should consider as "the current version"; because some releases
(regardless of age) are likely to be be incompatible with the distro - that is
to be expected; and distro packagers always work within that constraint - the
"current version", as it is actually relevant to the distro packager and users,
is the version currently in the distro repos, which is usually _not_ the latest
upstream version - also, some projects maintain multiple "current versions" in
tandem (eg: firefox, linux, ruby, jack); so distro repos may include multiple
versions of the same software, which are all denoted as "current" upstream  -
in other words, "the current version of 'foo'" is not a useful concept for
distribution or for users - that is meaningful to the upstream (bug reporting,
etc) - for each given target OS, the important factor is "the compatible
version of 'foo'" (which versions of 'foo' are compatible with my distro?)

so generally, the latest version upstream is not necessarily the one that any
distro or distro user wants or can make use of - as an extreme example: as
gnuzilla no longer makes releases, the actual "current version" of icecat is
v67 (the last release, from 2019) - in this case, no one wants to use the
actual "current version" of icecat - all users today are running pre-releases;
and that is actually preferable in this rare case

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.