Mailing List Archive

On Sat, Jul 8, 2023 at 4:33 AM Dale <rdalek1967@gmail.com> wrote:

> Howdy,
>
> I was wondering. Is there a way to highlight certain packages that are
> about to be upgraded? Example, I like to know when some larger packages
> like Firefox, LOo, that excessively long qt package and a couple others
> are going to be upgraded. Some that are listed in the world file show
> up in a darker green and are easier to see however, some are not. They
> are dependencies of another package but I'd like to have them stick out
> in the list of packages to be upgraded. I don't recall ever seeing
> anyone mention this as a feature of emerge or heard of a way to
> configure such a thing either. That said, it could be possible and just
> not well known.
>
> I'd like to be able to have those packages show up as red or something
> like that. If it is possible.
>
> Thoughts? Ever heard of such a thing?
>
> Dale
>
> :-) :-)


How about first making a list of all files needing to be rebuilt with
something like

emerge -pDuNv @world > builds

Then make a file “long” containing names of demanding builds like firefox
and qtwebengine, one to a line.

Finally, execute

grep -f long builds

which will print the names of those long builds if they’re due for
rebuilding or upgrading.

HTH

John Blinka

>

Dale,

On Saturday, 2023-07-08 03:33:30 -0500, you wrote:

> ...
> I was wondering.? Is there a way to highlight certain packages that are
> about to be upgraded?? Example, I like to know when some larger packages
> like Firefox, LOo, that excessively long qt package and a couple others
> are going to be upgraded.

I simply don't know whether or not build-time related highlighting is
possible in native Portage. I retrieve that information by some script-
ing, which involves sending the output of "emerge --ask" to a log file,
and as soon as "emerge" asks whether to continue, running a script in
another terminal window which analyses this log file using "qlop" and
"gawk".

But to really ban several buld-time hogs from my rig, I added "-clang"
and "-llvm" to my global USE flags, added "dev-lang/rust" to directory
"package.mask/", causing "dev-lang/rust-bin" to be used when necessary,
and besides happily replaced "www-client/firefox" with its binary vari-
ant. I also tried this with "app-office/libreoffice", but sadly its bi-
nary variant does not support exporting to PDF, so I humbly returned to
"app-office/libreoffice" which here needs some three hours to build. If
you don't need this feature, I would recommend using its binary version,
too. Luckily, I don't have many "Qt" packages as dependencies, the lon-
gest build time of these is about 23 minutes here.

Sincerely,
Rainer

On Sat, 8 Jul 2023 03:33:30 -0500, Dale wrote:

> I was wondering.  Is there a way to highlight certain packages that are
> about to be upgraded?  Example, I like to know when some larger packages
> like Firefox, LOo, that excessively long qt package and a couple others
> are going to be upgraded.  Some that are listed in the world file show
> up in a darker green and are easier to see however, some are not. They
> are dependencies of another package but I'd like to have them stick out
> in the list of packages to be upgraded.  I don't recall ever seeing
> anyone mention this as a feature of emerge or heard of a way to
> configure such a thing either.  That said, it could be possible and just
> not well known. 

If your objective is to update your system without the long build times,
put the atoms of the relevant packages in a file and run

emerge --your-options --exclude "$(cat big-packages.txt)" @world


--
Neil Bothwick

"There are two ways to live: you can live as if nothing is a miracle;
you can live as if everything is a miracle."
(Albert Einstein)

Neil Bothwick wrote:
> On Sat, 8 Jul 2023 03:33:30 -0500, Dale wrote:
>
>> I was wondering.  Is there a way to highlight certain packages that are
>> about to be upgraded?  Example, I like to know when some larger packages
>> like Firefox, LOo, that excessively long qt package and a couple others
>> are going to be upgraded.  Some that are listed in the world file show
>> up in a darker green and are easier to see however, some are not. They
>> are dependencies of another package but I'd like to have them stick out
>> in the list of packages to be upgraded.  I don't recall ever seeing
>> anyone mention this as a feature of emerge or heard of a way to
>> configure such a thing either.  That said, it could be possible and just
>> not well known. 
> If your objective is to update your system without the long build times,
> put the atoms of the relevant packages in a file and run
>
> emerge --your-options --exclude "$(cat big-packages.txt)" @world
>
>


