Re: [gentoo-user] KDE Activities
On Sat, Dec 27, 2014 at 11:19 PM, Alan McKinnon wrote: > > What you can do is make Activities go away and never impinge on your > life, that's what I do. I've had KDE here for years and like you never > grokked what it even is when it first hit early in 4.x. I'm a grumpy old > far, I like my 6 virtual desktops in 2 rows of three, I like to launch > the apps myself I known I'm going to use now, and I like global session > management for apps I always use all the time (like Konsole). I don't > like Activities. > > I made them go away and have been using the same KDE config ever since > quite happily. IIRC all it really took was to remove the icon[1] from > the panel, and maybe disable some keyboard shortcuts. Activities hasn't > appeared here for years now, I'd forgotten all about them till this > thread showed up :-) > > > Anyway, hope this helps > > > [1] The icon is the one with three small overlapping circles IIRC > It may, thanks for suggesting this. I can presumably resist the allure of the icon; but deactivating those shortcuts ought to save me from those "bridge troll" incidents, which invariably start with me accidentally or purposely mashing the keyboard or guessing at shortcuts in some random, hard-to-know-what-I-did-so-I-can-avoid-it-in-the-future way. -gmt
Re: [gentoo-user] Re: Kernel boot messages are no longer displayed
The essence of your problem is: you need a working console during your boot sequence if you want to see anything. For an X86 'puter the main two ways to get that are: the VGA console, and the framebuffer console (CONFIG_VGA_CONSOLE, almost always works in a pinch unless you boot from EFI, in which case it probably doesn't work at all). A working framebuffer console needs a working framebuffer. The glue that says (as best I understand it): "hey, Mr. kernel, please don't just leave that framebuffer of mine just lying around doing nothing, let's use it as a console" is CONFIG_FRAMEBUFFER_CONSOLE. Furthermore, CONFIG_EARLY_PRINTK is required if you want the really early junk to whiz by illegibly at the beginning of your boot sequence (the stuff that looks about like the output of "dmesg|head -n 500") If you compiled your framebuffer as a module, it also won't load until that module does. Which means, either until udev starts (and successfully loads the module) or until it gets loaded by some other means, i.e., by script code in an initrd/initramfs. The's a migration, in linuxville, underway now, from the old-school "userspace modesetting" paradigm (where graphic card configuration sorta worked like Windows 95: the "drivers" were hyper-privileged user-land programs running amok) to the newer, shinier "kernel modesetting" paradigm, which finally brings linux, let's say, into a "Windows NT 3.5" sort-of epoch (i.e.: working drivers, at least, finally, in the kernel, where they belong -- but, God help you, if you start hot-plugging stuff or want to use suspend, that stuff all broke). There has been some pain and upheaval. Recipes that used to work have been breaking and you just have to read your logs and some wikis and figure it out, sometimes, the old fashioned way. If you run radeon, well, read the wiki, most of the advice in there is correct and necessary to get a working accelerated system these days -- disabling KMS will break your xorg and your framebuffer entirely! also be /sure/ CONFIG_FB_RADEON and CONFIG_DRM_RADEON_UMS are both OFF (that's the /opposite/ of on!! I mean it!!!) and CONFIG_DRM_RADEON is on (preferably compiled into the kernel). Finally: if you you are using fglrx... well, frankly, your drivers are a sinking ship, bail now while you are still breathing. I'm not up to speed on the latest nvidia trouble but, read the wiki is probably the best advice. On Sat, May 24, 2014 at 8:19 PM, Hilco Wijbenga wrote: > On 24 May 2014 16:53, walt wrote: > > On 05/24/2014 01:20 PM, Hilco Wijbenga wrote: > >> Since kernel 3.12.13 (3.12.13-gentoo), the kernel boot messages have > >> disappeared, i.e. they are no longer displayed at boot time. All I get > >> is a line like "Loading kernel 3.12.13". (I just upgraded to > >> 3.12.20-gentoo, so now it's something like "Loading kernel 3.12.20".) > >> > >> I have no idea why. I checked my grub config and it does not add a > >> "quiet" argument. I see nothing in /etc/rc.conf about quiet (or > >> verbose). And X86_VERBOSE_BOOTUP is set to 'y'. I also looked for > >> "quiet", "boot", and "messages" (while running "make xconfig") and > >> nothing untoward showed up. > >> > >> How do I get back to a normal and sane boot process? > > > > What is the next thing you see after "Loading kernel 3.12.20" ? > > Nothing. There is a pause of a dozen seconds or so and then the login > panel appears. > > By the way, I checked again and it says "Loading Linux 3.12.20-gentoo > ..." (just to be complete and precise). > > > What was the last kernel that booted normally? Does it still boot > > normally? > > I don't quite remember. :-( Probably whatever kernel came before > 3.12.13 but I don't have any leftover configs or anything like that. I > ran the sys-kernel/aufs-sources (to be able to use Docker) so it might > have been one of those but I doubt it. > > > The kernel config files for each kernel are installed as > > /boot/config-3.12.nn so you can compare them to see what changed. > > Well, not by default... :-) In any case, I have deleted it all. It > didn't seem a difficult thing to fix and whenever I had logged in > other stuff happened that made me forget about the boot messages. :-) > It's just today I decided to google for it. Surprisingly, nobody is > complaining about this so it must be something specific to my > environment. I just have no clue what. I certainly did nothing (on > purpose) to get rid of boot messages. > >
Re: [gentoo-user] Chromium browser plugins not listed
On Sat, May 24, 2014 at 8:03 AM, Mick wrote: > Thanks Mike, I didn't know about ppapi - or that this is available as a > separate package. Shouldn't it be drawn in as dependency by Chromium, or > at > least done so by some USE flag? > www-plugins/chrome-binary-plugins will get you chrome-style flash and pdf viewing. As for everything else... well, I have been finding lots of uses for firefox lately... There is a patch out there to re-enable npapi but it's no panacea, believe me. Anyone know of a good chromium fork with less borg-ware and anti-features in it? I'm starting to get fed up. -gmt
Re: [gentoo-user] multiple monitor refresh rates and broken brains (was: fonts and bad eyes)
On Sat, May 17, 2014 at 4:21 AM, David Haller wrote: > Oh, and _very_ importantly: get a _GOOD_ matt monitor if you haven't > yet. > Apologies, David, for hijacking your really good question-thread, which I'm also very eager to hear people's answers to. But, this reminds me of something I've been pondering lately... I think maybe refresh-rate discrepancies are subtly evil in multi-monitor setups. When I look at my 59.9 kHz apple cinema next to my 60 kHz POS Dell throwaway monitor, something spooky clearly happens in my brain -- if I get up close and look carefully, the pixels seem to rather dramatically "swim" near the bezels between the two monitors, in a way that reminds me of a migraine prodrome (perhaps because, to some degree, that's exactly what I'm inducing in my brain, by exposing it to high-frequency polyharmonic interference (presumably, there's a >0.5 MHz harmonic between those two displays, no wonder my brain doesn't like it!). In practice, I don't seem to have had any huge problem from this (and I'm going to get rid of that crappy Dell soon, anyhow) but I have heard reports from people claiming this type of thing caused eye fatigue and headaches. My semi-baseless theory is that, so long as the remainders of the greatest common multiples of your various monitors' refresh-rates form nice clean ratios like 1:2, 2:3, etc, you probably won't fry your wetware input circuitry looking at them. However, if, as above, there are ugly harmonics, I suspect it might be pretty bad for some people. If, like me, you're too cheap for the 100% solution of buying identical monitors, maybe just try to ensure everything you buy supports standard 60kHz standard modes, or even go read the 1990's-era ModeLine authoring FAQ's and attempt to actually understand the problem and fix it, if you're feeling ambitious :) Anyhow... we now return to our regularly schedule programming... -gmt
Re: [gentoo-user] btrfs only, without dracut
On Sat, May 17, 2014 at 8:56 AM, Stefan G. Weichinger wrote: > It seems to not detect or interpret correctly the fact that there are 2 > physical devices in there and then the "linux ..." line for grub.cfg > gets messed up, at least for me here. > ACK, genkernel initramfs doesn't "btrfs scan" and TSHTF. genkernel-next works though. But if you have it working now without any initramfs then obviously that is full of win (the LA kind, not the Redmond variety)! I am a bit mystified -- or perhaps ignorant -- as to how it came to be that btrfs has no option to automatically initiate a scan (like md raid does, when it's built into the kernel as a non-module). Surely people must want that feature. I can see how scanning the wrong partitions could lead to terrible mayhem, though, say, in a disaster recovery scenario where you binary-cloned a failing drive and forgot to take the old one out before booting or whatever but btrfs has the secret sauce to most likely figure stuff like that out auto-magically anyhow, using the genid... so what gives? Anyone know? Perhaps the option really is there and I simply never found it; admittedly I didn't look very hard -- regardless, I can't imagine the btrfs people just "never thought of it". If i's really not implemented, there must be a reason... and if that reason doesn't apply to my situation I might consider patching such a feature into my kernels as this is the only thing tying my workstation to an initramfs. -gmt
Re: [gentoo-user] Re: Portage performance dropped considerably
On Mon, Feb 3, 2014 at 2:55 AM, Martin Vaeth wrote: > On fast processors > portage's speed is not so much a big issue. What kind of processor have you got, and where can I get one? -gmt
Re: [gentoo-user] Portage performance dropped considerably
On Sun, Jan 26, 2014 at 6:35 AM, Nikos Chantziaras wrote:
> Anyone else noticed this yet? Some portage update seems to have made "emerge
> -uDN @world" perform about 10 times slower than before. It used to take
> seconds, now it takes about 4 minutes only to tell me that there's nothing
> to update. And it does that every time, even directly in succession and with
> the caches warm.
>
> Is it just me?
Usually this occurs when you have done something that causes portage
to stop using the metadata that rolls in via rsync. The classic
example of something that will cause this is setting some
eclass-overrides in /etc/portage/repos.conf.
As of yesterday, portage still performed tolerably on a relatively
vanilla base system.
That stated, you're not hallucinating. Portage is slow as tar. I
suspect it's getting slower at least partially as a result of the
recent explosion of multilib-build-based ebuilds for multimedia and
x11 library ebuilds, and perhaps also due to those nasty
emul-linux-x86 blockers (a problem that will eventually be resolved,
Larry-The-Cow-God-willing, within a year or three) that are placing
higher and higher demands on portage's depsolving engine, as time
passes.
Having lots and lots of packages installed is a huge factor here.
This may be because, by default, portage uses installed packages to
calculate dependencies, resulting in a need to re-cache lots of
stuff... I'm a bit fuzzy on exactly what criteria are used to
determine when this happens, tbh.. that's something I've been meaning
to look into.
Adding something like:
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --backtrack=5"
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --complete-graph=n"
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --complete-graph-if-new-use=n"
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --complete-graph-if-new-ver=n"
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --with-bdeps=n"
to you /etc/portage/make.conf may help, as may running emerge
--metadata and/or egencache on your repos. after syncing... but...
these are no panacea.
Sometimes emerge -O is the only way to get some things done in any
reasonable time-frame.
It would help if there were some decent way to get some statistics
about where portage is spending all its time (especially, I suspect,
within the bash code, but the python level would also be interesting
to analyse). Anyone know of a good way of doing that?
-gmt
Re: [gentoo-user] Kernel ricing thread take 2
On Thu, Oct 24, 2013 at 9:18 PM, Adam Carter wrote:
>
> To build with other flags you set CFLAGS_KERNEL, so i've added a suitable
> -march to the standard ones for my system;
> export CFLAGS_KERNEL=" -Wall -Wmissing-prototypes -Wstrict-prototypes -O2
> -fomit-frame-pointer -pipe -march=amdfam10"
>
> then make, install, reboot. In my case the riced kernel is the same size as
> the regular one, but the md5 is different. Its been up for an hour with no
> obvious issues, and does seem snappier, but of course my brain is full of
> cognitive bias. Has anyone else played with this? Any good or bad outcomes?
>
FWIW, have found that some kernel module ebuilds fail to pick these
hacks up, if you are using them, and, indeed, (erroneously?) respect
{C,XXFLAGS}. An example that comes to mind is vmware-modules. I have
a script that extracts the CFLAGS from the Makefile and then exports
them and invokes modules-rebuild or whatever the correct name of that
is not really anything I'd like to share, it's a pretty
embarrassingly ugly script with lots of system-specific crud... been
meaning to clean it up one of these days for general consumption.
Anyhow, whether you rice your kernel in this way or not, that is
something to think about.
In general, I am pretty uncomfortable messing with the kernel CFLAGS.
You might want to ask yourself: do I really have a complete
understanding of how my riced CFLAGS might affect things like state
pickling during kernel context switching? Non-standard points in the
code-base such as early boot, when it might not be safe to assume that
the kernel is not in some crazy intermediate state with respect to
memory layout, exception handling, etc.? Will my flags create function
invocation ABI incompatibilities that require corresponding changes in
kernel assembler code? After digging into it just a little, I pretty
much came to the conclusion, persnally, that I didn't have clear
answers to those questions and that it wasn't worth the risk of
creating (even more) buggy kernels. Is there macro magic that might
break? I decided, for myself, against any such kernel-cflag rice, but
I do have hardware RAID with dead battery backup batteries (which I
perpetually never get around to replacing) ... makes crashing my
kernel pretty damn expensive, and I try only to do it in emulators, if
at all possible (far too often, I crash them anyhow). You might have
a much more crash-friendly environment or have spare hardware lying
around that you can experiment with in a consequence-free environment.
Not saying don't go for it... but my advice would be, basically, think
carefully before you frob unless you're OK with the idea of running a
potentially extra-buggy kernel.
--
gmt
Re: PORTDIR default - changing PORTDIR variable - WAS Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01
On Tue, Oct 1, 2013 at 2:24 PM, Alan McKinnon wrote: > On 01/10/2013 20:48, Neil Bothwick wrote: >> On Tue, 01 Oct 2013 14:15:49 -0400, Tanstaafl wrote: >> >>> I'm interested in what the DEFAULTS are, ie, for a new/from scratch >>> installation. >> >> Why? If ever there was a distro for people that didn't want to use >> defaults, Gentoo is it. >> >>> Someone had to decide the defaults - so, what are they? Anyone? >> >> I installed a VM a couple of weeks ago and I'm sure portage was still >> in /usr. It's easy enough to tell, unpack a stage 3 and see where the >> portage directory lives, but the handbook still refers to /usr/portage. >> >> > > Please say it isn't so, otherwise I'm going to look like a right royal > chump. > > Or maybe I just change it all on automatic these days and forget it do > it. But it was definitely discussed on -dev at length. i could be wrong > about the end result > Looks like it's still usr/portage here... http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=pym/portage/repository/config.py;h=0d6edf4e3e6dcffb0758caf859a597a8f0996bc0;hb=HEAD#l615 and here http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=cnf/repos.conf;h=8c657daae3259e42e01ea05c689b74293b5224a7;hb=HEAD#l5 I don't see repos.conf in gx86 and I don't see PORTDIR in any gx86-provided make.defaults'es as of yesterday. So I guess it's still usr/portage. I do think I vaguely recall that discussion about /var too though... frankly, /var seems more sensible ... but maybe that's a can of worms I should not be opening in this thread :) -gmt
Re: [gentoo-user] emerge --sync issue on only one comp on LAN
On Tue, Oct 1, 2013 at 7:20 AM, Bruce Hill wrote: > There are 3 (or more) computers which sync (sometimes daily) on my LAN at > work: server, router, and workstation. server has issues almost all the time > getting a rsync server (for lack of better way to state it). All three comps > have the exact same SYNC in make.conf: Seriously? Your problem is that an incredible build-up of bad karma has polluted your network. You are selfishly and pointlessly wasting the rsync.us.gentoo.org mirror network's resources, and your own bandwidth as well. Run rsyncd somewhere. Sync the other two systems to it. If the server has problems with outbound connectivity, use the router, I guess. Rsync mirrors don't grow on trees, man. People pay good money to provide that service to us. You should seriously be embarrassed to have posted this. -gmt
