Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

[Dale]

Dale wrote:
> P Levine wrote:
>> On Sat, Oct 28, 2017 at 2:49 PM, Dale > >wrote:
>>
>> After another round of google searches, startpage
>> actually, I found where someone posted that having a slideshow causes
>> this.  I switched from slideshow to something else and sure
>> enough, it
>> hasn't hogged up memory, yet anyway. 
>>
>> So, disable slideshow until this gets fixed and at least you
>> don't have
>> to worry about it hogging up every last bit of memory. 
>>
>>  
>> ​I vaguely
>>  
>> ​remember reading that the problem might be related to plasmashell
>> ​loading all available slideshow wallpapers into memory.   If you
>> really want slideshow, maybe as a  possible workaround you can see if
>> limiting the number of wallpapers used with slideshow reduces memory
>> consumption.
>>
>
> That would be possible I guess.  Thing is, I have a lot of wallpapers,
> some hi-res large ones that came from NASA at that.  If it tried to
> load them all, I'd had to have a lot more memory.  I think I have over
> 20GBs worth of them.  Currently I have 16GBs of memory.  I'm going to
> upgrade one of these days tho.  My mobo can handle 32GBs but even
> then, I wouldn't want plasmashell to take up that much memory. 
>
> I can test this theory tho.  I can pick a small directory and let it
> cycle through them.  If it is loading them like you read, then it
> shouldn't use more than the space the wallpaper files take up.  If it
> is something else, then it should get real hoggy again.  Spellchecker
> doesn't like my new word hoggy.  lol 
>
> I'm going to test that and see what happens.  I'll post the results,
> just in case someone runs up on this thread, and on the bug report as
> well.
>
> Thanks for the info.
>
> Dale
>
> :-)  :-) 


Well, that didn't take long.  I found a directory that was about 1.6GBs
of wallpapers.  It should not use more than a little over 2GBs of memory
even if it loads all the files in memory.  Well, it took up right at
3GBs in a short period of time.  That would put it using well over what
it normally uses plus the directory.  Usually, it uses about 300MBs at
start up.  Add to that the 1.6GBs and you end up with about 2GBs or so. 
Since it was quickly approaching 3GBs, it was well past that. 

I'm not sure what it is doing but even if it is loading the wallpapers
up, it is doing something else in addition to that. 

I was hoping we were on to something.  Oh well.  It was worth a try.

Thanks.

Dale

:-)  :-) 

Re: [gentoo-user] Alternatives to knutclient

[Dale]

Daniel Frey wrote:
>
> Well, that's odd. I just built it and see nothing of the sort. I built
> it with all USE flags.
>
> I am not using nut now, but I was trying it about a year ago. I did
> have a client (it wasn't knutclient), maybe it was removed from the
> tree. That's disappointing.
>
> How much information do your users need? I'm running KDE5 with apcupsd
> and an APC UPS, and the battery monitor built in to KDE shows me that
> the battery is at 100% (it doesn't really say much else, though.)
>
> Dan
>
>

I seem to recall that one was treecleaned a good while back, few
months.  I can't recall the name but think it was something KDE
related.  I seem to recall --depclean removing it or something here. 
Can't recall why it was removed from the tree tho.

That said, I tried Knutclient here and while it works, it doesn't say
much.  It seems most features don't work with the UPS I have.  It does
show on the command line with a upsc command.  Maybe I need some
different settings or something. 

Dale

:-)  :-) 

Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

[Dale]

P Levine wrote:
> On Sat, Oct 28, 2017 at 2:49 PM, Dale  >wrote:
>
> After another round of google searches, startpage
> actually, I found where someone posted that having a slideshow causes
> this.  I switched from slideshow to something else and sure enough, it
> hasn't hogged up memory, yet anyway. 
>
> So, disable slideshow until this gets fixed and at least you don't
> have
> to worry about it hogging up every last bit of memory. 
>
>  
> ​I vaguely
>  
> ​remember reading that the problem might be related to plasmashell
> ​loading all available slideshow wallpapers into memory.   If you
> really want slideshow, maybe as a  possible workaround you can see if
> limiting the number of wallpapers used with slideshow reduces memory
> consumption.
>

That would be possible I guess.  Thing is, I have a lot of wallpapers,
some hi-res large ones that came from NASA at that.  If it tried to load
them all, I'd had to have a lot more memory.  I think I have over 20GBs
worth of them.  Currently I have 16GBs of memory.  I'm going to upgrade
one of these days tho.  My mobo can handle 32GBs but even then, I
wouldn't want plasmashell to take up that much memory. 

I can test this theory tho.  I can pick a small directory and let it
cycle through them.  If it is loading them like you read, then it
shouldn't use more than the space the wallpaper files take up.  If it is
something else, then it should get real hoggy again.  Spellchecker
doesn't like my new word hoggy.  lol 

I'm going to test that and see what happens.  I'll post the results,
just in case someone runs up on this thread, and on the bug report as well.

Thanks for the info.

Dale

:-)  :-) 

Re: [gentoo-user] Python 3.5

[R0b0t1]

On Sat, Oct 28, 2017 at 8:17 PM, Philip Webb  wrote:
> Python 3.5 has become stable : what are the pro/cons of updating to it ?
> I have in  make.conf :
>
>   USE_PYTHON="2.7 3.4"
>   PYTHON_TARGETS="python2_7 python3_4"
>   PYTHON_SINGLE_TARGET="python3_4"
>
> Is it advisable to replace '3_4' '3.4' with '3_5' '3.5' ?
>

Python 3.5 adds some very novel language features that new projects
have already started to depend on. In fact, some packages (such as
qutebrowser) are soon to require Python 3.6, which provides some
extremely useful extensions to the extremely useful extensions.

If you have nothing that requires it at this moment it is unlikely you
have any need to update, but it is a good practice to track stable.

Cheers,
 R0b0t1.

[gentoo-user] Python 3.5

[Philip Webb]

Python 3.5 has become stable : what are the pro/cons of updating to it ?
I have in  make.conf :

  USE_PYTHON="2.7 3.4"
  PYTHON_TARGETS="python2_7 python3_4"
  PYTHON_SINGLE_TARGET="python3_4"

Is it advisable to replace '3_4' '3.4' with '3_5' '3.5' ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] A portage nuisance

[Michael Orlitzky]

On 10/28/2017 08:10 PM, Wols Lists wrote:
> 
> In other words, I'm asking emerge to automate what I do - look at the
> output, find a subset of packages that I think will work, and then ask
> it to try again with just those packages. I would be very surprised if
> it iterated repeatedly down to the null set.

This should be possible. I've lovingly referred to this option in the
past as something like "emerge --just-fucking-do-anything". I can have
300 packages in my update list, with a bunch of installed stuff
depending on a masked version of ruby, and a package that needs to be
manually uninstalled, and new REQUIRED_USE conflicts, and subslot
rebuilds of things that are now masked, and...

And yet portage still knows that timezone-data is going to get updated.
If I can look through the list and "emerge -1 timezone-data" and have
that work, then portage should be able to figure that out, too. No
matter how long it takes, it can't be slower than me doing it by hand.

Re: [gentoo-user] Re: systemd fails to mount nfs4 mounts

[Adam Carter]