I'm just wanting certain packages to stand out more in the list emerge
spits out.  Some require a lot of memory, some have long build times,
some both of those and some require me to restart programs or do other
things.  I already check the changes in USE flags but they stick out
good since they are usually yellow or some other color.  I was curious
if I could set colors for certain packages without reinventing the
wheel.  While I don't recall hearing or seeing anything about it, I
thought it might be possible I just hadn't heard about a feature that
does this. 

Doesn't sound like there is a easy way to do this so I guess just
looking at each package name is the way to go for now. 

Dale

:-)  :-) 

On 2023.07.08 13:02, Dale wrote:
> Neil Bothwick wrote:
> > On Sat, 8 Jul 2023 03:33:30 -0500, Dale wrote:
> >
> >> I was wondering.? Is there a way to highlight certain packages
> that are
> >> about to be upgraded?? Example, I like to know when some larger
> packages
> >> like Firefox, LOo, that excessively long qt package and a couple
> others
> >> are going to be upgraded.? Some that are listed in the world file
> show
> >> up in a darker green and are easier to see however, some are not.
> They
> >> are dependencies of another package but I'd like to have them
> stick out
> >> in the list of packages to be upgraded.? I don't recall ever seeing
> >> anyone mention this as a feature of emerge or heard of a way to
> >> configure such a thing either.? That said, it could be possible
> and just
> >> not well known.?
> > If your objective is to update your system without the long build
> times,
> > put the atoms of the relevant packages in a file and run
> >
> > emerge --your-options --exclude "$(cat big-packages.txt)" @world
> >
> >
>
>
> I'm just wanting certain packages to stand out more in the list emerge
> spits out.? Some require a lot of memory, some have long build times,
> some both of those and some require me to restart programs or do other
> things.? I already check the changes in USE flags but they stick out
> good since they are usually yellow or some other color.? I was curious
> if I could set colors for certain packages without reinventing the
> wheel.? While I don't recall hearing or seeing anything about it, I
> thought it might be possible I just hadn't heard about a feature that
> does this.?
>
> Doesn't sound like there is a easy way to do this so I guess just
> looking at each package name is the way to go for now.?
Using Neil's approach, you do the emerge with the excludes, so you know
there are no problem packages included. Then you run it again, without
the excludes, and all/most of what shows up will be those big/long
packages. No need to hunt through the first list, and the second list
will be much shorted and easier to review. Yes, it would be nice if
portage gave you a way to visually flag certain packages, but it's not
currently an option.

Jack wrote:
> On 2023.07.08 13:02, Dale wrote:
>> Neil Bothwick wrote:
>> > On Sat, 8 Jul 2023 03:33:30 -0500, Dale wrote:
>> >
>> >> I was wondering.  Is there a way to highlight certain packages
>> that are
>> >> about to be upgraded?  Example, I like to know when some larger
>> packages
>> >> like Firefox, LOo, that excessively long qt package and a couple
>> others
>> >> are going to be upgraded.  Some that are listed in the world file
>> show
>> >> up in a darker green and are easier to see however, some are not.
>> They
>> >> are dependencies of another package but I'd like to have them
>> stick out
>> >> in the list of packages to be upgraded.  I don't recall ever seeing
>> >> anyone mention this as a feature of emerge or heard of a way to
>> >> configure such a thing either.  That said, it could be possible
>> and just
>> >> not well known. 
>> > If your objective is to update your system without the long build
>> times,
>> > put the atoms of the relevant packages in a file and run
>> >
>> > emerge --your-options --exclude "$(cat big-packages.txt)" @world
>> >
>> >
>>
>>
>> I'm just wanting certain packages to stand out more in the list emerge
>> spits out.  Some require a lot of memory, some have long build times,
>> some both of those and some require me to restart programs or do other
>> things.  I already check the changes in USE flags but they stick out
>> good since they are usually yellow or some other color.  I was curious
>> if I could set colors for certain packages without reinventing the
>> wheel.  While I don't recall hearing or seeing anything about it, I
>> thought it might be possible I just hadn't heard about a feature that
>> does this. 
>>
>> Doesn't sound like there is a easy way to do this so I guess just
>> looking at each package name is the way to go for now. 
> Using Neil's approach, you do the emerge with the excludes, so you
> know there are no problem packages included.  Then you run it again,
> without the excludes, and all/most of what shows up will be those
> big/long packages.  No need to hunt through the first list, and the
> second list will be much shorted and easier to review.  Yes, it would
> be nice if portage gave you a way to visually flag certain packages,
> but it's not currently an option.
>
>


