Re: [gentoo-user] Managing multiple systems with identical hardware

[Grant]

>> > I'm soaking up a lot of your time (again).  I'll return with any real
>> > Gentoo questions I run into and to run down the final plan before I
>> > execute it.  Thanks so much for your help.  Not sure what I'd do
>> > without you. :)
>>
>> I'm sure Neil would step in if I'm hit by a bus
>> He'd say the same things, and use about 1/4 of the words it takes me ;-)
>
> So far in this thread, I've managed about 0/4 of the words you've used...
> Oh damn!
>
> But yes, a build host and adding --usepkg=y to EMERGE_DEFAULT_OPTS in
> make.conf gives a massive speed increase. Run the build host in an easily
> recovered environment, like a VM, and you don't even have to monitor the
> world update on it, just run a script in the early hours that does emerge
> --sync && emerge -uXX @world and check your mailbox for errors before
> running emerge on the "clients". The use clusterssh or dsh to update them
> all at once.

I'm hoping to update everything on my own laptop before I have the
laptop clients update.  If I install everything on my own laptop that
any of the clients have installed, I should be able to avoid any
update trouble on the clients.  clusterssh or dsh sounds like a good
method for updating the clients.  Basically, once I update everything
on my laptop and it looks good, I want to be able to send the clients
a signal to update as well.

- Grant

Re: [gentoo-user] SystemD + Gnome 3.8 I can log in as root but not as normal user

[Jochen Kirchner]

Am 01.10.2013 08:30, schrieb Carlos Sura:

Hello Mates,

I finally thought that I got this working, so now I am dealing this issue:
I choose the latest kernel with systemd and GDM starts good, but I 
cannot log in to gnome as a normal user, I can only log in to gnome as 
root.


What I have done before this started:

emerge -uDvaN world
emerge --depclean --ask
emerge @preserved-rebuild

Then it just happened.

What I've tried so far:
- .xinitrc with exec gnome-session for user and root
- emerge -1 $( qlist -IC x11-drivers/ )
- emerge @x11-module-rebuild
-  X -configure


Another note:
Starting gnome as normal user just hang, apparently it wants to start 
but it cannot start. Neither doing: startx.


I am using for xorg:
VIDEO_CARDS="intel vesa"

Any help?

Regards

--
Carlos Sura.-
www.carlossura.com 
www.carlossura.com/blog 


Hi,

have you looked in your /var/log/Xorg.0.log?

And I think the GDM session log is in /home/*user*/.cache/gdm/session.log.

Regards,

Jochen

--
"There is only one god, and his name is Death.
And there is only one thing we say to Death: 'Not today'."
- Syrio Forel, Game of Thrones

http://acidc0re.info

Re: [gentoo-user] systemd installation location

[Alan McKinnon]

On 01/10/2013 00:14, pk wrote:
> On 2013-09-30 08:45, Alan McKinnon wrote:
> 
>> That is over-simplifying the problem and trivializing it. No-one ever
>> said the *everythign* in /usr is criticial for boot.
> 
> Is it really over-simplyfying it? How am I supposed to know whatever
> comes next? Someone ("upstream") *may* find it boot-critical to have
> 'Space Invaders' operational during boot. Yes, I say that somewhat
> *tounge-in-cheek* but the way things are going I'm not so sure anymore...

There are many examples in /usr you could have used to illustrate your
point, such as many fuse modules. And yet you chose an imaginary space
invader game.

Let's rather stick within the bounds of what is feasible, OK?

>> This is the problem:
>>
>> a. There exists code used at boot and early-user space time. It is
>> critical that this code is available when needed.
> 
> I fully understand this and *if* I ever were to install code that I
> *knew* had this dependency I would take a serious look if I really
> *need* it and only then install it. But it would be up to me to make
> that decision and take the necessary steps.

But it's not just you. You are not running LFS, you are running Gentoo.
It has ebuilds and ebuilds put the generated files somewhere, and that
destination is the same for every user of that ebuild.

Unix, by design and unlike a traditional mainframe OS, does not
distinguish between different types of files and does limit where you
can put files. This has two consequences - you can do virtually anything
you like with it as everything is a file, and filesystem files and
structure have been moved out to human space in the hands of the
sysadmin/packager/maintainer/user or whatever. Some sanity must prevail.

The Linux boot process can conceivably run any arbitrary code it needs
to run to get userspace into a runnable state. This can easily be code
that we haven't conceived of yet and becuase it is Unix, it could reside
anywhere. Also because it's Unix and because sysadmins have learned over
the years we constrain ourselves to putting the code in the bin, sbin
and lib directories in / and in /usr.

Clearly, there is a massive distinction between code there and in say
/opt or /var/lib, that is why you won't find boot-critical code there.
But there is no such clear distinction between / and /usr. What *you*
think is not boot critical may be criticial for someone else.

And here's the kicker:

You don't get to decide for the other guy. But the packager gets to
support him, and has to edit ebuilds to install all the necessary code
not in /usr but in /. And they have to do this over and over and over,
and while they are doing that they have to answer users like you who are
complinaing about unneccessary rebuilds just to change the desitnation
of a few files.

This is a no-win-ever situation for devs and they have decided they are
not doing it anymore and have made a decision to not support separate
/usr without initramfs. that is their right as you do not pay them a salary.

This is the correct decision for Gentoo to have made, as the problem is
open ended and is never completed, plus there is no clear distinction
between what is boot critical in the general case and what is not. if
you can't see or understand that, then we have nothing more to discuss.

If you don't like what Gentoo has done then I recommend you take it like
a man and fork. Assume the maintenanceburden yourself.


> 
>> b. One cannot predict with absolute certainty 100% of the time what
>> exactly that critical code is.
> 
> In a general manner, no, you are correct... Also, see above
> ("Invaders")... (And if you don't understand what I'm trying to say, I'm
> saying this is as *arbitrary* as it gets - which you, like me, seem to
> be opposed to["arbitrariness"])
> 
>> c. many reasonable setups turn out to have such critical code in /usr,
>> and this cannot be reliably predicted in advance
> 
> So I avoid things like Gnome, pulseaudio, systemd and similar stuff like
> the plague but I *still* shall be forced to use whatever is dictated by
> these things[1]? Don't get me wrong, if anyone wants to install Gnome or
> whatever then they should have the restrictions required by it.
> 
>> Your second paragraph reveals that you beleive you already know
>> everything you need to have to boot your system. Now do the same for
>> every possible Gentoo user out there and have it work 100% of the time
>> in ALL valid cases.
> 
> I *do* know everything I need to have to boot my system. I carefully
> select my hardware and I take particular care of how I set up my system
> thank you very much. But apparently my system is no longer deemed a
> "valid case"... so I'm obviously not a "possible Gentoo user" anymore.
> 
>> Do you now see the problem and the fulls cope and impact of it?
> 
> I've seen it since *long* before this thread started. The main problem
> is lack of resources (because of stupid decisions upstream which puts a
> burden on Gentoo devs) and I 

Re: [gentoo-user] Managing multiple systems with identical hardware

[Alan McKinnon]

On 01/10/2013 08:07, Grant wrote:
> Keeping all of the laptops 100% identical as far as hardware is
> central to this plan.  I know I'm setting myself up for big problems
> otherwise.
>
> I'm hoping I can emerge every package on my laptop that every other
> laptop needs.  That way I can fix any build problems and update any
> config files right on my own system.  Then I would push config file
> differences to all of the other laptops.  Then each laptop could
> emerge its own stuff unattended.

 I see what you desire now - essentially you want to clone your laptop
 (or big chunks of it) over to your other workstations.
>>>
>>> That sounds about right.
>>>
 To get a feel for how it works, visit puppet's web site and download
 some of the test appliances they have there and run them in vm software.
 Set up a server and a few clients, and start experimenting in that
 sandbox. You'll quickly get a feel for how it all hangs together (it's
 hard to describe in text how puppet gets the job done, so much easier to
 do it for real and watch the results)
>>>
>>> Puppet seems like overkill for what I need.  I think all I really need
>>> is something to manage config file differences and user accounts.  At
>>> this point I'm thinking I shouldn't push packages themselves, but
>>> portage config files and then let each laptop emerge unattended based
>>> on those portage configs.  I'm going to bring this to the 'salt'
>>> mailing list to see if it might be a good fit.  It seems like a much
>>> lighter weight application.
>>
>> Two general points I can add:
>>
>> 1. Sharing config files turns out to be really hard. By far the easiest
>> way is to just share /etc but that is an all or nothing approach, and
>> you just need one file to be different to break it. Like /etc/hostname
>>
>> You *could* create a "share" directory inside /etc and symlink common
>> files in there, but that gets very tedious quickly.
>>
>> Rather go for a centralized repo solution that pushes configs out, you
>> must just find the one that's right for you.
> 
> Does using puppet or salt to push configs from my laptop qualify as a
> centralized repo solution?


yes



> 
>> 2. Binary packages are almost perfect for your needs IMHO, running
>> emerge gets very tedious quickly, and your spec is that all workstations
>> have the same USE. You'd be amazed how much time you save by doing this:
>>
>> emerge -b on your laptop and share your /var/packages
>> emerge -K on the workstations when your laptop is on the network
>>
>> step 2 goes amazingly quickly - eyeball the list to be emerged, they
>> should all be purple, press enter. About a minute or two per
>> workstation, as opposed to however many hours the build took.
> 
> The thing is my laptop goes with me all over the place and is very
> rarely on the same network as the bulk of the laptop clients.  Most of
> the time I'm on a tethered and metered cell phone connection
> somewhere.  Build time itself really isn't a big deal.  I can have the
> clients update overnight.  Whether the clients emerge or emerge -K is
> the same amount of admnistrative work I would think.


I see. So you give up the efficiency of binpkgs to get a system that at
least works reliably.

Within those constraints that probably is the best option.

> 
>> 3. (OK, three points). Share your portage tree over the network. No
>> point in syncing multiple times when you actually just need to do it once.
> 
> Yep, I figure each physical location should designate one system to
> host the portage tree and distfiles.


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

Re: [gentoo-user] Managing multiple systems with identical hardware

[Grant]

>> > Puppet seems like overkill for what I need.  I think all I really need
>> > is something to manage config file differences and user accounts.  At
>> > this point I'm thinking I shouldn't push packages themselves, but
>> > portage config files and then let each laptop emerge unattended based
>> > on those portage configs.  I'm going to bring this to the 'salt'
>> > mailing list to see if it might be a good fit.  It seems like a much
>> > lighter weight application.
>>
>> Two general points I can add:
>>
>> 1. Sharing config files turns out to be really hard. By far the easiest
>> way is to just share /etc but that is an all or nothing approach, and
>> you just need one file to be different to break it. Like /etc/hostname
>>
>> You *could* create a "share" directory inside /etc and symlink common
>> files in there, but that gets very tedious quickly.
>
> How about using something like unison? I've been using it for a while
> now to sync a specific subset of ~ between three computers.
> It allows for exclude rules for host-specific stuff.

I think what I'd be missing with unison is something to manage the
differences in those host-specific files.

- Grant

[gentoo-user] SystemD + Gnome 3.8 I can log in as root but not as normal user

[Carlos Sura]

Hello Mates,

I finally thought that I got this working, so now I am dealing this issue:
I choose the latest kernel with systemd and GDM starts good, but I cannot
log in to gnome as a normal user, I can only log in to gnome as root.

What I have done before this started:

emerge -uDvaN world
emerge --depclean --ask
emerge @preserved-rebuild

Then it just happened.

What I've tried so far:
- .xinitrc with exec gnome-session for user and root
-  emerge -1 $( qlist -IC x11-drivers/ )
- emerge @x11-module-rebuild
-  X -configure


Another note:
Starting gnome as normal user just hang, apparently it wants to start but
it cannot start. Neither doing: startx.

I am using for xorg:
VIDEO_CARDS="intel vesa"

Any help?

Regards

-- 
Carlos Sura.-
www.carlossura.com
www.carlossura.com/blog

Re: [gentoo-user] Managing multiple systems with identical hardware

[Grant]

 Keeping all of the laptops 100% identical as far as hardware is
 central to this plan.  I know I'm setting myself up for big problems
 otherwise.

 I'm hoping I can emerge every package on my laptop that every other
 laptop needs.  That way I can fix any build problems and update any
 config files right on my own system.  Then I would push config file
 differences to all of the other laptops.  Then each laptop could
 emerge its own stuff unattended.
>>>
>>> I see what you desire now - essentially you want to clone your laptop
>>> (or big chunks of it) over to your other workstations.
>>
>> That sounds about right.
>>
>>> To get a feel for how it works, visit puppet's web site and download
>>> some of the test appliances they have there and run them in vm software.
>>> Set up a server and a few clients, and start experimenting in that
>>> sandbox. You'll quickly get a feel for how it all hangs together (it's
>>> hard to describe in text how puppet gets the job done, so much easier to
>>> do it for real and watch the results)
>>
>> Puppet seems like overkill for what I need.  I think all I really need
>> is something to manage config file differences and user accounts.  At
>> this point I'm thinking I shouldn't push packages themselves, but
>> portage config files and then let each laptop emerge unattended based
>> on those portage configs.  I'm going to bring this to the 'salt'
>> mailing list to see if it might be a good fit.  It seems like a much
>> lighter weight application.
>
> Two general points I can add:
>
> 1. Sharing config files turns out to be really hard. By far the easiest
> way is to just share /etc but that is an all or nothing approach, and
> you just need one file to be different to break it. Like /etc/hostname
>
> You *could* create a "share" directory inside /etc and symlink common
> files in there, but that gets very tedious quickly.
>
> Rather go for a centralized repo solution that pushes configs out, you
> must just find the one that's right for you.