> I'm still having this issue, anyone have any ideas? I can see that
> NetworkManager-Wait-Online finishes, and that the mounting starts
> immediately after, but I don't think the network is quite up yet, resulting
> an all nfs mounts to timeout.
>
> The computer is using a static IP, so it shouldn't even be waiting for
> dhcp...
>
> I booted into openrc, and they all mount properly. Does anyone have any
> idea even how to start troubleshooting this?
>

I had this issue through some versions of systemd - but its fixed now (i'm
on ~adm64). Version is systemd-235-r1.

Are you ~arch?

Re: [gentoo-user] A portage nuisance

[Wols Lists]

On 28/10/17 23:45, Andrew Savchenko wrote:
>> emerge -u world
>> > A will be emerged with options ...
>> > B will be emerged with options ...
>> > C will be emerged with options ...
>> > D is blocked by E
>> > F will be emerged with options ...
>> > G is blocked by H
>> > Giving up, too many circular dependencies
>> > emerge A B C F
> Ah, man, this is where your mistake is. You are assuming that it
>  is possible to get a correct dependency subgraph without building
> full correct dependency graph first. This is not possible and this
> is math. While the approach you described abode may work in some
> practical cases, it will be busted in general case.
> 
> The key moment here is that graph's root node may be changed during
> dependency recalculation based on _how_ conflict is solved, the
> same as all other nodes may be reordered. And dependencies which
> appear to be valid before conflict is resolved may became invalid
> after, consider the following dep tree:
> 
>   A
>  / \
> B   C
> |
>  !{D,E}
> 
> - B and C depends on A;
> - D conflicts with E and both depend on C;
> 
> You assume that !{D,E} conflict can be skipped and A, B, C canbe
> emerged. But let's assume that you selected D later, but D depends
> on F and F conflicts with A[some_flag]. So you'll have to choose
> some alternative to A or change its USE flags, this may require to
> rebuild the whole dependency tree (and build order may change as
> well). In order to prevent dozens (sometimes hundreds or even
> thousands) of useless rebuilds and to avoid leaving intermediate
> tree in the utterly broken state emerge fails if it can't build the
> dependency graph.

EXCEPT.

My "emerge A B C F" will presumably then fail with those conflicts, and
it will loop again and just do an "emerge A".

I'm not saying "prune the graph first time, then just emerge
everything". I'm saying "prune the graph, and try again with the reduced
set".

Thing is, I have always found that deleting blockers "emerge -C1", and
emerging everything that I can get to emerge, is almost guaranteed to
end up with a system where everything eventually emerges.

The problem I have is that, if I delay updating (or something like kde
with its gazillions of packages is upgraded), I end up with maybe 300
packages to be emerged. Trying to sort that mess out is a nightmare
especially when emerge starts blowing up with circular dependencies and
stuff, and old packages blocking new ones - "A version 2 is blocked by A
version 1" etc etc. And all too often deleting the current version A
(and the other packages - slated for replacement - that depend on A)
fixes the problem.

I think we're having a misunderstanding here. If emerge does what I'm
asking for, and leaves the system in a broken state (as you seem to
think it will), then that's a serious bug in emerge. You seem to think
I'm asking emerge to prune the dependency tree - I'm not. I'm asking for
it to prune the package list - if it can't sort out dependencies, drop
that package from the package list and then, when it's got a list of
packages that it thinks will work, go back to the start and try to
emerge just those (calculating a new dependency tree).

In other words, I'm asking emerge to automate what I do - look at the
output, find a subset of packages that I think will work, and then ask
it to try again with just those packages. I would be very surprised if
it iterated repeatedly down to the null set.

As for doing useless rebuilds, isn't that MY call, not yours? What is
most valuable - my time, or my computer's time? As it stands, I have to
babysit an emerge - calculating the full graph bombs, so I have to try
to emerge a small subset, which might bomb, and when that works I try
again with the full set that bombs, so I have to iterate again, ad
nauseam ... I like to work on the principle "if the computer can
automate what I do, then it should ..."

What would you recommend as the best way (for somebody who's knowledge
of gentoo is patchy) of dealing with the situation when an emerge blows
up with loads of circular dependencies finishing with the message "too
many errors, giving up"? As opposed to my way of "emerge what I can,
then see what more emerges", which I have always found eventually fixes
everything.

Cheers,
Wol

Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

[P Levine]

On Sat, Oct 28, 2017 at 2:49 PM, Dale  wrote:

> After another round of google searches, startpage
> actually, I found where someone posted that having a slideshow causes
> this.  I switched from slideshow to something else and sure enough, it
> hasn't hogged up memory, yet anyway.
>
> So, disable slideshow until this gets fixed and at least you don't have
> to worry about it hogging up every last bit of memory.


​I vaguely

​remember reading that the problem might be related to plasmashell ​loading
all available slideshow wallpapers into memory.   If you really want
slideshow, maybe as a  possible workaround you can see if limiting the
number of wallpapers used with slideshow reduces memory consumption.

[gentoo-user] Re: systemd fails to mount nfs4 mounts

[Daniel Frey]

On 10/13/2017 03:13 PM, Daniel Frey wrote:
I discovered that after my update the other day (systemd is up to date 
as of Wednesday) that my remote nfs mounts are failing on startup.


(Note: as per my other thread, I haven't tried to disable ipv6 yet. I 
want to figure this out first.)


I use an IMSM raid with an initramfs provided by dracut.

I have also set:

  NetworkManager-wait-online.service
loaded active exited    Network Manager Wait Online


to wait until networkmanager starts up, and it appears to be working.

When booting, something complains about the module sunrpc not being able 
to be loaded. However, everything I've selected relating to nfs is built 
directly into the kernel, so there shouldn't be external modules to 
begin with.


After logging in, dropping to the shell and manually mounting these nfs 
mounts work.


systemctl status:
● mnt-nas-Pictures.mount    loaded failed 
failed /mnt/nas/Pictures


status:

# systemctl status mnt-nas-Pictures.mount
● mnt-nas-Pictures.mount - /mnt/nas/Pictures
    Loaded: loaded (/etc/fstab; generated; vendor preset: disabled)
    Active: failed (Result: timeout) since Fri 2017-10-13 14:51:08 PDT; 
17min ago

     Where: /mnt/nas/Pictures
  What: nas:/Pictures
  Docs: man:fstab(5)
    man:systemd-fstab-generator(8)
   Process: 781 ExecMount=/bin/mount nas:/Pictures /mnt/nas/Pictures -t 
nfs4 -o rw,defaults,_netdev,intr,bg (code=killed, signal=TERM)


Oct 13 14:49:37 myboringpc systemd[1]: Mounting /mnt/nas/Pictures...
Oct 13 14:51:08 myboringpc systemd[1]: mnt-nas-Pictures.mount: Mounting 
timed out. Stopping.
Oct 13 14:51:08 myboringpc systemd[1]: mnt-nas-Pictures.mount: Mount 
process exited, code=killed status=15

Oct 13 14:51:08 myboringpc systemd[1]: Failed to mount /mnt/nas/Pictures.
Oct 13 14:51:08 myboringpc systemd[1]: mnt-nas-Pictures.mount: Unit 
entered failed state.


So it is saying it was killed. When booting up, systemd sits waiting for 
a start job for two minutes. I rebooted and checked again, and it said 
it timed out. I can see it's waiting for Network Manager Wait Online, 
then it tries to mount the nfs shares.


I presume this means the network is not ready. As I mentioned above, 
logging in and manually mounting is working fine.


Anyone have any suggestions? Of course I didn't notice this until I 
tried to sync pictures from my phone...


Dan