Thing is, some of the packages are dependencies of other packages. 
Excluding them will likely trigger other problems, such as packages not
being able to upgrade due to others being excluded.  Plus, I'd have to
run it twice and do two separate upgrades.  Usually, I start the upgrade
in a chroot, take a nap and it is done when I wake up.  I'd have to
interrupt my nap for the second set if it is split up. 

Having it highlight the packages so I can see them easier was a thought,
just not a good one.  :/ 

Oh well, we tried.  lol

Dale

:-)  :-) 

On Sat, 8 Jul 2023 14:14:46 -0500, Dale wrote:

> Thing is, some of the packages are dependencies of other packages. 
> Excluding them will likely trigger other problems, such as packages not
> being able to upgrade due to others being excluded.  Plus, I'd have to
> run it twice and do two separate upgrades.  Usually, I start the upgrade
> in a chroot, take a nap and it is done when I wake up.  I'd have to
> interrupt my nap for the second set if it is split up. 
>
> Having it highlight the packages so I can see them easier was a thought,
> just not a good one.  :/ 

But what would you do with the information? If you're just going to see
that there are slow packages there and then carry, what's the point. I
suppose you know you can have a longer nap :)

You could try piping emerge's output through sed to add colour codes
around the packages you want to highlight. How exactly you do this is
left as an exercise for the reader :P


--
Neil Bothwick

Q. How many mathematicians does it take to change a light bulb?
A. Only one - who gives it to six Californians, thereby reducing the
problem to an earlier joke.

Neil Bothwick wrote:
> On Sat, 8 Jul 2023 14:14:46 -0500, Dale wrote:
>
>> Thing is, some of the packages are dependencies of other packages. 
>> Excluding them will likely trigger other problems, such as packages not
>> being able to upgrade due to others being excluded.  Plus, I'd have to
>> run it twice and do two separate upgrades.  Usually, I start the upgrade
>> in a chroot, take a nap and it is done when I wake up.  I'd have to
>> interrupt my nap for the second set if it is split up. 
>>
>> Having it highlight the packages so I can see them easier was a thought,
>> just not a good one.  :/ 
> But what would you do with the information? If you're just going to see
> that there are slow packages there and then carry, what's the point. I
> suppose you know you can have a longer nap :)
>
> You could try piping emerge's output through sed to add colour codes
> around the packages you want to highlight. How exactly you do this is
> left as an exercise for the reader :P
>
>


When I see certain packages, I know to close some of my Firefox profiles
if they require a lot of memory.  For some, I know I need to restart
that program/service.  For some, such as my video drivers, I know to
reload the modules after I logout.  What I do with the info depends on
which package it is.  I just make a mental note that certain things
needs to be done and I know to do them either before I start the upgrade
or after it is done. 

Just as a example, my overnight upgrade included nvidia drivers.  I
didn't see it so when I logged out, no X.  I usually see it but missed
it this time.  Having a way to easily set the colors would be easier but
having to repeat things, create files to scan, use tools I'm not
familiar with and such, that isn't easy.  I wanted to be able to see it
in the initial list, make a note of what packages I need to do things
for and then hit yes to continue.  Basically, I was hoping emerge had a
way to do this that isn't known to me.  After all, the thing all but
washes dishes already.  ROFL 

Maybe one day others will like this idea and one of them is willing to
add some code to emerge to do it.  Until then, I guess I'll just miss
one on occasion and have to scratch my head a couple times. 

Thanks to all.  Interesting ideas but generally over my head.  :/

Dale

:-)  :-) 

Hello Dale,

I solved it like this:

https://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg186292.html

I have reused the configuration file
"/etc/portage/package.env/no_tmpfs.conf"[1], which already contains a
list of packages, which need hours to compile.

-Ramon

[1]
https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#Per-package_choices_at_compile_time

On 08/07/2023 10:33, Dale wrote:
> Howdy,
>
> I was wondering.  Is there a way to highlight certain packages that are
> about to be upgraded?  Example, I like to know when some larger packages
> like Firefox, LOo, that excessively long qt package and a couple others
> are going to be upgraded.  Some that are listed in the world file show
> up in a darker green and are easier to see however, some are not. They
> are dependencies of another package but I'd like to have them stick out
> in the list of packages to be upgraded.  I don't recall ever seeing
> anyone mention this as a feature of emerge or heard of a way to
> configure such a thing either.  That said, it could be possible and just
> not well known.
>
> I'd like to be able to have those packages show up as red or something
> like that.  If it is possible.
>
> Thoughts?  Ever heard of such a thing?
>
> Dale
>
> :-)  :-)
>

