Re: [gentoo-user] Some files in /usr/share/doc are not compressed

2012-12-20 Thread Francesco Turco 
On Wed, Dec 19, 2012, at 23:11, Alan McKinnon wrote:
> That stuff is controlled by the ebuild, IIRC ebuilds should call
> function dodoc so they do with docs what you want them to do. The
> function name may well have changed and been superceded since last I
> looked.
> 
> The reason you find nothing interesting in the ebuild is because
> something that should be there isn't. ebuilds not following rules wrt
> doc files is a bug and should be filed at bgo as such.

I looked into this problem a little more before submitting any bug.

At http://devmanual.gentoo.org/ebuild-writing/eapi/ it says that, for
EAPI=4, there is a default compression exclusion list:
/usr/share/doc/${PF}/html. udisks-2.0.0 ebuild uses EAPI=4. So this
explains why /usr/share/doc/udisks-2.0.0/html/udisks2/index.sgml and
many other such files are not being compressed. I checked, and they all
use EAPI=4 or EAPI=5. So the list of uncompressed files drops to 23
instead of 79.

Then I looked for non-zero size files only, because it makes no sense to
compress empty files. The list dropped to 9 files, belonging to 4
different ebuilds or 3 packages:

> /usr/share/doc/automake-1.12.5/amhello-1.0.tar.gz
> /usr/share/doc/libasyncns-0.8-r2/README
> /usr/share/doc/automake-1.11.6/amhello-1.0.tar.gz
> /usr/share/doc/groff-1.21-r1/meref.ps
> /usr/share/doc/groff-1.21-r1/meref.me
> /usr/share/doc/groff-1.21-r1/pic.ps
> /usr/share/doc/groff-1.21-r1/pic.ms
> /usr/share/doc/groff-1.21-r1/meintro.me
> /usr/share/doc/groff-1.21-r1/meintro.ps

Perhaps I may report these ones.

Re: [gentoo-user] Gnome-Keyring not unlocking with Slim Autologin

2012-12-20 Thread Stephen Griffiths 
Just to follow up on this. Seeing that I'm happy enough for my machine to
autologin on bootup, I'm happy enough for the gnome-keyring to be
automatically unlocked.

Is there a way of doing this?

Regards, Steve


On 18 December 2012 10:41, Stephen Griffiths  wrote:

> Thanks for you reply Mark.
>
> The way you put it makes sense. I guess the option is whether I would like
> to have the security risk of having my passwords open without needing any
> kind of authentication. But that depends on whether I can bypass needing to
> enter a password on autologin in the first please, or if it's not possible.
>
>
> On 18 December 2012 10:17, Mark David Dumlao  wrote:
>
>> On Tue, Dec 18, 2012 at 6:08 PM, Stephen Griffiths 
>> wrote:
>> > Is there some kind of rule where if you AutoLogin, you require some
>> kind of
>> > authentication when it comes to unlocking the keyring?
>> That's how the keyring works, in principle. The keyring is a
>> password-protected secret, and a typical desktop system would be setup
>> so that the login password you used was also used to unlock the
>> keyring. With autologin, no password is typed in, so gnome-keyring has
>> no way of being unlocked without asking you for a password.
>>
>> --
>> This email is:[ ] actionable   [x] fyi[ ] social
>> Response needed:  [ ] yes  [x] up to you  [ ] no
>> Time-sensitive:   [ ] immediate[ ] soon   [x] none
>>
>>
>
>
> --
> Kind Regards,
> Stephen Griffiths
>
>  [image: Email 
> st...@stevegriff.com] [image:
> Twitter]  [image: 
> Facebook] [image:
> Google+]  [image:
> LinkedIn] 
>
>


-- 
Kind Regards,
Stephen Griffiths

[image: Email
st...@stevegriff.com][image:
Twitter] [image:
Facebook][image:
Google+] [image:
LinkedIn]

Re: [gentoo-user] Some files in /usr/share/doc are not compressed

