Re: [gentoo-user] BTRFS problem? [WAS Quick check on net-print/hplip-3.14.10]

[Mick]

On Friday 18 Sep 2015 19:15:50 Rich Freeman wrote:
> On Fri, Sep 18, 2015 at 1:56 PM, Mick  wrote:
> > On Friday 18 Sep 2015 17:16:54 Marc Joliet wrote:
> >> On Friday 18 September 2015 10:31:01 Mick wrote:
> >> >A couple of months ago the akonadi DB went sideways and kmail played up
> >> >as a result.  Again I was suspicious of btrfs, but neither the logs
> >> >nor fsck showed up anything.
> >> 
> >> I take it "btrfs scrub" didn't turn up anything, or is that what you
> >> meant by fsck?
> > 
> > Am I supposed to run scrub with I do not have a RAID running?  I thought
> > scrub was meant for comparing checksums between mirrored fs - have I got
> > this wrong?
> 
> You can actually run scrub on a non-raid btrfs setup.  Btrfs will
> report any errors that it detects (using the checksumming in the
> filesystem), but it would not be able to fix errors unless you have it
> storing redundant data somewhere (even on non-raid it still stores
> redundant metadata by default, and you can choose to do this with data
> as well which protects against block-level failures but not disk-level
> failures, obviously).
> 
> However, you'd have gotten the same errors in dmesg just trying to
> read the files - btrfs checks the checksum on all file read
> operations.  That is a big part of the value of both btrfs and zfs.

Ah!  V interesting ... can I run scrub with mounted partitions, or do I have 
to do it from a LiveCD?

-- 
Regards,
Mick


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

Re: [gentoo-user] Distfiles cache setup

[Daniel Frey]

On 09/18/2015 01:15 PM, Neil Bothwick wrote:
> How tight is space? eclean-dist only removes distfiles for packages that
> are no longer in the tree. So you can run it on one system and keep
> $DISTDIR reasonably trimmed. If you use the --package-names option, it
> will do as you suggest and only keep files needed by the machine running
> the command.
> 

Thanks for the replies.

I regularly run eclean-dist on the mythtv frontends as I still have 32GB
SSDs on a couple of them. These are pretty lean as all file shares &
mythtv recordings are on the server that is running 24/7.

I figured eclean-dist would wipe out everything that wasn't needed by
the machine it was run on, but if all it does is clean stuff that isn't
in the tree any longer that would work too.

The server I'd be running it on has ample space. Which is why I was
debating over the http-replicator (thanks for the suggestion Peter!) and
just exporting the damn distfiles directory.

I think I'm going to try exporting it first and see if it does what I
want first, if it works I'll leave it. :-)

Dan

Re: [gentoo-user] npm: ERR! cb() never called!

[Alan McKinnon]

On 18/09/2015 00:48, Michael Orlitzky wrote:
> On 09/17/2015 05:13 PM, Alan McKinnon wrote:
>>
>> Slightly OT, but the general idea of package management isn't hard.
>>
>> Put the stuff you should have in a list, then compare what you should
>> have to what you do have. Go get and install what you don't have, then
>> make a record that you did it.
>>
>> Everything needed to get these basics right has been known for 40 years
>> or more - fellows like Wirth and Dijkstra figured it all out way back when.
>>
>> Sure, there's always modern stumbling blocks (like why we have subslots)
>> but that's extra to the essential basics.
>>
>> So why oh why do the latest generation of wunderkinds (not) always get
>> it so completely WRONG? 3 runs to fetch all the deps? I suppose wget and
>> curl don't actually do what I think they do then
>>
> 
> Heavy on bad words and light on solutions, but it made me feel better:
> 
> http://michael.orlitzky.com/articles/motherfuckers_need_package_management.php

I read it, and now I also feel much better :-)


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

Re: [gentoo-user] npm: ERR! cb() never called!

[Alan McKinnon]

On 18/09/2015 05:34, Alec Ten Harmsel wrote:
>>> This sucks, but it seems to be the way a lot of web stuff is deployed
>>> > > these days.
> All these dynamic languages suffer from the fun problem that developers
> that don't write enough tests have essentially no guarantee that their
> code actually parses. I can't count how many times I've run Ruby,
> Python, or Bash scripts only to have 'variable not found' or type
> errors; all of the things that compilers do really well[1].


I well remember flameeyes' bitching about packaging ruby gems. One
problem kept coming up over and over: tests would fail, usually because
the dev used some code buried deep in his own workstation, and that HAD
NEVER BEEN RELEASED. Braindeaddeaddead

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

[gentoo-user] Re: portage can not find local ebuild

[Nikos Chantziaras]

On 18/09/15 06:15, the...@sys-concept.com wrote:

I'm trying to emerge one of my local ebuild and portage can not find it.
What am I missing?

emerge -avq nxclient

emerge: there are no ebuilds to satisfy "nxclient".

My settings:

make.conf.
...
PORTDRI_OVERLAY="/usr/local/portage"

cat /etc/portage/repos.conf/gentoo.conf
[DEFAULT]
main-repo = gentoo

[gentoo]
location = /usr/portage
sync-type = rsync
sync-uri = rsync://192.168.139.7/gentoo-portage


Remove the PORTDIR_OVERLAY entry from make.conf. Then, create a new file 
in /etc/portage/repos.conf/, for example "local.conf", with these contents:


[Local]
priority = 
location = /usr/local/portage
auto-sync = no

The high value for priority is just to make sure that your local ebuilds 
override any other ebuilds of the same name that exist elsewhere.

Re: [gentoo-user] BTRFS problem? [WAS Quick check on net-print/hplip-3.14.10]

[Mick]

On Friday 18 Sep 2015 17:16:54 Marc Joliet wrote:
> On Friday 18 September 2015 10:31:01 Mick wrote:
> >A couple of months ago the akonadi DB went sideways and kmail played up as
> >a result.  Again I was suspicious of btrfs, but neither the logs nor fsck
> >showed up anything.
> 
> I take it "btrfs scrub" didn't turn up anything, or is that what you meant
> by fsck?

Am I supposed to run scrub with I do not have a RAID running?  I thought scrub 
was meant for comparing checksums between mirrored fs - have I got this wrong?