I'm still having this issue, anyone have any ideas? I can see that 
NetworkManager-Wait-Online finishes, and that the mounting starts 
immediately after, but I don't think the network is quite up yet, 
resulting an all nfs mounts to timeout.


The computer is using a static IP, so it shouldn't even be waiting for 
dhcp...


I booted into openrc, and they all mount properly. Does anyone have any 
idea even how to start troubleshooting this?


Dan

Re: [gentoo-user] Alternatives to knutclient

[Daniel Frey]

On 10/28/2017 09:48 AM, Mick wrote:

On Saturday, 28 October 2017 15:18:26 BST Daniel Frey wrote:

On 10/28/2017 01:58 AM, Mick wrote:

Hi All,

I've been using the net-misc/knutclient GUI application to provide
information to desktop users of the state of the UPS.  Portage is telling
me this package depends on Qt4, it has received no development upstream
and is due to be ditched:

!!! The following installed packages are masked:
- net-misc/knutclient-1.0.5::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Andreas Sturmlechner  (21 Oct 2017)
# Dead upstream, depends on dead kdelibs4/Qt4.
# Masked for removal in 30 days. Bug #629018

Is there some other GUI front end for nut in portage I could use in its
place?

Have you tried the one that comes with the nut package? There should be
one installed with it. Although, I can't remember if it docks in the tray.

Dan


Thanks Dan,

 From what I see here there are number of GUI interfaces and NUT-Monitor
seems to be the application built in nut:

http://networkupstools.org/projects.html#_graphical_desktop_clients

However, I'm not sure it was built in my case:

$ find /usr/bin -iname *nut*
/usr/bin/binutils-config
/usr/bin/nut-scanner
/usr/bin/knutclient

This is how I built nut:

  Installed versions:  2.7.3(12:42:59 18/04/17)(ssl tcpd ups_drivers_al175
ups_drivers_apcsmart ups_drivers_apcsmart-old ups_drivers_apcupsd-ups
ups_drivers_bcmxcp ups_drivers_bcmxcp_usb ups_drivers_belkin
ups_drivers_belkinunv ups_drivers_bestfcom ups_drivers_bestfortress
ups_drivers_bestuferrups ups_drivers_bestups ups_drivers_blazer_ser
ups_drivers_blazer_usb ups_drivers_clone ups_drivers_clone-outlet
ups_drivers_dummy-ups ups_drivers_etapro ups_drivers_everups
ups_drivers_gamatronic ups_drivers_genericups ups_drivers_isbmex
ups_drivers_ivtscd ups_drivers_liebert ups_drivers_liebert-esp2
ups_drivers_masterguard ups_drivers_metasys ups_drivers_mge-shut
ups_drivers_mge-utalk ups_drivers_microdowell ups_drivers_nutdrv_qx
ups_drivers_oldmge-shut ups_drivers_oneac ups_drivers_optiups
ups_drivers_powercom ups_drivers_powerpanel ups_drivers_rhino
ups_drivers_richcomm_usb ups_drivers_riello_ser ups_drivers_riello_usb
ups_drivers_safenet ups_drivers_solis ups_drivers_tripplite
ups_drivers_tripplite_usb ups_drivers_tripplitesu ups_drivers_upscode2
ups_drivers_usbhid-ups ups_drivers_victronups usb xml -cgi -ipmi -selinux -
snmp -ups_drivers_netxml-ups -ups_drivers_nut-ipmipsu -ups_drivers_snmp-ups -
zeroconf)

What am I missing?



Well, that's odd. I just built it and see nothing of the sort. I built 
it with all USE flags.


