Repositories for supported Debian, Raspbian, and Ubuntu releases

Users and developers helping users with generic and technical Pale Moon issues on all operating systems.

Moderator: trava90

Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
User avatar
stevepusser
Project Contributor
Project Contributor
Posts: 827
Joined: 2015-08-01, 18:33
Location: California

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by stevepusser » 2022-07-09, 18:01

I'm currently working on 31.1.1, but a little late because I was hit by a pretty bad 48-hr stomach flu on Thursday morning. First i386 and amd64 builds should be appearing on the OBS in a few hours.
Avatar is my photo of a female coyote that is still in my neighborhood as of Sept 2022.
They know me, so I'm able to approach and get some nice photos. So far, they still
are quite afraid of other people and their kids, even after five years.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 32656
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by Moonchild » 2022-07-09, 19:41

Off-topic:
stevepusser wrote:
2022-07-09, 18:01
I was hit by a pretty bad 48-hr stomach flu on Thursday morning.
Oof! I hope you are feeling better and/or get well soon, Steve!
"The best revenge is to not be like the person who wronged you." -- Marcus Aurelius
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb

User avatar
stevepusser
Project Contributor
Project Contributor
Posts: 827
Joined: 2015-08-01, 18:33
Location: California

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by stevepusser » 2022-08-03, 01:20

64 and 32-bit x86 builds of 31.2.0 are finishing up on the OBS, as well as arm64 (aarm64).

There appears to be a problem with the armhf (armv71) builds there, however. They are failing with a flurry of errors which are variations on one like this:

Code: Select all

error: inlining failed in call to always_inline 'vpadd_u8': target specific option mismatch
here's a zip of one of build logs; the errors start at 7304s.

https://drive.google.com/file/d/1no1oTC ... sp=sharing
Avatar is my photo of a female coyote that is still in my neighborhood as of Sept 2022.
They know me, so I'm able to approach and get some nice photos. So far, they still
are quite afraid of other people and their kids, even after five years.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 32656
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by Moonchild » 2022-08-03, 04:59

stevepusser wrote:
2022-08-03, 01:20
There appears to be a problem with the armhf (armv71) builds there, however.
Looks like a cross-compile issue. Apparently, gcc only allows SIMD intrinsics to be used for instruction sets that are enabled for the compiler to use. i.e. it needs specific simd compiler flags to be passed to gcc for it to allow the use of those intrinsics in code, regardless if you provide the correct headers. That seems like a terrible oversight on gcc's part to me :/
Unfortunately I don't have a quick solution there but I'm guessing the build needs to be given specific -m flags on the erroring ARM Neon source code to work (e.g. -mavx or -msse4.1).

EDIT: a quick search gave a hint, maybe you need to specify -mfpu=neon in your config?
"The best revenge is to not be like the person who wronged you." -- Marcus Aurelius
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb

User avatar
stevepusser
Project Contributor
Project Contributor
Posts: 827
Joined: 2015-08-01, 18:33
Location: California

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by stevepusser » 2022-08-03, 19:02

Moonchild wrote:
2022-08-03, 04:59
stevepusser wrote:
2022-08-03, 01:20
There appears to be a problem with the armhf (armv71) builds there, however.
Looks like a cross-compile issue. Apparently, gcc only allows SIMD intrinsics to be used for instruction sets that are enabled for the compiler to use. i.e. it needs specific simd compiler flags to be passed to gcc for it to allow the use of those intrinsics in code, regardless if you provide the correct headers. That seems like a terrible oversight on gcc's part to me :/
Unfortunately I don't have a quick solution there but I'm guessing the build needs to be given specific -m flags on the erroring ARM Neon source code to work (e.g. -mavx or -msse4.1).

EDIT: a quick search gave a hint, maybe you need to specify -mfpu=neon in your config?
OK, I assume that will go with the rest of any gcc flags in the mozconfig file.

I'll run a test build as a separate package, but it takes many hours to finish. A build error after 7400 seconds on the armhf emulated machine is still near the start of the build, but at least I can see if it gets past that error this afternoon.
Avatar is my photo of a female coyote that is still in my neighborhood as of Sept 2022.
They know me, so I'm able to approach and get some nice photos. So far, they still
are quite afraid of other people and their kids, even after five years.

User avatar
stevepusser
Project Contributor
Project Contributor
Posts: 827
Joined: 2015-08-01, 18:33
Location: California

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by stevepusser » 2022-08-03, 20:12

The test OBS build/gcc rejected this syntax in the mozconfig:

Code: Select all

ac_add_options --enable-optimize="-O2 -Wl -mfpu=neon,--no-keep-memory,--reduce-memory-overhead"
Assume I don't know anything about the syntax, because I don't. :? How is it supposed to read?