--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF

What about piping the output of emerge through 'tee' into a file.  You
can then grep that file for the package names you are interested in, and
they will clearly be highlighted.  True, you will need to look at the
portage output directly to decide whether or not to proceed, and then
separately at the grep of the same text to see if you need to take other
actions.

On 7/8/23 16:20, Dale wrote:
> Neil Bothwick wrote:
>> On Sat, 8 Jul 2023 14:14:46 -0500, Dale wrote:
>>
>>> Thing is, some of the packages are dependencies of other packages.
>>> Excluding them will likely trigger other problems, such as packages not
>>> being able to upgrade due to others being excluded.  Plus, I'd have to
>>> run it twice and do two separate upgrades.  Usually, I start the upgrade
>>> in a chroot, take a nap and it is done when I wake up.  I'd have to
>>> interrupt my nap for the second set if it is split up.
>>>
>>> Having it highlight the packages so I can see them easier was a thought,
>>> just not a good one.  :/
>> But what would you do with the information? If you're just going to see
>> that there are slow packages there and then carry, what's the point. I
>> suppose you know you can have a longer nap :)
>>
>> You could try piping emerge's output through sed to add colour codes
>> around the packages you want to highlight. How exactly you do this is
>> left as an exercise for the reader :P
>>
>>
>
> When I see certain packages, I know to close some of my Firefox profiles
> if they require a lot of memory.  For some, I know I need to restart
> that program/service.  For some, such as my video drivers, I know to
> reload the modules after I logout.  What I do with the info depends on
> which package it is.  I just make a mental note that certain things
> needs to be done and I know to do them either before I start the upgrade
> or after it is done.
>
> Just as a example, my overnight upgrade included nvidia drivers.  I
> didn't see it so when I logged out, no X.  I usually see it but missed
> it this time.  Having a way to easily set the colors would be easier but
> having to repeat things, create files to scan, use tools I'm not
> familiar with and such, that isn't easy.  I wanted to be able to see it
> in the initial list, make a note of what packages I need to do things
> for and then hit yes to continue.  Basically, I was hoping emerge had a
> way to do this that isn't known to me.  After all, the thing all but
> washes dishes already.  ROFL
>
> Maybe one day others will like this idea and one of them is willing to
> add some code to emerge to do it.  Until then, I guess I'll just miss
> one on occasion and have to scratch my head a couple times.
>
> Thanks to all.  Interesting ideas but generally over my head.  :/
>
> Dale
>
> :-)  :-)
>

Jack wrote:
> What about piping the output of emerge through 'tee' into a file.  You
> can then grep that file for the package names you are interested in,
> and they will clearly be highlighted.  True, you will need to look at
> the portage output directly to decide whether or not to proceed, and
> then separately at the grep of the same text to see if you need to
> take other actions.
>


I think on most occasions it would be faster to just read every package
name being listed instead of doing other repetitive things.  I was
trying to make them more obvious, stand out more or something that would
catch my eye as I scan the list for USE changes.  The USE changes stand
out pretty good as they are.  I've read where one can change the default
colors as some background colors make the default colors hard to see.  I
use a black background so the default works fine for me, yellow stands
out pretty good for USE changes.  Since it highlights USE changes
already, I thought there might be a way to change colors of certain
package names as well, just maybe.  I was doubtful but in the past,
someone posts something that emerge does that is either new or I never
heard of before.  I was shooting in the dark but thought I'd ask.  Turns
out, I needed it this time.  I totally missed the nvidia upgrade and it
is usually shown as a world file entry which stands out a little more,
not much but a little. 

I see another batch of KDE packages was just released.  I may upgrade
again later tonight or tomorrow.  If I had known those were coming, I'd
have waited until tomorrow to upgrade.  :/

Even a blind squirrel finds a acorn every once in a while.  LOL 

Dale

:-)  :-) 

