Re: [gentoo-user] Helvetica fonts

2017-03-07 Thread thelma
On 03/07/2017 03:11 PM, David W Noon wrote:
> On Tue, 7 Mar 2017 14:20:54 -0700, Thelma (the...@sys-concept.com) wrote
> about "Re: [gentoo-user] Helvetica fonts" (in
> ):
> 
> [snip]
>> It seems to me the problem is the creator of the pdf document (on my
>> system): pdfTeX-1.40.16 or cairo 1.9.5
> 
> Cairo should not be part of the problem. It is a vector rendering
> library. The part of X.Org that renders text is Pango.
> 
>> Viewing these document via evnce, gv, gimp etc it show normal, nice
>> fonts; but when I open (same document) locally created via "flpsed" the
>> fonts are very rough.
>>
>> When I try to open any other PDF file via "flpsed", not created by me,
>> the fonts are nice looking.
> 
> Okay, I think we are getting somewhere now.
> 
> If evince shows the documents well, but flpsed does not, it would seem
> to me that the documents contain ambiguous font information. The other
> PDF viewers [evince, gv, etc.] seem able to resolve the ambiguity, but
> flpsed does not. This would indicate that the documents are not well formed.
> 
> Can you try another PDF builder, such as LibreOffice or OpenOffice?
> 
> If flpsed renders these PDF's well then your PDF builder is at fault. It
> is putting into the documents font specifications that do not match the
> installed fonts. The other PDF viewers possibly use a fuzzy matching
> algorithm that overcomes the ambiguity to select a suitable font.

Yes, I think this is the correct conclusion.
I created PDF file using OpenOffice:
Creator:OpenOffice 4.1.2
and flpsed displays the fonts very nice.

The two PFD documents that I created using both versions of Firefox:
www-client/firefox
www-client/firefox-bin

from pdfinfo:
Producer:   cairo 1.9.5 (using Firefox)
Producer:   pdfTeX-1.40.16 (using Firefox)

Both files are having problem viewing fonts using "flpsed".

--
Thelma









Re: [gentoo-user] Helvetica fonts

2017-03-07 Thread David W Noon
On Tue, 7 Mar 2017 14:20:54 -0700, Thelma (the...@sys-concept.com) wrote
about "Re: [gentoo-user] Helvetica fonts" (in
):

[snip]
> It seems to me the problem is the creator of the pdf document (on my
> system): pdfTeX-1.40.16 or cairo 1.9.5

Cairo should not be part of the problem. It is a vector rendering
library. The part of X.Org that renders text is Pango.

> Viewing these document via evnce, gv, gimp etc it show normal, nice
> fonts; but when I open (same document) locally created via "flpsed" the
> fonts are very rough.
> 
> When I try to open any other PDF file via "flpsed", not created by me,
> the fonts are nice looking.

Okay, I think we are getting somewhere now.

If evince shows the documents well, but flpsed does not, it would seem
to me that the documents contain ambiguous font information. The other
PDF viewers [evince, gv, etc.] seem able to resolve the ambiguity, but
flpsed does not. This would indicate that the documents are not well formed.

Can you try another PDF builder, such as LibreOffice or OpenOffice?

If flpsed renders these PDF's well then your PDF builder is at fault. It
is putting into the documents font specifications that do not match the
installed fonts. The other PDF viewers possibly use a fuzzy matching
algorithm that overcomes the ambiguity to select a suitable font.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 




[gentoo-user] Re: CIFS mounts started misbehaving

2017-03-07 Thread Grant Edwards
On 2017-03-07, Marc Joliet  wrote:
> On Dienstag, 7. M�rz 2017 15:19:33 CET Grant Edwards wrote:
>> No, as a rule I run stable gentoo-sources, and that's at 4.9.6-r1.
>
> Ah, of course.  I'm using ~arch kernels ATM.  (As a btrfs user I was tracking 
> the most recent upstream stable series, but want to switch to LTS kernels 
> now, 
> which happen to be the ones Gentoo stabilizes.  That is, unless a newer 
> kernel 
> has something that I really, *really* want.)

If I get bored, I may try latest 4.9, 4.10, 4.11 on my "test" machine
and see how it acts there.

I did some googling and didn't find anything that looked like this
problem being reported anywhere -- which makes me wonder what
particular combination of ancient windows server (IIRC, it's 2008) and
odd confguration is causing it.  I have a hard time believing that the
CIFS client in 4.9 kernels can be doing this for very many people...

-- 
Grant Edwards   grant.b.edwardsYow! Uh-oh!!  I forgot
  at   to submit to COMPULSORY
  gmail.comURINALYSIS!




Re: [gentoo-user] Re: CIFS mounts started misbehaving

2017-03-07 Thread Marc Joliet
On Dienstag, 7. März 2017 15:19:33 CET Grant Edwards wrote:
> No, as a rule I run stable gentoo-sources, and that's at 4.9.6-r1.

Ah, of course.  I'm using ~arch kernels ATM.  (As a btrfs user I was tracking 
the most recent upstream stable series, but want to switch to LTS kernels now, 
which happen to be the ones Gentoo stabilizes.  That is, unless a newer kernel 
has something that I really, *really* want.)

> However, I'm a bit confused about the table shown at
> 
>   https://packages.gentoo.org/packages/sys-kernel/gentoo-sources
> 
> There are two rows for some versions (e.g. 4.9.6-r1), with different
> indicators.  What does that mean?

AFAIK that's a (known?) bug.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


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


Re: [gentoo-user] Helvetica fonts

2017-03-07 Thread thelma
On 03/07/2017 01:47 PM, David W Noon wrote:
> On Tue, 7 Mar 2017 13:19:33 -0700, the...@sys-concept.com
> (the...@sys-concept.com) wrote about Re: [gentoo-user] Helvetica fonts:
> 
> [snip]
>> fc-list | egrep 'Helvetica' | sort
> 
> This last one should give you what you need:
> 
>> /usr/share/fonts/Helvetica/Helvetica.pfa:Helvetica:style=Regular
> 
>> The display far from samples fonts on wiki :-/

Sorry, was typing fast. I mean to say the display fonts via flpsed are
not what is shown on wiki pages.

> 
> I don't understand the above sentence.

It seems to me the problem is the creator of the pdf document (on my
system): pdfTeX-1.40.16 or cairo 1.9.5

Viewing these document via evnce, gv, gimp etc it show normal, nice
fonts; but when I open (same document) locally created via "flpsed" the
fonts are very rough.

When I try to open any other PDF file via "flpsed", not created by me,
the fonts are nice looking.

So, maybe I'm looking in a wrong place.

Here what is on my system:
qlist -C -I texlive

app-text/texlive
app-text/texlive-core
dev-texlive/texlive-basic
dev-texlive/texlive-fontsrecommended
dev-texlive/texlive-fontutils
dev-texlive/texlive-genericrecommended
dev-texlive/texlive-htmlxml
dev-texlive/texlive-langenglish
dev-texlive/texlive-latex
dev-texlive/texlive-latexrecommended
dev-texlive/texlive-metapost
dev-texlive/texlive-pictures
dev-texlive/texlive-texinfo

