Re: [gentoo-user] Gaming on gentoo

2022-12-14 Thread Alan Ianson
On Wed, 14 Dec 2022 21:12:32 +
Artur Tamm  wrote:

> Hi,
> 
> I finally had the time to test quakespasm. I tried both the binary from the
> project as well as the version compiled by me from the project page on
> github. After copying the binary into quake folder (GoG version) and making
> symlinks to pak0.pak and pak1.pak (filesystem is case sensitive and the
> software cannot handle it). It worked fine.

Thank you for the assistance. 
> 
> Here is the ldd output (don't know if it helps)

It does help. I can see that an sdl build is working for you so I will compare 
that with my own and see if anything is different.

My own quakespasm (sdl and sdl2) segfaulted, but I am able to run an sdl build 
provided by the project at sourceforge. Hmm. :)

I'm thinking I may need to -sdl and +sdl2 in the use flags, or maybe +sdl and 
-sdl2. I'll check that when I get a bit of free time.



Re: [gentoo-user] Gaming on gentoo

2022-12-14 Thread Artur Tamm
Hi,

I finally had the time to test quakespasm. I tried both the binary from the
project as well as the version compiled by me from the project page on
github. After copying the binary into quake folder (GoG version) and making
symlinks to pak0.pak and pak1.pak (filesystem is case sensitive and the
software cannot handle it). It worked fine.

Artur

Here is the ldd output (don't know if it helps)
ldd quakespasm_compiled
linux-vdso.so.1 (0x7ffe3bd52000)
libm.so.6 => /lib64/libm.so.6 (0x7f2cd37c)
libGL.so.1 => /usr/lib64/libGL.so.1 (0x7f2cd373a000)
libvorbisfile.so.3 => /usr/lib64/libvorbisfile.so.3 (0x7f2cd373)
libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x7f2cd3702000)
libogg.so.0 => /usr/lib64/libogg.so.0 (0x7f2cd36f7000)
libmad.so.0 => /usr/lib64/libmad.so.0 (0x7f2cd36d4000)
libSDL-1.2.so.0 => /usr/lib64/libSDL-1.2.so.0 (0x7f2cd3668000)
libc.so.6 => /lib64/libc.so.6 (0x7f2cd346b000)
/lib64/ld-linux-x86-64.so.2 (0x7f2cd3db6000)
libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x7f2cd33b3000)
libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x7f2cd337f000)
libasound.so.2 => /usr/lib64/libasound.so.2 (0x7f2cd328f000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f2cd328a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f2cd3283000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x7f2cd313f000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x7f2cd3115000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x7f2cd311)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x7f2cd3108000)
libbsd.so.0 => /usr/lib64/libbsd.so.0 (0x7f2cd30ef000)
libmd.so.0 => /usr/lib64/libmd.so.0 (0x7f2cd30e1000)


On Tue, 13 Dec 2022 at 14:24, Alan Ianson  wrote:

> On Tue, 13 Dec 2022 13:49:54 +
> Artur Tamm  wrote:
>
> > sourceforge tarball was a prebuilt binary (at least the one I
> downloaded).
>
> The source is there too in a different directory.
>
> > I saw that the source code is here:
> > https://github.com/sezero/quakespasm/tree/master/Quake
> > The default Makefile might need some editing for a successful
> compilation.
>
> I just grabbed the linux-64 archive from sourceforge. I have never run the
> prebuilt binaries before but I tried it just to see what would happen. The
> quakespasm-sdl2 segfaulted the same as my own build but the quakespasm (sdl
> I suppose?) does run here.
>
> So that is something! I can run their sdl quakespasm but not my own built
> here.
>
> That is better than nothing but I'd still like to hear about your
> experience. I'd be happy if I could build and run my own if I can figure
> out what the issue is.
>
>
>


Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch.

2022-12-14 Thread Alan Mackenzie
Hello, Peter.

On Tue, Dec 13, 2022 at 03:44:49 +, Peter Humphrey wrote:
> On Monday, 12 December 2022 18:23:28 GMT Alan Mackenzie wrote:

> > Here is the latest version of my soft scrolling patch for the gentoo
> > kernel version 5.15.80.  It will surely work on any reasonably recent
> > kernel version, and also on future versions.  The new version doesn't
> > add any new functionality, it just patches the kernel giving rise to
> > fewer messages from the patch utility.

> You've done it again! What a fine effort. It's saved me much wailing and 
> gnashing of teeth.

Thanks for that!

> Is there any chance of enabling gpm to work with it? That would save
> yet more generations of tooth enamel.  :)

Yes, that's been annoying me for some time, too - when the screen is
scrolled, and one tries to mark a portion of text with GPM, it gets the
text that was on the screen before the scroll, and corrupts the display
of the text.

I had a look at it last night, and the problem is that the kernel
doesn't currently store the 32-bit unicode characters which have been
scrolled off the screen - just the 8-bit character glyph codes together
with the 8-bit colour information.  So it would triple the amount of
information stored for each character position.  That surely shouldn't
be a problem on today's machines, though - even with
FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE set to 512 kB, that would only
be 1.5 MB per console.

So yes, this should be doable.  It's definitely more than a day's work,
almost certainly less than a month's.  I'll see what I can manage.

> Seriously, though, it's just wonderful as it is, and we all owe you a debt.

Thanks again!

> -- 
> Regards,
> Peter.

-- 
Alan Mackenzie (Nuremberg, Germany).



Re: [gentoo-user] Re: btop fails to compile

2022-12-14 Thread Jochen Kirchner

Am 2022-12-05 07:30, schrieb Walter Dnes:

On Wed, Nov 30, 2022 at 01:50:02PM +0100, Jochen Kirchner wrote


this is my make.conf: (its a web - and mail server)

MAKEOPTS="-j17 -l17"


  Ouch!!!  How much ram do you have on that machine?  The Gentoo 
install

handbook has a dire warning at...

https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#MAKEOPTS

...that you need approx 2 gigabytes free ram for each increment in
"MAKEOPTS".


* Warning
Using a large number of jobs can significantly impact memory
consumption. A good recommendation is to have at least 2 GiB of RAM
for every job specified (so, e.g. -j6 requires at least 12 GiB). To
avoid running out of memory, lower the number of jobs to fit the
available memory.


  If you have a fancy-schmancy "desktop environment" allow another 3 or
4 Gigs, especially if you're simultaneously running Chrome or
calculating large spreadsheets or processing large documents.  For
"MAKEOPTS=-j17" you'll need at least 36-to-40 gigabytes.


Hi,

it's a Hetzner dedicated Server with 64GB of ram :)
But now I switched to Netcup.de kvm server.

---
Mit freundlichen Grüßen,
Jochen Kirchner

eMail: jk@jk-foto.design
Web: https://www.jk-foto.design