2012-12-20 Thread Francesco Turco 
On Thu, Dec 20, 2012, at 10:57, Francesco Turco wrote:
> Then I looked for non-zero size files only, because it makes no sense to
> compress empty files. The list dropped to 9 files, belonging to 4
> different ebuilds or 3 packages:
> 
> > /usr/share/doc/automake-1.12.5/amhello-1.0.tar.gz
> > /usr/share/doc/libasyncns-0.8-r2/README
> > /usr/share/doc/automake-1.11.6/amhello-1.0.tar.gz
> > /usr/share/doc/groff-1.21-r1/meref.ps
> > /usr/share/doc/groff-1.21-r1/meref.me
> > /usr/share/doc/groff-1.21-r1/pic.ps
> > /usr/share/doc/groff-1.21-r1/pic.ms
> > /usr/share/doc/groff-1.21-r1/meintro.me
> > /usr/share/doc/groff-1.21-r1/meintro.ps
> 
> Perhaps I may report these ones.

It seems that amhello-1.0.tar.gz is already present in the tarball from
the distfiles directory, so it is not Portage responsible for
compressing in gz format. But it would be a good thing if Portage could
recompress that file in xz format instead. I don't know if this is
possible. So I won't file a bug report for this, as I think it could be
closed as invalid.

groff-1.21-r1 installs postscript files (which are not compressible) and
related files. So I don't think it's a good idea to file a report for
this, too.

So the only bug I decided to report is for libasyncns-0.8-r2:
https://bugs.gentoo.org/show_bug.cgi?id=447936.

Re: [gentoo-user] Some files in /usr/share/doc are not compressed

2012-12-20 Thread julian 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/19/2012 05:41 PM, Francesco Turco wrote:
> Hello.
> 
> On my system Portage uses the following two variables for
> compressing files in /usr/share/doc:
> 
>> $ portageq envvar PORTAGE_COMPRESS xz
> 
>> $ portageq envvar PORTAGE_COMPRESS_EXCLUDE_SUFFIXES css gif
>> htm[l]? jp[e]?g js pdf png
> 
> It seems anyway that some files are not compressed:
> 
>> $ find /usr/share/doc -type f -regextype posix-extended ! -regex
>> ".*\.(css|gif|htm[l]?|jp[e]?g|js|pdf|png|xz)" | wc -l 79
> 
> I won't list all of them here, just some examples:
> 
>> /usr/share/doc/gnome-shell-3.4.2/AUTHORS 
>> /usr/share/doc/udisks-2.0.0/html/udisks2/index.sgml 
>> /usr/share/doc/groff-1.21-r1/pic.ps 
>> /usr/share/doc/automake-1.12.5/amhello-1.0.tar.gz
> 
> My goal is to have everything under /usr/share/doc compressed with
> xz, or at least to understand why something is being excluded from 
> compression. Perhaps it is due to some additional rules I'm not
> aware of, or because of some bugs.
> 
> I checked the ebuilds of the packages the previous files belong to,
> but I found nothing interesting.
> 
> It would be great if anyone who is interested could check his/her
> own system too.
> 
> Thank you.
> 

the ebuild developer can choose whether to not compress some files, look
for stuff like "docompress -x foo" in the ebuild

it is described in PMS:
https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12800011.3.3
(search for docompress)
and in the devmanual
http://devmanual.gentoo.org/ebuild-writing/eapi/index.html


Afaik pkgcore does ignore this command.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQ0vi3AAoJEFpvPKfnPDWzEiYH/jnqnIRVo82F8tK4E1eTqvsN
u55oCbIEV6ySqBHHk3oHcX+K0PbuZkOUymauYVjoyf3fV33gBOLrKsKsY7U5wQvo
0ZpqY4C89UgpmuprLlflzu+Ehjnl0/lA9Qgfya94meWMBUetbddEu4ZwfJ7TG9PR
TafiVpbQ/pu0WuhfNdvgkFHYySwG4Pk+afDFTFnBGYFyV3ud/4aeU4Nt3aZTVpAN
xSBZdGFLM4WW/yKuXbbtg4UdSV4RBtX1UV6TRd4cjZxqOxPAdQXUXM3gQuVvUcnJ
sZovWSrThcmjmgP14ikjqsY6axU/GmxuqJFqX2GY56KDw84xtg7wjG230NGoG3U=
=mzU5
-END PGP SIGNATURE-