With 31.2.0, I also enabled av1 in the mozconfig per the packager's page example, since I don't have to worry about the problems it had with older gcc versions any longer. I'm running another test build with that disabled for armhf, just in case that caused the problems.
Avatar is my photo of a female coyote that is still in my neighborhood as of Sept 2022.
They know me, so I'm able to approach and get some nice photos. So far, they still
are quite afraid of other people and their kids, even after five years.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 32656
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by Moonchild » 2022-08-03, 20:26

--enable-optimize will be literally passed to gcc. I don't think using commas in there is right but I simply don't know enough about the gcc CLI to help you.
I'm assuming space-separated options is what you'd need?

Code: Select all

ac_add_options --enable-optimize="-O2 -Wl -mfpu=neon --no-keep-memory --reduce-memory-overhead"
"The best revenge is to not be like the person who wronged you." -- Marcus Aurelius
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb

User avatar
stevepusser
Project Contributor
Project Contributor
Posts: 827
Joined: 2015-08-01, 18:33
Location: California

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by stevepusser » 2022-08-03, 23:41

The comma-separated options is what I had in there before to reduce the memory consumption on 32-bit builds during the final libxul linking, since that was limited to 4 GB, along with the quotes around the whole schmeer. They did work, I just tried guessing where to add the extra flag. I do remember someone writing a while back that future releases shouldn't eat up as much RAM during linking, but don't know if we are there yet.

I did find this additional thing to worry about in the "gcc ARM flags":
If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations are not generated by GCC’s auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.
Avatar is my photo of a female coyote that is still in my neighborhood as of Sept 2022.
They know me, so I'm able to approach and get some nice photos. So far, they still
are quite afraid of other people and their kids, even after five years.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 32656
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by Moonchild » 2022-08-04, 07:28

stevepusser wrote:
2022-08-03, 23:41
the use of NEON instructions may lead to a loss of precision.
Can't really help you there, nor do I know in what way that would impact Pale Moon (or if it's significant for a browser? We're not making scientific applications here...)
Also it seems to that gcc will simply skip one compiler optimization if using Neon and use FP emulation for it. So trading off some performance for accuracy. At least that's what I read there.
"The best revenge is to not be like the person who wronged you." -- Marcus Aurelius
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb

User avatar
stevepusser
Project Contributor
Project Contributor
Posts: 827
Joined: 2015-08-01, 18:33
Location: California

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by stevepusser » 2022-08-04, 21:17

OK, I found out how to pass those gcc flags from the debian/rules file, and also how to have those particular flags only passed on autodetected armhf builds, so here's the complete set of flags in the ongoing test build on the OBS. Debian's debhelper automatically adds flags, which is probably why there are so many:

Code: Select all

BUILD=. -fstack-protector-strong -Wformat -Werror=format-security -mfpu=neon -funsafe-math-optimizations -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pipe -pthread  -g -O2 -Wl,--no-keep-memory,--reduce-memory-overhead -fomit-frame-pointer  -Wno-error=shadow 
The -Wl,--no-keep-memory,--reduce-memory-overhead flags are to reduce memory use during linking after the compile is finished...
Avatar is my photo of a female coyote that is still in my neighborhood as of Sept 2022.
They know me, so I'm able to approach and get some nice photos. So far, they still
are quite afraid of other people and their kids, even after five years.

User avatar
stevepusser
Project Contributor
Project Contributor
Posts: 827
Joined: 2015-08-01, 18:33
Location: California

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by stevepusser » 2022-08-05, 20:07

armhf builds succeeded for Debian 10, 11, Ubuntu 20.04, 21.10, and 22.04. Failed: Raspian 10, 11, and Debian testing and Sid. All managed to get through the actual compile--the ones that failed died during the final linking when ld threw out errors about "undefined references to blah blah blah".

What's annoying is that Raspian 10 and 11 are supposed to be equivalent to Debian 10 and 11, so I would expect those builds to also succeed. As a workaround, Raspian users can use the matching successful Debian armhf repo.

I'd try building the Debian testing and Sid versions on gcc-10 instead of 11 to see if that helps, except Ubuntu builds fine with gcc-11. :wtf:
Avatar is my photo of a female coyote that is still in my neighborhood as of Sept 2022.
They know me, so I'm able to approach and get some nice photos. So far, they still
are quite afraid of other people and their kids, even after five years.

User avatar
FranklinDM
Add-ons Team
Add-ons Team
Posts: 405
Joined: 2017-01-14, 02:40
Location: Manila, Philippines
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by FranklinDM » 2022-08-06, 03:28

stevepusser wrote:
2022-08-05, 20:07
the ones that failed died during the final linking when ld threw out errors about "undefined references to blah blah blah".
Off-topic:
Oddly enough, I'm currently encountering a similar issue on gcc-11 after updating to Ubuntu 22.04. This wasn't the case back in u20.04 as I was able to build and run without any problems there. I've tried gcc-10 and it threw a warning at the same point as well, with the following message:

Code: Select all

/usr/bin/ld: warning: ../../../../platform/toolkit/library/StaticXULComponents.ld contains output sections; did you forget -T?
This was on the master branch, which is why I doubt that the changes in my own dev branch caused this. The resulting binaries crashed immediately, so I'm now rebuilding with the recommended gcc-9 version. It does take an hour or so to complete, but I'm hoping that it will compile just fine now (fingers crossed).

Another thing is I'm not entirely sure if I'm doing it right in specifying the GCC version to be used. I added the following to my mozconfig:

Code: Select all

export CC=gcc-9
export CXX=g++-9
export CPP=cpp-9
export LD=gcc-9

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 845
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by athenian200 » 2022-08-06, 04:41

FranklinDM wrote:
2022-08-06, 03:28
Off-topic:
Oddly enough, I'm currently encountering a similar issue on gcc-11 after updating to Ubuntu 22.04. This wasn't the case back in u20.04 as I was able to build and run without any problems there. I've tried gcc-10 and it threw a warning at the same point as well, with the following message:

Code: Select all

/usr/bin/ld: warning: ../../../../platform/toolkit/library/StaticXULComponents.ld contains output sections; did you forget -T?
I've produced successful builds on newer Linux that all throw that warning during the build. I also know why it is produced (it's supposed to contain those), so that shouldn't be a major issue.

export CC=gcc-9
export CXX=g++-9
These two lines seem correct, but..
export CPP=cpp-9
export LD=gcc-9
These two, do not seem right. "CPP" is not a separate thing as far as I know. And LD is a separate program from GCC. The two main linkers that get used on Linux are gold and and bfd, and some also use the lld linker from LLVM. Some newer distros make "gold" the default ld, and put bfd under ld.bfd.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
jobbautista9
Astronaut
Astronaut
Posts: 533
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by jobbautista9 » 2022-08-06, 04:41

Hmm, that's interesting. I also did gcc-11, as well as gcc-12, and while they both gave me the same warning at the linking of libxul, I didn't get any crashes on runtime. I'm on the testing branch of Devuan GNU/Linux. I also only export CC and CXX, so the CPP and LD exports might cause issues for you.
smug mima

Developer of Ambassador in Window Menu, BrowserTickTock, CacheSwitch, Chrome Navigator, Cite4Wiki, Clickity Touch 'n Push, ColorPili, EditDatContent, EditDatTitle, Esrever, Go Menu, User Agent Status, Website Navigation Bar, and Yet Another about:config Helper.

My PGP public key (My copy on rw.rs)

I don't know who made this Touhou avatar. I found this in Danbooru.

User avatar
FranklinDM
Add-ons Team
Add-ons Team
Posts: 405
Joined: 2017-01-14, 02:40
Location: Manila, Philippines
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by FranklinDM » 2022-08-06, 05:25

I've removed the CPP and LD exports from my mozconfig, re-cloned the UXP and Epyrus repositories, and am now building again. If the resulting binaries still crash, I think I'll just have to reinstall Ubuntu from scratch and perhaps try out CentOS 7 as well, while I'm at it.

User avatar
athenian200
Contributing developer
Contributing developer
Posts: 845
Joined: 2018-10-28, 19:56
Location: Georgia
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by athenian200 » 2022-08-06, 05:42

FranklinDM wrote:
2022-08-06, 05:25
I've removed the CPP and LD exports from my mozconfig, re-cloned the UXP and Epyrus repositories, and am now building again. If the resulting binaries still crash, I think I'll just have to reinstall Ubuntu from scratch and perhaps try out CentOS 7 as well, while I'm at it.
I'm in the process of setting up an Ubuntu 22.04 test machine and seeing if UXP builds/runs at all on that OS. If it does, then perhaps a reinstall might be in order. But if not, then it probably wouldn't help.

EDIT: The build was successful with GCC 11 and default linker settings for me.

Just to rule something out... do the official binaries of Pale Moon or Epyrus work for you on there, or is it just your builds that crash instantly on newer Ubuntu? I remember some reports that our builds don't work out of the box on there for people with certain video card drivers, and it was after they updated that they started running into this problem. So this might not be a development issue at all.
"There are two sentences inscribed upon the Ancient oracle... 'Know thyself' and 'Nothing too much'; and upon these all other precepts depend." -- Plutarch

User avatar
FranklinDM
Add-ons Team
Add-ons Team
Posts: 405
Joined: 2017-01-14, 02:40
Location: Manila, Philippines
Contact:

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by FranklinDM » 2022-08-06, 07:07

