Re: [gentoo-user] Do I really need a sshd?
On Sat, 4 Jan 2014 22:12:42 + Neil Bothwick n...@digimed.co.uk wrote: On Sat, 4 Jan 2014 15:57:10 +0200, Gevisz wrote: etc-update or conf-update or similar I was afraid to run etc-update as man says it will replace everything automatically. However, I run dispatch-conf and it does not see any problems at /etc/ssh, which have only the following three files: moduli, ssh_config, sshd_config (though I have added /etc/ssh to CONFIG_PROTECT_MASK). Why did you do that? By masking out config file protection for /etc/ssh there will never be anything to be managed by etc-update as you have told portage to replace those files blindly and without asking. From man dispatch-conf: dispatch-conf will check all directories in the CONFIG_PROTECT variable. All config files found in CONFIG_PROTECT_MASK will automatically be updated for you by dispatch-conf. But anyway, 1) I mask it only for one session, just to check that this does not help, 2) as we have already figured out, there were no ssh config files to merge, only the dumb warning message issued without checking anything, and the latter, in my view, is a karma of ssh: it should have at least something implemented wrong :-) 3) I will continue to do this job manually with gvimdiff as I have found it much more convenient than dispatch-conf (gvimdiff shows the differences a way much better).
Re: [gentoo-user] Do I really need a sshd?
On Sunday 05 Jan 2014 11:36:20 Gevisz wrote: From man dispatch-conf: dispatch-conf will check all directories in the CONFIG_PROTECT variable. All config files found in CONFIG_PROTECT_MASK will automatically be updated for you by dispatch-conf. Have you tried another updater of config files? I still use the basic etc- update, but there are also app-portage/cfg-update and app-portage/conf-update. You might feel happier with one of those three. -- Regards Peter
Re: [gentoo-user] Do I really need a sshd?
On Sun, 5 Jan 2014 11:36:20 +0200, Gevisz wrote: I was afraid to run etc-update as man says it will replace everything automatically. However, I run dispatch-conf and it does not see any problems at /etc/ssh, which have only the following three files: moduli, ssh_config, sshd_config (though I have added /etc/ssh to CONFIG_PROTECT_MASK). Why did you do that? By masking out config file protection for /etc/ssh there will never be anything to be managed by etc-update as you have told portage to replace those files blindly and without asking. From man dispatch-conf: CONFIG_PROTECT_MASK is a make.conf setting, read that man page. It means your config files are overwritten at install time, way be for you run dispatch-conf or one of its friends. dispatch-conf will check all directories in the CONFIG_PROTECT variable. All config files found in CONFIG_PROTECT_MASK will automatically be updated for you by dispatch-conf. 3) I will continue to do this job manually with gvimdiff as I have found it much more convenient than dispatch-conf (gvimdiff shows the differences a way much better). I prefer conf-update but most of these tools allow you to specify your own diff program if you don't like the default. I use colordiff with conf-update. -- Neil Bothwick Money can't buy happiness. But it sure makes misery easier to live with. signature.asc Description: PGP signature
Re: [gentoo-user] Re: [gentoo-user] there are no ebuilds built with USE flags to satisfy “XXX”
On Sun, 5 Jan 2014 12:21:01 +0800, 钱泽森 wrote: Please don't top-post. Thanks a lot! I can play it now.BTW,what emerge means by that? I can emerge the game only when the two USE flags is enabled both? The output is telling you, not in the clearest of ways, that if you want to enable the mod USE flag, you must also enable one of mikmod or modplug, with mikmod being the default choice because it is listed first. -- Neil Bothwick We all know what comes after 'X', said Tom, wisely., signature.asc Description: PGP signature
Re: [gentoo-user] how to use my SSD the right way ;-)
Alan McKinnon alan.mckin...@gmail.com writes: that's expected, BFQ isn't in mainline Nor is it in Gentoo hardened-sources.
Re: [gentoo-user] how to use my SSD the right way ;-)
Am 03.01.2014 23:14, schrieb Stefan G. Weichinger: currently fiddling with my thinkpad hanging at boot ... so still no BFQ for that laptop ... :-( I don't get it. My thinkpad hangs repeatedly a booting and I don't really know how to spot the reason. As you may remember I run systemd as init-system ... with gentoo-sources-3.12.6 it boots at least more often than with USE=experimental ... dunno if it is related to BFQ. I had those hangs before as well ... for a while I assumed it was related to the flushing of the systemd-journal but it was not. I even had masked the flushing but it didn't help. Maybe I should mask the lvm-stuff as well, maybe I even don't need it at all? Is it necessary for encrypted partitions as well (sorry for that stupid q)? I don't have PVs/VGs/LVs on that one small SSD here I just let lvm2 there because I didn't want to break things. Stefan
[gentoo-user] x11-misc/shared-mime-info update problem...
Hi Gentoo-users, while trying to update my box I ran into some problem with x11-misc/shared-mime-info (updating from 1.0 to 1.2-r1). Maybe someone could help me to understand what the problem is. I see it failed in config-phase with: error: XML::Parser perl module is required for intltool But why was XML::Parser not pulled as dependency, when it is required? What ebuild is it in? Jarry _ Emerging (1 of 14) x11-misc/shared-mime-info-1.2-r1 * shared-mime-info-1.2.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] Unpacking source... Unpacking shared-mime-info-1.2.tar.xz to /var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/work Source unpacked in /var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/work Preparing source in /var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/work/shared-mime-info-1.2 ... * Applying shared-mime-info-1.2-g_type_init.patch ... [ ok ] Source prepared. Configuring source in /var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/work/shared-mime-info-1.2 ... ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-silent-rules --disable-dependency-tracking --disable-default-make-check --disable-update-mimedb checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of x86_64-pc-linux-gnu-gcc... none checking for an ANSI C-conforming const... yes checking whether NLS is requested... yes checking for intltool = 0.35.0... 0.50.2 found checking for intltool-update... /usr/bin/intltool-update checking for intltool-merge... /usr/bin/intltool-merge checking for intltool-extract... /usr/bin/intltool-extract checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/gmsgfmt checking for perl... /usr/bin/perl checking for perl = 5.8.1... 5.16.3 checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool !!! Please attach the following file when seeking support: !!! /var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/work/shared-mime-info-1.2/config.log * ERROR: x11-misc/shared-mime-info-1.2-r1::gentoo failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 93: Called src_configure *environment, line 2173: Called econf '--disable-default-make-check' '--disable-update-mimedb' * phase-helpers.sh, line 577: Called die * The specific snippet of code: * die econf failed * * If you need support, post the output of `emerge --info '=x11-misc/shared-mime-info-1.2-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=x11-misc/shared-mime-info-1.2-r1::gentoo'`. * The complete build log is located at '/var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/temp/environment'. * Working directory: '/var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/work/shared-mime-info-1.2' * S: '/var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/work/shared-mime-info-1.2' Failed to emerge x11-misc/shared-mime-info-1.2-r1, Log file: '/var/tmp/portage/x11-misc/shared-mime-info-1.2-r1/temp/build.log' * Messages for package x11-misc/shared-mime-info-1.2-r1: * ERROR: x11-misc/shared-mime-info-1.2-r1::gentoo failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 93: Called src_configure *environment, line 2173: Called econf '--disable-default-make-check' '--disable-update-mimedb' * phase-helpers.sh, line 577: Called die * The specific snippet of code: * die econf failed * * If you need support, post the output of `emerge --info '=x11-misc/shared-mime-info-1.2-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=x11-misc/shared-mime-info-1.2-r1::gentoo'`. * The complete build log is
Re: [gentoo-user] x11-misc/shared-mime-info update problem...
On 01/05/2014 04:32 AM, Jarry wrote: Hi Gentoo-users, while trying to update my box I ran into some problem with x11-misc/shared-mime-info (updating from 1.0 to 1.2-r1). Maybe someone could help me to understand what the problem is. I see it failed in config-phase with: error: XML::Parser perl module is required for intltool But why was XML::Parser not pulled as dependency, when it is required? What ebuild is it in? Jarry The proper dependency should be pulled in (x11-misc/shared-mime-info depends on dev-util/intltool, which depends on dev-perl/XML-Parser). My guess is that you recently upgraded perl, which might require you to rebuild the perl modules. You can try rebuilding just dev-perl/XML-Parser, but I recommend using perl-cleaner [1] to rebuild all the modules: perl-cleaner --allmodules -v And then try to rebuild shared-mime-info. Regards, Pavel [1] http://www.gentoo.org/proj/en/perl/perl-cleaner.xml
Re: [gentoo-user] x11-misc/shared-mime-info update problem...
On 05-Jan-14 13:48, Pavel Kazakov wrote: On 01/05/2014 04:32 AM, Jarry wrote: ... I see it failed in config-phase with: error: XML::Parser perl module is required for intltool The proper dependency should be pulled in (x11-misc/shared-mime-info depends on dev-util/intltool, which depends on dev-perl/XML-Parser). My guess is that you recently upgraded perl, which might require you to rebuild the perl modules. You can try rebuilding just dev-perl/XML-Parser, but I recommend using perl-cleaner [1] to rebuild all the modules: perl-cleaner --allmodules -v And then try to rebuild shared-mime-info. You are right and this fixed my problem. Thanks! I really updated perl recently but I did not know I had to run perl-cleaner. Never heard of it. Should not it be done automaticaly, always after new perl version has been installed? Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] Do I really need a sshd?
Am 05.01.2014 11:04, schrieb Peter Humphrey: On Sunday 05 Jan 2014 11:36:20 Gevisz wrote: From man dispatch-conf: dispatch-conf will check all directories in the CONFIG_PROTECT variable. All config files found in CONFIG_PROTECT_MASK will automatically be updated for you by dispatch-conf. Have you tried another updater of config files? I still use the basic etc- update, but there are also app-portage/cfg-update and app-portage/conf-update. You might feel happier with one of those three. I am using cfg-update for years without problems whatsoever.
Re: [gentoo-user] x11-misc/shared-mime-info update problem...
On Sun, 05 Jan 2014 14:06:31 +0100, Jarry wrote: You are right and this fixed my problem. Thanks! I really updated perl recently but I did not know I had to run perl-cleaner. Never heard of it. Should not it be done automaticaly, always after new perl version has been installed? Did ou not see this n the elog message from Perl? UPDATE THE PERL MODULES: After updating dev-lang/perl you must reinstall the installed perl modules. Use: perl-cleaner --all -- Neil Bothwick Reboot America. signature.asc Description: PGP signature
Re: [gentoo-user] x11-misc/shared-mime-info update problem...
On 05/01/2014 15:06, Jarry wrote: On 05-Jan-14 13:48, Pavel Kazakov wrote: On 01/05/2014 04:32 AM, Jarry wrote: ... I see it failed in config-phase with: error: XML::Parser perl module is required for intltool The proper dependency should be pulled in (x11-misc/shared-mime-info depends on dev-util/intltool, which depends on dev-perl/XML-Parser). My guess is that you recently upgraded perl, which might require you to rebuild the perl modules. You can try rebuilding just dev-perl/XML-Parser, but I recommend using perl-cleaner [1] to rebuild all the modules: perl-cleaner --allmodules -v And then try to rebuild shared-mime-info. You are right and this fixed my problem. Thanks! I really updated perl recently but I did not know I had to run perl-cleaner. Never heard of it. Should not it be done automaticaly, always after new perl version has been installed? Jarry perl ebuilds up to and including 5.14.2 used to give you an ewarn() that said to run perl-cleaner, and how to do it. I see it's missing from the 5.16 series of ebuilds. I didn't look into it too closely, but I would consider this a bug. There is no easy way to just quickly discover that a module is built for a previously installed version of perl - you can poke around in /usr/lib/perl5/version/XML/Parser but that's not exactly easy to use. And the failures are mysterious and hard to understand. You might want to file a bug at b.g.o. about the lack of messages at the end of a perl install. The reason it is not done automatically is that it's a huge job. the scripts has to find every perl module it can, check the version it is built against and decide if it needs to be rebuilt then emerge it. This can easily be 50-100 packages or more and can take longer than to build firefox. Portage can't figure this out when emerging perl that's why it doesn't do it, it is left to you to do manually. Same with python. Golden rule: When updating perl or python and a version change occurs, take note and always run perl-cleaner or python-updater afterwards. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] x11-misc/shared-mime-info update problem...
On 05-Jan-14 15:02, Neil Bothwick wrote: On Sun, 05 Jan 2014 14:06:31 +0100, Jarry wrote: You are right and this fixed my problem. Thanks! I really updated perl recently but I did not know I had to run perl-cleaner. Never heard of it. Should not it be done automaticaly, always after new perl version has been installed? Did ou not see this n the elog message from Perl? UPDATE THE PERL MODULES: After updating dev-lang/perl you must reinstall the installed perl modules. Use: perl-cleaner --all Well, I tested it on another computer and the problem is perl and shared-mime-info are updated at the same update-run. So I can find this message *after* update of shared-mime-info already crashed. And I have to scroll way back to see any perl-related messages... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
[gentoo-user] Updating $PATH variable permanently for root not working
Not sure what I'm missing...
I login as normal user, then su - to root...
I've created /root/.bashrc, and added the following:
export PATH=${PATH}:/path/I/want/to/add
If I logout, then su - back into root, shouldn't I see the new path?
Manually exporting it during the session works, so obviously I'm missing
something...
Re: [gentoo-user] x11-misc/shared-mime-info update problem...
On 2014-01-05 9:24 AM, Jarry mr.ja...@gmail.com wrote: Well, I tested it on another computer and the problem is perl and shared-mime-info are updated at the same update-run. So I can find this message *after* update of shared-mime-info already crashed. And I have to scroll way back to see any perl-related messages.. You don't email yourself all of the emerge logs, so you don't have to worry about missing these kinds of messages? I honestly can't see how anyone can reliably keep a gentoo system up to date without doing that...
[gentoo-user] Confusion about slot conflict
Hi list, When I do a world upgrade, I have encountered the following slot conflict: media-libs/libpng:0 (media-libs/libpng-1.5.17-r1::gentoo, installed) pulled in by media-libs/libpng:0/0= required by (dev-python/wxpython-2.8.12.1-r1::gentoo, installed) =media-libs/libpng-1.4:0/0= required by (net-libs/webkit-gtk-1.8.3-r201::gentoo, installed) media-libs/libpng:0/0= required by (app-text/poppler-0.22.5::gentoo, installed) media-libs/libpng:0/0= required by (media-libs/libwebp-0.3.1::gentoo, installed) media-libs/libpng:0/0= required by (net-print/cups-filters-1.0.36-r1::gentoo, installed) media-libs/libpng:0/0= required by (kde-base/kdelibs-4.11.4::gentoo, installed) (media-libs/libpng-1.6.8::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) My question is, seems upgrade to libpng-1.6.8 will solve the conflict, why emerge cannot proceed this automatically? or there are some switches to controller this? Thanks a lot.
Re: [gentoo-user] x11-misc/shared-mime-info update problem...
On Sun, 05 Jan 2014 15:24:49 +0100, Jarry wrote: Did you not see this n the elog message from Perl? UPDATE THE PERL MODULES: After updating dev-lang/perl you must reinstall the installed perl modules. Use: perl-cleaner --all Well, I tested it on another computer and the problem is perl and shared-mime-info are updated at the same update-run. So I can find this message *after* update of shared-mime-info already crashed. And I have to scroll way back to see any perl-related messages... I never rely on seeing the messages in a termnal and always have elogs mailed to me. -- Neil Bothwick The quickest way to a man's heart is through his sternum. signature.asc Description: PGP signature
[gentoo-user] Re: [gentoo-user] Re: [gentoo-user] there are no ebuilds built with USE flags to satisfy “XXX”
On 01/05/2014 02:25 AM, Neil Bothwick wrote: On Sun, 5 Jan 2014 12:21:01 +0800, 钱泽森 wrote: Please don't top-post. Thanks a lot! I can play it now.BTW,what emerge means by that? I can emerge the game only when the two USE flags is enabled both? The output is telling you, not in the clearest of ways, that if you want to enable the mod USE flag, you must also enable one of mikmod or modplug, with mikmod being the default choice because it is listed first. I needed that information also. Hopefully next time I run into a problem like that it won't be a bunch of guessing. Thanks for the info. -- Willie Matthews matthews.wil...@gmail.com (702) 508.8455 I have my geeky moments! signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Updating $PATH variable permanently for root not working
On Sun, Jan 5, 2014 at 9:28 AM, Tanstaafl tansta...@libertytrek.org wrote:
Not sure what I'm missing...
I login as normal user, then su - to root...
I've created /root/.bashrc, and added the following:
export PATH=${PATH}:/path/I/want/to/add
If I logout, then su - back into root, shouldn't I see the new path?
Manually exporting it during the session works, so obviously I'm missing
something...
Personally, I had to create /root/.bash_profile for .bashrc:
~ # cat .bash_profile
# /etc/skel/.bash_profile
# This file is sourced by bash for login shells. The following line
# runs your .bashrc and is recommended by the bash info pages.
[[ -f ~/.bashrc ]] . ~/.bashrc
--
Alecks Gates
Re: [gentoo-user] x11-misc/shared-mime-info update problem...
On 05/01/2014 16:24, Jarry wrote: On 05-Jan-14 15:02, Neil Bothwick wrote: On Sun, 05 Jan 2014 14:06:31 +0100, Jarry wrote: You are right and this fixed my problem. Thanks! I really updated perl recently but I did not know I had to run perl-cleaner. Never heard of it. Should not it be done automaticaly, always after new perl version has been installed? Did ou not see this n the elog message from Perl? UPDATE THE PERL MODULES: After updating dev-lang/perl you must reinstall the installed perl modules. Use: perl-cleaner --all Well, I tested it on another computer and the problem is perl and shared-mime-info are updated at the same update-run. So I can find this message *after* update of shared-mime-info already crashed. And I have to scroll way back to see any perl-related messages... As Neil and Charles already said, mail the elogs to yourself. Or you can adjust the various LOG settings in make.conf and view the entries with elogv (cli app) or elogviewer (qt gui app) or just less them - they are in /var/log/portage/elog/ But all of this is CLEARLY laid out in one of the most important man files you have - man 5 make.conf. Why have you not read it? Do yourself a big favour and before you touch anything else on a Gentoo system, do this. It will save you heaps of pain: man emerge man 5 portage man 5 ebuild man 5 make.conf make sure you understand everything in there. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Confusion about slot conflict
On 05/01/2014 17:57, 张东亚 wrote: Hi list, When I do a world upgrade, I have encountered the following slot conflict: media-libs/libpng:0 (media-libs/libpng-1.5.17-r1::gentoo, installed) pulled in by media-libs/libpng:0/0= required by (dev-python/wxpython-2.8.12.1-r1::gentoo, installed) =media-libs/libpng-1.4:0/0= required by (net-libs/webkit-gtk-1.8.3-r201::gentoo, installed) media-libs/libpng:0/0= required by (app-text/poppler-0.22.5::gentoo, installed) media-libs/libpng:0/0= required by (media-libs/libwebp-0.3.1::gentoo, installed) media-libs/libpng:0/0= required by (net-print/cups-filters-1.0.36-r1::gentoo, installed) media-libs/libpng:0/0= required by (kde-base/kdelibs-4.11.4::gentoo, installed) (media-libs/libpng-1.6.8::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) My question is, seems upgrade to libpng-1.6.8 will solve the conflict, why emerge cannot proceed this automatically? or there are some switches to controller this? Thanks a lot. libpng-1.5.17-r1 is latest stable version libpng-1.6.8 is latest unstable version I suspect you are probably running a stable system with several packages marked unstable and one of those requires libpng-1.6.8 To check, please post what is your ACCEPT_KEYWORDS in make.conf? what is the output of grep -r libpng /etc/portage/ -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Updating $PATH variable permanently for root not working
On 05/01/2014 17:28, Tanstaafl wrote:
Not sure what I'm missing...
I login as normal user, then su - to root...
I've created /root/.bashrc, and added the following:
export PATH=${PATH}:/path/I/want/to/add
If I logout, then su - back into root, shouldn't I see the new path?
Manually exporting it during the session works, so obviously I'm missing
something...
You are running into that crazy world called shell start-up scripts
where nothing is as it seems and every install has different levels of
crazy.
run man bash and search for the section called INVOCATION. Once you
wade through that byzantine mess, it may be apparent that ~/.bashrc is
only read when you launch an interactive non-login shell. But su -
starts a login shell, so .bashrc is never sourced.
Prove this by running su without the dash, your PATH should work then.
The usual solution is to source .bashrc from .bash_profile, this has the
effect that .bashrc is always sourced regardless of the kind of shell
you start.
Clear as mud right?
tl;dr
Long explanation:
long long ago in a land and time far far away, we have but
TheOneTrueShell(tm) and it's name was sh. This shell was very simple
and it's start up scripts followed a grand Unix tradition:
/etc/profile contained the global settings for all users
~/.profile contained a user's specific settings
And so the world was good. Until bash.
The authors of bash figured they should provide extra and wonderful ways
of providing bash-specific startup scripts. You'd think they'd do it so
the user could put their personal stuff for all shells into ~/.profile
and bash stuff into ~/.bash_profile.
But no, nothing so simple. Bash first looks for ~/.bash_profile and if
it finds it, it ignores ~/.profile entirely. So people would just add
. ~/.profile to .bash_profile and be done with it.
Then there's a distinction between a login shell (what you get at login,
or with su -) and a non-login shell (what you get with su or usually
with konsole, gnome-terminal etc). Why this difference exists, I do not
know. Maybe it's to save 512 precious bytes of environment memory.
A non-login shell reads only ~/.bashrc, presumably because the shell was
launched for something else (an Xsession, or a running shell) that had a
full environment set up already and there was no need to repeat it.
Head spinning yet? Just be done with all that nonsense and do this:
Put this line as the only non-comment line in .bash_profile
[[ -f ~/.bashrc ]] . ~/.bashrc
and put all your shell start-up stuff in .bashrc (moving them out of
.bash_profile if necessary
This way everything is still unbelievably complex but at least the
visible problems mostly just go away
--
Alan McKinnon
alan.mckin...@gmail.com
[gentoo-user] Re: Preparing a shared USB stick
On 01/04/2014 05:21 PM, Alan McKinnon wrote: On 05/01/2014 02:42, walt wrote: On 01/04/2014 03:44 PM, Alan McKinnon wrote: FAT was designed for MS-DOS where you put a floppy in the drive and you had full access to everything on it. There was no need to implement security. I think the operative phrase is there was no need back when Gates and Allen trained the world to accept failure as good enough. I don't think so. This was back in the early 80s remember and PCs were a new novelty. The thing to compare them to was paper records and we all know bits of paper have no inherent security attributes. If you want to secure them, keep them in a space with a lock. To secure a PC and it's floppies, store them in a space with a lock. And then there's the hardware, those things ran on 8086 chips. Not bad for the time, but not exactly heavy on cpu grunt. You can't seriously be pushing the line that MS promotes failure. gates and Allen had the balls to get a working pc to market that put one on every office desk and made computing ubiquitous. Sure, if they didn't do it someone else would have, but they are the guys that did when no-one else had managed. Think Amstrad, Sinclair, early Commodore. Even the Beeb, awesome as it was, tanked completely. It's all very easy for us to sit back today and play monday morning fullback but in those days hardly anyone had a clue about security or how to do it. The guys who did know were the mainframe and mini guys, and that model didn't translate to what the PC was meant for. Hey, I like to bash MS as much as the next guy (IE6 is a crime that shall never be forgiven) LOL! but I do think we should bash MS for things they deserve, not so much for things they don't. Okay, okay, you're absolutely right about the early-early days. I'm thinking about the era when GM's CEO complained that if GM made cars the way Bill made software (I paraphrase) then tow-truck drivers would be millionaires. For several years the IT people where I work have been making hundreds of lives a living hell because failure is greeted every day with a shrug and a hostile apology, I *do* blame M$ for setting the bar that low, though not in the early days, I agree.
[gentoo-user] disable numlock on netbook
I have Gentoo on a first gen Acer Aspire One. The teeny keyboard doesn't have a numpad, it's simulated by using the right-hand bunch of keys and you engage it with Fn-F11 It's recently started booting up with the numpad on which is annoying at first login as my username is not a3an0 The Num LED is also off at this stage. There used to be a way to set numlock on or off in baselayout/openrc but now I can't find it. grep -r numlock /etc returns nothing relevant, and /etc/init.d/numlock is to enable it with no function to disable it (I have this script disable in default runlevel) How is this done these days? Should I call setleds in rc.local somewhere? -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: Preparing a shared USB stick
On 01/04/2014 05:21 PM, Alan McKinnon wrote: It's all very easy for us to sit back today and play monday morning fullback :) I know as little about, um, Celtic football as you know about American football, I see. I know sod-all about sports from anywhere, but even I know that the phrase is monday morning quarterback. All in the spirit of cross-cultural fellowship, of course :)
Re: [gentoo-user] Re: Preparing a shared USB stick
On 05/01/2014 23:26, walt wrote: I'm thinking about the era when GM's CEO complained that if GM made cars the way Bill made software (I paraphrase) then tow-truck drivers would be millionaires. For several years the IT people where I work have been making hundreds of lives a living hell because failure is greeted every day with a shrug and a hostile apology, I know that attitude very well; I'm usually the guy shrugging about software, along with a what the fuck do you want me to do about it? I didn't write that code where that code is often in-house Ops stuff written years ago in php. I'm trying hard to get rid of the attitude, not succeeding much though. But I do think that MS's track record is not really a result of malice, it's more a case of ship it when it's good enough to run, not when it's correct for varying definitions of good enough and on how many machines it was good enough. I'll give you a parallel in the Linux world: gtk+/gnome vs efl/e18 GTK is the worst possible of all GUI toolkit. It's getting better but by god early versions sucked hugely. Ever looked into what it takes to write a gtk-engine for themeing?And as for Gnome they can never make up their damn mind how the back-end comms are going to work. We've been through endless iterations of corba and Miguel trying to get mono forced in, now I think they settled on dbus. What was that Corba thing called? Bonobo? But it ran, and ran good enough to be used. Contrast efl and e18. That project strives to be correct and raster refused to release anything until it was better than correct. For ten years it sat in cvs only, until one day MikeB stepped up and said hell or high water we release what we have 21 Dec 2013. I think there would be arguments behind the scenes but no matter, on that day e17 and efl was released. One year later exactly e18 was released. It's a beautiful toolkit, you don't have to touch any code at all to theme it and it's slick, neat and runs on just about anything with a cpu. Even does amazing amounts of OpenGL smoothly in software if you need to. But who uses it? MS:Gnome::not MS:efl-e18 But I'm still not going to forgive Bill for IE6 :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Preparing a shared USB stick
On 05/01/2014 23:50, walt wrote: On 01/04/2014 05:21 PM, Alan McKinnon wrote: It's all very easy for us to sit back today and play monday morning fullback :) I know as little about, um, Celtic football as you know about American football, I see. I know sod-all about sports from anywhere, but even I know that the phrase is monday morning quarterback. All in the spirit of cross-cultural fellowship, of course :) Yeah, you're right. I live in a country where the national religion is Rugby, none of that weeny nonsense with helmets and pads - we go in with bare hands. The guy at the back usually built like a brick shit-house and with a good kicking foot is never called a quarterback Old naming habits die hard :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Updating $PATH variable permanently for root not working
On 01/05/2014 04:14 PM, Alan McKinnon wrote:
This way everything is still unbelievably complex but at least the
visible problems mostly just go away
There is an apparently empty directory, /etc/skel, that upon closer
inspection contains some nice default bash junk:
$ ls -a /etc/skel/
total 32K
drwxr-xr-x 3 root root 4.0K 2013-06-06 10:53 .
drwxr-xr-x 113 root root 12K 2014-01-05 01:24 ..
-rw-r--r-- 1 root root 127 2013-06-06 10:53 .bash_logout
-rw-r--r-- 1 root root 193 2013-06-06 10:53 .bash_profile
-rw-r--r-- 1 root root 551 2013-06-06 10:53 .bashrc
drwx-- 2 root root 4.0K 2007-11-23 14:25 .ssh
The 'useradd' program {might,should} install these for you; if not it
can be coaxed into it with the --skel flag.
The .bash_profile in there does what Alan suggests.
[gentoo-user] Circular dependencies...
Hi,
I got this:
# emerge --update --newuse --deep --with-bdeps=y @world -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
[nomerge ] virtual/rubygems-6:ruby20 [1:ruby18, 4:ruby19]
RUBY_TARGETS=(ruby20)
[nomerge ] dev-lang/ruby-2.0.0_p353:2.0 [1.8.7_p374:1.8, 1.9.3_p484:1.9]
USE=berkdb doc gdbm ipv6 ncurses rdoc readline ssl -debug -examples -rubytests
-socks5 -tk (-xemacs)
[nomerge ] dev-ruby/json-1.8.0 [1.7.7] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%)
[nomerge ]dev-ruby/rake-0.9.6 [0.9.2.2] USE=doc {-test}
(-bash-completion%) RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%)
[nomerge ] dev-ruby/rdoc-4.0.1-r1 [3.12.2] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby)
[ebuild U ] dev-ruby/racc-1.4.9 [1.4.8] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%) 107 kB
[ebuild U ] dev-ruby/json-1.8.0 [1.7.7] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%) 146 kB
[ebuild U ] dev-ruby/rake-0.9.6 [0.9.2.2] USE=doc {-test}
(-bash-completion%) RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%)
121 kB
[ebuild U ]dev-ruby/rdoc-4.0.1-r1 [3.12.2] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) 457 kB
Total: 4 packages (4 upgrades), Size of downloads: 830 kB
* Error: circular dependencies:
(dev-ruby/rdoc-4.0.1-r1::gentoo, ebuild scheduled for merge) depends on
(dev-ruby/racc-1.4.9::gentoo, ebuild scheduled for merge) (buildtime)
(dev-ruby/rdoc-4.0.1-r1::gentoo, ebuild scheduled for merge) (buildtime)
It might be possible to break this cycle
by applying the following change:
- dev-ruby/racc-1.4.9 (Change USE: -doc)
I added this to /etc/portage/package.use:
=dev-ruby/racc-1.49 -doc
and have set doc in the USE flags in make.conf.
I am still getting the above output...
How can I get out of this cycle out of this cycle out of this cycles
out of... ;)
Best regards,
mcc
Re: [gentoo-user] Circular dependencies...
On Mon, 6 Jan 2014 08:18:20 +0100
meino.cra...@gmx.de wrote:
Hi,
I got this:
# emerge --update --newuse --deep --with-bdeps=y @world -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
[nomerge ] virtual/rubygems-6:ruby20 [1:ruby18, 4:ruby19]
RUBY_TARGETS=(ruby20)
[nomerge ] dev-lang/ruby-2.0.0_p353:2.0 [1.8.7_p374:1.8,
1.9.3_p484:1.9] USE=berkdb doc gdbm ipv6 ncurses rdoc readline ssl -debug
-examples -rubytests -socks5 -tk (-xemacs)
[nomerge ] dev-ruby/json-1.8.0 [1.7.7] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%)
[nomerge ]dev-ruby/rake-0.9.6 [0.9.2.2] USE=doc {-test}
(-bash-completion%) RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%)
[nomerge ] dev-ruby/rdoc-4.0.1-r1 [3.12.2] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby)
[ebuild U ] dev-ruby/racc-1.4.9 [1.4.8] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%) 107 kB
[ebuild U ] dev-ruby/json-1.8.0 [1.7.7] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%) 146 kB
[ebuild U ] dev-ruby/rake-0.9.6 [0.9.2.2] USE=doc {-test}
(-bash-completion%) RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) (-ree18%)
121 kB
[ebuild U ]dev-ruby/rdoc-4.0.1-r1 [3.12.2] USE=doc {-test}
RUBY_TARGETS=ruby18 ruby19 ruby20%* (-jruby) 457 kB
Total: 4 packages (4 upgrades), Size of downloads: 830 kB
* Error: circular dependencies:
(dev-ruby/rdoc-4.0.1-r1::gentoo, ebuild scheduled for merge) depends on
(dev-ruby/racc-1.4.9::gentoo, ebuild scheduled for merge) (buildtime)
(dev-ruby/rdoc-4.0.1-r1::gentoo, ebuild scheduled for merge) (buildtime)
It might be possible to break this cycle
by applying the following change:
- dev-ruby/racc-1.4.9 (Change USE: -doc)
I added this to /etc/portage/package.use:
=dev-ruby/racc-1.49 -doc
1.49 != 1.4.9, is that not just a typo in your email?
Cheers,
Khumba
and have set doc in the USE flags in make.conf.
I am still getting the above output...
How can I get out of this cycle out of this cycle out of this cycles
out of... ;)
Best regards,
mcc