I am not using nut now, but I was trying it about a year ago. I did have 
a client (it wasn't knutclient), maybe it was removed from the tree. 
That's disappointing.


How much information do your users need? I'm running KDE5 with apcupsd 
and an APC UPS, and the battery monitor built in to KDE shows me that 
the battery is at 100% (it doesn't really say much else, though.)


Dan

Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

[Dale]

R0b0t1 wrote:
> On Sat, Oct 28, 2017 at 5:35 PM, Dale  wrote:
>> P Levine wrote:
>>
>>
>>
>> On Sat, Oct 28, 2017 at 2:49 PM, Dale  wrote:
>>> Now let us pray that there is a fix soon enough.  I miss my slideshow.  :(
>>
>> You could track it here: https://bugs.kde.org/show_bug.cgi?id=344879
>>
>>
>>
>> That link didn't work but I found it by the number.  It is a bit dated so I
>> found this new one:
>>
>> https://bugs.kde.org/show_bug.cgi?id=385970
>>
>> For some reason, that didn't show up on my searches, usually does but not
>> this time.  Odd.  Anyway, I'll post my info there to just so the other guy
>> doesn't feel lonely.  ;-)
>>
> Moral support is extremely important on bug trackers.
>
>


Plus it helps the devs know it affects more than one person.  Sometimes,
the added info can narrow down a cause, even down to a specific change. 
Plus, if they can provide a patch that I can use here, I could even test
it.  I've already got a couple patches here that come in handy. 

Hopefully this will get a fix soon.  Having the world map thingy isn't
all bad.  I can see daylight and dark coming.  lol 

Dale

:-)  :-) 

Re: [gentoo-user] A portage nuisance

[Andrew Savchenko]

On Sat, 28 Oct 2017 22:59:26 +0100 Anthony Youngman wrote:
[...]
> All I'm asking is that as it progresses, it makes a list of those 
> packages it can resolve the dependencies for. If it then gives up with 
> the current list it's processing, eg "world", it then goes back to the 
> list it thinks it can process, and has another go with them.
> 
> Because that's exactly what I do, take the first few packages off the 
> list that look fine, and emerge them. I then re-run the original emerge, 
> rinse and repeat, but it takes absolutely ages, and worse I have to 
> babysit the emerge because I'm *expecting* it to hit a problem.
[...]
> To give you a very clear example of what I'm thinking ...
> 
> emerge -u world
> A will be emerged with options ...
> B will be emerged with options ...
> C will be emerged with options ...
> D is blocked by E
> F will be emerged with options ...
> G is blocked by H
> Giving up, too many circular dependencies
> emerge A B C F

Ah, man, this is where your mistake is. You are assuming that it
 is possible to get a correct dependency subgraph without building
full correct dependency graph first. This is not possible and this
is math. While the approach you described abode may work in some
practical cases, it will be busted in general case.

The key moment here is that graph's root node may be changed during
dependency recalculation based on _how_ conflict is solved, the
same as all other nodes may be reordered. And dependencies which
appear to be valid before conflict is resolved may became invalid
after, consider the following dep tree:

  A
 / \
B   C
|
 !{D,E}

- B and C depends on A;
- D conflicts with E and both depend on C;

You assume that !{D,E} conflict can be skipped and A, B, C canbe
emerged. But let's assume that you selected D later, but D depends
on F and F conflicts with A[some_flag]. So you'll have to choose
some alternative to A or change its USE flags, this may require to
rebuild the whole dependency tree (and build order may change as
well). In order to prevent dozens (sometimes hundreds or even
thousands) of useless rebuilds and to avoid leaving intermediate
tree in the utterly broken state emerge fails if it can't build the
dependency graph.

Maybe my example above is synthetic and not the best one, you
should understand that dependencies are very complex, may be
intricately interconnected and there is no way to tell which parts
are correct until all picture is seen.

Best regards,
Andrew Savchenko


pgpBVWkDHhpq1.pgp
Description: PGP signature

Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

[R0b0t1]

On Sat, Oct 28, 2017 at 5:35 PM, Dale  wrote:
> P Levine wrote:
>
>
>
> On Sat, Oct 28, 2017 at 2:49 PM, Dale  wrote:
>>
>> Now let us pray that there is a fix soon enough.  I miss my slideshow.  :(
>
>
> You could track it here: https://bugs.kde.org/show_bug.cgi?id=344879
>
>
>
> That link didn't work but I found it by the number.  It is a bit dated so I
> found this new one:
>
> https://bugs.kde.org/show_bug.cgi?id=385970
>
> For some reason, that didn't show up on my searches, usually does but not
> this time.  Odd.  Anyway, I'll post my info there to just so the other guy
> doesn't feel lonely.  ;-)
>

Moral support is extremely important on bug trackers.

Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

[Dale]

P Levine wrote:
>
>
> On Sat, Oct 28, 2017 at 2:49 PM, Dale  > wrote:
>
> Now let us pray that there is a fix soon enough.  I miss my
> slideshow.  :(
>
>
> You could track it here: ​https://bugs.kde.org/show_bug.cgi?id=344879​
> 


That link didn't work but I found it by the number.  It is a bit dated
so I found this new one:

https://bugs.kde.org/show_bug.cgi?id=385970 

For some reason, that didn't show up on my searches, usually does but
not this time.  Odd.  Anyway, I'll post my info there to just so the
other guy doesn't feel lonely.  ;-)

Thanks much.

Dale

:-)  :-) 

Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

[P Levine]

On Sat, Oct 28, 2017 at 2:49 PM, Dale  wrote:
>
> Now let us pray that there is a fix soon enough.  I miss my slideshow.  :(
>

You could track it here: ​https://bugs.kde.org/show_bug.cgi?id=344879​

Re: [gentoo-user] A portage nuisance

[Anthony Youngman]

On 28/10/17 21:50, Alan McKinnon wrote:

On 28/10/2017 22:39, Anthony Youngman wrote:

On 28/10/17 20:54, Alan McKinnon wrote:

Portage cannot do that, it is backed by silicon and has no concept of
meaning. So it has only one real choice - it can do it all or it does
not try.

I'm not surprised Zac never tried implementing partial graph resolution
for the very simple reason that if you try do it, you have no idea what
is going to be built. That is the opposite of what portage must deliver.


Why is it the opposite of what portage *must* deliver? All I'm asking is
that portage build *what it can*. In other words, I know EXACTLY what it
is going to deliver - its best effort!


Dude, calm down. Showing me that you are upset isn't going to change
jack shit.


Sorry - I'm not upset. I just think you are missing what I'm asking for.


And why does portage *have* to choose between all or nothing? All I'm
asking is that if it can't resolve everything, I want it to resolve
everything it can. Silicon is perfectly capable of making that decision.


because "everything it can" is not necessarily the same thing as
"everything it should" or "everything it was asked to do"

Portage has no idea at all why the depgraph failed to resolve fully at
the start. It knows about blockers that are in it's own ebuilds and can
deal with those; the way ebuilds are spec'ed a package manager can
cleave off an entire branch of the tree and build the remainder fully
confident that each part of what it then does build is identical to the
same parts if the blockers never hit the rest. It's deterministic and so
portage can continue.

And if we are understanding each other correctly, THIS is the point at 
which I would expect portage to give up and terminate. Except you seem 
to be saying it doesn't terminate here ...



For everything else, the input is not completely known therefore the
output cannot be completely known either and portage does the correct
thing and not try guess. This is a good thing.


You think it terminates here ...


If I say "emerge -u world" I have no idea what it's going to build, if I
say "emerge -u best-efforts", I have no idea what it's going to build,
where's the difference?

What I do know, is if I repeat "emerge -u best-efforts" several times, I
will end up (in all likelihood) with the same result as "emerge -u world".


No, you will not. In this case, what portage will give is not the sum of
it's individual parts as there is a real risk that some attributes of
the various parts are WRONG. Therefore the output can be WRONG. It
really is that simple.


When I run portage, it displays a list of what it is going to emerge. As 
I understand it, as each package is displayed of what it is going to 
emerge, that means it has successfully resolved the dependency graph. It 
also displays packages that are blocked. And then sometimes it just goes 
into a tizzy and says "too many blocks - giving up".


All I'm asking is that as it progresses, it makes a list of those 
packages it can resolve the dependencies for. If it then gives up with 
the current list it's processing, eg "world", it then goes back to the 
list it thinks it can process, and has another go with them.


Because that's exactly what I do, take the first few packages off the 
list that look fine, and emerge them. I then re-run the original emerge, 
rinse and repeat, but it takes absolutely ages, and worse I have to 
babysit the emerge because I'm *expecting* it to hit a problem.


You even said it yourself when you used the phrase "in all likelihood".
What about when it isn't? This is a package manager and package managers
have one singular objective that the code must always deliver: the
output must be entirely deterministic. Anything other than that and you
do not have a package manager anymore, now you have software that puts
stuff on a disk.

Portage is doing the right thing when it detects invalid input that it
cannot reliably  - it stops.


Why can't it just discard the invalid input, and try again with input 
that appears valid?


Note I didn't say *continue* - I said "try again". From the beginning.

I'm sorry, but the current behaviour is reminiscent of the way 
programmers (used to) code huge green-screen input forms - when you get 
to the bottom and hit "submit" - one error and it throws the whole lot 
away and makes you start again from scratch!


But feel free to disagree. If you can do this, the proof is in code and
patches. Got any?

What language? Python? Sorry, at the moment I don't speak Python - maybe 
I should.


And I hate to say it, but demanding code and patches is NOT good form. 
Yes, far too many people do it, but not everybody is a programmer (I am, 
but it's C and DataBasic). And do you REALLY want jack-of-all-trades 
giving you dodgy code? I contribute elsewhere. Fixing emerge is not 
really my thing, I'm just chucking out an idea I would find very useful 
(and I expect other people will too). I'm one of those odd people who 

Re: [gentoo-user] A portage nuisance

[Alan McKinnon]

On 28/10/2017 22:39, Anthony Youngman wrote:
> On 28/10/17 20:54, Alan McKinnon wrote:
>> Portage cannot do that, it is backed by silicon and has no concept of
>> meaning. So it has only one real choice - it can do it all or it does
>> not try.
>>
>> I'm not surprised Zac never tried implementing partial graph resolution
>> for the very simple reason that if you try do it, you have no idea what
>> is going to be built. That is the opposite of what portage must deliver.
> 
> Why is it the opposite of what portage *must* deliver? All I'm asking is
> that portage build *what it can*. In other words, I know EXACTLY what it
> is going to deliver - its best effort!

Dude, calm down. Showing me that you are upset isn't going to change
jack shit.

> 
> And why does portage *have* to choose between all or nothing? All I'm
> asking is that if it can't resolve everything, I want it to resolve
> everything it can. Silicon is perfectly capable of making that decision.

because "everything it can" is not necessarily the same thing as
"everything it should" or "everything it was asked to do"

Portage has no idea at all why the depgraph failed to resolve fully at
the start. It knows about blockers that are in it's own ebuilds and can
deal with those; the way ebuilds are spec'ed a package manager can
cleave off an entire branch of the tree and build the remainder fully
confident that each part of what it then does build is identical to the
same parts if the blockers never hit the rest. It's deterministic and so
portage can continue.

For everything else, the input is not completely known therefore the
output cannot be completely known either and portage does the correct
thing and not try guess. This is a good thing.

> 
> If I say "emerge -u world" I have no idea what it's going to build, if I
> say "emerge -u best-efforts", I have no idea what it's going to build,
> where's the difference?
> 
> What I do know, is if I repeat "emerge -u best-efforts" several times, I
> will end up (in all likelihood) with the same result as "emerge -u world".

No, you will not. In this case, what portage will give is not the sum of
it's individual parts as there is a real risk that some attributes of
the various parts are WRONG. Therefore the output can be WRONG. It
really is that simple.

You even said it yourself when you used the phrase "in all likelihood".
What about when it isn't? This is a package manager and package managers
have one singular objective that the code must always deliver: the
output must be entirely deterministic. Anything other than that and you
do not have a package manager anymore, now you have software that puts
stuff on a disk.

Portage is doing the right thing when it detects invalid input that it
cannot reliably  - it stops.

But feel free to disagree. If you can do this, the proof is in code and
patches. Got any?


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] A portage nuisance

[Anthony Youngman]

On 28/10/17 20:54, Alan McKinnon wrote:

Portage cannot do that, it is backed by silicon and has no concept of
meaning. So it has only one real choice - it can do it all or it does
not try.

I'm not surprised Zac never tried implementing partial graph resolution
for the very simple reason that if you try do it, you have no idea what
is going to be built. That is the opposite of what portage must deliver.


Why is it the opposite of what portage *must* deliver? All I'm asking is 
that portage build *what it can*. In other words, I know EXACTLY what it 
is going to deliver - its best effort!


And why does portage *have* to choose between all or nothing? All I'm 
asking is that if it can't resolve everything, I want it to resolve 
everything it can. Silicon is perfectly capable of making that decision.


If I say "emerge -u world" I have no idea what it's going to build, if I 
say "emerge -u best-efforts", I have no idea what it's going to build, 
where's the difference?


What I do know, is if I repeat "emerge -u best-efforts" several times, I 
will end up (in all likelihood) with the same result as "emerge -u world".


Cheers,
Wol

Re: [gentoo-user] bounces

[Alan McKinnon]

I'm sorry, but I'm going to be rude here. I have no goddamn idea what
the below paragraph means. It reads like my kids on a sugar high when
they were 10.




On 28/10/2017 21:54, mad.scientist.at.la...@tutanota.com wrote:
> sorry, didn't realize that message posted, with getting a bounce
> message.  resubscribing solved the problem, please disregard the post. 
> as far as headers, difficult to get with my current free provider and i
> can't see any reason headers would tell me why, suddenly, emails to list
> are bouncing though it might tell me where.  obviously the server flaked
> as i was still getting email from the list but couldn't post.  the
> system told me the bellow email bounced, and it didn't get sent to me
> like my post usually do, definitely a server/list problem.
> 
> mad.scientist.at.large (a good madscientist)
> -- 
> "The U.S. intelligence community concluded in a report made public in
> January that the Kremlin sought to disrupt the 2016 election and sway
> the race in Trump's favor."  From "thehill.com".  Only Trump and his
> duplicitous supports try to say it was Clinton who conspired.  Frankly
> Trump is likely guilty of treason, the sooner he's impeached and indited
> the better, along with ALL of his supporters in goverment.
> 
> 
> 28. Oct 2017 13:45 by alan.mckin...@gmail.com
> :
> 
> On 28/10/2017 21:08, mad.scientist.at.la...@tutanota.com
>  wrote:
> 
> why is my email to the list bouncing back at me??  I just
> tried twice.
> 
> mad.scientist.at.large (a good madscientist)
> 
> 
> 
> 
> Any special reason why you did not post the bounce message complete with
> all headers?
> 
> Because if answers are to be had, that is where they will be.
> 
> 
> -- 
> Alan McKinnon
> alan.mckin...@gmail.com 
> 


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] A portage nuisance

[Alan McKinnon]

On 28/10/2017 19:58, Wols Lists wrote:
> On 28/10/17 15:52, Andrew Savchenko wrote:
>> On Fri, 27 Oct 2017 14:58:13 +0100 Peter Humphrey wrote:
 On Fri, 27 Oct 2017 12:52:54 -
 Helmut Jarausch  wrote:

>> I have a problem with emerge for a long time.
>> Sometimes I need to (re-)emerge many packages like in an
>> emerge --emptytree @world
>>
>> Because I use several overlays, there are problems with a lot of
>> packages.
>> Unfortunately, emerge shows me just the first problem (like a missing
>> USE-flags) and then terminates.
>> Is there any means to let emerge go and report several (all) problems
>> which are independent of each other?

 EMERGE_DEFAULT_OPTS="--keep-going" ?
>> No, --keep-going allows to continue as long as possible after a
>> build failure. Helmut asks about dependecies resolution failures,
>> e.g. in some package REQUIRED_USE is not met, or circular
>> dependency occurs and so on.
> 
> What I would like - a bit like --keep-going - is some option that tries
> again.
> 
> When I do an "emerge -u" it sometimes blows up with this massive load of
> dependency failures. So what I end up doing is emerge a few packages
> that look like they're going to work, and then try my full update again.
> After several cycles through this, suddenly everything works.
> 
> So my spec for what I would like is basically, as each package
> successfully resolves its dependencies, add it to a "try again" list. If
> the current list blows up in dependency hell, restart the emerge with
> just the packages in the "try again" list.


That is completely contrary to how portage is supposed to work and
produces an unpredictable result.

*You* know what you want and can do it, *you* are a human with a brain
who understands meaning.

Portage cannot do that, it is backed by silicon and has no concept of
meaning. So it has only one real choice - it can do it all or it does
not try.

I'm not surprised Zac never tried implementing partial graph resolution
for the very simple reason that if you try do it, you have no idea what
is going to be built. That is the opposite of what portage must deliver.
-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] bounces