> >The OS is on a single SSD (no RAID), with some caches and busy fs mounted
> >on a  spinning disk.  I have some backups in case of DR, but after a
> >while a corrupted fs will have migrated to the back ups.
> 
> With btrfs, if there really was silent corruption, you wouldn't be able to
> access the file in the single disk case, so no, I don't think it actually
> would propagate to the backup (although perhaps you don't use btrfs
> exclusively, in which case it of course could).  Though keep in mind that
> corruption can happen in a variety of ways, e.g., application-level or
> firmware bugs.

-- 
Regards,
Mick


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

Re: [gentoo-user] BTRFS problem? [WAS Quick check on net-print/hplip-3.14.10]

[Rich Freeman]

On Fri, Sep 18, 2015 at 1:56 PM, Mick  wrote:
> On Friday 18 Sep 2015 17:16:54 Marc Joliet wrote:
>> On Friday 18 September 2015 10:31:01 Mick wrote:
>> >A couple of months ago the akonadi DB went sideways and kmail played up as
>> >a result.  Again I was suspicious of btrfs, but neither the logs nor fsck
>> >showed up anything.
>>
>> I take it "btrfs scrub" didn't turn up anything, or is that what you meant
>> by fsck?
>
> Am I supposed to run scrub with I do not have a RAID running?  I thought scrub
> was meant for comparing checksums between mirrored fs - have I got this wrong?
>

You can actually run scrub on a non-raid btrfs setup.  Btrfs will
report any errors that it detects (using the checksumming in the
filesystem), but it would not be able to fix errors unless you have it
storing redundant data somewhere (even on non-raid it still stores
redundant metadata by default, and you can choose to do this with data
as well which protects against block-level failures but not disk-level
failures, obviously).

However, you'd have gotten the same errors in dmesg just trying to
read the files - btrfs checks the checksum on all file read
operations.  That is a big part of the value of both btrfs and zfs.

-- 
Rich

Re: [gentoo-user] Distfiles cache setup

[Neil Bothwick]

On Fri, 18 Sep 2015 10:02:27 -0700, Daniel Frey wrote:

> 2. Export the distfiles directory.

That's what I do.
 
> This seems to be a bit better of a solution, other than not being able
> to use it outside the LAN.

ZeroTier can take care of that, or a VPN if you feel like doing the work
yourself.

> However, cleaning this directory becomes a
> lot less trivial as tools used to clean it will assume that the current
> machine is the only machine using it and clobber other workstation's
> required distfiles.

How tight is space? eclean-dist only removes distfiles for packages that
are no longer in the tree. So you can run it on one system and keep
$DISTDIR reasonably trimmed. If you use the --package-names option, it
will do as you suggest and only keep files needed by the machine running
the command.

> I suppose the easiest way to sync is to wipe it completely out and run
> `emerge -fe world` on all machines to rebuild it, but this would be a
> fair bit of work as well.

If you run this on each computer

emerge -epf --usepkg=n world | awk '/^[fh]t?tps?\:\/\// {print $1}' | sort -u | 
while read f; do
touch --no-create ${DISTDIR}/$(basename ${f})
done

It will touch each file needed by an installed package. Then you can
simply delete all files more than a day old (or longer if you want to keep
some fallback)

find $DISTDIR -type f -mtime +3- -exec rm "{}" +


-- 
Neil Bothwick

Everyone has a photographic memory. Some don't have film.


pgp3TQ9Jt2QJU.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] BTRFS problem? [WAS Quick check on net-print/hplip-3.14.10]

[Rich Freeman]

On Fri, Sep 18, 2015 at 2:19 PM, Mick  wrote:
> On Friday 18 Sep 2015 19:15:50 Rich Freeman wrote:
>> On Fri, Sep 18, 2015 at 1:56 PM, Mick  wrote:
>> > On Friday 18 Sep 2015 17:16:54 Marc Joliet wrote:
>> >> On Friday 18 September 2015 10:31:01 Mick wrote:
>> >> >A couple of months ago the akonadi DB went sideways and kmail played up
>> >> >as a result.  Again I was suspicious of btrfs, but neither the logs
>> >> >nor fsck showed up anything.
>> >>
>> >> I take it "btrfs scrub" didn't turn up anything, or is that what you
>> >> meant by fsck?
>> >
>> > Am I supposed to run scrub with I do not have a RAID running?  I thought
>> > scrub was meant for comparing checksums between mirrored fs - have I got
>> > this wrong?
>>
>> You can actually run scrub on a non-raid btrfs setup.  Btrfs will
>> report any errors that it detects (using the checksumming in the
>> filesystem), but it would not be able to fix errors unless you have it
>> storing redundant data somewhere (even on non-raid it still stores
>> redundant metadata by default, and you can choose to do this with data
>> as well which protects against block-level failures but not disk-level
>> failures, obviously).
>>
>> However, you'd have gotten the same errors in dmesg just trying to
>> read the files - btrfs checks the checksum on all file read
>> operations.  That is a big part of the value of both btrfs and zfs.
>
> Ah!  V interesting ... can I run scrub with mounted partitions, or do I have
> to do it from a LiveCD?

I didn't check, but I suspect you can only run scrub on a mounted
partition.  I also suspect that fsck probably has an option to do
something equivalent offline.

You do get the error-detection anyway just by reading files, and if
you just ran find on your filesystem and catted every file you have to
/dev/null that would actually accomplish the same thing as long as
you're not in a redundant mode (simply reading all the files doesn't
guarantee that all copies of each file are checked).

The main reason for doing a scrub is to detect latent issues, and if
you have redundancy that means you can auto-correct them today, rather
than discovering them a month from now when the drive containing the
only good copy fails.  Even if you don't have redundancy maybe you
rotate your backups every 30 days and detecting the error might mean
having the ability to go back and restore a good copy of the file
before it is completely replaced with bad copies.

-- 
Rich

[gentoo-user] Re: npm: ERR! cb() never called!

[James]

Michael Orlitzky  gentoo.org> writes:


> Heavy on bad words and light on solutions, but it made me feel better:

> http://michael.orlitzky.com/articles/motherfuckers_need_package_management.php


You know, when I read this I got quite a chuckle.  Then I started to 
'marinate' on this a while and stupid little things started to just
pop up in the back of my head. I've been trying to forget this post
ever since I read it; it has a bit too much truth to it, I suppose.
Then  a bombshell hit me on a very big FOSS project  (no do not ask the 
name) that I could not believe I was reading.