Does using puppet or salt to push configs from my laptop qualify as a
centralized repo solution?

> 2. Binary packages are almost perfect for your needs IMHO, running
> emerge gets very tedious quickly, and your spec is that all workstations
> have the same USE. You'd be amazed how much time you save by doing this:
>
> emerge -b on your laptop and share your /var/packages
> emerge -K on the workstations when your laptop is on the network
>
> step 2 goes amazingly quickly - eyeball the list to be emerged, they
> should all be purple, press enter. About a minute or two per
> workstation, as opposed to however many hours the build took.

The thing is my laptop goes with me all over the place and is very
rarely on the same network as the bulk of the laptop clients.  Most of
the time I'm on a tethered and metered cell phone connection
somewhere.  Build time itself really isn't a big deal.  I can have the
clients update overnight.  Whether the clients emerge or emerge -K is
the same amount of admnistrative work I would think.

> 3. (OK, three points). Share your portage tree over the network. No
> point in syncing multiple times when you actually just need to do it once.

Yep, I figure each physical location should designate one system to
host the portage tree and distfiles.

- Grant

Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim

[Mark David Dumlao]

On Tue, Oct 1, 2013 at 1:11 PM, Mark David Dumlao  wrote:
> On Tue, Oct 1, 2013 at 7:21 AM, Francisco Blas Izquierdo Riera
> (klondike)  wrote:
 Ohh and BTW, /usr was not just added because someone added a harddrive,
 in most cases it was used to allow machines contain a very small system
 on / which was enough to just boot and mount a networked system (/usr)
 containing most of the software. This allowed for cheaper deployment of
 machines since the hard drive could be smaller as it wouldn't need to
 have all the data locally. Yeah, if this sounds familiar is because this
 was later moved to initramfs.
>>> no, network'ed file systems came a lot later.
>>> Initially /usr was added because one harddisk was full. Really, that is
>>> the whole reason for its (broken) existance.
>> Please provide some reference about "Initially /usr was added because
>> one harddisk was full." without it your statement is moot to me.
>>
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Bell Labs notes on Unix. Search for "usr" and you'll notice it was originally
for home directories.

http://cm.bell-labs.com/cm/cs/who/dmr/notes.html

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

Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim

[Mark David Dumlao]

On Tue, Oct 1, 2013 at 7:21 AM, Francisco Blas Izquierdo Riera
(klondike)  wrote:
>>> Ohh and BTW, /usr was not just added because someone added a harddrive,
>>> in most cases it was used to allow machines contain a very small system
>>> on / which was enough to just boot and mount a networked system (/usr)
>>> containing most of the software. This allowed for cheaper deployment of
>>> machines since the hard drive could be smaller as it wouldn't need to
>>> have all the data locally. Yeah, if this sounds familiar is because this
>>> was later moved to initramfs.
>> no, network'ed file systems came a lot later.
>> Initially /usr was added because one harddisk was full. Really, that is
>> the whole reason for its (broken) existance.
> Please provide some reference about "Initially /usr was added because
> one harddisk was full." without it your statement is moot to me.
>

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
-- 
This email is:[ ] actionable   [x] fyi[ ] social
Response needed:  [ ] yes  [x] up to you  [ ] no
Time-sensitive:   [ ] immediate[ ] soon   [x] none

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Bruce Hill]

On Mon, Sep 30, 2013 at 09:47:46PM +0100, Neil Bothwick wrote:
> My desktop
> 
> % df /usr
> Filesystem Type  Size  Used Avail Use% Mounted on
> silastic/usr   zfs32G   15G   17G  48% /usr
> 
> My laptop
> 
> % df /usr
> Filesystem Type  Size  Used Avail Use% Mounted on
> bangbang/usr   zfs16G  9.1G  6.6G  59% /usr
> 
> Both with KDE and LO, but no portage. $PORTDIR is on /var,
> $DISTDIR and $PKGDIR are on an NFS mount.

Do you have some alias causing df output to use -h or how does that work?
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Dale]

Volker Armin Hemmann wrote:
> Am 30.09.2013 22:48, schrieb Dale:
>> Volker Armin Hemmann wrote:
>>> 500gb harddisks are extremely cheap. 150gb for / with usr and you will
>>> be fine for ages. Why are you acting like this is a problem? 
>> Maybe cheap for you but not so for me.  I'm on a fixed income,
>> disabled.  Also, my brother has cancer and I'm taking him to treatments
>> that are about 75 miles away one way.  I'm buying gas since he can't
>> work much if any right now either.  Right now, buying anything computer
>> related is out of the question.  I got much more important things to
>> deal wtih.  I'm certainly not going to be able to do that in the next 30
>> days.  So, computer, Gentoo as well, is pretty low on the priority
>> list.  I suspect I will be bootable for a good while but have a plan B
>> if needed. 
>>
>> Dale
>>
>> :-)  :-)
>>
> you are talking to a person whose income is only slightly above social
> security levels and I am still be able to buy an adequate hdd once in a
> while.
>
>

As I said, I got other more important things to deal with right now.  My
money is going to that not hard drives.

Dale

:-)  :-) 

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

[gentoo-user] Package Create on remote Host

[siefke_listen]

Hello,

i have a Rootserver with Power. Can i built package on this Host and send 
Package  to my Notebooks? Can i built Packages on the Root without local 
install?

I has read about distcc and other way with NFS. But NFS over Network not the 
best and sounds complicate. 

Thank you & Nice Day
Silvio

[gentoo-user] Sloppy sterm screen update over ssh

[Walter Dnes]

  I've recently noticed when ssh'ing into another machine that the xterm
display doesn't fully update.  I.e. there are "holes" where an app
updates over a previous screen.  I've tried Google, but any mention of
"screen" is interpreted as the "screen" utility.

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

Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim

[Francisco Blas Izquierdo Riera (klondike)]

El 30/09/13 00:47, Volker Armin Hemmann escribió:
> Am 29.09.2013 18:41, schrieb Francisco Blas Izquierdo Riera (klondike):
>> El 29/09/13 18:03, Volker Armin Hemmann escribió:
>>> Am 29.09.2013 17:12, schrieb Greg Woodbury:
 On 09/29/2013 07:58 AM, Volker Armin Hemmann wrote:

> things were broken way before that. As much as I hate systemd, it is not
> the root cause of the problem.
>
> The problems were caused by people saying that seperate /usr was a good
> idea, so / would not fill up and similar idiocies. The problems were
> caused by people saying that lvm is a good idea - for desktops. Those
> people who are fighting against the kernel auto assembling raids are to
> blame too.
>
> Systemd is just another point in a very long list.
>
 The usr filesystem was separate from root from the very early days of
 UNIX.  Disks were *tiny* (compared to today) and spreading certain
 things across separate spindles provided major benefits. Certainly,
 the original need to require a separate usr went away fairly quickly,
 but other benefits continued to encourage a seperation between root
 and usr.

>>> in the very early days /usr did not exist in the first space and was
>>> only created because someone added a harddisk.
>>>
>>> Not really a good reason to keep it around.
>> I'm going to show the lack of sense of this argument:
>> in the very early days linux did not exist in the first space and was
>> only created because someone got a 386.
>>
>> Not really a good reason to keep it around.
> wrong analogy and it goes down from here. Really.
Ohh, but they are inspired on YOUR analogy, so guess how wrong yours was.
>> in the very early days GNU did not exist in the first space and was
>> only created because someone jammed a printer.
>>
>> Not really a good reason to keep it around.
>>
>> in the very early days Gentoo did not exist in the first space and was
>> only created because someone added a processor.
>>
>> Not really a good reason to keep it around.
>>
>> in the very early days hardening did not exist in the first space and was
>> only created because someone added security.
>>
>> Not really a good reason to keep it around.
>>
>> in the very early days Gnome did not exist in the first space and was
>> only created because someone got a graphics card.
>>
>> Not really a good reason to keep it around.
>>
>> I'm sure you'll be able to figure out the pattern there.
>>
>> Ohh and BTW, /usr was not just added because someone added a harddrive,
>> in most cases it was used to allow machines contain a very small system
>> on / which was enough to just boot and mount a networked system (/usr)
>> containing most of the software. This allowed for cheaper deployment of
>> machines since the hard drive could be smaller as it wouldn't need to
>> have all the data locally. Yeah, if this sounds familiar is because this
>> was later moved to initramfs.
> no, network'ed file systems came a lot later.
> Initially /usr was added because one harddisk was full. Really, that is
> the whole reason for its (broken) existance.
Please provide some reference about "Initially /usr was added because
one harddisk was full." without it your statement is moot to me.

The setup of a separate /usr on a networked system was used in amongst
other places a few swedish universities.
 The var filesystem was for variable system data, and was never
 terribly big and its inclusion on the root volume happened.  The home
 filesystem  became traditionally separate because data expands to fill
 all availab;e space, and users collect *things*
>>> and a seperate /home does not create any problems.
>>> /var is much more prone to accidentally fill up then /usr ever was.
>> You are jst getting it wrong, /var was kept locally as the data there
>> was supposed to change from machine to machine.
> no, you just don't understand what I wrote.
> People told other people to keep /usr seperate so / may not fill up by
> accident.
>
> That advise always was murky at best. Outright stupid is a good
> description too.
>
> /usr is not prone to much changes. So if your / fits the contents of
> /usr just fine, there is pretty much no risk.
> /var on the other hand tends to explode - but a lot of people never got
> told to put /var on a seperate disk.
>
> If you ever realized that a tens of gigabyte logfile just made your box
> unbootable, you learnt a lot that day.
That's why you move /var/log, not /var
 Networking made it possible to have home entirely off system, and
 diskless worstations ruled for a while as well.

 By the time Linux came along, it had become common for boot volumes to
 not be mounted during normal system operation, but the three
 filesystem layout was common and workable.  As Linux continued to be
 like Topsy (she jest growed!) fragmentation started to occur as
 "distributions" arose.  The "balkanization" of Linux distribution

Re: [gentoo-user] systemd installation location

[Neil Bothwick]

On Tue, 01 Oct 2013 00:14:55 +0200, pk wrote:

> > Your second paragraph reveals that you beleive you already know
> > everything you need to have to boot your system. Now do the same for
> > every possible Gentoo user out there and have it work 100% of the time
> > in ALL valid cases.  
> 
> I *do* know everything I need to have to boot my system. I carefully
> select my hardware and I take particular care of how I set up my system
> thank you very much. But apparently my system is no longer deemed a
> "valid case"... so I'm obviously not a "possible Gentoo user" anymore.

Actually you are. No one said that your setup would no longer work, only
that it would no longer be supported by the devs. Since you know exactly
what you want and how to get it, that shouldn't be a problem as you
support it yourself.

Come November you will be running an unsupported setup, just like I am
now and have been for most of this year. But my system hasn't stopped
working. Well it did once and I had to fix it myself, that's all.


-- 
Neil Bothwick

"A computer is like an Old Testament god, with a lot of rules and no
mercy." -- Joseph Campbell


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01

[Neil Bothwick]

On Mon, 30 Sep 2013 23:05:29 +0100, Mick wrote:

> > > really? so when I moved PORTDIR to /var/portage I was ahead of the
> > > rest? Wow...  
> > 
> > You were ahead of me for sure :-)
> > 
> > I clearly remember one day long long ago you ranted and raved about
> > how a huge chunk of /usr was write-often...
> > 
> > ... so I fiddled with mine to make it work on /var too and was very
> > happy with it.  
> 
> 
> There's no reason to move /usr/portage to /  It can stay in your LVM.

This isn't about moving it to /, it's about moving it to /var, which is a
far more logical location for the portage tree. /usr is for static system
files, /var is for variable data.


-- 
Neil Bothwick

What's the difference between ignorance and apathy?
I don't know and I don't care


signature.asc
Description: PGP signature

Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim

[Neil Bothwick]

On Mon, 30 Sep 2013 17:05:39 -0400, Walter Dnes wrote:

> > If *something1* at boot time requires access to *something2* at boot
> > time that isn't available then I would say that *something1* is broken
> > by design not the *something2*.  
> 
>   What about the case where *something2* *USED TO BE AVAILABLE, BUT HAS
> BEEN MOVED TO /USR* ?

What about the case where something1 wasn't required at boot time but
changed circumstances mean it now is?
 
> > So I would argue that devs relying on /usr always being there have
> > broken the "system".  
> 
>   So I would argue that unnecessarily moving stuff into /usr is
> deliberate sabotage, designed to break *something1*.