[mad.scientist.at.large]

sorry, didn't realize that message posted, with getting a bounce message.  
resubscribing solved the problem, please disregard the post.  as far as 
headers, difficult to get with my current free provider and i can't see any 
reason headers would tell me why, suddenly, emails to list are bouncing though 
it might tell me where.  obviously the server flaked as i was still getting 
email from the list but couldn't post.  the system told me the bellow email 
bounced, and it didn't get sent to me like my post usually do, definitely a 
server/list problem.

mad.scientist.at.large (a good madscientist)
--
"The U.S. intelligence community concluded in a report made public in January 
that the Kremlin sought to disrupt the 2016 election and sway the race in 
Trump's favor."  From "thehill.com".  Only Trump and his duplicitous supports 
try to say it was Clinton who conspired.  Frankly Trump is likely guilty of 
treason, the sooner he's impeached and indited the better, along with ALL of 
his supporters in goverment.


28. Oct 2017 13:45 by alan.mckin...@gmail.com:


> On 28/10/2017 21:08, > mad.scientist.at.la...@tutanota.com>  wrote:
>> why is my email to the list bouncing back at me??  I just tried twice.
>>
>> mad.scientist.at.large (a good madscientist)
>
>
>
> Any special reason why you did not post the bounce message complete with
> all headers?
>
> Because if answers are to be had, that is where they will be.
>
>
> -- 
> Alan McKinnon
> alan.mckin...@gmail.com

Re: [gentoo-user] bounces