It seems they  have, somehow murky, all sorts of release tarballs with
proper identification, if you can find them with major.minor-revision
numbers, like we use in gentoo. But they pow_wow, pick the best one and then
release it with only major release numbers, although there are many, maybe
up to 5 or 6 tarballs floating around from the various work products
that should have the minor-rev info in the dam name. 


So just spank my ass and send me home from coding school. How the hell can
they do that, and maintain any resemblance to credibility? Deep in the
ticket system you can find the details. Seriously, it's a joke and now
there's some finger pointing amongst some big names in 'open source'
development. I guess they just want folks to download major-distro binaries
and bolt ons to the various distros. What ends up in the distro binary
downloads is even a further drift from the sources. Some serious smoke and
mirrors.

So, Micheal's profanity, although not optimal, is ceratinly warranted.
The more I hack and write code the more I'm realizing that either idiocy
or chicanery is a mainstay of some major FOSS projects and the big distros?
  Gut-wrencing experience, to say the least. I just can't believe folks this
smart that can code are such a bunch of fools Package manager?
These folks need a class in manners, ethics and common sense.   


Rant on, Michael, Rant on!


hth,
James

Re: [gentoo-user] Distfiles cache setup

[hydra]

On Fri, Sep 18, 2015 at 7:02 PM, Daniel Frey  wrote:

> Hi all,
>
> I have been running several Gentoo machines here at my house, and am
> currently up to 7 (or was it 8?) installs.
>
> I have been trying to reduce my resource consumption and set up an rsync
> mirror long ago, so my [acting] server only syncs to the internet and
> all other devices point to it. That part is working fine, I've already
> moved it to the repos.conf configuration.
>
> Whenever I search for running a local distfiles mirror (on this list and
> on the web) it gets a bit murky.
>
> The way I see it is this can be done a couple of ways:
>
> 1. Set up a lighttpd server to serve the distfiles directory.
>
> This has the benefit of being able to sync machines outside my network,
> although I don't know if I'd expose it to the internet.
>
> The major issue I can see with this is that if the file doesn't exist,
> portage will crap out saying it's not available. What I don't know is if
> there's an easy way to "get around" this issue.
>
> 
>
> 2. Export the distfiles directory.
>
> This seems to be a bit better of a solution, other than not being able
> to use it outside the LAN. However, cleaning this directory becomes a
> lot less trivial as tools used to clean it will assume that the current
> machine is the only machine using it and clobber other workstation's
> required distfiles.
>
> I suppose the easiest way to sync is to wipe it completely out and run
> `emerge -fe world` on all machines to rebuild it, but this would be a
> fair bit of work as well.
>
> 
>
> With those two options, neither being perfect - it made me wonder if
> there's a Better Way(tm) to do this.
>
> In the case of a shared distfiles, it would be best if something was one
> the machine hosting the distfiles monitoring what workstation needed
> what file and only removing a file when no workstations request it.
> Alas, I don't think a tool such as that exists (although I didn't really
> look that hard.)
>
> Ideally, it would be nice to have some sort of caching proxy that could
> fetch the file as it was needed, but in searching for this I encountered
> so much noise in the search results I gave up for the time being.
>
> Anyone have any suggestions?
>
> Dan
>
>
>
>

You can export distfiles via glusterfs. A single machine holds the data
while the others can fetch / upload files. Glusterfs needs to be installed
on each machine and fuse enabled in the kernel.

Re: [gentoo-user] BTRFS problem? [WAS Quick check on net-print/hplip-3.14.10]

[Mick]

On Friday 18 Sep 2015 19:30:49 Rich Freeman wrote:
> On Fri, Sep 18, 2015 at 2:19 PM, Mick  wrote:
> > On Friday 18 Sep 2015 19:15:50 Rich Freeman wrote:
> >> On Fri, Sep 18, 2015 at 1:56 PM, Mick  wrote:
> >> > On Friday 18 Sep 2015 17:16:54 Marc Joliet wrote:
> >> >> On Friday 18 September 2015 10:31:01 Mick wrote:
> >> >> >A couple of months ago the akonadi DB went sideways and kmail played
> >> >> >up as a result.  Again I was suspicious of btrfs, but neither the
> >> >> >logs nor fsck showed up anything.
> >> >> 
> >> >> I take it "btrfs scrub" didn't turn up anything, or is that what you
> >> >> meant by fsck?
> >> > 
> >> > Am I supposed to run scrub with I do not have a RAID running?  I
> >> > thought scrub was meant for comparing checksums between mirrored fs -
> >> > have I got this wrong?
> >> 
> >> You can actually run scrub on a non-raid btrfs setup.  Btrfs will
> >> report any errors that it detects (using the checksumming in the
> >> filesystem), but it would not be able to fix errors unless you have it
> >> storing redundant data somewhere (even on non-raid it still stores
> >> redundant metadata by default, and you can choose to do this with data
> >> as well which protects against block-level failures but not disk-level
> >> failures, obviously).
> >> 
> >> However, you'd have gotten the same errors in dmesg just trying to
> >> read the files - btrfs checks the checksum on all file read
> >> operations.  That is a big part of the value of both btrfs and zfs.
> > 
> > Ah!  V interesting ... can I run scrub with mounted partitions, or do I
> > have to do it from a LiveCD?
> 
> I didn't check, but I suspect you can only run scrub on a mounted
> partition.  I also suspect that fsck probably has an option to do
> something equivalent offline.
> 
> You do get the error-detection anyway just by reading files, and if
> you just ran find on your filesystem and catted every file you have to
> /dev/null that would actually accomplish the same thing as long as
> you're not in a redundant mode (simply reading all the files doesn't
> guarantee that all copies of each file are checked).
> 
> The main reason for doing a scrub is to detect latent issues, and if
> you have redundancy that means you can auto-correct them today, rather
> than discovering them a month from now when the drive containing the
> only good copy fails.  Even if you don't have redundancy maybe you
> rotate your backups every 30 days and detecting the error might mean
> having the ability to go back and restore a good copy of the file
> before it is completely replaced with bad copies.

Thank you Rich, I ran 'btrfs scrub start /" and it found zero problems.  dmesg 
and syslog clean too. 
-- 
Regards,
Mick


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

[gentoo-user] File-system mounting questions

[Walter Dnes]

  A while ago, I mentioned that I had problems running cdda2wav as a
regular user.  While rebuilding cdrtools recently, I noticed that the
build finished with the following warnings...