athenian200 wrote:
2022-08-06, 05:42
Just to rule something out... do the official binaries of Pale Moon or Epyrus work for you on there, or is it just your builds that crash instantly on newer Ubuntu?
Yes, official binaries for both applications work (I'm currently using stevepusser's GTK2 build to write this post), including those that I've built in the older Ubuntu 20.04. I've been able to compile and it doesn't crash anymore - however, no window shows up and top says that it's eating ~15% CPU in the background doing nothing. The console messages after executing mach run doesn't provide anything useful:

Code: Select all

frank@frank:/projects/uxp/epyrus$ ./mach run
 0:00.55 /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/epyrus -no-remote -profile /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/tmp/scratch_user
[calBackendLoader] Using Thunderbird's builtin libical backend
I'll just go ahead and reinstall the OS, I'm guessing something went wrong during the upgrade process.

GDB backtrace:

Code: Select all

(gdb) bt
#0  0x00007f6d0917fb55 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#1  0x00007f6d0aa9f9c9 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#2  0x00007f6d0aa9fe3a in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#3  0x00007f6d0aa917a7 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#4  0x00007f6d0aabca75 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#5  0x00007f6d0aad051b in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#6  0x00007f6d0aac5242 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#7  0x00007f6d0aad051b in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#8  0x00007f6d0ab07bea in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#9  0x00007f6d0ab11e7d in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#10 0x00007f6d0ab12fa2 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#11 0x00007f6d0aad0cc8 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#12 0x00007f6d0ab9d7e3 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#13 0x00007f6d0aa74b76 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#14 0x00007f6d0aa784cc in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#15 0x00007f6d0aa78107 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#16 0x00007f6d0aa8e04c in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#17 0x00007f6d0aa8e4f8 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#18 0x00007f6d0aa8e654 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#19 0x00007f6d0aa80e0f in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#20 0x00007f6d089a96fe in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#21 0x00007f6d089cff3c in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#22 0x00007f6d08d4daca in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#23 0x00007f6d08d30589 in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#24 0x00007f6d0a77191c in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#25 0x00007f6d0aeed04e in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#26 0x00007f6d0af1150e in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#27 0x00007f6d0af11e3c in  () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#28 0x00007f6d0af1212b in XRE_main () at /projects/uxp/epyrus/obj-x86_64-pc-linux-gnu/dist/bin/libxul.so
#29 0x0000561667696a45 in  ()
#30 0x00005616676960c7 in  ()
#31 0x00007f6d0d440d90 in __libc_start_call_main (main=main@entry=0x561667696060, argc=argc@entry=4, argv=argv@entry=0x7fff7f9aa7d8)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#32 0x00007f6d0d440e40 in __libc_start_main_impl
     (main=0x561667696060, argc=4, argv=0x7fff7f9aa7d8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff7f9aa7c8)
    at ../csu/libc-start.c:392
#33 0x0000561667696335 in _start ()

User avatar
random
Moongazer
Moongazer
Posts: 11
Joined: 2022-07-22, 06:31

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by random » 2022-08-11, 06:29

stevepusser wrote:
2022-08-05, 20:07
armhf builds succeeded for Debian 10, 11, Ubuntu 20.04, 21.10, and 22.04. Failed: Raspian 10, 11, and Debian testing and Sid.

What's annoying is that Raspian 10 and 11 are supposed to be equivalent to Debian 10 and 11, so I would expect those builds to also succeed. As a workaround, Raspian users can use the matching successful Debian armhf repo.
What is the difference between the Raspbian and Debian versions anyway? Before there were Raspbian 11 versions available, I always used the Debian 11 Palemoon package on Raspbian 11.

User avatar
stevepusser
Project Contributor
Project Contributor
Posts: 827
Joined: 2015-08-01, 18:33
Location: California

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by stevepusser » 2022-08-12, 22:18

As far as I know, they should be equivalent. Raspian does leave off certain Qt 5 packages that Debian includes, https://forums.raspberrypi.com/viewtopic.php?t=320031
which caused problems when I built Stellarium armhf packages on Debian armhf that ended up depending on runtimes that aren't in Raspian, but Raspian users were able to just installing the missing debs from the Debian repo, and then it worked fine.

But that doesn't affect Pale Moon builds.
Avatar is my photo of a female coyote that is still in my neighborhood as of Sept 2022.
They know me, so I'm able to approach and get some nice photos. So far, they still
are quite afraid of other people and their kids, even after five years.

User avatar
Pentium4User
Keeps coming back
Keeps coming back
Posts: 863
Joined: 2019-04-24, 09:38

Re: Repositories for supported Debian, Raspbian, and Ubuntu releases

Unread post by Pentium4User » 2022-08-19, 11:43

Ubuntu 21.10 can be removed, EoL.
I still use a 64 bit capable Pentium 4 670 processor with Pale Moon.

Post Reply