[gentoo-user] Graphics configuration for a Ryzen 7 7700X chip and water cooling.
Hello, Gentoo. My current rig is working well (hence the lack of posts to the list from me), but The time is coming up for me to buy a new PC, the current one being around 7 years old. It's served me well for that time, but nothing lasts forever. Also, it would be nice to be able to build clang and rust and friends somewhat faster. So I'm looking at getting an AMD Ryzen 7 7700X processor, and using its inbuilt graphics rather than buying a distinct graphics card. But in the doc on wiki.gentoo.org, I can't find any mention of inbuilt graphics; all references are to graphics _cards_. Does Gentoo support my intended processor's graphics, and if so, how do I go about identifying the needed microcode (if any) and so on? Am I missing something obvious in the wiki? As a somewhat tangential question, would it be worthwhile getting water cooling in my new machine? In particular, to reduce the noise it gives off while building large packages such as clang and rust? Or is water cooling only sensible for really heavy users such as gamers? Thanks for the upcoming answers! -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] CONFIG_BLK_DEBUG_FS on kernel 6.8.1 considered a Bad Thing.
Hello, Gentoo. A heads-up for kernel 6.8: I'm playing with kernel 6.8.1 (direct from Linux). When I first booted it, it failed to mount my /boot partition with this error message in dmesg: [5.645341] FAT-fs (nvme0n1p2): bogus number of reserved sectors [5.645345] FAT-fs (nvme0n1p2): Can't find a valid FAT filesystem .. On diffing the 6.7 and 6.8 .config files, I found a new pertinent item [*] Block layer debugging information in debugfs .. When I disabled this and rebuilt the kernel, my /boot mounted without problem. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Soft scrolling on framebuffer consoles - with GPM handling - version of the patch for kernel 6.8.1 onwards.
Hello, Peter.
On Mon, Mar 11, 2024 at 10:47:43 +, Peter Humphrey wrote:
> On Wednesday, 24 January 2024 12:20:29 GMT Alan Mackenzie wrote:
> > Hello, Gentoo.
> > On Wed, Jan 24, 2024 at 10:00:37 +, Alan Mackenzie wrote:
> > [ ]
> > Please note the corrected subject line. This version of the soft
> > scrolling patch is for kernel 6.6.13, or thereabouts.
> It works well here, Alan, up to kernel version 6.7.9, but one of the 15 or so
> new kernel parameters (since 6.7.8) seems to cause it to fail.
> I've attached the reject file, /usr/src/linux-6.8.0-gentoo/drivers/tty/vt/
> vt.c.rej.
Thanks!
I've had a look at this, now. The 6.6.13 patch appears to work on 6.7.x
(I tested it on 6.7.10 this morning).
For 6.8.1, a new patch is needed, see below. Remember, to apply it, you
need smething like:
$ patch -p1 < 6.8.1-GPS.20240402.diff
.. Have fun!
> --
> Regards,
> Peter.
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index 8967c3a0d916..f40ebbfb87de 100644
--- a/drivers/tty/vt/selection.c
+++ b/drivers/tty/vt/selection.c
@@ -217,7 +217,8 @@ static int vc_selection_store_chars(struct vc_data *vc,
bool unicode)
unless non-space at end of line. */
if (obp != bp) {
bp = obp;
- *bp++ = '\r';
+ if ((i + 2) < vc_sel.end) /* Don't add \r to
the last line. */
+ *bp++ = '\r';
}
obp = bp;
}
@@ -263,6 +264,11 @@ static int vc_do_selection(struct vc_data *vc, unsigned
short mode, int ps,
new_sel_start = rounddown(ps, vc->vc_size_row);
new_sel_end = rounddown(pe, vc->vc_size_row) +
vc->vc_size_row - 2;
+ while ((new_sel_end > pe)
+ && (is_space_on_vt (sel_pos (new_sel_end, unicode
+ new_sel_end -= 2;
+ if (!((new_sel_end) % vc->vc_size_row))
+ new_sel_end += 2;
break;
case TIOCL_SELPOINTER:
highlight_pointer(pe);
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 38a765eadbe2..dd012e99e797 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];
EXPORT_SYMBOL(vc_cons);
@@ -289,8 +294,31 @@ 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) /* Should never happen! */
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ if (vc->vc_softback_in >= vc->vc_softback_curr)
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr;
+ else
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr
+ + 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)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -298,6 +326,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.. */
@@ -319,107 +348,111 @@ void schedule_console_callback(void)
* Code to manage unicode-based screen buffers
*/
-/*
- * Our screen buffer is preceded by an array of line pointers so that
- * scrolling only implies some pointer shuffling.
- */
+#define vc_uniscr_buf_end(vc) (vc->vc_uniscr_buf + vc->vc_uniscr
Re: [gentoo-user] My emerge @preserved-rebuild is wedged. Help, please!
Hello, Stefan. Sorry it's taken me so long to reply. Just after I first posted, I updated my system, with which libssl-1.1.1w got unmerged. So my qmail stopped working. I've now reinstalled and configured it. On Mon, Apr 01, 2024 at 15:23:02 +, stefan1 wrote: > On 2024-04-01 15:12, Alan Mackenzie wrote: > > Hello, Gentoo. > > I'm trying to do > > # emerge -a @preserved-rebuild > > .. For this purpose, I created a temporary repository, filling it with > > ancient ebuilds recovered from /var/db/pkg. > > It shows me 5 packages to be merged, among them being > > [ebuild R] dev-lang/spidermonkey-78.15.0 [78.15.0] > > .. When I answer the "are you sure?" prompt with Yes, spidermonkey > > fails > > to build with this error message: > >>>> Emerging (1 of 5) dev-lang/spidermonkey-78.15.0::localrepo > > !!! Fetched file: firefox-78.15.0esr.source.tar.xz VERIFY FAILED! > > !!! Reason: Insufficient data for checksum verification > > !!! Got: > > !!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 > > SHA512 WHIRLPOOL > > * Fetch failed for 'dev-lang/spidermonkey-78.15.0', Log file: > > * '/var/tmp/portage/dev-lang/spidermonkey-78.15.0/temp/build.log' > > It would appear that the sources are no longer available at Firefox, > > and > > I no longer have a copy in /usr/portage/distfiles. > > Why is portage trying to build this obsolete version? I surely will > > just > > unmerge it as soon as my system is back in order. > > Most importantly, how can I free up my system so that I can proceed > > with > > the pending profile update? I appear to be stuck. I hope I won't have > > to reinstall gentoo. > For old distfiles, NeddySeagoon hosts them publicly accessible. > This is the closest I found to your version: > https://bloodnoc.org/~roy/olde-distfiles/spidermonkey-78-patches-04.tar.xz Thanks! In the end I didn't need to download any files. > -- > Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz > COMMON_FLAGS="-O3 -pipe -march=native -fno-stack-protector > -ftree-vectorize -ffast-math -funswitch-loops -fuse-linker-plugin -flto > -fdevirtualize-at-ltrans -fno-plt -fno-semantic-interposition > -falign-functions=64 -fgraphite-identity -floop-nest-optimize" > USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto > libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal > strip system-man" > INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd > /usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus > /lib/udev /usr/share/icons /usr/share/applications > /usr/share/gtk-3.0/emoji" -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] My emerge @preserved-rebuild is wedged. Help, please!
Hello, Arsen. Sorry it's taken me so long to reply. Just after I first posted, I updated my system, with which libssl-1.1.1w got unmerged. So my qmail stopped working. I've now reinstalled and configured it. On Mon, Apr 01, 2024 at 17:48:18 +0200, Arsen Arsenović wrote: > Hi Alan, > Alan Mackenzie writes: > > Hello, Gentoo. > > I'm trying to do > > # emerge -a @preserved-rebuild > > .. For this purpose, I created a temporary repository, filling it with > > ancient ebuilds recovered from /var/db/pkg. > > It shows me 5 packages to be merged, among them being > > [ebuild R] dev-lang/spidermonkey-78.15.0 [78.15.0] > > .. When I answer the "are you sure?" prompt with Yes, spidermonkey fails > > to build with this error message: > >>>> Emerging (1 of 5) dev-lang/spidermonkey-78.15.0::localrepo > > !!! Fetched file: firefox-78.15.0esr.source.tar.xz VERIFY FAILED! > > !!! Reason: Insufficient data for checksum verification > > !!! Got: > > !!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 > > SHA512 WHIRLPOOL > > * Fetch failed for 'dev-lang/spidermonkey-78.15.0', Log file: > > * '/var/tmp/portage/dev-lang/spidermonkey-78.15.0/temp/build.log' > > It would appear that the sources are no longer available at Firefox, and > > I no longer have a copy in /usr/portage/distfiles. > > Why is portage trying to build this obsolete version? I surely will just > > unmerge it as soon as my system is back in order. > Because it currently is installed and depends on a preserved lib. I was confused about that. It didn't appear to be present and functional. > > Most importantly, how can I free up my system so that I can proceed with > > the pending profile update? I appear to be stuck. I hope I won't have > > to reinstall gentoo. > You can just go ahead with it. Odds are Spidermonkey will be updated, > or at least rebuilt, when you do that. I've got rid of it with energe --unmerge. My @preserved-rebuild now works again. So it's time to go for the 23.0 profile. Thanks! > -- > Arsen Arsenović -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] My emerge @preserved-rebuild is wedged. Help, please!
Hello, Michael. Sorry it's taken me so long to reply. Just after I first posted, I updated myrsystem,2with which libssl-1.1.1w got unmerged. So my qmail stopped working. I've now reinstalled and configured it. On Mon, Apr 01, 2024 at 16:38:57 +0100, Michael wrote: > On Monday, 1 April 2024 16:12:51 BST Alan Mackenzie wrote: > > Hello, Gentoo. > > > > I'm trying to do > > > > # emerge -a @preserved-rebuild > > > > .. For this purpose, I created a temporary repository, filling it with > > ancient ebuilds recovered from /var/db/pkg. > I may be missing something, but why are you doing this? My @preserved-rebuild had been broken for months. It needed sorting out before migrating to the new profile. > Why don't you run @world update first, which will bring your system to a > stable state, before you proceed with anything else, e.g. migrating to > profile > 23.0? @world updates didn't resolve the problem with @p-r. But Jack's suggestion has worked for me. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] My emerge @preserved-rebuild is wedged. Help, please!
Hello, Jack. Sorry it's taken me so long to reply. Just after I first posted, I updated my system, with which libssl-1.1.1w got unmerged. So my qmail stopped working. I've now reinstalled and configured it. On Mon, Apr 01, 2024 at 11:25:38 -0400, Jack wrote: >If you are just going to unmerge it anyway, why not do so before >emerging @preserved-rebuild? Possibly because it didn't occur to me that --unmerge would work on a package that wasn't properly installed. However, after unmerging it (and two ancient versions of php), @preserved-rebuild worked. :-). So I'm back in action. Thanks very much! -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] My emerge @preserved-rebuild is wedged. Help, please!
Hello, Gentoo. I'm trying to do # emerge -a @preserved-rebuild .. For this purpose, I created a temporary repository, filling it with ancient ebuilds recovered from /var/db/pkg. It shows me 5 packages to be merged, among them being [ebuild R] dev-lang/spidermonkey-78.15.0 [78.15.0] .. When I answer the "are you sure?" prompt with Yes, spidermonkey fails to build with this error message: >>> Emerging (1 of 5) dev-lang/spidermonkey-78.15.0::localrepo !!! Fetched file: firefox-78.15.0esr.source.tar.xz VERIFY FAILED! !!! Reason: Insufficient data for checksum verification !!! Got: !!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 SHA512 WHIRLPOOL * Fetch failed for 'dev-lang/spidermonkey-78.15.0', Log file: * '/var/tmp/portage/dev-lang/spidermonkey-78.15.0/temp/build.log' It would appear that the sources are no longer available at Firefox, and I no longer have a copy in /usr/portage/distfiles. Why is portage trying to build this obsolete version? I surely will just unmerge it as soon as my system is back in order. Most importantly, how can I free up my system so that I can proceed with the pending profile update? I appear to be stuck. I hope I won't have to reinstall gentoo. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Don't be like stupid me!
Hello, Bill. On Sun, Feb 11, 2024 at 10:14:49 +0800, William Kenworthy wrote: > On 10/2/24 23:56, Alan Mackenzie wrote: > > I was wanting to do a pretty full build of my Emacs working repository. > > This involved first purging al *.elc files. The way to do this is > > $ find . -name '*.elc' | xargs rm > > . But for some reason, I typed > > $ find . '*.elc' | xargs rm > > . I even carefully checked it before pressing RET. However, press it I > > did, instantly deleting all files in my working directory. OUTCH! > > So, I fell back on my backup from last Sunday. After about 1½ hours > > trial and error, I had my source files as of last Sunday back again, > > though git could have been more helpful than it actually is. > > Thankfully, I had Emacs open, with all the files modified since Sunday > > in buffers. So, I laboriously worked through Emacs's buffer list, > > saving those ones I'd since changed. > > I lost all my timestamps on the files, and lost all my Emacs backup > > files (things ending in ~ which Emacs constantly makes). But my > > software builds and runs. > > It could have been a lot worse. Boys and girls, don't use > > $ find | xargs rm > > unless you really know what you're doing. And even then, it's probably > > better not to. ;-( > > It occurred to me fairly quickly after that press of RET that I could > > have done well with a COW snapshot facility, something which has been > > discussed at length on another recent thread. I even have LVM on my > > machine for its RAID capabilities. But I've never bothered before. I > > mean "I'm too careful", amn't I? ;-( At least I do a weekly backup, > > though. > > So, in the end I managed to recover fairly well, thankfully. > No, you don't need a snapshot system - you need a proper backup system > that stores the proper metadata. I remembered after sending my original post that I stored the timestamps of all the files in a file called timestamps.txt. So a quick sed script invocation on this file, and I had my timestamps back again! > When I was experimenting with snapshots (btrfs and moosefs) at > different times I lost everything a few times with filesystem > corruption which meant I lost the snapshots too. > Snapshots are NOT safe backups - treat them as a convenient copy ... I was thinking of a snapshot more as an addition to backups, not an alternative. Such would have made it easier for me to recover yesterday. A backup on the same medium as the filesystem isn't a backup at all. I've never had a disk drive or SSD fail on me yet, but I'm not pushing my luck. > BillK -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Don't be like stupid me!
Hello, gentoo. I was wanting to do a pretty full build of my Emacs working repository. This involved first purging al *.elc files. The way to do this is $ find . -name '*.elc' | xargs rm .. But for some reason, I typed $ find . '*.elc' | xargs rm .. I even carefully checked it before pressing RET. However, press it I did, instantly deleting all files in my working directory. OUTCH! So, I fell back on my backup from last Sunday. After about 1½ hours trial and error, I had my source files as of last Sunday back again, though git could have been more helpful than it actually is. Thankfully, I had Emacs open, with all the files modified since Sunday in buffers. So, I laboriously worked through Emacs's buffer list, saving those ones I'd since changed. I lost all my timestamps on the files, and lost all my Emacs backup files (things ending in ~ which Emacs constantly makes). But my software builds and runs. It could have been a lot worse. Boys and girls, don't use $ find | xargs rm unless you really know what you're doing. And even then, it's probably better not to. ;-( It occurred to me fairly quickly after that press of RET that I could have done well with a COW snapshot facility, something which has been discussed at length on another recent thread. I even have LVM on my machine for its RAID capabilities. But I've never bothered before. I mean "I'm too careful", amn't I? ;-( At least I do a weekly backup, though. So, in the end I managed to recover fairly well, thankfully. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Soft scrolling on framebuffer consoles - with GPM handling - version of the patch for kernel 6.6 [was 6.3] onwards.
Hello, Gentoo. On Wed, Jan 24, 2024 at 10:00:37 +, Alan Mackenzie wrote: [ ] Please note the corrected subject line. This version of the soft scrolling patch is for kernel 6.6.13, or thereabouts. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Soft scrolling on framebuffer consoles - with GPM handling - version of the patch for kernel 6.3 onwards.
Hello, Gentoo.
[ First an older post, but without quoting >s on the lines. ]
On Fri, Feb 03, 2023 at 18:56:27 +0000, Alan Mackenzie wrote:
The topic of this post is my kernel patch which enables soft scrolling
on Linux tty's with and , and also enables
the GPM mouse utility on those scrolled regions.
Currently, the patch I posted some months ago works on all 6.1.x
kernels, and very likely works on 6.2.x, too. In kernel 6.3.1, some
significant refactoring was done by the kernel people, necessitating a
new version of the patch, called 6.3.11-GPM.20231004.diff. I've tested
this on 6.3.11 and 6.5.5.
Just a quick reminder of how to use these files for anybody else who
might be interested:
(i) cd /usr/src/linux-6.3.11-gentoo, or similar. (Or ...-6.1.x-gentoo).
(ii) patch -p1 < 6.3.11-GPM.20231004.diff (or the other one).
(iii) Configure the kernel as normal. Additionally, under Device
drivers/Graphic Support/Console display driver support, enable
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK, set the buffer size to taste
(it's default is 128 kB) and accept the default enablement of
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM.
(iv) Build the kernel and install it into your boot manager.
(v) Reboot and enjoy! You can now use GPM in scrolled consoles.
Just a warning: if you copy your kernel .config from a 6.1.x kernel, and
use make oldconfig to generate a new kernel for 6.3.x etc., you will
have to enable CONFIG_HID_SUPPORT, otherwise your USB keyboard and mouse
will be dead on bootup. ;-(
The usual disclaimers apply, here. If this patch breaks anything for
you, you get to join the pieces back together again. But if this does
happen, please let me know, so that I can try to fix the bug. My only
promise is that there's nothing malicious in the patch.
As well as 6.3.11-GPM.20231004.diff, I'm reposting
6.1.8-GPM.20230203.diff for anybody new here who wants to try it on the
current Gentoo 6.1.x kernel.
--
Alan Mackenzie (Nuremberg, Germany).
I've adapted this patch for kernel 6.6.13. All of the parent post still
applies, with the exception of the version numbers.
The main patch for the new kernel is 6.6.13-GPM.20240123.diff.
Additionally I've attached a smaller patch which fixes what to me was a
little glitch in the gpm utility. This was that on a triple click to
select a whole line (or sequence of lines), the (last) line got a
linefeed appended to it. The effect was that if you wanted to hoik a
line out of some screen output and execute that from the bash command
line, you couldn't edit it first. So with this patch, you no longer get
that annoying linefeed, and the highlighting is adjusted accordingly.
This patch is (as far as I'm aware, without testing) independent of the
main GPM patch.
If anybody still needs them, I've still got the patches for the 6.1
kernel, and the 6.3 and 6.5 kernels, and one or two earlier kernels too.
Have fun!
--
Alan Mackenzie (Nuremberg, Germany).
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 5c47f77804f0..3a901537d5b6 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];
EXPORT_SYMBOL(vc_cons);
@@ -289,8 +294,31 @@ 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) /* Should never happen! */
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ if (vc->vc_softback_in >= vc->vc_softback_curr)
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr;
+ else
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr
+ + 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)
p = (unsigne
Re: [gentoo-user] Soft scrolling on framebuffer consoles - with GPM handling - version of the patch for kernel 6.3 onwards.
Hello, Jorge. On Wed, Oct 04, 2023 at 18:08:20 +0100, Jorge Almeida wrote: >6.3.11-GPM.20231004.diff works fine with 6.5.5 (vanilla from >[1]kernel.org) Thanks for doing this testing. > > References > >1. http://kernel.org/ -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] An annoyance in GPM, and a fix for it
Hello, Gentoo.
In the GPM mouse utility in a tty, one can use a double click to select
a word (and by holding the button down and moving the mouse, select a
sequence of words).
Similarly, with a triple click, one can select a line, or a sequence of
lines. This is all very fine, but GPM adds a CR after each line in the
sequnce, INCLUDING THE LAST ONE. This makes it less useful for, say,
copying a shell script command from and editor onto a command line.
Because typically, you'd want to edit the command before executing it,
but with GPM's mechanism, the CR on the end immediately executes it, not
giving you a chance to edit it.
A solution to this problem is not to append the CR to the last line in a
sequence of lines selected by GPM. This means patching the kernel. To
apply the patch, first get the attached patch into the kernel's
directory, and do something like:
# patch -p1 < 6.1.8-TRIPLE.20231004.diff
, then rebuild the kernel. Install this kernel into your boot manager,
and voilà - the problem is solved. :-)
The usual disclaimer applies.
--
Alan Mackenzie (Nuremberg, Germany).
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index 6ef22f01cc51..e2a07b8759ed 100644
--- a/drivers/tty/vt/selection.c
+++ b/drivers/tty/vt/selection.c
@@ -217,7 +217,8 @@ static int vc_selection_store_chars(struct vc_data *vc,
bool unicode)
unless non-space at end of line. */
if (obp != bp) {
bp = obp;
- *bp++ = '\r';
+ if ((i + 2) < vc_sel.end) /* Don't add \r to
the last line. */
+ *bp++ = '\r';
}
obp = bp;
}
Re: [gentoo-user] Soft scrolling on framebuffer consoles - with GPM handling - version of the patch for kernel 6.3 onwards.
Hello, Gentoo.
On Fri, Feb 03, 2023 at 18:56:27 +, Alan Mackenzie wrote:
The topic of this post is my kernel patch which enables soft scrolling
on Linux tty's with and , and also enables
the GPM mouse utility on those scrolled regions.
Currently, the patch I posted some months ago works on all 6.1.x
kernels, and very likely works on 6.2.x, too. In kernel 6.3.1, some
significant refactoring was done by the kernel people, necessitating a
new version of the patch, called 6.3.11-GPM.20231004.diff. I've tested
this on 6.3.11 and 6.5.5.
Just a quick reminder of how to use these files for anybody else who
might be interested:
(i) cd /usr/src/linux-6.3.11-gentoo, or similar. (Or ...-6.1.x-gentoo).
(ii) patch -p1 < 6.3.11-GPM.20231004.diff (or the other one).
(iii) Configure the kernel as normal. Additionally, under Device
drivers/Graphic Support/Console display driver support, enable
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK, set the buffer size to taste
(it's default is 128 kB) and accept the default enablement of
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM.
(iv) Build the kernel and install it into your boot manager.
(v) Reboot and enjoy! You can now use GPM in scrolled consoles.
Just a warning: if you copy your kernel .config from a 6.1.x kernel, and
use make oldconfig to generate a new kernel for 6.3.x etc., you will
have to enable CONFIG_HID_SUPPORT, otherwise your USB keyboard and mouse
will be dead on bootup. ;-(
The usual disclaimers apply, here. If this patch breaks anything for
you, you get to join the pieces back together again. But if this does
happen, please let me know, so that I can try to fix the bug. My only
promise is that there's nothing malicious in the patch.
As well as 6.3.11-GPM.20231004.diff, I'm reposting
6.1.8-GPM.20230203.diff for anybody new here who wants to try it on the
current Gentoo 6.1.x kernel.
--
Alan Mackenzie (Nuremberg, Germany).
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 3c2ea9c098f7..51a3f0e7ffb5 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];
#ifndef VT_SINGLE_DRIVER
@@ -286,8 +291,31 @@ 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) /* Should never happen! */
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ if (vc->vc_softback_in >= vc->vc_softback_curr)
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr;
+ else
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr
+ + 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)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -295,6 +323,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.. */
@@ -316,107 +345,111 @@ void schedule_console_callback(void)
* Code to manage unicode-based screen buffers
*/
-/*
- * Our screen buffer is preceded by an array of line pointers so that
- * scrolling only implies some pointer shuffling.
- */
+#define vc_uniscr_buf_end(vc) (vc->vc_uniscr_buf + vc->vc_uniscr_char_size)
-static u32 **vc_uniscr_alloc(unsigned int cols, unsigned int rows)
+static int vc_uniscr_alloc(struct vc_data *vc, unsigned int cols, unsigned int
rows)
{
- u32 **uni_lines;
- void *p;
- unsigned int memsize, i, col_size = cols * sizeof(**uni_lines);
-
- /* allocate everything in one go */
- memsize = col_size * rows;
Re: [gentoo-user] Invalid opcode after kernel update
Hello, Fernando. On Sun, Sep 17, 2023 at 17:49:22 -0400, Fernando Rodriguez wrote: > A few months ago after updating my kernel I started getting an invalid > opcode error during boot on the init process on my initramfs which I did > rebuilt. Switching to the old kernel and initramfs fixed the problem so > I kept that kernel for a few months for lack of time. > Today I rebuilt the whole system using `emerge -e @world` and after that > I'm able to boot the new kernel but now some pre-compiled packages (and > some that emerge -e missed because the ebuild was masked) crash with > illegal opcode. In the case of chrome it's not crashing but it only > renders garbage for webpages. > Does anyone have a clue what is happening? It's like the instruction set > changed after the kernel update (or was it the microcode?) Could it be that you've got a sporadic RAM failure? Running the standard RAM test (the one you boot into, I've forgotten its name) for many hours might pin down the problem. > Thanks, > -- > Fernando Rodriguez -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] he's baaaaaaack :-D
Hello, Alan. Welcome back! On Thu, Aug 31, 2023 at 20:15:00 +0200, Alan McKinnon wrote: >Hello Gentoo'ers >After some years away, I'm back to Gentoo. Arch was nice and I got >fuzzies but something was always missing. Was on Mint for a while but >eventually got fed up with how it does Bluetooth. So Gentoo is now on >the new laptop from work. >Going through the list archives, I see a whole bunch of familiar names >like Dale, Helmut, Peter, Rich, Grant, Walter, William and more. >For those who never knew me, My name is Alan, first used Gentoo 18/19 >years ago, work at a large mobile operator where I'm a sysadmin and >general know-it-all-busy-body working with ICT stuff, so happy to make >your acquaintance. >-- >Alan McKinnon > alan dot mckinnon at gmail dot com -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Spurious error messages at boot up from the new dhcpcd
Hello, Michael. On Tue, Aug 22, 2023 at 16:03:16 +0100, Michael wrote: > Hello Alan, > On Tuesday, 22 August 2023 14:00:26 BST Alan Mackenzie wrote: > > I don't understand what I just did, by deleting net.enp38s0, though it > > appeared to have fixed the problem. That worries me. Could you possibly > > explain to me a bit more what that removal did? Thanks! > There are different ways to configure and bring up your network interface. > If you have a complicated network configuration, with static address(es), > bridges, multihoming, etc. then using netifrc scripts is a convenient method > to automate default runlevel service(s) to manage your setup. OK. > For simpler network requirements a dhcp client, like dhcpcd, is adequate for > bringing up and configuring your network interface. Which is appropriate for my setup. > In absence of any manual settings netifrc will also bring up dhcpcd to try to > obtain an IP address from the router. > You had both a netifrc service and a dhcpcd service starting up, each trying > to negotiate an IP address from your router and tripping over themselves. Ah, so that was it! Thanks! > > On removing dhcpcd from default, the maching just has no network > > connection on booting up. > OK, sometimes a service which requires a network connection can bring in > dhcpcd - I have neither netifrc nor dhcpcd services starting here on their > own: > $ rc-update -s -v | grep 'dhcpcd|net' >dhcpcd | > local | default nonetwork >net-online | >net.lo | > netmount | default > but in my case I think chronyd starts dhcpcd to connect to the network. OK. > In your case, dhcpcd launched as a default service is needed to set up your > connection. Yes. Thanks again for the explanation. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Spurious error messages at boot up from the new dhcpcd
Hello, Nuno. On Tue, Aug 22, 2023 at 22:41:11 +0100, Nuno Silva wrote: > On 2023-08-22, Alan Mackenzie wrote: > > With the new dhcpcd-10.0.2 (previous version being ?9.5.1) I get spurious > > error messages on boot up. In particular, I see this: > > * Starting DHCP Client Daemon ... > > * [ ok ] * Bringing up interface enp38s0 > > * Caching network module dependencies > > * config_enp38s0 not specified; defaulting to DHCP > > * dhcp ... > > * The dhcpcd version is too old. Please upgrade. > > * [ !! ] * ERROR: net.enp38s0 failed to start > [...] > > So it would appear that everything is working, but I still get error > > messages. The "dhcpcd version is too old" is particularly galling, given > > that dhcpcd was updated yesterday. > A check (in netifrc) didn't account for two-digit major version numbers > when checking the dhcpcd version. > https://bugs.gentoo.org/show_bug.cgi?id=904422 Thanks, I've had a look at that bug. It was a simple coding error. > So check if there's a newer version of net-misc/netifrc available. I've currently got netifrc-0.7.3 installed. There are 0.7.4 and 0.7.5 available (according to eshowkw). But, for some reason, portage hasn't upgraded my system (an amd64) to 0.7.5. It looks as though I should do this by hand. > -- > Nuno Silva -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Spurious error messages at boot up from the new dhcpcd
Hello, Michael. On Tue, Aug 22, 2023 at 12:29:38 +0100, Michael wrote: > On Tuesday, 22 August 2023 10:56:52 BST Alan Mackenzie wrote: > > Hello, gentoo. > > With the new dhcpcd-10.0.2 (previous version being ?9.5.1) I get spurious > > error messages on boot up. In particular, I see this: > > * Starting DHCP Client Daemon ... > > * [ ok ] * Bringing up interface enp38s0 > > * Caching network module dependencies > > * config_enp38s0 not specified; defaulting to DHCP > > * dhcp ... > > * The dhcpcd version is too old. Please upgrade. > > * [ !! ] * ERROR: net.enp38s0 failed to start > > .. However, after ~1 hour searching for the problem, I just tried using > > enp38s0 to ssh onto my ISP, and it worked. In /var/log/messages, I see > > the following: > > Aug 22 09:24:20 ACM dhcpcd[2435]: dhcpcd-10.0.2 starting > > Aug 22 09:24:20 ACM dhcpcd[2437]: dev: loaded udev > > Aug 22 09:24:20 ACM dhcpcd[2437]: DUID > > 00:01:00:01:20:97:45:37:60:45:cb:9c:5b:d6 Aug 22 09:24:20 ACM dhcpcd[2437]: > > enp38s0: waiting for carrier > > Aug 22 09:24:22 ACM kernel: igb :26:00.0 enp38s0: igb: enp38s0 NIC Link > > is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Aug 22 09:24:23 ACM > > dhcpcd[2437]: enp38s0: carrier acquired > > Aug 22 09:24:23 ACM kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp38s0: link > > becomes ready Aug 22 09:24:23 ACM dhcpcd[2437]: enp38s0: IAID cb:9c:5b:d6 > > Aug 22 09:24:24 ACM dhcpcd[2437]: enp38s0: rebinding lease of 192.168.178.86 > > Aug 22 09:24:24 ACM dhcpcd[2437]: enp38s0: probing address > > 192.168.178.86/24 Aug 22 09:24:28 ACM dhcpcd[2437]: enp38s0: leased > > 192.168.178.86 for 864000 seconds Aug 22 09:24:28 ACM dhcpcd[2437]: > > enp38s0: adding route to 192.168.178.0/24 Aug 22 09:24:28 ACM dhcpcd[2437]: > > enp38s0: adding default route via 192.168.178.1 Aug 22 09:24:29 ACM > > /etc/init.d/net.enp38s0[2686]: config_enp38s0 not specified; defaulting to > > DHCP > I don't know what your network configuration requirements may be, but if you > have not specified a manual configuration for your enp38s0 interface, then > you > probably do not need the netifrc service enabled. You can remove net.enp38s0 > service from the default runlevel and reboot, with an eye on the log messages. I am running a simple workstation, connected to a consumer-grade router by an ethernet cable. I didn't (and don't) have a specific configuration for enp38s0. I did $ rc-update del net.enp38s0 default and rebooted. The machine came up without error messages, indeed with fewer messages than it used to. On tty1, I now see just: INIT: Entering runlevel: 3 * Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ... * [ ok ] * Starting syslog-ng ... * [ ok ] * Starting DHCP Client Daemon ... * [ ok ] * Setting clock via the NTP client 'ntpdate' ... * [ ok ] * Starting cronie ... * [ ok ] * Starting dbus ... * [ ok ] * Starting cupsd ... * [ ok ] * Starting gpm ... * [ ok ] * Mounting network filesystems ... * [ ok ] * Starting local ... , and in /var/log/message I see: Aug 22 12:36:56 ACM dhcpcd[2435]: dhcpcd-10.0.2 starting Aug 22 12:36:56 ACM dhcpcd[2437]: dev: loaded udev Aug 22 12:36:56 ACM dhcpcd[2437]: DUID 00:01:00:01:20:97:45:37:60:45:cb:9c:5b:d6 Aug 22 12:36:56 ACM dhcpcd[2437]: enp38s0: waiting for carrier Aug 22 12:36:58 ACM kernel: igb :26:00.0 enp38s0: igb: enp38s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Aug 22 12:36:59 ACM dhcpcd[2437]: enp38s0: carrier acquired Aug 22 12:36:59 ACM kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp38s0: link becomes ready Aug 22 12:36:59 ACM dhcpcd[2437]: enp38s0: IAID cb:9c:5b:d6 Aug 22 12:37:00 ACM dhcpcd[2437]: enp38s0: rebinding lease of 192.168.178.86 Aug 22 12:37:00 ACM dhcpcd[2437]: enp38s0: probing address 192.168.178.86/24 Aug 22 12:37:05 ACM dhcpcd[2437]: enp38s0: leased 192.168.178.86 for 864000 seconds Aug 22 12:37:05 ACM dhcpcd[2437]: enp38s0: adding route to 192.168.178.0/24 Aug 22 12:37:05 ACM dhcpcd[2437]: enp38s0: adding default route via 192.168.178.1 .. > > Aug 22 09:24:29 ACM /etc/init.d/net.enp38s0[2695]: The dhcpcd version > > is too old. Please upgrade. > I'm running the same version like you and do not see this message, but this > does not explain why you get this printed out. I don't understand what I just did, by deleting net.enp38s0, though it appeared to have fixed the problem. That worries me. Could you possibly explain to me a bit more what that removal did? Thanks! > I expect you have the dhcpcd service enabled. Does your NIC come up and > obtain an IP address via dhcpcd, if you remove dhcpcd from the default > runlevel? Careful you do not lock yourself out, if this is a remote system > and no network comes up w
[gentoo-user] Spurious error messages at boot up from the new dhcpcd
Hello, gentoo. With the new dhcpcd-10.0.2 (previous version being ?9.5.1) I get spurious error messages on boot up. In particular, I see this: * Starting DHCP Client Daemon ... * [ ok ] * Bringing up interface enp38s0 * Caching network module dependencies * config_enp38s0 not specified; defaulting to DHCP * dhcp ... * The dhcpcd version is too old. Please upgrade. * [ !! ] * ERROR: net.enp38s0 failed to start .. However, after ~1 hour searching for the problem, I just tried using enp38s0 to ssh onto my ISP, and it worked. In /var/log/messages, I see the following: Aug 22 09:24:20 ACM dhcpcd[2435]: dhcpcd-10.0.2 starting Aug 22 09:24:20 ACM dhcpcd[2437]: dev: loaded udev Aug 22 09:24:20 ACM dhcpcd[2437]: DUID 00:01:00:01:20:97:45:37:60:45:cb:9c:5b:d6 Aug 22 09:24:20 ACM dhcpcd[2437]: enp38s0: waiting for carrier Aug 22 09:24:22 ACM kernel: igb :26:00.0 enp38s0: igb: enp38s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Aug 22 09:24:23 ACM dhcpcd[2437]: enp38s0: carrier acquired Aug 22 09:24:23 ACM kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp38s0: link becomes ready Aug 22 09:24:23 ACM dhcpcd[2437]: enp38s0: IAID cb:9c:5b:d6 Aug 22 09:24:24 ACM dhcpcd[2437]: enp38s0: rebinding lease of 192.168.178.86 Aug 22 09:24:24 ACM dhcpcd[2437]: enp38s0: probing address 192.168.178.86/24 Aug 22 09:24:28 ACM dhcpcd[2437]: enp38s0: leased 192.168.178.86 for 864000 seconds Aug 22 09:24:28 ACM dhcpcd[2437]: enp38s0: adding route to 192.168.178.0/24 Aug 22 09:24:28 ACM dhcpcd[2437]: enp38s0: adding default route via 192.168.178.1 Aug 22 09:24:29 ACM /etc/init.d/net.enp38s0[2686]: config_enp38s0 not specified; defaulting to DHCP Aug 22 09:24:29 ACM /etc/init.d/net.enp38s0[2695]: The dhcpcd version is too old. Please upgrade. Aug 22 09:24:29 ACM /etc/init.d/net.enp38s0[2527]: ERROR: net.enp38s0 failed to start .. So it would appear that everything is working, but I still get error messages. The "dhcpcd version is too old" is particularly galling, given that dhcpcd was updated yesterday. Could anybody suggest how I might get further with this problem? Thanks! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Please help me understand this emerge error message.
Hello, Paul. On Sat, Aug 12, 2023 at 11:15:05 +1000, Paul Colquhoun wrote: > On Saturday, August 12, 2023 4:46:17 A.M. AEST Alan Mackenzie wrote: > > Hello, Gentoo. > > For the past couple of days, after $ emerge --sync, I've tried > > $ emerge -auND @world > > .. It has come back very quickly with the error message: > > # > > !!! The ebuild selected to satisfy ">=net-misc/curl-7.21.5[ssl]" has unmet > > requirements. - net-misc/curl-8.1.2::gentoo USE="adns ftp gnutls http2 imap > > pop3 progress-meter smtp ssl tftp -alt-svc -brotli -gopher -hsts -idn > > -kerberos -ldap -mbedtls (-nghttp3) -nss -openssl -rtmp (-rustls) -samba > > -ssh (-sslv3) -static-libs -telnet -test -verify-sig -websockets -zstd" > > ABI_X86="(64) -32 (-x32)" CURL_SSL="openssl -gnutls -mbedtls -nss > > (-rustls)" > > The following REQUIRED_USE flag constraints are unsatisfied: > > curl_ssl_openssl? ( openssl ) > > The above constraints are a subset of the following complete expression: > > ssl? ( exactly-one-of ( curl_ssl_gnutls curl_ssl_mbedtls curl_ssl_nss > > curl_ssl_openssl curl_ssl_rustls ) ) curl_ssl_gnutls? ( gnutls ) > > curl_ssl_mbedtls? ( mbedtls ) curl_ssl_nss? ( nss ) curl_ssl_openssl? ( > > openssl ) curl_ssl_rustls? ( rustls ) > > # > > .. I don't understand what is meant by "curl_ssl_openssl? ( openssl )" in > > the above message. I assume it's talking about some USE flag, but which? > > openssl? curl_ssl_openssl? As a matter of interest, I have > > =dev-libs/openssl-3.0.9-r2 installed. > > Please help me understand what's happening. > > Thanks for the help! > In the USE flsgs you have: gnutls -openssl > In the CURL_SSL flags you have: openssl -gnutls > These 2 are contradicting each other. One says use gnutls instead of openssl, > the other says no, use openssl instead of gnutls. > Pick which option you want to use, and adjust the flags to agree on that > option. Thanks, that's what I did. I set openssl for curl (in /etc/portage/package.use), and the problem resolved itself. > -- > Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/ > Asking for technical help in newsgroups? Read this first: > http://catb.org/~esr/faqs/smart-questions.html#intro -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Please help me understand this emerge error message.
Hello, Arsen. On Fri, Aug 11, 2023 at 21:45:38 +0200, Arsen Arsenović wrote: > Alan Mackenzie writes: [ ] > > The following REQUIRED_USE flag constraints are unsatisfied: > > curl_ssl_openssl? ( openssl ) > A REQUIRED_USE of 'X? ( Y Z )' means that if X is set, Y and Z must be > set. In boolean algebra, it can be expressed as a X => ( Y AND Z ). OK, thanks! I tried to look up curl_ssl_openssl in use.desc and use.local.desc, but couldn't find it there. I think openssl was missing, too. So it didn't occur to me that they were themselves USE flags. > See https://wiki.gentoo.org/wiki/Required_USE_flags OK. > Hope that helps, have a lovely day. It does, thanks. I set the USE flag openssl for curl, and it all built OK. [ ] > -- > Arsen Arsenović -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Please help me understand this emerge error message.
On Fri, Aug 11, 2023 at 13:52:25 -0500, Dale wrote: > Alan Mackenzie wrote: > > Hello, Gentoo. > > For the past couple of days, after $ emerge --sync, I've tried > > $ emerge -auND @world > > .. It has come back very quickly with the error message: > > # > > !!! The ebuild selected to satisfy ">=net-misc/curl-7.21.5[ssl]" has unmet > > requirements. > > - net-misc/curl-8.1.2::gentoo USE="adns ftp gnutls http2 imap pop3 > > progress-meter smtp ssl tftp -alt-svc -brotli -gopher -hsts -idn -kerberos > > -ldap -mbedtls (-nghttp3) -nss -openssl -rtmp (-rustls) -samba -ssh > > (-sslv3) -static-libs -telnet > > -test -verify-sig -websockets -zstd" ABI_X86="(64) -32 (-x32)" > > CURL_SSL="openssl -gnutls -mbedtls -nss (-rustls)" > > The following REQUIRED_USE flag constraints are unsatisfied: > > curl_ssl_openssl? ( openssl ) > > The above constraints are a subset of the following complete expression: > > ssl? ( exactly-one-of ( curl_ssl_gnutls curl_ssl_mbedtls curl_ssl_nss > > curl_ssl_openssl curl_ssl_rustls ) ) curl_ssl_gnutls? ( gnutls ) > > curl_ssl_mbedtls? ( mbedtls ) curl_ssl_nss? ( nss ) curl_ssl_openssl? ( > > openssl ) curl_ssl_rustls? ( > > rustls ) > > # > > .. I don't understand what is meant by "curl_ssl_openssl? ( openssl )" in > > the above message. I assume it's talking about some USE flag, but which? > > openssl? curl_ssl_openssl? As a matter of interest, I have > > =dev-libs/openssl-3.0.9-r2 installed. > > Please help me understand what's happening. > > Thanks for the help! > I think I got that a while back. This is what I have for my USE flags > for that package. [ ] > I think it wants you to enable openssl or one of the other USE flag > options. Since I seem to recall having openssl installed already, I > just picked it. I'd try enabling that and see if the error goes away. That was the problem. Although I had openssl installed, I hadn't set the USE flag openssl for curl. When I did that, the problem went away. :-) > Hope that helps. It did. Thanks! > Dale > :-) :-) -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Please help me understand this emerge error message.
Hello, Gentoo. For the past couple of days, after $ emerge --sync, I've tried $ emerge -auND @world .. It has come back very quickly with the error message: # !!! The ebuild selected to satisfy ">=net-misc/curl-7.21.5[ssl]" has unmet requirements. - net-misc/curl-8.1.2::gentoo USE="adns ftp gnutls http2 imap pop3 progress-meter smtp ssl tftp -alt-svc -brotli -gopher -hsts -idn -kerberos -ldap -mbedtls (-nghttp3) -nss -openssl -rtmp (-rustls) -samba -ssh (-sslv3) -static-libs -telnet -test -verify-sig -websockets -zstd" ABI_X86="(64) -32 (-x32)" CURL_SSL="openssl -gnutls -mbedtls -nss (-rustls)" The following REQUIRED_USE flag constraints are unsatisfied: curl_ssl_openssl? ( openssl ) The above constraints are a subset of the following complete expression: ssl? ( exactly-one-of ( curl_ssl_gnutls curl_ssl_mbedtls curl_ssl_nss curl_ssl_openssl curl_ssl_rustls ) ) curl_ssl_gnutls? ( gnutls ) curl_ssl_mbedtls? ( mbedtls ) curl_ssl_nss? ( nss ) curl_ssl_openssl? ( openssl ) curl_ssl_rustls? ( rustls ) # .. I don't understand what is meant by "curl_ssl_openssl? ( openssl )" in the above message. I assume it's talking about some USE flag, but which? openssl? curl_ssl_openssl? As a matter of interest, I have =dev-libs/openssl-3.0.9-r2 installed. Please help me understand what's happening. Thanks for the help! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New (?final) version of the patch - with GPM handling.
Hello, Peter.
I have another version of the patch which makes GPM usable on scrolled
consoles. I'd like to think that it's now final.
On Sat, Jan 28, 2023 at 14:41:53 +, Peter Humphrey wrote:
> On Friday, 27 January 2023 22:31:17 GMT Alan Mackenzie wrote:
> > On Fri, Jan 27, 2023 at 12:24:41 +, Peter Humphrey wrote:
> --->8
> > > I've attached the reject files.
> >
> > Thanks for these! It looks like it'll probably be straightforward to
> > amend the patch for 6.1.8. Are you currently running 6.1.8 as your main
> > kernel?
> Yes Alan, I'm running ~amd64, so 6.1.8 is the current kernel. I have 5.15.88
> as a backup.
OK, I'm enclosing a patch for each version, 5.15.x and 6.1.y. I'm not
aware of any outstanding bugs in these patches. In particular, the
following have been fixed since the previous version:
(i) The synchronisation between the "mouse" character buffer and the
contents of the screen is now 100%. In particular, when changing
fonts (e.g. at bootup), and when the Tux logos get removed from the
screen, things continue working.
(ii) CONFIG_LOGO (i.e. the Tuxes on bootup) can now be freely configured
without losing functionality.
Just a quick reminder of how to use these files for anybody else who
might be interested:
(i) cd /usr/src/linux-5.15.88-gentoo, or similar. (Or
...-6.1.x-gentoo).
(ii) patch -p1 < 5.15.80-GPM.20230203.diff (or the other one).
(iii) Configure the kernel as normal. Additionally, under Device
drivers/Graphic Support/Console display driver support, enable
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK, set the buffer size to
taste (it's default is 128 kB) and accept the default enablement of
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM.
(iv) Build the kernel and install it into your boot manager.
(v) Reboot and enjoy! You can now use GPM in scrolled consoles.
> --
> Regards,
> Peter.
--
Alan Mackenzie (Nuremberg, Germany).
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index b8f5bc19416d..5d5508209164 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];
#ifndef VT_SINGLE_DRIVER
@@ -286,8 +291,31 @@ 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) /* Should never happen! */
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ if (vc->vc_softback_in >= vc->vc_softback_curr)
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr;
+ else
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr
+ + 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)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -295,6 +323,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.. */
@@ -316,101 +345,96 @@ 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_end(vc) (vc->vc_uniscr_buf +
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling.
Hello, Peter.
On Fri, Jan 27, 2023 at 12:24:41 +, Peter Humphrey wrote:
> On Thursday, 26 January 2023 20:28:36 GMT Alan Mackenzie wrote:
> --->8
> > Again, on any problems please let me know and I'll try to fix them. As
> > ever, there are no guarantees, etc., etc., etc. My only promise is that
> > there's no malicious code in the patch.
> Good news! Well, partly... :)
> I applied the new patch to 5.15.88 and it seems fine. I'll have to test it in
> use and let you know.
I have since found a few bugs in that patch. Mainly they're to do with
losing 18 lines[*] GPM-ability at the earliest boot messages, when
changing font size, and things like that.
[*] 18 lines is the difference between 49 lines (from an 11x22 font such
as ter-122n) and 67 lines (from an 8x16 font like lat1-16) which fit on
the screen.
I've also discovered that when CONFIG_LOGO (i.e. displaying Tux at boot
up) is enabled, all boot messages which preceded the Tuxes become
invisible to GPM, and they cannot be selected. I don't (yet) know why
this is happening, but the obvious workaround is to disable CONFIG_LOGO
in one's kernel configuration.
I've found yet another bug which it's taken me a few hours to determine
is nothing to do with me. It goes like this: boot up in an 11x22 font
such as ter-122n, and move the mouse on that screen. Run the command
setfont lat1-16, which will resize the existing text. The GPM mouse is
now restricted to the 174x49 rectangle in the top left of the screen.
This is the bug. To free it, switch to a different tty and move the
mouse there. On returning to the first tty, the mouse can now be moved
over the entire screen.
The cause of this bug is that GPM does not connect up with screen
resizing events. The only time it determines a tty's size is when it
detects the tty has been switched. Not a big bug, but somewhat
annoying.
> Patching 6.1.8 failed, though, whereas the previous 5.15.80-scroll.
> 20221212.diff succeeded:
I haven't actually looked at any versions except for 5.15.80 and 5.15.88
so far.
> # patch -p1 < /usr/local/src/5.15.80-GPM.20230126.diff
> patching file drivers/tty/vt/vt.c
> Hunk #37 succeeded at 4748 (offset -1 lines).
> Hunk #38 succeeded at 5049 (offset -1 lines).
> Hunk #39 FAILED at 5353.
> 1 out of 39 hunks FAILED -- saving rejects to file drivers/tty/vt/vt.c.rej
> patching file drivers/video/console/Kconfig
> Hunk #1 succeeded at 99 (offset 1 line).
> patching file drivers/video/fbdev/core/fbcon.c
> Hunk #1 succeeded at 3171 (offset 19 lines).
> patching file include/linux/console_struct.h
> Hunk #2 FAILED at 170.
> 1 out of 2 hunks FAILED -- saving rejects to file include/linux/
> console_struct.h.rej
> patching file include/linux/vt_kern.h
> Hunk #1 succeeded at 114 (offset -1 lines).
> I've attached the reject files.
Thanks for these! It looks like it'll probably be straightforward to
amend the patch for 6.1.8. Are you currently running 6.1.8 as your main
kernel?
Anyhow, I'll probably post another patch with corrections in the next
day or two. Thanks for the testing!
> --
> Regards,
> Peter.
> --- drivers/tty/vt/vt.c
> +++ drivers/tty/vt/vt.c
> @@ -5353,10 +5965,19 @@ EXPORT_SYMBOL_GPL(screen_glyph);
>
> u32 screen_glyph_unicode(const struct vc_data *vc, int n)
> {
> - struct uni_screen *uniscr = get_vc_uniscr(vc);
> + int y = n / vc->vc_cols, x = n % vc->vc_cols;
> + uint32_t *ln = vc->vc_uniscr_curr + y * vc->vc_cols;
>
> - if (uniscr)
> - return uniscr->lines[n / vc->vc_cols][n % vc->vc_cols];
> + if (vc->vc_uniscr_curr) {
> + if (ln >= vc_uniscr_buf_end(vc))
> + ln -= vc->vc_uniscr_char_size;
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM
> + ln -= vc->vc_softback_lines * vc->vc_cols;
> + if (ln < vc->vc_uniscr_buf)
> + ln += vc->vc_uniscr_char_size;
> +#endif
> + return ln[x];
> + }
> return inverse_translate(vc, screen_glyph(vc, n * 2), 1);
> }
> EXPORT_SYMBOL_GPL(screen_glyph_unicode);
> --- include/linux/console_struct.h
> +++ include/linux/console_struct.h
> @@ -170,7 +181,11 @@ struct vc_data {
> struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg
> console for this display */
> struct uni_pagedir *vc_uni_pagedir;
> struct uni_pagedir **vc_uni_pagedir_loc; /* [!] Location of uni_pagedir
> variable for this console */
> - struct uni_screen *vc_uni_screen; /* unicode screen content */
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM
> + uint32_t *vc_uniscr_buf;/* Address of unicode screen content */
> + unsigned int vc_uniscr_char_size; /* Size of *vc-uniscr_buf in 32-bit
> chars */
> + uint32_t *vc_uniscr_curr; /* Pos of first char of (unscrolled)
> screen */
> +#endif
> /* additional information is in vt_kern.h */
> };
>
--
Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling.
Hello, Peter.
On Sun, Jan 01, 2023 at 15:13:02 +, Alan Mackenzie wrote:
> On Sat, Dec 31, 2022 at 16:13:23 +0000, 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.
[ ]
> 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.
OK, I'm now including a revised patch which is less imperfect. ;-)
To use it, please apply it to the vanilla gentoo-sources 5.15.88 (or
similar) with the usual:
patch -p1 < 5.15.80-GPM.20230126.diff
, followed by configuring in CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
and CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM, and setting an
appropriate scrollback buffer size as already done. The ..._GPM is new,
but is enabled by default. Build and install the kernel, then reboot
into it, to try it out.
I think it will work better than the previous patch.
> >>>> 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.
Again, on any problems please let me know and I'll try to fix them. As
ever, there are no guarantees, etc., etc., etc. My only promise is that
there's no malicious code in the patch.
> > > --
> > > Regards,
> > > Peter.
--
Alan Mackenzie (Nuremberg, Germany).
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index b8f5bc19416d..58332d1dd923 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];
#ifndef VT_SINGLE_DRIVER
@@ -286,8 +291,38 @@ 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) /* Should never happen! */
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ /* OLD STOUGH, 2023-01-26 */
+ /* scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr; */
+ /* if (scrolled_expanse < 0) */
+ /* scrolled_expanse += vc->vc_softback_end */
+ /* - vc->vc_softback_buf; */
+ /* NEW STOUGH, 2023-01-26 */
+ if (vc->vc_softback_in >= vc->vc_softback_curr)
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr;
+ else
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr
+ + vc->vc_softback_end - vc->vc_softback_buf;
+ /* END OF NEW STOUGH */
+ if (offset >= scrolled_expanse)
+ return (unsigned short *)(vc->vc_origin
+ + (offset -
scrolled_expanse));
+ else {
+ softback_pos = vc->vc_softback_curr + offset;
+
Re: [gentoo-user] Help!!! My system won't boot. (?lvm?) :-(
Hello, Alan.
On Wed, Jan 11, 2023 at 20:16:07 +, Alan J. Wylie wrote:
> Alan Mackenzie writes:
> > My system isn't booting. In particular, most of the SSD partitions
> > won't mount, because they are not under /dev any more. The root
> > partition, /dev/md125 mounts, but that is all.
> > These partitions are lvm partitions under RAID-1 (software RAID). They
> > simply fail to appear in /dev/mapper on boot up.
> > I've managed to bring my system up using a Rescue-DVD followed by
> > chroot. This shows that the partions on the SSD are basically
> > undamaged.
> > I strongly suspect that my emerge update from last night is to blame.
> It was.
> Been there, done that myself.
> Mount your filesystems from the rescue boot and chroot into them.
> Re-emerge lvm2 with the "lvm" flag enabled.
Many thanks, indeed! That was the cause of my problem, and re-emerging
lvm2 with that USE flag set solved it completely.
> See
> https://www.gentoo.org/support/news-items/2022-11-19-lvm2-default-USE-flags.html
Yes. There was even a news item about it back in November. I've read
it again, and it seems too vague to me. For example, it says:
>>> If you use LVM2 for any partitions, or if you use tools like
>>> 'lvchange', you should enable USE=lvm.
, without saying in detail anywhere what it means to "use" LVM2. I
wasn't aware of "using" LVM2 when I read that news item, so I just
carried on, blithely unaware of the coming catastrophe. ;-)
Still, it's OK, now.
> Some of these commands (or similar) in the rescue boot might be helpful:
> mkdir -p /mnt/{usr,var,home,work,boot,dev,sys,proc}
> mount /dev/mapper/vg0-root /mnt
> mount /dev/mapper/vg0-usr /mnt/usr
> mount /dev/mapper/vg0-var /mnt/var
> mount /dev/mapper/vg1-home /mnt/home
> mount /dev/mapper/vg1-work /mnt/work
> mount /dev/sda1/mnt/boot
> mount -o bind /dev /mnt/dev
> mount -o bind /dev/pts /mnt/dev/pts
> mount -o bind /dev/shm /mnt/dev/shm
> mount -o bind /sys /mnt/sys
> mount -o bind /proc/mnt/proc
> PATH=/bin:/sbin:/usr/bin:/usr/sbin \
> SHELL=/bin/bash \
> chroot /mnt
Thanks for that, too. I actually created a small script with commands
like these when I was installing Gentoo ~5 years ago, and I adapted
that, saving the heavy labour of working out again that the flag in
mount that I need is -o bind. :-)
> --
> Alan J. Wylie
> https://www.wylie.me.uk/
> Dance like no-one's watching. / Encrypt like everyone is.
> Security is inversely proportional to convenience
--
Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Help!!! My system won't boot. (?lvm?) :-(
Hello, Gentoo. My system isn't booting. In particular, most of the SSD partitions won't mount, because they are not under /dev any more. The root partition, /dev/md125 mounts, but that is all. These partitions are lvm partitions under RAID-1 (software RAID). They simply fail to appear in /dev/mapper on boot up. (I don't remember the exact error message, here). I've managed to bring my system up using a Rescue-DVD followed by chroot. This shows that the partions on the SSD are basically undamaged. I strongly suspect that my emerge update from last night is to blame. There, lvm2-2.03.17-r1 was reinstalled after other packages (dependencies) were updated. The order of these packages, taken from /var/log/emerge.log was: 1. dev-libs/mpfr-4.1.1_p1 2. dev-lang/mujs-1.3.2 3. sys-apps/util-linux-2.38.1 4. sys-apps/systemd-utils-251.10 5. dev-python/installer-0.6.0 6. app-text/lib-paper-2.0.4 7. app-misc/ca-certificates-20211016.3.86 8. sys-fs/lvm2-2.03.17-r1 .. There were a few more packages after that, a total of 23. If any of these is relevant, then it is surely 3. or 4. lvm2 itself was merely rebuilt. I've had a quick scan of the gentoo bugzilla, but not found anything relevant there. Please help me get my system booting again! Thanks! -- Alan Mackenzie (Nuremberg, Germany).
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
-
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling.
Hello again, Peter. 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: > > What I'm thinking here is that you might be installing a font which is > > bigger than the 8x16 standard that you appear to be booting with. To > > check this, would you please do: > > # file /lib/rc/console/font > > , which should return a message like: > > /lib/rc/console/font: Linux/i386 PC Screen Font v1 data, 256 characters, > > Unicode directory, 8x16 > > What is the size of this font, here (where it says 8x16 for my font)? > > The reason I ask is, I've got a horrible suspicion that one of the C > > functions which copies screen data when the screen size is changed can > > only copy to a same sized or (possibly) _bigger_ screen (i.e. with a > > smaller font). If this is indeed the case, it might explain why you're > > seeing a hang, here. > 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. > 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. > 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. Again, thanks for such effective testing! > -- > Regards, > Peter. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling.
Hello, Peter, thanks for the reply. The photo was extremely helpful! On Sat, Dec 31, 2022 at 09:42:54 +, Peter Humphrey wrote: > Morning Alan, > On Thursday, 29 December 2022 19:50:18 GMT Alan Mackenzie wrote: > > I've got a first version of a patch which attempts to handle GPM in > > conjunction with scrolling. It's imperfect - for example, I can't get it > > to select anything the first 66 lines of the console's displayed boot-up > > messages. Nevertheless it may be useful. [ ] > > Please let me know of any problems you encounter with this new facility, > > so that I can try to fix them. Thanks! > Bad news, I'm afraid. After following your instructions carefully, the > new kernel hangs early in the boot process. The first time I tried it > it seemed to be just as the first HID message had been displayed; the > second time I didn't see that (could be my eyes). > I've attached a photo of the console. The interesting bit of the photo is right at the end, where the INIT: version 3.05 booting appears. The corresponding section from my (successful) boot is: [4.007014] Write protecting the kernel read-only data: 24576k [4.008379] Freeing unused kernel image (text/rodata gap) memory: 2036K [4.009611] Freeing unused kernel image (rodata/data gap) memory: 1364K [4.010670] Run /sbin/init as init process INIT: version 3.05 booting [4.041455] setfont (884) used greatest stack depth: 13584 bytes left [4.048471] init-early.sh (882) used greatest stack depth: 12888 bytes left OpenRC 0.42.1 is starting up Gentoo Linux (x86_64) * Mounting /proc ... * Mounting /run ... * /run/openrc: creating directory * /run/lock: creating directory * /run/lock: correcting owner What I see is a message saying something about init-early.sh being called. I don't know what, exactly, is calling it, but I tracked the file down to /lib/rc/sh/init-early.sh. It is a part of rc-init, despite the message being printed with a kernel style time stamp. This message doesn't appear in your photo. I'm guessing init-early.sh was called, but never returned. init-early.sh does two things: it sets a console font (see the message about setfont) and sets a key mapping. It does that via symbolic links to /etc/init.d. The console font is more interesting, here. It installs the font which is in /lib/rc/console/font. What I'm thinking here is that you might be installing a font which is bigger than the 8x16 standard that you appear to be booting with. To check this, would you please do: # file /lib/rc/console/font , which should return a message like: /lib/rc/console/font: Linux/i386 PC Screen Font v1 data, 256 characters, Unicode directory, 8x16 What is the size of this font, here (where it says 8x16 for my font)? The reason I ask is, I've got a horrible suspicion that one of the C functions which copies screen data when the screen size is changed can only copy to a same sized or (possibly) _bigger_ screen (i.e. with a smaller font). If this is indeed the case, it might explain why you're seeing a hang, here. > -- > Regards, > Peter. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling.
Hello again, Peter.
On Wed, Dec 14, 2022 at 10:53:07 +, Alan Mackenzie wrote:
> 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!
I've got a first version of a patch which attempts to handle GPM in
conjunction with scrolling. It's imperfect - for example, I can't get it
to select anything the first 66 lines of the console's displayed boot-up
messages. Nevertheless it may be useful.
In particular, moving the mouse over an already scrolled area no longer
corrupts that area. Also, one can select text from a scrolled area.
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.
Note that it uses ~twice as much memory as the previous scrolling
buffers, giving a total of ~three times as much memory used. This
shouldn't really be a problem on a modern machine with 16GB or 32GB of
RAM.
Please let me know of any problems you encounter with this new facility,
so that I can try to fix them. Thanks!
> > --
> > Regards,
> > Peter.
--
Alan Mackenzie (Nuremberg, Germany).
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index d7aadca5107d..c453c6031098 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 @@
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch.
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] Soft scrolling on framebuffer consoles - New version of the patch.
Hello, Mike. On Mon, Dec 12, 2022 at 19:29:43 +, Mike Civil wrote: > Many thanks for this. > I can confirm that it patches, compiles and works on 6.1 :) Thanks for the testing! 6.1 _is_ up to date. :-) -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch.
Hello, Gentoo.
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.
The purpose of the patch is to enable you to scroll a linux console text
display up and down by half a screen by typing and
.
To use this patch, proceed thusly:
(i) cd /usr/src/linux-5.15.80, or similar. Get the attached patch file,
5.15.80-scroll-20221212.diff into this directory.
(ii) patch -p1 < 5.15.80-scroll-20221212.diff.
(iii) Configure the kernel in your usual way. The extra items added by
the patch are CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK and
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE, to be found in make
menuconfig under Device Drivers/Graphic Support/Console display driver
support. The help items for these should explain them adequately.
(iv) Build the kernel.
(v) Put the new kernel into your usual boot manager.
(vi) Reboot and enjoy!
As far as I know this patch should be safe (apart from the mysterious
alleged security problem which caused the soft scrolling to be removed
from the kernel in the first place). There is certainly nothing
malicious in it. But if it does break anything for you, you get to keep
the pieces. But if anything does go wrong, please tell me about it
(preferably here on the list, but by private email if you'd prefer), so
that I can try and fix it.
--
Alan Mackenzie (Nuremberg, Germany).
* Unmerged path .config
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index b8f5bc19416d..d7aadca5107d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];
#ifndef VT_SINGLE_DRIVER
@@ -287,7 +292,7 @@ static inline unsigned short *screenpos(const struct
vc_data *vc, int offset,
bool viewed)
{
unsigned short *p;
-
+
if (!viewed)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -616,6 +621,218 @@ static void vc_uniscr_debug_check(struct vc_data *vc)
}
}
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static void con_update_softback(struct vc_data *vc)
+{
+ int l = vc->vc_softback_size / vc->vc_size_row;
+ if (l > 5)
+ {
+ vc->vc_softback_end = vc->vc_softback_buf + l * vc->vc_size_row;
+ vc->vc_softback_top = vc->vc_softback_buf;
+ }
+ else
+ /* Smaller scrollback makes no sense, and 0 would screw
+ the operation totally */
+ vc->vc_softback_top = 0;
+}
+
+static int concon_set_origin(struct vc_data *vc)
+{
+ if (vc->vc_softback_lines)
+ concon_scrolldelta(vc, vc->vc_softback_lines);
+ return 0;
+}
+
+#define advance_row(p, delta) (unsigned short *)((unsigned long)(p) + (delta)
* vc->vc_size_row)
+
+static void con_redraw_softback(struct vc_data *vc, /* struct display *p, */
+ long delta)
+{
+ int count = vc->vc_rows;
+ unsigned short *d, *s;
+ unsigned long n;
+ int line = 0;
+
+ if (!vc->vc_softback_lines)
+ vc->vc_char_at_pos = scr_readw((u16 *)vc->vc_pos);
+
+ d = (u16 *) vc->vc_softback_curr;
+ if (d == (u16 *) vc->vc_softback_in)
+ d = (u16 *) vc->vc_origin;
+ n = vc->vc_softback_curr + delta * vc->vc_size_row;
+ vc->vc_softback_lines -= delta;
+ if (delta < 0) {
+ if (vc->vc_softback_curr < vc->vc_softback_top
+ && n < vc->vc_softback_buf) {
+ n += vc->vc_softback_end - vc->vc_softback_buf;
+ if (n < vc->vc_softback_top) {
+ vc->vc_softback_lines -=
+ (vc->vc_softback_top - n) / vc->vc_size_row;
+ n = vc->vc_softback_top;
+ }
+ } else if (vc->vc_softback_curr >= vc->vc_softback_top
+ && n < vc->vc_softback_top) {
+ vc->vc_softback_lines -=
+ (vc->vc_softback_top - n) / vc->vc_size_row;
+ n = vc->vc_softback_top;
+ }
+ } else {
+ if (vc->vc_softback_curr > vc->vc_softback_in
+
[gentoo-user] Joining PDFs and/or jpegs together. Help, please!
Hello, Gentoo, I'm back again after something kicked me off the mailing list some while ago. I have a problem, in that I need to join several PDFs or jpegs output from xsane (the scanner program) into a single document. I don't know which program can do this for me. Would somebody please recommend one (or even two) to me, please. Thanks! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Hard drive error from SMART
On Sat, Apr 16, 2022 at 19:58:22 +0100, Neil Bothwick wrote: > -- > Neil Bothwick > If Yoda so strong in force is, why words in right order he cannot put? Vielleicht, weil seine Muttersprache Deutsch ist. :-) -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] How do I get a core dump from seg-faulting software?
Hello, Karl. On Thu, Dec 16, 2021 at 17:32:58 +0100, k...@aspodata.se wrote: > Alex: > > I've got CONFIG_ELF_CORE and CONFIG_COREDUMP both configured to yes in > > my kernel. > > When I do > > $ uclimit -H -c > > , it tells me "unlimited". > > But still, no dump. :-( > > What am I missing? > Have you tried: > $ man gcore > $ man 5 core I've looked at them now, thanks. It was tastytea who spotted the crux, the file /etc/security/limits.conf. > Regards, > /Karl Hammar -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] How do I get a core dump from seg-faulting software?
Hello, Rich. On Thu, Dec 16, 2021 at 15:23:53 -0500, Rich Freeman wrote: > On Thu, Dec 16, 2021 at 10:55 AM Alan Mackenzie wrote: > > But still, no dump. :-( > > What am I missing? > Are you using systemd? It has a mechanism to consolidate core dumps > to a system directory with a tool to view/debug them and retention > policies. I think that all is enabled by default, but it has been a > while since I touched it. If it is enabled then that might explain > why dumps aren't where you expect them. No, I'm on openrc. I think tastytea's answer will work. Thanks! > -- > Rich -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] How do I get a core dump from seg-faulting software?
Hello, tastytea. On Fri, Dec 17, 2021 at 00:18:12 +0100, tastytea wrote: > On 2021-12-16 15:55+0000 Alan Mackenzie wrote: > > Hello, Gentoo. > > I'm developing software, and it crashes in its build process. I want > > a core dump, to help find out where and why it's crashing. > > I've got CONFIG_ELF_CORE and CONFIG_COREDUMP both configured to yes in > > my kernel. > > When I do > > $ uclimit -H -c > > , it tells me "unlimited". > > But still, no dump. :-( > > What am I missing? > You need to enable them explicitly. If you're using PAM: > echo '* soft core unlimited' > /etc/security/limits.conf > It only has an effect after your next login. For more information, see > <https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces#Core_dumps>. Thanks greatly! This was a very helpful answer. I've now edited that file, and will be ready next time there's a problem like this. As half expected when you ask a question like this, I found the problem in my build software anyhow. I was doing one too many pointer dereferences on a (in C) **bool. > Kind regards, tastytea > -- > Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at > <https://tastytea.de/tastytea.asc>. -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] How do I get a core dump from seg-faulting software?
Hello, Gentoo. I'm developing software, and it crashes in its build process. I want a core dump, to help find out where and why it's crashing. I've got CONFIG_ELF_CORE and CONFIG_COREDUMP both configured to yes in my kernel. When I do $ uclimit -H -c , it tells me "unlimited". But still, no dump. :-( What am I missing? -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Soft scrolling on framebuffer consoles - New versions of the patches.
Hello, Gentoo.
Here are the latest versions of my soft scrolling patch for the kernel
lines 5.10.xx and 5.14.xx. They fix bugs where a PC would crash if it
was initialised with a 25x80 console and later changed to a full
resolution frame buffer screen. It also now works (so I am told) for
kernels initialised with parameters like vga=791.
To use one of these (the right one for your kernel version) do:
(i) cd /usr/src/linux-5.10.61-gentoo, or similar. Extract the right
patch file to that directory. (Don't worry about having > 61 for a
kernel version. Just use it!)
(ii) patch -p1 < 5.10.61-scroll.20211007.diff.
(iii) Configure the kernel in your usual way. The extra items added by
the patch are CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK and
CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE, to be found in make
menuconfig under Device Drivers/Graphic Support/Console display driver
support. The help items for these should explain them adequately.
(iv) Build the kernel.
(v) Put the new kernel into your usual boot manager.
(vi) Reboot and enjoy!
As far as I know this patch should be safe (apart from the mysterious
alleged security problem which caused the soft scrolling to be removed
from the kernel in the first place). There is certainly nothing
malicous in it. But if it does break anything for you, you get to keep
the pieces. But if anything does go wrong, please tell me about it
(preferably here on the list, but by private email if you'd prefer), so
that I can try and fix it.
--
Alan Mackenzie (Nuremberg, Germany).
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 06757b1d4aec..c2061813c825 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];
#ifndef VT_SINGLE_DRIVER
@@ -287,7 +292,7 @@ static inline unsigned short *screenpos(const struct
vc_data *vc, int offset,
bool viewed)
{
unsigned short *p;
-
+
if (!viewed)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -616,6 +621,218 @@ static void vc_uniscr_debug_check(struct vc_data *vc)
}
}
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static void con_update_softback(struct vc_data *vc)
+{
+ int l = vc->vc_softback_size / vc->vc_size_row;
+ if (l > 5)
+ {
+ vc->vc_softback_end = vc->vc_softback_buf + l * vc->vc_size_row;
+ vc->vc_softback_top = vc->vc_softback_buf;
+ }
+ else
+ /* Smaller scrollback makes no sense, and 0 would screw
+ the operation totally */
+ vc->vc_softback_top = 0;
+}
+
+static int concon_set_origin(struct vc_data *vc)
+{
+ if (vc->vc_softback_lines)
+ concon_scrolldelta(vc, vc->vc_softback_lines);
+ return 0;
+}
+
+#define advance_row(p, delta) (unsigned short *)((unsigned long)(p) + (delta)
* vc->vc_size_row)
+
+static void con_redraw_softback(struct vc_data *vc, /* struct display *p, */
+ long delta)
+{
+ int count = vc->vc_rows;
+ unsigned short *d, *s;
+ unsigned long n;
+ int line = 0;
+
+ if (!vc->vc_softback_lines)
+ vc->vc_char_at_pos = scr_readw((u16 *)vc->vc_pos);
+
+ d = (u16 *) vc->vc_softback_curr;
+ if (d == (u16 *) vc->vc_softback_in)
+ d = (u16 *) vc->vc_origin;
+ n = vc->vc_softback_curr + delta * vc->vc_size_row;
+ vc->vc_softback_lines -= delta;
+ if (delta < 0) {
+ if (vc->vc_softback_curr < vc->vc_softback_top
+ && n < vc->vc_softback_buf) {
+ n += vc->vc_softback_end - vc->vc_softback_buf;
+ if (n < vc->vc_softback_top) {
+ vc->vc_softback_lines -=
+ (vc->vc_softback_top - n) / vc->vc_size_row;
+ n = vc->vc_softback_top;
+ }
+ } else if (vc->vc_softback_curr >= vc->vc_softback_top
+ && n < vc->vc_softback_top) {
+ vc->vc_softback_lines -=
+ (vc->vc_softback_top - n) / vc->vc_size_row;
+ n = vc->vc_softback_top;
+ }
+ } else {
+ if (vc->vc_softback_curr > vc->vc_softback_in
+ && n >= vc->vc_softback_end) {
+ n +
Re: [gentoo-user] console scrollback (kernel 5.14)
Hello, Jorge. On Fri, Sep 24, 2021 at 23:44:51 +, Jorge Almeida wrote: > On Fri, Sep 24, 2021 at 5:29 PM Alan Mackenzie wrote: > Hello, Alan > > > $ patch -p0 <../patch_for_5.14.diff > > > patching file ./drivers/tty/vt/vt.c > > > Hunk #1 FAILED at 3208. > > > 1 out of 1 hunk FAILED -- saving rejects to file ./drivers/tty/vt/vt.c.rej > > attached. Please start again from a gentoo-sources without any previous > > traces of the scrollback patches, and apply that patch. _Surely_ it > > should work this time. > Sure enough, the patch was succesful. Unfortunately, I cannot test it, > because my computer is out of luck (big thunderstorm, crappy power > provider, not-so-smart owner). I'm sorry to hear it. I'm sure you've done it already, but get a decent backup from that machine somehow while it is still even partly working. > I can ssh into it and it all seems fine, but VT's other than tty1 go > dim after 1 or 2 seconds (showing the greeting) and then go black; I > can login blindly! I'm sure it has nothing to do with the patch, > since I also booted the former kernel (for which the previous patch > has been applied with success as expected) and it happens the same. > Damaged UPS or MO, maybe... Anyway, I'll try again when I manage to > fix or replace the computer and I'll report then. OK, thanks! > Thanks, > Jorge Almeida > P.S. I just noticed you mention gentoo-sources. I use the vanilla > kernel from kernel.org. Could that be a problem? Highly unlikely. I doubt very much there's any difference in the tty code between vanilla and gentoo-sources, but even so, I'm now basing my patches on a Linux repository cloned from their central repository server. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Advice sought on the use of a VCS (specifically git) to keep track of my Softscroll patch.
Hello, Marco. On Fri, Sep 24, 2021 at 10:56:39 +0200, Marco Rebhan wrote: > On Friday, 24 September 2021 10:49:53 CEST Peter Humphrey wrote: > > This raises the question of which kernel to work with: vanilla source > > or Gentoo? > Gentoo's patches are kept minimal so it shouldn't really matter (and I > don't think they'd touch this part of the code anyway). Personally I'd > make the patches against the vanilla sources. That's just what I'm doing, for these reasons. I'm not even sure Gentoo maintains a git repository with all the gentoo-sources realeases. > -Marco -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Advice sought on the use of a VCS (specifically git) to keep track of my Softscroll patch.
Hello, Ramon. On Thu, Sep 23, 2021 at 22:56:34 +0200, Ramon Fischer wrote: > If GitHub is preferred, there is also an official GitHub repository of > the Linux Kernel: https://github.com/torvalds/linux Thanks, but here GitHub is most emphatically _not_ preferred. ;-) I've managed to clone a repo from the official site that Marco cited, so I'm up and running. > -Ramon -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Advice sought on the use of a VCS (specifically git) to keep track of my Softscroll patch.
Hello, Marco. On Thu, Sep 23, 2021 at 21:27:26 +0200, Marco Rebhan wrote: > On Thursday, 23 September 2021 20:23:57 CEST Alan Mackenzie wrote: > > Where would I find a suitable kernel git repository to clone? An > > "official" repository, whatever that means? Ideally, I want one with > > just the various kernel releases, not one containing gigabytes of > > intermediate versions. Where would I even start searching to find > > this out? > Hey Alan, > The official repository I think is > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/. > What I would do is apply your patch on top of that, and then to update > it, rebase the patch onto the new upstream commit you want to update to. > This leads to your patches always being at the tip of the commit history > and not somewhere buried between commits from upstream. Thanks, that was a very great deal of help. Rather than downloading the /torvalds/ repo, I went for /linux-stable-rc/, which appears to have release versions going back a long, long way. It has a tag for every such version, which is just what I wanted. So far, I've constructed a clean patch which applies to 5.14.5, for Jorge Almeida. Maybe I can clean up the others over the weekend. I've decided to create a single branch for each kernel version I'm patching. So, so far, I've got a branch called scroll-5.14.5. From that I have recreated a clean diff file for that version. I may not be doing a lot of rebasing, since I'm creating patches for already released versions rather than keeping up to date with the head of the master branch. > However, this rewrites git history so you'd have to force push the > branch to whatever remote you're tracking it in, so keep that in mind. I don't envisage any upstream accepting my patch. The powers that be were adamant that the soft scrolling be removed from the official kernel, ostensibly due to security reasons. I may get around to posting the patch on the Gentoo wiki, but for now it'll just be on the mailing list, plus to any individual Linux user who asks for a copy. > You could do this though and additionally have another branch where you > track the patch files themselves that are rebased onto a certain kernel > commit (you can export them with "git format-patch upstream/master" if > upstream/master is whatever branch the patch is currently rebased on). > That of course you don't have to then force push. I'll probably have a more static system than that, doing a git pull when after a new gentoo-sources is released. > I hope this helps :P It did indeed. Thanks! > -Marco -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] console scrollback (kernel 5.14)
Hello, Jorge.
On Fri, Sep 24, 2021 at 09:22:45 +0100, Jorge Almeida wrote:
> On Thu, Sep 23, 2021 at 6:03 PM Alan Mackenzie wrote:
[ ]
> It still fails:
> $ patch -p0 <../patch_for_5.14.diff
> patching file ./drivers/tty/vt/vt.c
> Hunk #1 FAILED at 3208.
> 1 out of 1 hunk FAILED -- saving rejects to file ./drivers/tty/vt/vt.c.rej
Apologies once more. Late last night I managed to get a Linux kernel
git repository set up. :-) So, at least if there are any more
failures, they'll be systematic failures rather than erratic failures.
;-)
>From this I've constructed a complete clean 5.14.5 patch, which I've
attached. Please start again from a gentoo-sources without any previous
traces of the scrollback patches, and apply that patch. _Surely_ it
should work this time.
To apply the patch (you surely know this already), cd to the top of the
kernel tree, and use
$ patch -p1 < 5.14.5-scroll-20210924.diff
.. Alternatively, if you've got git, you could use
$ git apply 5.14.5-scroll-20210924.diff
.. Please let me know again how it works out. Thanks!
[ ]
> Thanks,
> Jorge Almeida
--
Alan Mackenzie (Nuremberg, Germany).
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index ef981d3b7bb4..17b51bdc9f6e 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];
#ifndef VT_SINGLE_DRIVER
@@ -287,7 +292,7 @@ static inline unsigned short *screenpos(const struct
vc_data *vc, int offset,
bool viewed)
{
unsigned short *p;
-
+
if (!viewed)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -616,6 +621,218 @@ static void vc_uniscr_debug_check(struct vc_data *vc)
}
}
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static void con_update_softback(struct vc_data *vc)
+{
+ int l = vc->vc_softback_size / vc->vc_size_row;
+ if (l > 5)
+ {
+ vc->vc_softback_end = vc->vc_softback_buf + l * vc->vc_size_row;
+ vc->vc_softback_top = vc->vc_softback_buf;
+ }
+ else
+ /* Smaller scrollback makes no sense, and 0 would screw
+ the operation totally */
+ vc->vc_softback_top = 0;
+}
+
+static int concon_set_origin(struct vc_data *vc)
+{
+ if (vc->vc_softback_lines)
+ concon_scrolldelta(vc, vc->vc_softback_lines);
+ return 0;
+}
+
+#define advance_row(p, delta) (unsigned short *)((unsigned long)(p) + (delta)
* vc->vc_size_row)
+
+static void con_redraw_softback(struct vc_data *vc, /* struct display *p, */
+ long delta)
+{
+ int count = vc->vc_rows;
+ unsigned short *d, *s;
+ unsigned long n;
+ int line = 0;
+
+ if (!vc->vc_softback_lines)
+ vc->vc_char_at_pos = scr_readw((u16 *)vc->vc_pos);
+
+ d = (u16 *) vc->vc_softback_curr;
+ if (d == (u16 *) vc->vc_softback_in)
+ d = (u16 *) vc->vc_origin;
+ n = vc->vc_softback_curr + delta * vc->vc_size_row;
+ vc->vc_softback_lines -= delta;
+ if (delta < 0) {
+ if (vc->vc_softback_curr < vc->vc_softback_top
+ && n < vc->vc_softback_buf) {
+ n += vc->vc_softback_end - vc->vc_softback_buf;
+ if (n < vc->vc_softback_top) {
+ vc->vc_softback_lines -=
+ (vc->vc_softback_top - n) / vc->vc_size_row;
+ n = vc->vc_softback_top;
+ }
+ } else if (vc->vc_softback_curr >= vc->vc_softback_top
+ && n < vc->vc_softback_top) {
+ vc->vc_softback_lines -=
+ (vc->vc_softback_top - n) / vc->vc_size_row;
+ n = vc->vc_softback_top;
+ }
+ } else {
+ if (vc->vc_softback_curr > vc->vc_softback_in
+ && n >= vc->vc_softback_end) {
+ n += vc->vc_softback_buf - vc->vc_softback_end;
+ if (n > vc->vc_softback_in) {
+ n = vc->vc_softback_in;
+ vc->vc_softback_lines = 0;
+ }
+ } else if (vc->vc_softback_curr <= vc->vc_softback_in
+ &&am
[gentoo-user] Advice sought on the use of a VCS (specifically git) to keep track of my Softscroll patch.
Hello, Gentoo. Over the last few months I've posted several versions of my kernel patch which re-enables soft scrollback. I thought at the time I could just keep a few files informally in my home directory. But I'm already getting confused about what is where, what applies to which kernel versions and so on. Clearly I need to put the patch into a version control system. I would appreciate some advice on this. I think I need to get a clone of the kernel's git repository, and maintain the patch in it as a branch or several branches. Or would it be feasible just to maintain the patch in a VCS? My feeling is that I really need the full repository. Where would I find a suitable kernel git repository to clone? An "official" repository, whatever that means? Ideally, I want one with just the various kernel releases, not one containing gigabytes of intermediate versions. Where would I even start searching to find this out? Once I've got this far, I'll need to think about a versioning scheme for the patch - there are irritating little differences in the console code between versions of the kernel, as recently pointed out by Jorge Almeida, so there would be irritating differences between versions of the patch. Maybe I could put it onto the Gentoo wiki, but that's not in the near future. Thanks for the help! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] console scrollback (kernel 5.14)
Hello, Jorge. On Wed, Sep 22, 2021 at 22:40:11 +0100, Jorge Almeida wrote: > On Wed, Sep 22, 2021 at 9:29 PM Alan Mackenzie wrote: > Hi Alan, thanks for the reply > > I must confess that somebody told me by private email that it fails on > > systems which change their screen geometry during boot-up. For example, > > a system which first boots into 80x25, then changes to a frame buffer. > > I know why this is happening, but I don't have a machine to debug it on, > > so the debugging is happening slowly, with the help of my correspondent. > > It also doesn't seem to work on machines with kernel parameters such as > > vga=791. > OK, I don't know much about this kind of stuff, but I don't think > there's a problem there. I have an integrated GPU (intel), driver > i915, resolution 1920x1080. It boots (via Refind) with the proper > resolution, and that's it. All the VTs show the same resolution and > font. I don't use a login manager. No problems, no change is supposed > to happen. I start an X session from a login shell, in any VT except > tty1, which I like to keep as console. Sounds pretty much like my setup. :-) > > I'm assuming that the patch you tried to apply was > > 5.10.49-scroll.20210715.diff. If so, please leave it applied (with the > > one failed hunk), and additionally apply this: > I may have missed some announcement from you, I'm using > diff.20210405.diff. I wasn't aware of newer versions. Is there an URL > to download it? I would try it before trying to apply the patch > included in your message. I'm currently discovering what version control systems are for. :-( Even though I've only posted two or three versions of my patch, I'm already having difficulty keeping track of it. I no longer believe keeping the patch informally is going to work. I think I'm going to have to clone the git repository of the kernel (about which I'm going to ask on another thread). Anyhow, back to the topic. There's no URL with my patch; it's purely posted on gentoo-users. Maybe I should put it into the Gentoo wiki. But first, I must get it into a proper VCS. As for the two(?) versions of my patch, they differed mainly in the aesthetics - diff.20210405.diff had lots of ugly maintainer comments in it. So, could I ask you please to try that 1-hunk patch I posted yesterday on top of the version you have. Please then tell me whether or not it works. I am going to get this unsystematic muddle sorted out. > Thanks, > Jorge Almeida -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] console scrollback (kernel 5.14)
Hello, Jorge.
On Sat, Sep 18, 2021 at 21:40:46 +0100, Jorge Almeida wrote:
> Hello, gentooers in general and Alan in particular
> I've been using Alan Mackenzie's patch until kernel 5.13, with
> success. It failed with 5.14.4 --yes, I know, but it doesn't hurt to
> try :)
I'm happy to know my patch is still useful.
I must confess that somebody told me by private email that it fails on
systems which change their screen geometry during boot-up. For example,
a system which first boots into 80x25, then changes to a frame buffer.
I know why this is happening, but I don't have a machine to debug it on,
so the debugging is happening slowly, with the help of my correspondent.
It also doesn't seem to work on machines with kernel parameters such as
vga=791.
That said, I'm hoping that the failure of the patch on 5.14.4 is just a
simple struct change in 5.14, which I hope to have corrected (but in
5.14.5). What used to be
while (!tty->stopped ...
has now become
while (!tty->flow.stopped ...
I'm assuming that the patch you tried to apply was
5.10.49-scroll.20210715.diff. If so, please leave it applied (with the
one failed hunk), and additionally apply this:
--- ./drivers/tty/vt/vt.c.orig 2020-12-13 22:41:30.0 +
+++ ./drivers/tty/vt/vt.c 2021-04-05 16:20:32.624563241 +
@@ -3208,6 +3208,12 @@
param.vc = vc;
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+ /* Undo any soft scrolling - and do
+ not pass through this function. */
+ concon_set_origin (vc);
+#endif
+
while (!tty->flow.stopped && count) {
int orig = *buf;
buf++;
As always, there are no guarantees. Please let me know whether or not
the above hunk applies, and if so, whether or not the scrolling still
works. (Also, feel free to send me private email if there're any
problems with the mechanics of applying the patch.)
Thanks!
> Jorge Almeida
> Just in case it is useful:
It was, thanks!
[ ]
> param.vc = vc;
> + /* NEW STOUGH, 2021-04-03 */
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
> + /* Undo any soft scrolling - and do
> + not pass through this function. */
> + concon_set_origin (vc);
> +#endif
> + /* END OF NEW STOUGH */
> +
> while (!tty->stopped && count) { <==
> int orig = *buf;
> buf++;
--
Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] pm-suspend replacement?
Hello, tastytea. On Sun, Sep 19, 2021 at 22:50:30 +0200, tastytea wrote: > On 2021-09-19 20:24+0000 Alan Mackenzie wrote: > > […] > > > Or maybe I'll try and find pm-suspend again on the web. Maybe it > > > had some feature (or bug workaround) which the more modern packages > > > are lacking. > > That's just what I did. A web search for pm-utils found it easily > > enough. pm-suspend works again, and I'm a happy chappy - almost. Why > > was pm-utils taken off of portage in the first place? Was there some > > sort of security problem, or was it just because it hadn't been > > updated in a fair while (since 2013, I think)? > It was removed because upstream abandoned it. It was announced in > <https://www.gentoo.org/support/news-items/2020-04-14-elogind-default.html> > which references <https://bugs.gentoo.org/659616>. It was indeed. I think I missed it because "pm-utils" didn't ring any alarm bells whereas "pm-suspend" would have done. > > That's another feature missing from portage - a systematic way of > > discovering why a package has been removed. > `eselect news read all | less` is sometimes helpful. Thanks! > -- > Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at > <https://tastytea.de/tastytea.asc>. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] pm-suspend replacement?
Hello again, Gentoo. On Sun, Sep 19, 2021 at 11:03:00 +, Alan Mackenzie wrote: > On Sat, Sep 18, 2021 at 20:49:45 +0200, tastytea wrote: > > On 2021-09-18 18:39+0000 Alan Mackenzie wrote: > > > Hello, Gentoo. > > > I used to have a utility pm-suspend which would suspend the current > > > state of the machine to RAM (or, maybe to the swap partition) and shut > > > the machine down to a resting state. A keypress or mouse movement > > > would restore full functionality in a few seconds. > > > I think I lost this program in the emerge --depclean I did a couple of > > > months ago (the one that wanted to make my machine unbootable). > > > Is there anything to take its place? In particular I want actively to > > > put the machine into resting state (as opposed to it happening after a > > > period of inactivity), and I would prefer to do this without having to > > > start a GUI session. > > > I feel there must be something like this in portage, I just don't know > > > how to find it. > > > Thanks for the help! > > `loginctl suspend`[1] if you use sys-auth/elogind. `echo mem > > > /sys/power/state`[2] if not. > Thanks! > Unfortunately, neither of them works. I tried s2ram too. It also > doesn't work. > What they all do is suspend the system, then immediately restore it, > without the keyboard or mouse being touched. > I'm sure the kernel isn't the problem: I tried it with three kernels > going back to 5.4.97 and it failed on them all. pm-suspend worked on > these. Similarly, I doubt my HW is the problem. > At this stage, I think it's time to give up. I don't want to spend hours > submitting bug reports and following up, or on endless web searches for > solutions. The feature just isn't that important, convenient though it > would be. > Or maybe I'll try and find pm-suspend again on the web. Maybe it had > some feature (or bug workaround) which the more modern packages are > lacking. That's just what I did. A web search for pm-utils found it easily enough. pm-suspend works again, and I'm a happy chappy - almost. Why was pm-utils taken off of portage in the first place? Was there some sort of security problem, or was it just because it hadn't been updated in a fair while (since 2013, I think)? That's another feature missing from portage - a systematic way of discovering why a package has been removed. > > [1] <https://wiki.gentoo.org/wiki/Elogind#loginctl> > > [2] > > <https://www.kernel.org/doc/html/v5.10/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation> > > -- > > Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at > > <https://tastytea.de/tastytea.asc>. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] pm-suspend replacement?
On Sat, Sep 18, 2021 at 20:49:45 +0200, tastytea wrote: > On 2021-09-18 18:39+0000 Alan Mackenzie wrote: > > Hello, Gentoo. > > I used to have a utility pm-suspend which would suspend the current > > state of the machine to RAM (or, maybe to the swap partition) and shut > > the machine down to a resting state. A keypress or mouse movement > > would restore full functionality in a few seconds. > > I think I lost this program in the emerge --depclean I did a couple of > > months ago (the one that wanted to make my machine unbootable). > > Is there anything to take its place? In particular I want actively to > > put the machine into resting state (as opposed to it happening after a > > period of inactivity), and I would prefer to do this without having to > > start a GUI session. > > I feel there must be something like this in portage, I just don't know > > how to find it. > > Thanks for the help! > `loginctl suspend`[1] if you use sys-auth/elogind. `echo mem > > /sys/power/state`[2] if not. Thanks! Unfortunately, neither of them works. I tried s2ram too. It also doesn't work. What they all do is suspend the system, then immediately restore it, without the keyboard or mouse being touched. I'm sure the kernel isn't the problem: I tried it with three kernels going back to 5.4.97 and it failed on them all. pm-suspend worked on these. Similarly, I doubt my HW is the problem. At this stage, I think it's time to give up. I don't want to spend hours submitting bug reports and following up, or on endless web searches for solutions. The feature just isn't that important, convenient though it would be. Or maybe I'll try and find pm-suspend again on the web. Maybe it had some feature (or bug workaround) which the more modern packages are lacking. > [1] <https://wiki.gentoo.org/wiki/Elogind#loginctl> > [2] > <https://www.kernel.org/doc/html/v5.10/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation> > -- > Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at > <https://tastytea.de/tastytea.asc>. -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] pm-suspend replacement?
Hello, Gentoo. I used to have a utility pm-suspend which would suspend the current state of the machine to RAM (or, maybe to the swap partition) and shut the machine down to a resting state. A keypress or mouse movement would restore full functionality in a few seconds. I think I lost this program in the emerge --depclean I did a couple of months ago (the one that wanted to make my machine unbootable). Is there anything to take its place? In particular I want actively to put the machine into resting state (as opposed to it happening after a period of inactivity), and I would prefer to do this without having to start a GUI session. I feel there must be something like this in portage, I just don't know how to find it. Thanks for the help! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
Hello, Rainer. On Tue, Jul 27, 2021 at 11:28:05 +0200, Dr Rainer Woitok wrote: > Alan, > On Monday, 2021-07-26 19:01:21 +, you wrote: > > ... > > The warning was not very explicit. An explicit warning would have said > > "--depclean is capable of removing critical system packages". As it > > happened I didn't ignore the warning. But some people might. > > You seem to see nothing wrong with an OS being one keypress away from > > destroying itself. I do. > You mentioned in an earlier post that you not only got this warning for > "openrc" but also for "nano". I remember that after my first Gentoo in- > stall ever, I explicitly emerged the packages "vim" (as an emergency > fallback) and -- more importantly -- "XEmacs" which were thus added to > "@world". Just as a matter of interest (I am an Emacs maintainer), are you still using XEmacs? > I then ran my very first "emerge --ask --depclean" and got that > warning about "nano". I do not remember the exact wording, but -- > honestly -- I was startled. Not very explicit? When "emerge" is > tell- ing me that removing "nano" might result in my system becoming > unusable? Or something to that effect? Being a Gentoo novice then, > I immediately replied "n", researched the webs, and then with a bit > more knowledge and conscience I rerun "emerge --ask --depclean" and > bravely typed "y". > You were startled, too, when reading that warning, so where exactly is > the problem? Had I wanted a third editor I'd have stuffed "nano" into > "@world", but I didn't. Since you want "openrc", you should. The problem is that the documentation doesn't warn about the potential loss of critical packages. Only runtime messages which could easily have scrolled off the screen. Heck, when I first ran --depclean, there were something like 220 packages to be removed. It would be very easy to have missed openrc. (Shameless plug) only my kernel patch which restores soft scroll enabled me to scroll back and see the warning. The other problem is that, as (I think) Scott Adams, the creator of Dilbert, has said, everybody is an idiot. Just not 24 hours a day. The very fact that --depclean can remove the active init system means it will catch somebody at a time when he is being an idiot. I know I'm repeating myself, but I don't think an OS should ever delete critical parts of itself unless explicitly requested by the user. Perhaps not even then, but I wouldn't go that far. The fact that portage does this means IMHO that something has gone wrong. Maybe portage is too complicated, and people aren't aware of the lack of safety catches. > And yes, some people tend to ignore warnings. In particular, if there > are just too many of them. Yes. I wonder just how many people really do read the "Waschzettel" which accompanies all pharmaceuticals in Germany? It takes some commitment and patience to do so, but might be very important. > I remember when back in the old days plenty of sources suggested to > put "alias rm='rm -i'" into one's profile. I always objected to > this, because you'd get so used to typing "y" to the plethora of > questions that you'd have an excellent chance to miss the one file > which would have been worth retaining. > So the most important rule when working with computers still is "Read > carefully, think carefully, then type carefully". More warnings, bigger > fonts or red colour simply don't cut it. Or are you skimming your "gcc" > compilation logs after doing your weekly Gentoo upgrade for every warn- > ing in order to then check the source code to see whether or not you > should do anything about it? I don't. OK. Respectfully, I think I disagree with you here. Who'd have thought it? Two Gentoo users disagreeing about something. ;-) > My two cents ... Much appreciated, thanks. > Sincerely, > Rainer -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
Hello, Rich. On Sun, Jul 25, 2021 at 15:54:25 -0400, Rich Freeman wrote: > On Sun, Jul 25, 2021 at 2:05 PM Alan Mackenzie wrote: > > OK, so you're clever and you know this. You know to do the > > couter-intuitive thing of putting @system packages into @world. Less > > clever people like me follow the handbook, and assume that packages in > > @system are protected. Putting init-systems into @world is an unnatural > > thing to do, and must be construed as a workaround for deficiencies in > > portage. > I think you're really conflating the package manager with how some > virtuals/ebuilds are configured. Portage shouldn't have > service-manager-specific functionality. Nor should it do things like > never uninstall things that packages say aren't needed just in case > you might still be using them, when you run it with --depclean which > basically is supposed to have it remove the stuff that isn't needed. I don't think portage should ever uninstall the active init system, or other crucial parts of the system, unless explicitly requested by the user. I think that would be poor design if it were deliberate. People make mistakes, and systems should take that into account. > All protage does is follow the dependencies. > I think there is room for discussing whether daemontools should be > treated as a service manager by default. I've never used it and can't > speak to how it is typically used. You might want to talk to the > maintainers of it to get their thoughts. How would I track down the Gentoo maintainer? > > No, I did not make that mistake. I simply assumed, not entirely > > consciously, that Gentoo would not destroy my system without me > > specifically asking it to. > It isn't like uninstalling openrc is going to "destroy your system". > Worst case you could always just pass init=/bin/bash or whatever to > the kernel and just reinstall it. Granted, it wouldn't really be > welcome behavior. > > It would be saner still to be kept in the system file (whatever that > > might be). > I suppose you might not care to hear that I've advocated a few times > that the "system file" should disappear entirely and no packages > should get special treatment. :) Granted, that has more to do with > how assumed dependencies work in the repository. I don't really have > a problem with confirmation before removing certain packages because > reinstalling them can be quite painful. The service manager actually > is one of the easier ones to fix. If you break the ability to > bootstrap gcc/etc that can be a real bugger to fix. :-) I suppose I'd be in favour of some sort of "are you really sure?" protections for things like gcc and python, too. > Really though posting on this list and successfully winning every > argument with everybody who replies It's clear that that's not going to happen. ;-) > is going to do zero to change this behavior, because it is > unlikely that anybody involved in this particular issue reads this > list. It would make more sense to chat with the daemontools > maintainer and get their thoughts on how the virtual ought to be > configured as a starting point. You could always try for a second > opinion/etc if that doesn't work. Plus the conversation would > probably help you understand what their thinking was. That's an excellent idea. This feature is not going to hurt me any more, because I know about it now. I'm concerned it could hurt other people in the future. > -- > Rich -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
Hello, Martin. On Sun, Jul 25, 2021 at 22:32:10 -, Martin Vaeth wrote: > Alan Mackenzie wrote: > > On Sun, Jul 25, 2021 at 16:18:25 -, Martin Vaeth wrote: > >> Portage *cannot* know unless you tell it. The way to tell portage that > >> a package is crucial for *you* is to put it into the world file (or > >> into some set which is in your world file). > > OK, so you're clever and you know this. You know to do the > > couter-intuitive thing of putting @system packages into @world. > No, I am doing the intuitive thing, and put *that particular* > service-manager(s) which is crucial for my system in world. You're being clever again and, perhaps unconsciously, being disdainful of the less clever or experienced. It's a reasonable expectation that an operating system won't delete itself. Gentoo doesn't always meet that expectation. You don't seem to see anything wrong with that. > > Less clever people like me follow the handbook, and assume that > > packages in @system are protected. > And they are right to do so. And openrc is not in @system (at least not > in the profile which you have chosen), and certainly the handbook does > not claim the contrary. Now you're getting legalistic. By @system I meant "the operating system", not what some legal text defines it to be. That "the handbook does not claim the contrary" is poor reasoning. If anything surprising and painful is liable to happen, the handbook should explicitly point it out. > Your assumption that all packages which are in stage3 are also in > @system is just plain wrong. It would actually be horrible if that > would be the case. > > Putting init-systems into @world is an unnatural thing to do > No. Putting the packages which *you* want to use into world is > the most natural thing to do. It is unnatural to regard the operating system as a package. It is natural to assume the OS won't delete itself. I'm unaware of any other non-joke OS's which delete themselves without being asked. [ ] > > No, I did not make that mistake. > You did. You would have done the same mistake if you would have > emerged systemd with the same profile without putting it into world, > and have configured your boot-loader to always load systemd: > In that case, systemd would be critical to your system and openrc is > completely superfluous. > Why should you expect that systemd will not get removed in the above > situation if you have not put it into world? > And if you do not expect that: Why should you expect that this is > different for openrc? > Well, you do, because you obviously falsely assumed that you are > using an openrc profile or something similar which let openrc > magically make a "special" package for you in contrast to systemd. Now you're trying to win an argument because you know portage etc., better than me. And you're being pedantic and legalistic. Quite simply I expect that an OS, including Gentoo, will not delete itself unless specifically asked by the user. I'm not getting involved in arguments about details. Gentoo is not perfect. [ ] > > Fine for a very clever person, not so much for the rest of us. I > > installed my Gentoo in accordance with the handbook (as of 2017), and > > I don't recall any suggestion of putting critical system packages > > into the world file. > I am sure that there is written something that you should put all > packages which you want to use into the world file. And BTW, I am also > sure that there is nothing written like "do not do this for @system > packges". No reasonable user is going to assume the OS will delete itself. Very many will regard the OS as something into which one installs packages, not as a package itself. There was nothing in the handbook to contradict this natural view. [ ] > >> Except for the warning that you should read *very carefully* through > >> the list of packages which are going to be removed. > > That looks more like a "cover your backside" warning than a real > > warning > This is gentoo - a distribution which explicitly never hinders you to > shoot yourself in the foot. And you really think that if there is even > an explicit warning you should ignore it? The warning was not very explicit. An explicit warning would have said "--depclean is capable of removing critical system packages". As it happened I didn't ignore the warning. But some people might. You seem to see nothing wrong with an OS being one keypress away from destroying itself. I do. So our discussion is bound to be somewhat at cross purposes. > > - one that transfers the responsibility from the perpetrators of an > > unsafe system to the victims. > Oh, come on: You have misconfigur
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
Hello, Martin. On Sun, Jul 25, 2021 at 16:18:25 -, Martin Vaeth wrote: > Alan Mackenzie wrote: > > On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote: > >> Well, it's not installed on my new system. I doubt it's installed on any > >> new-ish gentoo-gnome systems. So openrc itself can't be critical. > > Must you be so objectionably pedantic? It is surely clear that I was > > using "openrc" as a metasyntactic variable for "the current init > > system". If it wasn't, apologies. [ ] > Portage *cannot* know unless you tell it. The way to tell portage that > a package is crucial for *you* is to put it into the world file (or > into some set which is in your world file). OK, so you're clever and you know this. You know to do the couter-intuitive thing of putting @system packages into @world. Less clever people like me follow the handbook, and assume that packages in @system are protected. Putting init-systems into @world is an unnatural thing to do, and must be construed as a workaround for deficiencies in portage. > The mistake you made is to assume that the profile > profiles/default/linux/amd64/17.1/desktop (or whichever profile you > use) is an openrc-specific profile. It is not: It is the generic > profile for any init system. And it is a *good* thing that the basic > profiles do not force an init-system upon you which you do not want to > use. No, I did not make that mistake. I simply assumed, not entirely consciously, that Gentoo would not destroy my system without me specifically asking it to. > The systemd init system has its own profile, but only because systemd > is not only an init system, and it is therefore natural to have more > things in that profile than just the init system itself. > One could make also openrc, runit, daemontool profiles, but this > would lead to an explosion of the number of profiles (for various > architectures and other variants like desktop, hardened, ...), > and probably the only thing these profiles would do would be to > pull in the init system itself. It is much saner to keep this in > the world file. It would be saner still to be kept in the system file (whatever that might be). > (Once it has become standard to "combine" profiles from several > smaller profiles, I would suggest to have such openrc, ... profiles > as well, but although this is technically possible, already, it is > hardly documented and certainly cannot be considered at standard.) > >> It may be critical for *your* system ... :-) > > Just as systemd is for your system. > And for that reason, I have systemd in my world file. (Together with > openrc, BTW, because I want to be able to toggle between init systems > for the case that one is not running for whatever reason.) Fine for a very clever person, not so much for the rest of us. I installed my Gentoo in accordance with the handbook (as of 2017), and I don't recall any suggestion of putting critical system packages into the world file. Why not just put ALL system packages into the world file? > > If you'd installed daemontools you would also have come within > > a keystroke of destroying your system > Nope. > > as I did, on attempting emerge --depclean. You would have received no > > warning of any kind on installing the package, and there would be no > > documentation brought to your attention about the potential catastrophe. > Except for the warning that you should read *very carefully* through > the list of packages which are going to be removed. That looks more like a "cover your backside" warning than a real warning - one that transfers the responsibility from the perpetrators of an unsafe system to the victims. There is no specific warning that --depclean can remove critical system files. Probably there should be. > Surprises in misconfigured systems can occur. But the problem is > not the system but the misconfiguration - in your case the missing > world entry. Not a bit of it. The problem is the lack of documentation in the handbook to perform this counter-intuitive step. > > No, my problem is caused by Gentoo allowing its package system, without > > me doing anything strange > Relying on openrc as a critical part of the system and not telling > portage about it *is* something strange. Oh, come on! Relying on Gentoo not to commit suicide by deleting critical system packages is strange? Even you probably started out doing this when you first installed Gentoo. There is nothing in the handbook to say to do this. > > Nobody here has made any suggestions as to how this situation might be > > prevented in the future > The correct suggestion is to inform portage about your intention. > Maybe add a paragraph to the handbook about doin
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Neil. On Sun, Jul 25, 2021 at 16:40:23 +0100, Neil Bothwick wrote: > On Sun, 25 Jul 2021 13:43:46 +0000, Alan Mackenzie wrote: > > > It may be critical for *your* system ... :-) > > Just as systemd is for your system. If you'd installed daemontools you > > would also have come within a keystroke of destroying your system, just > > as I did, on attempting emerge --depclean. You would have received no > > warning of any kind on installing the package, and there would be no > > documentation brought to your attention about the potential catastrophe. > This is a valid point, that appears to have been obscured by some of the > discussions about the cause. As to whether it would render the system > unbootable, I have no idea, would daemontools have taken care of that. And this is the main point of my complaint - the surprise, the shock, and the innocence (as in opposite of guilty, not of wordly-wise) of the victims. They have done nothing but installing a package in the normal way. daemontools can only boot a system if it's been configured to do so. That involves writing entries into /etc/inittab. The number of people who would lose their systems by this mechanism is likely very small, but that loss would probably involve a re-installation. I mean all a victim has to go on is the fact that his machine won't boot, combined with a memory of having run emerge --depclean the night before. My guess (for which I have little basis) would be that daemontools is used more as part of the various qmail variants rather than as the prime init system. I don't recall anybody on this list using d. rather than o. or s. as their main init system. In fact, I wasn't even aware it was possible, before looking it up on Wikipedia this afternoon. > It seems that Rich's suggestion has the most merit, add a USE flag to > daemontools to indicate that it is intended to be your service manager, > and have the virtual require that flag. Yes, it would require a > one-off rebuild of daemontools for everyone with it installed, but the > potential for breakage would be removed. Another idea I had today is to have two packages, daemontools and daemontools-init, which would be identical, apart from the fact that only the second of these would satisfy virtual/service-manager. > If I had to allocate blame for this, I would say it is the virtual that > is the cause of the problem. With the current setup, unmerging openrc is > the only way for depclean to deal with it when you have daemontools in > @world. I can't help feeling that maybe portage has become too complicated. > -- > Neil Bothwick > Top Oxymorons Number 41: Good grief -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Wol. On Sun, Jul 25, 2021 at 13:26:17 +0100, Wols Lists wrote: > On 25/07/21 12:47, Alan Mackenzie wrote: > >> They are, @system is a set of packages and nothing it it will be > >> > depcleaned. However, openrc is not part of @system, the virtual is. > > Ah, that's it. So we have critical system packages which aren't part of > > @system. I think openrc is a critical system package. > Well, it's not installed on my new system. I doubt it's installed on any > new-ish gentoo-gnome systems. So openrc itself can't be critical. Must you be so objectionably pedantic? It is surely clear that I was using "openrc" as a metasyntactic variable for "the current init system". If it wasn't, apologies. > It may be critical for *your* system ... :-) Just as systemd is for your system. If you'd installed daemontools you would also have come within a keystroke of destroying your system, just as I did, on attempting emerge --depclean. You would have received no warning of any kind on installing the package, and there would be no documentation brought to your attention about the potential catastrophe. > Let's rephrase it - "openrc is one of the (optional) packages that > satisfied a critical dependency". If you must. > Your problem is caused because you have explicitly installed an > alternate package that satisfies the same critical dependency. No, my problem is caused by Gentoo allowing its package system, without me doing anything strange, to bring my system to within a single keystroke of destruction. That is a bug in any circumstance. All you and most of the others have done is pointed out the mechanisms by which this happened, with the implicit assumption that because that's what they do, they must be right. They're not at all right. Nobody here has made any suggestions as to how this situation might be prevented in the future, not just for me, but for the next user who needs daemontools. > Cheers, > Wol -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Neil. On Sun, Jul 25, 2021 at 10:03:44 +0100, Neil Bothwick wrote: > On Sat, 24 Jul 2021 21:01:34 +0000, Alan Mackenzie wrote: > > > > It seems it's insisting on removing all packages but one which > > > > satisfy a virtual. Maybe that is unwise, and it should keep _all_ > > > > such packages which are currently installed. > > > Well, the whole point of an any-of dependency is to only require one > > > of them. Why force packages to stick around if they aren't needed? > > I would say all packages in @system _are_ needed, unless the user > > explicitly says otherwise. > They are, @system is a set of packages and nothing it it will be > depcleaned. However, openrc is not part of @system, the virtual is. Ah, that's it. So we have critical system packages which aren't part of @system. I think openrc is a critical system package. > > > Now, whether daemontools actually should satisfy the dependency I > > > don't want to comment on without doing more research. Surely though > > > there is little point in having openrc and systemd and runit on the > > > same system unless the user explicitly wants this (and if they do they > > > can just stick them in @world). > > The user might be switching between them, doing comparisons. (No, I > > don't know if this is practical.) I don't know either whether it's > > practical to boot Gentoo with just daemontools. But there are use cases > > which require both openrc and daemontools on the same system, so there's > > something not quite right about the service-manager ebuild, or emerge. > That is possible, but it is also possible that this is entirely down to > you installing things outside of portage and handling their dependencies > manually, creating unwanted side-effects like this. Quite the contrary. If I'd've stuck to the daemontools I installed from a tarball, this whole thing wouldn't have happened. It's BECAUSE I switched to using the portage version that this danger reared its ugly head. > > I think that would be solving the wrong problem. The fact is, it is > > easy, far too easy, to shoot yourself in the foot here. As well as > > openrc, --depclean also wanted to remove nano (the editor) for the same > > reason. That might be serious for some people. > It did that because you have another suitable editor installed. I don't > like nano so I'm happy to install something else that satisfies > virtual/editor and let depclean get rid of nano, knowing that it won't do > it unless I already have a suitable alternative installed. > > Maybe the answer is to regard --depclean as a tool for experts only, > > since it is capable in ordinary innocent use of rendering a system > > unusable. > I feel it's more a case of Gentoo being a system for those that > understand what they are doing with the system - with great power comes > great responsibility and all that. That feels needlessly patronising, Neil. I fear the Gentoo maintainers will take the same attitude. Not only can the user shoot himself in the foot, but it's Gentoo that provides the gun, innocently wrapped, with a "press here" direction on the packaging above a hidden trigger. Nobody accepts any responsibility for preventing accidents. The implication of what you say is that nobody should use portage without understanding every last intricate detail of it. This doesn't feel reasonable. Nobody but me seems to see anything wrong with all this. It's one thing saying users should look after themselves, but surely it's quite another thing to provide an obsure mechanism where one's one keypress away from destroying ones system. I'm quite a bit less enthusiastic about Gentoo than I was a few days ago. > -- > Neil Bothwick > Caution, an incorrigible punster - don't incorrige. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Dale. On Sat, Jul 24, 2021 at 10:03:52 -0500, Dale wrote: > Alan Mackenzie wrote: > > I'm considering submitting a bug to bugs.gentoo.org, requesting that > > _all_ installed packages satisfying a virtual get kept. There is surely > > something wrong when somebody who just wants to be a user (me) has to > > read .ebuild files to get normal things done. > If you can, I'd recommend trying to reach out to the maintainer to see > if that is expected behavior. It could be that that is the way it is > supposed to work. If that is so tho, I find it odd. I find it infuriating when ordinary innocent use of something like emerge can totally break a system. > Maybe qmail needs a USE flag to pull in daemontools? I'm actually using s/qmail, tarball direct from its maintainer, since there's no ebuild for it. Originally, I had daemontools from the same place, until I discovered there was an ebuild for it. > Maybe something else needs changing. I'd start by reaching out to the > maintainer. I guess a bug report would be considered reaching out but > a email may also work as well. Thanks, I submitted a bug report. I think it's a bug in emerge. I've got a nasty feeling there isn't enough sympathy for non-experts for that bug to go anywhere, but we'll see. > Just my thoughts. May not be worth much. ;-) > Dale > :-) :-) -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello again, Rich. On Sat, Jul 24, 2021 at 10:58:55 -0400, Rich Freeman wrote: > On Sat, Jul 24, 2021 at 10:46 AM Alan Mackenzie wrote: > > On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote: > > > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie wrote: > > > > So in these virtual packages, it seems by default the _last_ mentioned > > > > package in a || ( ... ) construct is the one --depclean keeps. It all > > > > has the feeling of things not having been properly thought through. > > > I'm not sure what the default is - most likely PMS just requires that > > > one of them be kept. > > PMS? Part of emerge? > Package Manager Specification. Specifically: > https://projects.gentoo.org/pms/8/pms.html#x1-760008.2.3 Ah, thanks! > All it requires is that one be present. Portage can use whatever > behavior it wishes to decide which to keep (assuming all installed > packages have their deps). > > It seems it's insisting on removing all packages but one which satisfy a > > virtual. Maybe that is unwise, and it should keep _all_ such packages > > which are currently installed. > Well, the whole point of an any-of dependency is to only require one > of them. Why force packages to stick around if they aren't needed? I would say all packages in @system _are_ needed, unless the user explicitly says otherwise. > Now, whether daemontools actually should satisfy the dependency I > don't want to comment on without doing more research. Surely though > there is little point in having openrc and systemd and runit on the > same system unless the user explicitly wants this (and if they do they > can just stick them in @world). The user might be switching between them, doing comparisons. (No, I don't know if this is practical.) I don't know either whether it's practical to boot Gentoo with just daemontools. But there are use cases which require both openrc and daemontools on the same system, so there's something not quite right about the service-manager ebuild, or emerge. > > I'm considering submitting a bug to bugs.gentoo.org, requesting that > > _all_ installed packages satisfying a virtual get kept. There is surely > > something wrong when somebody who just wants to be a user (me) has to > > read .ebuild files to get normal things done. > I'd be shocked if that went anywhere. I'd think the better solution > would be to have some kind of USE flag that tells daemontools whether > it is used as an actual service manager or not, though that has its > own issues (changing that state shouldn't require rebuilds/etc, but it > would). I think that would be solving the wrong problem. The fact is, it is easy, far too easy, to shoot yourself in the foot here. As well as openrc, --depclean also wanted to remove nano (the editor) for the same reason. That might be serious for some people. I have, in fact, submitted a bug on the "shoot yourself in the foot" problem. So far it's got one reply which (possibly wilfully) misunderstood the intent of the report, and said, much like you did "add daemontools to @world and the problem's solved". Maybe the answer is to regard --depclean as a tool for experts only, since it is capable in ordinary innocent use of rendering a system unusable. > In any case, you probably should have a chat with the daemontools > maintainer. I doubt the portage team would consider doing something > like this as some kind of universal policy. It would impact hundreds > of things that have any-of dependencies. OK. The suggestion I made in my bug report was that @system packages should be protected, much like @world packages are already. I don't see the rationale in protecting @world, but not the more important @system. > -- > Rich -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Rich. On Sat, Jul 24, 2021 at 10:14:20 -0400, Rich Freeman wrote: > On Sat, Jul 24, 2021 at 9:47 AM Alan Mackenzie wrote: > > So in these virtual packages, it seems by default the _last_ mentioned > > package in a || ( ... ) construct is the one --depclean keeps. It all > > has the feeling of things not having been properly thought through. > I'm not sure what the default is - most likely PMS just requires that > one of them be kept. PMS? Part of emerge? It seems it's insisting on removing all packages but one which satisfy a virtual. Maybe that is unwise, and it should keep _all_ such packages which are currently installed. > If daemontools (or something that depends on it) is in your @world > that would explain why openrc was selected for removal. OK, that solves the mystery, thanks. > I don't know enough to comment on whether daemontools is a substitute > for openrc. My first complete guess would be that it could either be > used in addition to openrc or on its own. I've only ever used it as part of qmail (the mail transport program), never on its own. I'm loathe to mess around with it, since my email depends on it. But from what I remember about daemontools, it probably could be used as an alternative to openrc, I just don't envisage anybody wanting to do it, though. > Busybox can be a substitute for sysvinit or udev though most people > who have it installed probably don't intend for it to be used that > way. You could have that conversation with the maintainer. I'm considering submitting a bug to bugs.gentoo.org, requesting that _all_ installed packages satisfying a virtual get kept. There is surely something wrong when somebody who just wants to be a user (me) has to read .ebuild files to get normal things done. > -- > Rich -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Neil. On Wed, Jul 21, 2021 at 21:27:05 +0100, Neil Bothwick wrote: > On Wed, 21 Jul 2021 22:13:50 +0200, tastytea wrote: > > > emerge included openrc (the only version of it on my system) in the > > > packages it planned to remove. It was kind enough to give me a > > > warning that this "might" do bad things, but I was somewhat shocked > > > to see it there at all. I might have accidentally typed 'y' instead > > > of 'n'. > > > Maybe the program wants revenge at me executing so seldomly. Or > > > something like that. > Well, it would help if you ran it more often. > > > But now, my question is how can I trust --depclean even a little bit > > > after that? Do I have to go through all the package versions, > > > manually removing the obsolete ones? There are several hundred. :-( > > I'm not sure why it would want to remove openrc, as far as I know it > > should be part of the @system set unless you're on a systemd profile. > It's the first dependency of virtual/system-manager, which in turn is > part of @system. I don't see why it would be removed unless you have > something else installed that satisfies the virtual , such as systemd or > runit. The virtual/service-manager ebuild looks like: ; # Copyright 1999-2021 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 DESCRIPTION="Virtual for various service managers" SLOT="0" KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86 ~x64-cygwin ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt" IUSE="kernel_linux" RDEPEND=" prefix-guest? ( >=sys-apps/baselayout-prefix-2.2 ) !prefix-guest? ( || ( sys-apps/openrc kernel_linux? ( || ( sys-apps/systemd sys-process/runit virtual/daemontools < ) ) ) )" ; Maybe virtual/daemontools is what's doing it. I have sys-process/daemontools-0.76-r8 installed, and this ebuild satisfies virtual/daemontools. However daemontools is NOT (necessarily) an alternative to openrc, but a supplementary utility. (I need it for running a qmail variant.) So, maybe having daemontools in virtual/service-manager is a bug. Also, why is --depclean keeping the _last_ installed package which satisfies a virtual rather than the _first_ package which does? I thought only a single package satisfying a virtual was allowed. Maybe I used some sort of forcing flag to get daemontools installed, I can't remember, and there's nothing about this in my notes. I've got a similar situation with virtual/editor, where I've got vim installed, and --depclean wants to remove nano, but is warning me against it. So in these virtual packages, it seems by default the _last_ mentioned package in a || ( ... ) construct is the one --depclean keeps. It all has the feeling of things not having been properly thought through. > > You can record it in your @world set with `emerge --select --noreplace > > sys-apps/openrc`. That should prevent accidental removals. > It would, but it doesn't address the issue of why portage wants to remove > it. > -- > Neil Bothwick > mandelbug /man'del-buhg/ n. > [from the Mandelbrot set] A >bug whose underlying causes are so complex and obscure as to make >its behavior appear chaotic or even non-deterministic. This term >implies that the speaker thinks it is a Bohr bug, rather than >a heisenbug. See also schroedinbug. -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] --depclean wants to remove openrc. Yikes!
Hello, Gentoo. As prompted after the recent perl update, I did # emerge --depclean -va. emerge included openrc (the only version of it on my system) in the packages it planned to remove. It was kind enough to give me a warning that this "might" do bad things, but I was somewhat shocked to see it there at all. I might have accidentally typed 'y' instead of 'n'. Maybe the program wants revenge at me executing so seldomly. Or something like that. But now, my question is how can I trust --depclean even a little bit after that? Do I have to go through all the package versions, manually removing the obsolete ones? There are several hundred. :-( What do I do? Help! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback is back again!
Hello, Gentoo. A new kernel, gentoo-sources-5.10.49-r1 has become current. For those who wish to have console soft scrolling, the patch which worked with 5.10.27 actually still works in 5.10.49-r1. But I've tidied that patch up somewhat for 5.10.49-r1 and have attached the patch file to this post. The instructions for using it are basically unchanged, apart from file names, etc. Updating those instructions gives us: (i) Extract the attached patch file to your /usr/src/linux-5.10.49-gentoo-r1 directory (or probably any 5.10 kernel's). (ii) From that directory run $ patch -p0 < 5.10.49-scroll.20210715.diff. (iii)(a) If you've already got a working 5.10.49-r1, do a $ make oldconfig. That should bring up the new configuration items, for which you can accept the defaults. These two items are a flag to enable the scrollback, and a buffer size defaulting to 128kB. (iii)(b) If you haven't yet got a 5.10.49-r1, just configure your kernel in the usual way. The two new items are under Device Drivers/Graphics support/Console display driver support. (iv) Build the kernel. (v) Put the new kernel into your usual boot manager. (vi) Reboot and enjoy! As before, it works for me, and there's nothing malicious in it, but if it breaks for you, I'm sorry but I won't be responsible. -- Alan Mackenzie (Nuremberg, Germany). On Mon, Apr 05, 2021 at 17:12:07 +0000, Alan Mackenzie wrote: > Hello, Gentoo. > Yes, console soft scrolling is back! That essential feature that was > stripped out of the kernel at around 5.4.x has returned! > Only this time, it's even better! Instead of one scrollback buffer > shared between all tty's, there's now a buffer for each tty. > How to get it working: > (i) Extract the enclosed patch file to your /usr/src/linux-5.10.27-gentoo > directory (or probably any 5.10 kernel's). > (ii) From that directory run $ patch -p0 < diff.20210405.diff. > (iii)(a) If you've already got a working 5.10.27, do a $ make oldconfig. > That should bring up the new configuration items, for which you can > accept the defaults. These two items are a flag to enable the > scrollback, and a buffer size defaulting to 128kB. > (iii)(b) If you haven't yet got a 5.10.27, just configure your kernel in > the usual way. The two new items are under Device Drivers/Graphics > support/Console display driver support. > (iv) Build the kernel. > (v) Put the new kernel into your usual boot manager. > (vi) Reboot and enjoy! > Admittedly, the exercise isn't quite finished - the patched source files > still have my personal change markings in them, to make debugging easier. > But the problems I reported here a few days ago are now solved. One or > two features haven't (yet) been implemented - having a single scroll > buffer shared amongst all tty's isn't there, and there're no kernel > command line parameters to control the feature. > Also, you may wonder about how safe the patch is. All I can say is that > there is nothing malicious in it, and I am known on this list, but of > course if it breaks I won't be to blame. > Bug reports and other comments are welcome, of course. > If anybody would like the corresponding patch which works on 5.4.n, for n > >= 80, that is available, too. > -- > Alan Mackenzie (Nuremberg, Germany). --- ./include/linux/vt_kern.h.orig 2020-12-13 22:41:30.0 + +++ ./include/linux/vt_kern.h 2021-04-05 15:22:28.445755234 + @@ -127,6 +127,9 @@ /* vt.c */ void vt_event_post(unsigned int event, unsigned int old, unsigned int new); int vt_waitactive(int n); +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK +void concon_scrolldelta(struct vc_data *vc, int lines); +#endif void change_console(struct vc_data *new_vc); void reset_vc(struct vc_data *vc); int do_unbind_con_driver(const struct consw *csw, int first, int last, --- ./include/linux/console_struct.h.orig 2020-12-13 22:41:30.0 + +++ ./include/linux/console_struct.h2021-04-05 15:22:28.432755234 + @@ -109,6 +109,17 @@ unsigned short *vc_screenbuf; /* In-memory character/attribute buffer */ unsigned intvc_screenbuf_size; unsigned char vc_mode;/* KD_TEXT, ... */ +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK + unsigned intvc_softback_size; /* Size in bytes of scrollback buffer. */ + unsigned long vc_softback_buf;/* Address of scrollback buffer. */ + unsigned long vc_softback_end;/* (Just past) end of buffer. */ + unsigned long vc_softback_in; /* Head pointer into circular buffer. */ + unsigned long vc_softback_top;/* Tail pointer into circular buffer. */ + unsigned long vc_softback_curr; /* Pos in vc_screenbuf or vc_softback_buf + corresponding t
Re: [gentoo-user] glibc-2.33-r1 crashes out at the start before building.
Hello, Sergei and Gentoo.
On Thu, Jul 08, 2021 at 09:00:59 +0100, Sergei Trofimovich wrote:
> On Wed, 7 Jul 2021 18:16:44 +
> Alan Mackenzie wrote:
> > Hello, Gentoo.
> > Would somebody help me here, please.
> > When I try to emerge glibc-2.33-r1, the very first phase of the build
> > crashes out with:
> > x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -Wl,-O1 -Wl,--as-needed
> > glibc-test.c -o glibc-test
> > * Checking that IA32 emulation is enabled in the running kernel ...
> > /usr/portage/sys-libs/glibc/glibc-2.33-r1.ebuild: line 608: 199
> > Segmentation fault "${T}/check-ia32-emulation.elf32"
> > [ !! ]
> > * ERROR: sys-libs/glibc-2.33-r1::gentoo failed (pretend phase):
> > * CONFIG_IA32_EMULATION must be enabled in the kernel to compile a
> > multilib glibc.
> > *
> > * Call stack:
> > * ebuild.sh, line 127: Called pkg_pretend
> > * glibc-2.33-r1.ebuild, line 721: Called sanity_prechecks
> > * glibc-2.33-r1.ebuild, line 670: Called die
> > * The specific snippet of code:
> > * [[ $STAT -eq 0 ]] || die "CONFIG_IA32_EMULATION
> > must be enabled in the kernel to compile a multilib glibc."
> > *
> > * If you need support, post the output of `emerge --info
> > '=sys-libs/glibc-2.33-r1::gentoo'`,
> > * the complete build log and the output of `emerge -pqv
> > '=sys-libs/glibc-2.33-r1::gentoo'`.
> > * The complete build log is located at
> > '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/build.log'.
> > * The ebuild environment file is located at
> > '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/die.env'.
> > * Working directory: '/var/tmp/portage/sys-libs/glibc-2.33-r1/empty'
> > * S: '/var/tmp/portage/sys-libs/glibc-2.33-r1/work/glibc-2.33'
> > >>> Failed to emerge sys-libs/glibc-2.33-r1, Log file:
> > >>> '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/build.log'
> > What is clearly happening is that the C Compiler is crashing out with a
> > segfault. I actually have CONFIG_IA32_EMULATION in my kernel config.
> > I've tried this with both GCC-10.3.0 and GCC-9.3.0 with the same results
> > on both.
> > What is going wrong? (Horrible thought - maybe my RAM is failing.)
> If it happens consistently it's more likely a software problem and
> not a hardware problem.
> Try getting a backtrace and instructing dump out of SIGSEGVing glibc-test.
> The typical session would look like:
> $ gdb ./glibc-test
> (gdb) run
> (gdb) bt
> (gdb) disassemble
In the end, I submitted bug #802036 to the Gentoo bugzilla. Ben Kohler
noticed straight away I was still using a very old binutils (hence the
benefit of supplying complete documentation with a bug), and remarked
that problems had been seen with glibc and old binutils. Sergei then
helped with practical suggestions.
I didn't even know you had manually to configure binutils versions, but I
did this, and glibc continued to crash out. Then I tried editing the
ebuild file, removing the check that was causing the crash. This gave me
ebuild validation errors. So, after looking up the man page, I gave the
argument --digest to emerge, and it built. Phew!
So, after catching up on my emerging, I've just got one package which
isn't building, libdrm, but that can wait till another day.
> --
> Sergei
--
Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] glibc-2.33-r1 crashes out at the start before building.
Hello, Dan.
On Wed, Jul 07, 2021 at 12:28:35 -0700, Daniel Frey wrote:
> On 7/7/21 11:16 AM, Alan Mackenzie wrote:
> > Hello, Gentoo.
> > Would somebody help me here, please.
> > When I try to emerge glibc-2.33-r1, the very first phase of the build
> > crashes out with:
> > x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -Wl,-O1 -Wl,--as-needed
> > glibc-test.c -o glibc-test
> > * Checking that IA32 emulation is enabled in the running kernel ...
> > /usr/portage/sys-libs/glibc/glibc-2.33-r1.ebuild: line 608: 199
> > Segmentation fault "${T}/check-ia32-emulation.elf32"
> > [ !! ]
> > * ERROR: sys-libs/glibc-2.33-r1::gentoo failed (pretend phase):
> > * CONFIG_IA32_EMULATION must be enabled in the kernel to compile a
> > multilib glibc.
> > *
> > * Call stack:
> > * ebuild.sh, line 127: Called pkg_pretend
> > * glibc-2.33-r1.ebuild, line 721: Called sanity_prechecks
> > * glibc-2.33-r1.ebuild, line 670: Called die
> > * The specific snippet of code:
> > * [[ $STAT -eq 0 ]] || die "CONFIG_IA32_EMULATION
> > must be enabled in the kernel to compile a multilib glibc."
> > *
> > * If you need support, post the output of `emerge --info
> > '=sys-libs/glibc-2.33-r1::gentoo'`,
> > * the complete build log and the output of `emerge -pqv
> > '=sys-libs/glibc-2.33-r1::gentoo'`.
> > * The complete build log is located at
> > '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/build.log'.
> > * The ebuild environment file is located at
> > '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/die.env'.
> > * Working directory: '/var/tmp/portage/sys-libs/glibc-2.33-r1/empty'
> > * S: '/var/tmp/portage/sys-libs/glibc-2.33-r1/work/glibc-2.33'
> >>>> Failed to emerge sys-libs/glibc-2.33-r1, Log file:
> >>>> '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/build.log'
> > What is clearly happening is that the C Compiler is crashing out with a
> > segfault. I actually have CONFIG_IA32_EMULATION in my kernel config.
> > I've tried this with both GCC-10.3.0 and GCC-9.3.0 with the same results
> > on both.
> > What is going wrong? (Horrible thought - maybe my RAM is failing.)
> It looks to me that it ran a test to see if you have a kernel option
> enabled.
That's what the test is trying to discern, yes.
> It didn't, looks like it crashed. And then the build warns you
> that you have to enable CONFIG_IA32_EMULATION in your kernel?
I do have CONFIG_IA32_EMULATION enable in my kernel, and have had for a
long time. Something segfaulted (?the compiler), which looks like a bug
in wherever.
The emerge script doesn't return the position of the segfault (line 608
is just the beginning of the section). It hides the return code STAT
(which wouldn't have been set anyway). And it gives a wrong diagnostic
about a kernel setting. How is one supposed to debug such a scenario?
> Dan
--
Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] glibc-2.33-r1 crashes out at the start before building.
Hi, Dale.
On Wed, Jul 07, 2021 at 13:23:21 -0500, Dale wrote:
> Alan Mackenzie wrote:
> > Hello, Gentoo.
> > Would somebody help me here, please.
> > When I try to emerge glibc-2.33-r1, the very first phase of the build
> > crashes out with:
> > x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -Wl,-O1 -Wl,--as-needed
> > glibc-test.c -o glibc-test
> > * Checking that IA32 emulation is enabled in the running kernel ...
> > /usr/portage/sys-libs/glibc/glibc-2.33-r1.ebuild: line 608: 199
> > Segmentation fault "${T}/check-ia32-emulation.elf32"
> > [ !! ]
> > * ERROR: sys-libs/glibc-2.33-r1::gentoo failed (pretend phase):
> > * CONFIG_IA32_EMULATION must be enabled in the kernel to compile a
> > multilib glibc.
> > *
> > * Call stack:
> > * ebuild.sh, line 127: Called pkg_pretend
> > * glibc-2.33-r1.ebuild, line 721: Called sanity_prechecks
> > * glibc-2.33-r1.ebuild, line 670: Called die
> > * The specific snippet of code:
> > * [[ $STAT -eq 0 ]] || die "CONFIG_IA32_EMULATION
> > must be enabled in the kernel to compile a multilib glibc."
> > *
> > * If you need support, post the output of `emerge --info
> > '=sys-libs/glibc-2.33-r1::gentoo'`,
> > * the complete build log and the output of `emerge -pqv
> > '=sys-libs/glibc-2.33-r1::gentoo'`.
> > * The complete build log is located at
> > '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/build.log'.
> > * The ebuild environment file is located at
> > '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/die.env'.
> > * Working directory: '/var/tmp/portage/sys-libs/glibc-2.33-r1/empty'
> > * S: '/var/tmp/portage/sys-libs/glibc-2.33-r1/work/glibc-2.33'
> >>>> Failed to emerge sys-libs/glibc-2.33-r1, Log file:
> >>>> '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/build.log'
> > What is clearly happening is that the C Compiler is crashing out with a
> > segfault. I actually have CONFIG_IA32_EMULATION in my kernel config.
> > I've tried this with both GCC-10.3.0 and GCC-9.3.0 with the same results
> > on both.
> > What is going wrong? (Horrible thought - maybe my RAM is failing.)
Well, 20 minutes of memtest86+ doesn't show any errors, thankfully.
> Could it be that the /usr/src/linux link is pointing to the wrong kernel
> directory? It could be pointing to a old config that doesn't have that
> option enabled. I know I've done that before when rebuilding modules.
> It's amazing how it doesn't work when that link is pointing to the wrong
> kernel.
Thanks, I've just checked that. The link is indeed pointing to the
correct kernel. The only thing odd about it is the kernel has 777
permissions rather than 755, dating from April when I was messing with
the kernel's soft scrolling. But that couldn't cause gcc to segfault,
surely?
> If it isn't that, maybe someone else will have a better idea.
> Dale
> :-) :-)
--
Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] glibc-2.33-r1 crashes out at the start before building.
Hello, Gentoo.
Would somebody help me here, please.
When I try to emerge glibc-2.33-r1, the very first phase of the build
crashes out with:
x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -Wl,-O1 -Wl,--as-needed
glibc-test.c -o glibc-test
* Checking that IA32 emulation is enabled in the running kernel ...
/usr/portage/sys-libs/glibc/glibc-2.33-r1.ebuild: line 608: 199 Segmentation
fault "${T}/check-ia32-emulation.elf32"
[ !! ]
* ERROR: sys-libs/glibc-2.33-r1::gentoo failed (pretend phase):
* CONFIG_IA32_EMULATION must be enabled in the kernel to compile a multilib
glibc.
*
* Call stack:
* ebuild.sh, line 127: Called pkg_pretend
* glibc-2.33-r1.ebuild, line 721: Called sanity_prechecks
* glibc-2.33-r1.ebuild, line 670: Called die
* The specific snippet of code:
* [[ $STAT -eq 0 ]] || die "CONFIG_IA32_EMULATION must be
enabled in the kernel to compile a multilib glibc."
*
* If you need support, post the output of `emerge --info
'=sys-libs/glibc-2.33-r1::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=sys-libs/glibc-2.33-r1::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/die.env'.
* Working directory: '/var/tmp/portage/sys-libs/glibc-2.33-r1/empty'
* S: '/var/tmp/portage/sys-libs/glibc-2.33-r1/work/glibc-2.33'
>>> Failed to emerge sys-libs/glibc-2.33-r1, Log file:
>>> '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/build.log'
What is clearly happening is that the C Compiler is crashing out with a
segfault. I actually have CONFIG_IA32_EMULATION in my kernel config.
I've tried this with both GCC-10.3.0 and GCC-9.3.0 with the same results
on both.
What is going wrong? (Horrible thought - maybe my RAM is failing.)
--
Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Qustions re Dell M.2 PCIe NVMe Solid State Drives under Gentoo
Hello, Walter. On Thu, May 27, 2021 at 17:05:07 -0400, Walter Dnes wrote: > It was nice to have a newer "hot backup" (XPS8940) to switch over to > quickly when an older machine started locking up occasionally. Now I > need a "hot backup" for the newer machine that I ordered last October. > Dell Inspirons seem to top out at 12 gigs ram, so I'm looking for an XPS > model in order to get more ram as the bloating of linux continues. All > current XPS models seem to have 256G or 512G M.2 PCIe NVMe Solid State > drives in the base configuration. Questions... > * do NVMe drives function well under Gentoo (driver issues, etc)? Yes. Without reservation. You need to enable NVMe in the kernel, and there is a user-level program for doing things to them (like checking number of reads/writes). There is no great problem setting up a boot loader, any more than for any other sort of drive. > * how long do they hold up (wear and tear)? I've had a pair of Samsung 500Gb nvmes in RAID-1 in my 4 year old machine since it was new. As yet I've had no problems with them. In fact, the machine has never known spinning rust. > * can I simply disable them if I run into problems? If you've got something to fall back onto, yes. > If someone can suggest an alternate supplier to Dell, that ships to > greater Toronto, at similar prices, I'd be willing to take a look at > them. I can't comment at all on that. I built my machine from components. The only slightly tricky bit was finding a PCIe card to hold the second NVMe drive. > -- > Walter Dnes > I don't run "desktop environments"; I run useful applications -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Rusty problems
Hello, Neil.
On Wed, Apr 28, 2021 at 00:09:12 +0100, Neil Bothwick wrote:
> On Tue, 27 Apr 2021 20:53:11 +0000, Alan Mackenzie wrote:
> > Help! What am I supposed to do? I've got 16 Gb RAM (I'm _not_ going to
> > use the word "only" here), and wondering just how big a chunk a ram disk
> > can take out of that before the machine siezes up altogether. But if I
> > increase the ram disk to 15 Gb, even assuming it'd work, it's only going
> > to be a small number of releases before the clever people at rust
> > increase their bloat even more.
> Setting the RAM disk so high will mean you don't have enough memory for
> the compilation, which will start swapping and everything will grind to a
> near halt.
I think that was happening when I tried to use a 14 GB ram disk.
> > I know I could plump for the -bin package. Maybe I should. But before
> > I do that, is it possible to redirect this one ebuild away from
> > /var/tmp/portage (my ram disk) without disturbing the other builds? If
> > so, how would I do this (or where should I look for documentation)?
> Lookup package.env on the wiki.
Many thanks for the tip. I did this, and set up my PORTAGE_TMPDIR to
point into /home/portage. Not the ideal place, but the only place with
enough room, without messing around with mdadm to create more.
> I use rust-bin now, so this isn't an issue for me, but my laptop has
> only 8GB and this is how I have it set for chromium:
> % cat /etc/portage/env/disk-tmpdir.conf
> PORTAGE_TMPDIR="/mnt/scratch"
> % cat /etc/portage/package.env/chromium
> www-client/chromium disk-tmpdir.conf
> I do similar for libreoffice and a couple of other heavyweights.
With a like setup, building rust took ~45 minutes. This is about the
same as it took on the ram disk before giving up. So, I'm not losing a
lot, if anything, by using /home/portage (On mirrored nvme SSDs).
> Another option, to be used instead of or as well as this would be distcc.
> Once again, you can use package.env to apply this to selected packages:
That's for building on a different (more powerful) machine, isn't it? I
don't actually have a more powerful machine. ;-)
> % cat /etc/portage/env/distcc.conf
> FEATURES="distcc buildpkg distlocks"
> MAKEOPTS="-j36 -l4"
> CFLAGS="-march=broadwell -O2 -pipe"
> CXXFLAGS="${CFLAGS}"
> --
> Neil Bothwick
> I'm firm. You're obstinate. He's a pigheaded fool.
At times, I'm all three!
--
Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Rusty problems
Hello, Gentoo. I'm having problems building rust. I build everything in a ram disk, and last night my 13 Gb ram disk proved too small to build rust in. So I increased its size to 14 Gb, and tried again this evening. Same result. The pre-check on the disk size gave an OK both times, and both runs lasted about 45 minutes before running out of space. Help! What am I supposed to do? I've got 16 Gb RAM (I'm _not_ going to use the word "only" here), and wondering just how big a chunk a ram disk can take out of that before the machine siezes up altogether. But if I increase the ram disk to 15 Gb, even assuming it'd work, it's only going to be a small number of releases before the clever people at rust increase their bloat even more. I know I could plump for the -bin package. Maybe I should. But before I do that, is it possible to redirect this one ebuild away from /var/tmp/portage (my ram disk) without disturbing the other builds? If so, how would I do this (or where should I look for documentation)? Thanks for the help! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback is back again!
Hello, John
On Tue, Apr 06, 2021 at 10:13:39 -0400, John Covici wrote:
> On Tue, 06 Apr 2021 09:14:23 -0400,
> Peter Humphrey wrote:
> > On Monday, 5 April 2021 19:13:18 BST Alan Mackenzie wrote:
> > > We'll see how people react to it here, first.
> > You're my hero!
> Would this patch work on 5.4.96 and following?
No, there is a slight difference (two struct fields moved and renamed)
between 5.4 and 5.10.
For 5.4, please use the attached patch instead. It has been tested on
5.4.80-r1 and 5.4.97.
> --
> Your life is like a penny. You're going to lose it. The question is:
> How do
> you spend it?
> John Covici wb2una
> cov...@ccs.covici.com
--
Alan Mackenzie (Nuremberg, Germany).
--- drivers/video/console/Kconfig.orig 2021-03-31 19:14:48.186140856 +
+++ drivers/video/console/Kconfig 2021-04-05 13:41:20.967713154 +
@@ -79,6 +79,55 @@
help
Low-level framebuffer-based console driver.
+config FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+ bool "Enable Scrollback Buffer in System RAM"
+ depends on FB=y && FRAMEBUFFER_CONSOLE
+ default y
+ select FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_PERSISTENT_ENABLE_BY_DEFAULT
+ help
+ This option creates scrollback buffers for each framebuffer console,
+ or one buffer for them all. These buffers are allocated dynamically
+ during initialisation.
+
+ If you want this feature, say 'Y' here and enter the amount of
+ RAM to allocate for this buffer. If unsure, say 'N'.
+
+config FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE
+ int "Scrollback Buffer Size (in KB)"
+ depends on FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+ range 1 1024
+ default "128"
+ help
+ Enter the amount of System RAM to allocate for each scrollback
+ buffer of framebuffer consoles in kilobytes. Each character
+ position on the video takes 2 bytes of storage. 128k will give you
+ approximately 4 240x67 screenfuls of scrollback buffer.
+
+config FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_PERSISTENT_ENABLE_BY_DEFAULT
+ bool "Persistent Scrollback History for each framebuffer console by
default"
+ depends on FB=y && FRAMEBUFFER_CONSOLE &&
FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+ default y
+ help
+
+ Note: this option's value N has not (?yet) been implemented (2021-04).
+
+ Say Y here if the scrollback history should persist by default when
+ switching between consoles. Otherwise, the scrollback history will
+ be flushed the first time a scroll-up operation occurs on the new
+ console after the console is switched. STOUGH!!! FIXME!!! This
+ feature can also be enabled using the boot command line parameter
+ 'vgacon.scrollback_persistent=1'.
+
+ This feature might break your tool of choice to flush the scrollback
+ buffer, e.g. clear(1) will work fine but Debian's clear_console(1)
+ will be broken, which might cause security issues.
+ You can use the escape sequence \e[3J instead if this feature is
+ activated.
+
+ Note that a buffer of VGACON_SOFT_SCROLLBACK_SIZE is taken for each
+ created tty device.
+ So if you use a RAM-constrained system, say N here.
+
config FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
bool "Map the console to the primary display device"
depends on FRAMEBUFFER_CONSOLE
--- drivers/tty/vt/vt.orig.c2020-11-28 17:14:38.523649992 +
+++ drivers/tty/vt/vt.c 2021-04-05 14:33:47.743786578 +
@@ -142,6 +142,13 @@
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+/* NEW STOUGH, 2021-04-01 */
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+/* END OF NEW STOUGH */
+
struct vc vc_cons [MAX_NR_CONSOLES];
#ifndef VT_SINGLE_DRIVER
@@ -294,7 +301,7 @@
static inline unsigned short *screenpos(struct vc_data *vc, int offset, int
viewed)
{
unsigned short *p;
-
+
if (!viewed)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -623,6 +630,232 @@
}
}
+/* NEW STOUGH, 2021-03-31 */
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+/* NEW STOUGH, 2021-04-01 */
+static void con_update_softback(struct vc_data *vc)
+{
+ int l = vc->vc_softback_size / vc->vc_size_row;
+ if (l > 5)
+ {
+ vc->vc_softback_end = vc->vc_softback_buf + l * vc->vc_size_row;
+ vc->vc_softback_top = vc->vc_softback_buf; /* STOUGH,
2021-04-04 */
+ }
+ else
+ /* Smaller scrollback makes no sense, and 0 would screw
+
Re: [gentoo-user] Console scrollback is back again!
Hello, Karl. On Mon, Apr 05, 2021 at 21:58:37 +0200, k...@aspodata.se wrote: > Alan Mackenzie: > > Yes, console soft scrolling is back! That essential feature that was > > stripped out of the kernel at around 5.4.x has returned! > It is commit 087b6cb17df5834d395ab72da3f937380470ba15, > between v5.4.65 and 66. > Perhaps also 0d123a8c64fde433a, cf5a7ded53652c3d63d72, and possible > other stuff. I will confess that I don't actually have a git repository of Linux on my machine. I'd have to back it up, somehow. It would be a fair amount of work to write an efficient back-up procedure - the one I have at the moment for git repos backs up the entire repository, which would probably be excessive for Linux. Currently, I've changed a mere five files, for which I'm getting by with symbolic links in the kernel tree pointing into my home directory. > > Only this time, it's even better! Instead of one scrollback buffer > > shared between all tty's, there's now a buffer for each tty. > Great, no more missing data when switching vts. > Btw, wasn't that added in commit aabd31c421ddc730edf6d89c4ed3885e4fca5e30 > but turned off by default. There was no capability at all for one buffer per tty in framebuffer consoles. It was there for VGA consoles, and, I think, one or two others. The configuration page for it was confusing - the option for "persistent scrollback" was purely for VGAcon, though that wasn't obvious. I spent time in the past trying to get multiple buffers working, and was even considering reporting a bug. > ... > > One or two features haven't (yet) been implemented - having a > > single scroll buffer shared amongst all tty's isn't there, > ... > Is there any reason to share the buffer ? Not that I can think of. The only reason might be if somebody wanted a very large scrollback buffer, but didn't have a lot of RAM. But even so, the current default takes a total of less than 1 MB of RAM with the standard 7 tty's. Even increasing the buffer size to 10 MB, that would only come to 70 MB. Such a size of buffer would really need more sophisticated handling, with search facilities, some marking of positions, and so on. That would be a large project. > > Bug reports and other comments are welcome, of course. > git log drivers/video/console/vgacon.c etc. can give some ideas > what one is up against. Once I find some way to read it. ;-( Anyhow, the patch I have is working software, and is not going away any time soon. It means I can carry on using Linux. Just in case you're interested, the problem I had with no scrolling on tty1 was due to the way the console was initialised early on in the boot process. Its structures were initialised in a separate place from the normal init function, thus bypassing the scrollbuffer's init. When it came to re-initialising it for scrollbuffer, this partial initialisation acted as a flag not to carry on with the init. At least it caused me to learn about printk. ;-) > Regards, > /Karl Hammar -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback is back again!
Hello, Jorge. On Mon, Apr 05, 2021 at 19:38:57 +0100, Jorge Almeida wrote: > On Mon, Apr 5, 2021 at 6:12 PM Alan Mackenzie wrote: > > Hello, Gentoo. > > Yes, console soft scrolling is back! That essential feature that was > > stripped out of the kernel at around 5.4.x has returned! > > Only this time, it's even better! Instead of one scrollback buffer > > shared between all tty's, there's now a buffer for each tty. > I just tested it with kernel 5.11.11. Seems fine. Thanks! > Jorge Almeida -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback is back again!
Hello, Michael. On Mon, Apr 05, 2021 at 18:08:58 -0500, Michael Jones wrote: [ ] > Without looking at the patch itself: > Have you considered something like kmscon as a userland alternative? To be honest, no. I wasn't really aware of it when I starting working on the Linux console. According to Wikipedia, the last release was in 2013, and development stopped altogether in 2015. The Gentoo package for it is masked. > I installed it on my laptop, and aside from not working with gpmd or > consolation for mouse support, it's a perfectly functional local tty. I suppose it's one of these programs that once working, pretty much carries on working for ever. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback is back again!
Hello, Wol. On Mon, Apr 05, 2021 at 18:44:15 +0100, antlists wrote: > On 05/04/2021 18:12, Alan Mackenzie wrote: > > Bug reports and other comments are welcome, of course. > > > > If anybody would like the corresponding patch which works on 5.4.n, for n > >> = 80, that is available, too. > Why did it get removed from the kernel? Allegedly, there were security problems with it. I think the kernel people had a program which fired random inputs at lots of components, and noted when things went wrong; and things went wrong in the scroll back component. And they couldn't find anybody to look into these problems. That's the official position. I'm a bit more cynical about it. > If you want to get it back in, couldn't you ping Greg KH and get some > help - or even just advice - getting it accepted? I have no reason to believe all the "security problems" will have been resolved by my hacking. I took the algorithmic bits from 4.19.97 basically unchanged. Maybe there's not much enthusiasm for this feature, in which case I will keep it working for myself. Linux is basically unusable to me without it. There are probably quite a few patches to restore the scrollback floating around the web by now: the changes were not particularly difficult to anybody who knows the code, but getting to know the code was unusually difficult. We'll see how people react to it here, first. > Cheers, > Wol -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Console scrollback is back again!
Hello, Gentoo. Yes, console soft scrolling is back! That essential feature that was stripped out of the kernel at around 5.4.x has returned! Only this time, it's even better! Instead of one scrollback buffer shared between all tty's, there's now a buffer for each tty. How to get it working: (i) Extract the enclosed patch file to your /usr/src/linux-5.10.27-gentoo directory (or probably any 5.10 kernel's). (ii) From that directory run $ patch -p0 < diff.20210405.diff. (iii)(a) If you've already got a working 5.10.27, do a $ make oldconfig. That should bring up the new configuration items, for which you can accept the defaults. These two items are a flag to enable the scrollback, and a buffer size defaulting to 128kB. (iii)(b) If you haven't yet got a 5.10.27, just configure your kernel in the usual way. The two new items are under Device Drivers/Graphics support/Console display driver support. (iv) Build the kernel. (v) Put the new kernel into your usual boot manager. (vi) Reboot and enjoy! Admittedly, the exercise isn't quite finished - the patched source files still have my personal change markings in them, to make debugging easier. But the problems I reported here a few days ago are now solved. One or two features haven't (yet) been implemented - having a single scroll buffer shared amongst all tty's isn't there, and there're no kernel command line parameters to control the feature. Also, you may wonder about how safe the patch is. All I can say is that there is nothing malicious in it, and I am known on this list, but of course if it breaks I won't be to blame. Bug reports and other comments are welcome, of course. If anybody would like the corresponding patch which works on 5.4.n, for n >= 80, that is available, too. -- Alan Mackenzie (Nuremberg, Germany). --- ./include/linux/vt_kern.h.orig 2020-12-13 22:41:30.0 + +++ ./include/linux/vt_kern.h 2021-04-05 15:22:28.445755234 + @@ -127,6 +127,11 @@ /* vt.c */ void vt_event_post(unsigned int event, unsigned int old, unsigned int new); int vt_waitactive(int n); +/* NEW STOUGH, 2021-04-01 */ +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK +void concon_scrolldelta(struct vc_data *vc, int lines); +#endif +/* END OF NEW STOUGH */ void change_console(struct vc_data *new_vc); void reset_vc(struct vc_data *vc); int do_unbind_con_driver(const struct consw *csw, int first, int last, --- ./include/linux/console_struct.h.orig 2020-12-13 22:41:30.0 + +++ ./include/linux/console_struct.h2021-04-05 15:22:28.432755234 + @@ -109,6 +109,21 @@ unsigned short *vc_screenbuf; /* In-memory character/attribute buffer */ unsigned intvc_screenbuf_size; unsigned char vc_mode;/* KD_TEXT, ... */ + /* NEW STOUGH, 2021-03-31 */ +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK + unsigned intvc_softback_size; /* Size in bytes of scrollback buffer. */ + unsigned long vc_softback_buf;/* Address of scrollback buffer. */ + unsigned long vc_softback_end;/* (Just past) end of buffer. */ + unsigned long vc_softback_in; /* Head pointer into circular buffer. */ + unsigned long vc_softback_top;/* Tail pointer into circular buffer. */ + unsigned long vc_softback_curr; /* Pos in vc_screenbuf or vc_softback_buf + corresponding to visible screen. */ + int vc_softback_lines; /* Number of lines currently scrolled. */ + /* NEW STOUGH, 2021-04-04 */ + unsigned short vc_char_at_pos; /* Char at vc_pos when no soft scroll */ + /* END OF NEW STOUGH. */ +#endif + /* END OF NEW STOUGH */ /* attributes for all characters on screen */ unsigned char vc_attr;/* Current attributes */ unsigned char vc_def_color; /* Default colors */ --- ./drivers/video/fbdev/core/fbcon.c.orig 2021-04-05 15:22:28.434755234 + +++ ./drivers/video/fbdev/core/fbcon.c 2021-04-05 15:56:00.836644342 + @@ -3084,6 +3084,11 @@ .con_font_default = fbcon_set_def_font, .con_font_copy = fbcon_copy_font, .con_set_palette= fbcon_set_palette, + /* NEW STOUGH, 2021-04-01 */ +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK + .con_scrolldelta= concon_scrolldelta, +#endif + /* END OF NEW STOUGH */ .con_invert_region = fbcon_invert_region, .con_screen_pos = fbcon_screen_pos, .con_getxy = fbcon_getxy, --- ./drivers/video/console/Kconfig.orig2020-12-13 22:41:30.0 + +++ ./drivers/video/console/Kconfig 2021-04-05 15:22:28.414755235 + @@ -78,6 +78,55 @@ help Low-level framebuffer-based console driver. +config FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK + bool &
Re: [gentoo-user] Console scrollback
Hello, Karl. Thanks for the reply. On Fri, Apr 02, 2021 at 21:32:04 +0200, k...@aspodata.se wrote: > Alan Mackenzie: > ... > > I've now cobbled together a working console scroll on Linux > > 5.4.80-gentoo-r1. In the end, I reused much of the old machinery which > > was still present in 4.19.97. Once I've tidied it up, I hope that the > > resulting patch file will apply cleanly also to later versions than > > 5.4.80-r1. > ... > Nice, where is the patch so I can try ? I've attached a patch to this post. To apply it, the following seems to work from the top directory of a kernel source tree, e.g. 5.4.80-r1: $ patch -p0 < diff.20210402.diff .. Then you'll need to run make menuconfig (or whatever), going down to Device Drivers/Graphic support/Console display driver support and there accepting the defaults for the new config variables. (This is assuming you've got FRAMEBUFFER support enabled in a neighbouring page.) Then build the kernel as normal, and put the new version into whatever boot loader you use. It should (??) run, with a scrollback buffer on each virtual terminal. Just a word about the current state of the source - it is rough, with things unfinished. The "word" STOUGH (pronounced "stuff") is just a word I use which appears nowhere else and enables me to find changes quickly and unambiguously. As I said, I'm not finished with the changes, and swapping from and back to a scrolled tty isn't completely satisfactory. Nevertheless, I hope it works for you and you have fun with it. > > (i) The scrolling doesn't work on /dev/tty1 aka the console. > > (ii) When, e.g., /dev/tty6 has been scrolled upwards a bit, and then > >pressed to go to /dev/tty2, on returning to /dev/tty6, the > > scrolling has been cancelled and the cursor is no longer visible. > > However, the scrollback buffer is still present. > > > > I think I'm fairly likely to be able to solve (ii). However, (i), the > > problem with /dev/tty1, has me baffled. I don't know where to start > > looking for the problem. If anybody with some kernel knowledge could > > make any suggestions, I'd be very grateful. > What happens if you set /dev/console to be /dev/ttyS0, i.e. make sure > that tty1 is the only one using the first virtual console. I will try than. Thanks! > Regards, > /Karl Hammar -- Alan Mackenzie (Nuremberg, Germany). --- drivers/video/console/Kconfig.orig 2021-03-31 19:14:48.186140856 + +++ drivers/video/console/Kconfig 2021-03-31 12:39:08.090301096 + @@ -79,6 +79,52 @@ help Low-level framebuffer-based console driver. +config FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK + bool "Enable Scrollback Buffer in System RAM" + depends on FB=y && FRAMEBUFFER_CONSOLE + default y + help + This option creates scrollback buffers for each framebuffer console, + or one buffer for them all. These buffers are allocated dynamically + during initialisation. + +If you want this feature, say 'Y' here and enter the amount of +RAM to allocate for this buffer. If unsure, say 'N'. + +config FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE + int "Scrollback Buffer Size (in KB)" + depends on FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK + range 1 1024 + default "128" + help + Enter the amount of System RAM to allocate for scrollback buffers of + framebuffer consoles. Each character position on the video takes 2 + bytes of storage. 128k will give you approximately 4 240x67 + screenfuls of scrollback buffer. + +config FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_PERSISTENT_ENABLE_BY_DEFAULT + bool "Persistent Scrollback History for each framebuffer console by default" + depends on FB=y && FRAMEBUFFER_CONSOLE && FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK + default y + help + + Say Y here if the scrollback history should persist by default when + switching between consoles. Otherwise, the scrollback history will + be flushed the first time a scroll-up operation occurs on the new + console after the console is switched. STOUGH!!! FIXME!!! This + feature can also be enabled using the boot command line parameter + 'vgacon.scrollback_persistent=1'. + + This feature might break your tool of choice to flush the scrollback + buffer, e.g. clear(1) will work fine but Debian's clear_console(1) + will be broken, which might cause security issues. + You can use the escape sequence \e[3J instead if this feature is + activated. + + Note that a buffer of VGACON_SOFT_SCROLLBACK_SIZE is taken for each + created tty device. + So if you use a RAM-constrained system, say
Re: [gentoo-user] Console scrollback
Hello, Gentoo. On Wed, Jan 20, 2021 at 19:59:09 +, Alan Mackenzie wrote: [Context: Scrolling on the Linux text console using the keys and has been removed from the kernel. This is not a Good Thing.] > What I have in mind now is writing a Linux driver, a small piece of code > which would piggy-back on the existing virtual terminal drivers, and > simply pass everything through to and from the main driver, filtering out > things relevant to scrolling, and processing these in my new driver. > I've spent the last few evenings reading up on drivers, and reading the > relevant source code from 4.19.97. I can understand the kernel > maintainers not being enthusiastic about the existing code. But that > dates from, I believe, the 1990s, when RAM was measured in megabytes, and > processor speeds in megahertz. Optimisation for speed and store usage > just isn't important any more. I finally got around to looking into this seriously in the last couple of weeks. The above plan turned out not to be the right thing. I've now cobbled together a working console scroll on Linux 5.4.80-gentoo-r1. In the end, I reused much of the old machinery which was still present in 4.19.97. Once I've tidied it up, I hope that the resulting patch file will apply cleanly also to later versions than 5.4.80-r1. As a matter of interest, the kernel code for the console is not the easiest in the world to deal with, having too many abstractions and too few comments. ;-( I've enhanced the mechanism so that each tty has its own scrollback buffer, rather than one buffer being shared between all tty's. The default size of these buffers is now 128kB, but can be set in make menuconfig. I'm intending to make sharing a buffer between all tty's be an option, but haven't implemented that yet. The code, as yet, is a bit scruffy (in fact, very scruffy), and I have several technical problems: (i) The scrolling doesn't work on /dev/tty1 aka the console. (ii) When, e.g., /dev/tty6 has been scrolled upwards a bit, and then pressed to go to /dev/tty2, on returning to /dev/tty6, the scrolling has been cancelled and the cursor is no longer visible. However, the scrollback buffer is still present. I think I'm fairly likely to be able to solve (ii). However, (i), the problem with /dev/tty1, has me baffled. I don't know where to start looking for the problem. If anybody with some kernel knowledge could make any suggestions, I'd be very grateful. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback
Hello, Wol. On Thu, Jan 21, 2021 at 09:32:13 +, Wols Lists wrote: > On 20/01/21 19:59, Alan Mackenzie wrote: > > I can understand the kernel maintainers not being enthusiastic about > > the existing code. But that dates from, I believe, the 1990s, when > > RAM was measured in megabytes, and processor speeds in megahertz. > > Optimisation for speed and store usage just isn't important any more. > I think you're being highly optimistic. Bear in mind that this is the > code that was responsible for Alan Cox ceasing linux development, it's > such a pile of steaming manure ... It is indeed a tortuous mess of code, with far too many abstractions, and far too little overview. > Don't ask me why it is, but I think it's got so much stuff wrong with it > that the entire system is marked "beware here be dragons". Over the weekend, I achieved the first part of my task, getting a transparent new driver into the kernel, which would merely pass through to and from /dev/sctty3 to and from /dev/tty3, etc. This works. Now I have to hook up with the /dev/vcs drivers to buffer the text written to the screen, so as to be able to output it again in the event of a -. I would guess I'm around 50% through the task (as in the first 50% takes the first 90% of the time, and the second 50% takes the second 90% of the time). > https://lwn.net/Articles/842415/ > Take a read, as it's mentioned in this article. The website said it would become freely available on 2021-01-28, so I'll read it then. > Cheers, > Wol -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback
Hello, Laurence. On Tue, Jan 19, 2021 at 17:09:03 +, Laurence Perkins wrote: > On Sun, 2021-01-17 at 05:17 +, Thomas Mueller wrote: > > On Sat, 16 Jan 2021 12:01:48 +0000, Alan Mackenzie wrote: > > > I don't know what I'll be doing, long term. For the moment, I'll > > > be hanging onto the working kernel I've got, old though it may be > > > (4.19.97). It might be possible (I'm not sure) to hook up a user > > > space program to the keys - which would take > > > care of the scrolling. This would obviously not work with early > > > kernel messages, but would be better than nothing. I had a look at > > > the GNU screen source code yesterday to see how it managed such > > > things, but it is very sparsely commented, and thus hard work to > > > understand. Maybe I should just cut my losses, and convert to > > > using one of the BSDs. > > 2000 posts per day on Linux kernel list would be more than > > unmanageable for me! I wouldn't say "almost"! > > Is Linus Torvalds' removal of console scrolling the reason why Scroll > > Lock does not work on the console with System Rescue CD or USB, while > > with FreeBSD and NetBSD, I can press Scroll Lock and scroll back? > > I like that ability but don't think Linus Torvalds is listening or > > reading this. > > Further, with System Rescue console, the lines/text go only partway > > down. > > Using screen, now at v4.8, means having to remember a lot of key > > functions, you need a separate reference screen to look them up. > > There is also tmux, which is part of the base system in NetBSD but > > not FreeBSD. > > If Linus cared about his users, he could make the kernel headers more > > user-friendly, installing kernel headers should not be any more > > complicated than copying or downloading. > > Console scrolling is especially useful with an OS or distro that is > > built from the ground up, like Gentoo, Void or Arch, as opposed to > > being installed all at once. > > If more Linux users would go to and try NetBSD or FreeBSD, those OSes > > would have more users, more ideas, more ability to improve. > > You can even cross-compile NetBSD from Linux. You'd need NetBSD > > source tree, but don't have to do anything special to install kernel > > headers. > > Tom > You're getting this second-hand since it was my brother who actually > looked into it, so pardon anything I misremember, but the big problem > is that adding unicode support to vgacon would need a near total > rewrite, and nobody wants to do that since it's a terrible hackjob to > start with. > kmscon is slated to be the replacement. You might want to see if that > can do what you need. I looked kmscon up on Wikipedia, and apparently development ceased several years ago. What I have in mind now is writing a Linux driver, a small piece of code which would piggy-back on the existing virtual terminal drivers, and simply pass everything through to and from the main driver, filtering out things relevant to scrolling, and processing these in my new driver. I've spent the last few evenings reading up on drivers, and reading the relevant source code from 4.19.97. I can understand the kernel maintainers not being enthusiastic about the existing code. But that dates from, I believe, the 1990s, when RAM was measured in megabytes, and processor speeds in megahertz. Optimisation for speed and store usage just isn't important any more. > LMP -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Console scrollback
Hello, Gentoo. On Thu, Jan 14, 2021 at 16:06:38 +, Alan Mackenzie wrote: > On Wed, Jan 13, 2021 at 22:15:25 -, Grant Edwards wrote: > > On 2021-01-13, Alan Mackenzie wrote: > > > I think bringing up a new Gentoo system absolutely requires working in > > > the console, certainly up to the point where X11 and a Window Manager > > > have been installed and debugged. > > I usually install Gentoo via ssh. > > The article I read about the removal of Linux console's backscrolling > > feature said it was mostly due to lack of a maintainer for that code, > > and that if somebody stepped forward to maintain it, it could be revived. > I'm doing my best to step forward, but I suspect that will be almost as > difficult as fixing the bugs in it. ;-) And so it transpired. I subscribed to the linux-kernel list for a short time, and offered my services in a post. Not one single reply did I get. That list is not a friendly one. It gets an almost unmanageable ~2000 posts a day, the vast bulk of which are patches, fragmented into, perhaps, one diff hunk per post. > I'm disappointed that the decision to cut out this important feature was > taken without any serious attempt to find a maintainer. I have the > impression (though I may be wrong), that the problem was talked about on > the linux kernel mailing list, but nobody there took it upon himself to > post on any of the more hard-core distributions' mailing lists, such as > gentoo's. I've come to realise that Linus Torvalds, who personally took the decision to remove the scrolling, doesn't care about users, and indeed regards them with disdain. He cares about _customers_, and Linux's customers are RedHat, Suse, IBM, Intel, and the other HW manufacturers. RedHat customers don't use the console, therefore the console isn't important. It's a bit like Microsoft's attitude towards users. Sure, Linus went through the motions of pretending to try to find a maintainer, but didn't put any serious effort into it. He argued that "nobody" uses it anyway, therefore it is unimportant, which is an ironic echo of the argument that nobody uses Linux on a desktop PC. Even if the bugs came to be fixed, I doubt the scrolling would be allowed back into the kernel, for the above reasons. Exactly what the bugs are in the scrolling code wasn't gone into on the list, despite more than one contributor asking. > > FWOW, if you really want backscrolling on the console, you can get > > that with screen, but doing so would drive me nuts, since I'd have to > > break all my fingers to stop them from typeing ctrl-A to move the > > start of a line. I've switched screen's meta-character a few times, > > but everytime I try that I find my fingers already have something else > > assigned to that control character (which I had forgotten about). It > > would be nice if I could print out my fingers' assignment table to > > find an unused control character, but that doesn't seem to be how it > > works. > Can one set up a "basic" screen which doesn't use a meta-character? I don't know what I'll be doing, long term. For the moment, I'll be hanging onto the working kernel I've got, old though it may be (4.19.97). It might be possible (I'm not sure) to hook up a user space program to the keys - which would take care of the scrolling. This would obviously not work with early kernel messages, but would be better than nothing. I had a look at the GNU screen source code yesterday to see how it managed such things, but it is very sparsely commented, and thus hard work to understand. Maybe I should just cut my losses, and convert to using one of the BSDs. > > -- > > Grant -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: Console scrollback
Hello, Grant. On Wed, Jan 13, 2021 at 22:15:25 -, Grant Edwards wrote: > On 2021-01-13, Alan Mackenzie wrote: > > I think bringing up a new Gentoo system absolutely requires working in > > the console, certainly up to the point where X11 and a Window Manager > > have been installed and debugged. > I usually install Gentoo via ssh. > The article I read about the removal of Linux console's backscrolling > feature said it was mostly due to lack of a maintainer for that code, > and that if somebody stepped forward to maintain it, it could be revived. I'm doing my best to step forward, but I suspect that will be almost as difficult as fixing the bugs in it. ;-) I'm disappointed that the decision to cut out this important feature was taken without any serious attempt to find a maintainer. I have the impression (though I may be wrong), that the problem was talked about on the linux kernel mailing list, but nobody there took it upon himself to post on any of the more hard-core distributions' mailing lists, such as gentoo's. > FWOW, if you really want backscrolling on the console, you can get > that with screen, but doing so would drive me nuts, since I'd have to > break all my fingers to stop them from typeing ctrl-A to move the > start of a line. I've switched screen's meta-character a few times, > but everytime I try that I find my fingers already have something else > assigned to that control character (which I had forgotten about). It > would be nice if I could print out my fingers' assignment table to > find an unused control character, but that doesn't seem to be how it > works. Can one set up a "basic" screen which doesn't use a meta-character? > -- > Grant -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback
Hello, Neil. On Wed, Jan 13, 2021 at 18:44:15 +, Neil Bothwick wrote: > On Wed, 13 Jan 2021 18:14:39 +0000, Alan Mackenzie wrote: > > > I see that the kernel code to scroll the console has been stripped out > > > [1]. > > This is appalling. I do all my work on the console (apart from web > > browsing), and with this development, Linux effectively becomes unusable > > to me. I will NOT be bullied into using second rate alternatives like > > X-Windows terminals. > What about screen/tmux? I suppose they'd do at a pinch, but they're both things which get between Linux and my applications, and like X-Windows, they offer "features" which I don't need and don't want, and hijack key sequences. But I will look into it if I have to. For the moment, I can get by by not updating my kernel. > -- > Neil Bothwick > WinErr 00D: Window closed - Do not look outside -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback
Hello, Grant.
On Wed, Jan 13, 2021 at 12:32:28 -0700, Grant Taylor wrote:
> On 1/13/21 11:14 AM, Alan Mackenzie wrote:
> > This is appalling. I do all my work on the console (apart from web
> > browsing), and with this development, Linux effectively becomes
> > unusable to me. I will NOT be bullied into using second rate
> > alternatives like X-Windows terminals.
> Wow. I don't think I've run into someone that was a devout
> {physical,virtual} /console/ user in quite a while.
> I'm curious what you do in the Linux console that can't be done in a
> terminal emulator.
Well, there's really not much that can't be done in a terminal emulator.
But it's the manner of the doing that's important. Doing text work in X
is s l u g g i s h. Changing from one application to another, which
would be achieved by, say Alt-F4 on a console takes more key sequences
in X, and is less than instantaneous. The X terminal emulator tends not
to occupy the whole screen - it tends to have title bars, menu items,
tabs even, which just distract from the task at hand. Maybe it can be
set up to take the whole screen, but that's work. And the fonts used
tend to be less distinct and helpful than the 16 x 8 bitmaps I have on
the console. And X windows steals useful key sequences, such as
Alt-Tab. On an Emacs session, in three columns on a console, I can
display 195 consecutive lines of a source file simultaneously.
I could go on, but ...
That's not to say there aren't problems with the tty console - even
before the screen scrolling was removed altogether, it wasn't exactly
anything to write home about. And it would be nice to have more than 16
colours available. But, on balance, I'll stick with the console.
> I know that there is a lot of difference in different terminal
> emulators. -- I *strongly* prefer XTerm as it does things that other
> terminal emulators have never heard of.
> Please share if you do things that /can/ be done in the Linux console
> that /can't/ be done in a terminal emulator.
I think bringing up a new Gentoo system absolutely requires working in
the console, certainly up to the point where X11 and a Window Manager
have been installed and debugged.
> If it's just preference, then hat's off to you.
> --
> Grant. . . .
> unix || die
--
Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Console scrollback
Hello, Peter. On Wed, Jan 13, 2021 at 10:30:19 +, Peter Humphrey wrote: > Hello list, > I see that the kernel code to scroll the console has been stripped out > [1]. This is appalling. I do all my work on the console (apart from web browsing), and with this development, Linux effectively becomes unusable to me. I will NOT be bullied into using second rate alternatives like X-Windows terminals. Thanks for the heads up! > What do people use instead? Well, it looks like I'll have to stop upgrading my kernel at 5.8.n. That can only be a short term answer, though. > This loss is a nuisance while installing a new system, as I am still > trying to do on my old laptop. > 1. https://soylentnews.org/article.pl?sid=20/09/15/1824233=rss Question: I'm a C hacker; how do I go about getting to restore (and enhance) this essential facility myself? > -- > Regards, > Peter. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Gobbledegook error message from emerge.
Hello, Neil. On Fri, Dec 11, 2020 at 21:05:48 +, Neil Bothwick wrote: > On Fri, 11 Dec 2020 18:08:55 +0000, Alan Mackenzie wrote: > > I got back a horrendously long list of packages to merge (most of them > > re-merges), followed by: > > emerge: there are no ebuilds built with USE flags to satisfy > > "dev-python/pycparser[python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]". > > !!! One of the following packages is required to complete your request: > > - dev-python/pycparser-2.20-r1::gentoo (Change USE: > > +python_targets_python3_7) > > - dev-python/cffi-1.14.0-r3::gentoo (Change USE: > > -python_targets_python3_7) (dependency required by > A required package is just a dependency. If package A depends on package > B then package B is required is you have A installed. OK. I can now see that "dependency required by" just means "is a dependency of". Dependency is a relationship; it is not a thing. > > "dev-python/cffi-1.14.0-r3::gentoo" [ebuild]) (dependency required by > > "dev-python/bcrypt-3.2.0::gentoo" [installed]) (dependency required by > > "dev-python/paramiko-2.7.1::gentoo" [installed]) (dependency required > > by "dev-vcs/bzr-2.7.0::gentoo" [installed]) > This is part of the python cleanup/upgrade already discussed at length on > this list over the past week, so the answers are already available. Yes, sorry. I've not been keeping up with the list as assiduously as I might. > You have had some useful replies already but one thing I noticed it > that this is brought about by bzr, which is no longer in portage. > Unless you have it installed from an overlay for a particular need of > yours, you should let it be depcleaned. Yes, bazaar was indeed the sticking point. It's been unmaintained for quite a few years, and is written in python. I just unmerged it, then the mega-merge went ahead without problems (though I excluded libreoffice from that merge, for now). I still amn't happy about the error message I got. But I'm not unhappy enough about it to invest the time needed to get up to speed on portage and submit patches. :-( Anyhow, thanks for the tip! > -- > Neil Bothwick > A TRUE Klingon warrior does not comment his code! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Gobbledegook error message from emerge.
Hello, Mark. On Fri, Dec 11, 2020 at 12:11:02 -0700, Mark Knecht wrote: > On Fri, Dec 11, 2020 at 11:09 AM Alan Mackenzie wrote: > > > (dependency required by "dev-vcs/bzr-2.7.0::gentoo" [installed]) > > (dependency required by "@selected" [set]) > > (dependency required by "@world" [argument]) > So I'm totally guessing here but as you have no other responses yet: > I'd start near the 'top', which of course is near the bottom. > What is 'bzr'? > https://packages.gentoo.org/categories/dev-vcs It is (or was) the version control system bazaar. It was a competitor for mercurial and git, but just wasn't quite as good. It was poorly documented, too (like git still is). It became unmaintained maybe three or four years ago. And it was written in python. > I do not see 'bzr' on this page. Is it something left over in your world > file, or just installed by some other app and no longer used, or moved to > some other package category? I used to use bazaar until the Emacs project converted to git. It's time I expunged it altogether. > If you don't know what it is and think you don't need it then if it were me > I'd consider just removing it and letting emerge @world figure out how to > proceed. > And all of that is just a guess. No Gentoo available right now to delve > further. > Best of luck, Thanks! > Mark -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Gobbledegook error message from emerge.
Hello, Gentoo. I'm angry, because I've wasted several hours trying to decypher a wholly unintuitive error "message" from emerge. Because of this, it's been too long since I've been able to update. Help, please! The command I typed in was # time emerge -auND @world. I got back a horrendously long list of packages to merge (most of them re-merges), followed by: emerge: there are no ebuilds built with USE flags to satisfy "dev-python/pycparser[python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]". !!! One of the following packages is required to complete your request: - dev-python/pycparser-2.20-r1::gentoo (Change USE: +python_targets_python3_7) - dev-python/cffi-1.14.0-r3::gentoo (Change USE: -python_targets_python3_7) (dependency required by "dev-python/cffi-1.14.0-r3::gentoo" [ebuild]) (dependency required by "dev-python/bcrypt-3.2.0::gentoo" [installed]) (dependency required by "dev-python/paramiko-2.7.1::gentoo" [installed]) (dependency required by "dev-vcs/bzr-2.7.0::gentoo" [installed]) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) . What is the syntax and semantics of that first line? Is it explained somewhere in the emerge manual? What do the square brackets mean? What do the commas within these square brackes mean? AND? OR? What about the question marks following minus signs inside parentheses? What does "(Change USE: +python_targets_python3_7)" mean? Is it a suggestion to me that I should change some USE flag somewhere? Or is it telling me that a changed USE flag is the reason for all the trouble? Or does it mean something else? What is "dependency required by" supposed to mean? I can understand a dependency of A on B. I can understand A being required by B. But a dependency being required? what does this mean? Presumably to get out of the mess I've got to do something with one of the packages which "is required to complete your request". Surely somebody in the Gentoo portage team must see that printing human readable error messages is a worthwhile thing to do. Surely? -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Lots of Fail.
Hello, Alan. On Sat, Nov 14, 2020 at 13:24:34 -0500, Alan Grimes wrote: > First, my 3960x nearly melted the last few days, my cooling loop had run > almost dry. (apparent boil off...) root cause appears to be some kind of > chemical issue with my coolant that had resulted in the waterblock being > almost completely clogged preventing it from doing anything but getting > red hot, (north of 105C !!) so PSA = CHECK YOUR WATER LOOPS!!! So, you got a water block in your waterblock. I'm sure that's not as funny as it sounds. > Anyway, I cleaned and flushed it at least enough to get it running again. It's good you noticed it in time to stop your machine melting. > Since I rebooted for the first time in a month+, I need to update my > packages. Every cloud has a silver lining. > One of the fails I'm getting is a bunch of packages looking for > libgit2.so.1.0, Ofcourse we now have libgit2.so.1.1 > Who in god's name requires a specific minor version of a package!?!?!?! > Pure madness!!! There is madness in Linux! But I think so.1.1 can be functonally different from so.1.0. It's in the third digit where only bug fixes etc., are allowed. Something like so.1.0.1 may not have a different functionality to so.1.0.0. > My much bigger problem is: > atg@tortoise ~ $ chromium > chromium-browser: error while loading shared libraries: libre2.so.8: > cannot open shared object file: No such file or directory > atg@tortoise ~ $ > So I tried to 'emptytree chromium' and got hit by the libgit2 problem in > librsvg, also hit it in a number of other packages... =\ Sometimes Gentoo can be fun. > -- > The vaccine is a LIE. > #EggCrisis > The Great Reset > Powers are not rights. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] OT: Red jack and white jack on a pair of headphones
Hello, Joshua. On Sun, Oct 18, 2020 at 13:44:40 -0400, Poison BL. wrote: > On Sun, Oct 18, 2020 at 1:35 PM Alan Mackenzie wrote: > > Hello, Gentoo. > > I've recently found a pair of headphones with a microphone. I've no idea > > where it came from, but I'd like to try it out. I've got no manual for > > it. I'm not even sure it's functional. > > It has a red (stereo) 3.5mm jack plug and a white (stereo) 3.5mm jack > > plug. I'm assuming that one of these is for the headphones and the other > > for the microphone, and that they plug into the pale green and pink jack > > sockets on my PC. > > But which is which? I don't want to destoy anything by connecting them > > the wrong way around. > > Help would be appreciated. > > Thanks! > > -- > > Alan Mackenzie (Nuremberg, Germany). > It shouldn't damage anything to get it backwards. It's *very* likely > that one of those is mono, not stereo, on the plug, which is the quick > way to find the microphone at a glance, though (unless they were just > too cheap to manage 2 styles of plug in manufacturing) Thanks for the tip! It turns out the white plug is for the earphones, and the red one for the microphone. And yes, they were too cheap to use two styles of plugs. The tone quality is not all that high. Still, better to try it out before throwing it away. > -- > Poison [BLX] > Joshua M. Murphy -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] OT: Red jack and white jack on a pair of headphones
Hello, Gentoo. I've recently found a pair of headphones with a microphone. I've no idea where it came from, but I'd like to try it out. I've got no manual for it. I'm not even sure it's functional. It has a red (stereo) 3.5mm jack plug and a white (stereo) 3.5mm jack plug. I'm assuming that one of these is for the headphones and the other for the microphone, and that they plug into the pale green and pink jack sockets on my PC. But which is which? I don't want to destoy anything by connecting them the wrong way around. Help would be appreciated. Thanks! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] How do I compress jpeg files?
Hello, tastytea. On Fri, Sep 18, 2020 at 15:58:59 +0200, tastytea wrote: > On 2020-09-18 13:32+0000 Alan Mackenzie wrote: > > I've a number of jpeg files, 17 to be precise, which are high > > resolution and are around 3½ megabytes each. I would like to > > compress them down to around 100 kb each. > > I'm sure this is possible, if tedious, in gimp, somehow, but I can't > > for the life of me work out how (since it's years since I last did > > this). > > What is the best way (minimal learning, scriptable if possible), to do > > this? > I'm not aware of a way that allows you to specify a file size, but you > can use convert from media-gfx/imagemagick to re-compress and/or resize > the files. For example: > convert -quality 50 in.jpg out.jpg > convert -resize 1000 in.jpg out.jpg > The last command makes the image 1000px wide and sets the height > automatically to the right value. > Hope this helps, Thanks, it helped enormously! Having emerged imagemagick, with convert -quality 20 in.jpg out.jpg in a for loop, I got the size down to around 200 kb each, without much degradation in the picture quality. > tastytea -- Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] How do I compress jpeg files?
Hello, Gentoo! I've a number of jpeg files, 17 to be precise, which are high resolution and are around 3½ megabytes each. I would like to compress them down to around 100 kb each. I'm sure this is possible, if tedious, in gimp, somehow, but I can't for the life of me work out how (since it's years since I last did this). What is the best way (minimal learning, scriptable if possible), to do this? Thanks in advance! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Joining PDF files together.
Hello, everybody on Gentoo. On Thu, Jul 09, 2020 at 13:31:36 +, Alan Mackenzie wrote: > I've just scanned in a two-page document using sane, and it's given me > as output two separate files. I would like to join these together into > a single document. > Would somebody please suggest to me an appropriate package to do this > with. Thanks to everybody who responded with a suggestion. In the end, I used pdfunite, simply because it was there. I don't have (and don't want) Java on my system, so that ruled out pdftk. Gerrit, you were quite right about sane producing ludicrously large PDF files. I should have cut my file down before emailing it off, but laziness got the better of me. :-( gentoo-user is a tremendous group! > Thanks! -- Alan Mackenzie (Nuremberg, Germany).
