Re: [gentoo-user] eix settings for searching all layman overlays

2013-07-08 Thread Thanasis
on 07/07/2013 11:58 PM Neil Bothwick wrote the following:
> On Sun, 07 Jul 2013 19:52:31 +0300, Thanasis wrote:
> 
>> I would like to use eix and (updating it via cron job) be able to search
>> locally *all* layman overlays.
>> What commands and settings should I use?
> 
> LOCAL_LAYMAN=/path/to/layman/storage eix-remote -q update
> 
> 

I don't have a local overlay, and the default path for layman overlays
is /var/lib/layman/, so I guess I don't have to set the
LOCAL_LAYMAN variable, do I?

The problem is that after updating (by running the command eix-remote
update). I still don't get the results expected when doing a search, eg:

 # eix -l games-engines/spring
No matches found.

whereas it should list that there is a match in the sabayon (layman)
overlay (though not installed) like:

spring-88.0 ~amd64 ~x86

because, at least, the above is what I get by using the
http://gpo.zugaina.org/ search at
http://gpo.zugaina.org/games-engines/spring

So, I guess, I must be missing something in my eix configuration, don't
I? Besides, under /etc I only have /etc/eixrc/00-eixrc which is the
default (all lines in it are comments).



Re: [gentoo-user] eix settings for searching all layman overlays

2013-07-08 Thread Alan McKinnon
On 08/07/2013 09:56, Thanasis wrote:
> on 07/07/2013 11:58 PM Neil Bothwick wrote the following:
>> On Sun, 07 Jul 2013 19:52:31 +0300, Thanasis wrote:
>>
>>> I would like to use eix and (updating it via cron job) be able to search
>>> locally *all* layman overlays.
>>> What commands and settings should I use?
>>
>> LOCAL_LAYMAN=/path/to/layman/storage eix-remote -q update
>>
>>
> 
> I don't have a local overlay, and the default path for layman overlays
> is /var/lib/layman/, so I guess I don't have to set the
> LOCAL_LAYMAN variable, do I?
> 
> The problem is that after updating (by running the command eix-remote
> update). I still don't get the results expected when doing a search, eg:
> 
>  # eix -l games-engines/spring
> No matches found.
> 
> whereas it should list that there is a match in the sabayon (layman)
> overlay (though not installed) like:
> 
> spring-88.0 ~amd64 ~x86
> 
> because, at least, the above is what I get by using the
> http://gpo.zugaina.org/ search at
> http://gpo.zugaina.org/games-engines/spring
> 
> So, I guess, I must be missing something in my eix configuration, don't
> I? Besides, under /etc I only have /etc/eixrc/00-eixrc which is the
> default (all lines in it are comments).
> 


You  are trying to do something the software does not support.

eix will index your *installed* overlays, not all possible overlays that
could be out there. There is no way I know of to do that, and even if
there was a way, it would be a rather dumb idea.

That's what Google is for.



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




Re: [gentoo-user] eix settings for searching all layman overlays

2013-07-08 Thread Daniel Pielmeier
2013/7/7 Neil Bothwick :
> On Sun, 07 Jul 2013 19:52:31 +0300, Thanasis wrote:
>
>> I would like to use eix and (updating it via cron job) be able to search
>> locally *all* layman overlays.
>> What commands and settings should I use?
>
> LOCAL_LAYMAN=/path/to/layman/storage eix-remote -q update
>

A good explaination on how to use eix-remote can be found here [1] and
as usual in the man pages.

[1] http://klaig.blogspot.de/2013/04/how-to-search-super-quickly-in-all.html

-- 
Regards
Daniel



Re: [gentoo-user] eix settings for searching all layman overlays

2013-07-08 Thread Thanasis
on 07/08/2013 11:12 AM Daniel Pielmeier wrote the following:
> 2013/7/7 Neil Bothwick :
>> On Sun, 07 Jul 2013 19:52:31 +0300, Thanasis wrote:
>>
>>> I would like to use eix and (updating it via cron job) be able to search
>>> locally *all* layman overlays.
>>> What commands and settings should I use?
>>
>> LOCAL_LAYMAN=/path/to/layman/storage eix-remote -q update
>>
> 
> A good explaination on how to use eix-remote can be found here [1] and
> as usual in the man pages.
> 
> [1] http://klaig.blogspot.de/2013/04/how-to-search-super-quickly-in-all.html
> 

Following the above, I see that the way ti search for remote (not
locally installed overlays) is to use the -R option.
>From eix (app-portage/eix-0.28.5) man page:

-R, --remote
Uses the value of EIX_REMOTE1 as cache file name.  Use this option if
you want to see what eix-remote produced.  You  can  make this option
the default by setting REMOTE_DEFAULT=1.

So in /etc/eixrc/00-eixrc I have set
KEEP_VIRTUALS=true
REMOTE_DEFAULT=1

and now when doing a search I get results from all layman overlays
(either installed or not).

I am not sure whether the KEEP_VIRTUALS setting is needed though,
because the man page is *not* clear to me. Besides, in the bugs section
of the man page, it says:

The previous default KEEP_VIRTUALS=true used to confuse people. However,
with the new default, nobody will find out that this feature exists.  :(



Re: [gentoo-user] k3b burning BD-Disk pretends to fail at 99.99%

2013-07-08 Thread Alexander Puchmayr
On Sonntag, 7. Juli 2013, 17:19:30 Paul Hartman wrote:
> On Sat, Jul 6, 2013 at 11:33 AM, Alexander Puchmayr
> 
>  wrote:
> > I just burned all my pictures from my last vacation on a blueray-disk
> > using
> > k3b, and for no apparent reason it stoped at 99.8% and complained an error
> > (I/O error). I checked the logs (see attached file), but could not find a
> > hint. I compared each and every file on the disk with its original, but
> > yould not find any problem.
> 
> Maybe it is same as described in this bug:
> 
> https://bugs.kde.org/show_bug.cgi?id=255483
> 
> I don't use k3b but I know when I burn a 25GB disc image using
> growisofs, I have to disable the spare sectors otherwise it won't fit
> on the disc, and it burns all the way until the end where it fails,
> rather than "knowing" ahead of time that it won't fit.
> 

Don't think so, since the media I've burnt were 10G and 22G large.

Alex




Re: [gentoo-user] k3b burning BD-Disk pretends to fail at 99.99%

2013-07-08 Thread Joerg Schilling
Alexander Puchmayr  wrote:

> > I don't use k3b but I know when I burn a 25GB disc image using
> > growisofs, I have to disable the spare sectors otherwise it won't fit
> > on the disc, and it burns all the way until the end where it fails,
> > rather than "knowing" ahead of time that it won't fit.
> > 
>
> Don't think so, since the media I've burnt were 10G and 22G large.

What growisofs definitely causes with formatting the media is to make it slow.

Growisofs is not a cleanly writen application. It frequently returns slightly 
modified mode data to the drive that was fetched before from the drive. The way 
this new data is created is in conflict with the SCSI standard. Some drives 
still accept the data others do not. In some cases, sending back identical data
will even switch the drive into unwanted behavior. A quick statement could be:
It was written in C++ but looks like assembly code Note that there was no 
update since 5 years and several people reported less problems when using 
cdrecord instead of growisofs.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



[gentoo-user] Disable Screen Blanking

2013-07-08 Thread Norman Rieß
Hi,

i am trying to disable Screen Blanking but have been unsuccessful so far.

I used various methods:

* installed gnome-power-manager and disabled screen power saving
* setterm -blank 0
* echoing "setterm -blank 0" to the dev/ttyXs
* xset s off
* Kernel parameter in Grub consoleblank=0

A kernelsetting for this seem to have existed in older kernels, but
seems to have vanished in recent ones.

All methods have failed.

Does anyone know of a way to just keep the screen on?

Thanks,
Norman



Re: [gentoo-user] Disable Screen Blanking

2013-07-08 Thread Randolph Maaßen
2013/7/8 Norman Rieß 

> Hi,
>
> i am trying to disable Screen Blanking but have been unsuccessful so far.
>
> I used various methods:
>
> * installed gnome-power-manager and disabled screen power saving
> * setterm -blank 0
> * echoing "setterm -blank 0" to the dev/ttyXs
> * xset s off
> * Kernel parameter in Grub consoleblank=0
>
> A kernelsetting for this seem to have existed in older kernels, but
> seems to have vanished in recent ones.
>
> All methods have failed.
>
> Does anyone know of a way to just keep the screen on?
>
> Thanks,
> Norman
>
>
I have in my openbox autostart.sh "xset -dpms s off". this disables the
sceensaver (as you tried), but also turns Energy Star (DPMS) features off.
So no power management turns off the screen.

-- 
Mit freundlichen Grüßen / Best regards

Randolph Maaßen


Re: [gentoo-user] Linux viruses

2013-07-08 Thread Dale
Walter Dnes wrote:
> On Fri, Jul 05, 2013 at 05:21:25PM -0500, Dale wrote
>
>> Well, no Wine here.  So that won't happen.  Actually, I don't have a
>> copy of windoze here at all.  Neither of my two rigs have ever had
>> windoze installed on them at all. 
>>
>> BTW, I have been known to open those attachments before. I usually open
>> them with kwrite or something and try to see what is human readable in
>> there.  Most is machine language but there is usually a small portion
>> that is human readable.  They sent it and I'm nosy that way.  lol
>   The bad guys go after the "low hanging fruit", i.e. the easiest
> targets.  Years ago, it was Internet Explorer.  This also included
> Outlook and Outlook Express, which were glorified IE frontends.  There
> were many "drive-by-downloads", thanks to Active-X (aka "Active-Hacks").
>
>   MS has gotten its act together on IE, so the bad guys are now going
> after other stuff.  The "other stuff" is cross-platform stuff like Java
> and Javascript and Adobe Acrobat and Flash (known affectionately as
> "Schlockwave Trash").  So yes... it can happen here.
>
>   I've been Java-free for years.  I use Noscript and Flashblock on
> Firefox.  I keep Opera around for those sites that don't work on
> Firefox.  I also use mupdf instead of the bloated Acrobat Reader
> monstrosity.
>


Questions.  Can a virus infect the OS when running on Linux through
java/javascript/flash?  Or would the infection at the least be limited
to that user? 

How is html5 going to affect this?  Better or worse? 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how 
you interpreted my words!




[gentoo-user] Re: Linux viruses

2013-07-08 Thread Grant Edwards
On 2013-07-08, Dale  wrote:
> Walter Dnes wrote:
>
> Questions.  Can a virus infect the OS when running on Linux through
> java/javascript/flash?

Possibly.  It would require use of a privledge-escalation exploit
(which have been found in the past for Linux).

> Or would the infection at the least be limited to that user?

Usually.

-- 
Grant Edwards   grant.b.edwardsYow! Vote for ME -- I'm
  at   well-tapered, half-cocked,
  gmail.comill-conceived and
   TAX-DEFERRED!




Re: [gentoo-user] Linux viruses

2013-07-08 Thread Paul Hartman
On Mon, Jul 8, 2013 at 8:24 AM, Dale  wrote:
> Questions.  Can a virus infect the OS when running on Linux through
> java/javascript/flash?  Or would the infection at the least be limited
> to that user?

I think how they typically work, on any OS, is they exploit a bug in
the browser (or a browser plug-in) to run code on your local machine,
and then that code exploits the operating system in order to get
root-level privileges. After it has that, the possibilities are
endless...

There's nothing special about Linux that would make that scenario play
out any better than it does on Windows, but in reality the number of
exploits found for Windows has been greater, and the number of Linux
web browser users is far fewer, so it's pretty rare to see web pages
that target Linux exploits (but I do read about them from time to
time).

I personally use Firefox with RequestPolicy, NoScript and Adblock
Plus. That still won't protect me from a bug in Firefox itself. I
suppose if I really wanted to be paranoid I would run it in a virtual
machine (but, hey, those can be exploited, too). At some point, you
have to just go with it and hope for the best. Either that or turn off
the computer. :)