Maybe I'm missing something.

--
Thelma



Re: [gentoo-user] Helvetica fonts

2017-03-07 Thread David W Noon
On Tue, 7 Mar 2017 13:19:33 -0700, the...@sys-concept.com
(the...@sys-concept.com) wrote about Re: [gentoo-user] Helvetica fonts:

[snip]
> fc-list | egrep 'Helvetica' | sort

This last one should give you what you need:

> /usr/share/fonts/Helvetica/Helvetica.pfa:Helvetica:style=Regular

> The display far from samples fonts on wiki :-/

I don't understand the above sentence.

> I've run into one posting suggesting use of "-xfl" flag in fltk -
> package http://git.net/ml/lib.fltk.general/2004-08/msg00155.html

Was that post about flpsed?

> so I compiled  x11-libs/fltk without xfl but it did not make any
> difference.

The flag is named xft. It won't help unless flpsed is written in C++ and
uses the fltk toolkit.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


pgpoLylZlbsEk.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Emerge @system causing gcc downgrade

2017-03-07 Thread Dale
White, Phil wrote:
> On 7 March 2017 at 19:38, Neil Bothwick  > wrote:
>
>
> Please don't top post, it is disliked on this list.
>
>
> Sorry - a consequence of moving away from a proper mail client, and on
> to a web-based thing.
>  
>
> If you copied over /var/db/pkg you have a rather confused and
> messed up
> system. The safest way to recreate it is probably to move the pkg
> directory elsewhere and then run "emerge -e @world".
>
>
> Yep! I think that would be a polite way of putting it! ;)
>  
>
> gcc is slotted, so emerging 4.9.4 will not touch your 5.4.0
> installation,
> you use gcc-config to choose which one to use. What does gcc-config -l
> show?
>
>
> Just the one line:
> [1] i686-pc-linux-gnu-4.9.4
>
> I *think*, that with little time and patience, I can now sort this out.
> Thanks for the emerge -e hint. It doesn't seem to be in the emerge man
> page, though. What is the long-option name?
>
> Kind regards,
>
> Phil


Here ya go.

--emptytree (-e)
Reinstalls  target  atoms  and  their  entire  deep dependency tree, as
though no packages are currently installed. You should run this with
--pretend first to make sure the result is what you expect.
 

Dale

:-)  :-) 


Re: [gentoo-user] Helvetica fonts

2017-03-07 Thread thelma
On 03/07/2017 12:47 PM, David W Noon wrote:
> On Tue, 7 Mar 2017 11:49:44 -0700, Thelma (the...@sys-concept.com) wrote
> about "Re: [gentoo-user] Helvetica fonts" (in
> ):
> 
[snip]
> 
> Try the following, to see what fontconfig has cached:
> 
>  fc-list | egrep 'Helvetica' | sort | less

fc-list | egrep 'Helvetica' | sort
It shows them all:

/usr/share/fonts/100dpi/helvB08-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB08.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB10-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB10.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB12-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB12.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB14-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB14.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB18-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB18.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB24-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvB24.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/100dpi/helvBO08-ISO8859-1.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO08.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO10-ISO8859-1.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO10.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO12-ISO8859-1.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO12.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO14-ISO8859-1.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO14.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO18-ISO8859-1.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO18.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO24-ISO8859-1.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvBO24.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/100dpi/helvO08-ISO8859-1.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO08.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO10-ISO8859-1.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO10.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO12-ISO8859-1.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO12.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO14-ISO8859-1.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO14.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO18-ISO8859-1.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO18.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO24-ISO8859-1.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvO24.pcf.gz: Helvetica:style=Oblique
/usr/share/fonts/100dpi/helvR08-ISO8859-1.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR08.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR10-ISO8859-1.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR10.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR12-ISO8859-1.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR12.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR14-ISO8859-1.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR14.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR18-ISO8859-1.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR18.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR24-ISO8859-1.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/100dpi/helvR24.pcf.gz: Helvetica:style=Regular
/usr/share/fonts/75dpi/helvB08-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB08.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB10-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB10.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB12-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB12.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB14-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB14.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB18-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB18.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB24-ISO8859-1.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvB24.pcf.gz: Helvetica:style=Bold
/usr/share/fonts/75dpi/helvBO08-ISO8859-1.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/75dpi/helvBO08.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/75dpi/helvBO10-ISO8859-1.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/75dpi/helvBO10.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/75dpi/helvBO12-ISO8859-1.pcf.gz: Helvetica:style=Bold Oblique
/usr/share/fonts/75dpi/helvBO12.pcf.gz: Helvetica:style=Bold Oblique

Re: [gentoo-user] How to update a system if some packages can't be updated

2017-03-07 Thread Dale
Alan McKinnon wrote:
> On 07/03/2017 21:46, Dale wrote:
>> Helmut Jarausch wrote:
>>> Hi,
>>> I have packages which can't be updated at the moment, e.g.
>>> dev-python/numba doesn't work with llvm-4.0.0(_rc3)
>>> But this makes
>>>
>>> emerge -uvp --tree --unordered-display --verbose-conflicts --deep
>>> --with-bdeps=y @world
>>>
>>> fail. Is there any means to proceed except masking all those packages
>>> which can't be currently updated.
>>>
>>> Many thanks for a hint,
>>> Helmut
>>>
>> Would --keepgoing work?   Sometimes that doesn't work, depending on what
>> packages depend on something that needs to be updated first.  Also,
>> sometimes --skipfirst comes in handy. 
> Helmut's question looks like emerge fails to make a list of stuff to
> compile due to hard blocks. Not a compile failure.
>
> So --keep-going won't work
>


I read it as a package fails, numba, and emerge stops.  Either way,
sometimes that option doesn't help anyway.  Sometimes emerge has done
all it can and it needs a human fix to carry on. 

Dale

:-)  :-) 



Re: [gentoo-user] Emerge @system causing gcc downgrade

2017-03-07 Thread Alan McKinnon
On 07/03/2017 22:00, White, Phil wrote:
> On 7 March 2017 at 19:38, Neil Bothwick  > wrote:
> 
> 
> Please don't top post, it is disliked on this list.
> 
> 
> Sorry - a consequence of moving away from a proper mail client, and on
> to a web-based thing.
>  
> 
> If you copied over /var/db/pkg you have a rather confused and messed up
> system. The safest way to recreate it is probably to move the pkg
> directory elsewhere and then run "emerge -e @world".
> 
> 
> Yep! I think that would be a polite way of putting it! ;)
>  
> 
> gcc is slotted, so emerging 4.9.4 will not touch your 5.4.0
> installation,
> you use gcc-config to choose which one to use. What does gcc-config -l
> show?
> 
> 
> Just the one line:
> [1] i686-pc-linux-gnu-4.9.4
> 
> I *think*, that with little time and patience, I can now sort this out.
> Thanks for the emerge -e hint. It doesn't seem to be in the emerge man
> page, though. What is the long-option name?


