Hello All,
i would be very interested in getting Firefox and Thunderbird (and
possibly Seamonkey, but this isn't available at all with debian it
seam) running, if possible at all for the newer versions.
I would be willing to file error reports and produce gdb output on
crashes, if this would help and someone could direct me to information
on how and where to do it for debian.
I have a few Sparc64 machines (Ultra45, Blade100, Ultra10, T1000,
V120) to test.
What i can get running (but also with errors) are only to following
two versions:
firefox_50.1.0-1_sparc64.deb
thunderbird_52.9.1-1_sparc64.deb
All later packages crash with bus errors.
But as the latest versions for Sparc64 are well behind the releases on
the other architectures, would debian even accept bug reports for
older packages? (eg. firefox-esr 78 x86_64 vs. firefox-esr 60 sparc64)
Rust seems not to be an issue any more for sparc64/linux, but the
general upstream neglect of sparc64 seems to be the major problem.
I would like to hear opinions on how to proceed or if you think this
is a lost cause?
Regards,
Connor
This thread below claims that Big-Endian is dead (2015). It says that IBM changed
their PowerPC's from BE to LE. Also that web developers assume LE.
Adrian explained the problem in Firefox a while ago, it was complex.
The words of Linus:
https://lkml.org/lkml/2015/4/24/606
Linux Plumbers Congress 2020:
https://lwn.net/Articles/829733/
Hello Rick!
On 11/7/21 22:44, rleir@leirtech.com wrote:
This thread below claims that Big-Endian is dead (2015). It says that IBM changed
their PowerPC's from BE to LE. Also that web developers assume LE.
Not sure how your comment is related to the original question but let me just add this:
- IBM's s390x architecture is fully supported and one of IBM's cash cows and it's big-endian
- IBM's AIX operating system which IBM is still actively developing and selling is big-endian
Adrian explained the problem in Firefox a while ago, it was complex.
Not really. Firefox on Solaris/SPARC exists and works. It's not complex, it's just that I am
doing the work here alone. I was planning to write an answer to this mail but I haven't gotten
around to doing that.
The words of Linus:
https://lkml.org/lkml/2015/4/24/606
Linux Plumbers Congress 2020:
https://lwn.net/Articles/829733/
Linus is not the center of the universe.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
The reason that I think PPC is related is that, if it is also BE then PPC users may
have solved some of the compatibility problems that we experience. I realize that
there's a difference in this between PPC and Sparc; but some of the PPC fixes can
at least suggest Sparc fixes as long as they have stayed BE. IBM is putting considerable
effort into this.
https://github.com/oracle/solaris-userland/tree/master/components/desktop/firefox/wrapper-node
I talked with an IBM consultant at the X11 conference in Montreal two years ago. But we didn't
discuss Sparc. And I didn't discuss IBM changing to LE. Is it true?
On 11/8/21 11:07, Rick Leir wrote:
The reason that I think PPC is related is that, if it is also BE thenPPC users may
have solved some of the compatibility problems that we experience. Irealize that
there's a difference in this between PPC and Sparc; but some of thePPC fixes can
at least suggest Sparc fixes as long as they have stayed BE. IBM isputting considerable
effort into this.
The fundamental problem with Firefox and Thunderbird is that building both requires NodeJS.
There is no NodeJS for SPARC which is why you have to compile the
JavaScript sources on a
different architecture and then put them into the SPARC
Firefox/Thunderbird packages, see:
https://github.com/oracle/solaris-userland/tree/master/components/desktop/firefox/wrapper-node
This has got nothing to do with big-endian vs. little-endian.
I talked with an IBM consultant at the X11 conference in Montreal twoyears ago. But we didn't
discuss Sparc. And I didn't discuss IBM changing to LE. Is it true?
IBM is supporting Linux on POWER both big- and little-endian. Their
zSeries mainframes are BE
and so is AIX on POWER.
Big-endian is not going anywhere, doesn't matter what anyone on Phoronix
or the LKML writes.
And it's not related to Firefox or Thunderbird on SPARC as explained above.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Adrian,
thank you for your time. This sounds a bit complicated for the newer versions.
Currently i don't know where to start.
I was trying to build the old firefox52 and thunderbird52 which run on NetBSD/Sparc64 from pkgsrc and manually. The thunderbird52 exists on debian and the firefox package did skip 52 and was only released as a 50 with
error messages filling up the console. I can get them to build with pkgsrc and manually but some patches seem to be missing to avoid bus errors in libxul.so on debian.
Unfortunately i don't know yet how debian builds its own packages and where to find the patches used in those builds, so that i could reproduce the building of firefox50 and thunderbird52 to maybe learn something as a starting point.
Hi Connoer,
On Tue, Nov 09, 2021 at 10:59:47PM +0100, Connor McLaughlan wrote:
Hi Adrian,
thank you for your time. This sounds a bit complicated for the newer versions.
Currently i don't know where to start.debian
I was trying to build the old firefox52 and thunderbird52 which run on NetBSD/Sparc64 from pkgsrc and manually. The thunderbird52 exists on
and the firefox package did skip 52 and was only released as a 50 with error messages filling up the console. I can get them to build withpkgsrc
and manually but some patches seem to be missing to avoid bus errors in libxul.so on debian.
Unfortunately i don't know yet how debian builds its own packages andwhere
to find the patches used in those builds, so that i could reproduce the building of firefox50 and thunderbird52 to maybe learn something as a starting point.
apt-get source <package>
The debian specific stuff is in the debian/ directory, also the debian specific patches.
To get the the dependencies needed for building:
apt-get build-dep <package>
Good luck,
greetings
Hermann
--
Administration/Zentrale Dienste, Interdiziplinaeres
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427
Email: Hermann.Lauer@iwr.uni-heidelberg.de
apt-get source <package>
The debian specific stuff is in the debian/ directory, also the debian specific patches.
To get the the dependencies needed for building:
apt-get build-dep <package>
https://wiki.debian.org/sbuild
https://buildd.debian.org/status/logs.php?pkg=firefox&arch=sparc64
but how would this work for a patch set of a specific old release .deb
where the .deb is only available on snapshot.debian.org <http://snapshot.debian.org>?
I guess i have to then load the specific source package form snapshot manually?
I guess i have to then load the specific source package form snapshot
manually?
Isn't it possible to add a specific snapshot as deb-src to your
sources.list?
Something like this should work:
deb-src https://snapshot.debian.org/archive/debian/<dateandtime>/ sid main
Hello All,
i would be very interested in getting Firefox and Thunderbird (and
possibly Seamonkey, but this isn't available at all with debian it
seam) running, if possible at all for the newer versions.
Rust seems not to be an issue any more for sparc64/linux, but the
general upstream neglect of sparc64 seems to be the major problem.
I would like to hear opinions on how to proceed or if you think this
is a lost cause?
Hi Connor,
you touch a delicate subject. You touch both endianness and SPARC cpu in
On 11/6/21 5:05 PM, Connor McLaughlan wrote:
Hello All,
i would be very interested in getting Firefox and Thunderbird (and
possibly Seamonkey, but this isn't available at all with debian it
seam) running, if possible at all for the newer versions.
yes, SeaMonkey is for me a missed package for both Debian/Devuan and
FreeBSD. I just love it. I like the classic interface and can't stand
the chrome-like of Firefox.
SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It
should be a decent candidate to get it running on SPARC, since a
specific Mac PPC G5 version was maintained for a long time. Current SM
is FF 60 based and so has rust
Rust seems not to be an issue any more for sparc64/linux, but the
general upstream neglect of sparc64 seems to be the major problem.
Rust is evil... however as you write it does not to be the biggest
problem here.
The major issue is endianness - current FireFox runs on PPC64 but is
totally unusable. Everything in the UI has mangled colors, endianness is broken at about every level. E.g. FF relies now a lot on skia and
officially it will never support BE. And so a lot of other issues,
including Mesa.
Add to endianness issues that SPARCs are sensitive to memory alignment
and issues and you get the crashes.
I follow the Big Endian issues closely, since I am interested in getting
a usable browser on PPC, but it is an uphill road. I have been in
contact for a long time with Cameron Kaiser who maintained TenFourFox (winding down activity right this year) and which as an excellent
browser on MacOS PPC. Some of his patches were accepted upstream, but
several not. His browser fork however is heavily MacOS 10.4 optimized
(hence the name).
I am working since a long time on ArcticFox and intend to keep it as
much as possible cross-platform, close to Firefox, but incorporating as
many fixes done for TenFourFox as I can. Currently, it is quite usable
on PPC, although there are endianness issues with image composition operations. I can browser Wikipedia and even watch a youtube video with audio. That is already impossible with standard Firefox.
I would like to hear opinions on how to proceed or if you think this
is a lost cause?
It is not a lost cause, but it is a hard cause, not well supported by upstream. I intend to generalize a lot of TenFourFox patches in
ArcticFox, but it requires work.
NetBSD should have a working FF (I think FF 52) on SPARC.
I was finally able to compile ArcticFox on NetBSD/SPARC64 and
Linux/SPARC64. It will start, show a window but crash very soon. That's already an improvement compared to crashing immediately as it did one
year ago!
For this cause, I need help - I am working alone and I have no real
Gecko knowledge. I need to port patches from Gecko to improve certain
parts, so I need somebody how knows Firefox code more than me to help me understand why certain give issues. Not specific SPARC, but I work
mostly on amd64 and arm64 and then "test" on PPC and SPARC (my netra T1
takes 20 hours to compile ArcticFox....) So if you know somebody who can
help me with some specific issues please ping me. I have some blocking
issues I need to solve so that ArcticFox doesn't die out and can evolve, specifically some JavaScript and JIT issues, currently verified on Intel.
I have the hardware, I can test and often GDB stacktraces are quite meaningless if a debug is not used. I need real "code" help, if you know somebody, please point him.
Riccardo
i would be very interested in getting Firefox and Thunderbird (and possibly >> Seamonkey, but this isn't available at all with debian it seam) running, if >> possible at all for the newer versions.
yes, SeaMonkey is for me a missed package for both Debian/Devuan and FreeBSD. I just love it. I like the classic interface and can't stand the chrome-like of Firefox.
SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. It should be a decent candidate to get it running on SPARC, since a specific Mac PPC G5 version was maintained for a long time. Current SM is FF 60 based and so has rust
Rust seems not to be an issue any more for sparc64/linux, but the general upstream
neglect of sparc64 seems to be the major problem.
Rust is evil... however as you write it does not to be the biggest problem here.
The major issue is endianness - current FireFox runs on PPC64 but is totally unusable.
Everything in the UI has mangled colors, endianness is broken at about every level.
E.g. FF relies now a lot on skia and officially it will never support BE. And so a
lot of other issues, including Mesa.
Add to endianness issues that SPARCs are sensitive to memory alignment and issues and you get the crashes.
I am working since a long time on ArcticFox and intend to keep it as much as possible
cross-platform, close to Firefox, but incorporating as many fixes done for TenFourFox
as I can. Currently, it is quite usable on PPC, although there are endianness issues
with image composition operations. I can browser Wikipedia and even watch a youtube
video with audio. That is already impossible with standard Firefox.
I would like to hear opinions on how to proceed or if you think this is a lost cause?
It is not a lost cause, but it is a hard cause, not well supported by upstream. I intend
to generalize a lot of TenFourFox patches in ArcticFox, but it requires work.
NetBSD should have a working FF (I think FF 52) on SPARC.
I was finally able to compile ArcticFox on NetBSD/SPARC64 and Linux/SPARC64. It will start,
show a window but crash very soon. That's already an improvement compared to crashing immediately
as it did one year ago!
For this cause, I need help - I am working alone and I have no real Gecko knowledge. I need
to port patches from Gecko to improve certain parts, so I need somebody how knows Firefox
code more than me to help me understand why certain give issues. Not specific SPARC, but I
work mostly on amd64 and arm64 and then "test" on PPC and SPARC (my netra T1 takes 20 hours
to compile ArcticFox....) So if you know somebody who can help me with some specific issues
please ping me. I have some blocking issues I need to solve so that ArcticFox doesn't die
out and can evolve, specifically some JavaScript and JIT issues, currently verified on Intel.
Hello!
On 11/14/21 17:58, Riccardo Mottola wrote:
running, ifi would be very interested in getting Firefox and Thunderbird (and possibly
Seamonkey, but this isn't available at all with debian it seam)
possible at all for the newer versions.
yes, SeaMonkey is for me a missed package for both Debian/Devuan andFreeBSD.
I just love it. I like the classic interface and can't stand thechrome-like
of Firefox.
There is currently no one willing to step up being the maintainer of Seamonkey
in Debian which is why it's currently not included.
SeaMonkey up to 2.49 was FF 52 based, so very portable and no rust. Itshould
be a decent candidate to get it running on SPARC, since a specific MacPPC G5
version was maintained for a long time. Current SM is FF 60 based and sohas rust
Rust is available on SPARC and fully supported.
general upstreamRust seems not to be an issue any more for sparc64/linux, but the
neglect of sparc64 seems to be the major problem.
Rust is evil... however as you write it does not to be the biggestproblem here.
Calling Rust "evil" is not a technical argument but an emotional one.
The major issue is endianness - current FireFox runs on PPC64 but istotally unusable.
Everything in the UI has mangled colors, endianness is broken at aboutevery level.
E.g. FF relies now a lot on skia and officially it will never supportBE. And so a
lot of other issues, including Mesa.
As I mentioned before, Oracle officially support Firefox on Solaris on
SPARC and thus
on a big-endian system. Debian ships Firefox on s390x as a supported
package.
Claiming that Firefox is a mess on big-endian is definitely not accurate although
Firefox upstream does not officially support big-endian targets, but they don't
prevent it either.
Add to endianness issues that SPARCs are sensitive to memory alignmentand issues and you get the crashes.
The more Rust code Firefox has, the less likely this is going to happen as Rust is much
stricter with alignment than C/C++.
I am working since a long time on ArcticFox and intend to keep it asmuch as possible
cross-platform, close to Firefox, but incorporating as many fixes donefor TenFourFox
as I can. Currently, it is quite usable on PPC, although there areendianness issues
with image composition operations. I can browser Wikipedia and evenwatch a youtube
video with audio. That is already impossible with standard Firefox.
Well, it's based on an ancient Firefox code base which is why it still has many of the
old bugs that have been fixed in the mean time.
a lost cause?I would like to hear opinions on how to proceed or if you think this is
It is not a lost cause, but it is a hard cause, not well supported byupstream. I intend
to generalize a lot of TenFourFox patches in ArcticFox, but it requireswork.
NetBSD should have a working FF (I think FF 52) on SPARC.
I was finally able to compile ArcticFox on NetBSD/SPARC64 andLinux/SPARC64. It will start,
show a window but crash very soon. That's already an improvementcompared to crashing immediately
as it did one year ago!
We have already had a fully working Rust-based Firefox on SPARC. I don't think it's a good
idea to use these ancient versions, especially since there is no official security support.
For this cause, I need help - I am working alone and I have no realGecko knowledge. I need
to port patches from Gecko to improve certain parts, so I need somebodyhow knows Firefox
code more than me to help me understand why certain give issues. Notspecific SPARC, but I
work mostly on amd64 and arm64 and then "test" on PPC and SPARC (mynetra T1 takes 20 hours
to compile ArcticFox....) So if you know somebody who can help me withsome specific issues
please ping me. I have some blocking issues I need to solve so thatArcticFox doesn't die
out and can evolve, specifically some JavaScript and JIT issues,currently verified on Intel.
It's probably a better idea to start working on separating the Javascript transpilation process
in the Firefox build system from the build process for the native code as this will remove
the NodeJS build dependency for Firefox.
Firefox itself does not require NodeJS. It's just that the Mozilla
developers decided to pull
in NodeJS as a hard dependency for the build so that the Javascript files
are always freshly
transpiled from the source.
However, the transpilation process does not necessarily have to happen on
the same architecture
and one can transpile the Javascript files on x86_64 and copy them into
the Firefox build
tree later. This is what Oracle does on Solaris and we could do the same
on Debian by moving
the transpiled Javascript packages into a firefox-common package which
will be used by the
firefox package on the various architectures.
This way we could use current versions of Firefox and wouldn't be stuck to old and buggy
versions. I have already a concept for the common package, but I didn't
have the time for
turning the concept into code yet.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Mon, Nov 15, 2021 at 1:06 AM John Paul Adrian Glaubitz <<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
did the working rust based firefox make it into a released package?
https://buildd.debian.org
The only packaged version of firefox i could get to run was firefox50.
And i have tested all higher available version of firefox and firefox-esr
on snapshot.debian.org
Hello Connor!
On 11/15/21 01:53, Connor McLaughlan wrote:
did the working rust based firefox make it into a released package?
Yes, as I said in a previous mail, Firefox 60 was successfully built and uploaded.
If you want to see which packages where built, check the build log archive
by opening:
https://buildd.debian.org
then type "firefox" and click "Go".
Look for the row with "sparc64" and click on "old" in the eight column,
there you'll see that the last successfully built package version was "62.0.3-1".
If you now go to snapshot.debian.org and type "firefox" in the source
package
name field and click "Submit", you will get a list of versions, including sparc64. Click it and scroll down to "firefox_62.0.3-1_sparc64.deb" and you get your package.
To install the package directly, add the following line to your
sources.list:
deb [trusted=yes] https://snapshot.debian.org/archive/debian-ports/20181004T035335Z/
unstable main
The only packaged version of firefox i could get to run was firefox50.
And i have tested all higher available version of firefox and firefox-esr on snapshot.debian.org
What problem did you run in to? You need to describe the actual problem so that
I can help you debug it.
Building newer versions should be possible as explained before, but I
haven't had
the time for the NodeJS hack yet.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Type "show configuration" for configuration details.<br>For bug reporting instructions, please see:<br><<a href="https://www.gnu.org/software/gdb/bugs/">https://www.gnu.org/software/gdb/bugs/</a>>.<br>Find the GDB manual and otherdocumentation resources online at:<br> <<a href="http://www.gnu.org/software/gdb/documentation/">http://www.gnu.org/software/gdb/documentation/</a>>.<br><br>For help, type "help".<br>Type "apropos word" to search for
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".<br>[Detaching after fork from child process 4008]<br>[New Thread 0xfff000010e6a3870 (LWP 4009)]<br>[New Thread 0xfff0000111f79870 (LWP 4010)]<br>[Thread0xfff0000111f79870 (LWP 4010) exited]<br>[New Thread 0xfff0000111f79870 (LWP 4011)]<br>[New Thread 0xfff000011277b870 (LWP 4012)]<br>[New Thread 0xfff0000112f7d870 (LWP 4013)]<br>[New Thread 0xfff000011377f870 (LWP 4015)]<br>[New Thread
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 15, 2021 at 10:35 AM John Paul Adrian Glaubitz <<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Connor!<br>
On Mon, Nov 15, 2021 at 5:00 PM Connor McLaughlan <cont6pro3@gmail.com> wrote:
i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error, no window comes up.
gdb output:
connor@SunUltra25:/usr/lib/firefox$ gdb firefox
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
make sure to use recent gdb (11+) or more ancient one (9.x), since
version 10.x is buggy on sparc64
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988711
i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error, no window comes up.
gdb output:
connor@SunUltra25:/usr/lib/firefox$ gdb firefox
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
On Mon, Nov 15, 2021 at 5:10 PM Anatoly Pugachev <matorola@gmail.com>
wrote:
On Mon, Nov 15, 2021 at 5:00 PM Connor McLaughlan <cont6pro3@gmail.com>wrote:
no window comes up.i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error,
gdb output:
connor@SunUltra25:/usr/lib/firefox$ gdb firefox
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
make sure to use recent gdb (11+) or more ancient one (9.x), since
version 10.x is buggy on sparc64
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988711
sorry for misinformation, gdb-10.2.x will work on sparc64, please see https://sourceware.org/bugzilla/show_bug.cgi?id=27147
i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error, no window comes up.
(...)
Thread 1 "firefox" received signal SIGBUS, Bus error.
HashIIDPtrKey (key=0xfff000010a7cfe4c <xpt::detail::sInterfaces+30352>)
at /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp:26 26 /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp: No
such file or directory.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1434726
Hi!
On 11/15/21 15:00, Connor McLaughlan wrote:
i installed firefox_62.0.3-1_sparc64.deb. On start i get a bus error, no window comes up./build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp:26
(...)
Thread 1 "firefox" received signal SIGBUS, Bus error.
HashIIDPtrKey (key=0xfff000010a7cfe4c <xpt::detail::sInterfaces+30352>)
at
26 /build/firefox-YyDH69/firefox-62.0.3/js/xpconnect/src/XPCMaps.cpp: No such file or directory.
That's this bug [1]. It got fixed in Firefox 68. So you need to cherry-pick this patch and rebuild the package as I explained in one of my previous mails.
I can maybe do that later this week if you can't do it yourself.
Adrian
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1434726
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
<div><br></div><div>I tried to follow this page instead to build the package:</div><div><a href="https://wiki.debian.org/BuildingTutorial">https://wiki.debian.org/BuildingTutorial</a></div><div><br></div><div>But i here i am unable to solve the builddependencies for firefox-62.0.3 on my install:</div><div><br></div><div>dpkg-checkbuilddeps: error: Unmet build dependencies: python-minimal (>= 2.6.6-13~) llvm-6.0-dev libclang-6.0-dev clang-6.0</div><div><br></div><div>These are not available from
i have read through the sbuild page and it is very long and looks very complicated and not tailored to a sparc64 machine.
Is really everything on that page needed to get it running?
Hello Anatoly,
i am using the highest available gdb for sparc64: root@SunUltra25:/work/firefox62# aptitude versions gdb
i 10.1-2 unstable 500
Should i use something else?
Hello!
On 11/15/21 23:20, Connor McLaughlan wrote:
i have read through the sbuild page and it is very long and looks very complicated and not tailored to a sparc64 machine.
Is really everything on that page needed to get it running?
No, it's actually very simple and works on any architecture.
As root:
# apt install sbuild devscripts
# sbuild-createchroot unstable /srv/chroot/sid-sparc64-sbuild --alias=sid \
--keyring /usr/share/keyrings/debian-ports-archive-keyring.gpg \
http://ftp.ports.debian.org/debian-ports
# sbuild-adduser $YOURUSER
Then, as your normal user ($YOURUSER):
$ mkdir firefox-build
# cd firefox-build
# dget -u http://snapshot.debian.org/archive/debian/20181003T162948Z/pool/main/f/firefox/firefox_62.0.3-1.dsc
# wget https://bug1434726.bmoattachments.org/attachment.cgi?id=8947275 -O align-fix.diff
# cd firefox-62.0.3
# patch -p1 < ../align-fix.diff
# dpkg-source --commit (enter a desired patch name, then opens an editor; just save and close)
# dch -i 'Add patch to fix alignment on sparc64'
# dch -r ''
# sbuild -d sid --arch=sparc64 --no-arch-all
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
/bin/sh: 1: python: not found<br>/bin/sh: 1: python: not found<br>/bin/sh: 1: python: not found<br>/bin/sh: 1: python: not found<br>/bin/sh: 1: python: not found<br>rm -f debian/firefox-dev.links debian/firefox.1 debian/firefox.NEWS debian/firefox.README.Debian debian/firefox.bug-control debian/firefox.bug-presubj debian/firefox.bug-script debian/firefox.desktop debian/firefox.dirs debian/firefox.install debian/firefox.js debian/firefox.links debian/firefox.lintian-overrides debian/firefox.
<br># wget <a href="https://bug1434726.bmoattachments.org/attachment.cgi?id=8947275" rel="noreferrer" target="_blank">https://bug1434726.bmoattachments.org/attachment.cgi?id=8947275</a> -O align-fix.diff<br>
onnor@SunUltra25:/work/firefox-build/firefox-62.0.3$ sbuild -d sid --arch=sparc64 --no-arch-all
hostname: Name or service not known
/bin/sh: 1: python: not found
Hello Adrian,
sbuild was able to start now.
I am now getting the dependency problem regarding python-minimal here also:
output-version: 1.2
native-architecture: sparc64
report:
-
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: sparc64
status: broken
reasons:
-
missing:
pkg:
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: sparc64
unsat-dependency: python-minimal:sparc64 (>= 2.6.6-13~)
background-packages: 77315
foreground-packages: 1
total-packages: 77316
broken-packages: 1
+------------------------------------------------------------------------------+
| Cleanup
|
+------------------------------------------------------------------------------+
Purging /<<BUILDDIR>>
Not cleaning session: cloned chroot in use
E: Package build dependencies not satisfied; skipping
+------------------------------------------------------------------------------+
| Summary
|
+------------------------------------------------------------------------------+
Build Architecture: sparc64
Build Type: any
Build-Space: n/a
Build-Time: 0
Distribution: sid
Fail-Stage: install-deps
Host Architecture: sparc64
Install-Time: 0
Job: /work/firefox-build/firefox_62.0.3-1.1.dsc
Machine Architecture: sparc64
Package: firefox
Package-Time: 0
Source-Version: 62.0.3-1.1
Space: n/a
Status: given-back
Version: 62.0.3-1.1
--------------------------------------------------------------------------------
Finished at 2021-11-16T16:15:18Z
Build needed 00:00:00, no disk space
E: Package build dependencies not satisfied; skipping connor@SunUltra25:/work/firefox-build/firefox-62.0.3$
On Tue, Nov 16, 2021 at 3:26 PM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:
On 11/16/21 15:22, Connor McLaughlan wrote:
onnor@SunUltra25:/work/firefox-build/firefox-62.0.3$ sbuild -d sid
--arch=sparc64 --no-arch-all
hostname: Name or service not known
/bin/sh: 1: python: not found
As root, change into the chroot and install python-is-python2:
# chroot /srv/chroot/sid-sparc64-sbuild
# apt install python-is-python2
# exit
Then try again.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 11/16/21 15:22, Connor McLaughlan wrote:
onnor@SunUltra25:/work/firefox-build/firefox-62.0.3$ sbuild -d sid --arch=sparc64 --no-arch-all
hostname: Name or service not known
/bin/sh: 1: python: not found
As root, change into the chroot and install python-is-python2:
# chroot /srv/chroot/sid-sparc64-sbuild
# apt install python-is-python2
# exit
Then try again.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
I am now getting the dependency problem regarding python-minimal here also: (...)
unsat-dependency: python-minimal:sparc64 (>= 2.6.6-13~)
Hello!
On 11/16/21 18:23, Connor McLaughlan wrote:> sbuild was able to start now.
I am now getting the dependency problem regarding python-minimal herealso:
(...)
unsat-dependency: python-minimal:sparc64 (>= 2.6.6-13~)
You need to replace "python-minimal" with "python2-minimal" in the Build-Depends
field in debian/control:
$ sed -i 's/python-minimal/python2-minimal/g' debian/control
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
i had also to replace python-minimal in the config.in it seems, otherwise
it would show up again with the original package.
Now it is missing those dependencies:
The following packages have unmet dependencies:
sbuild-build-depends-main-dummy : Depends: llvm-6.0-dev but it is not installable
Depends: libclang-6.0-dev but it is not installable
Depends: clang-6.0 but it is not installable
Hello!
On 11/17/21 00:33, Connor McLaughlan wrote:
i had also to replace python-minimal in the config.in it seems,otherwise
it would show up again with the original package.
Yes, you're right. debian/control is generated from debian/control.in
(not config.in).
Now it is missing those dependencies:
The following packages have unmet dependencies:not
sbuild-build-depends-main-dummy : Depends: llvm-6.0-dev but it is not installable
Depends: libclang-6.0-dev but it is
installable
Depends: clang-6.0 but it is not installable
Try replacing the following in debian/control.in:
llvm-6.0-dev,
libclang-6.0-dev,
clang-6.0,
with:
llvm-11-dev,
libclang-11-dev,
clang-11,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Regards,</div><div>Connor</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 17, 2021 at 2:40 PM John Paul Adrian Glaubitz <<a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
On Nov 18, 2021, at 2:01 AM, Connor McLaughlan <cont6pro3@gmail.com> wrote:
checking for llvm-config... not found
ERROR: Could not find LLVM/Clang installation for compiling stylo build-time bindgen. Please specify the 'LLVM_CONFIG' environment variable (recommended), pass the '--with-libclang-path' and '--with-clang-path' options to configure, or put 'llvm-config' in your PATH. Altering your
PATH may expose 'clang' as well, potentially altering your compiler,
which may not be what you intended.
make[1]: *** [debian/rules:205: stamps/configure-browser] Error 1
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:321: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2
--------------------------------------------------------------------------------
What can i do here?
= 1.5.0), libdbus-glib-1-dev, libffi-dev, libevent-dev (>= 1.4.1), libjsoncpp-dev, libpulse-dev, libasound2-dev, yasm (>= 1.1), rustc (>=1.24), cargo (>= 0.25), llvm-11-dev, libclang-11-dev, clang-11, llvm-11,
On Nov 18, 2021, at 2:01 AM, Connor McLaughlan <cont6pro3@gmail.com>
wrote:
checking for llvm-config... not found
ERROR: Could not find LLVM/Clang installation for compiling stylo
build-time
bindgen. Please specify the 'LLVM_CONFIG' environment variable (recommended), pass the '--with-libclang-path' and '--with-clang-path' options to configure, or put 'llvm-config' in your PATH. Altering your
PATH may expose 'clang' as well, potentially altering your compiler,
which may not be what you intended.
make[1]: *** [debian/rules:205: stamps/configure-browser] Error 1
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:321: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2
--------------------------------------------------------------------------------
What can i do here?
Try adding “llvm” to Build-Depends, see:
https://packages.debian.org/search?searchon=contents&keywords=llvm-config&mode=exactfilename&suite=stable&arch=any
Adrian
Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13, libx11-dev, libx11-xcb-dev, libxt-dev, libgtk-3-dev, libgtk2.0-dev (>=
2.10), libglib2.0-dev (>= 2.16.0), libstartup-notification0-dev,
libjpeg-dev, zlib1g-dev, libreadline-dev, python2.7, python2-minimal (>= 2.6.6-13~), python3, python-ply, dpkg-dev (>= 1.16.1.1~), libnspr4-dev (>= 2:4.19~), libnss3-dev (>= 2:3.38~), libsqlite3-dev (>= 3.24.0), libvpx-dev (>= 1.5.0), libdbus-glib-1-dev, libffi-dev, libevent-dev (>= 1.4.1), libjsoncpp-dev, libpulse-dev, libasound2-dev, yasm (>= 1.1), rustc (>=
1.24), cargo (>= 0.25), llvm-11-dev, libclang-11-dev, clang-11, llvm-11,
zip, unzip, locales, xvfb, xfonts-base, xauth, ttf-bitstream-vera, fonts-freefont-ttf, fonts-dejima-mincho, iso-codes
However this didn't change anything regarding the error...
In file included from /<<PKGBUILDDIR>>/build-browser/js/src/Unified_cpp_js_src26.cpp:20: /<<PKGBUILDDIR>>/js/src/util/NativeStack.cpp:29:1: error: ‘pid_t gettid()’
was declared ‘extern’ and later ‘static’ [-fpermissive]
29 | gettid()
| ^~~~~~
On 11/18/21 13:57, Connor McLaughlan wrote:
Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13, libx11-dev, libx11-xcb-dev, libxt-dev, libgtk-3-dev, libgtk2.0-dev (>= 2.10), libglib2.0-dev (>= 2.16.0), libstartup-notification0-dev, libjpeg-dev, zlib1g-dev, libreadline-dev, python2.7, python2-minimal (>= 2.6.6-13~), python3, python-ply, dpkg-dev (>= 1.16.1.1~), libnspr4-devlibvpx-dev
=
2:4.19~), libnss3-dev (>= 2:3.38~), libsqlite3-dev (>= 3.24.0),
= 1.5.0), libdbus-glib-1-dev, libffi-dev, libevent-dev (>= 1.4.1), libjsoncpp-dev, libpulse-dev, libasound2-dev, yasm (>= 1.1), rustc (>= 1.24), cargo (>= 0.25), llvm-11-dev, libclang-11-dev, clang-11, llvm-11, zip, unzip, locales, xvfb, xfonts-base, xauth, ttf-bitstream-vera, fonts-freefont-ttf, fonts-dejima-mincho, iso-codes
However this didn't change anything regarding the error...
Did you add "llvm"? Not "llvm-11".
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hello!
On 11/18/21 19:48, Connor McLaughlan wrote:
In file included from /<<PKGBUILDDIR>>/build-browser/js/src/Unified_cpp_js_src26.cpp:20: /<<PKGBUILDDIR>>/js/src/util/NativeStack.cpp:29:1: error: ‘pid_tgettid()’
was declared ‘extern’ and later ‘static’ [-fpermissive]
29 | gettid()
| ^~~~~~
Try building with "--disable-warnings-as-errors":
--- debian/rules.orig 2018-10-03 09:18:06.000000000 +0200
+++ debian/rules 2021-11-18 19:57:12.041480785 +0100
@@ -87,6 +87,8 @@
AUTOCONF_DIRS := build/autoconf
+CONFIGURE_FLAGS += --disable-warnings-as-errors
+
ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
CONFIGURE_FLAGS += --disable-optimize
endif
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
<br></div><div>Regards,</div><div>Connor<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 18, 2021 at 7:57 PM John Paul Adrian Glaubitz <<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to debian/rules didn't remove the error.
Should i try to add -fpermissive to the CFLAGS?
[1] https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html#step-maintainer
On Fri, Nov 19, 2021 at 3:26 PM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:
On 11/19/21 01:14, Connor McLaughlan wrote:By adding -fpermissive to the CFLAGS the build process went further.
adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to debian/rules >> > didn't remove the error.
Should i try to add -fpermissive to the CFLAGS?
Yes, you can try this. But make sure you add it with "+=" to not overwrite >> the other CFLAGS/CXXFLAGS.
You can also use DEB_CXXFLAGS_MAINT_APPEND, see [1].
Now it is stuck at a rustc compile error:
Compiling url v1.7.0
error[E0713]: borrow may still be in use when destructor runs
--> /<<PKGBUILDDIR>>/third_party/rust/url/src/form_urlencoded.rs:261:40
|
259 | impl<'a> Target for ::UrlQuery<'a> {
| -- lifetime `'a` defined here
260 | fn as_mut_string(&mut self) -> &mut String { &mut self.url.serialization }
261 | fn finish(self) -> &'a mut ::Url { self.url }
| ^^^^^^^^ - here, drop of
`self` needs exclusive access to `*self.url`, because the type
`UrlQuery<'_>` implements the `Drop` trait
| |
| returning this value requires that `*self.url` is borrowed for `'a`
For more information about this error, try `rustc --explain E0713`.
error: could not compile `url` due to previous error
make[5]: *** [/<<PKGBUILDDIR>>/config/rules.mk:951: force-cargo-library-build] Error 101
make[5]: Leaving directory '/<<PKGBUILDDIR>>/build-browser/toolkit/library/rust'
make[4]: *** [/<<PKGBUILDDIR>>/config/recurse.mk:74: toolkit/library/rust/target] Error 2
make[4]: Leaving directory '/<<PKGBUILDDIR>>/build-browser'
make[3]: *** [/<<PKGBUILDDIR>>/config/recurse.mk:34: compile] Error 2 make[3]: Leaving directory '/<<PKGBUILDDIR>>/build-browser'
make[2]: *** [/<<PKGBUILDDIR>>/config/rules.mk:418: default] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>/build-browser'
dh_auto_build: error: cd build-browser && make -j1 LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit code
2
make[1]: *** [debian/rules:218: stamps/build-browser] Error 25
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:323: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2
--------------------------------------------------------------------------------
Build finished at 2021-11-19T16:01:50Z
Regards,
Connor
On 11/19/21 01:14, Connor McLaughlan wrote:<br>> adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to debian/rules<br>
On 11/19/21 01:14, Connor McLaughlan wrote:
adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to debian/rules didn't remove the error.
Should i try to add -fpermissive to the CFLAGS?
Yes, you can try this. But make sure you add it with "+=" to not overwrite the other CFLAGS/CXXFLAGS.
You can also use DEB_CXXFLAGS_MAINT_APPEND, see [1].
On Fri, Nov 19, 2021 at 5:21 PM Connor McLaughlan <cont6pro3@gmail.com> wrote:
It seems the cause is that rust compiler has changed behavior and so the
On Fri, Nov 19, 2021 at 3:26 PM John Paul Adrian Glaubitz <
glaubitz@physik.fu-berlin.de> wrote:
On 11/19/21 01:14, Connor McLaughlan wrote:By adding -fpermissive to the CFLAGS the build process went further.
adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" todebian/rules
didn't remove the error.
Should i try to add -fpermissive to the CFLAGS?
Yes, you can try this. But make sure you add it with "+=" to not
overwrite
the other CFLAGS/CXXFLAGS.
You can also use DEB_CXXFLAGS_MAINT_APPEND, see [1].
Now it is stuck at a rustc compile error:
Compiling url v1.7.0
error[E0713]: borrow may still be in use when destructor runs
--> /<<PKGBUILDDIR>>/third_party/rust/url/src/form_urlencoded.rs:261
:40
|
259 | impl<'a> Target for ::UrlQuery<'a> {
| -- lifetime `'a` defined here
260 | fn as_mut_string(&mut self) -> &mut String { &mut
self.url.serialization }
261 | fn finish(self) -> &'a mut ::Url { self.url }
| ^^^^^^^^ - here, drop of
`self` needs exclusive access to `*self.url`, because the type
`UrlQuery<'_>` implements the `Drop` trait
| |
| returning this value
requires that `*self.url` is borrowed for `'a`
For more information about this error, try `rustc --explain E0713`.
error: could not compile `url` due to previous error
make[5]: *** [/<<PKGBUILDDIR>>/config/rules.mk:951:
force-cargo-library-build] Error 101
make[5]: Leaving directory
'/<<PKGBUILDDIR>>/build-browser/toolkit/library/rust'
make[4]: *** [/<<PKGBUILDDIR>>/config/recurse.mk:74:
toolkit/library/rust/target] Error 2
make[4]: Leaving directory '/<<PKGBUILDDIR>>/build-browser'
make[3]: *** [/<<PKGBUILDDIR>>/config/recurse.mk:34: compile] Error 2
make[3]: Leaving directory '/<<PKGBUILDDIR>>/build-browser'
make[2]: *** [/<<PKGBUILDDIR>>/config/rules.mk:418: default] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>/build-browser'
dh_auto_build: error: cd build-browser && make -j1
LD_LIBS=-Wl,--no-gc-sections _LEAKTEST_FILES=leaktest.py returned exit code >> 2
make[1]: *** [debian/rules:218: stamps/build-browser] Error 25
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:323: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned
exit status 2
--------------------------------------------------------------------------------
Build finished at 2021-11-19T16:01:50Z
Regards,
Connor
url v1.7.0 needs an update.
But i don't know where to take it from and how to apply it...
Regards,
Connor
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/19/21 01:14, Connor McLaughlan wrote:<br>> adding "CONFIGURE_FLAGS += --disable-warnings-as-errors" to debian/rules<br>
<div>Regards,</div><div>Connor<br> </div></div></div>
Now it is stuck at a rustc compile error:
Compiling url v1.7.0
error[E0713]: borrow may still be in use when destructor runs
--> /<<PKGBUILDDIR>>/third_party/rust/url/src/form_urlencoded.rs:261:40
[1] https://snapshot.debian.org/package/rustc/1.29.0%2Bdfsg1-1/
On 11/19/21 17:21, Connor McLaughlan wrote:
Now it is stuck at a rustc compile error:
Compiling url v1.7.0:40
error[E0713]: borrow may still be in use when destructor runs
--> /<<PKGBUILDDIR>>/third_party/rust/url/src/form_urlencoded.rs:261
I would suggest downloading and installing rustc 1.29 from snapshots [1] which
should be easier than starting to update the individual Rust components of the
Firefox sources.
Adrian
[1] https://snapshot.debian.org/package/rustc/1.29.0%2Bdfsg1-1/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
<div>Selecting previously unselected package libstd-rust-1.56:sparc64.<br>Preparing to unpack .../12-libstd-rust-1.56_1.56.0+dfsg1-2_sparc64.deb ...<br>Unpacking libstd-rust-1.56:sparc64 (1.56.0+dfsg1-2) ...<br>Preparing to unpack .../13-rustc_1.56.0+dfsg1-2_sparc64.deb ...<br>Unpacking rustc (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...<br>Preparing to unpack .../14-libstd-rust-dev_1.56.0+dfsg1-2_sparc64.deb ...<br>Unpacking libstd-rust-dev:sparc64 (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...</div><div><
</div><div>How do i prevent it?</div><div><br></div><div>Do i need to modify <a href="http://control.in">control.in</a> and set it to 1.29 exactly:</div><div><br></div><div>rustc (>= 1.24) -> rustc (= 1.29)</div><div><br></div><div><br></div><
Regards,</div><div>Connor<br></div></div></div>
However when i execute sbuild, 1.29 gets replaced with 1.56 automatically:
Selecting previously unselected package libstd-rust-1.56:sparc64.
Preparing to unpack .../12-libstd-rust-1.56_1.56.0+dfsg1-2_sparc64.deb ... Unpacking libstd-rust-1.56:sparc64 (1.56.0+dfsg1-2) ...
Preparing to unpack .../13-rustc_1.56.0+dfsg1-2_sparc64.deb ...
Unpacking rustc (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...
Preparing to unpack .../14-libstd-rust-dev_1.56.0+dfsg1-2_sparc64.deb ... Unpacking libstd-rust-dev:sparc64 (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...
How do i prevent it?
Do i need to modify control.in and set it to 1.29 exactly:
rustc (>= 1.24) -> rustc (= 1.29)
On 11/20/21 21:34, Connor McLaughlan wrote:
However when i execute sbuild, 1.29 gets replaced with 1.56automatically:
Selecting previously unselected package libstd-rust-1.56:sparc64....
Preparing to unpack .../12-libstd-rust-1.56_1.56.0+dfsg1-2_sparc64.deb
Unpacking libstd-rust-1.56:sparc64 (1.56.0+dfsg1-2) ......
Preparing to unpack .../13-rustc_1.56.0+dfsg1-2_sparc64.deb ...
Unpacking rustc (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1) ...
Preparing to unpack .../14-libstd-rust-dev_1.56.0+dfsg1-2_sparc64.deb ... Unpacking libstd-rust-dev:sparc64 (1.56.0+dfsg1-2) over (1.29.0+dfsg1-1)
How do i prevent it?
Do i need to modify control.in and set it to 1.29 exactly:
rustc (>= 1.24) -> rustc (= 1.29)
Run sbuild with "--no-apt-upgrade --no-apt-distupgrade".
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/20/21 21:34, Connor McLaughlan wrote:<br>> However when i execute sbuild, 1.29 gets replaced with 1.56 automatically:<br>
Compiling unicode-xid v0.1.0
error: Unrecognized option: 'json'
error: could not compile `unicode-xid`
http://snapshot.debian.org/package/cargo/0.29.0-1/#cargo_0.29.0-1
Hello!
On 11/21/21 04:17, Connor McLaughlan wrote:
Compiling unicode-xid v0.1.0
error: Unrecognized option: 'json'
error: could not compile `unicode-xid`
You need to downgrade cargo to 0.29.0-1:
http://snapshot.debian.org/package/cargo/0.29.0-1/#cargo_0.29.0-1
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
53: 0xfff000010058187b - std::rt::lang_start_internal::h5b2959a2ae66034e<br> 54: 0x10000000d27 - <unknown><br> 55: 0xfff000010076312f - __libc_start_main<br> 56: 0x10000000b2b - <unknown><br>query stack duringpanic:<br>#0 [symbol_name] computing the symbol for `<unix::rusage as std::clone::Clone>::clone`<br>#1 [collect_and_partition_mono_items] collect_and_partition_mono_items<br>end of query stack<br><br>error: internal compiler error: unexpected panic<
<br>note: the compiler unexpectedly panicked. this is a bug.<br><br>note: we would appreciate a bug report: <a href="https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports">https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports</a><br><br>note: rustc 1.29.0 running on sparc64-unknown-linux-gnu<br><br>note: compiler flags: -C opt-level=2 -C codegen-units=1 -C linker=/<<PKGBUILDDIR>>/build/cargo-linker --crate-type lib<br><br>note: some of the compiler
Now it compiles unicode-xid v.0.1.0, but crashes at libc v0.2.39:
make[5]: Entering directory
Should i go up or down with the rustc version?
Or is there another way to fix it?
On 11/21/21 22:37, Connor McLaughlan wrote:
Now it compiles unicode-xid v.0.1.0, but crashes at libc v0.2.39:
make[5]: Entering directory
Try building with a slightly newer rustc version or use LLVM-6.0 instead
as originally intended.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/21/21 22:37, Connor McLaughlan wrote:<br>> Now it compiles unicode-xid v.0.1.0, but crashes at libc v0.2.39:<br>
<div> Compiling style_traits v0.0.1 (/<<PKGBUILDDIR>>/servo/components/style_traits)<br>error: missing documentation for macro<br> --> servo/components/style_traits/values.rs:142:1<br> |<br>142 | macro_rules! serialize_function {<br> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br> |<br>note: lint level defined here<br> --> servo/components/style_traits/lib.rs:12:22<br> |<br>12 | #![deny(unsafe_code, missing_docs)]<br> |
Hi!
On 11/23/21 22:34, Connor McLaughlan wrote:
Should i go up or down with the rustc version?
You need to go down since you need a Rust version that is less strict
with macros.
Or is there another way to fix it?
As I said, the best way is to work on the NodeJS workaround that the
Solaris
developers are using. I might write something down for that tomorrow and
then
you can try whether you can get it working.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Conner!
On 11/30/21 23:19, Connor McLaughlan wrote:
For the last error, i applied a quick and dirty fix i found here - for compiling problems with nss 3.66:
https://bugs.archlinux.org/task/71113
Sorry for not being able to respond the past days, I was busy with other software issues, both in Debian and my dayjob. I will start looking into
this later this week.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
For the last error, i applied a quick and dirty fix i found here - for compiling problems with nss 3.66:
https://bugs.archlinux.org/task/71113
Hello Adrian,
update on the current progress:
rustc_1.30.0, rustc_1.31.0 and rustc_1.32.0 are crashing on my machine
during configure or later during rust building.
rustc_1.33.0 and rustc_1.35.0 seem to work, so when went with
rustc_1.35.0, since rustc_1.33.0 has the same constraints with missing_docs in place.
llvm stayed at 11 for now.
As stated above i removed #![deny(missing_docs)] from servo/components/style/lib.rs and servo/components/style_traits/lib.rs
The rust part compiled without errors it seems (unsure if a second rust
part is coming later in the build).
Now after 14 hours of compile time the errors below will appear.
Have to search if there is a known solution.
However this is now getting somewhat tedious as it seems that i can not
just apply a change and test it by continuing the build.
sbuild will always start the building from scratch.
Is there a way around restarting the whole build?
Regards,
Connor
<div><br></div><div>However this is now getting somewhat tedious as it seems that i can not just apply a change and test it by continuing the build.</div><div>sbuild will always start the building from scratch.</div><div><br></div><div>Is there a wayaround restarting the whole build?</div><div><br></div><div>Regards,</div><div>Connor</div></div><div><br></div><br><div></div></div></div></blockquote><div><br></div><div>For the last error, i applied a quick and dirty fix i found here - for compiling
+------------------------------------------------------------------------------+<br>| Summary |<br>+------------------------------------------------------------------------------+<br><br>Build Architecture: sparc64<br>Build Type: any<br>Build-Space: 8376604<br>Build-Time: 69453<br>Distribution: sid<br>Fail-Stage: build<br>Host Architecture: sparc64<br>Install-Time: 538<br>Job: /work/firefox-build/
Since i am using gcc-10 for this build, i wonder if it is the same problem and could be fixed by adding - where applicable:
#include <limits>
Or is it advised to install a lower gcc for the build? If so, which one?
On 11/30/21 23:30, Connor McLaughlan wrote:
Since i am using gcc-10 for this build, i wonder if it is the sameproblem
and could be fixed by adding - where applicable:
#include <limits>
Yes, that sounds reasonable. Just try it.
Or is it advised to install a lower gcc for the build? If so, which one?
No, that's too much of a hassle. I would advise against that.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/30/21 23:30, Connor McLaughlan wrote:<br>> Since i am using gcc-10 for this build, i wonder if it is the same problem<br>
Hi,
commenting to this topic. I was able to first fix and then upgrade my faitfhul Ultra 2 (*). Equipped now with 2x 396 MHz processors and 1GB of
RAM, running NetBSD 9 I could for the first time "dare" to install firefox
52 esr, with all the patches done for it by Martin. I am quite impressed:
it has no immediately apparent Endianness issues and is capable of browsing without crashing, even performance is acceptable, although of course JS itself is slow. I cannot fully assert speed, since current versions of Xorg are quite slow on the Creator card, as if it running without even 2D acceleration (moving and scrolling is bad, but even with xterm). Images, fonts, interface all display fine. The only broken thing are image operations, but this is a long-standing issue that affects also ArcticFox.
So all-in-all that FF version is more modern than AF39 and has no more
issue (compared to non-patched official releases).
I did not find any rust-basef FFs in NetBSD packages, so I couldn't
compare.
Riccardo
<div><br></div><div>Linux runs more software but is generally less stable for me than NetBSD on my machines. I have very strange issues with filesystems where checking them will occasionally destroy critical parts of the filesystems. I fixed it itsomewhat by using xfs and booting up with read-only filesystems. Then i execute a few runs of xfs_repair -n on them until i get a stable result. Then i can remount to rw and use the systems. Pretty annoying but works reliably.</div><div>Another problem
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 45:28:57 |
| Calls: | 6,648 |
| Files: | 12,197 |
| Messages: | 5,329,774 |