Ramon Fischer wrote:
> Hello Dale,
>
> I solved it like this:
>
> https://www.mail-archive.com/gentoo-user@lists.gentoo.org/msg186292.html
>
> I have reused the configuration file
> "/etc/portage/package.env/no_tmpfs.conf"[1], which already contains a
> list of packages, which need hours to compile.
>
> -Ramon
>
> [1]
> https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#Per-package_choices_at_compile_time
>


I need more than just packages that take a while to compile. I need a
list of packages that require large amounts of memory, needs restarting
after upgrade is done and other things.  I already use notmpfs on a few
packages.  That works fine.  Things is, I need to know about other
packages for other reasons as well.  Upgrading nvidia is one.  It uses
little memory to upgrade but it does require the modules to be reloaded. 

Maybe one of these days. 

Dale

:-)  :-) 

On Sat, 8 Jul 2023 15:44:47 -0500, Dale wrote:

> > I have reused the configuration file
> > "/etc/portage/package.env/no_tmpfs.conf"[1], which already contains a
> > list of packages, which need hours to compile.
> >
> > -Ramon
> >
> > [1]
> > https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#Per-package_choices_at_compile_time
> >
>
>
> I need more than just packages that take a while to compile. I need a
> list of packages that require large amounts of memory, needs restarting
> after upgrade is done and other things.  I already use notmpfs on a few
> packages.  That works fine.  Things is, I need to know about other
> packages for other reasons as well.  Upgrading nvidia is one.  It uses
> little memory to upgrade but it does require the modules to be
> reloaded. 

You can do a lot with package.env, including sending notifications
to remind you to do this. I also run app-admin/needrestart after each
emerge to list any services that need restarting.


--
Neil Bothwick

He who asks a question is a fool for a minute,
He who doesn't ask is a fool for a lifetime.

Neil Bothwick wrote:
> On Sat, 8 Jul 2023 15:44:47 -0500, Dale wrote:
>
>>> I have reused the configuration file
>>> "/etc/portage/package.env/no_tmpfs.conf"[1], which already contains a
>>> list of packages, which need hours to compile.
>>>
>>> -Ramon
>>>
>>> [1]
>>> https://wiki.gentoo.org/wiki/Portage_TMPDIR_on_tmpfs#Per-package_choices_at_compile_time
>>>
>>
>> I need more than just packages that take a while to compile. I need a
>> list of packages that require large amounts of memory, needs restarting
>> after upgrade is done and other things.  I already use notmpfs on a few
>> packages.  That works fine.  Things is, I need to know about other
>> packages for other reasons as well.  Upgrading nvidia is one.  It uses
>> little memory to upgrade but it does require the modules to be
>> reloaded. 
> You can do a lot with package.env, including sending notifications
> to remind you to do this. I also run app-admin/needrestart after each
> emerge to list any services that need restarting.
>
>

I just wanted to be able to see them better in the output of emerge. 
Anything else just creates more work and consumes more time than it
saves.  Once I scan the list, I can hit yes and let it start.  If I see
Firefox, LOo or others, I close Firefox profiles, sometimes Seamonkey,
to free up memory.  If I see packages that are services, I know I need
to restart them, even if checkrestart doesn't show it.  If I see
mplayer, I know that if Smplayer moves to a new video in the playlist,
it will likely fail to start.  Some I just know I can take a nice
loooong nap.  What I do just depends on the package.  I just need it to
be easier to see in the list.  Nothing fancy, just easier to see. 

I use checkrestart still.  I tried needrestart but it does more than I
need.  I found checkrestart in a overlay and I just stuck with it. 
Heck, I still use the rc command, even tho it gripes each time I use
it.  lol 

Dale

:-)  :-) 

On Sat, 8 Jul 2023 17:29:58 -0500, Dale wrote:

> I use checkrestart still.  I tried needrestart but it does more than I
> need.

Just about every program on this computer does more than I need. What
counts is that they do all that I need :)

Have you looked at using sed to add extra colour codes to the output of
emerge?


--
Neil Bothwick

Growing old is mandatory; growing up is optional!!

Neil Bothwick wrote:
> On Sat, 8 Jul 2023 17:29:58 -0500, Dale wrote:
>
>> I use checkrestart still.  I tried needrestart but it does more than I
>> need.
> Just about every program on this computer does more than I need. What
> counts is that they do all that I need :)
>
> Have you looked at using sed to add extra colour codes to the output of
> emerge?
>
>