[Alan McKinnon]

On 28/10/2017 21:08, mad.scientist.at.la...@tutanota.com wrote:
> why is my email to the list bouncing back at me??  I just tried twice.
> 
> mad.scientist.at.large (a good madscientist)



Any special reason why you did not post the bounce message complete with
all headers?

Because if answers are to be had, that is where they will be.


-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

[Nikos Chantziaras]

Alright, thanks. Looks like I'll have to live with that message for a 
while. Which isn't a big deal.



On 28/10/17 21:58, Canek Peláez Valdés wrote:
On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras > wrote:

 >
 > There is no such kernel option.

Yes, there is[1]. However, there is no such option for kernel version 
4.9[2], although there is for 4.10[3]. I think that's the problem, for 
using the firewall BPF options of systemd, you'll need to use kernel 
version >= 4.10.


Regards.

[1] https://github.com/torvalds/linux/blob/master/init/Kconfig#L848
[2] https://github.com/torvalds/linux/blob/v4.9/init/Kconfig
[3] https://github.com/torvalds/linux/blob/v4.10/init/Kconfig#L1157
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

[mad.scientist.at.large]

you should probably update your' kernel anyway, a lot of recent security fixes 
in the newer kernels.

mad.scientist.at.large (a good madscientist)
--
"The U.S. intelligence community concluded in a report made public in January 
that the Kremlin sought to disrupt the 2016 election and sway the race in 
Trump's favor."  From "thehill.com".  Only Trump and his duplicitous supports 
try to say it was Clinton who conspired.  Frankly Trump is likely guilty of 
treason, the sooner he's impeached and indited the better, along with ALL of 
his supporters in goverment.


28. Oct 2017 12:58 by can...@gmail.com:


> On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras <> rea...@gmail.com> > 
> wrote:
> >
> > There is no such kernel option.
>
> Yes, there is[1]. However, there is no such option for kernel version 4.9[2], 
> although there is for 4.10[3]. I think that's the problem, for using the 
> firewall BPF options of systemd, you'll need to use kernel version >= 4.10.
> Regards.
> [1] > https://github.com/torvalds/linux/blob/master/init/Kconfig#L848> [2] > 
> https://github.com/torvalds/linux/blob/v4.9/init/Kconfig> [3] > 
> https://github.com/torvalds/linux/blob/v4.10/init/Kconfig#L1157
> --
> Dr. Canek Peláez Valdés
> Profesor de Carrera Asociado C
> Departamento de Matemáticas
> Facultad de Ciencias
> Universidad Nacional Autónoma de México

[gentoo-user] bounces

[mad.scientist.at.large]

why is my email to the list bouncing back at me??  I just tried twice.

mad.scientist.at.large (a good madscientist)
--
"The U.S. intelligence community concluded in a report made public in January 
that the Kremlin sought to disrupt the 2016 election and sway the race in 
Trump's favor."  From "thehill.com".  Only Trump and his duplicitous supports 
try to say it was Clinton who conspired.  Frankly Trump is likely guilty of 
treason, the sooner he's impeached and indited the better, along with ALL of 
his supporters in goverment.

Re: [gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

[mad.scientist.at.large]

you should update the kernel anyway.  some serious security holes have recently 
been found and corrected in the newest kernel.

mad.scientist.at.large (a good madscientist)
--
"The U.S. intelligence community concluded in a report made public in January 
that the Kremlin sought to disrupt the 2016 election and sway the race in 
Trump's favor."  From "thehill.com".  Only Trump and his duplicitous supports 
try to say it was Clinton who conspired.  Frankly Trump is likely guilty of 
treason, the sooner he's impeached and indited the better, along with ALL of 
his supporters in goverment.


28. Oct 2017 12:58 by can...@gmail.com:


> On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras <> rea...@gmail.com> > 
> wrote:
> >
> > There is no such kernel option.
>
> Yes, there is[1]. However, there is no such option for kernel version 4.9[2], 
> although there is for 4.10[3]. I think that's the problem, for using the 
> firewall BPF options of systemd, you'll need to use kernel version >= 4.10.
> Regards.
> [1] > https://github.com/torvalds/linux/blob/master/init/Kconfig#L848> [2] > 
> https://github.com/torvalds/linux/blob/v4.9/init/Kconfig> [3] > 
> https://github.com/torvalds/linux/blob/v4.10/init/Kconfig#L1157
> --
> Dr. Canek Peláez Valdés
> Profesor de Carrera Asociado C
> Departamento de Matemáticas
> Facultad de Ciencias
> Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

[mad.scientist.at.large]

updating the kernel is a really good idea, recent kernels have corrected a 
number of serious security issues that are definitely  real and exploitable.

mad.scientist.at.large (a good madscientist)
--
"The U.S. intelligence community concluded in a report made public in January 
that the Kremlin sought to disrupt the 2016 election and sway the race in 
Trump's favor."  From "thehill.com".  Only Trump and his duplicitous supports 
try to say it was Clinton who conspired.  Frankly Trump is likely guilty of 
treason, the sooner he's impeached and indited the better, along with ALL of 
his supporters in goverment.


28. Oct 2017 12:58 by can...@gmail.com:


> On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras <> rea...@gmail.com> > 
> wrote:
> >
> > There is no such kernel option.
>
> Yes, there is[1]. However, there is no such option for kernel version 4.9[2], 
> although there is for 4.10[3]. I think that's the problem, for using the 
> firewall BPF options of systemd, you'll need to use kernel version >= 4.10.> 
> 
> --
> Dr. Canek Peláez Valdés
> Profesor de Carrera Asociado C
> Departamento de Matemáticas
> Facultad de Ciencias
> Universidad Nacional Autónoma de México

Re: [gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

[Canek Peláez Valdés]

On Sat, Oct 28, 2017 at 1:44 PM, Nikos Chantziaras  wrote:
>
> There is no such kernel option.

Yes, there is[1]. However, there is no such option for kernel version
4.9[2], although there is for 4.10[3]. I think that's the problem, for
using the firewall BPF options of systemd, you'll need to use kernel
version >= 4.10.

Regards.

[1] https://github.com/torvalds/linux/blob/master/init/Kconfig#L848
[2] https://github.com/torvalds/linux/blob/v4.9/init/Kconfig
[3] https://github.com/torvalds/linux/blob/v4.10/init/Kconfig#L1157
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-user] Plasmashell consuming huge amounts of memory.

[Dale]

Dale wrote:
> Just a little update, a recent update seems to have corrected this
> issue.  The update to 5.11.2 doesn't seem to have the same memory hog
> issue.  If anyone else is having this issue, upgrade to that version and
> hopefully it will work like it should.
>
> Thanks to all for their replies.
>
> Dale
>
> :-)  :-) 
>

Well, I spoke to soon.  It worked OK for a good while then it started
creeping up again.  After another round of google searches, startpage
actually, I found where someone posted that having a slideshow causes
this.  I switched from slideshow to something else and sure enough, it
hasn't hogged up memory, yet anyway. 

So, disable slideshow until this gets fixed and at least you don't have
to worry about it hogging up every last bit of memory. 

Still, that thing does use quite a bit of ram.  It's not in the area of
Firefox or anything but it uses a good bit.  Actually, in top it is
usually listed right below Firefox and Seamonkey.  In the past tho, it
just used the same stable amount.  ;-) 

Now let us pray that there is a fix soon enough.  I miss my slideshow.  :(

Dale

:-)  :-) 