Re: [gentoo-user] Installing swi-prolog and gnustep-base in the same time

2012-12-20 Thread Alan McKinnon 
On Wed, 19 Dec 2012 23:21:01 +0100
Frank Schwidom  wrote:

> Hi,
> 
> it seems, that swi-prolog and gnustep-base cannpot be installed in the
> same time because both packages share the same file /usr/bin/pl
> 
> what is the best solution, to handle this situation?


file a bug at b.g.o. asking for one or both ebuilds to be modified.

You've probably read the long output emerge gives when it encounters a
file collision and the warnings not to file gratuitous bugs without
full info on ebuilds and files etc. Well, this is not one of those
cases, this is a valid bug.

In the interim, you could also modify the ebuild locally (or slipstream
your own patch) to rename the files before install. This will let you
get both installed until the bug is fixed.


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

Re: [gentoo-user] Re: Anyone switched to eudev yet?

2012-12-20 Thread Volker Armin Hemmann 
Am Donnerstag, 20. Dezember 2012, 11:45:34 schrieb Mark David Dumlao:
> On Thu, Dec 20, 2012 at 2:42 AM, Volker Armin Hemmann
> 
>  wrote:
> > with redhat's push to move everything into /usr - why not stop right there
> > and move everything back into /?
> 
> I originally thought this way, but they actually reviewed the
> technical and historical merits for all the use cases and and found
> /usr to be superior. Straight out of the freedesktop wiki:
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
> 
> 0) If / and /usr are kept separate, programs in /usr can't be updated
> independently of programs in /, because the libraries they depend on
> might break compatibility. If the binaries and libraries were *all* in
> /usr, then the entire system's binaries would always be consistent
> regardless of where /usr were sourced from (config files in /etc,
> however, would still break).

not a problem at all if everything is in / and /usr doesn't even exist 
anymore.

> 1) There is historical precedent in Unix for /usr-centric systems,
> notably Solaris.

so what? historically we lived in mud huts and used flintstone knives.

> 2) If /usr were separated from /, then /usr could be mounted
> read-only, with / being mounted "normally". Which makes sense, as /
> does have bits that are meant to be read-write.
really? once upon a time I was told mounting / ro and /usr rw was a GOOD THING 
to do. I ignored that the same way I ignore it the other way round. With bind 
mounting and stuff, you can make single directories rw.. so what is the matter?

> 3) Most software packagers write their binaries to a PREFIX defaulting
> to /usr/local, or /usr, as opposed to /. Determining which ones belong
> in / or /usr can sometimes be dependent on the distro and/or sysad.
> But since more of them default to /usr, if everything were in /usr
> it'd be a saner default.

so what? PREFIX can be changed. Set it to /local if you want. Or /var/local. 
Or /my/happy/place/local. 

> 
> (0) basically says that keeping them separate only works as intended
> if the both the sysad and the distro upstream work together for their
> shared /usr mount. In many cases, however, sysads have to do a lot of
> working around and careful planning to get /usr mounted remotely.
> (1), (2), and (3) provide advantages to mounting the binaries and
> libraries separately from the / filesystem, which mounting them as
> part of / does not provide.

no, not really. No.

-- 
#163933

[gentoo-user] 'eix-remote update' STDERR bug?

2012-12-20 Thread Grant 
I run 'eix-remote update > /dev/null' in a crontab and I get the following
via email.  The lines at the very end seem appropriate but the rest seems
like it should be STDOUT.  Should I file a bug about this?

>From git://github.com/init6/init_6
   ea76d0b..6740e9a  master -> origin/master
--2012-12-20 04:02:25--
http://dev.gentooexperimental.org/eix_cache/eix-caches.tbz2
Resolving dev.gentooexperimental.org... 91.191.147.225
Connecting to dev.gentooexperimental.org|91.191.147.225|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2166202 (2.1M) [application/octet-stream]
Last-modified header missing -- time-stamps turned off.
--2012-12-20 04:02:27--
http://dev.gentooexperimental.org/eix_cache/eix-caches.tbz2
Reusing existing connection to dev.gentooexperimental.org:80.
HTTP request sent, awaiting response... 200 OK
Length: 2166202 (2.1M) [application/octet-stream]
Saving to: 'eix-caches.tbz2'

 0K .. .. .. .. ..  2% 49.6K 42s