>>> Installing (1 of 1) app-cdr/cdrtools-3.01_alpha17::gentoo
 * >>> SetUID: [chmod go-r] /usr/sbin/rscsi ...  [ ok ]
 * >>> SetUID: [chmod go-r] /usr/bin/cdda2wav ...[ ok ]
 * >>> SetUID: [chmod go-r] /usr/bin/readcd ...  [ ok ]
 * >>> SetUID: [chmod go-r] /usr/bin/cdrecord ...[ ok ]
 * Could not set caps on '/usr/bin/cdrecord' due to missing filesystem support:
 * * enable XATTR support for 'ext2/ext3' in your kernel (if configurable)
 * * mount the fs with the user_xattr option (if not the default)
 * * enable the relevant FS_SECURITY option (if configurable)
 * Could not set caps on '/usr/bin/cdda2wav' due to missing filesystem support:
 * * enable XATTR support for 'ext2/ext3' in your kernel (if configurable)
 * * mount the fs with the user_xattr option (if not the default)
 * * enable the relevant FS_SECURITY option (if configurable)
 * Could not set caps on '/usr/bin/readcd' due to missing filesystem support:
 * * enable XATTR support for 'ext2/ext3' in your kernel (if configurable)
 * * mount the fs with the user_xattr option (if not the default)
 * * enable the relevant FS_SECURITY option (if configurable)
>>> Auto-cleaning packages...

  That might explain my problems.  So I modified my kernel as below...

<*> Second extended fs support
[*]   Ext2 extended attributes
[ ] Ext2 POSIX Access Control Lists
[ ] Ext2 Security Labels
<*> Ext3 journalling file system support
[*]   Default to 'data=ordered' in ext3
[*]   Ext3 extended attributes
[ ] Ext3 POSIX Access Control Lists
[ ] Ext3 Security Labels
< > The Extended 4 (ext4) filesystem

...rebuilt, and rebooted into it.  Still the same warnings on the build.
So now it appears that I have to...
> mount the fs with the user_xattr option (if not the default)
> enable the relevant FS_SECURITY option (if configurable)

  Can someone point me to an example somewhere of how to do it?  I
prefer not to muck around blindly with unknown options in /etc/fstab
BTW, I'm building cdrtools with USE="caps filecaps -acl -nls -unicode"
if that matters.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] File-system mounting questions

[Fernando Rodriguez]

On Friday, September 18, 2015 5:14:15 PM Walter Dnes wrote:
>   A while ago, I mentioned that I had problems running cdda2wav as a
> regular user.  While rebuilding cdrtools recently, I noticed that the
> build finished with the following warnings...
> 
> >>> Installing (1 of 1) app-cdr/cdrtools-3.01_alpha17::gentoo
>  * >>> SetUID: [chmod go-r] /usr/sbin/rscsi ...  [ ok 
> ]
>  * >>> SetUID: [chmod go-r] /usr/bin/cdda2wav ...[ ok 
> ]
>  * >>> SetUID: [chmod go-r] /usr/bin/readcd ...  [ ok 
> ]
>  * >>> SetUID: [chmod go-r] /usr/bin/cdrecord ...[ ok 
> ]
>  * Could not set caps on '/usr/bin/cdrecord' due to missing filesystem 
> support:
>  * * enable XATTR support for 'ext2/ext3' in your kernel (if configurable)
>  * * mount the fs with the user_xattr option (if not the default)
>  * * enable the relevant FS_SECURITY option (if configurable)
>  * Could not set caps on '/usr/bin/cdda2wav' due to missing filesystem 
> support:
>  * * enable XATTR support for 'ext2/ext3' in your kernel (if configurable)
>  * * mount the fs with the user_xattr option (if not the default)
>  * * enable the relevant FS_SECURITY option (if configurable)
>  * Could not set caps on '/usr/bin/readcd' due to missing filesystem support:
>  * * enable XATTR support for 'ext2/ext3' in your kernel (if configurable)
>  * * mount the fs with the user_xattr option (if not the default)
>  * * enable the relevant FS_SECURITY option (if configurable)
> >>> Auto-cleaning packages...
> 
>   That might explain my problems.  So I modified my kernel as below...
> 
> <*> Second extended fs support
> [*]   Ext2 extended attributes
> [ ] Ext2 POSIX Access Control Lists
> [ ] Ext2 Security Labels
> <*> Ext3 journalling file system support
> [*]   Default to 'data=ordered' in ext3
> [*]   Ext3 extended attributes
> [ ] Ext3 POSIX Access Control Lists
> [ ] Ext3 Security Labels

You'll also need this ^

> < > The Extended 4 (ext4) filesystem
> 
> ...rebuilt, and rebooted into it.  Still the same warnings on the build.
> So now it appears that I have to...
> > mount the fs with the user_xattr option (if not the default)
> > enable the relevant FS_SECURITY option (if configurable)
> 
>   Can someone point me to an example somewhere of how to do it?  I
> prefer not to muck around blindly with unknown options in /etc/fstab
> BTW, I'm building cdrtools with USE="caps filecaps -acl -nls -unicode"
> if that matters.

Just add the user_xattr unde  column. Like:

UUID=34868f06-d56b-4539-a649-33ec96b50d74   /   ext3
noatime,user_xattr  0 1 

-- 
Fernando Rodriguez

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

Re: [gentoo-user] npm: ERR! cb() never called!

[Neil Bothwick]

On Fri, 18 Sep 2015 08:57:55 +0200, Alan McKinnon wrote:

> > Heavy on bad words and light on solutions, but it made me feel better:
> > 
> > http://michael.orlitzky.com/articles/motherfuckers_need_package_management.php
> >   
> 
> I read it, and now I also feel much better :-)

+1

It's a shame that those it is aimed at will either never read it or read
it and think it doesn't apply to them :(


-- 
Neil Bothwick

Oxymoron: Reagan memoirs.


pgpgpuQHTEUJH.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Can't paste from selection in gtk-3 apps

[Grant Edwards]

On 2015-09-18, J. Roeleveld  wrote:

>>> echo $DISPLAY returns the same on both desktops.
>> 
>> That is a single X11 screen spread across two physical monitors.  It
>> will not exhibit the gtk-3 selection bug.
>> 
>> Are you sure you have two desktops and it's not just a single desktop
>> that is spread across two monitors?  Can you drag a window from one
>> monitor to the other?  If you can, then it's a single desktop.
>
> Yes, I can.
> When I maximize a window, it's only on 1 screen.
>
> This is how it seems "right" to me.