> How is html5 going to affect this?  Better or worse?

HTML5 is already here and you're probably already using it. :) The
biggest benefit to using "anything but Flash" is the idea that the
code is not in Adobe's hands and that the community would identify and
fix bugs sooner. But that's not guaranteed to be the case.

A web browser is perhaps the most complicated piece of software most
of us will ever run on our computers, and there's a lot of room for
mistakes to happen in those millions of lines of code. Anything can
happen.



Re: [gentoo-user] Linux viruses

2013-07-08 Thread Alan McKinnon
On 08/07/2013 15:24, Dale wrote:
> Walter Dnes wrote:
>> On Fri, Jul 05, 2013 at 05:21:25PM -0500, Dale wrote
>>
>>> Well, no Wine here.  So that won't happen.  Actually, I don't have a
>>> copy of windoze here at all.  Neither of my two rigs have ever had
>>> windoze installed on them at all. 
>>>
>>> BTW, I have been known to open those attachments before. I usually open
>>> them with kwrite or something and try to see what is human readable in
>>> there.  Most is machine language but there is usually a small portion
>>> that is human readable.  They sent it and I'm nosy that way.  lol
>>   The bad guys go after the "low hanging fruit", i.e. the easiest
>> targets.  Years ago, it was Internet Explorer.  This also included
>> Outlook and Outlook Express, which were glorified IE frontends.  There
>> were many "drive-by-downloads", thanks to Active-X (aka "Active-Hacks").
>>
>>   MS has gotten its act together on IE, so the bad guys are now going
>> after other stuff.  The "other stuff" is cross-platform stuff like Java
>> and Javascript and Adobe Acrobat and Flash (known affectionately as
>> "Schlockwave Trash").  So yes... it can happen here.
>>
>>   I've been Java-free for years.  I use Noscript and Flashblock on
>> Firefox.  I keep Opera around for those sites that don't work on
>> Firefox.  I also use mupdf instead of the bloated Acrobat Reader
>> monstrosity.
>>
> 
> 
> Questions.  Can a virus infect the OS when running on Linux through
> java/javascript/flash?  