50K .. .. .. .. ..  4% 75.3K 34s
   100K .. .. .. .. ..  7% 2.19M 22s
   150K .. .. .. .. ..  9%  150K 19s
   200K .. .. .. .. .. 11%  152K 18s
   250K .. .. .. .. .. 14% 2.15M 14s
   300K .. .. .. .. .. 16%  167K 14s
   350K .. .. .. .. .. 18% 1.37M 12s
   400K .. .. .. .. .. 21% 1.99M 10s
   450K .. .. .. .. .. 23%  169K 10s
   500K .. .. .. .. .. 25% 2.21M 9s
   550K .. .. .. .. .. 28% 2.18M 8s
   600K .. .. .. .. .. 30% 1.27M 7s
   650K .. .. .. .. .. 33% 1.18M 6s
   700K .. .. .. .. .. 35%  217K 6s
   750K .. .. .. .. .. 37% 2.20M 6s
   800K .. .. .. .. .. 40% 2.16M 5s
   850K .. .. .. .. .. 42% 2.20M 5s
   900K .. .. .. .. .. 44% 1.20M 4s
   950K .. .. .. .. .. 47%  229K 4s
  1000K .. .. .. .. .. 49% 2.18M 4s
  1050K .. .. .. .. .. 51% 2.18M 3s
  1100K .. .. .. .. .. 54%  125K 3s
  1150K .. .. .. .. .. 56% 5.57M 3s
  1200K .. .. .. .. .. 59% 6.36M 3s
  1250K .. .. .. .. .. 61% 82.2M 3s
  1300K .. .. .. .. .. 63% 71.3M 2s
  1350K .. .. .. .. .. 66% 86.4M 2s
  1400K .. .. .. .. .. 68% 78.8M 2s
  1450K .. .. .. .. .. 70% 84.5M 2s
  1500K .. .. .. .. .. 73% 68.9M 2s
  1550K .. .. .. .. .. 75% 88.5M 1s
  1600K .. .. .. .. .. 77% 95.6M 1s
  1650K .. .. .. .. .. 80% 2.94M 1s
  1700K .. .. .. .. .. 82%  127K 1s
  1750K .. .. .. .. .. 85%  148K 1s
  1800K .. .. .. .. .. 87% 2.26M 1s
  1850K .. .. .. .. .. 89%  156K 1s
  1900K .. .. .. .. .. 92% 2.18M 0s
  1950K .. .. .. .. .. 94% 2.20M 0s
  2000K ..  2050K .. .. .. ..
.. 99%  178K 0s
  2100K .. .  100%
2.41M=5.6s

2012-12-20 04:02:33 (376 KB/s) - 'eix-caches.tbz2' saved [2166202/2166202]

garbage (eta37) at end of version '1.0.0beta37'
accepting version anyway
garbage (-scm) at end of version '3.0-scm'
accepting version anyway
garbage (-scm) at end of version '2.1-scm'
accepting version anyway

- Grant

Re: [gentoo-user] Re: Anyone switched to eudev yet?

2012-12-20 Thread Kevin Chadwick 
> really? once upon a time I was told mounting / ro and /usr rw was a GOOD 
> THING 
> to do. I ignored that the same way I ignore it the other way round. With bind 
> mounting and stuff, you can make single directories rw.. so what is the 
> matter?

Ignorance is bliss, so good for you.

Only as root and if RBAC/SELINUX doesn't stop you. It's an extra quite
formidable layer. It is a good thing for many reasons and even a
requirement on some embedded systems. The kernel can also inform you of
any remounts making monitoring far simpler, easier and so powerful and
more efficient.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: [gentoo-user] Re: Anyone switched to eudev yet?