Then by all means continue to use it that way.  That's how most people
seem to like it.

> Why would I want it to be different?  Eg. windows can't be moved
> between screens? I don't see the point of having more than 1 screen
> in that case.

I like having separate screens because the window manager I use
(xfwm4) supports multiple virtual workspaces for each screen (4 per
screen by default).  I find it very useful to be able to flip one
screen to a different workspace while leaving the others unaffected.
That allows me, for example, to leave email and web-browser up on one
screen while switching the other two back and forth between multiple
tasks/projects. (I am rarely allowed to work uninterrupted for long
periods on a single task.)

Not being able to move windows between screens is an inconvenience,
but for me it's well worth it to get independently switchable virtual
workspaces on each screen.

-- 
Grant Edwards   grant.b.edwardsYow! Pardon me, but do you
  at   know what it means to be
  gmail.comTRULY ONE with your BOOTH!

Re: [gentoo-user] Re: Can't paste from selection in gtk-3 apps

[Alan McKinnon]

On 18/09/2015 16:11, J. Roeleveld wrote:
> On Friday 18 September 2015 13:23:49 Grant Edwards wrote:
>> On 2015-09-18, J. Roeleveld  wrote:
>>> On Thu, September 17, 2015 16:33, Grant Edwards wrote:
 On 2015-09-17, Grant Edwards  wrote:
> On 2015-09-17, J. Roeleveld  wrote:
 I use 2 screens extensively and never experienced any issues like you
 describe.
>>>
>>> And you can select/paste from one screen to another where the source
>>> is a gtk-3 app?
>>
>> Not sure, need to test with a gtk-3 app.
>>
>> I run KDE myself.
>>
>>> I should clarify that I mean "screen" in the strict X11 usage.  Using
>>> Xinerama or the like to spread a single desktop across multiple
>>> monitors is still a single screen setup.  I'm trying to select text
>>> on DISPLAY=:0.0 and paste it on DISPLAY=:0.1
>>
>> Not using my desktop atm.
>> What does Xorg do by default when it detects multiple screens?
>
> Not sure -- I'll have to give it a try. IIRC, it just uses the first
> one.

 At least on my machine, if I start up X11 without a configuration
 file it only uses one of my three monitors.  That behavior may depend
 on which boards are installed and which board/driver is found first.
>>>
>>> On my desktop:
>>>
>>> $ cat /etc/X11/xorg.conf
>>> Section "Device"
>>>
>>> Identifier  "Card0"
>>> Driver  "nvidia"
>>> BusID   "PCI:2:0:0"
>>>
>>> EndSection
>>>
>>> (Without this, X doesn't start, complaining it can't find VESA)
>>>
>>> echo $DISPLAY returns the same on both desktops.
>>
>> That is a single X11 screen spread across two physical monitors.  It
>> will not exhibit the gtk-3 selection bug.
>>
>> Are you sure you have two desktops and it's not just a single desktop
>> that is spread across two monitors?  Can you drag a window from one
>> monitor to the other?  If you can, then it's a single desktop.
> 
> Yes, I can.
> When I maximize a window, it's only on 1 screen.
> 
> This is how it seems "right" to me.
> 
> Why would I want it to be different? Eg. windows can't be moved between 
> screens? I don't see the point of having more than 1 screen in that case.

There's a few reasons you might want more than one screen. Primary one
is two heads and two video cards with different resolutions and dpi.
Xinerama and big desktop et al will use the lower setting for both.

Some folk have 2 screens just because they've always done it that way
for years and don't want to change

These days the usual case is one video card with more than one output so
you connect identical monitors to each. For that, one big desktop makes
sense.


> 
> --
> Joost
> 
> 


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

Re: [gentoo-user] Re: Can't paste from selection in gtk-3 apps

[J. Roeleveld]

On Friday 18 September 2015 16:22:00 Alan McKinnon wrote:
> On 18/09/2015 16:11, J. Roeleveld wrote:
> > On Friday 18 September 2015 13:23:49 Grant Edwards wrote:
> >> On 2015-09-18, J. Roeleveld  wrote:
> >>> On Thu, September 17, 2015 16:33, Grant Edwards wrote:
>  On 2015-09-17, Grant Edwards  wrote:
> > On 2015-09-17, J. Roeleveld  wrote:
>  I use 2 screens extensively and never experienced any issues like
>  you
>  describe.
> >>> 
> >>> And you can select/paste from one screen to another where the source
> >>> is a gtk-3 app?
> >> 
> >> Not sure, need to test with a gtk-3 app.
> >> 
> >> I run KDE myself.
> >> 
> >>> I should clarify that I mean "screen" in the strict X11 usage. 
> >>> Using
> >>> Xinerama or the like to spread a single desktop across multiple
> >>> monitors is still a single screen setup.  I'm trying to select text
> >>> on DISPLAY=:0.0 and paste it on DISPLAY=:0.1
> >> 
> >> Not using my desktop atm.
> >> What does Xorg do by default when it detects multiple screens?
> > 
> > Not sure -- I'll have to give it a try. IIRC, it just uses the first
> > one.
>  
>  At least on my machine, if I start up X11 without a configuration
>  file it only uses one of my three monitors.  That behavior may depend
>  on which boards are installed and which board/driver is found first.
> >>> 
> >>> On my desktop:
> >>> 
> >>> $ cat /etc/X11/xorg.conf
> >>> Section "Device"
> >>> 
> >>> Identifier  "Card0"
> >>> Driver  "nvidia"
> >>> BusID   "PCI:2:0:0"
> >>> 
> >>> EndSection
> >>> 
> >>> (Without this, X doesn't start, complaining it can't find VESA)
> >>> 
> >>> echo $DISPLAY returns the same on both desktops.
> >> 
> >> That is a single X11 screen spread across two physical monitors.  It
> >> will not exhibit the gtk-3 selection bug.
> >> 
> >> Are you sure you have two desktops and it's not just a single desktop
> >> that is spread across two monitors?  Can you drag a window from one
> >> monitor to the other?  If you can, then it's a single desktop.
> > 
> > Yes, I can.
> > When I maximize a window, it's only on 1 screen.
> > 
> > This is how it seems "right" to me.
> > 
> > Why would I want it to be different? Eg. windows can't be moved between
> > screens? I don't see the point of having more than 1 screen in that case.
> 
> There's a few reasons you might want more than one screen. Primary one
> is two heads and two video cards with different resolutions and dpi.
> Xinerama and big desktop et al will use the lower setting for both.