I don't know anything about sed.  Heck, it took me a long to to even get
started with grep.  ROFL

Dale

:-)  :-) 

On 08/07/2023 21:20, Dale wrote:
> Just as a example, my overnight upgrade included nvidia drivers.  I
> didn't see it so when I logged out, no X.  I usually see it but missed
> it this time.  Having a way to easily set the colors would be easier but
> having to repeat things, create files to scan, use tools I'm not
> familiar with and such, that isn't easy.  I wanted to be able to see it
> in the initial list, make a note of what packages I need to do things
> for and then hit yes to continue.  Basically, I was hoping emerge had a
> way to do this that isn't known to me.  After all, the thing all but
> washes dishes already.  ROFL
>
> Maybe one day others will like this idea and one of them is willing to
> add some code to emerge to do it.  Until then, I guess I'll just miss
> one on occasion and have to scratch my head a couple times.
>
> Thanks to all.  Interesting ideas but generally over my head.  :/

Something I saw elsewhere - why don't you put all of these programs into
a list like @system or @world. You can exclude these programs from an
"emerge @world".

I don't know whether these programs will be emerged as dependencies of
an "emerge @world", but if you want to know if they will be emerged, an
"emerge @... --pretend" will tell you.

So firstly, you know whether any of these programs are going to be
emerged. Secondly, you can emerge all the hogs in one go. And thirdly,
you you can emerge @world before or after.

So, I guess, if you don't exclude these hogs from @world then you can
just find out if they are going to be emerged (and emerge them first if
you want), or if you do exclude them from @world, you can emerge them
(to some extent at least) on your own timescale.

Cheers,
Wol

On 08/07/2023 11:33, Dale wrote:
> that excessively long qt package
Off-topic, but just in case you mean qtwebengine, I was able to get rid
of it by putting "-webengine" in my USE flags. After a world update, a
depclean should then remove it from the system.

You might have to juggle a few other USE flags in specific packages to
make it happen though, I forgot. It's been a while.

Nikos Chantziaras wrote:
> On 08/07/2023 11:33, Dale wrote:
>> that excessively long qt package
> Off-topic, but just in case you mean qtwebengine, I was able to get
> rid of it by putting "-webengine" in my USE flags. After a world
> update, a depclean should then remove it from the system.
>
> You might have to juggle a few other USE flags in specific packages to
> make it happen though, I forgot. It's been a while.
>
>
>


That's a idea but since everything works well enough, I don't mind the
compile times. After all, I nap while it does it anyway.  Someone else
may see that info and find it interesting tho.  Maybe someone with a
laptop or a really under-powered system.  I never thought about trying
to get rid of it.  I didn't know it was possible even. 

Thanks.

Dale

:-)  :-) 

On Monday, 10 July 2023 04:45:52 BST Dale wrote:
> Nikos Chantziaras wrote:
> > On 08/07/2023 11:33, Dale wrote:
> >> that excessively long qt package
> >
> > Off-topic, but just in case you mean qtwebengine, I was able to get
> > rid of it by putting "-webengine" in my USE flags. After a world
> > update, a depclean should then remove it from the system.
> >
> > You might have to juggle a few other USE flags in specific packages to
> > make it happen though, I forgot. It's been a while.
>
> That's a idea but since everything works well enough, I don't mind the
> compile times. After all, I nap while it does it anyway. Someone else
> may see that info and find it interesting tho. Maybe someone with a
> laptop or a really under-powered system. I never thought about trying
> to get rid of it. I didn't know it was possible even.
>
> Thanks.
>
> Dale
>
> :-) :-)

Thanks for the tip, Nikos. I wouldn't mind trying this, because qtwebengine
is a pain to emerge on resource constrained hardware:

>>> Running pre-merge checks for dev-qt/qtwebengine-5.15.10_p20230623
* Checking for at least 20 GiB RAM ...
* Amount of main memory is insufficient, but amount
* of main memory combined with swap is sufficient.
* Build process may make computer very slow! [ ok ]
* Checking for at least 7 GiB disk space at "/var/tmp/portage/dev-qt/
qtwebengine-5.15.10_p20230623/temp" ... [ ok ]
* Checking for at least 150 MiB disk space at "/usr" ... [ ok ]

However, I wonder what will break if I were to do this:

$ euse -i webengine
global use flags (searching: webengine)
************************************************************
no matching entries found