2012-12-20 Thread Kevin Chadwick 
> On Thu, Dec 20, 2012 at 2:42 AM, Volker Armin Hemmann
>  wrote:
> > with redhat's push to move everything into /usr - why not stop right there 
> > and
> > move everything back into /?
> 
> I originally thought this way, but they actually reviewed the
> technical and historical merits for all the use cases and and found
> /usr to be superior. Straight out of the freedesktop wiki:
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
> 
> 0) If / and /usr are kept separate, programs in /usr can't be updated
> independently of programs in /, because the libraries they depend on
> might break compatibility. If the binaries and libraries were *all* in
> /usr, then the entire system's binaries would always be consistent
> regardless of where /usr were sourced from (config files in /etc,
> however, would still break).

Complete rubbish. If something in / needs something it should be in /
if something is in / that isn't critical it shouldn't be there and
won't matter. In all other cases everything exists. If you want some
special feature that adds complexity to your early boot up stage
or single user then that should be an optional package that installs
into /. Similar to ssh enabled grub, it's optional.

> 2) If /usr were separated from /, then /usr could be mounted
> read-only, with / being mounted "normally". Which makes sense, as /
> does have bits that are meant to be read-write.

It certainly does not. There are packages that fix dhcp. I haven't ever
setup a system that needed to do that. Updates get temporary
controlled access.

> 3) Most software packagers write their binaries to a PREFIX defaulting
> to /usr/local, or /usr, as opposed to /. Determining which ones belong
> in / or /usr can sometimes be dependent on the distro and/or sysad.
> But since more of them default to /usr, if everything were in /usr
> it'd be a saner default.
> 

A concensus would be good. A right consensus is more likely to get a
consensus. This has no bearing on the matters at hand.

> (0) basically says that keeping them separate only works as intended
> if the both the sysad and the distro upstream work together for their
> shared /usr mount. In many cases, however, sysads have to do a lot of
> working around and careful planning to get /usr mounted remotely.
> (1), (2), and (3) provide advantages to mounting the binaries and
> libraries separately from the / filesystem, which mounting them as
> part of / does not provide.
> 

Rubbish you can mount the whole of / or /usr. If all you have is /usr
then if anything all you can mount is / but in fact you can mount any
folder anywhere due to unix-like systems being ace.

I wonder what percentage of Linux users believe you should have
one partition for everything due to easier installs. I know the number
will be increasing every day.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

2012-12-20 Thread Grant 
>> I should have specified that the people in the organization are spread out
>> in different locations.
>>
>> It sounds like it is difficult/dangerous to run an internet-facing IRC
>> server and ejabberd is unstable?
>
> This is what VPNs are for. I haven't really heard anything seriously
> problematic about ejabberd outside of some folks dislike of adding
> another language runtime.
>
> Whatever you decide to run internally, you're going to need to become
> knowledgeable in its administration. This is why a fair amount of
> folks are outsourcing communications infrastructure. Few believe they
> have the time to learn to manage the thing properly.

Is ejabberd difficult to run over the internet safely?

- Grant

[gentoo-user] {OT} anyone tried egroupware?

2012-12-20 Thread Grant 
Has anyone tried egroupware?  Any opinions on it?

- Grant

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

2012-12-20 Thread Michael Mol 
On Thu, Dec 20, 2012 at 4:02 PM, Grant  wrote:
>>> I should have specified that the people in the organization are spread out
>>> in different locations.
>>>
>>> It sounds like it is difficult/dangerous to run an internet-facing IRC
>>> server and ejabberd is unstable?
>>
>> This is what VPNs are for. I haven't really heard anything seriously
>> problematic about ejabberd outside of some folks dislike of adding
>> another language runtime.
>>
>> Whatever you decide to run internally, you're going to need to become
>> knowledgeable in its administration. This is why a fair amount of
>> folks are outsourcing communications infrastructure. Few believe they
>> have the time to learn to manage the thing properly.
>
> Is ejabberd difficult to run over the internet safely?

I doubt it. But you'd want to give the docs a thorough reading to make
sure you have security questions locked down properly. Off the top of
my head...don't allow remote registrations (i.e. don't allow clients
to create accounts). Require SSL/TLS. Always make sure you're up on
the latest security patches.

Beyond that, you'd have to read docs. Which is what a lot of
self-described sysadmins can't be bothered to do.

