Re: [gentoo-user] Thunderbird build failure ..
Thanks bud Dave On Sun, Jan 1, 2023, 4:22 PM cal wrote: > On 1/1/23 13:05, Wol wrote: > > On 01/01/2023 20:08, cal wrote: > >> FWIW, Thunderbird builds fine with GCC on my machine -- I'm unsure of > >> your reasons for setting your Portage compiler to clang, but you may > >> wish to use a package.env override to build Thunderbird with GCC as a > >> workaround until the problem can be fixed upstream. > > > > I don't know anything about clang ... it must be the default ... > > > > I thought part of Firefox/Thunderbird was written in Rust, so I assumed > > it was built with llvm as a matter of course. > > > > I'll just wait for it to sort itself out. > > > > Cheers, > > Wol > You're right, it looks like the Thunderbird ebuild has a clang USE > turned on by default; I didn't realize that in my earlier reply and > assumed you had overridden this yourself. Regardless, this version > built correctly on my machine, so it's worthy of investigation with > upstream which combinations of parameters may be triggering the crash. > > cal > >
Re: [gentoo-user] Thunderbird build failure ..
On 1/1/23 13:05, Wol wrote: > On 01/01/2023 20:08, cal wrote: >> FWIW, Thunderbird builds fine with GCC on my machine -- I'm unsure of >> your reasons for setting your Portage compiler to clang, but you may >> wish to use a package.env override to build Thunderbird with GCC as a >> workaround until the problem can be fixed upstream. > > I don't know anything about clang ... it must be the default ... > > I thought part of Firefox/Thunderbird was written in Rust, so I assumed > it was built with llvm as a matter of course. > > I'll just wait for it to sort itself out. > > Cheers, > Wol You're right, it looks like the Thunderbird ebuild has a clang USE turned on by default; I didn't realize that in my earlier reply and assumed you had overridden this yourself. Regardless, this version built correctly on my machine, so it's worthy of investigation with upstream which combinations of parameters may be triggering the crash. cal
Re: [gentoo-user] Thunderbird build failure ..
On 01/01/2023 20:08, cal wrote: FWIW, Thunderbird builds fine with GCC on my machine -- I'm unsure of your reasons for setting your Portage compiler to clang, but you may wish to use a package.env override to build Thunderbird with GCC as a workaround until the problem can be fixed upstream. I don't know anything about clang ... it must be the default ... I thought part of Firefox/Thunderbird was written in Rust, so I assumed it was built with llvm as a matter of course. I'll just wait for it to sort itself out. Cheers, Wol
Re: [gentoo-user] Thunderbird build failure ..
On 1/1/23 11:14, Wols Lists wrote:
> On 01/01/2023 18:33, cal wrote:
>> On 1/1/23 03:07, Wols Lists wrote:
>>> I got the following build failure in my weekly emerge yesterday ...
>>>
>>> * Messages for package mail-client/thunderbird-102.6.0:
>>>
>>> * ERROR: mail-client/thunderbird-102.6.0::gentoo failed (compile
>>> phase):
>>> * (no error message)
>>> *
>>> * Call stack:
>>> * ebuild.sh, line 136: Called src_compile
>>> * environment, line 4782: Called die
>>> * The specific snippet of code:
>>> * ${virtx_cmd} ./mach build --verbose || die
>>> *
>>> * If you need support, post the output of `emerge --info
>>> '=mail-client/thunderbird-102.6.0::gentoo'`,
>>> * the complete build log and the output of `emerge -pqv
>>> '=mail-client/thunderbird-102.6.0::gentoo'`.
>>> * The complete build log is located at
>>> '/var/tmp/portage/mail-client/thunderbird-102.6.0/temp/build.log'.
>>> * The ebuild environment file is located at
>>> '/var/tmp/portage/mail-client/thunderbird-102.6.0/temp/environment'.
>>> * Working directory:
>>> '/var/tmp/portage/mail-client/thunderbird-102.6.0/work/thunderbird-102.6.0'
>>> * S:
>>> '/var/tmp/portage/mail-client/thunderbird-102.6.0/work/thunderbird-102.6.0'
>
>> Can you post the outputs referenced above/the full build log and your
>> portage configuration?
>
> Files attached - not sure it's everything you want, but I'm sure you'll
> let me know if I've messed up ... :-)
If you scroll up a bit in build.log, you can see that clang has crashed:
[...]
836:17.68 clang-15: error: clang frontend command failed with exit code
139 (use -v to see invocation)
836:17.68 clang version 15.0.6
836:17.68 Target: x86_64-pc-linux-gnu
836:17.69 Thread model: posix
836:17.69 InstalledDir: /usr/lib/llvm/15/bin
836:17.69 Configuration file: /etc/clang/clang++.cfg
836:18.07 clang-15: note: diagnostic msg:
836:18.07
836:18.07 PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
836:18.07 Preprocessed source(s) and associated run script(s) are
located at:
836:18.07 clang-15: note: diagnostic msg:
/var/tmp/portage/mail-client/thunderbird-102.6.0/temp/Unified_cpp_dom_media_webaudio1-f85814.cpp
836:18.07 clang-15: note: diagnostic msg:
/var/tmp/portage/mail-client/thunderbird-102.6.0/temp/Unified_cpp_dom_media_webaudio1-f85814.sh
836:18.07 clang-15: note: diagnostic msg:
836:18.07
If you search for "clang frontend command failed with exit code 139" it
turns up a few GitHub issues which may or may not be related; you may
wish to follow up with upstream on that.
FWIW, Thunderbird builds fine with GCC on my machine -- I'm unsure of
your reasons for setting your Portage compiler to clang, but you may
wish to use a package.env override to build Thunderbird with GCC as a
workaround until the problem can be fixed upstream.
>>>
>>> I'm wondering whether this will simply clear itself next week, seeing as
>>> last week I got a very similar failure for both thunderbird and firefox.
>>>
>>> Could it simply be a bit of the fallout from app-alternatives? Of
>>> course, it's blocking my depclean ...
>> Having followed this list for quite a while, my first guess whenever
>> someone fails to compile a web browser or similar heavy piece of
>> software (I'm counting Thunderbird here) is that they ran out of memory.
>> I would double check your MAKEOPTS and RAM size and try building with a
>> smaller -j. But as noted above, perhaps if you attach the full build
>> log for Thunderbird, a more obvious cause will appear in the output.
>>>
>
> thewolery /usr/local # df
> Filesystem 1K-blocks Used Available Use%
> Mounted on
> none 16404256 3328 16400928 1% /run
> udev 10240 0 10240 0% /dev
> tmpfs 16404256 0 16404256 0%
> /dev/shm
> /dev/dm-1 131001348 101620580 22653500 82% /
> tmpfs 16404260 4 16404256 1% /tmp
> /dev/mapper/vg--home-lv--data 2064042928 1472050236 487118712 76% /home
> tmpfs 3280848 56 3280792 1%
> /run/user/1000
> /dev/mapper/vg--home-lv--Videos 772966856 276285468 457343404 38%
> /home/Videos
> /dev/mapper/vg--home-lv--ISO 153707984 88546712 57280568 61%
> /home/ISO
> thewolery /usr/local #
>
> There's 28GB free disk space, surely that's enough? And iirc this
> machine has 32GB ram. Or do I need to do a bit of a clean-out - I appear
> to have used some 100GB for root which seems rather a lot ...
>
> Cheers,
> Wol
Re: [gentoo-user] Thunderbird build failure ..
On 1/1/23 03:07, Wols Lists wrote:
> I got the following build failure in my weekly emerge yesterday ...
>
> * Messages for package mail-client/thunderbird-102.6.0:
>
> * ERROR: mail-client/thunderbird-102.6.0::gentoo failed (compile phase):
> * (no error message)
> *
> * Call stack:
> * ebuild.sh, line 136: Called src_compile
> * environment, line 4782: Called die
> * The specific snippet of code:
> * ${virtx_cmd} ./mach build --verbose || die
> *
> * If you need support, post the output of `emerge --info
> '=mail-client/thunderbird-102.6.0::gentoo'`,
> * the complete build log and the output of `emerge -pqv
> '=mail-client/thunderbird-102.6.0::gentoo'`.
> * The complete build log is located at
> '/var/tmp/portage/mail-client/thunderbird-102.6.0/temp/build.log'.
> * The ebuild environment file is located at
> '/var/tmp/portage/mail-client/thunderbird-102.6.0/temp/environment'.
> * Working directory:
> '/var/tmp/portage/mail-client/thunderbird-102.6.0/work/thunderbird-102.6.0'
> * S:
> '/var/tmp/portage/mail-client/thunderbird-102.6.0/work/thunderbird-102.6.0'
Can you post the outputs referenced above/the full build log and your
portage configuration?
>
> I'm wondering whether this will simply clear itself next week, seeing as
> last week I got a very similar failure for both thunderbird and firefox.
>
> Could it simply be a bit of the fallout from app-alternatives? Of
> course, it's blocking my depclean ...
Having followed this list for quite a while, my first guess whenever
someone fails to compile a web browser or similar heavy piece of
software (I'm counting Thunderbird here) is that they ran out of memory.
I would double check your MAKEOPTS and RAM size and try building with a
smaller -j. But as noted above, perhaps if you attach the full build
log for Thunderbird, a more obvious cause will appear in the output.
>
> Cheers,
> Wol
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling.
On Sunday, 1 January 2023 15:13:02 GMT Alan Mackenzie wrote: > > > $ file /lib/rc/console/font > > > /lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters, > > > Unicode directory, 22x11 > > > > > > I use consolefont="ter-122n" from the terminus-font package. It's a long > > > time since I was able to read a high-resolution screen in its native > > > resolution. > That's a nice font. I could get used to it if I wasn't so attached to > the 8x16 font. [OT] Yes, I like it. I'd like it even better if I could redefine the zero character without the central dot (which I believe is an American affectation) because the central dot makes the 0 resemble an 8 too closely. Instead I'd change the outline shape. Then Os and 0s would more resemble their usual printed and GUI forms. I know this wouldn't be possible on smaller sizes, but it should be possible at 11x22. In fact I did try doing that once with a font editor, but it couldn't handle the whole font set properly. Perhaps I should look into it again. [/OT] --->8 > The included patch is still imperfect. When booting in 11x22, it doesn't > handle the early boot messages at all well. Also, I'm a little confused > by what a low-level scroll function is meant to do - sometimes, scrolling > happens when you type a CR, and want a line on the screen to be space > filled. Other times, you type and don't want any space > filling to happen. So I'm not convinced that scrolling, invoked by, say, > an editor program, will work correctly. > Just a quick test shows it to work here. If I find anything I'll raise a flag. Many thanks again, Alan. -- Regards, Peter.
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling.
Hello, Peter.
On Sat, Dec 31, 2022 at 16:13:23 +, Alan Mackenzie wrote:
> On Sat, Dec 31, 2022 at 15:47:01 +, Peter Humphrey wrote:
> > Hello Alan,
> > On Saturday, 31 December 2022 14:08:43 GMT you wrote:
[ ]
> > I think you've put your finger on it:
> > $ file /lib/rc/console/font
> > /lib/rc/console/font: Linux/i386 PC Screen Font v2 data, 256 characters,
> > Unicode directory, 22x11
> > I use consolefont="ter-122n" from the terminus-font package. It's a long
> > time
> > since I was able to read a high-resolution screen in its native resolution.
That's a nice font. I could get used to it if I wasn't so attached to
the 8x16 font.
> > Is there some way I can get the UEFI BIOS to boot with that font, or a
> > larger
> > one? Or perhaps let the system boot without setting a font and then
> > changing
> > it later?
> Probably, but it would be better if I just fixed the bug(s) in my changes to
> the kernel. Changing font size is something one should be able to do.
OK, the bug was that I was trying to free memory by calling the wrong
kernel function kfree, when it should have been kvfree. With that
correction, the kernel now boots in 11x22, at least for me.
> > Neither of those looks easy to do. I'd better have a good root through the
> > BIOS options to start with.
> A happy new year to you (and everybody else here), and give me somewhere
> between a few hours and a few days, and this bug should get fixed.
The included patch is still imperfect. When booting in 11x22, it doesn't
handle the early boot messages at all well. Also, I'm a little confused
by what a low-level scroll function is meant to do - sometimes, scrolling
happens when you type a CR, and want a line on the screen to be space
filled. Other times, you type and don't want any space
filling to happen. So I'm not convinced that scrolling, invoked by, say,
an editor program, will work correctly.
> Again, thanks for such effective testing!
So, please try the attached patch, which is "at the same level" as my
patch from three days ago. For anybody who wants to try it new, I'm
repeating the instructions from that post:
To use it, please apply the supplied patch ON TOP OF the patch I
posted here on 12th December. Proceed as documented in that post,
up until configuring the kernel - in Device drivers/Graphic
support/Console display driver support, there's an extra item
"Enable a working GPM for scrolled back scrollback buffer in System
RAM" which should be enabled by default. Check this is set up
properly. Then build and install the kernel. Then reboot into it
and try it out.
> > --
> > Regards,
> > Peter.
--
Alan Mackenzie (Nuremberg, Germany).
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index d7aadca5107d..7bea89f03e75 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -291,6 +291,28 @@ static inline bool con_should_update(const struct vc_data
*vc)
static inline unsigned short *screenpos(const struct vc_data *vc, int offset,
bool viewed)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+ unsigned long softback_pos, scrolled_expanse;
+
+ if (vc->vc_softback_curr == vc->vc_origin)
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ scrolled_expanse = vc->vc_softback_in - vc->vc_softback_curr;
+ if (scrolled_expanse < 0)
+ scrolled_expanse += vc->vc_softback_end
+ - vc->vc_softback_buf;
+ if (offset >= scrolled_expanse)
+ return (unsigned short *)(vc->vc_origin
+ + (offset -
scrolled_expanse));
+ else {
+ softback_pos = vc->vc_softback_curr + offset;
+ if (softback_pos >= vc->vc_softback_end)
+ softback_pos -= vc->vc_softback_end
+ - vc->vc_softback_buf;
+ }
+ }
+ return (unsigned short *)softback_pos;
+#else
unsigned short *p;
if (!viewed)
@@ -300,6 +322,7 @@ static inline unsigned short *screenpos(const struct
vc_data *vc, int offset,
else
p = vc->vc_sw->con_screen_pos(vc, offset);
return p;
+#endif
}
/* Called from the keyboard irq path.. */
@@ -321,101 +344,106 @@ void schedule_console_callback(void)
* Code to manage unicode-based screen buffers
*/
-#ifdef NO_VC_UNI_SCREEN
-/* this disables and optimizes related code away at compile time */
-#define get_vc_uniscr(vc) NULL
-#else
-#define get_vc_uniscr(vc) vc->vc_uni_screen
-#endif
-
#define VC_UNI_SCREEN_DEBUG 0
typedef uint32_t char32_t;
-/*
- * Our screen buffer is preceded by an array of line pointers so that
- * scrolling only implies some pointer shuffling.
- */
-struct uni_screen {
- char32_t *lines[0];
-};
+#define vc_uniscr_buf_en
[gentoo-user] Thunderbird build failure ..
I got the following build failure in my weekly emerge yesterday ...
* Messages for package mail-client/thunderbird-102.6.0:
* ERROR: mail-client/thunderbird-102.6.0::gentoo failed (compile phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 136: Called src_compile
* environment, line 4782: Called die
* The specific snippet of code:
* ${virtx_cmd} ./mach build --verbose || die
*
* If you need support, post the output of `emerge --info
'=mail-client/thunderbird-102.6.0::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=mail-client/thunderbird-102.6.0::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/mail-client/thunderbird-102.6.0/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/mail-client/thunderbird-102.6.0/temp/environment'.
* Working directory:
'/var/tmp/portage/mail-client/thunderbird-102.6.0/work/thunderbird-102.6.0'
* S:
'/var/tmp/portage/mail-client/thunderbird-102.6.0/work/thunderbird-102.6.0'
I'm wondering whether this will simply clear itself next week, seeing as
last week I got a very similar failure for both thunderbird and firefox.
Could it simply be a bit of the fallout from app-alternatives? Of
course, it's blocking my depclean ...
Cheers,
Wol