[gentoo-user] Re: systemd: "local system does not support BPF/cgroup based firewalling"

[Nikos Chantziaras]

There is no such kernel option.


On 28/10/17 21:21, Canek Peláez Valdés wrote:

Do you have CONFIG_CGROUP_BPF enabled?

Regards.

On Sat, Oct 28, 2017 at 1:03 PM, Nikos Chantziaras > wrote:


I'm getting these at startup:

systemd[1]: File /lib/systemd/system/systemd-journald.service:33
configures an IP firewall (IPAddressDeny=any), but the local system
does not support BPF/cgroup based firewalling.
systemd[1]: Proceeding WITHOUT firewalling in effect!
systemd[1]: File /lib/systemd/system/systemd-udevd.service:32
configures an IP firewall (IPAddressDeny=any), but the local system
does not support BPF/cgroup based firewalling.
systemd[1]: Proceeding WITHOUT firewalling in effect!
systemd[1]: File /lib/systemd/system/systemd-logind.service:34
configures an IP firewall (IPAddressDeny=any), but the local system
does not support BPF/cgroup based firewalling.
systemd[1]: Proceeding WITHOUT firewalling in effect!

What do I need to make this work? I found this:

https://github.com/systemd/systemd/issues/7188


But CONFIG_BPF_SYSCALL is enabled and I still get that message.

This is on kernel 4.9.59 with systemd 235.

Re: [gentoo-user] Does Gentoo support more than 8 bits per color channel?

[wabe]

Helmut Jarausch  wrote:

> Hi,
> I'm considering buying a new monitor (and graphics card) which
> supports 10 bits per color channel.
> Will Gimp on a Linux machine (X11) support this now or in the near
> future. Or is it just waste of money to buy a monitor with more than
> 8 bits/color channel? Many thanks for some hints,
> Helmut

I have two identical machines. GPU is Radeon R7 250E and Monitor is
a Samsung U32D970. Monitor and GPU both supporting 10bpc. One machine 
is running Gentoo and the other Win7.

When I start Radeon Settings on the Win machine, it shows me that 
10bpc are used. All graphic software that I use on the win machine 
also supports 10bpc.

On the gentoo machine I use xf86-video-ati-7.10.0 and 
xorg-server-1.19.5. When I look at /var/log/Xorg.0.log I can see that
only 8bpc are used. 

At the time when I bought my monitor (nearly 3 years ago) I searched
the internet for information about Linux and 10bpc. All I found was 
that it is not supported by the xorg drivers. As I do no graphic work 
on gentoo this is not that important for me. So I never searched again.
Maybe it is supported now but I didn't read anything about that on the
xorg-announce mailing list so I don't think so.

Maybe other drivers (nvidia or proprietary amd) are supporting 10bpc.
But I never searched for that information.

Although the newest Gimp supports 16 and 32 bit images and also can 
use these color depths on internal rendering, I don't know if Gimp 
could support more than 8bpc color output if the display would be able 
to. 

--
Regards
wabe

Re: [gentoo-user] systemd: "local system does not support BPF/cgroup based firewalling"

[Canek Peláez Valdés]

Do you have CONFIG_CGROUP_BPF enabled?

Regards.

On Sat, Oct 28, 2017 at 1:03 PM, Nikos Chantziaras  wrote:

> I'm getting these at startup:
>
> systemd[1]: File /lib/systemd/system/systemd-journald.service:33
> configures an IP firewall (IPAddressDeny=any), but the local system does
> not support BPF/cgroup based firewalling.
> systemd[1]: Proceeding WITHOUT firewalling in effect!
> systemd[1]: File /lib/systemd/system/systemd-udevd.service:32 configures
> an IP firewall (IPAddressDeny=any), but the local system does not support
> BPF/cgroup based firewalling.
> systemd[1]: Proceeding WITHOUT firewalling in effect!
> systemd[1]: File /lib/systemd/system/systemd-logind.service:34 configures
> an IP firewall (IPAddressDeny=any), but the local system does not support
> BPF/cgroup based firewalling.
> systemd[1]: Proceeding WITHOUT firewalling in effect!
>
> What do I need to make this work? I found this:
>
>   https://github.com/systemd/systemd/issues/7188
>
> But CONFIG_BPF_SYSCALL is enabled and I still get that message.
>
> This is on kernel 4.9.59 with systemd 235.
>
>
>


-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

[gentoo-user] systemd: "local system does not support BPF/cgroup based firewalling"

[Nikos Chantziaras]

I'm getting these at startup:

systemd[1]: File /lib/systemd/system/systemd-journald.service:33 
configures an IP firewall (IPAddressDeny=any), but the local system does 
not support BPF/cgroup based firewalling.

systemd[1]: Proceeding WITHOUT firewalling in effect!
systemd[1]: File /lib/systemd/system/systemd-udevd.service:32 configures 
an IP firewall (IPAddressDeny=any), but the local system does not 
support BPF/cgroup based firewalling.

systemd[1]: Proceeding WITHOUT firewalling in effect!
systemd[1]: File /lib/systemd/system/systemd-logind.service:34 
configures an IP firewall (IPAddressDeny=any), but the local system does 
not support BPF/cgroup based firewalling.

systemd[1]: Proceeding WITHOUT firewalling in effect!

What do I need to make this work? I found this:

  https://github.com/systemd/systemd/issues/7188

But CONFIG_BPF_SYSCALL is enabled and I still get that message.

This is on kernel 4.9.59 with systemd 235.

Re: [gentoo-user] A portage nuisance

[Wols Lists]

On 28/10/17 15:52, Andrew Savchenko wrote:
> On Fri, 27 Oct 2017 14:58:13 +0100 Peter Humphrey wrote:
>> > On Fri, 27 Oct 2017 12:52:54 -
>> > Helmut Jarausch  wrote:
>> > 
>>> > > I have a problem with emerge for a long time.
>>> > > Sometimes I need to (re-)emerge many packages like in an
>>> > > emerge --emptytree @world
>>> > > 
>>> > > Because I use several overlays, there are problems with a lot of
>>> > > packages.
>>> > > Unfortunately, emerge shows me just the first problem (like a missing
>>> > > USE-flags) and then terminates.
>>> > > Is there any means to let emerge go and report several (all) problems
>>> > > which are independent of each other?
>> > 
>> > EMERGE_DEFAULT_OPTS="--keep-going" ?
> No, --keep-going allows to continue as long as possible after a
> build failure. Helmut asks about dependecies resolution failures,
> e.g. in some package REQUIRED_USE is not met, or circular
> dependency occurs and so on.

What I would like - a bit like --keep-going - is some option that tries
again.

When I do an "emerge -u" it sometimes blows up with this massive load of
dependency failures. So what I end up doing is emerge a few packages
that look like they're going to work, and then try my full update again.
After several cycles through this, suddenly everything works.

So my spec for what I would like is basically, as each package
successfully resolves its dependencies, add it to a "try again" list. If
the current list blows up in dependency hell, restart the emerge with
just the packages in the "try again" list.

When you haven't updated for a while and you've got a lot of packages,
this "emerge what you can" approach certainly seems to work for me, it
would just be nice if it was automated because it can take a lot of
attempts (and time) before the system finally succeeds in updating itself.

Cheers,
Wol

Re: [gentoo-user] Alternatives to knutclient

[Mick]