Actually, this desktop has xinerama enabled in USE-flags. IOW, I'm assuming I 
am using Xinerama on here.
I can change the resolution of either screen and it all still works. (apart 
from the weird look of windows on the other screen)

> Some folk have 2 screens just because they've always done it that way
> for years and don't want to change
> 
> These days the usual case is one video card with more than one output so
> you connect identical monitors to each. For that, one big desktop makes
> sense.

Same with laptops, all laptops I've used in the past 5 years all had the 
option to add a 2nd display and use that. Even with differing resolutions, it 
works the same way.
Plug it in, change the setting if necessary (kdesettings does a good job with 
that) and I have 2 screens where i can move windows back and forth.
It's great for presentations. Can open a text-file with the passwords on the 
laptop screen and copy/paste them from there onto the big screen everyone else 
sees.

--
Joost

[gentoo-user] Re: Can't paste from selection in gtk-3 apps

[Grant Edwards]

On 2015-09-18, J. Roeleveld  wrote:
>
>> There's a few reasons you might want more than one screen. Primary one
>> is two heads and two video cards with different resolutions and dpi.
>> Xinerama and big desktop et al will use the lower setting for both.
>
> Actually, this desktop has xinerama enabled in USE-flags. IOW, I'm
> assuming I am using Xinerama on here. I can change the resolution of
> either screen and it all still works. (apart from the weird look of
> windows on the other screen)

But can you set DPI independenty for the two monitors?  I'm guessing
not, since you mention the "weird look of windows" -- that's probably
due to use of the wrong DPI on one of the monitors.  With multiple
screens, you _can_ set DPI correctly for two different monitors.

>> Some folk have 2 screens just because they've always done it that way
>> for years and don't want to change
>> 
>> These days the usual case is one video card with more than one output
>> so you connect identical monitors to each. For that, one big desktop
>> makes sense.
>
> Same with laptops, all laptops I've used in the past 5 years all had
> the option to add a 2nd display and use that. Even with differing
> resolutions, it works the same way. Plug it in, change the setting if
> necessary (kdesettings does a good job with that) and I have 2
> screens where i can move windows back and forth. It's great for
> presentations. Can open a text-file with the passwords on the laptop
> screen and copy/paste them from there onto the big screen everyone
> else sees.

Except for the "moving windows back and forth" it works the same with
dual screens except you can properly set DPI for both of them.

There is one other disadvantage of having multiple screens that I
forgot to mention.  Apart from the gtk-3 selection brokenness, there
are some buggy X apps which just plain refuse to run on multiple
screens simultaneously (Firefix is one).  They were apparently written
by MS-Windows programmers based on the assumption that a computer is
always used by exactly one person to run exactly one program on
exactly on screen.  Most other X apps are properly written and support
multiple screens just fine.

-- 
Grant Edwards   grant.b.edwardsYow! Spreading peanut
  at   butter reminds me of
  gmail.comopera!!  I wonder why?

Re: [gentoo-user] Re: Can't paste from selection in gtk-3 apps

[J. Roeleveld]

On Friday 18 September 2015 13:23:49 Grant Edwards wrote:
> On 2015-09-18, J. Roeleveld  wrote:
> > On Thu, September 17, 2015 16:33, Grant Edwards wrote:
> >> On 2015-09-17, Grant Edwards  wrote:
> >>> On 2015-09-17, J. Roeleveld  wrote:
> >> I use 2 screens extensively and never experienced any issues like you
> >> describe.
> > 
> > And you can select/paste from one screen to another where the source
> > is a gtk-3 app?
>  
>  Not sure, need to test with a gtk-3 app.
>  
>  I run KDE myself.
>  
> > I should clarify that I mean "screen" in the strict X11 usage.  Using
> > Xinerama or the like to spread a single desktop across multiple
> > monitors is still a single screen setup.  I'm trying to select text
> > on DISPLAY=:0.0 and paste it on DISPLAY=:0.1
>  
>  Not using my desktop atm.
>  What does Xorg do by default when it detects multiple screens?
> >>> 
> >>> Not sure -- I'll have to give it a try. IIRC, it just uses the first
> >>> one.
> >> 
> >> At least on my machine, if I start up X11 without a configuration
> >> file it only uses one of my three monitors.  That behavior may depend
> >> on which boards are installed and which board/driver is found first.
> > 
> > On my desktop:
> > 
> > $ cat /etc/X11/xorg.conf
> > Section "Device"
> > 
> > Identifier  "Card0"
> > Driver  "nvidia"
> > BusID   "PCI:2:0:0"
> > 
> > EndSection
> > 
> > (Without this, X doesn't start, complaining it can't find VESA)
> > 
> > echo $DISPLAY returns the same on both desktops.
> 
> That is a single X11 screen spread across two physical monitors.  It
> will not exhibit the gtk-3 selection bug.
> 
> Are you sure you have two desktops and it's not just a single desktop
> that is spread across two monitors?  Can you drag a window from one
> monitor to the other?  If you can, then it's a single desktop.

Yes, I can.
When I maximize a window, it's only on 1 screen.

This is how it seems "right" to me.

Why would I want it to be different? Eg. windows can't be moved between 
screens? I don't see the point of having more than 1 screen in that case.

--
Joost

[gentoo-user] Re: Can't paste from selection in gtk-3 apps

[Grant Edwards]

On 2015-09-18, J. Roeleveld  wrote:
> On Thu, September 17, 2015 16:33, Grant Edwards wrote:
>> On 2015-09-17, Grant Edwards  wrote:
>>> On 2015-09-17, J. Roeleveld  wrote:
>>>
>> I use 2 screens extensively and never experienced any issues like you
>> describe.
>
> And you can select/paste from one screen to another where the source
> is a gtk-3 app?

 Not sure, need to test with a gtk-3 app.

 I run KDE myself.
>>>
> I should clarify that I mean "screen" in the strict X11 usage.  Using
> Xinerama or the like to spread a single desktop across multiple
> monitors is still a single screen setup.  I'm trying to select text
> on DISPLAY=:0.0 and paste it on DISPLAY=:0.1

 Not using my desktop atm.
 What does Xorg do by default when it detects multiple screens?