Yes. If you can get the payload to run, then that code will run and will
do whatever the environment it is in will let it do.

> Or would the infection at the least be limited
> to that user? 

That's the normal case, but by no means the only one.

If you have sudoers set up to run any command as root without using a
password, well then

> 
> How is html5 going to affect this?  Better or worse? 


I think you need to gain a deeper understanding of how computer software
works Dale. You are asking black/white questions, and the world just is
not like that. It's all grey.

These questions do not have simple answers. Windows well-deserved it's
bad rep from many years ago - that came not from bad security or
loopholes but more from the simple fact that early Windows had no
security to speak of. It wasn't poor locks, there just wasn't a lock,
not a door ... oh stuff it there wasn't even a wall to put the door in
for many years!

Things have vastly improved now and Windows in the hands of someone with
clue rates about the same as (more-or-less conventional) Linux in the
hands of someone with clue.

Lastly, gaining root permissions is no longer the holy grail it used to
be. Nowadays first prize is ability to send mail through your mail
accounts, access your browsing history, and get into your password
wallet. All of which by their very nature, MUST be accessible to the
user's account.


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




Re: [gentoo-user] Disable Screen Blanking

2013-07-08 Thread Norman Rieß
Am 08.07.2013 14:43, schrieb Randolph Maaßen:
> 2013/7/8 Norman Rieß mailto:nor...@smash-net.org>>
> 
> Hi,
> 
> i am trying to disable Screen Blanking but have been unsuccessful so
> far.
> 
> I used various methods:
> 
> * installed gnome-power-manager and disabled screen power saving
> * setterm -blank 0
> * echoing "setterm -blank 0" to the dev/ttyXs
> * xset s off
> * Kernel parameter in Grub consoleblank=0
> 
> A kernelsetting for this seem to have existed in older kernels, but
> seems to have vanished in recent ones.
> 
> All methods have failed.
> 
> Does anyone know of a way to just keep the screen on?
> 
> Thanks,
> Norman
> 
> 
> I have in my openbox autostart.sh "xset -dpms s off". this disables the
> sceensaver (as you tried), but also turns Energy Star (DPMS) features off. 
> So no power management turns off the screen.
> 
> -- 
> Mit freundlichen Grüßen / Best regards
>  
> Randolph Maaßen
> 

Thank you! It works.

Regards,
Norman



Re: [gentoo-user] hp H222 SAS controller

2013-07-08 Thread Paul Hartman
On Thu, Jul 4, 2013 at 9:04 PM, Paul Hartman
 wrote:
> ST4000DM000

As a side-note these two Seagate 4TB "Desktop" edition drives I bought
already, after about than 100 hours of power-on usage, both drives
have each encountered dozens of unreadable sectors so far. I was able
to correct them (force reallocation) using hdparm... So it should be
"fixed", and I'm reading that this is "normal" with newer drives and
"don't worry about it", but I'm still coming from the time when 1 bad
sector = red alert, replace the drive ASAP.  I guess I will need to
monitor and see if it gets worse.



Re: [gentoo-user] hp H222 SAS controller

2013-07-08 Thread Alan McKinnon
On 08/07/2013 17:39, Paul Hartman wrote:
> On Thu, Jul 4, 2013 at 9:04 PM, Paul Hartman
>  wrote:
>> ST4000DM000
> 
> As a side-note these two Seagate 4TB "Desktop" edition drives I bought
> already, after about than 100 hours of power-on usage, both drives
> have each encountered dozens of unreadable sectors so far. I was able
> to correct them (force reallocation) using hdparm... So it should be
> "fixed", and I'm reading that this is "normal" with newer drives and
> "don't worry about it", but I'm still coming from the time when 1 bad
> sector = red alert, replace the drive ASAP.  I guess I will need to
> monitor and see if it gets worse.
> 