On Saturday, 28 October 2017 15:18:26 BST Daniel Frey wrote:
> On 10/28/2017 01:58 AM, Mick wrote:
> > Hi All,
> > 
> > I've been using the net-misc/knutclient GUI application to provide
> > information to desktop users of the state of the UPS.  Portage is telling
> > me this package depends on Qt4, it has received no development upstream
> > and is due to be ditched:
> > 
> > !!! The following installed packages are masked:
> > - net-misc/knutclient-1.0.5::gentoo (masked by: package.mask)
> > /usr/portage/profiles/package.mask:
> > # Andreas Sturmlechner  (21 Oct 2017)
> > # Dead upstream, depends on dead kdelibs4/Qt4.
> > # Masked for removal in 30 days. Bug #629018
> > 
> > Is there some other GUI front end for nut in portage I could use in its
> > place?
> Have you tried the one that comes with the nut package? There should be
> one installed with it. Although, I can't remember if it docks in the tray.
> 
> Dan

Thanks Dan,

>From what I see here there are number of GUI interfaces and NUT-Monitor
seems to be the application built in nut:

http://networkupstools.org/projects.html#_graphical_desktop_clients

However, I'm not sure it was built in my case:

$ find /usr/bin -iname *nut*
/usr/bin/binutils-config
/usr/bin/nut-scanner
/usr/bin/knutclient

This is how I built nut:

 Installed versions:  2.7.3(12:42:59 18/04/17)(ssl tcpd ups_drivers_al175 
ups_drivers_apcsmart ups_drivers_apcsmart-old ups_drivers_apcupsd-ups 
ups_drivers_bcmxcp ups_drivers_bcmxcp_usb ups_drivers_belkin 
ups_drivers_belkinunv ups_drivers_bestfcom ups_drivers_bestfortress 
ups_drivers_bestuferrups ups_drivers_bestups ups_drivers_blazer_ser 
ups_drivers_blazer_usb ups_drivers_clone ups_drivers_clone-outlet 
ups_drivers_dummy-ups ups_drivers_etapro ups_drivers_everups 
ups_drivers_gamatronic ups_drivers_genericups ups_drivers_isbmex 
ups_drivers_ivtscd ups_drivers_liebert ups_drivers_liebert-esp2 
ups_drivers_masterguard ups_drivers_metasys ups_drivers_mge-shut 
ups_drivers_mge-utalk ups_drivers_microdowell ups_drivers_nutdrv_qx 
ups_drivers_oldmge-shut ups_drivers_oneac ups_drivers_optiups 
ups_drivers_powercom ups_drivers_powerpanel ups_drivers_rhino 
ups_drivers_richcomm_usb ups_drivers_riello_ser ups_drivers_riello_usb 
ups_drivers_safenet ups_drivers_solis ups_drivers_tripplite 
ups_drivers_tripplite_usb ups_drivers_tripplitesu ups_drivers_upscode2 
ups_drivers_usbhid-ups ups_drivers_victronups usb xml -cgi -ipmi -selinux -
snmp -ups_drivers_netxml-ups -ups_drivers_nut-ipmipsu -ups_drivers_snmp-ups -
zeroconf)

What am I missing?
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Does Gentoo support more than 8 bits per color channel?

[Andrew Savchenko]

On Fri, 20 Oct 2017 16:17:37 - Helmut Jarausch wrote:
> Hi,
> I'm considering buying a new monitor (and graphics card) which supports
> 10 bits per color channel.
> Will Gimp on a Linux machine (X11) support this now or in the near future.
> Or is it just waste of money to buy a monitor with more than 8 bits/color 
> channel?
> Many thanks for some hints,
> Helmut

Linux and Gentoo in particular supports 10 and 12 bits per channel.

But in order for this to work you need to have support from all
chain, both hardware and software:

application -> de/wm or rendering stack (gtk/qt) -> xorg (supports)
-> video driver (see below) -> video card -> cable(! ) -> monitor

You have not told us what is your video card, but at least Intel[1]
and nVidia[2] products support 10/12 bits in Linux.

Definitely not all application support deep colour (10/12 bpc), but
most multimedia oriented do: gimp, ffmpeg, mplayer, mpv...

You may encounter some problems with GTK apps, though the proof
links I found[3,4] are quite old and situation may have improved.

Also take a note that 10 bpc imposes some limitations on the screen
resolution depending on your connectivity[5].

[1] https://communities.intel.com/thread/101627
[2] 
https://nvidia.custhelp.com/app/answers/detail/a_id/3050/~/how-to-enable-30-bit-color-on-linux
[3] http://www.oyranos.org/tag/30-bit/
[4] http://darktable-users.narkive.com/ndONjycG/anyone-with-30-bit-color-depth
[5] http://bilder.hifi-forum.de/medium/262100/hdmi-20-597x266_609346.jpg

Best regards,
Andrew Savchenko


pgpmanGDHoNsB.pgp
Description: PGP signature

Re: [gentoo-user] A portage nuisance

[Andrew Savchenko]

On Fri, 27 Oct 2017 14:58:13 +0100 Peter Humphrey wrote:
> On Fri, 27 Oct 2017 12:52:54 -
> Helmut Jarausch  wrote:
> 
> > I have a problem with emerge for a long time.
> > Sometimes I need to (re-)emerge many packages like in an
> > emerge --emptytree @world
> > 
> > Because I use several overlays, there are problems with a lot of
> > packages.
> > Unfortunately, emerge shows me just the first problem (like a missing
> > USE-flags) and then terminates.
> > Is there any means to let emerge go and report several (all) problems
> > which are independent of each other?
> 
> EMERGE_DEFAULT_OPTS="--keep-going" ?

No, --keep-going allows to continue as long as possible after a
build failure. Helmut asks about dependecies resolution failures,
e.g. in some package REQUIRED_USE is not met, or circular
dependency occurs and so on.

AFAIK there is no way to use keep-going like option for deps
resolution, because first error may trigger a lot of others and
there will be inevitably false errors, because the dependency tree
was not fully built.

Best regards,
Andrew Savchenko


pgp00OQ7zNaOM.pgp
Description: PGP signature

Re: [gentoo-user] Alternatives to knutclient

[Daniel Frey]

On 10/28/2017 01:58 AM, Mick wrote:

Hi All,

I've been using the net-misc/knutclient GUI application to provide information
to desktop users of the state of the UPS.  Portage is telling me this package
depends on Qt4, it has received no development upstream and is due to be
ditched:

!!! The following installed packages are masked:
- net-misc/knutclient-1.0.5::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Andreas Sturmlechner  (21 Oct 2017)
# Dead upstream, depends on dead kdelibs4/Qt4.
# Masked for removal in 30 days. Bug #629018

Is there some other GUI front end for nut in portage I could use in its place?



Have you tried the one that comes with the nut package? There should be 
one installed with it. Although, I can't remember if it docks in the tray.


Dan

[gentoo-user] Alternatives to knutclient

[Mick]

Hi All,

I've been using the net-misc/knutclient GUI application to provide information 
to desktop users of the state of the UPS.  Portage is telling me this package 
depends on Qt4, it has received no development upstream and is due to be 
ditched:

!!! The following installed packages are masked:
- net-misc/knutclient-1.0.5::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Andreas Sturmlechner  (21 Oct 2017)
# Dead upstream, depends on dead kdelibs4/Qt4.
# Masked for removal in 30 days. Bug #629018

Is there some other GUI front end for nut in portage I could use in its place?
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.