>>>
>>> Not sure -- I'll have to give it a try. IIRC, it just uses the first
>>> one.
>>
>> At least on my machine, if I start up X11 without a configuration
>> file it only uses one of my three monitors.  That behavior may depend
>> on which boards are installed and which board/driver is found first.
>
> On my desktop:
>
> $ cat /etc/X11/xorg.conf
> Section "Device"
> Identifier  "Card0"
> Driver  "nvidia"
> BusID   "PCI:2:0:0"
> EndSection
>
> (Without this, X doesn't start, complaining it can't find VESA)
>
> echo $DISPLAY returns the same on both desktops.

That is a single X11 screen spread across two physical monitors.  It
will not exhibit the gtk-3 selection bug.

Are you sure you have two desktops and it's not just a single desktop
that is spread across two monitors?  Can you drag a window from one
monitor to the other?  If you can, then it's a single desktop.

> Please note: This desktop was installed years ago and simply kept
> up-to-date for the most part. But it does have the "xinerama"
> USE-flag set globally.
>
> I remember reading something about it, but not sure if this is the
> "new" or "old" way of doing it. I need to check how my laptop handles
> it later today/this weekend.

-- 
Grant Edwards   grant.b.edwardsYow! MERYL STREEP is my
  at   obstetrician!
  gmail.com

Re: [gentoo-user] Quick check on net-print/hplip-3.14.10

[Mick]

On Thursday 17 Sep 2015 23:33:57 Alan McKinnon wrote:
> On 18/09/2015 00:26, Mick wrote:
> > On Thursday 17 Sep 2015 20:25:57 Alan McKinnon wrote:
> >> On 17/09/2015 19:36, Mick wrote:
> >>> OK, I managed to get 10 minutes access to the offending box and I
> >>> remerged hplip.  Guess what?  The 930c driver re-appeared on the list.
> >>> So I am now doubly paranoid that the btrfs is playing up ...
> >> 
> >> Or, someone deleted the ppd and the re-emerge put it back :-)
> > 
> > Hmm ... now, who would that be, when I'm the only one with root access to
> > this box?  O_o
> > 
> >> As the saying goes "never ascribe to malice what is adequately explained
> >> by stupidity"
> > 
> > Yeah, right, I don't have to answer that.  :-p
> 
> When you said "I managed to get 10 minutes access to the offending box"
> I figured it wasn't yours, that it had users, and you were the guy with
> the problem of sorting it out, and you needed some pointy haired bosses'
> permission to do it at all.
> 
> Seems that's not actually the case?

It is indeed the case, with the pointy haired boss being the missus and the 
box in question a production desktop. :-))

I have to admit that I can't recall messing up with the ppd files, or indeed 
ever using hpijs on this box.

A couple of months ago the akonadi DB went sideways and kmail played up as a 
result.  Again I was suspicious of btrfs, but neither the logs nor fsck showed 
up anything.

The OS is on a single SSD (no RAID), with some caches and busy fs mounted on a 
spinning disk.  I have some backups in case of DR, but after a while a 
corrupted fs will have migrated to the back ups.
-- 
Regards,
Mick


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

[gentoo-user] Re: Can't paste from selection in gtk-3 apps

[Grant Edwards]

On 2015-09-18, J. Roeleveld  wrote:
> On Friday 18 September 2015 14:34:26 Grant Edwards wrote:

>> I like having separate screens because the window manager I use
>> (xfwm4) supports multiple virtual workspaces for each screen (4 per
>> screen by default).  I find it very useful to be able to flip one
>> screen to a different workspace while leaving the others unaffected.
>> That allows me, for example, to leave email and web-browser up on one
>> screen while switching the other two back and forth between multiple
>> tasks/projects. (I am rarely allowed to work uninterrupted for long
>> periods on a single task.)
>> 
>> Not being able to move windows between screens is an inconvenience,
>> but for me it's well worth it to get independently switchable virtual
>> workspaces on each screen.
>
> To "simulate" that, I occasionally set a window to be on all virtual 
> workspaces.

Yep, that's what I do when I only have a single monitor.

> Does that only work when you have the displays seperate like you do?

Yes, but I find I don't need it with multiple screens -- I just open
in a particular screen all things I would otherwise pin-down.

> As that would be convenient and is something I actually miss.

-- 
Grant Edwards   grant.b.edwardsYow! I'm receiving a coded
  at   message from EUBIE BLAKE!!
  gmail.com

[gentoo-user] Re: Can't paste from selection in gtk-3 apps

[Grant Edwards]

On 2015-09-18, J. Roeleveld  wrote:

> I'll test without "xinerama" in the near future and let you know.
> (requires a rebuild of a lot of stuff...)

Don't bother on my account -- it's just idle curiosity, and I could do
the test myself...

-- 
Grant Edwards   grant.b.edwardsYow! I can't decide which
  at   WRONG TURN to make first!!
  gmail.comI wonder if BOB GUCCIONE
   has these problems!

[gentoo-user] Distfiles cache setup

[Daniel Frey]

Hi all,

I have been running several Gentoo machines here at my house, and am
currently up to 7 (or was it 8?) installs.

I have been trying to reduce my resource consumption and set up an rsync
mirror long ago, so my [acting] server only syncs to the internet and
all other devices point to it. That part is working fine, I've already
moved it to the repos.conf configuration.

Whenever I search for running a local distfiles mirror (on this list and
on the web) it gets a bit murky.

The way I see it is this can be done a couple of ways:

1. Set up a lighttpd server to serve the distfiles directory.

This has the benefit of being able to sync machines outside my network,
although I don't know if I'd expose it to the internet.

The major issue I can see with this is that if the file doesn't exist,
portage will crap out saying it's not available. What I don't know is if
there's an easy way to "get around" this issue.



2. Export the distfiles directory.

This seems to be a bit better of a solution, other than not being able
to use it outside the LAN. However, cleaning this directory becomes a
lot less trivial as tools used to clean it will assume that the current
machine is the only machine using it and clobber other workstation's
required distfiles.

I suppose the easiest way to sync is to wipe it completely out and run
`emerge -fe world` on all machines to rebuild it, but this would be a
fair bit of work as well.



With those two options, neither being perfect - it made me wonder if
there's a Better Way(tm) to do this.

In the case of a shared distfiles, it would be best if something was one
the machine hosting the distfiles monitoring what workstation needed
what file and only removing a file when no workstations request it.
Alas, I don't think a tool such as that exists (although I didn't really
look that hard.)