local use flags (searching: webengine)
************************************************************
[- ] webengine
app-misc/recoll: Use dev-qt/qtwebengine for fancy result list display
[- ] 1.34.6-r1 [gentoo]
[- ] 1.35.0 [gentoo]

[- ] webengine
app-office/libalkimia: Enable online quotes using dev-qt/qtwebengine
[- ] (0/8) 8.1.1-r1 [gentoo]

[- ] webengine
app-text/kbibtex: Use dev-qt/qtwebengine for HTML previews
[- ] (5) 0.10.0 [gentoo]

[- ] webengine
dev-python/QtPy: Pull in QtWebEngine and QtWebEngineWidgets modules
[- ] 2.3.1 [gentoo]

[- ] webengine
dev-python/pyside2: Build QtWebEngine and QtWebEngineWidgets modules
[- ] 5.15.9 [gentoo]
[- ] 5.15.10 [gentoo]

[- ] webengine
dev-python/pyside6: Build QtWebEngine and QtWebEngineWidgets modules
[- ] 6.5.0 [gentoo]
[- ] 6.5.1.1 [gentoo]

[- ] webengine
dev-qt/qt-creator: Use dev-qt/qtwebengine to view documentation
[- ] 8.0.2 [gentoo]

[- ] webengine
dev-qt/qt-docs: Install documentation for dev-qt/qtwebengine
[- ] (5) 5.15.2_p202011130614 [gentoo]

[- ] webengine
kde-apps/kaccounts-providers: Enable Nextcloud KAccounts plugin using dev-
qt/qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdecore-meta: Enable www-client/falkon which depends on dev-qt/
qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdeedu-meta: Enable packages requiring dev-qt/qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdenetwork-meta: Enable support for Google Drive integration via
kde-misc/kio-gdrive
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdesdk-meta: Enable dev-util/kdevelop, requiring dev-qt/
qtwebengine
[- ] (5) 22.12.3 [gentoo]
[- ] (5) 23.04.2 [gentoo]
[- ] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/kdeutils-meta: Enable kde-apps/kimagemapeditor, requiring dev-qt/
qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
kde-apps/marble: Use dev-qt/qtwebengine for embedded web browser
[+ B] (5/22.12) 22.12.3 [gentoo]
[+ B] (5/23.04) 23.04.2 [gentoo]
[+ B] (5/23.04) 23.04.3 [gentoo]

[- ] webengine
kde-plasma/discover: Enable webflow support using dev-qt/qtwebview and
dev-qt/qtwebengine instead of default URL handler
[- ] (5) 5.27.5-r1 [gentoo]
[- ] (5) 5.27.6 [gentoo]

[- ] webengine
kde-plasma/kdeplasma-addons: Enable dictionary and web browser applets
using
dev-qt/qtwebengine
[- ] (5) 5.27.5 [gentoo]
[- ] (5) 5.27.6 [gentoo]

[- ] webengine
kde-plasma/libksysguard: Enable display of detailed memory information
using
dev-qt/qtwebengine.
[- ] (5/9) 5.27.5 [gentoo]
[- ] (5/9) 5.27.6 [gentoo]

[- ] webengine
media-sound/musescore: Use dev-qt/qtwebengine for embedded web browser
[- ] 3.6.2-r1 [gentoo]
4.0.2 [gentoo]
[- ] 9999 [gentoo]

[- ] webengine
media-sound/supercollider: Enable the internal help system using
QtWebengine
[- ] 3.13.0 [gentoo]

[- ] webengine
net-im/psi: Enable themed, html-based chatlogs using dev-qt/qtwebengine
[- ] 1.5-r1 [gentoo]
[- ] 9999 [gentoo]

[- ] webengine
net-misc/nextcloud-client: Enable old Flow1 login using dev-qt/qtwebengine
[- ] 3.8.0 [gentoo]
[- ] 3.8.1 [gentoo]
[- ] 3.8.2-r1 [gentoo]

[- ] webengine
net-news/rssguard: Use dev-qt/qtwebengine for embedded web browser
[- ] 4.3.3 [gentoo]
[- ] 4.3.4 [gentoo]
[- ] 4.4.0 [gentoo]

[- ] webengine
net-p2p/ktorrent: Embedded search for torrents using dev-qt/qtwebengine
[+ B] (5) 22.12.3 [gentoo]
[+ B] (5) 23.04.2 [gentoo]
[+ B] (5) 23.04.3 [gentoo]