Way back when in the bad old days of drives measured in 100s of megs,
you'd get a few bad sectors now and then, and would have to mark them as
faulty. This didn't bother us then much

Nowadays we have drives that are 8,000 bigger than that so all other
things being equal we'd expect sectors to fail 8,000 time more (more
being a very fuzzy concept, and I know full well I'm using it loosely :-) )

Our drives nowadays also have smart firmware, something we had to
introduce when CHS no longer cut it, this lead to sector failures being
somewhat "invisible" leaving us with the happy delusion that drives were
vastly reliable etc etc etc. But you know all this.

A mere few dozen failures in the first 100 hours is a failure rate of
(Alan whips out the trust sci calculator) 4.8E-6%. Pretty damn
spectacular if you ask me and WELL within probabilities.

There is likely nothing wrong with your drives. If they are faulty, it's
highly likely a systemic manufacturing fault of the mechanicals (servo
systems, motor bearing etc)

You do realize that modern hard drives have for the longest time been up
there in the Top X list of Most Reliable Devices Made By Mankind Ever?



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




Re: [gentoo-user] hp H222 SAS controller

2013-07-08 Thread Stefan G. Weichinger
Am 08.07.2013 17:58, schrieb Alan McKinnon:
> On 08/07/2013 17:39, Paul Hartman wrote:
>> On Thu, Jul 4, 2013 at 9:04 PM, Paul Hartman
>>  wrote:
>>> ST4000DM000
>>
>> As a side-note these two Seagate 4TB "Desktop" edition drives I bought
>> already, after about than 100 hours of power-on usage, both drives
>> have each encountered dozens of unreadable sectors so far. I was able
>> to correct them (force reallocation) using hdparm... So it should be
>> "fixed", and I'm reading that this is "normal" with newer drives and
>> "don't worry about it", but I'm still coming from the time when 1 bad
>> sector = red alert, replace the drive ASAP.  I guess I will need to
>> monitor and see if it gets worse.
>>
> 
> 
> Way back when in the bad old days of drives measured in 100s of megs,
> you'd get a few bad sectors now and then, and would have to mark them as
> faulty. This didn't bother us then much
> 
> Nowadays we have drives that are 8,000 bigger than that so all other
> things being equal we'd expect sectors to fail 8,000 time more (more
> being a very fuzzy concept, and I know full well I'm using it loosely :-) )
> 
> Our drives nowadays also have smart firmware, something we had to
> introduce when CHS no longer cut it, this lead to sector failures being
> somewhat "invisible" leaving us with the happy delusion that drives were
> vastly reliable etc etc etc. But you know all this.
> 
> A mere few dozen failures in the first 100 hours is a failure rate of
> (Alan whips out the trust sci calculator) 4.8E-6%. Pretty damn
> spectacular if you ask me and WELL within probabilities.
> 
> There is likely nothing wrong with your drives. If they are faulty, it's
> highly likely a systemic manufacturing fault of the mechanicals (servo
> systems, motor bearing etc)
> 
> You do realize that modern hard drives have for the longest time been up
> there in the Top X list of Most Reliable Devices Made By Mankind Ever?

Does it make sense to apply some sort of burn-in-procedure before
actually formatting and using the disks? Running badblocks or something?

I ask because I wait for that shiny new server and doing so might not
hurt before installing gentoo. Or is that too paranoid and a waste of time?

Thanks, greets, Stefan




[gentoo-user] Re: eix settings for searching all layman overlays

2013-07-08 Thread Martin Vaeth
Thanasis  wrote:
>
> So in /etc/eixrc/00-eixrc I have set
> KEEP_VIRTUALS=true
> REMOTE_DEFAULT=1

With the current default setting of separate databases for the
local eix cache (normally /var/cache/eix/portage.eix) and
for the remote eix cache (/var/cache/eix/remote.eix),
KEEP_VIRTUALS=true makes no sense:

The purpose of KEEP_VIRTUALS=true was to update the local
cache data without changing the remote data with eix-update
(if both are in the same file).

However, especially if you set REMOTE_DEFAULT you should call
eix-remote add1
after every eix-sync so that your local eix cache is
copied into the remote eix cache
(see the manpage how to do this automatically with eix-sync).