I'm too lazy to look it up myself and long ago stopping trying to
remember minutia, but search the man page for "empty". That's where it
is :-)



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




Re: [gentoo-user] Emerge @system causing gcc downgrade

2017-03-07 Thread White, Phil
On 7 March 2017 at 19:38, Neil Bothwick  wrote:

>
> Please don't top post, it is disliked on this list.
>

Sorry - a consequence of moving away from a proper mail client, and on to a
web-based thing.


> If you copied over /var/db/pkg you have a rather confused and messed up
> system. The safest way to recreate it is probably to move the pkg
> directory elsewhere and then run "emerge -e @world".
>

Yep! I think that would be a polite way of putting it! ;)


> gcc is slotted, so emerging 4.9.4 will not touch your 5.4.0 installation,
> you use gcc-config to choose which one to use. What does gcc-config -l
> show?
>

Just the one line:
[1] i686-pc-linux-gnu-4.9.4

I *think*, that with little time and patience, I can now sort this out.
Thanks for the emerge -e hint. It doesn't seem to be in the emerge man
page, though. What is the long-option name?

Kind regards,

Phil


Re: [gentoo-user] How to update a system if some packages can't be updated

2017-03-07 Thread Alan McKinnon
On 07/03/2017 21:46, Dale wrote:
> Helmut Jarausch wrote:
>> Hi,
>> I have packages which can't be updated at the moment, e.g.
>> dev-python/numba doesn't work with llvm-4.0.0(_rc3)
>> But this makes
>>
>> emerge -uvp --tree --unordered-display --verbose-conflicts --deep
>> --with-bdeps=y @world
>>
>> fail. Is there any means to proceed except masking all those packages
>> which can't be currently updated.
>>
>> Many thanks for a hint,
>> Helmut
>>
> 
> Would --keepgoing work?   Sometimes that doesn't work, depending on what
> packages depend on something that needs to be updated first.  Also,
> sometimes --skipfirst comes in handy. 

Helmut's question looks like emerge fails to make a list of stuff to
compile due to hard blocks. Not a compile failure.

So --keep-going won't work

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




Re: [gentoo-user] Helvetica fonts

2017-03-07 Thread David W Noon
On Tue, 7 Mar 2017 11:49:44 -0700, Thelma (the...@sys-concept.com) wrote
about "Re: [gentoo-user] Helvetica fonts" (in
):

[snip]
>> I would start by deleting the *.ttf files in that directory (or move
>> them elsewhere) and refreshing the font cache again.
> 
> I removed them.
> I have bunch of font helvetica:
> find /usr/share/fonts/ -iname helv*
> /usr/share/fonts/75dpi/helvBO12-ISO8859-14.pcf.gz
> /usr/share/fonts/75dpi/helvB18-ISO8859-9.pcf.gz
> /usr/share/fonts/75dpi/helvR24-ISO8859-14.pcf.gz
> /usr/share/fonts/75dpi/helvBO10-ISO8859-4.pcf.gz
> /usr/share/fonts/75dpi/helvR08-ISO8859-3.pcf.gz
> /usr/share/fonts/75dpi/helvO14-ISO8859-3.pcf.gz
> /usr/share/fonts/75dpi/helvB24-ISO8859-4.pcf.gz
> /usr/share/fonts/75dpi/helvR14-ISO8859-9.pcf.gz
> /usr/share/fonts/75dpi/helvB12-ISO8859-9.pcf.gz
> /usr/share/fonts/75dpi/helvBO10-ISO8859-15.pcf.gz
> /usr/share/fonts/75dpi/helvB18-ISO8859-1.pcf.gz
> /usr/share/fonts/75dpi/helvR10-ISO8859-14.pcf.gz
> /usr/share/fonts/75dpi/helvR12-ISO8859-15.pcf.gz

Try the following, to see what fontconfig has cached:

 fc-list | egrep 'Helvetica' | sort | less

> So which group do they belong to?

The fonts above belong to the package media-fonts/fonts-adobe-75dpi.
These are fonts optimized for rendering on display devices that have a
pixel density of 75 dots per inch (dpi). A qlist for that package
indicates that they do not have a fontconfig .conf file. However,
fontconfig does cache them, since /usr/share/fonts is named in
/etc/fonts/fonts.conf.

> eselect fontconfig list
[snip]

The fonts configured by eselect are "exotic" fonts that are added to
fontconfig. They are of no importance here.

> I don't see anything starting with "helv"

You won't see any such entry.

> Maybe they are not enabled in my system?

Run the fc-list command, as I suggested above. That will show you every
font that purports to offer the Helvetica type face plus any other font
attributes.

Just to show you what to expect from Helvetica and Arial, here are a
couple of Wikipedia articles:

 
 

These articles contain sample text rendered in the respective fonts.
This will help you recognize Helvetica when you get it working.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] How to update a system if some packages can't be updated

2017-03-07 Thread Dale
Helmut Jarausch wrote:
> Hi,
> I have packages which can't be updated at the moment, e.g.
> dev-python/numba doesn't work with llvm-4.0.0(_rc3)
> But this makes
>
> emerge -uvp --tree --unordered-display --verbose-conflicts --deep
> --with-bdeps=y @world
>
> fail. Is there any means to proceed except masking all those packages
> which can't be currently updated.
>
> Many thanks for a hint,
> Helmut
>

Would --keepgoing work?   Sometimes that doesn't work, depending on what
packages depend on something that needs to be updated first.  Also,
sometimes --skipfirst comes in handy. 

Dale

:-)  :-)



Re: [gentoo-user] Emerge @system causing gcc downgrade

2017-03-07 Thread Neil Bothwick
On Tue, 7 Mar 2017 16:14:26 +, White, Phil wrote:

> Hi Neil,

Please don't top post, it is disliked on this list.