[- ] webengine
sci-astronomy/stellarium: Show online results about the selected star in
an embedded
window using dev-qt/qtwebengine
[- ] 23.1 [gentoo]

[- ] webengine
sci-geosciences/merkaartor: Enable dev-qt/qtwebengine in some plugins
[- ] 0.19.0-r1 [gentoo]
[- ] 9999 [gentoo]

[- ] webengine
sci-visualization/paraview: Add support for dev-qt/qtwebengine
[+ B] 5.11.1 [gentoo]

On Monday, 10 July 2023 02:25:43 BST Nikos Chantziaras wrote:
> On 08/07/2023 11:33, Dale wrote:
> > that excessively long qt package
>
> Off-topic, but just in case you mean qtwebengine, I was able to get rid
> of it by putting "-webengine" in my USE flags. After a world update, a
> depclean should then remove it from the system.
>
> You might have to juggle a few other USE flags in specific packages to
> make it happen though, I forgot. It's been a while.

Nice idea, but it's not for me I'm afraid:

$ emerge -cvp qtwebengine

Calculating dependencies ... done!
dev-qt/qtwebengine-5.15.10_p20230623 pulled in by:
app-office/kalendar-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5
kde-apps/akregator-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5
kde-apps/grantlee-editor-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5[widgets]
kde-apps/kaccounts-providers-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5
kde-apps/kdepim-runtime-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5[widgets]
kde-apps/kmail-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5[widgets]
kde-apps/kontact-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5[widgets]
kde-apps/libksieve-23.04.3 requires >=dev-qt/qtwebengine-5.15.9:5[widgets]
kde-apps/messagelib-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5[widgets]
net-libs/signon-ui-0.15_p20171022-r1 requires dev-qt/qtwebengine:5
www-client/falkon-23.04.3 requires >=dev-qt/
qtwebengine-5.15.9:5=[widgets], >=dev-qt/qtwebengine-5.15.9:5/5.15=[widgets]


--
Regards,
Peter.

On Mon, 2023-07-10 at 04:25 +0300, Nikos Chantziaras wrote:
> > that excessively long qt package
> Off-topic, but just in case you mean qtwebengine, I was able to get
> rid of it by putting "-webengine" in my USE flags.

I got rid of it by switching to a flatpak version of the singular
desktop application that required it on my system.

Normally I'll always choose a native package but qtwebengine builds for
a program that I run a couple of times a week skews the reward/effort
ratio.

Thank u

David

On Sat, Jul 8, 2023, 4:33 AM Dale <rdalek1967@gmail.com> wrote:

> Howdy,
>
> I was wondering. Is there a way to highlight certain packages that are
> about to be upgraded? Example, I like to know when some larger packages
> like Firefox, LOo, that excessively long qt package and a couple others
> are going to be upgraded. Some that are listed in the world file show
> up in a darker green and are easier to see however, some are not. They
> are dependencies of another package but I'd like to have them stick out
> in the list of packages to be upgraded. I don't recall ever seeing
> anyone mention this as a feature of emerge or heard of a way to
> configure such a thing either. That said, it could be possible and just
> not well known.
>
> I'd like to be able to have those packages show up as red or something
> like that. If it is possible.
>
> Thoughts? Ever heard of such a thing?
>
> Dale
>
> :-) :-)
>
>

On Sun, 9 Jul 2023 13:10:17 -0500, Dale wrote:

> > Just about every program on this computer does more than I need. What
> > counts is that they do all that I need :)
> >
> > Have you looked at using sed to add extra colour codes to the output
> > of emerge?

> I don't know anything about sed.  Heck, it took me a long to to even get
> started with grep.  ROFL

Try this:

Create a file with the package atoms you want to highlight, one per
line, say packages.txt. Then run this command, you'll need to rerun it
each time you edit the packages list

awk '{print "s:\\("$0"\\):\\x1b[1;31m\\1:"}' packages.txt
>|packages.script

Then run

emerge --options @world -p --color y | sed -f packages.script

It highlights any of the packages in your file in bright red. See
https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797 for a list
of colour options.


--
Neil Bothwick

If you give a man a fish, he's fed for a day.
If you teach a man to fish, he'll buy a silly hat.
If you talk about fish to a starving man, you're a consultant.