Ideally, it would be nice to have some sort of caching proxy that could
fetch the file as it was needed, but in searching for this I encountered
so much noise in the search results I gave up for the time being.

Anyone have any suggestions?

Dan

Re: [gentoo-user] Quick check on net-print/hplip-3.14.10

[Marc Joliet]

On Friday 18 September 2015 10:31:01 Mick wrote:
>A couple of months ago the akonadi DB went sideways and kmail played up as a 
>result.  Again I was suspicious of btrfs, but neither the logs nor fsck
>showed up anything.

I take it "btrfs scrub" didn't turn up anything, or is that what you meant by 
fsck?

>The OS is on a single SSD (no RAID), with some caches and busy fs mounted on
>a  spinning disk.  I have some backups in case of DR, but after a while a
>corrupted fs will have migrated to the back ups.

With btrfs, if there really was silent corruption, you wouldn't be able to 
access the file in the single disk case, so no, I don't think it actually 
would propagate to the backup (although perhaps you don't use btrfs 
exclusively, in which case it of course could).  Though keep in mind that 
corruption can happen in a variety of ways, e.g., application-level or 
firmware bugs.

-- 
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] Re: Can't paste from selection in gtk-3 apps

[J. Roeleveld]

On Friday 18 September 2015 14:34:26 Grant Edwards wrote:
> On 2015-09-18, J. Roeleveld  wrote:
> >>> echo $DISPLAY returns the same on both desktops.
> >> 
> >> That is a single X11 screen spread across two physical monitors.  It
> >> will not exhibit the gtk-3 selection bug.
> >> 
> >> Are you sure you have two desktops and it's not just a single desktop
> >> that is spread across two monitors?  Can you drag a window from one
> >> monitor to the other?  If you can, then it's a single desktop.
> > 
> > Yes, I can.
> > When I maximize a window, it's only on 1 screen.
> > 
> > This is how it seems "right" to me.
> 
> Then by all means continue to use it that way.  That's how most people
> seem to like it.
> 
> > Why would I want it to be different?  Eg. windows can't be moved
> > between screens? I don't see the point of having more than 1 screen
> > in that case.
> 
> I like having separate screens because the window manager I use
> (xfwm4) supports multiple virtual workspaces for each screen (4 per
> screen by default).  I find it very useful to be able to flip one
> screen to a different workspace while leaving the others unaffected.
> That allows me, for example, to leave email and web-browser up on one
> screen while switching the other two back and forth between multiple
> tasks/projects. (I am rarely allowed to work uninterrupted for long
> periods on a single task.)
> 
> Not being able to move windows between screens is an inconvenience,
> but for me it's well worth it to get independently switchable virtual
> workspaces on each screen.

To "simulate" that, I occasionally set a window to be on all virtual 
workspaces.
Does that only work when you have the displays seperate like you do? As that 
would be convenient and is something I actually miss.

--
Joost

Re: [gentoo-user] Re: Can't paste from selection in gtk-3 apps

[J. Roeleveld]

On Friday 18 September 2015 14:44:20 Grant Edwards wrote:
> On 2015-09-18, J. Roeleveld  wrote:
> >> There's a few reasons you might want more than one screen. Primary one
> >> is two heads and two video cards with different resolutions and dpi.
> >> Xinerama and big desktop et al will use the lower setting for both.
> > 
> > Actually, this desktop has xinerama enabled in USE-flags. IOW, I'm
> > assuming I am using Xinerama on here. I can change the resolution of
> > either screen and it all still works. (apart from the weird look of
> > windows on the other screen)
> 
> But can you set DPI independenty for the two monitors?  I'm guessing
> not, since you mention the "weird look of windows" -- that's probably
> due to use of the wrong DPI on one of the monitors.  With multiple
> screens, you _can_ set DPI correctly for two different monitors.
> 
> >> Some folk have 2 screens just because they've always done it that way
> >> for years and don't want to change
> >> 
> >> These days the usual case is one video card with more than one output
> >> so you connect identical monitors to each. For that, one big desktop
> >> makes sense.
> > 
> > Same with laptops, all laptops I've used in the past 5 years all had
> > the option to add a 2nd display and use that. Even with differing
> > resolutions, it works the same way. Plug it in, change the setting if
> > necessary (kdesettings does a good job with that) and I have 2
> > screens where i can move windows back and forth. It's great for
> > presentations. Can open a text-file with the passwords on the laptop
> > screen and copy/paste them from there onto the big screen everyone
> > else sees.
> 
> Except for the "moving windows back and forth" it works the same with
> dual screens except you can properly set DPI for both of them.

Not with the kdesettings.
I tend to always use the native resolution of the screens.

> There is one other disadvantage of having multiple screens that I
> forgot to mention.  Apart from the gtk-3 selection brokenness, there
> are some buggy X apps which just plain refuse to run on multiple
> screens simultaneously (Firefix is one).  They were apparently written
> by MS-Windows programmers based on the assumption that a computer is
> always used by exactly one person to run exactly one program on
> exactly on screen.  Most other X apps are properly written and support
> multiple screens just fine.

I'll test without "xinerama" in the near future and let you know.
(requires a rebuild of a lot of stuff...)

--
Joost

Re: [gentoo-user] Re: portage can not find local ebuild

[thelma]

On 09/18/2015 01:38 AM, Nikos Chantziaras wrote:
[snip]
> 
> Remove the PORTDIR_OVERLAY entry from make.conf. Then, create a new file
> in /etc/portage/repos.conf/, for example "local.conf", with these contents:
> 
> [Local]
> priority = 
> location = /usr/local/portage
> auto-sync = no
> 
> The high value for priority is just to make sure that your local ebuilds
> override any other ebuilds of the same name that exist elsewhere.

Good suggestion, thanks.

Thelma

Re: [gentoo-user] Distfiles cache setup

[Peter Humphrey]

On Friday 18 September 2015 10:02:27 Daniel Frey wrote:

> Ideally, it would be nice to have some sort of caching proxy that could
> fetch the file as it was needed, but in searching for this I encountered
> so much noise in the search results I gave up for the time being.
> 
> Anyone have any suggestions?

I use http-replicator for this. It needs a bit of maintenance to keep its 
space use down, but that can be taken care of by a cron script.

-- 
Rgds
Peter