--
:wq

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

2012-12-20 Thread Alan McKinnon 
On Thu, 20 Dec 2012 13:02:46 -0800
Grant  wrote:

> >> I should have specified that the people in the organization are
> >> spread out in different locations.
> >>
> >> It sounds like it is difficult/dangerous to run an internet-facing
> >> IRC server and ejabberd is unstable?
> >
> > This is what VPNs are for. I haven't really heard anything seriously
> > problematic about ejabberd outside of some folks dislike of adding
> > another language runtime.
> >
> > Whatever you decide to run internally, you're going to need to
> > become knowledgeable in its administration. This is why a fair
> > amount of folks are outsourcing communications infrastructure. Few
> > believe they have the time to learn to manage the thing properly.
> 
> Is ejabberd difficult to run over the internet safely?

Not especially difficult. It's just another daemon that runs and does
things much like classic daemons do. It listens to one port and doesn't
do anything weird or funky.

To make it safe, you just follow regular guidelines about security,
firewalls etc. Your job is *much* easier if you intend to run a closed
server used only by users you create, which is what you intend if I
read it right.


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

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

2012-12-20 Thread Grant 
>> Is ejabberd difficult to run over the internet safely?
>
> I doubt it. But you'd want to give the docs a thorough reading to make
> sure you have security questions locked down properly. Off the top of
> my head...don't allow remote registrations (i.e. don't allow clients
> to create accounts). Require SSL/TLS. Always make sure you're up on
> the latest security patches.
>
> Beyond that, you'd have to read docs. Which is what a lot of
> self-described sysadmins can't be bothered to do.

Fair enough.  It sounds like IRC is especially tricky with regard to
security but ejabberd isn't.

- Grant

Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code

2012-12-20 Thread Michael Mol 
On Thu, Dec 20, 2012 at 4:32 PM, Grant  wrote:
>>> Is ejabberd difficult to run over the internet safely?
>>
>> I doubt it. But you'd want to give the docs a thorough reading to make
>> sure you have security questions locked down properly. Off the top of
>> my head...don't allow remote registrations (i.e. don't allow clients
>> to create accounts). Require SSL/TLS. Always make sure you're up on
>> the latest security patches.
>>
>> Beyond that, you'd have to read docs. Which is what a lot of
>> self-described sysadmins can't be bothered to do.
>
> Fair enough.  It sounds like IRC is especially tricky with regard to
> security but ejabberd isn't.

Dunno about that. You can set up IRC to be "authorized-users only" as
well. I imagine the only real difference for you would be the variety
of software clients your users have available to them.

(Also, as an aside, I've been at places with internal XMPP and with
internal IRC. I've found internal IRC to be far more flexible and
comfortable.)

--
:wq

Re: [gentoo-user] Re: Anyone switched to eudev yet?

2012-12-20 Thread Mark David Dumlao 
On Fri, Dec 21, 2012 at 5:01 AM, Kevin Chadwick  wrote:
>> On Thu, Dec 20, 2012 at 2:42 AM, Volker Armin Hemmann
>>  wrote:
>> > with redhat's push to move everything into /usr - why not stop right there 
>> > and
>> > move everything back into /?
>>
>> I originally thought this way, but they actually reviewed the
>> technical and historical merits for all the use cases and and found
>> /usr to be superior. Straight out of the freedesktop wiki:
>> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
>>
>> 0) If / and /usr are kept separate, programs in /usr can't be updated
>> independently of programs in /, because the libraries they depend on
>> might break compatibility. If the binaries and libraries were *all* in
>> /usr, then the entire system's binaries would always be consistent
>> regardless of where /usr were sourced from (config files in /etc,
>> however, would still break).
>
> Complete rubbish. If something in / needs something it should be in /
> if something is in / that isn't critical it shouldn't be there and
> won't matter. In all other cases everything exists. If you want some
> special feature that adds complexity to your early boot up stage
> or single user then that should be an optional package that installs
> into /. Similar to ssh enabled grub, it's optional.

Key here being "should" be. In theory, that's what should happen. In
practice, either the sysad or the upstream fails to keep it that way.
Here's a quick test:

$ equery belongs /lib
shows a list of packages installing to /lib. On my system, that's a
lot, including ncurses, readline, glibc, consolekit, and god knows
what other "basic" libraries a lot of programs are bound to depend on.
Wouldn't it be fun if my / filesystem got updated to a new, oh I
dunno, glibc, and my /usr filesystem didn't know all about it?

_In theory_, such programs should be independent. But to implement
this theory, either or both the sysad and the distro needs to ensure
that
(1) both / and /usr get duplicate essential libraries
(2) no programs in /usr ever depend on any libraries in /

i.e., _in practice_, the / and /usr split isn't being properly
delivered by distros anyway. And Gentoo is no exception to that. My
/usr/lib's libraries are just symlinks to the libraries in /, so I
can't trust a system where the binaries and libraries in both
filesystems aren't updated _together_.

>
>> 2) If /usr were separated from /, then /usr could be mounted
>> read-only, with / being mounted "normally". Which makes sense, as /
>> does have bits that are meant to be read-write.
>
> It certainly does not. There are packages that fix dhcp. I haven't ever
> setup a system that needed to do that. Updates get temporary
> controlled access.

You're already assuming that all the other read-write folders (/var
and /tmp) are sent off to different filesystems. That is definitely
good practice, but is not a given. And /etc is config files, which is
at least "semantically" a read-write thing - and in practice ALSO
written to by packages like *cough* *cough* networkmanager.

i.e., you're comparing
/ rw
/usr ro

to a series of bind mounts and/or extra filesystems or symlinking
magic. Well yes, those can _still_ be done if /usr contained all the
binaries, though. But combining the binaries and libs into /usr makes
the simpler setup above possible. It isn't possible right now without
some painstaking sysad work.

>
>> 3) Most software packagers write their binaries to a PREFIX defaulting
>> to /usr/local, or /usr, as opposed to /. Determining which ones belong
>> in / or /usr can sometimes be dependent on the distro and/or sysad.
>> But since more of them default to /usr, if everything were in /usr
>> it'd be a saner default.
>>
>
> A concensus would be good. A right consensus is more likely to get a
> consensus. This has no bearing on the matters at hand.

/usr as the default prefix for installed packages is the "consensus"
of the vast majority of packages out there. Why do you think this has
no bearing on their consideration?

--
This email is:[ ] actionable   [ ] fyi[x] social
Response needed:  [ ] yes  [x] up to you  [ ] no
Time-sensitive:   [ ] immediate[ ] soon   [x] none

Re: [gentoo-user] Re: Anyone switched to eudev yet?

2012-12-20 Thread Kevin Chadwick 
On Fri, 21 Dec 2012 05:46:33 +0800
Mark David Dumlao  wrote:

> >
> > A concensus would be good. A right consensus is more likely to get a
> > consensus. This has no bearing on the matters at hand.  
> 
> /usr as the default prefix for installed packages is the "consensus"
> of the vast majority of packages out there. Why do you think this has
> no bearing on their consideration?

I'm just pointing out that despite what many seem to state there are
losses and unclear/non forth coming positive reasons or real benefits
to the current apparently to be imposed or your doomed "consensus" of
consolidating data. Once your at multi-user the whole filesystem is one
for all intensive purposes anyway and so much of what you have said is
misleading. It really shouldn't be a difficult problem to fix, it is
just data after all.

 I certainly don't expect linux to solve these management problems,
 quite the opposite in fact but I can hope. I am just glad eudev is
 removing some of the excuse to ignore and quieten complaints that may
 be the real motivation to allow changes later that don't break
 anything or cause too loud screams, being the rules of the kernel
 devs before allowing more radical changes. There are a few indicators
 that lend credence to this possibility.

What is even more encouraging is eudevs keen eye on unneccesary
complexity and increased potential for bugs and unexpected code pull
in at the very core of the early boot process.

Stability and security features or design is never missed until it's too
late and then lots is spent on ineffective band aids.

[gentoo-user] Re: How do I remove a module from ENLIGHTENMENT_MODULES?

2012-12-20 Thread Nikos Chantziaras 

On 20/12/12 08:52, ckard wrote:

On Thu, Dec 20, 2012 at 6:32 AM, Nikos Chantziaras  wrote:


On 12/19/2012 22:15, Nikos Chantziaras wrote:


I want to remove the "connman" module from ENLIGHTENMENT_MODULES.  I've
put this in my make.conf:

 ENLIGHTENMENT_MODULES = "-connman"

But it doesn't work; emerge complains:

Invalid '-' operator in non-incremental variable
'ENLIGHTENMENT_MODULES': '-connman'


In your package.use
"x11-wm/enlightenment -enlightenment_modules_connman"

"enlightenment_modules_module-name" in general for each one you wanna
turn off individually


Thanks.  That does the trick.

Re: [gentoo-user] Re: Anyone switched to eudev yet?

2012-12-20 Thread Kevin Chadwick 
On Fri, 21 Dec 2012 00:09:50 +
Kevin Chadwick  wrote:

> I certainly don't expect linux to solve these management problems,
>  quite the opposite in fact but I can hope.

I hope mentioning OpenBSD won't put anyone off but taking a leap out of
their book I feel could really benefit linux. This could be a busybox
like project but with general usage fully functional and non space
sensitive goals that creates a core reliable single user environment
with compilation options like busybox for distros to pick and choose
from that is consistent across all distros and self managing via
packagers needing to request for immediate inclusion by default but
obviously being installable though recognising they are crossing the
line drawn in the sand.

[gentoo-user] copy resize files with directories

2012-12-20 Thread Joseph 
I've found this script that copy and resize file on the fly from one location to another. 


for INPUT in ./*.JPG; do OUTPUT=/media/stick/`echo $INPUT | sed 
's/\.JPG/\_new\.JPG/'`; echo $INPUT /media/stick/$OUTPUT; convert $INPUT -scale 
800x $OUTPUT; done

I go into each directory manually and run this command, however my camera was originally 
set to start the same file name every time I empty it so I have the same file name in may directories (the are not unique) so every time I run this script it re-writes 
the original one.


The ideal situation would be go into each directory and create the same 
director directory on the destination disk with modified files
Can anybody suggest how can I rewrite this script to copy files together with 
directory or change the file to a unique one.

I would like to span all directory I'm IN and bellow and run that script on any 
directory below.

--
Joseph

Re: [gentoo-user] {OT} anyone tried egroupware?

2012-12-20 Thread J. Roeleveld 
Grant  wrote:

>Has anyone tried egroupware?  Any opinions on it?
>
>- Grant

Yes. I have been using the community version for several years.

Originally for the calendar and addressbook. But gradually been using the other 
stuff as well apart from that website module. (not logged in at the moment. 
Can't check the actual name)

I quite like it. It does what it says on the box.
It's also easy to set up when you have some experience with other webapps. 
Integrates well with Kontakt from KDE and probably also others (but can't 
comment on it)

Is there anything in particular you want to know about it?

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] copy resize files with directories

2012-12-20 Thread Joseph 

On 12/20/12 22:07, Joseph wrote:

I've found this script that copy and resize file on the fly from one location 
to another.

for INPUT in ./*.JPG; do OUTPUT=/media/stick/`echo $INPUT | sed 
's/\.JPG/\_new\.JPG/'`; echo $INPUT /media/stick/$OUTPUT; convert $INPUT -scale 
800x $OUTPUT; done

I go into each directory manually and run this command, however my camera was 
originally
set to start the same file name every time I empty it so I have the same file 
name in may directories (the are not unique) so every time I run this script it 
re-writes
the original one.

The ideal situation would be go into each directory and create the same 
director directory on the destination disk with modified files
Can anybody suggest how can I rewrite this script to copy files together with 
directory or change the file to a unique one.

I would like to span all directory I'm IN and bellow and run that script on any 
directory below.


I do I combine the script above with this one below:

find . -maxdepth 1 -type f -name "*rospslpar*" |while read filename; do
 path_name=${filename%/*}
 base_name=${filename##*/}
 new_name="$(expr substr $base_name 14 6).jpg"
 mv "$filename" "$path_name/$new_name"
done

It would help be rename the file with unique name.  

--
Joseph