> 
> Well, this is a new install.
> Used Stage3-i686-20170214.tar.bz2
> There is nothing in package.accept_keywords that is currently installed
> (as far as I know - although it is possible that I might have added
> ~x86 to gcc, although in this instance I don't believe that i did)
> I have installed some packages, but removed them also (been having
> problems with perl)
> So currently, updating @world is the same as @system
> 
> OK - talking this through is helping. I *have* done something strange
> here. The currently installed version is 4.9.4 (from gcc --version),
> except that portage believes that 5.4.0 is installed.
> My guess is that, since I am trying to rebuild an old system (due to a
> hard-drive fail), I have accidentally copied over files that do not
> belong. My guess is a completely useless /var/db/pkg/* is confusing the
> hell out of portage/emerge.

If you copied over /var/db/pkg you have a rather confused and messed up
system. The safest way to recreate it is probably to move the pkg
directory elsewhere and then run "emerge -e @world".

> So - any suggestions how to fix this mess?
> Bite the bullet, emerge gcc, and then do a depclean - or can I convince
> portage that gcc 4.9.4 is really here?

gcc is slotted, so emerging 4.9.4 will not touch your 5.4.0 installation,
you use gcc-config to choose which one to use. What does gcc-config -l
show?


> 
> Thanks,
> Phil
> 
> On 7 March 2017 at 15:38, Neil Bothwick  wrote:
> 
> > On Tue, 7 Mar 2017 15:07:32 +, White, Phil wrote:
> >  
> > > I have a new install of Gentoo.
> > > emerge -uDpv --newuse @system results in a new slot for gcc,
> > > *downgrading* the current version (from 5.4.0 to 4.9.4)
> > > No other package is selected for merging.  
> >
> > 4.9.4 is the latest stable. Are you running a stable system with some
> > packages in package.accept_keywords? If so, and you gave a specific
> > version of gcc, it is possible that version is no longer in the tree -
> > 5.4.0-r2 was recently removed.
> >
> > Use the ~ operator when specifying versions to allow for minor updates
> >
> > ~sys-devel/gcc-5.4.0
> >
> > or, in the case of gcc, you can specify a slot
> >
> > sys-devel/gcc:5.4.0
> >
> >
> > --
> > Neil Bothwick
> >
> > Despite the cost of living it remains popular.
> >  




-- 
Neil Bothwick

This message has been cruelly tested on sweet little furry animals.


pgpKVLfG25qL8.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] How to update a system if some packages can't be updated

2017-03-07 Thread Neil Bothwick
On Tue, 07 Mar 2017 18:51:28 +0100, Helmut Jarausch wrote:

> I have packages which can't be updated at the moment, e.g.  
> dev-python/numba doesn't work with llvm-4.0.0(_rc3)
> But this makes
> 
> emerge -uvp --tree --unordered-display --verbose-conflicts --deep  
> --with-bdeps=y @world
> 
> fail.

Fail how?

> Is there any means to proceed except masking all those packages  
> which can't be currently updated.

masking packages is the usual way of dealing with this, it is even
recommended n the portage output.


-- 
Neil Bothwick

Am I ignorant or apathetic? I don't know and don't care!


pgp156mlKTmWs.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Helvetica fonts

2017-03-07 Thread thelma
On 03/06/2017 02:08 PM, Corbin Bird wrote:
> On 03/06/2017 01:27 PM, the...@sys-concept.com wrote:
>> Which package contain "Helvetica" font?
>>
>> I'm using "flpsed" and apparently it is using Helvetica font, which
>> "eselect fontconfig list" is not showing anything that resemble "helvet"
>> "eix helvet" is not showing anything either.
>>
>> The fonts in "flpsed" display are very rugged/pixelated, it is hard to
>> look at them.
>>
> 
> This font package works for Helvetica deps in Mozilla / Firefox && CUPS.
> 
> "media-fonts/liberation-fonts"
> 
> 
> Reference Link :
> https://packages.gentoo.org/packages/media-fonts/liberation-fonts
> 
> 
> Corbin


Yes, in the past "media-fonts/liberation-fonts"
Installed versions:  2.00.1-r1(10:28:40 PM 05/08/2015)(X -fontforge)

solved the problem, but it is not working this time.

--
Thelma



[gentoo-user] Duplicate rows in "Availble Version" tables at packages.gentoo.org

2017-03-07 Thread Grant Edwards
Are the "Available Version" tabels at packages.gentoo.org broken?

I've noticed that many of them have more that one row for a particular
version:

For example:

  https://packages.gentoo.org/packages/dev-lang/php

There are two rows for 7.0.15:7.0. One shows all green except for
ia64.  The other is all yellow except for amd64.  I don't remember
seeing this sort of thing in the past, but I won't swear that it's a
new thing either.

-- 
Grant Edwards   grant.b.edwardsYow! ... I don't like FRANK
  at   SINATRA or his CHILDREN.
  gmail.com




Re: [gentoo-user] Helvetica fonts

2017-03-07 Thread thelma



Thelma
On 03/07/2017 10:12 AM, David W Noon wrote:
> On Mon, 6 Mar 2017 16:41:06 -0700, Thelma (the...@sys-concept.com) wrote
> about "Re: [gentoo-user] Helvetica fonts" (in
> <860e60f9-c35e-24cb-0de7-0ecc3de8b...@sys-concept.com>):
> 
> [snip]
>> I've emerge htmldoc copied their fonts to /usr/share/fonts/Helvetica/
>> unmerged htmldoc
>> run: fc-cache -fv
>>
>> But the fonts in "flpsed" are still same looking (not impressive).
>>
>> I've the following fonts installed:
>> ll /usr/share/fonts/Helvetica/
>> -rw-r--r-- 1 root root 31741 Mar  6 16:24 Helvetica.afm
>> -rw-r--r-- 1 root root 31586 Mar  6 16:24 Helvetica-Bold.afm
>> -rw-r--r-- 1 root root 31896 Mar  6 16:24 Helvetica-BoldOblique.afm
>> -rw-r--r-- 1 root root 77039 Mar  6 16:24 Helvetica-BoldOblique.pfa
>> -rw-r--r-- 1 root root 70803 Mar  6 16:24 Helvetica-Bold.pfa
>> -rw-r--r-- 1 root root 39520 Mar  6 13:04 'Helvetica Neu Bold.ttf'
>> -rw-r--r-- 1 root root 39520 Mar  6 13:04 HelveticaNeueBd.ttf
>> -rw-r--r-- 1 root root 38016 Mar  6 13:04 'HelveticaNeue BlackCond.ttf'
>> -rw-r--r-- 1 root root 39568 Mar  6 13:04 HelveticaNeueHv.ttf
>> -rw-r--r-- 1 root root 43148 Mar  6 13:04 HelveticaNeueIt.ttf
>> -rw-r--r-- 1 root root 40104 Mar  6 13:04 'HelveticaNeue Light.ttf'
>> -rw-r--r-- 1 root root 40104 Mar  6 13:04 HelveticaNeueLt.ttf
>> -rw-r--r-- 1 root root 39656 Mar  6 13:04 'HelveticaNeue Medium.ttf'
>> -rw-r--r-- 1 root root 39656 Mar  6 13:04 HelveticaNeueMed.ttf
>> -rw-r--r-- 1 root root 40144 Mar  6 13:04 'HelveticaNeue Thin.ttf'
>> -rw-r--r-- 1 root root 41180 Mar  6 13:04 HelveticaNeue.ttf
>> -rw-r--r-- 1 root root 32044 Mar  6 13:56 helvetica-normal-58bdcca3a92e8.ttf
>> -rw-r--r-- 1 root root 32097 Mar  6 16:24 Helvetica-Oblique.afm
>> -rw-r--r-- 1 root root 75595 Mar  6 16:24 Helvetica-Oblique.pfa
>> -rw-r--r-- 1 root root 70952 Mar  6 16:24 Helvetica.pfa
>>
>> So I don't know what fonts it is looking for.
> 
> You have a bunch of TrueType fonts in that list. Helvetica is not a
> TrueType font, but an Adobe Postscript font. The nearest TrueType font
> to Helvetica is probably Arial. However, flpsed is definitely looking
> for Helvetica, not Arial.
> 
> I would start by deleting the *.ttf files in that directory (or move
> them elsewhere) and refreshing the font cache again.

I removed them.
I have bunch of font helvetica:
find /usr/share/fonts/ -iname helv*
/usr/share/fonts/75dpi/helvBO12-ISO8859-14.pcf.gz
/usr/share/fonts/75dpi/helvB18-ISO8859-9.pcf.gz
/usr/share/fonts/75dpi/helvR24-ISO8859-14.pcf.gz
/usr/share/fonts/75dpi/helvBO10-ISO8859-4.pcf.gz
/usr/share/fonts/75dpi/helvR08-ISO8859-3.pcf.gz
/usr/share/fonts/75dpi/helvO14-ISO8859-3.pcf.gz
/usr/share/fonts/75dpi/helvB24-ISO8859-4.pcf.gz
/usr/share/fonts/75dpi/helvR14-ISO8859-9.pcf.gz
/usr/share/fonts/75dpi/helvB12-ISO8859-9.pcf.gz
/usr/share/fonts/75dpi/helvBO10-ISO8859-15.pcf.gz
/usr/share/fonts/75dpi/helvB18-ISO8859-1.pcf.gz
/usr/share/fonts/75dpi/helvR10-ISO8859-14.pcf.gz
/usr/share/fonts/75dpi/helvR12-ISO8859-15.pcf.gz
...

So which group do they belong to?

eselect fontconfig list
Available fontconfig .conf files (* is enabled):
  [1]   10-autohint.conf
  [2]   10-no-sub-pixel.conf
  [3]   10-scale-bitmap-fonts.conf *
  [4]   10-sub-pixel-bgr.conf
  [5]   10-sub-pixel-rgb.conf
  [6]   10-sub-pixel-vbgr.conf
  [7]   10-sub-pixel-vrgb.conf
  [8]   10-unhinted.conf
  [9]   11-lcdfilter-default.conf
  [10]  11-lcdfilter-legacy.conf
  [11]  11-lcdfilter-light.conf
  [12]  20-unhint-small-dejavu-sans.conf
  [13]  20-unhint-small-dejavu-sans-mono.conf
  [14]  20-unhint-small-dejavu-serif.conf
  [15]  20-unhint-small-vera.conf *
  [16]  25-ttf-arphic-ukai-render.conf
  [17]  25-ttf-arphic-uming-bitmaps.conf
  [18]  25-ttf-arphic-uming-render.conf
  [19]  25-unhint-nonlatin.conf
  [20]  30-metric-aliases.conf *
  [21]  30-urw-aliases.conf *
  [22]  35-ttf-arphic-ukai-aliases.conf
  [23]  35-ttf-arphic-uming-aliases.conf
  [24]  40-nonlatin.conf *
  [25]  41-ttf-arphic-ukai.conf
  [26]  41-ttf-arphic-uming.conf
  [27]  42-luxi-mono.conf *
  [28]  45-latin.conf *
  [29]  49-sansserif.conf *
  [30]  50-user.conf *
  [31]  51-local.conf *
  [32]  57-dejavu-sans.conf
  [33]  57-dejavu-sans-mono.conf
  [34]  57-dejavu-serif.conf
  [35]  60-latin.conf *
  [36]  60-liberation.conf *
  [37]  64-ttf-arphic-uming.conf
  [38]  65-fonts-persian.conf *
  [39]  65-khmer.conf
  [40]  65-nonlatin.conf *
  [41]  69-unifont.conf *
  [42]  70-no-bitmaps.conf
  [43]  70-yes-bitmaps.conf
  [44]  75-ttf-arphic-ukai-select.conf
  [45]  75-yes-terminus.conf
  [46]  80-delicious.conf *
  [47]  90-synthetic.conf *
  [48]  90-ttf-arphic-ukai-embolden.conf
  [49]  90-ttf-arphic-uming-embolden.conf
  [50]  99pdftoopvp.conf

I don't see anything starting with "helv"
Maybe they are not enabled in my system?

--
Thelma






[gentoo-user] How to update a system if some packages can't be updated

2017-03-07 Thread Helmut Jarausch

Hi,
I have packages which can't be updated at the moment, e.g.  
dev-python/numba doesn't work with llvm-4.0.0(_rc3)

But this makes

emerge -uvp --tree --unordered-display --verbose-conflicts --deep  
--with-bdeps=y @world


fail. Is there any means to proceed except masking all those packages  
which can't be currently updated.


Many thanks for a hint,
Helmut


Re: [gentoo-user] Helvetica fonts

2017-03-07 Thread David W Noon
On Mon, 6 Mar 2017 16:41:06 -0700, Thelma (the...@sys-concept.com) wrote
about "Re: [gentoo-user] Helvetica fonts" (in
<860e60f9-c35e-24cb-0de7-0ecc3de8b...@sys-concept.com>):

[snip]
> I've emerge htmldoc copied their fonts to /usr/share/fonts/Helvetica/
> unmerged htmldoc
> run: fc-cache -fv
> 
> But the fonts in "flpsed" are still same looking (not impressive).
> 
> I've the following fonts installed:
> ll /usr/share/fonts/Helvetica/
> -rw-r--r-- 1 root root 31741 Mar  6 16:24 Helvetica.afm
> -rw-r--r-- 1 root root 31586 Mar  6 16:24 Helvetica-Bold.afm
> -rw-r--r-- 1 root root 31896 Mar  6 16:24 Helvetica-BoldOblique.afm
> -rw-r--r-- 1 root root 77039 Mar  6 16:24 Helvetica-BoldOblique.pfa
> -rw-r--r-- 1 root root 70803 Mar  6 16:24 Helvetica-Bold.pfa
> -rw-r--r-- 1 root root 39520 Mar  6 13:04 'Helvetica Neu Bold.ttf'
> -rw-r--r-- 1 root root 39520 Mar  6 13:04 HelveticaNeueBd.ttf
> -rw-r--r-- 1 root root 38016 Mar  6 13:04 'HelveticaNeue BlackCond.ttf'
> -rw-r--r-- 1 root root 39568 Mar  6 13:04 HelveticaNeueHv.ttf
> -rw-r--r-- 1 root root 43148 Mar  6 13:04 HelveticaNeueIt.ttf
> -rw-r--r-- 1 root root 40104 Mar  6 13:04 'HelveticaNeue Light.ttf'
> -rw-r--r-- 1 root root 40104 Mar  6 13:04 HelveticaNeueLt.ttf
> -rw-r--r-- 1 root root 39656 Mar  6 13:04 'HelveticaNeue Medium.ttf'
> -rw-r--r-- 1 root root 39656 Mar  6 13:04 HelveticaNeueMed.ttf
> -rw-r--r-- 1 root root 40144 Mar  6 13:04 'HelveticaNeue Thin.ttf'
> -rw-r--r-- 1 root root 41180 Mar  6 13:04 HelveticaNeue.ttf
> -rw-r--r-- 1 root root 32044 Mar  6 13:56 helvetica-normal-58bdcca3a92e8.ttf
> -rw-r--r-- 1 root root 32097 Mar  6 16:24 Helvetica-Oblique.afm
> -rw-r--r-- 1 root root 75595 Mar  6 16:24 Helvetica-Oblique.pfa
> -rw-r--r-- 1 root root 70952 Mar  6 16:24 Helvetica.pfa
> 
> So I don't know what fonts it is looking for.

You have a bunch of TrueType fonts in that list. Helvetica is not a
TrueType font, but an Adobe Postscript font. The nearest TrueType font
to Helvetica is probably Arial. However, flpsed is definitely looking
for Helvetica, not Arial.

I would start by deleting the *.ttf files in that directory (or move
them elsewhere) and refreshing the font cache again.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-user] Emerge @system causing gcc downgrade

2017-03-07 Thread White, Phil
Hi Neil,

Well, this is a new install.
Used Stage3-i686-20170214.tar.bz2
There is nothing in package.accept_keywords that is currently installed (as
far as I know - although it is possible that I might have added ~x86 to
gcc, although in this instance I don't believe that i did)
I have installed some packages, but removed them also (been having problems
with perl)
So currently, updating @world is the same as @system

OK - talking this through is helping. I *have* done something strange here.
The currently installed version is 4.9.4 (from gcc --version), except that
portage believes that 5.4.0 is installed.
My guess is that, since I am trying to rebuild an old system (due to a
hard-drive fail), I have accidentally copied over files that do not belong.
My guess is a completely useless /var/db/pkg/* is confusing the hell out of
portage/emerge.

So - any suggestions how to fix this mess?
Bite the bullet, emerge gcc, and then do a depclean - or can I convince
portage that gcc 4.9.4 is really here?

Thanks,
Phil

On 7 March 2017 at 15:38, Neil Bothwick  wrote:

> On Tue, 7 Mar 2017 15:07:32 +, White, Phil wrote:
>
> > I have a new install of Gentoo.
> > emerge -uDpv --newuse @system results in a new slot for gcc,
> > *downgrading* the current version (from 5.4.0 to 4.9.4)
> > No other package is selected for merging.
>
> 4.9.4 is the latest stable. Are you running a stable system with some
> packages in package.accept_keywords? If so, and you gave a specific
> version of gcc, it is possible that version is no longer in the tree -
> 5.4.0-r2 was recently removed.
>
> Use the ~ operator when specifying versions to allow for minor updates
>
> ~sys-devel/gcc-5.4.0
>
> or, in the case of gcc, you can specify a slot
>
> sys-devel/gcc:5.4.0
>
>
> --
> Neil Bothwick
>
> Despite the cost of living it remains popular.
>


Re: [gentoo-user] Emerge @system causing gcc downgrade

2017-03-07 Thread Neil Bothwick
On Tue, 7 Mar 2017 15:07:32 +, White, Phil wrote:

> I have a new install of Gentoo.
> emerge -uDpv --newuse @system results in a new slot for gcc,
> *downgrading* the current version (from 5.4.0 to 4.9.4)
> No other package is selected for merging.

4.9.4 is the latest stable. Are you running a stable system with some
packages in package.accept_keywords? If so, and you gave a specific
version of gcc, it is possible that version is no longer in the tree -
5.4.0-r2 was recently removed.

Use the ~ operator when specifying versions to allow for minor updates

~sys-devel/gcc-5.4.0

or, in the case of gcc, you can specify a slot

sys-devel/gcc:5.4.0


-- 
Neil Bothwick

Despite the cost of living it remains popular.


pgp1Mq7JmTTDY.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] Emerge @system causing gcc downgrade

2017-03-07 Thread White, Phil
Sorry Alan, that results in no extra information from emerge.
Still only gcc listed for installation - and nothing else.

--
Phil

On 7 March 2017 at 15:08, Alan McKinnon  wrote:

> On 07/03/2017 17:07, White, Phil wrote:
> > Hi,
> >
> > I'm sorry. This is probably a really simple question.
> > I have a new install of Gentoo.
> > emerge -uDpv --newuse @system results in a new slot for gcc,
> > *downgrading* the current version (from 5.4.0 to 4.9.4)
> > No other package is selected for merging.
> >
> > Why??? What command line can I give to show why a new slot is being
> > pulled in?
> > (I wouldn't particularly mind, but as I am on an old x86 celeron, this
> > will take hours to complete, for no obvious benefit...)
> >
> > Thanks
> > Phil
> >
>
>
>
> Add -t option to the command
>
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
>
>


Re: [gentoo-user] Emerge @system causing gcc downgrade

2017-03-07 Thread Alan McKinnon
On 07/03/2017 17:07, White, Phil wrote:
> Hi,
> 
> I'm sorry. This is probably a really simple question.
> I have a new install of Gentoo.
> emerge -uDpv --newuse @system results in a new slot for gcc,
> *downgrading* the current version (from 5.4.0 to 4.9.4)
> No other package is selected for merging.
> 
> Why??? What command line can I give to show why a new slot is being
> pulled in?
> (I wouldn't particularly mind, but as I am on an old x86 celeron, this
> will take hours to complete, for no obvious benefit...)
> 
> Thanks
> Phil
> 



Add -t option to the command


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




[gentoo-user] Emerge @system causing gcc downgrade

2017-03-07 Thread White, Phil
Hi,

I'm sorry. This is probably a really simple question.
I have a new install of Gentoo.
emerge -uDpv --newuse @system results in a new slot for gcc, *downgrading*
the current version (from 5.4.0 to 4.9.4)
No other package is selected for merging.

Why??? What command line can I give to show why a new slot is being pulled
in?
(I wouldn't particularly mind, but as I am on an old x86 celeron, this will
take hours to complete, for no obvious benefit...)

Thanks
Phil


[gentoo-user] Re: CIFS mounts started misbehaving

2017-03-07 Thread Grant Edwards
On 2017-03-07, Marc Joliet  wrote:

>> It's a kernel 4.9 problem.
>> 
>> I had built and installed a gentoo-sources 4.9.6-r1 kernel about a
>> month ago, but didn't update the grub configuration and reboot until
>> two weeks ago.
>> 
>> Rebooting with the 4.4.39 kernel fixes the problem.
[...]
>> I guess I'll have to stick with the 4.4 series until this gets fixed.
>
> I'm glad you found the source of the problem and a workaround.
> However, the 4.9 series is now at 4.9.13.  Have you tried that, too?

No, as a rule I run stable gentoo-sources, and that's at 4.9.6-r1.

However, I'm a bit confused about the table shown at

  https://packages.gentoo.org/packages/sys-kernel/gentoo-sources

There are two rows for some versions (e.g. 4.9.6-r1), with different
indicators.  What does that mean?

-- 
Grant Edwards   grant.b.edwardsYow! for ARTIFICIAL
  at   FLAVORING!!
  gmail.com




Re: [gentoo-user] rotating backup script

2017-03-07 Thread Rich Freeman
On Tue, Mar 7, 2017 at 12:04 AM,   wrote:
> I was looking at this rotating backup script
>
> source:
> https://community.spiceworks.com/topic/34970-how-to-create-rotating-backups-of-files
>

If you're looking for rotating backup solution based on rsync I'd take
a look at rsnapshot.  It is in the Gentoo repo, and it has been
completely dependable in my experience.

You get the same kind of storage you'd expect with plain rsync (just a
replica directory tree that you can freely read, cp from, etc).
However, it does stuff like ensure backups are complete before
rotating them in, handling the rotation itself, and also linking
incremental backups with hard-links to reduce storage.  It isn't quite
de-duplication but it gets you 90% of the benefit vs having a bunch of
complete backup directories that each take up the capacity of a full
backup.  Basically it copies the last backup using hard links, then
rsyncs over that.  The result is what looks like a bunch of full
backups but without all the space use.

If you're looking for something even more space-efficient that is
still based on rsync but which does not store its files as a simple
replica directory tree then look at duplicity, which is also in the
Gentoo repo.  It stores the data in compact archive files like most
other backup solutions, but it uses librsync to do most of the heavy
lifting.  If 1kb changes inside the middle of a 1TB file it only
stores the extra 1kb, just as rsync would only transfer the 1kb.  It
also has a bunch of backend options, including a few cloud services
like S3.  For remote backups it is pretty smart about how it stores
metadata vs data so that if the local cache gets out of sync it can
just re-fetch the metadata from the cloud without having to retrieve
the actual backup data, and it supports gpg.

I personally use both right now.  High-value files are saved using
duplicity to an S3 backend, fully gpg encrypted.  Since I like to mess
with zfs/btrfs I also keep a full replica of those drives locally on
ext4 using rsnapshot.  This is very easy to restore should btrfs eat
my data (and I've made use of it twice).

Rolling your own can certainly be an educational experience, but IMO
it is unnecessary.  Of course, be sure to test recovery no matter how
you end up setting everything up.

-- 
Rich



Re: [gentoo-user] rotating backup script

2017-03-07 Thread thelma
On 03/06/2017 11:35 PM, Jean-Christophe Bach wrote:
> Hello,
> 
>> I was looking at this rotating backup script
>>
>> source:
>> https://community.spiceworks.com/topic/34970-how-to-create-rotating-backups-of-files
>>
>> --backup script
>> BACKUPDIR=`date +%A`
>> OPTS="--force --ignore-errors --delete-excluded --exclude-from=$EXCLUDES 
>>   --delete --backup --backup-dir=/$BACKUPDIR -a"
>>
>> export PATH=$PATH:/bin:/usr/bin:/usr/local/bin
>>
>> # the following line clears the last weeks incremental directory
>> [ -d $HOME/emptydir ] || mkdir $HOME/emptydir
>> rsync --delete -a $HOME/emptydir/ $BSERVER::$USER/$BACKUPDIR/
>> rmdir $HOME/emptydir
>>
>> # now the actual transfer
>> rsync $OPTS $BDIR $BSERVER::$USER/current
>> ---end backup script
>>
>> Can anybody explain why they they "...clear the last weeks incremental 
>> directory"?
> 
> Probably because BACKUPDIR is set to the name of the day (`date +`A`).
> Today is Tuesday and a backup is done, next week the backup will be
> overwritten because BACKUPDIR will also be Tuesday. Therefore there will
> only be 7 directories.
> 
>> Doesn't "rsync --deleate" option take take care of this?
> 
> --delete removes extraneous files. Combined with the previous thing, it
> ensures the backup rotation.
> 
[snip]

Yes, the script clear states there will be 7-backups.
But I see no reason to remove/clear old backup from previous week since
"--delete" will remove all the file on destination that are not in source.

That is just a redundant step, I think.

--
Thelma



Re: [gentoo-user] Rear & Genkernel

2017-03-07 Thread Mick
On Tuesday 07 Mar 2017 12:25:50 Alan McKinnon wrote:
> On 07/03/2017 12:16, White, Phil wrote:
> > Hi Alan, Thanks for the reply.
> > 
> > First attempt at install was using emerge. This installs version 1.17.1.
> > This didn't work, so I removed it, and installed version 2.00 from Git,
> > in an attempt to fix the problem.
> > 
> > BOTH produce the same error - unable to find a kernel due to the naming
> > issue described previously.
> > So firstly I need to know whether Genkernel is incorrectly naming the
> > kernel, or whether Rear is looking for the wrong name.
> 
> genkernel is free to call a kernel image by any name it feels like
> calling it. It's just a file and the only thing the bootloader cares
> about is if it can find it.
> 
> Therefore rear is out of step, and rear needs to be patched

I also do not know how ReaR parses the path or name of the OS kernel.  If it 
were using your /usr/src/linux/arch/ tree then it would not mind 'x86' in the 
name of the kernel.  Either way, as a workaround you can try renaming the 
kernel image in boot and see if that works - don't forget to update GRUB's 
configuration after you do so.  If ReaR follows symlinks you could just create 
a symlink instead of renaming the kernel.

If you do not want to experiment, then you could ask on the ReaR chat channel 
and see what their devs suggest:

https://gitter.im/rear/rear

-- 
Regards,
Mick

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


Re: [gentoo-user] Rear & Genkernel

2017-03-07 Thread Alan McKinnon
On 07/03/2017 12:16, White, Phil wrote:
> Hi Alan, Thanks for the reply.
> 
> First attempt at install was using emerge. This installs version 1.17.1.
> This didn't work, so I removed it, and installed version 2.00 from Git,
> in an attempt to fix the problem.
> 
> BOTH produce the same error - unable to find a kernel due to the naming
> issue described previously.
> So firstly I need to know whether Genkernel is incorrectly naming the
> kernel, or whether Rear is looking for the wrong name.


genkernel is free to call a kernel image by any name it feels like
calling it. It's just a file and the only thing the bootloader cares
about is if it can find it.

Therefore rear is out of step, and rear needs to be patched



> 
> Cheers,
> Phil
> 
> On 6 March 2017 at 22:25, Alan McKinnon  > wrote:
> 
> On 06/03/2017 23:55, White, Phil wrote:
> > Hi,
> >
> > I'm not sure if this needs submitting as a bug, or if I just need a
> > little help in configuring...
> >
> > I have set up a new install of Gentoo. I use genkernel to create my
> > kernel and initrd.
> > The resulting /boot directory gives:
> >   kernel-genkernel-x86-4.9.6-gentoo-r1
> >
> > My chost is i686-pc-linux-gnu.
> >
> > Now, I also have installed rear (relax-and-recover) v2, from git
> > (app-backup/rear is 1.17.1)
> >
> > Problem: rear is looking for a kernel, and it expects it to be named:
> >   kernel-genkernel-i686-4.9.6-gentoo-r1
> > Since the name doesn't match, it bails out with an error. (This only
> > fails with my i686 machine. Running the same configuration on a 64-bit
> > machine works fine)
> >
> > Question: How am I going to fix this? I don't want to hard code anything
> > in the config file, as this will break when I update the kernel... Is
> > this a 'bug'?
> 
> 
> Please clarify what version of rear has this problem, and how you
> installed it.
> 
> Either way, from the problem description one can see that rear needs
> patching, however:
> 
> If it was installed by ortage from an ebuild, then you have a bug to be
> reported to b.g.o.
> 
> If you installed from git outside of portage, the you get to patch rear
> yourself
> 
> Or, perhaps a third option. Does rear have a config file where you can
> define the naming template for the kernel used? (I don't use rear and
> can't be bothered googling it, the idea just occurred to me)
> 
> 
> --
> Alan McKinnon
> alan.mckin...@gmail.com 
> 
> 
> 


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




Re: [gentoo-user] Rear & Genkernel

2017-03-07 Thread White, Phil
Hi Alan, Thanks for the reply.

First attempt at install was using emerge. This installs version 1.17.1.
This didn't work, so I removed it, and installed version 2.00 from Git, in
an attempt to fix the problem.

BOTH produce the same error - unable to find a kernel due to the naming
issue described previously.
So firstly I need to know whether Genkernel is incorrectly naming the
kernel, or whether Rear is looking for the wrong name.

Cheers,
Phil

On 6 March 2017 at 22:25, Alan McKinnon  wrote:

> On 06/03/2017 23:55, White, Phil wrote:
> > Hi,
> >
> > I'm not sure if this needs submitting as a bug, or if I just need a
> > little help in configuring...
> >
> > I have set up a new install of Gentoo. I use genkernel to create my
> > kernel and initrd.
> > The resulting /boot directory gives:
> >   kernel-genkernel-x86-4.9.6-gentoo-r1
> >
> > My chost is i686-pc-linux-gnu.
> >
> > Now, I also have installed rear (relax-and-recover) v2, from git
> > (app-backup/rear is 1.17.1)
> >
> > Problem: rear is looking for a kernel, and it expects it to be named:
> >   kernel-genkernel-i686-4.9.6-gentoo-r1
> > Since the name doesn't match, it bails out with an error. (This only
> > fails with my i686 machine. Running the same configuration on a 64-bit
> > machine works fine)
> >
> > Question: How am I going to fix this? I don't want to hard code anything
> > in the config file, as this will break when I update the kernel... Is
> > this a 'bug'?
>
>
> Please clarify what version of rear has this problem, and how you
> installed it.
>
> Either way, from the problem description one can see that rear needs
> patching, however:
>
> If it was installed by ortage from an ebuild, then you have a bug to be
> reported to b.g.o.
>
> If you installed from git outside of portage, the you get to patch rear
> yourself
>
> Or, perhaps a third option. Does rear have a config file where you can
> define the naming template for the kernel used? (I don't use rear and
> can't be bothered googling it, the idea just occurred to me)
>
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
>
>


[gentoo-user] Re: WARNING: Crucial MX300 drives SUUUUUCK!!!!

2017-03-07 Thread Kai Krakow
Am Mon, 6 Mar 2017 09:09:48 -0500
schrieb "Poison BL." :

> On Mon, Mar 6, 2017 at 2:23 AM, Kai Krakow 
> wrote:
> 
> > Am Tue, 14 Feb 2017 16:14:23 -0500
> > schrieb "Poison BL." :  
> > > I actually see both sides of it... as nice as it is to have a
> > > chance to recover the information from between the last backup
> > > and the death of the drive, the reduced chance of corrupt data
> > > from a silently failing (spinning) disk making it into backups is
> > > a bit of a good balancing point for me.  
> >
> > I've seen bordbackup giving me good protection to this. First, it
> > doesn't backup files which are already in the backup. So if data
> > silently changed, it won't make it into the backup. Second, it does
> > incremental backups. Even if something broke and made it into the
> > backup, you can eventually go back weeks or months to get back the
> > file. The algorithm is very efficient. And every incremental backup
> > is a full backup at the same time - so you thin out backup history
> > by deleting any backup at any time (so it's not like traditional
> > incremental backup which always needs the parent backup).
> >
> > OTOH, this means that every data block is only stored once. If
> > silent data corruption is hitting here, you loose the complete
> > history of this file (and maybe others using the same deduplicated
> > block).
> >
> > For the numbers, I'm storing my 1.7 TB system into a 3 TB disk
> > which is 2.2 TB full now. But the backup history is almost 1 year
> > now (daily backups).
> >
> > As a sort of protection against silent data corruption, you could
> > rsync borgbackup to a remote location. The differences are usually
> > small, so that should be a fast operation. Maybe to some cloud
> > storage or RAID protected NAS which can detect and correct silent
> > data corruption (like ZFS or btrfs based systems).
> >
> >
> > --
> > Regards,
> > Kai
> >
> > Replies to list-only preferred.
> >  
> 
> That's some impressive backup density... and I haven't looked into
> borgbackup, but it sounds like it runs on the same principles as the
> rsync+hardlink based scripts I've seen, though those will back up
> files that've silently changed, since the checksums won't match any
> more, but that won't blow away previous copies of the file either.
> I'll have to give it a try!

Borgbackup seems to check inodes to really fast get a listing of what
files changed. It only needs a few minutes to scan through millions of
files for me, rsync is way slower, and even "find" is slower I feel.
Taking a daily backup of takes usually 8-12 minutes for me (depending
on the delta), thinning the backup set from old backups takes another
1-2 minutes.

> As for protecting against the backup set itself getting silent
> corruption, an rsync to a remote location would help, but you would
> have to ensure it doesn't overwrite anything already there that
> may've changed, only create new.

Use timestamp check only in rsync, not contents check. This should work
for borgbackup as it is only creating newer files, never older.

> Also, making the initial clone would
> take ages, I suspect, since it would have to rebuild the hardlink set
> for everything (again, assuming that's the trick borgbackup's using).

No, that's not the trick. Stored files are stored as chunks. Chunks are
split based on a moving window checksumming algorithm to detect
duplicate file blocks. So, deduplication is not done at file level but
subfile level (block level with variable block sizes).

Additionally, those chunks can be compressed with lz4, gzip, and I
think xz (the latter being painfully slow of course).

> One of the best options is to house the base backup set itself on
> something like zfs or btrfs on a system with ecc ram, and maintain
> checksums of everything on the side (crc32 would likely suffice, but
> sha1's fast enough these days there's almost no excuse not to use
> it). It might be possible to task tripwire to keep tabs on that side
> of it, now that I consider it. While the filesystem itself in that
> case is trying its best to prevent issues, there's always that slim
> risk that there's a bug in the filesystem code itself that eats
> something, hence the added layer of paranoia. Also, with ZFS for the
> base data set,
> you gain in-place compression,

Is already done by borgbackup.

> dedup

Is also done by borgbackup.

> if you're feeling
> adventurous

You don't have to because you can use a more simple filesystem for
borgbackup. I'm storing on xfs and yet plan to sync to remote.

> (not really worth it unless you have multiple very
> similar backup sets for different systems), block level checksums,
> redundancy across physical disks, in place snapshots, and the ability
> to use zfs send/receive to do snapshot backups of the backup set
> itself.
> 
> I managed to corrupt some data with zfs (w/ dedup, on gentoo) shared
> out over nfs a while back on a box with way