Define unnecessarily in that context? You can't, not for all use cases.
There are many files that clearly need to be available early on, and many
more that clearly do not. Between them is a huge grey area, files that
some need and some don't, that may be needed now or at some indeterminate
point in the future. If you put everything that may conceivably be needed
at early boot into /, you shift a large chunk of /usr/*bin/ and /usr/lib*
into /, effectively negating the point of a small, lean /. That puts us
right back where we started, try to define a point of separation that
cannot be defined.

initramfs is the new /, for varying values of new since most distros have
been doing it that way for well over a decade.


-- 
Neil Bothwick

"He's dead, Jim.  You get his phaser, I'll grab his wallet."


signature.asc
Description: PGP signature

Re: [gentoo-user] systemd installation location

[pk]

On 2013-09-30 08:45, Alan McKinnon wrote:

> That is over-simplifying the problem and trivializing it. No-one ever
> said the *everythign* in /usr is criticial for boot.

Is it really over-simplyfying it? How am I supposed to know whatever
comes next? Someone ("upstream") *may* find it boot-critical to have
'Space Invaders' operational during boot. Yes, I say that somewhat
*tounge-in-cheek* but the way things are going I'm not so sure anymore...

> This is the problem:
> 
> a. There exists code used at boot and early-user space time. It is
> critical that this code is available when needed.

I fully understand this and *if* I ever were to install code that I
*knew* had this dependency I would take a serious look if I really
*need* it and only then install it. But it would be up to me to make
that decision and take the necessary steps.

> b. One cannot predict with absolute certainty 100% of the time what
> exactly that critical code is.

In a general manner, no, you are correct... Also, see above
("Invaders")... (And if you don't understand what I'm trying to say, I'm
saying this is as *arbitrary* as it gets - which you, like me, seem to
be opposed to["arbitrariness"])

> c. many reasonable setups turn out to have such critical code in /usr,
> and this cannot be reliably predicted in advance

So I avoid things like Gnome, pulseaudio, systemd and similar stuff like
the plague but I *still* shall be forced to use whatever is dictated by
these things[1]? Don't get me wrong, if anyone wants to install Gnome or
whatever then they should have the restrictions required by it.

> Your second paragraph reveals that you beleive you already know
> everything you need to have to boot your system. Now do the same for
> every possible Gentoo user out there and have it work 100% of the time
> in ALL valid cases.

I *do* know everything I need to have to boot my system. I carefully
select my hardware and I take particular care of how I set up my system
thank you very much. But apparently my system is no longer deemed a
"valid case"... so I'm obviously not a "possible Gentoo user" anymore.

> Do you now see the problem and the fulls cope and impact of it?

I've seen it since *long* before this thread started. The main problem
is lack of resources (because of stupid decisions upstream which puts a
burden on Gentoo devs) and I can't (currently) help much with that other
than through monetary means (donations) but since Gentoo seems to go the
way of the dodo for me (or "assimilated" if you will) then I will take
my leave. For a while now it has only been inertia keeping me here. Or
maybe a hope that things will get better...

[1] And no, I'm not blaming systemd, Gnome or any of the other "pests"
in particular for this...

Best regards

Peter K

Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01

[Mick]

On Monday 30 Sep 2013 20:14:44 Alan McKinnon wrote:
> On 30/09/2013 19:25, Volker Armin Hemmann wrote:
> >>> But... is /usr/portage the default/recommended location? If so, then I
> >>> 
> >>> >> don't think I want to move it - I generally never change defaults
> >>> >> unless there is a very good reason to do so.
> >> > 
> >> > It's /var/portage for new installs. If you want it to be somewhere
> >> > else, just move it and adjust make.conf
> > 
> > really? so when I moved PORTDIR to /var/portage I was ahead of the rest?
> > Wow...
> 
> You were ahead of me for sure :-)
> 
> I clearly remember one day long long ago you ranted and raved about how
> a huge chunk of /usr was write-often...
> 
> ... so I fiddled with mine to make it work on /var too and was very
> happy with it.


There's no reason to move /usr/portage to /  It can stay in your LVM.

-- 
Regards,
Mick


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

Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim

[Walter Dnes]

On Mon, Sep 30, 2013 at 09:40:45PM +0200, pk wrote

> If *something1* at boot time requires access to *something2* at boot
> time that isn't available then I would say that *something1* is broken
> by design not the *something2*.

  What about the case where *something2* *USED TO BE AVAILABLE, BUT HAS
BEEN MOVED TO /USR* ?

> So I would argue that devs relying on /usr always being there have
> broken the "system".

  So I would argue that unnecessarily moving stuff into /usr is
deliberate sabotage, designed to break *something1*.

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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Volker Armin Hemmann]

Am 30.09.2013 22:48, schrieb Dale:
> Volker Armin Hemmann wrote:
>> 500gb harddisks are extremely cheap. 150gb for / with usr and you will
>> be fine for ages. Why are you acting like this is a problem? 
> Maybe cheap for you but not so for me.  I'm on a fixed income,
> disabled.  Also, my brother has cancer and I'm taking him to treatments
> that are about 75 miles away one way.  I'm buying gas since he can't
> work much if any right now either.  Right now, buying anything computer
> related is out of the question.  I got much more important things to
> deal wtih.  I'm certainly not going to be able to do that in the next 30
> days.  So, computer, Gentoo as well, is pretty low on the priority
> list.  I suspect I will be bootable for a good while but have a plan B
> if needed. 
>
> Dale
>
> :-)  :-)
>
you are talking to a person whose income is only slightly above social
security levels and I am still be able to buy an adequate hdd once in a
while.

Re: [gentoo-user] Managing multiple systems with identical hardware

[Neil Bothwick]

On Mon, 30 Sep 2013 21:31:18 +0200, Alan McKinnon wrote:

> > I'm soaking up a lot of your time (again).  I'll return with any real
> > Gentoo questions I run into and to run down the final plan before I
> > execute it.  Thanks so much for your help.  Not sure what I'd do
> > without you. :)  
> 
> I'm sure Neil would step in if I'm hit by a bus
> He'd say the same things, and use about 1/4 of the words it takes me ;-)

So far in this thread, I've managed about 0/4 of the words you've used...
Oh damn!

But yes, a build host and adding --usepkg=y to EMERGE_DEFAULT_OPTS in
make.conf gives a massive speed increase. Run the build host in an easily
recovered environment, like a VM, and you don't even have to monitor the
world update on it, just run a script in the early hours that does emerge
--sync && emerge -uXX @world and check your mailbox for errors before
running emerge on the "clients". The use clusterssh or dsh to update them
all at once.


-- 
Neil Bothwick

Q. How many radical feminists does it take to change a light bulb?
A. Two - one to change the bulb and one to write a book about the passive
role of the socket.


signature.asc
Description: PGP signature

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Neil Bothwick]

On Mon, 30 Sep 2013 18:38:36 +0200, Dan Johansson wrote:

> I agree to 100% with you Dale. I have /usr on a separate LVM partition
> (I only have, as you, / and /boot on regular partitions) to be able to
> easily extend it (which I have been forced to do a few times).
> And as my VG-partition starts directly after the /-partition I am not in
> the position to extend / to "engulf" all the data in /usr.

It's possible, even without an external drive, but a fair bit more work,
provided you have enough free space in your VG to be able to reduce it.


-- 
Neil Bothwick

GOTO: (n.) an efficient and general way of controlling a program, much
despised by academics and others whose brains have been ruined by
overexposure to Pascal.


signature.asc
Description: PGP signature

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Dale]

Volker Armin Hemmann wrote:
> 500gb harddisks are extremely cheap. 150gb for / with usr and you will
> be fine for ages. Why are you acting like this is a problem? 

Maybe cheap for you but not so for me.  I'm on a fixed income,
disabled.  Also, my brother has cancer and I'm taking him to treatments
that are about 75 miles away one way.  I'm buying gas since he can't
work much if any right now either.  Right now, buying anything computer
related is out of the question.  I got much more important things to
deal wtih.  I'm certainly not going to be able to do that in the next 30
days.  So, computer, Gentoo as well, is pretty low on the priority
list.  I suspect I will be bootable for a good while but have a plan B
if needed. 

Dale

:-)  :-)

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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Neil Bothwick]

On Mon, 30 Sep 2013 13:25:57 -0400, Tanstaafl wrote:

> On 2013-09-30 1:10 PM, Volker Armin Hemmann
>  wrote:
> > 150gb for / with usr and you will be fine for ages.
> 
> I'm curious what a common/average size is for desktops...
> 
> My /usr, without portage files, is @ 5GB.
> 
> My current / is only 83M, so even after I merge /usr into it, it will 
> still be only @ 5GB...
> 
> But, this is a server, so...
> 
> For an average desktop, loaded with software (say, KDE, Libreoffice, 
> etc), how much will /usr grow to? Or more specifically, what is a 
> *reasonable* maximum one could expect?
> 
My desktop

% df /usr
Filesystem Type  Size  Used Avail Use% Mounted on
silastic/usr   zfs32G   15G   17G  48% /usr

My laptop

% df /usr
Filesystem Type  Size  Used Avail Use% Mounted on
bangbang/usr   zfs16G  9.1G  6.6G  59% /usr

Both with KDE and LO, but no portage. $PORTDIR is on /var,
$DISTDIR and $PKGDIR are on an NFS mount.


-- 
Neil Bothwick

"There are some ideas so idiotic that only an intellectual could believe
them" George Orwell


signature.asc
Description: PGP signature

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Dan Johansson]

On 30.09.2013 20:09, Mark David Dumlao wrote:
> Peeps using LVM:
> If, right now, you were forced to boot into /, without /usr, would you
> be able to manually assemble your usr using pv/vg/lv tools - without
> the assistance of udev?

Sure can!!!



-- 
Dan Johansson, 
***
This message is printed on 100% recycled electrons!
***


0x2FB894AD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 30.09.2013 20:23, schrieb Stefan G. Weichinger:

> [ 1747.393960] hpet1: lost 2 rtc interrupts
> [ 1747.452994] hpet1: lost 1 rtc interrupts
> [ 1747.481786] hpet1: lost 1 rtc interrupts
> [ 1747.527556] hpet1: lost 1 rtc interrupts
> [ 1747.660527] hpet1: lost 1 rtc interrupts
> [ 1747.726264] hpet1: lost 1 rtc interrupts
> 
> 
> :-(
> 
> I would be very happy to get some hints how to debug this ...

booted with "hpet=disable" ... so far no more lost interrupts in dmesg.

I will simply let the scp take its time over night ... and I hope the
KVM-performance will be OK when I start the converted VM.

S

Re: [gentoo-user] Managing multiple systems with identical hardware

[Frank Steinmetzger]

On Mon, Sep 30, 2013 at 09:31:18PM +0200, Alan McKinnon wrote:

> >> (or big chunks of it) over to your other workstations.
> > 
> > Puppet seems like overkill for what I need.  I think all I really need
> > is something to manage config file differences and user accounts.  At
> > this point I'm thinking I shouldn't push packages themselves, but
> > portage config files and then let each laptop emerge unattended based
> > on those portage configs.  I'm going to bring this to the 'salt'
> > mailing list to see if it might be a good fit.  It seems like a much
> > lighter weight application.
> 
> Two general points I can add:
> 
> 1. Sharing config files turns out to be really hard. By far the easiest
> way is to just share /etc but that is an all or nothing approach, and
> you just need one file to be different to break it. Like /etc/hostname
> 
> You *could* create a "share" directory inside /etc and symlink common
> files in there, but that gets very tedious quickly.

How about using something like unison? I've been using it for a while
now to sync a specific subset of ~ between three computers.
It allows for exclude rules for host-specific stuff.
-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any Facebook service.

No, you *can’t* call 999 now.  I’m downloading my mail.


signature.asc
Description: Digital signature

Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim

[pk]

On 2013-09-30 09:32, Alan McKinnon wrote:

> I never mentioned /var at all.
> 
> Go back and read again what I did write.

I'm quite aware what you wrote. If you only read what I wrote... English
is not my native language but the word *may* surely cannot be
misunderstood? Ok, I'll make it simple:

If *something1* at boot time requires access to *something2* at boot
time that isn't available then I would say that *something1* is broken
by design not the *something2*.

So I would argue that devs relying on /usr always being there have
broken the "system".

Best regards

Peter K

Re: [gentoo-user] Managing multiple systems with identical hardware

[Alan McKinnon]

On 30/09/2013 19:31, Grant wrote:
>>> Keeping all of the laptops 100% identical as far as hardware is
>>> central to this plan.  I know I'm setting myself up for big problems
>>> otherwise.
>>>
>>> I'm hoping I can emerge every package on my laptop that every other
>>> laptop needs.  That way I can fix any build problems and update any
>>> config files right on my own system.  Then I would push config file
>>> differences to all of the other laptops.  Then each laptop could
>>> emerge its own stuff unattended.
>>
>> I see what you desire now - essentially you want to clone your laptop
>> (or big chunks of it) over to your other workstations.
> 
> That sounds about right.
> 
>> To get a feel for how it works, visit puppet's web site and download
>> some of the test appliances they have there and run them in vm software.
>> Set up a server and a few clients, and start experimenting in that
>> sandbox. You'll quickly get a feel for how it all hangs together (it's
>> hard to describe in text how puppet gets the job done, so much easier to
>> do it for real and watch the results)
> 
> Puppet seems like overkill for what I need.  I think all I really need
> is something to manage config file differences and user accounts.  At
> this point I'm thinking I shouldn't push packages themselves, but
> portage config files and then let each laptop emerge unattended based
> on those portage configs.  I'm going to bring this to the 'salt'
> mailing list to see if it might be a good fit.  It seems like a much
> lighter weight application.

Two general points I can add:

1. Sharing config files turns out to be really hard. By far the easiest
way is to just share /etc but that is an all or nothing approach, and
you just need one file to be different to break it. Like /etc/hostname

You *could* create a "share" directory inside /etc and symlink common
files in there, but that gets very tedious quickly.

Rather go for a centralized repo solution that pushes configs out, you
must just find the one that's right for you.

2. Binary packages are almost perfect for your needs IMHO, running
emerge gets very tedious quickly, and your spec is that all workstations
have the same USE. You'd be amazed how much time you save by doing this:

emerge -b on your laptop and share your /var/packages
emerge -K on the workstations when your laptop is on the network

step 2 goes amazingly quickly - eyeball the list to be emerged, they
should all be purple, press enter. About a minute or two per
workstation, as opposed to however many hours the build took.

3. (OK, three points). Share your portage tree over the network. No
point in syncing multiple times when you actually just need to do it once.


> 
> I'm soaking up a lot of your time (again).  I'll return with any real
> Gentoo questions I run into and to run down the final plan before I
> execute it.  Thanks so much for your help.  Not sure what I'd do
> without you. :)

I'm sure Neil would step in if I'm hit by a bus
He'd say the same things, and use about 1/4 of the words it takes me ;-)


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

Re: [gentoo-user] Managing multiple systems with identical hardware

[thegeezer]

On 09/30/2013 06:31 PM, Grant wrote:
>>> Keeping all of the laptops 100% identical as far as hardware is
>>> central to this plan.  I know I'm setting myself up for big problems
>>> otherwise.
>>>
>>> I'm hoping I can emerge every package on my laptop that every other
>>> laptop needs.  That way I can fix any build problems and update any
>>> config files right on my own system.  Then I would push config file
>>> differences to all of the other laptops.  Then each laptop could
>>> emerge its own stuff unattended.
>> I see what you desire now - essentially you want to clone your laptop
>> (or big chunks of it) over to your other workstations.
> That sounds about right.
>
>> To get a feel for how it works, visit puppet's web site and download
>> some of the test appliances they have there and run them in vm software.
>> Set up a server and a few clients, and start experimenting in that
>> sandbox. You'll quickly get a feel for how it all hangs together (it's
>> hard to describe in text how puppet gets the job done, so much easier to
>> do it for real and watch the results)
> Puppet seems like overkill for what I need.  I think all I really need
> is something to manage config file differences and user accounts.  At
> this point I'm thinking I shouldn't push packages themselves, but
> portage config files and then let each laptop emerge unattended based
> on those portage configs.  I'm going to bring this to the 'salt'
> mailing list to see if it might be a good fit.  It seems like a much
> lighter weight application.
>
> I'm soaking up a lot of your time (again).  I'll return with any real
> Gentoo questions I run into and to run down the final plan before I
> execute it.  Thanks so much for your help.  Not sure what I'd do
> without you. :)
>
> - Grant
>
maybe someone could chip in re: experience with distributed compilation
and cached compiles?
https://wiki.gentoo.org/wiki/Distcc
http://ccache.samba.org/

this may be closer to what you are looking for ?

Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 19:25, Volker Armin Hemmann wrote:
>>> But... is /usr/portage the default/recommended location? If so, then I
>>> >> don't think I want to move it - I generally never change defaults unless
>>> >> there is a very good reason to do so.
>> > It's /var/portage for new installs. If you want it to be somewhere else,
>> > just move it and adjust make.conf
>> >
>> >
> really? so when I moved PORTDIR to /var/portage I was ahead of the rest?
> Wow...
> 


You were ahead of me for sure :-)

I clearly remember one day long long ago you ranted and raved about how
a huge chunk of /usr was write-often...

... so I fiddled with mine to make it work on /var too and was very
happy with it.



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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 19:25, Tanstaafl wrote:
> On 2013-09-30 1:10 PM, Volker Armin Hemmann 
> wrote:
>> 150gb for / with usr and you will be fine for ages.
> 
> I'm curious what a common/average size is for desktops...
> 
> My /usr, without portage files, is @ 5GB.
> 
> My current / is only 83M, so even after I merge /usr into it, it will
> still be only @ 5GB...
> 
> But, this is a server, so...
> 
> For an average desktop, loaded with software (say, KDE, Libreoffice,
> etc), how much will /usr grow to? Or more specifically, what is a
> *reasonable* maximum one could expect?
> 


The big space hogs are:

/usr/lib*
/usr/share/

most of that comes from KDE and Gnome. Both systems are huge and bundle
lots of "accessory" files - best descriptive word I could find.

The main culprit by far is artwork - themes, wallpaper, sound themes,
icon collections and so on. Second is marble, celestia and similar geo*
type apps with their maps.

I'd say 20G total is a) lots more than you'd actually need even with
tons of unneeded artwork and b) a tiny fraction of the smallest
(spinning) disk you can buy these days.

So 20G is a good upper limit to start with. Marble and celestia users
can bump it up according to their needs - anyone who has detailed maps
of the entire Earth's land surface likely already knows how much disk
space it takes up :-)

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

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 30.09.2013 19:07, schrieb Volker Armin Hemmann:
> Am 30.09.2013 11:54, schrieb Stefan G. Weichinger:
>> Am 29.09.2013 16:37, schrieb Stefan G. Weichinger:
>>> Am 27.09.2013 17:55, schrieb Volker Armin Hemmann:
>>>
> What direction to go? force or disable HPET?
>
>
 neither
>>> And what to do to avoid those lost interrupts?
>> Is there no good suggestion for this?
>>
>>
>>
>>
>>
> let the kernel figure out the best clocksource for you?
> 
> if you have a real problem with lost interrupts, go to lkml.

After reboot without any clocksource options it still choses hpet and it
still shows:

[ 1747.393960] hpet1: lost 2 rtc interrupts
[ 1747.452994] hpet1: lost 1 rtc interrupts
[ 1747.481786] hpet1: lost 1 rtc interrupts
[ 1747.527556] hpet1: lost 1 rtc interrupts
[ 1747.660527] hpet1: lost 1 rtc interrupts
[ 1747.726264] hpet1: lost 1 rtc interrupts


:-(

I would be very happy to get some hints how to debug this ...

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Mark David Dumlao]

On Tue, Oct 1, 2013 at 12:38 AM, Dan Johansson  wrote:
> On 29.09.2013 20:25, Dale wrote:
>> Simple, I have never had to resize / or /boot before.  I have had to
>> resize /usr, /var and /home several times tho.  THAT is the reason.  For
>> me, it doesn't matter if it is rational to YOU or not.  I am the one
>> doing things on my puter not you or anyone else.  If the init thingy
>> fails, that will be me staring at a error message, not you.
>
> I agree to 100% with you Dale. I have /usr on a separate LVM partition
> (I only have, as you, / and /boot on regular partitions) to be able to
> easily extend it (which I have been forced to do a few times).
> And as my VG-partition starts directly after the /-partition I am not in
> the position to extend / to "engulf" all the data in /usr.

Peeps using LVM:
If, right now, you were forced to boot into /, without /usr, would you
be able to manually assemble your usr using pv/vg/lv tools - without
the assistance of udev?

The gentoo warning is simply saying that they don't have enough people
to devote to debugging problems where that happens. So if you so love
your / rescue systems, you can make a very early init script - before udev -
that mounts /usr. And you could host it on an overlay if you want or
submit it into gentoo bugzilla as a proposal.

It isn't unsupported in that they're going to make sure it doesn't work.
It's unsupported in that they don't have the resources to fix bugs caused by
that.

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

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 30.09.2013 19:46, schrieb Bruce Hill:
> On Mon, Sep 30, 2013 at 07:36:35PM +0200, Stefan G. Weichinger wrote:
>>
>> What is the best way to transfer multi-GB-files in LAN? I don't really
>> need encryption here ...
> 
> Did not mention rsync has:
> -n, --dry-run   perform a trial run with no changes made
> 
> as well as many other options..."man rsync".

Thanks for both replies ... I know all these options already and use
them regularly ...   exactly these commands stall after a while and get
really slow throughput.

I am currently rebooting the upgraded machine ...

Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 2:24 PM, pk  wrote:
> On 2013-09-30 04:05, Mark David Dumlao wrote:
>> are the same. Distro packagers, however, have to decide for 100% of the 
>> cases.
>> So they're going to end up making weird decisions that are easy for you to
>> second-guess but are actually tough.
>
> That's only true for binary distros.

That is not true. Even in source-based distros like gentoo, distro packagers
decide where the files go. So far, it's only in a completely from scratch *nix
environment where the end user gets to decide where files go.

And "where do the files go" is pretty much what made this problem be apparent.
Many packages with udev rules depend on programs, resources, libraries in /usr.
It is _not_ trivial to fix those packages. If _you_ think it is, I recommend you
replace the entire gentoo bugzilla community because you are clearly a
rockstar bugfixer.

>
>> If you want to solve the "hard problem", you want to create a tool that
>> will automate / and /usr migrations. Portage has to be aware of the tool
>
> What's wrong with using autotools? I really don't see why you need it to
> be dynamic. In Gentoo you install stuff once for every version (or if
> you change use flag). Why invent stuff/complicate matters when you don't
> need to?
>

You do not really understand the scope of the problem.

The problem is that "boot critical" is subjective to the system. A program that
is "boot critical" for one system may not be "boot critical" for another. But
where software gets installed is generally "hard coded" into packages
(defaulting to /usr). That is the status quo.

Because of this, the package manager simply does not have enough
information on whether a package is boot critical or not. It is not part of
the ebuild. It is not part of the emerge switches. Not only that, whether a
package is boot critical or not could change at any time. nfs-utils are only
boot critical if you use nfs. ssh is only boot critical if you use sshfs.
Perl is only boot critical if you have a startup script that counts the number
of virgins you've sacrificed to the goat god. Making a filesystem boot-critical
is something that the package manager does not and cannot track. Autotools
also cannot track it as it happens outside of compile time.

If you want the / and /usr separation nonsense solved, you should write a
program that can "mark" a binary as boot-critical. It will then copy the binary
and all of its libraries to /, and copy and rebuild any dependencies into / as
well. It must be a full copy, otherwise the promise that /usr can be shared
will be violated. Everytime that package is rebuilt, it must be built and copied
into _both_ / and /usr. Your program should also be able to unmark a binary
as boot critical and thus delete any copies in /

Your program should be understood by portage, or at least run as a portage
hook. Copy paste that to all package managers as well.

What's more, any program depending on a boot critical program must be
rewritten so that it looks for the program in the correct path. For backwards
compatibility, a "boot critical" program should generate\ symlinks in the
/ filesystem's /usr tree (the normally empty directory shadowed by the /usr
filesystem), so that if the /usr filesystem is not available any programs
depending on that program would still work.

That program is writable in theory. It's VERY tedious to write it, much less
test that it works.
-- 
This email is:[ ] actionable   [x] fyi[ ] social
Response needed:  [ ] yes  [x] up to you  [ ] no
Time-sensitive:   [ ] immediate[ ] soon   [x] none

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Bruce Hill]

On Mon, Sep 30, 2013 at 07:36:35PM +0200, Stefan G. Weichinger wrote:
> 
> What is the best way to transfer multi-GB-files in LAN? I don't really
> need encryption here ...

Did not mention rsync has:
-n, --dry-run   perform a trial run with no changes made

as well as many other options..."man rsync".
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Bruce Hill]

On Mon, Sep 30, 2013 at 07:36:35PM +0200, Stefan G. Weichinger wrote:
> 
> What is the best way to transfer multi-GB-files in LAN? I don't really
> need encryption here ...

My choice is always "rsync -av /source/ user@IP:~/destination/" because it
won't copy a corrupt file. Make sure you understand the use of slash first.
And the -av is going to preserve timestamps and give you verbose output. If
you also want to see status of your copying add --progress.
-- 
Happy Penguin Computers   >')
126 Fenco Drive   ( \
Tupelo, MS 38801   ^^
supp...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Volker Armin Hemmann]

Am 30.09.2013 19:25, schrieb Tanstaafl:
> On 2013-09-30 1:10 PM, Volker Armin Hemmann
>  wrote:
>> 150gb for / with usr and you will be fine for ages.
>
> I'm curious what a common/average size is for desktops...
>
> My /usr, without portage files, is @ 5GB.
>
> My current / is only 83M, so even after I merge /usr into it, it will
> still be only @ 5GB...
>
> But, this is a server, so...
>
> For an average desktop, loaded with software (say, KDE, Libreoffice,
> etc), how much will /usr grow to? Or more specifically, what is a
> *reasonable* maximum one could expect?
>
>

my whole / with KDE, libreoffice, ut2004 in /opt and /usr/src having
several linux versions in it but without PORTDIR is:
/dev/root59G 33G   24G   58% /
10G are /opt
18G are /usr
5.4G are /usr/src

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 30.09.2013 19:07, schrieb Volker Armin Hemmann:
> Am 30.09.2013 11:54, schrieb Stefan G. Weichinger:
>> Am 29.09.2013 16:37, schrieb Stefan G. Weichinger:
>>> Am 27.09.2013 17:55, schrieb Volker Armin Hemmann:
>>>
> What direction to go? force or disable HPET?
>
>
 neither
>>> And what to do to avoid those lost interrupts?
>> Is there no good suggestion for this?
>>
>>
>>
>>
>>
> let the kernel figure out the best clocksource for you?
> 
> if you have a real problem with lost interrupts, go to lkml.

I am gonna reboot the system without forcing any clocksource after my
current "emerge -e @system" (I did that to fit the transferred VM-image
to the given hardware/CPU). And I will maybe upgrade to 3.10.7-r1 as well.

What is the best way to transfer multi-GB-files in LAN? I don't really
need encryption here ...

thanks, Stefan

Re: [gentoo-user] Managing multiple systems with identical hardware

[Grant]

>> Keeping all of the laptops 100% identical as far as hardware is
>> central to this plan.  I know I'm setting myself up for big problems
>> otherwise.
>>
>> I'm hoping I can emerge every package on my laptop that every other
>> laptop needs.  That way I can fix any build problems and update any
>> config files right on my own system.  Then I would push config file
>> differences to all of the other laptops.  Then each laptop could
>> emerge its own stuff unattended.
>
> I see what you desire now - essentially you want to clone your laptop
> (or big chunks of it) over to your other workstations.

That sounds about right.

> To get a feel for how it works, visit puppet's web site and download
> some of the test appliances they have there and run them in vm software.
> Set up a server and a few clients, and start experimenting in that
> sandbox. You'll quickly get a feel for how it all hangs together (it's
> hard to describe in text how puppet gets the job done, so much easier to
> do it for real and watch the results)

Puppet seems like overkill for what I need.  I think all I really need
is something to manage config file differences and user accounts.  At
this point I'm thinking I shouldn't push packages themselves, but
portage config files and then let each laptop emerge unattended based
on those portage configs.  I'm going to bring this to the 'salt'
mailing list to see if it might be a good fit.  It seems like a much
lighter weight application.

I'm soaking up a lot of your time (again).  I'll return with any real
Gentoo questions I run into and to run down the final plan before I
execute it.  Thanks so much for your help.  Not sure what I'd do
without you. :)

- Grant

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Tanstaafl]

On 2013-09-30 1:10 PM, Volker Armin Hemmann  
wrote:

150gb for / with usr and you will be fine for ages.


I'm curious what a common/average size is for desktops...

My /usr, without portage files, is @ 5GB.

My current / is only 83M, so even after I merge /usr into it, it will 
still be only @ 5GB...


But, this is a server, so...

For an average desktop, loaded with software (say, KDE, Libreoffice, 
etc), how much will /usr grow to? Or more specifically, what is a 
*reasonable* maximum one could expect?

Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01

[Volker Armin Hemmann]

Am 30.09.2013 11:00, schrieb Alan McKinnon:
> On 30/09/2013 00:53, Tanstaafl wrote:
>> On 2013-09-29 5:15 PM, Alan McKinnon  wrote:
>>> Those numbers are not likely to change much with time, with one
>>> exception:
>>>
>>> /usr/src
>>>
>>> That can get real big real quick if you don't clean up kernel sources
>>> often. Ideally, you'd make that a suitably sized LV and mount it
>>> seperately.
>> Yeah, I always keep 2 or 3 known good kernels, and clean out the old
>> stuff, so no worries there.
>>
>>> The other space consumer is /usr/share with it's many documentation
>>> files. But those too tend to be stable once you have everything
>>> installed. 5G free out of 19G is ~75% space in use which is perfectly
>>> acceptable for this case.
>>>
>>> Regular monitoring of the state of your machines will tell you if space
>>> usage increases so you can investigate and deal with it timeously.
>>>
>>> I assume you long since moved portage and it's storage directories out
>>> of /usr into /var?
>> Hmmm... No, I never did that myself...
>>
>> Wow...
>>
>> moria : Sun Sep 29, 18:19:01 : ~
>>  # du -sh /usr/*
>> 85M /usr/bin
>> 131M/usr/include
>> 0   /usr/lib
>> 11M /usr/lib32
>> 530M/usr/lib64
>> 51M /usr/libexec
>> 15M /usr/local
>> 7.8G/usr/portage
>> 21M /usr/sbin
>> 509M/usr/share
>> 3.9G/usr/src
>> 0   /usr/tmp
>> 7.0M/usr/x86_64-pc-linux-gnu
>> moria : Sun Sep 29, 18:26:30 : ~
>>  #
> Apart from portage and src that all looks totally normal and unlikely to
> vary much over time.
>
>
>
>> Is this the official gentoo way now? Will a new/fresh virgin install
>> have /var/portage instead of /usr/portage?
> The new instaled default is to put all of portage on /var, whilst still
> supporting old installs on /usr. This is no big deal in code, as it's
> really just a string containing a base path
>
>
>> I can eliminate almost 8GB by moving portage and its storage directories...
> Or move them onto a dedictaed LV. This is a case where a different mount
> point makes a lot of sense - we're all aware just how unique the tree is
> in terms of fs performance - thousands of small files mostly smaller
> than 2k in hundreds of directories. It's quite different to everything
> else on /usr or even /var.
>
> Same with distfiles, that too can move anywhere you want it to be, just
> adjust one setting in make.conf
>
>> I don't recall seeing a news item about that...
> IIRC it wasn't a news item as such. Perhaps it was an elog from portage
> itself.
>
>
>> But... is /usr/portage the default/recommended location? If so, then I
>> don't think I want to move it - I generally never change defaults unless
>> there is a very good reason to do so.
> It's /var/portage for new installs. If you want it to be somewhere else,
> just move it and adjust make.conf
>
>
really? so when I moved PORTDIR to /var/portage I was ahead of the rest?
Wow...

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Volker Armin Hemmann]

Am 30.09.2013 01:27, schrieb Dale:
> Tanstaafl wrote:
>> On 2013-09-29 5:35 PM, Dale  wrote:
>>> Tanstaafl wrote:
 Ok, but... everything I've read and personal experience over the years
 shows that space required for /usr should not change much, especially
 constantly grow over time (like requirements for /home can and will)-
 it may fluctuate (increase, decrease) *a little* over time, but it
 definitely should not grow substantially, so, if you had to resize it,
 most likely it is because you simply didn't allocate enough room to
 start with.
>>> So my experience doesn't matter any then?
>> Dale, that is NOT what I said, and nothing I am saying is intended to
>> be offensive.
>>
>>> My /usr does vary and sometimes varies quite a bit.
>> The question you should be asking yourself then, is WHY?
> To me, it doesn't matter why it varies, it just does.  After each
> update, I check to see what the partitions look like.  The biggest
> change was going from KDE3 to KDE4.  That seemed to make things grow a
> good bit.  Other things I install/uninstall seem to change things too.
>
>>> That is why I had to resize the thing. Saying that I didn't make it
>>> large enough to begin with isn't the point.
>> It is precisely the point...
>>
>> The fact is, there is nothing in there that *should* vary much (once
>> your system is fully installed) - unless you are using it in some
>> non-standard way, and/or not occasionally cleaning out /usr/src (as
>> Alan pointed out)... and if either of those is the case, then as I
>> said, it is your own fault that you needed to resize it.
>>
>> Don't you see how contradictory it is to say that you will change from
>> gentoo to distro-x because gentoo has made a change that requires you
>> to either merge /usr into / or use an 'init thingy', when distro-x,
>> that you say you will change to, USES AN INIT THINGY? Doesn't that
>> sound irrational to you?
> No, it doesn't.  On Gentoo, I HAVE to make the thing but don't know how
> to fix it if it breaks.  On other distros, I don't have to make the
> thing.  If it fails, at worst, I can reinstall in much less time than I
> would spend trying to fix the silly thing.  Since I don't know how to
> fix one and can't boot to get help, then the computer may as well be a
> screen door on a submarine.  As I posted before, if something breaks and
> I can't fix it, I replace it with something else that works.  That could
> be why /usr varies so much too. 
>
>> What would be logical and rational would be to either:
>>
>> a) learn how to use an init thingy (which from some more reading I've
>> been doing, doesn't look quite as bad as it seemed initially), or
>>
>> b) determine what is a sane size for /usr, make / an appropriate size
>> to subsume it, and merge it into /.
>>
>> Now, if you don't have enough room in / to merge it, then obviously it
>> will be more painful, but once it is done, you never have to worry
>> about it again - and no init thingy.
> Actually, history proves that wrong too.  I started using LVM because I
> got tired of having to rearrange my partitions and resize things.  That
> was the whole reason I switched to LVM when I did.  Ask anyone on this
> list that has been here long ehough.  I have had to move things around
> LOTS of times because things grow including /usr and /var.  /home is a
> different and unrelated thing.  Funny thing is, I did it several times
> and never even posted about it. 
>
>>> When people use LVM, the reason they use it is so that we can resize
>>> things when needed.
>> Yes, and I use LVM - but again, this is only important for dirs/mnt
>> points that have the potential to consume more and more disk space...
>> that potential is simply not there for (a properly configured and
>> maintained) /usr...
> See above. 
>
>>> And what is rational for you, is not rational to me.  Since you can
>>> dismiss mine, I can dismiss yours too.   Funny how that works huh?
>> Yep... and you can also dismiss my claim that jumping off that 1,000'
>> cliff won't result in you going splat, but it doesn't change the fact
>> that if you jump off of it, you WILL go splat. I just wouldn't get the
>> chance to say I told you so.
>>
>>
> And what you are saying is not changing anything either.  I don't want
> to mess with the init thingy.  If I do, first time it fails and a
> solution isn't obvious, time to move on to something else.  I like my 16
> year old washing machine and I have repaired things on it a few times. 
> If it breaks and I can't fix it, time for a new washing machine.  Most
> likely, a different brand and model too. 
>
> Dale
>
> :-)  :-) 
>

500gb harddisks are extremely cheap.
150gb for / with usr and you will be fine for ages.

Why are you acting like this is a problem?

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Volker Armin Hemmann]

Am 30.09.2013 11:54, schrieb Stefan G. Weichinger:
> Am 29.09.2013 16:37, schrieb Stefan G. Weichinger:
>> Am 27.09.2013 17:55, schrieb Volker Armin Hemmann:
>>
 What direction to go? force or disable HPET?


>>> neither
>> And what to do to avoid those lost interrupts?
> Is there no good suggestion for this?
>
>
>
>
>
let the kernel figure out the best clocksource for you?

if you have a real problem with lost interrupts, go to lkml.

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Dan Johansson]

On 29.09.2013 20:25, Dale wrote:
> Tanstaafl wrote:
>> On 2013-09-29 11:24 AM, Dale  wrote:
>>> Tanstaafl wrote:
 Dale - I'm honestly curious, what is your reason, philisophical or
 technical, for wanting a separate /usr?

 Everything I've read says there is no good reason for it today.
 Separate /home, /tmp, /var, yes, good reasons for t hose... but not
 /usr...

 So, again - why would you prefer switching distro's over merging /usr
 back into / and be done with it?
>>
>>> The reason is the same I have posted before.  I have / and /boot on
>>> regular partitions.  Everything else is on LVM.  I don't have / on LVM
>>> because it would require a init thingy.  I don't have /boot on LVM
>>> because grub doesn't or didn't support it.  I have since switched to
>>> grub2 so it may but still have the issue with / so no need redoing
>>> everything for that.
>>
>> Well, I don't see a *reason* to WANT to have /usr on a separate
>> partition. I see only THE reason that you have it there NOW.
>>
>> Also, logically speaking, if the stated reason for not having / (or
>> /boot) on separate LVM partitions is because it would require an init
>> thingy, then why can't you simply add /usr to that reason?
>>
>> Again, I'm asking for why you WANT it on a separate LVM partition, not
>> why it is there now.
>>
>> The way I see it, if y ou cannot provide a rational answer to that
>> question, then  there is no reason for you to use this as a reason to
>> abandon gentoo, only a reason to merge /usr into /...
>>
>>
> 
> Simple, I have never had to resize / or /boot before.  I have had to
> resize /usr, /var and /home several times tho.  THAT is the reason.  For
> me, it doesn't matter if it is rational to YOU or not.  I am the one
> doing things on my puter not you or anyone else.  If the init thingy
> fails, that will be me staring at a error message, not you. 

I agree to 100% with you Dale. I have /usr on a separate LVM partition
(I only have, as you, / and /boot on regular partitions) to be able to
easily extend it (which I have been forced to do a few times).
And as my VG-partition starts directly after the /-partition I am not in
the position to extend / to "engulf" all the data in /usr.

-- 
Dan Johansson, 
***
This message is printed on 100% recycled electrons!
***


0x2FB894AD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

[gentoo-user] Re: systemd installation location

[Martin Vaeth]

pk  wrote:
>
> Seriously, boot-critical would be something that the system cannot *boot
> without*, which belongs in /. Everything else should be in /usr, i.e.
> non-boot-critical. How hard is it to start *non-boot* (system) critical
> *after* boot (things like sshd)? I do that today...

For somebody who uses sshfs-fuse to mount /usr from another machine,
sshd and fuse *are* boot critical. (And yes, this maybe a natural
setup for home systems since in many settings this is more secure
than using nfs for this.)

But even without net-mounting the answer to "how hard is it to start ...
after boot" the answer for modern kernels is: a lot.
Modern kernels initialize modules simulataneously (i.e. in an
unpredictable order). So you would have to remember and postpone these
initializations which can produce all sorts of unexpected problems
if you have complicated implicit dependencies.
Older versions of udev did this in a somewhat primitive way
(restarting failed services again), but obviously this is not
a clean solution (since the failing could have other reasons).

Re: [gentoo-user] poppler - how to update it elegantly?

[Alan McKinnon]

On 30/09/2013 14:37, Helmut Jarausch wrote:
> On 09/30/2013 02:24:40 PM, Alan McKinnon wrote:
>> On 30/09/2013 13:55, Helmut Jarausch wrote:
>> > Hi, my most hated package is poppler. Each time in the past and now
>> > again it's hard to upgrade.
>> >
>> > portage (2.2.7) cannot handle it, so I have to (manually) unmerge all
>> > packages depending on it and emerge them after
>> > the poppler upgrade again.
>> >
>> > Has anybody found a more elegant procedure?
>> >
>> > Many thanks,
>> > Helmut.
>> >
>>
>>
>> poppler packaging is a pita, but it's never broke anything for me (but
>> does cause lots and lots and lots of stuff to be rebuilt...)
>>
>> Yesterday's update worked just fine:
>>
>> $ genlop -t poppler
>>  * app-text/poppler
>>
>>  Wed Sep 18 08:46:05 2013 >>> app-text/poppler-0.24.1
>>merge time: 33 seconds.
>>
>>  Sun Sep 29 12:31:08 2013 >>> app-text/poppler-0.24.2
>>merge time: 35 seconds.
>>
>>
>> What errors are you getting?
>> Any customizations to poppler on your system?
>>(i.e grep -r poppler /etc/portage)
>>
> 
> First, are you using portage-2.2.7?


Yes



> I haven't changed poppler nor its ebuild in any way.
> 
> Here is my problem:
> 
> emerge -vp app-text/poppler
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies   * waiting for lock on
> /var/db/.pkg.portage_lockfile ... [ ok ]
> ... done!
> [ebuild  r  U  ] app-text/poppler-0.24.2:0/43 [0.22.5:0/37] USE="cairo
> cjk cxx introspection jpeg lcms png qt4 tiff utils -curl -debug -doc
> -jpeg2k" 1,470 kB
> [ebuild  rR] net-print/cups-filters-1.0.36-r2  USE="jpeg png tiff
> -perl -static-libs -zeroconf" 0 kB
> [ebuild  rR] dev-tex/luatex-0.76.0  USE="-doc" 0 kB
> [ebuild  rR] app-text/evince-3.8.3:0/evd3.4-evv3.3 
> USE="introspection postscript tiff -debug -djvu -dvi -gnome-keyring
> -nautilus -t1lib -xps" 0 kB
> [ebuild  rR] dev-python/python-poppler-0.12.1-r4  USE="-examples"
> PYTHON_TARGETS="python2_7 -python2_6" 0 kB
> [ebuild  rR] app-office/calligra-2.7.3:4  USE="crypt eigen exif fftw
> fontconfig gif glew glib gsf gsl handbook jpeg jpeg2k kdcraw kdepim lcms
> marble mysql okular opengl pdf ssl threads tiff truetype xbase xml xslt
> (-aqua) -attica -freetds -openexr -opengtl (-postgres) -spacenav
> (-sybase) {-test} -vc -word-perfect" CALLIGRA_FEATURES="author braindump
> flow karbon kexi krita plan sheets stage words" 0 kB
> [ebuild  r  U  ] app-office/libreoffice-4.1.2.2-r1 [4.1.2.2]
> USE="bluetooth branding cups dbus gnome gtk java kde opengl vba webdav
> (-aqua) -debug -eds -gstreamer -gtk3 -jemalloc -mysql -odk -postgres
> -telepathy {-test}" LIBREOFFICE_EXTENSIONS="presenter-minimizer
> -nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher"
> PYTHON_SINGLE_TARGET="python2_7 -python3_3" PYTHON_TARGETS="python2_7
> python3_3" 0 kB
> [ebuild  rR] app-text/texlive-core-2013-r1  USE="X doc tk xetex -cjk
> -source" 0 kB
> [ebuild  rR] app-office/texmaker-4.0.4  0 kB


That all looks quite normal - poppler triggered 8 rebuilds.

Is the problem just on the other machine (this one looks fine)?



> 
> Total: 9 packages (2 upgrades, 7 reinstalls), Size of downloads: 1,470 kB
> 
> and on a different machine portage couldn't resolve blocking itself.
> 
> I'll try this (big) re-emerge later on.
> Thanks,
> Helmut
> 
> 
> 


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

Re: [gentoo-user] poppler - how to update it elegantly?

[Helmut Jarausch]

On 09/30/2013 02:24:40 PM, Alan McKinnon wrote:

On 30/09/2013 13:55, Helmut Jarausch wrote:
> Hi, my most hated package is poppler. Each time in the past and now
> again it's hard to upgrade.
>
> portage (2.2.7) cannot handle it, so I have to (manually) unmerge  
all

> packages depending on it and emerge them after
> the poppler upgrade again.
>
> Has anybody found a more elegant procedure?
>
> Many thanks,
> Helmut.
>


poppler packaging is a pita, but it's never broke anything for me (but
does cause lots and lots and lots of stuff to be rebuilt...)

Yesterday's update worked just fine:

$ genlop -t poppler
 * app-text/poppler

 Wed Sep 18 08:46:05 2013 >>> app-text/poppler-0.24.1
   merge time: 33 seconds.

 Sun Sep 29 12:31:08 2013 >>> app-text/poppler-0.24.2
   merge time: 35 seconds.


What errors are you getting?
Any customizations to poppler on your system?
   (i.e grep -r poppler /etc/portage)



First, are you using portage-2.2.7?
I haven't changed poppler nor its ebuild in any way.

Here is my problem:

emerge -vp app-text/poppler

These are the packages that would be merged, in order:

Calculating dependencies   * waiting for lock on  
/var/db/.pkg.portage_lockfile ... [ ok ]

... done!
[ebuild  r  U  ] app-text/poppler-0.24.2:0/43 [0.22.5:0/37] USE="cairo  
cjk cxx introspection jpeg lcms png qt4 tiff utils -curl -debug -doc  
-jpeg2k" 1,470 kB
[ebuild  rR] net-print/cups-filters-1.0.36-r2  USE="jpeg png tiff  
-perl -static-libs -zeroconf" 0 kB

[ebuild  rR] dev-tex/luatex-0.76.0  USE="-doc" 0 kB
[ebuild  rR] app-text/evince-3.8.3:0/evd3.4-evv3.3   
USE="introspection postscript tiff -debug -djvu -dvi -gnome-keyring  
-nautilus -t1lib -xps" 0 kB
[ebuild  rR] dev-python/python-poppler-0.12.1-r4  USE="-examples"  
PYTHON_TARGETS="python2_7 -python2_6" 0 kB
[ebuild  rR] app-office/calligra-2.7.3:4  USE="crypt eigen exif  
fftw fontconfig gif glew glib gsf gsl handbook jpeg jpeg2k kdcraw  
kdepim lcms marble mysql okular opengl pdf ssl threads tiff truetype  
xbase xml xslt (-aqua) -attica -freetds -openexr -opengtl (-postgres)  
-spacenav (-sybase) {-test} -vc -word-perfect"  
CALLIGRA_FEATURES="author braindump flow karbon kexi krita plan sheets  
stage words" 0 kB
[ebuild  r  U  ] app-office/libreoffice-4.1.2.2-r1 [4.1.2.2]  
USE="bluetooth branding cups dbus gnome gtk java kde opengl vba webdav  
(-aqua) -debug -eds -gstreamer -gtk3 -jemalloc -mysql -odk -postgres  
-telepathy {-test}" LIBREOFFICE_EXTENSIONS="presenter-minimizer  
-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher"  
PYTHON_SINGLE_TARGET="python2_7 -python3_3" PYTHON_TARGETS="python2_7  
python3_3" 0 kB
[ebuild  rR] app-text/texlive-core-2013-r1  USE="X doc tk xetex  
-cjk -source" 0 kB

[ebuild  rR] app-office/texmaker-4.0.4  0 kB

Total: 9 packages (2 upgrades, 7 reinstalls), Size of downloads: 1,470  
kB


and on a different machine portage couldn't resolve blocking itself.

I'll try this (big) re-emerge later on.
Thanks,
Helmut

Re: [gentoo-user] poppler - how to update it elegantly?

[Alan McKinnon]

On 30/09/2013 13:55, Helmut Jarausch wrote:
> Hi, my most hated package is poppler. Each time in the past and now
> again it's hard to upgrade.
> 
> portage (2.2.7) cannot handle it, so I have to (manually) unmerge all
> packages depending on it and emerge them after
> the poppler upgrade again.
> 
> Has anybody found a more elegant procedure?
> 
> Many thanks,
> Helmut.
> 


poppler packaging is a pita, but it's never broke anything for me (but
does cause lots and lots and lots of stuff to be rebuilt...)

Yesterday's update worked just fine:

$ genlop -t poppler
 * app-text/poppler

 Wed Sep 18 08:46:05 2013 >>> app-text/poppler-0.24.1
   merge time: 33 seconds.

 Sun Sep 29 12:31:08 2013 >>> app-text/poppler-0.24.2
   merge time: 35 seconds.


What errors are you getting?
Any customizations to poppler on your system?
   (i.e grep -r poppler /etc/portage)



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

[gentoo-user] poppler - how to update it elegantly?

[Helmut Jarausch]

Hi, my most hated package is poppler. Each time in the past and now  
again it's hard to upgrade.


portage (2.2.7) cannot handle it, so I have to (manually) unmerge all  
packages depending on it and emerge them after

the poppler upgrade again.

Has anybody found a more elegant procedure?

Many thanks,
Helmut.

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 12:32, Joost Roeleveld wrote:
> On Monday 30 September 2013 10:01:32 Alan McKinnon wrote:
>> On 30/09/2013 06:14, Walter Dnes wrote:
>>>   If the udev people had made "net ifnames=0" the default, and allowed
>>>
>>> the small percentage of multi-nic machine admins to set "net.ifnames=1",
>>> this would not have been an issue.  Some corner case exotic setups
>>> require complex solutions... no ifs/ands/ors/buts.  All the complaining
>>> you hear is from the other 99% who's setup worked just fine with the
>>> simple solution, suddenly finding the complex solution rammed down their
>>> throats.
>>
>> No, that is just plain wrong.
>>
>> Having interfaces on a multi-nic host come up as ethX where X is a
>> mostly random number is just so broken it beggars belief. Trust me, it
>> is zero fun when it happens and what makes it even worse if you have no
>> warning at all beforehand.
> 
> I trust you, but on my multi-nic systems, I found a better solution :)
> As I use Xen to virtualize my systems and as I don't want to have multiple 
> network cables running side-by-side, I started using VLANs.
> 
> I know have all the NICs names eth1,eth2,...ethn.
> I throw them all as a bonded network device: bond0 (the other ends go into a 
> switch supporting bonding network ports)
> then on top of that, I have VLANs with distinctive names (lan, dmz, guest, 
> vm,...) and link these as required to different Xen-domains.
> 
> When the network names get renamed suddenly to the "non-predictive" scheme, 
> my 
> system refuses to boot.
> Before that, I would use mac-addresses to link ethx devices to names that 
> make 
> sense to me. (see above for the names)


The worst case that comes to mind was a three zone netflow collector
plus the first nic on our management range.

If you're familiar with old netflow versions you'll know it is UDP from
the router and is touchy about addresses. So we had incoming netflow
from three ranges each hitting a dedicated nic and this all worked
marvellously for years and years.

One day after a routine maintenance window the box came up with all 4
nics scrambled and who knows what was now assigned to what. Forget ssh
to log in and fix it - nothing was listening. That took very senior
sysadmins on site to deal with, the regular maintenance guy was in way
over his head.

Business were OK with losing 15 minutes billing and stats data in a
maintenance window. They were definitely not OK with losing several
hours of it because someone thought assigning names on a
non-deterministic discovery order was a good idea.

One thing about Dell hardware - you always know exactly what each nic is
connected to on the motherboard so with that info the new names are
predictable (consistent is actually the better term). Using MAC
addresses for the same purposes is clunky and unwieldy, the MACs have to
be recorded somewhere and you still don't know which MAC goes with which
physical socket. With bus numbers you do know.


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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Joost Roeleveld]

On Monday 30 September 2013 11:24:58 Neil Bothwick wrote:
> On Mon, 30 Sep 2013 12:16 +0200, Joost Roeleveld wrote:
> > > Installing a new kernel does not magically make the old one break. If
> > > that kernel worked yesterday, it will work today.
> > 
> > Actually, that is not guaranteed.
> > I remember a situation in the past where boot-critical software
> > required a certain minimal kernel-version with specific config-settings.
> > Without those I could not boot.
> 
> I don't see how that is an issue with correctly written ebuilds.
> 
> If you update the kernel, you are increasing the version number and your
> old one will still work.
> 
> If you update the software, the ebuild should detect an unsuitable kernel
> and either warn you or abort.

That is the problem though, the ebuild can't detect that there is an 
unsuitable kernel still available.

> Either way, it is irrelevant whether you are using an initramfs or not.

I agree, my comment was made to point out that a kernel that worked yesterday, 
may no longer work tomorrow.

--
Joost

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 12:27, Daniel Campbell wrote:
> On 09/30/2013 04:31 AM, Alan McKinnon wrote:
>> On 30/09/2013 01:31, Daniel Campbell wrote:
>>
>>
>>> Curious; how is merging two filesystems done? I don't have a separate
>>> /usr and am completely unaffected by this change, but it's somewhat
>>> interesting to me. /usr stores some pretty important data on it, and I
>>> imagine you'd need to mount it somewhere else in order to move the
>>> files from it to /'s /usr dir. Is a Live environment recommended
>>> instead? How would you mitigate the leftover partition, assuming it's
>>> not adjacent to /'s partition?
>>
>>
>> Because /usr is continually in use, boot using a livecd of your choice.
>> In that environment, use fdisk (or whichever *disk you like) to make any
>> changes to partitions you know you will need.
>>
>> Mount your gentoo / somewhere convenient
>> Mount your gentoo /usr somewhere convenient
>>
>> copy the latter over to the former
>> edit fstab
>> reboot
>>
>> It really is just a case of moving a large number of files around, but
>> because those very files are always in use you have to do it in livecd
>> environment.
>>
>> There's no exact checklist one can follow to guarantee a 100% result
>> blindly. Instead, as this is Gentoo, we assume users built their system
>> knowing what they were doing and can appropriately deal with their
>> config themselves. RAID and LVM for example may need attention, but the
>> user is usually equipped to deal with that and knows what t do.
>>
>>
>>>
>>> I don't run an initramfs, thankfully, but I keep a pretty simple
>>> system in terms of filesystems: /, /boot, and /home.
>>>
>>
> My suspicions were mostly correct, then. If the merge is that simple, I
> see no reason not to do it if one doesn't want to roll an initramfs.
> However, I imagine moving partitions around in gparted or something
> similar would be quite a wait if / and /usr weren't adjacent on the drive.

Indeed, this is the part where it can get hairy, and it all totally
depends on how the user decided to lay out their partitions.

Eyeballs and brains form the solution here, not computers and scripts :-)


> 
> Thanks for the simple-but-thorough explanation. :)
> 


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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Joost Roeleveld]

On Monday 30 September 2013 10:01:32 Alan McKinnon wrote:
> On 30/09/2013 06:14, Walter Dnes wrote:
> >   If the udev people had made "net ifnames=0" the default, and allowed
> > 
> > the small percentage of multi-nic machine admins to set "net.ifnames=1",
> > this would not have been an issue.  Some corner case exotic setups
> > require complex solutions... no ifs/ands/ors/buts.  All the complaining
> > you hear is from the other 99% who's setup worked just fine with the
> > simple solution, suddenly finding the complex solution rammed down their
> > throats.
> 
> No, that is just plain wrong.
> 
> Having interfaces on a multi-nic host come up as ethX where X is a
> mostly random number is just so broken it beggars belief. Trust me, it
> is zero fun when it happens and what makes it even worse if you have no
> warning at all beforehand.

I trust you, but on my multi-nic systems, I found a better solution :)
As I use Xen to virtualize my systems and as I don't want to have multiple 
network cables running side-by-side, I started using VLANs.

I know have all the NICs names eth1,eth2,...ethn.
I throw them all as a bonded network device: bond0 (the other ends go into a 
switch supporting bonding network ports)
then on top of that, I have VLANs with distinctive names (lan, dmz, guest, 
vm,...) and link these as required to different Xen-domains.

When the network names get renamed suddenly to the "non-predictive" scheme, my 
system refuses to boot.
Before that, I would use mac-addresses to link ethx devices to names that make 
sense to me. (see above for the names)

--
Joost

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Daniel Campbell]

On 09/30/2013 04:31 AM, Alan McKinnon wrote:
> On 30/09/2013 01:31, Daniel Campbell wrote:
> 
> 
>> Curious; how is merging two filesystems done? I don't have a separate
>> /usr and am completely unaffected by this change, but it's somewhat
>> interesting to me. /usr stores some pretty important data on it, and I
>> imagine you'd need to mount it somewhere else in order to move the
>> files from it to /'s /usr dir. Is a Live environment recommended
>> instead? How would you mitigate the leftover partition, assuming it's
>> not adjacent to /'s partition?
> 
> 
> Because /usr is continually in use, boot using a livecd of your choice.
> In that environment, use fdisk (or whichever *disk you like) to make any
> changes to partitions you know you will need.
> 
> Mount your gentoo / somewhere convenient
> Mount your gentoo /usr somewhere convenient
> 
> copy the latter over to the former
> edit fstab
> reboot
> 
> It really is just a case of moving a large number of files around, but
> because those very files are always in use you have to do it in livecd
> environment.
> 
> There's no exact checklist one can follow to guarantee a 100% result
> blindly. Instead, as this is Gentoo, we assume users built their system
> knowing what they were doing and can appropriately deal with their
> config themselves. RAID and LVM for example may need attention, but the
> user is usually equipped to deal with that and knows what t do.
> 
> 
>>
>> I don't run an initramfs, thankfully, but I keep a pretty simple
>> system in terms of filesystems: /, /boot, and /home.
>>
> 
My suspicions were mostly correct, then. If the merge is that simple, I
see no reason not to do it if one doesn't want to roll an initramfs.
However, I imagine moving partitions around in gparted or something
similar would be quite a wait if / and /usr weren't adjacent on the drive.

Thanks for the simple-but-thorough explanation. :)

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Neil Bothwick]

On Mon, 30 Sep 2013 12:16 +0200, Joost Roeleveld wrote:

> > Installing a new kernel does not magically make the old one break. If
> > that kernel worked yesterday, it will work today.  
> 
> Actually, that is not guaranteed.
> I remember a situation in the past where boot-critical software
> required a certain minimal kernel-version with specific config-settings.
> Without those I could not boot.

I don't see how that is an issue with correctly written ebuilds.

If you update the kernel, you are increasing the version number and your
old one will still work.

If you update the software, the ebuild should detect an unsuitable kernel
and either warn you or abort.

Either way, it is irrelevant whether you are using an initramfs or not.


-- 
Neil Bothwick

"Be strict when sending and tolerant when receiving."
 RFC 1958 - Architectural Principles of the Internet - section 3.9


signature.asc
Description: PGP signature

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Neil Bothwick]

On Mon, 30 Sep 2013 12:01:27 +0200, Hinnerk van Bruinehsen wrote:

> > mount /usr -o remount,ro
> > mkdir /newusr
> > rsync -a /usr/ /new/usr/
> > Comment out /usr line in /etc/fstab
> > mv /usr /oldusr
> > mv /newusr /usr
> > reboot
> > rmdir /oldusr
> >
> > What you do with the old partition is up to you. In this case the
> > discussion was about /usr on LVM, so you just delete it and allocate
> > the space elsewhere when needed.

> You can even leave out the step of creating a new directory and moving
> it later if you bind-mount you rootfs somewhere, e.g. /mnt/gentoo.

Good point.

> You may want to add some parameters to the call to rsync, though (e.g.
> those that preserve permissions, xattrs (especially for SELinux or
> XT-PaX) and owner/group (should be -pogX),

-a covers most if not all of those.

> possibly -x aswell (if you
> have other filesystems under /usr (e.g. a discrete FS for the portage
> tree).

Another good point, one of those things you think of immediately after
hitting Send :(


-- 
Neil Bothwick

Middle-age - because your age starts to show at your middle.


signature.asc
Description: PGP signature

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Joost Roeleveld]

On Sunday 29 September 2013 22:09:35 Alan McKinnon wrote:
> On 29/09/2013 19:59, Tanstaafl wrote:
> > I've been told that this shouldn't be a big deal... while I am a
> > (barely) passable linux sys admin
> 
> Allow me to forward an opinion. The above is not true, not even close.
> 
> Don't knock yourself, you don't deserve it :-)
> 
> In my day job I get to meet many people, and vast fleets of them are
> paid obscene amounts of money to do sysadmin work. I have an unprintable
> opinion of most of these folks (I'm tired of cleaning up after them and
> they mess they leave).

I can imagine some of those opinions, I am certain I have uttered the exact 
same words myself on occasion.

It gets worse when those are the ones holding the root-password and refuse to 
give it to you, even though it is obvious I know how to do things better then 
they do...

> You on the other hand would wipe the floor with easily 95% of those
> clowns. Seriously.
> 
> And that goes for just about everyone else on this list who has been
> around a while.

The list thanks you :)

--
Joost

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Joost Roeleveld]

On Sunday 29 September 2013 19:36:32 Neil Bothwick wrote:
> On Sun, 29 Sep 2013 10:53:26 -0400, Tanstaafl wrote:
> > Precisely. And, it is my understanding (correct me if I'm wrong), that
> > simply keeping your old kernel/initramfs around is NOT a guarantee (it
> > might work - and it might NOT) of being able to fallback to a known
> > working config until you figure it out.
> 
> Installing a new kernel does not magically make the old one break. If
> that kernel worked yesterday, it will work today.

Actually, that is not guaranteed.
I remember a situation in the past where boot-critical software required a 
certain minimal kernel-version with specific config-settings.
Without those I could not boot.

Inconsistencies can, and will, happen on occasion.

--
Joost

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Hinnerk van Bruinehsen]

On Mon, Sep 30, 2013 at 12:57:12AM +0100, Neil Bothwick wrote:
> On Sun, 29 Sep 2013 18:31:37 -0500, Daniel Campbell wrote:
>
> > Curious; how is merging two filesystems done? I don't have a separate
> > /usr and am completely unaffected by this change, but it's somewhat
> > interesting to me. /usr stores some pretty important data on it, and I
> > imagine you'd need to mount it somewhere else in order to move the
> > files from it to /'s /usr dir. Is a Live environment recommended
> > instead? How would you mitigate the leftover partition, assuming it's
> > not adjacent to /'s partition?
>
> For /usr you don't need a live CD, because the contents of /usr shouldn't
> change unless you instal/remove something. You can make sure they don't
> change during the merge by remounting read-only
>
> mount /usr -o remount,ro
> mkdir /newusr
> rsync -a /usr/ /new/usr/
> Comment out /usr line in /etc/fstab
> mv /usr /oldusr
> mv /newusr /usr
> reboot
> rmdir /oldusr
>
> What you do with the old partition is up to you. In this case the
> discussion was about /usr on LVM, so you just delete it and allocate the
> space elsewhere when needed.
>
>

You can even leave out the step of creating a new directory and moving it later
if you bind-mount you rootfs somewhere, e.g. /mnt/gentoo.
You may want to add some parameters to the call to rsync, though (e.g. those
that preserve permissions, xattrs (especially for SELinux or XT-PaX) and
owner/group (should be -pogX), possibly -x aswell (if you have other
filesystems under /usr (e.g. a discrete FS for the portage tree).

This would boil down to:

mount /usr -o remout,ro # just to make sure there are no changes
mount -o bind / /mnt/gentoo
rsync -apogXx /usr/ /mnt/usr/ # possibly fiddle around with the flags
comment out the /usr line in fstab
reboot

if everything's working: delete the old usr-partition (or do with it whatever
you like).

WKR
Hinnerk


signature.asc
Description: Digital signature

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 29.09.2013 16:37, schrieb Stefan G. Weichinger:
> Am 27.09.2013 17:55, schrieb Volker Armin Hemmann:
> 
>>> What direction to go? force or disable HPET?
>>>
>>>
>> neither
> 
> And what to do to avoid those lost interrupts?

Is there no good suggestion for this?

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 01:31, Daniel Campbell wrote:


> Curious; how is merging two filesystems done? I don't have a separate
> /usr and am completely unaffected by this change, but it's somewhat
> interesting to me. /usr stores some pretty important data on it, and I
> imagine you'd need to mount it somewhere else in order to move the
> files from it to /'s /usr dir. Is a Live environment recommended
> instead? How would you mitigate the leftover partition, assuming it's
> not adjacent to /'s partition?


Because /usr is continually in use, boot using a livecd of your choice.
In that environment, use fdisk (or whichever *disk you like) to make any
changes to partitions you know you will need.

Mount your gentoo / somewhere convenient
Mount your gentoo /usr somewhere convenient

copy the latter over to the former
edit fstab
reboot

It really is just a case of moving a large number of files around, but
because those very files are always in use you have to do it in livecd
environment.

There's no exact checklist one can follow to guarantee a 100% result
blindly. Instead, as this is Gentoo, we assume users built their system
knowing what they were doing and can appropriately deal with their
config themselves. RAID and LVM for example may need attention, but the
user is usually equipped to deal with that and knows what t do.


> 
> I don't run an initramfs, thankfully, but I keep a pretty simple
> system in terms of filesystems: /, /boot, and /home.
> 

-- 
Alan McKinnon
Systems Engineer^W Technician
Infrastructure Services
Internet Solutions

+27 11 575 7585


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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Dale]

Alan McKinnon wrote:
> On 30/09/2013 01:08, Dale wrote:
>>> At the end of they day, you don't want to learn how to do it "the hard 
>>> way". So
 do it the easy way and be done with your troubles. If you don't want to do 
 it
 EITHER way fine, but stop pretending that it's anything else but a problem
 with your attitude. You're being exactly the kind of user that unpaid
 volunteer devs don't want to waste time having to support.
>> And that is your opinon which is pretty much useless and wrong to boot. 
>
> Dale,
>
> I've known you for 7 years. Now get over this init thingy thing you have
> going. Seriously.
>
>
>
>
>

Longer than that.  LOL 

Dale

:-)  :-) 

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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Walter Dnes]

On Sun, Sep 29, 2013 at 11:36:02PM -0500, Canek Peláez Valdés wrote
> On Sun, Sep 29, 2013 at 11:21 PM, Mark David Dumlao  
> wrote:

> And, on a personal note, I find a little quaint (and somehow naïve) to
> think about (for example) bluetooth as a "corner case", when most of
> us walk with a bluetooth enabled Linux computer on our pockets.

  Dalvik != GNU/Linux as we know it.  Exactly what percentage of
cellphones is running GNU/Linux as we know it, let alone Gentoo?

> I want Gentoo Linux on my cellphone. And it's probably not going to
> happen with OpenRC.

  I used to laugh at Windows users who got their OS dumbed down to a
useless mess, all in the name of "convergence with smartphones".  Now I
cry along with them.

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

Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01

[Dale]

»Q« wrote:
> On Sun, 29 Sep 2013 10:39:35 -0500
> Dale  wrote:
>
>> I think I'll update that Kubuntu disk right quick while I am thinking
>> about it.  Fall back plan just in case.  ;-)
> Make sure you notify the Kubuntu mailing list of your contingency plans
> in case Kubuntu's init thingy gives you trouble.  ;)
>
>
>

Real simple, reinstall.  It takes a very short time compared to Gentoo. 
I used to install Mandrake in about 30 minutes and that was a complete
install on much slower hard drives and CD readers. 

I got that covered.

Dale

:-)  :-) 

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

Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 00:53, Tanstaafl wrote:
> On 2013-09-29 5:15 PM, Alan McKinnon  wrote:
>> Those numbers are not likely to change much with time, with one
>> exception:
>>
>> /usr/src
>>
>> That can get real big real quick if you don't clean up kernel sources
>> often. Ideally, you'd make that a suitably sized LV and mount it
>> seperately.
> 
> Yeah, I always keep 2 or 3 known good kernels, and clean out the old
> stuff, so no worries there.
> 
>> The other space consumer is /usr/share with it's many documentation
>> files. But those too tend to be stable once you have everything
>> installed. 5G free out of 19G is ~75% space in use which is perfectly
>> acceptable for this case.
>>
>> Regular monitoring of the state of your machines will tell you if space
>> usage increases so you can investigate and deal with it timeously.
>>
>> I assume you long since moved portage and it's storage directories out
>> of /usr into /var?
> 
> Hmmm... No, I never did that myself...
> 
> Wow...
> 
> moria : Sun Sep 29, 18:19:01 : ~
>  # du -sh /usr/*
> 85M /usr/bin
> 131M/usr/include
> 0   /usr/lib
> 11M /usr/lib32
> 530M/usr/lib64
> 51M /usr/libexec
> 15M /usr/local
> 7.8G/usr/portage
> 21M /usr/sbin
> 509M/usr/share
> 3.9G/usr/src
> 0   /usr/tmp
> 7.0M/usr/x86_64-pc-linux-gnu
> moria : Sun Sep 29, 18:26:30 : ~
>  #

Apart from portage and src that all looks totally normal and unlikely to
vary much over time.



> Is this the official gentoo way now? Will a new/fresh virgin install
> have /var/portage instead of /usr/portage?

The new instaled default is to put all of portage on /var, whilst still
supporting old installs on /usr. This is no big deal in code, as it's
really just a string containing a base path


> I can eliminate almost 8GB by moving portage and its storage directories...

Or move them onto a dedictaed LV. This is a case where a different mount
point makes a lot of sense - we're all aware just how unique the tree is
in terms of fs performance - thousands of small files mostly smaller
than 2k in hundreds of directories. It's quite different to everything
else on /usr or even /var.

Same with distfiles, that too can move anywhere you want it to be, just
adjust one setting in make.conf

> I don't recall seeing a news item about that...

IIRC it wasn't a news item as such. Perhaps it was an elog from portage
itself.


> 
> But... is /usr/portage the default/recommended location? If so, then I
> don't think I want to move it - I generally never change defaults unless
> there is a very good reason to do so.

It's /var/portage for new installs. If you want it to be somewhere else,
just move it and adjust make.conf


> 
> But, is there some official gentoo docs online explaining how to do this?
> 
> Something more to think about...
> 
> Also - is there any kind of maintenance I shoudl be doing on
> /usr/portage to clean old cruft out? Or does portage maintain it already.

rsync takes care of all that.
You have eclean to keep distfiles tidy
binpkgs you need to clean up on your own, as portage has no way of
knowing what you want to keep. And local overlays fall in the same category


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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Neil Bothwick]

On Mon, 30 Sep 2013 00:14:08 -0400, Walter Dnes wrote:

> > seperate /usr has stopped working fine AGES AGO. Just some setups were
> > lucky enough not to stumble over the wreckage and fall into the
> > shards.  
> 
>   I.e. the 99% who don't need initramfs before today.  Some corner case
> exotic setups require complex solutions... no ifs/ands/ors/buts.  All
> the complaining you hear is from the other 99% who's setup worked just
> fine with the simple solution, suddenly finding the complex solution
> rammed down their throats.

Separate /usr is broken, maybe "faulty" would be a better word. It's like
software bugs, not everyone hits every bug, if you don't use the buggy
bits of the program. But would you rather wait until the program stopped
working for you or have the bugs fixed before you ever saw them?

Also consider that this is about Gentoo support for separate /usr. They
are supporting it now, which means they are spending time on it that
could be devoted elsewhere. Their spending that time on it may well be
the reason you have been shielded from the problems caused by a
separate /usr. All the news item says is that the Gentoo devs are no
longer going to do that for you, and they have presented a couple of
solutions. You are free to find a third path, or even continue using a
separate /usr without initramfs in the hope or belief that it will not
break for you.


-- 
Neil Bothwick

You are about to give someone a piece of your mind,
something you can ill afford...


signature.asc
Description: PGP signature

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[Neil Bothwick]

On Sun, 29 Sep 2013 22:03:11 -0400, Greg Woodbury wrote:

> One of the most obvious things that broke booting with a seperate /usr 
> is not GNOMEs fault, but GRUB 2's fault.

How so? All the files GRUB2 needs to boot are in /boot and GRUB is out of
the picture before the kernel loads or mounts /, let alone does anything
else.


-- 
Neil Bothwick

A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort.


signature.asc
Description: PGP signature

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Joost Roeleveld]

On Sunday 29 September 2013 14:45:05 Tanstaafl wrote:
> On 2013-09-29 2:25 PM, Dale  wrote:
> > Tanstaafl wrote:
> >> The way I see it, if you cannot provide a rational answer to that
> >> question, then  there is no reason for you to use this as a reason to
> >> abandon gentoo, only a reason to merge /usr into /...
> > 
> > Simple, I have never had to resize / or /boot before.  I have had to
> > resize /usr, /var and /home several times tho.  THAT is the reason.
> 
> Ok, but... everything I've read and personal experience over the years
> shows that space required for /usr should not change much, especially
> constantly grow over time (like requirements for /home can and will)- it
> may fluctuate (increase, decrease) *a little* over time, but it
> definitely should not grow substantially, so, if you had to resize it,
> most likely it is because you simply didn't allocate enough room to
> start with.

Then what would be a correct size for the "/" partition when putting "/usr" on 
there as well?
I have had no issues with giving "/" 500MB, "/boot" another 500MB and have 
everything else with minimal values on LVM and extending partitions without 
rebooting the machine whenever necessary.
If I am now forced to put "/usr" on "/", detailed steps on how to migrate all 
my systems succesfully with minimal downtime would be appreciated. Along with 
a size-indication that will:
1) Always be sufficient
2) Not be a waste of valuable diskspace


> > For me, it doesn't matter if it is rational to YOU or not.
> 
> Sorry, but rationality is not subjective. Just because something seems
> to be rational to you doesn't mean that it is.
> 
> You have still not stated a logical, rational reason for wanting a
> separate /usr.

Dale has, and so have I, see above.

> > I am the one doing things on my puter not you or anyone else. If the
> > init thingy fails, that will be me staring at a error message, not
> > you.
> 
> I don't want one of those things either, but that isn't what I was
> questioning you about.
> 
> Of course you can do whatever you want *and* are technically capable of
> on your own computer, but that doesn't automatically make those things
> logical or rational.
> 
> I did see one good case for a separate /usr (someone who was using
> ancient PATA drives, and something about striping for performance), but
> that was obviously a corner case...

Actually, it isn't a corner case.
Striping increases performance, I use it as well.
Why put all the software that I load when needed (and expect to be thrown out 
of memory when not used) on a single disk when you have the option to put all 
that on a RAID0 (striping) set?

--
Joost

Re: [gentoo-user] systemd installation location

[Neil Bothwick]

On Mon, 30 Sep 2013 10:42:37 +0800, Mark David Dumlao wrote:

> > What was /usr's original purpose?  
> /usr was originally the home directory. Programs were moved there
> because Unix didn't fit into a single disk.
> 
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Thanks for that link, it does a good job of explaining how we got in this
mess.


-- 
Neil Bothwick

I spilled Spot remover on my dog. Now he's gone.


signature.asc
Description: PGP signature

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 06:14, Walter Dnes wrote:
>   If the udev people had made "net ifnames=0" the default, and allowed
> the small percentage of multi-nic machine admins to set "net.ifnames=1",
> this would not have been an issue.  Some corner case exotic setups
> require complex solutions... no ifs/ands/ors/buts.  All the complaining
> you hear is from the other 99% who's setup worked just fine with the
> simple solution, suddenly finding the complex solution rammed down their
> throats.


No, that is just plain wrong.

Having interfaces on a multi-nic host come up as ethX where X is a
mostly random number is just so broken it beggars belief. Trust me, it
is zero fun when it happens and what makes it even worse if you have no
warning at all beforehand.

Go check out FreeBSD sometime and see how they number their nics, and
see how it is completely reliable every single time. Check Windows for
that matter, they also don't have the problem. Neither does MacOS.

All that happened is that Linux and udev got dragged screaming and
bitching into the 21st century wrt nic naming, and things are now in a
better situation they should have been in many many years ago. But, as
usual, people are resistant to change even when the change is something
that does indeed need to happen.




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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 01:40, Daniel Campbell wrote:
> The best path for you seems to be a merge of / and /usr. I asked Alan
> how to do this since he seemed knowledgeable about it. If he replies,
> maybe his advice will be handy and save you a lot of trouble. It seems
> clear to me that you want to avoid trouble, but looking at your options,
> putting /usr in / is probably the least painful thing you can do, and it
> won't require an initramfs. I don't like initramfs's either, but that's
> because I'm lazy and don't like maintaining more than two things (kernel
> and GRUB config) in order to boot.


I think I replied so a similar question from tanstaafl already, but
basically all you need to do is boot with a rescue disk, mount /usr
somewhere else and copy everything in it to the usr/ directory on /

But the devil is in the details and if anything will trip you up it's
the extact contents you have there and how much space you have
available. I don't know of any script around that automates it, so human
eyeballs is what it will take.

If you post the output of df -h, du -sh /usr, du -sh /usr/*, mount, and
the contents of fstab, loads of folks here can tell you how to proceed.

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

Re: [gentoo-user] separate / and /usr to require initramfs 2013-11-01

[Alan McKinnon]

On 30/09/2013 01:08, Dale wrote:
>> At the end of they day, you don't want to learn how to do it "the hard way". 
>> So
>> > do it the easy way and be done with your troubles. If you don't want to do 
>> > it
>> > EITHER way fine, but stop pretending that it's anything else but a problem
>> > with your attitude. You're being exactly the kind of user that unpaid
>> > volunteer devs don't want to waste time having to support.
> And that is your opinon which is pretty much useless and wrong to boot. 


Dale,

I've known you for 7 years. Now get over this init thingy thing you have
going. Seriously.





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

Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim

[Alan McKinnon]

On 30/09/2013 08:31, pk wrote:
> On 2013-09-30 00:04, Alan McKinnon wrote:
> 
>> It's the general idea that you can leave /usr unmounted until some
>> random arb time later in the startup sequence and just expect things to
>> work out fine that is broken.
>>
>> It just happened to work OK for years because nothing happened to use
>> the code in /usr at that point in the sequence. More and more we are
>> seeing that this is no longer the case.
> 
> So basically it wasn't broke before stuff started to use the code in
> /usr. How isn't that breaking?
> 
>> So no-one broke it with a specific commit. It has always been broken by
>> design becuase it's a damn stupid idea that just happened to work by
>> fluke. IT and computing is rife with this kind of error.
> 
> If what you are saying is true then *everything* is broken "by design"
> if something isn't available at boot time (may be /usr, may be /var or
> whatever).



I never mentioned /var at all.

Go back and read again what I did write.





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