Re: [gentoo-user] Questions about optimal mplayer settings
On Tue, 18 Dec 2012 19:05:14 -0600 Dale rdalek1...@gmail.com wrote: This may help, may not. When I was playing with this a year or so ago, I found a HD test video on the internet somewhere. I'm pretty sure it was 1080p. I set smplayer to play and repeat the video and then I watched the CPU and temps on the video card. I would try each setting and see how much CPU load there was and watched the temps on the video card. I figure if the card temps are warmer, it is giving the card a work out instead of my CPU. Personally I use a local Bluray 1080p rip of Transformers3 for that. I figure if the scene with Optimus and Sentinel bashing hunks off each other doesn't give a GPU a decent work-out, then nothing will and it's a fun movie, much more interesting to watch than temp guages -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 18 Dec 2012 17:55:16 -0500 Michael Mol mike...@gmail.com wrote: On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue, 18 Dec 2012 09:08:53 -0500 Michael Mol mike...@gmail.com wrote: This sentence summarizes my understanding of your post nicely: Now, why is /usr special? It's because it contains executable code the system might require while launching. Now there are only two approaches that could solve that problem: 1. Avoid it entirely 2. Deal with it using any of a variety of bootstrap techniques #1 is handled by policy, whereby any code the system might require while launching is not in /usr. This is the solution I favor. Systemic structure which allows dependency leakage is indicative (to me) of lack of foresight and proper component role limitation, and ought to be fought. #2 already has a solution, it's called an init*. Other solutions exist but none are as elegant as a throwaway temporary filesystem in RAM. I find virtually nothing elegant about a temporary filesystem in RAM. It duplicates code that already exists on the system, and it represents and additional maintenance step in system upgrades. It seems almost a given that if someone is keeping multiple kernel images on a system, they're not updating the initr* for each when binaries that would be found in each are upgraded or rebuilt. You could level the same criticism at boot loaders... The also duplicate functionality in the main system they launch (albeit read-only at least in legacy grub) in the fs drivers, are only used briefly at boot-time and have to be maintained. True, the bootloader doesn't contain a *copy* of the main system files which is where the parallel breaks down. init* may well suck, but they suck less than any other possible solution. And they come with one more benefit - the community has agreed on how they work so they form a standard of sorts In Debian, Ubuntu and others, this is handled by a post-install hook where the initr* image is rebuilt. To me, this honestly feels like a hack. In something like Gentoo, I'd rather see package placement driven by whether or not it will be needed to get all mount points mounted. If that means i18n databases under something like /boot/data, that seems reasonable. To me, the only cases where initr* feels like the right solution are things like netboot or booting from read-only media. Let's not forget the prime reason why init* exists - so that binary distros can boot and still have all kernel modules required at launch time compiled as modules. Bootstrap code and operation is ugly, always has been and always will be. It also tends to be inflexible unless you use a slipstreaming technique (my invented description of how init* works). I still think the solution is elegant given the real-world requirements imposed on systems. I should be clear that I do not necessarily support Lennart's solutions, but I do support his perception of the problem (at least partially). We cannot support situations where *launch* code is haphazardly scattered in location X and this must always work for all values of X. We already have a remarkably parallel situation in /boot - in order to boot at all, the code running at that point in time needs to be able to find stuff, and it finds it (by policy) in what we will later call /boot. I see this /usr debate as the same thing on a larger scale. -- :wq -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 18 Dec 2012 22:05:21 -0500 Michael Mol mike...@gmail.com wrote: I don't use separate initr* files, the initramfs is built into the kernel, using the latest versions of the tools installed at the time the kernel was compiled. That gives a single bootable file that, if it works now, should always work. Most changes to the component packages do not affect the simple job they have to do to get a system ready to run init. Just because it runs, doesn't mean it works. For example, let's say your network now requires an additional protocol for the host to operate properly. Or let's say there's a security vulnerability in some network-aware component in your initramfs. Or that some piece of automounter code is vulnerable to corrupted filesystems on flash drives. To borrow your own term, all that falls fair and square under the heading of unforeseen operational requirements demanded it Things change, packagers and sysadmins must react. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 18 Dec 2012 22:05:21 -0500, Michael Mol wrote: I don't use separate initr* files, the initramfs is built into the kernel, using the latest versions of the tools installed at the time the kernel was compiled. That gives a single bootable file that, if it works now, should always work. Most changes to the component packages do not affect the simple job they have to do to get a system ready to run init. Just because it runs, doesn't mean it works. For example, let's say your network now requires an additional protocol for the host to operate properly. Or let's say there's a security vulnerability in some network-aware component in your initramfs. Or that some piece of automounter code is vulnerable to corrupted filesystems on flash drives. Those are unreasonable, if somewhat unlikely, scenarios. It would be simple to add a post_install hook that checks if a package used by your initramfs has been updated and uses einfo to advise you to rebuild your initramfs/kernel. -- Neil Bothwick Man and mouse are alike, both end up in pussy :) signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, 19 Dec 2012 09:38:14 +, Neil Bothwick wrote: Those are unreasonable, if somewhat unlikely, scenarios Ack! Too many uns s/unreasonable/reasonable/ -- Neil Bothwick With free advice you often get what you pay for. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Questions about optimal mplayer settings
Bruce Hill wrote: The youtube-dl program works for more sites than just YouTube. And I chose it for the links you provided, specifically because they were YouTube videos. Give /usr/share/doc/youtube-dl-2012.09.27/README.md.bz2 a read. The file fluctuated but the overall speed was 1.77M/s ... don't ever remember getting that type of speed in FF. This shows (via gkrellm) the effects it had playing on this system: http://www.servantsofyeshua.org/XITHbsUUlYI.mp4-screenshot.png Didn't really heat my GPU (temp1) over 38C, and it's normally around 31C. Here's another file check on the MP4: mingdao@workstation ~/test $ md5sum XITHbsUUlYI.mp4 dab460274c1ce3ed8ebaf7caa6c0ad02 XITHbsUUlYI.mp4 Even before Walter's reply to me, I'd rebuilt mesa with new flags: media-libs/mesa-9.0 USE=classic egl g3dvl gallium llvm nptl r600-llvm-compiler shared-glapi xa xvmc -bindist -debug -gbm -gles1 -gles2 -openvg -osmesa -pax_kernel -pic (-selinux) -vdpau (-wayland) -xorg VIDEO_CARDS=r600 -i915 -i965 -intel -nouveau -r100 -r200 -r300 -radeon -radeonsi -vmware Hopefully tomorrow I've have time to check. I'd also saved the old /var/log/Xorg.0.log from before rebuilding mesa. And then there are other comps with other chipsets on this LAN to try. Thanks for the replies. One reason I download them, I play them in full screen mode and it doesn't stutter either. Generally, full screen seems to make it work a bit harder, unless your desktop has things in motion too. ;-) When I use Seamonkey to download, it goes as fast as my DSL will let it. Sometimes, the server on the other end will have high loads and slow things down but generally, it's as fast as my connection either way. For me, downloadhelper is just easier. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Questions about optimal mplayer settings
Am 19.12.2012 00:20, schrieb Walter Dnes: 1) In the past couple of days I finally figured out what I was doing wrong with hardware acceleration (causing lack thereof) with an onboard Intel GPU in my HTPC machine. I've applied the same fix to my desktop. mplayer now has 5 video output modes that actually show a picture... xv X11/Xv This doesn't use any GPU features. Good compatibility but otherwise not recommended. gl_nosw OpenGL no software rendering Same as gl just that it fails when you have driver issues that prevent it from using the GPU. More like a debugging tool. x11 X11 ( XImage/Shm ) Practically outdated. gl OpenGL Recommended. Should work okay without further tuning but offers a lot of them. Just play around. gl2 X11 (OpenGL) - multiple textures version Unmaintained. Use gl. Which one has the best playback ability? Is there a test program or a torture test video file I can use for testing? 2) When I start up mplayer, the diagnostics include... MMX2 supported but disabled There is no mmx2 in the USE flags or in /proc/cpuinfo That should be USE=mmxext. No clue what's its name in cpuinfo but since you are running something newer than a P3 it should be a safe bet. PS: Have to tried mplayer2? It's mostly compatible but offers no mencoder support but you can install mplayer to get that. It has better threading support and some other minor improvements. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, Dec 19, 2012 at 4:26 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue, 18 Dec 2012 17:55:16 -0500 Michael Mol mike...@gmail.com wrote: On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue, 18 Dec 2012 09:08:53 -0500 Michael Mol mike...@gmail.com wrote: [snip] #2 already has a solution, it's called an init*. Other solutions exist but none are as elegant as a throwaway temporary filesystem in RAM. I find virtually nothing elegant about a temporary filesystem in RAM. It duplicates code that already exists on the system, and it represents and additional maintenance step in system upgrades. It seems almost a given that if someone is keeping multiple kernel images on a system, they're not updating the initr* for each when binaries that would be found in each are upgraded or rebuilt. You could level the same criticism at boot loaders... The also duplicate functionality in the main system they launch (albeit read-only at least in legacy grub) in the fs drivers, are only used briefly at boot-time and have to be maintained. True, the bootloader doesn't contain a *copy* of the main system files which is where the parallel breaks down. Bootloaders tend to be updated in a targeted or atomic fashion. This remains true even as they become more and more like full operating systems. init* may well suck, but they suck less than any other possible solution. I disagree. I think defining boot stages, and fixing cross-stage dependency errors, is a far better solution. And they come with one more benefit - the community has agreed on how they work so they form a standard of sorts In Debian, Ubuntu and others, this is handled by a post-install hook where the initr* image is rebuilt. To me, this honestly feels like a hack. In something like Gentoo, I'd rather see package placement driven by whether or not it will be needed to get all mount points mounted. If that means i18n databases under something like /boot/data, that seems reasonable. To me, the only cases where initr* feels like the right solution are things like netboot or booting from read-only media. Let's not forget the prime reason why init* exists - so that binary distros can boot and still have all kernel modules required at launch time compiled as modules. Another valid use case. Bootstrap code and operation is ugly, always has been and always will be. It also tends to be inflexible unless you use a slipstreaming technique (my invented description of how init* works). I still think the solution is elegant given the real-world requirements imposed on systems. And I still think that, outside of scenarios where workarounds don't exist, it's an ugly hack and a cop-out. -- :wq
[gentoo-user] Some files in /usr/share/doc are not compressed
Hello. On my system Portage uses the following two variables for compressing files in /usr/share/doc: $ portageq envvar PORTAGE_COMPRESS xz $ portageq envvar PORTAGE_COMPRESS_EXCLUDE_SUFFIXES css gif htm[l]? jp[e]?g js pdf png It seems anyway that some files are not compressed: $ find /usr/share/doc -type f -regextype posix-extended ! -regex .*\.(css|gif|htm[l]?|jp[e]?g|js|pdf|png|xz) | wc -l 79 I won't list all of them here, just some examples: /usr/share/doc/gnome-shell-3.4.2/AUTHORS /usr/share/doc/udisks-2.0.0/html/udisks2/index.sgml /usr/share/doc/groff-1.21-r1/pic.ps /usr/share/doc/automake-1.12.5/amhello-1.0.tar.gz My goal is to have everything under /usr/share/doc compressed with xz, or at least to understand why something is being excluded from compression. Perhaps it is due to some additional rules I'm not aware of, or because of some bugs. I checked the ebuilds of the packages the previous files belong to, but I found nothing interesting. It would be great if anyone who is interested could check his/her own system too. Thank you.
Re: [gentoo-user] Re: Anyone switched to eudev yet?
with redhat's push to move everything into /usr - why not stop right there and move everything back into /? seperate /home, /var, /dev and /tmp makes sense (not counting proc, sys for obvious reasons). But the rest? Why /usr/lib? Just /lib would be fine. Remember how once there was a whole X11 subtree in /usr? /usr/tmp - wtf? Just empty /usr and be happy... I wish I could do that... -- #163933
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
Am Dienstag, 18. Dezember 2012, 23:02:41 schrieb Marc Joliet: Am Tue, 18 Dec 2012 13:34:07 + schrieb Kevin Chadwick ma1l1i...@yahoo.co.uk: [...] Going back in time his claim of pulse audio being good for professional audio was also completely off the mark. Seperating Gnome and pulse can now cause pro audio users on binary distro's major headaches too. I pointed one fellow in the direction of a pro audio on gentoo tutorial rather than deal with some new problems a little after systemd hit Arch. Holy cow, did he really? Link, please! I thought pulseaudio was only ever advertised for desktop and some embedded use cases, and that Lennart is perfectly aware of the fundamental differences between JACK and PA and that they target a completely different range of applications [0]. I wouldn't *dream* of using anything other than JACK (with LADISH) for pro-audio work (well, more like home recording in my case, but close enough). I actually like pulseaudio for desktop use, though. When you start JACK it will kindly get out of the way, so the two aren't necessarily mutually exclusive (actually, you can set it up to automatically set up ports in JACK2 with the jackdbus-detect module, if you want that). After a few years of use I finally ended up requiring one of its more advanced features: moving streams between sound cards at runtime. [0] http://0pointer.de/blog/projects/when-pa-and-when-not.html remember this? a solution without a problem to solve, making a lot of people's lifes harder, dropped onto them by the godlike Lennart P.? http://lalists.stanford.edu/lad/2009/06/0218.html -- #163933
Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code
XMPP clients are a dime a dozen, take you pick: pidgin, kopete, telepathy and a hots of others. Servers are another story. All of them that you can lay your hands on seem to suck big eggs big time. ejabberd is the only one I found stable enough to actually stay up for sane amounts of time, and not DEPEND on java. But that info might be well out of date, I haven't looked at our jabber server for ages. There's no need to - the techies all gravitated by themselves over to GTalk and Skype, claiming that the cloud services did everything they needed and more, and it was there, and it worked. Our in-house jabber server - not so much. Can't say I blame them. It's true. Thanks Alan, this is just the kind of info I need. It sounds like I would be better off with a cloud solution for collaborative chat. Just out of curiosity: why couldn't you use a Jabber client with Bonjour/Zeroconf support (all or most of them?) within the company (which is what this is for IIUC)? With Zeroconf, the Jabber clients find each other, then you wouldn't need to bother with setting up a server. Or is Zeroconf problematic? I know Pidgin can do Zeroconf on Windows, even if you need to manually install a separate package for it to work. That doesn't really work when one fellow is at his desk in the office, another at home on an ADSL connection and the third is a 3rd party dev based in Los Angeles. That's quite common for me. Zeroconf has it's uses, but it does have a rather narrow scope as to where it can work. I understand that, I just thought that Grant was talking about a purely internal chat solution (like my workplace has) - he did say within a company (though admittedly in retrospect I realize that that doesn't necessarily mean *physically* within the company). Regardless, it isn't clear to me that Grant is talking about something that has to be available from anywhere. While he is apparently gravitating towards a cloud solution for chat, my understanding is that that is because then he doesn't have to manage his own server. All of the other solutions mentioned could be for internal *and* external use. Anyway, I was just curious and thought that if this is purely for internal use than Zeroconf might be a good server-less option for chat. I should have specified that the people in the organization are spread out in different locations. It sounds like it is difficult/dangerous to run an internet-facing IRC server and ejabberd is unstable? Besides chat, has anyone tried egroupware? - Grant
Re: [gentoo-user] {OT} open-source: chat, tasks, resources, code
On Wed, Dec 19, 2012 at 3:14 PM, Grant emailgr...@gmail.com wrote: XMPP clients are a dime a dozen, take you pick: pidgin, kopete, telepathy and a hots of others. Servers are another story. All of them that you can lay your hands on seem to suck big eggs big time. ejabberd is the only one I found stable enough to actually stay up for sane amounts of time, and not DEPEND on java. But that info might be well out of date, I haven't looked at our jabber server for ages. There's no need to - the techies all gravitated by themselves over to GTalk and Skype, claiming that the cloud services did everything they needed and more, and it was there, and it worked. Our in-house jabber server - not so much. Can't say I blame them. It's true. Thanks Alan, this is just the kind of info I need. It sounds like I would be better off with a cloud solution for collaborative chat. Just out of curiosity: why couldn't you use a Jabber client with Bonjour/Zeroconf support (all or most of them?) within the company (which is what this is for IIUC)? With Zeroconf, the Jabber clients find each other, then you wouldn't need to bother with setting up a server. Or is Zeroconf problematic? I know Pidgin can do Zeroconf on Windows, even if you need to manually install a separate package for it to work. That doesn't really work when one fellow is at his desk in the office, another at home on an ADSL connection and the third is a 3rd party dev based in Los Angeles. That's quite common for me. Zeroconf has it's uses, but it does have a rather narrow scope as to where it can work. I understand that, I just thought that Grant was talking about a purely internal chat solution (like my workplace has) - he did say within a company (though admittedly in retrospect I realize that that doesn't necessarily mean *physically* within the company). Regardless, it isn't clear to me that Grant is talking about something that has to be available from anywhere. While he is apparently gravitating towards a cloud solution for chat, my understanding is that that is because then he doesn't have to manage his own server. All of the other solutions mentioned could be for internal *and* external use. Anyway, I was just curious and thought that if this is purely for internal use than Zeroconf might be a good server-less option for chat. I should have specified that the people in the organization are spread out in different locations. It sounds like it is difficult/dangerous to run an internet-facing IRC server and ejabberd is unstable? This is what VPNs are for. I haven't really heard anything seriously problematic about ejabberd outside of some folks dislike of adding another language runtime. Whatever you decide to run internally, you're going to need to become knowledgeable in its administration. This is why a fair amount of folks are outsourcing communications infrastructure. Few believe they have the time to learn to manage the thing properly. -- :wq
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, Dec 19, 2012 at 07:48:45PM +0100, Volker Armin Hemmann wrote remember this? a solution without a problem to solve, making a lot of people's lifes harder, dropped onto them by the godlike Lennart P.? http://lalists.stanford.edu/lad/2009/06/0218.html The thread was started by Lennart. In the first message http://lalists.stanford.edu/lad/2009/06/0191.html he says... If you don't do RT development or doing RT development only for embedded cases, or if you are a Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy then it doesn't mean anything for you. And people wonder why Gentoo-ers dislike the guy. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, 19 Dec 2012 19:42:01 +0100 Volker Armin Hemmann volkerar...@googlemail.com wrote: with redhat's push to move everything into /usr - why not stop right there and move everything back into /? seperate /home, /var, /dev and /tmp makes sense (not counting proc, sys for obvious reasons). But the rest? Why /usr/lib? Just /lib would be fine. Remember how once there was a whole X11 subtree in /usr? /usr/tmp - wtf? Just empty /usr and be happy... I wish I could do that... Well at least you don't have to put up with /usr/X11 anymore :-) That took ripping out the entire XFree86 build system and replacing it with something at least half-way sane that supported --prefix I'm not too concerned with modern /usr on the whole, the layout is something I can tolerate. What *really* gets my goat up is /var/lib. Now what on this earth could /var/lib/ possibly be useful for Surely not libs, those go in /usr/lib or /lib. If it's variable data somehow related to libs then someone needs to look up lib in a dictionary. If it really is lib code, then my question is how exactly is this stuff variable to warrant being in /var? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Some files in /usr/share/doc are not compressed
On Wed, 19 Dec 2012 17:41:30 +0100 Francesco Turco ftu...@fastmail.fm wrote: Hello. On my system Portage uses the following two variables for compressing files in /usr/share/doc: $ portageq envvar PORTAGE_COMPRESS xz $ portageq envvar PORTAGE_COMPRESS_EXCLUDE_SUFFIXES css gif htm[l]? jp[e]?g js pdf png It seems anyway that some files are not compressed: $ find /usr/share/doc -type f -regextype posix-extended ! -regex .*\.(css|gif|htm[l]?|jp[e]?g|js|pdf|png|xz) | wc -l 79 I won't list all of them here, just some examples: /usr/share/doc/gnome-shell-3.4.2/AUTHORS /usr/share/doc/udisks-2.0.0/html/udisks2/index.sgml /usr/share/doc/groff-1.21-r1/pic.ps /usr/share/doc/automake-1.12.5/amhello-1.0.tar.gz My goal is to have everything under /usr/share/doc compressed with xz, or at least to understand why something is being excluded from compression. Perhaps it is due to some additional rules I'm not aware of, or because of some bugs. I checked the ebuilds of the packages the previous files belong to, but I found nothing interesting. It would be great if anyone who is interested could check his/her own system too. That stuff is controlled by the ebuild, IIRC ebuilds should call function dodoc so they do with docs what you want them to do. The function name may well have changed and been superceded since last I looked. The reason you find nothing interesting in the ebuild is because something that should be there isn't. ebuilds not following rules wrt doc files is a bug and should be filed at bgo as such. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Installing swi-prolog and gnustep-base in the same time
Hi, it seems, that swi-prolog and gnustep-base cannpot be installed in the same time because both packages share the same file /usr/bin/pl what is the best solution, to handle this situation? Regards
[gentoo-user] kernel 3.7 - internal 'udev'; signed lkms; file hash validation
Found this interesting: http://www.h-online.com/open/features/Kernel-Log-Coming-in-3-7-Part-3-Infrastructure-1755953.html Are there Gentoo guidelines on using these new kernel features? TIA
Re: [gentoo-user] Questions about optimal mplayer settings
On Wed, Dec 19, 2012 at 03:38:15PM +0100, Florian Philipp wrote gl OpenGL Recommended. Should work okay without further tuning but offers a lot of them. Just play around. [...deletia...] 2) When I start up mplayer, the diagnostics include... MMX2 supported but disabled There is no mmx2 in the USE flags or in /proc/cpuinfo That should be USE=mmxext. No clue what's its name in cpuinfo but since you are running something newer than a P3 it should be a safe bet. Thanks for the feedback. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Surely not libs, those go in /usr/lib or /lib. If it's variable data somehow related to libs then someone needs to look up lib in a dictionary. I have to say I was shocked a while back when I found /usr/bin/firefox linking to a shell script at /usr/lib/firefox/firefox I'd be interested if anyone can explain that oddity? I see one other on this system. Perhaps systemd-udev copied firefox? If it really is lib code, then my question is how exactly is this stuff variable to warrant being in /var? Maybe it's for JIT on steroids. JIT for pid1, what an unnerving thought. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
[gentoo-user] Re: OpenRC error message at boot
On 12/18/2012 01:07 AM, Francesco Turco wrote: On Tue, Dec 18, 2012, at 9:49, Dale wrote: If the RC_DEBUG setting is not there, add it. There are lots of settings that are not in there by default but you can add them if you need to. It's strange because all variables in my /etc/rc.conf file are lowercase (for example rc_interactive, rc_parallel, ...). Perhaps we are not discussing the same openrc version. Also, with equery files --filter=man/doc openrc, I couldn't find a documentation file where there is a list of all possible variables for rc.conf. It seems rc.conf itself is such a file, and I already check it for a debug variable, without success. I find obscure man pages like this: $qlist openrc |grep man The openrc package includes about twenty man pages, all of which look like they were written for developers instead of us (l)users. I (re)discovered the RC_DEBUG variable like this: $grep -ri debug /lib64/rc/* I say rediscover because I remember using it years ago when I was playing with the *BSD operating systems, but without using grep I couldn't possibly remember that. There are some questions that require a group of old farts, and you have found one in this mailing list :)
Re: [gentoo-user] Re: OpenRC error message at boot
On Wed, Dec 19, 2012 at 05:25:13PM -0800, walt wrote: that. There are some questions that require a group of old farts, and you have found one in this mailing list :) Something smells ... bad ... here. :( -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Some files in /usr/share/doc are not compressed
Am Thu, 20 Dec 2012 00:11:38 +0200 schrieb Alan McKinnon alan.mckin...@gmail.com: On Wed, 19 Dec 2012 17:41:30 +0100 Francesco Turco ftu...@fastmail.fm wrote: Hello. On my system Portage uses the following two variables for compressing files in /usr/share/doc: $ portageq envvar PORTAGE_COMPRESS xz $ portageq envvar PORTAGE_COMPRESS_EXCLUDE_SUFFIXES css gif htm[l]? jp[e]?g js pdf png It seems anyway that some files are not compressed: $ find /usr/share/doc -type f -regextype posix-extended ! -regex .*\.(css|gif|htm[l]?|jp[e]?g|js|pdf|png|xz) | wc -l 79 I won't list all of them here, just some examples: /usr/share/doc/gnome-shell-3.4.2/AUTHORS /usr/share/doc/udisks-2.0.0/html/udisks2/index.sgml /usr/share/doc/groff-1.21-r1/pic.ps /usr/share/doc/automake-1.12.5/amhello-1.0.tar.gz My goal is to have everything under /usr/share/doc compressed with xz, or at least to understand why something is being excluded from compression. Perhaps it is due to some additional rules I'm not aware of, or because of some bugs. I checked the ebuilds of the packages the previous files belong to, but I found nothing interesting. It would be great if anyone who is interested could check his/her own system too. That stuff is controlled by the ebuild, IIRC ebuilds should call function dodoc so they do with docs what you want them to do. The function name may well have changed and been superceded since last I looked. Indeed: starting with EAPI 4 there is a DOCS variable for this. ebuild(5) says it can be an array or a space delimited list, but for me (using EAPI 5) only the array version worked. However, a default list of files is used when it isn't specified. [...] -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 20, 2012 at 2:42 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: with redhat's push to move everything into /usr - why not stop right there and move everything back into /? I originally thought this way, but they actually reviewed the technical and historical merits for all the use cases and and found /usr to be superior. Straight out of the freedesktop wiki: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge 0) If / and /usr are kept separate, programs in /usr can't be updated independently of programs in /, because the libraries they depend on might break compatibility. If the binaries and libraries were *all* in /usr, then the entire system's binaries would always be consistent regardless of where /usr were sourced from (config files in /etc, however, would still break). 1) There is historical precedent in Unix for /usr-centric systems, notably Solaris. 2) If /usr were separated from /, then /usr could be mounted read-only, with / being mounted normally. Which makes sense, as / does have bits that are meant to be read-write. 3) Most software packagers write their binaries to a PREFIX defaulting to /usr/local, or /usr, as opposed to /. Determining which ones belong in / or /usr can sometimes be dependent on the distro and/or sysad. But since more of them default to /usr, if everything were in /usr it'd be a saner default. (0) basically says that keeping them separate only works as intended if the both the sysad and the distro upstream work together for their shared /usr mount. In many cases, however, sysads have to do a lot of working around and careful planning to get /usr mounted remotely. (1), (2), and (3) provide advantages to mounting the binaries and libraries separately from the / filesystem, which mounting them as part of / does not provide.
[gentoo-user] How do I remove a module from ENLIGHTENMENT_MODULES?
I want to remove the connman module from ENLIGHTENMENT_MODULES. I've put this in my make.conf: ENLIGHTENMENT_MODULES = -connman But it doesn't work; emerge complains: Invalid '-' operator in non-incremental variable 'ENLIGHTENMENT_MODULES': '-connman' So how does this work?
Re: [gentoo-user] How do I remove a module from ENLIGHTENMENT_MODULES?
On 12/19/2012 22:15, Nikos Chantziaras wrote: I want to remove the connman module from ENLIGHTENMENT_MODULES. I've put this in my make.conf: ENLIGHTENMENT_MODULES = -connman But it doesn't work; emerge complains: Invalid '-' operator in non-incremental variable 'ENLIGHTENMENT_MODULES': '-connman' So how does this work? Non-incremental variable means it will reset whenever you assign to it. Thus, all you need to do is specify only what modules you want; anything not specified will be excluded. -- ♫Dustin
[gentoo-user] Re: How do I remove a module from ENLIGHTENMENT_MODULES?
On 20/12/12 06:26, Dustin C. Hatch wrote: On 12/19/2012 22:15, Nikos Chantziaras wrote: I want to remove the connman module from ENLIGHTENMENT_MODULES. I've put this in my make.conf: ENLIGHTENMENT_MODULES = -connman But it doesn't work; emerge complains: Invalid '-' operator in non-incremental variable 'ENLIGHTENMENT_MODULES': '-connman' So how does this work? Non-incremental variable means it will reset whenever you assign to it. Thus, all you need to do is specify only what modules you want; anything not specified will be excluded. I want to have the defaults for it, except connman. The defaults are provided by the ebuild (and they can change from version to version; I can't keep track of that.)
Re: [gentoo-user] Re: How do I remove a module from ENLIGHTENMENT_MODULES?
On Thu, Dec 20, 2012 at 6:32 AM, Nikos Chantziaras rea...@gmail.com wrote: On 20/12/12 06:26, Dustin C. Hatch wrote: On 12/19/2012 22:15, Nikos Chantziaras wrote: I want to remove the connman module from ENLIGHTENMENT_MODULES. I've put this in my make.conf: ENLIGHTENMENT_MODULES = -connman But it doesn't work; emerge complains: Invalid '-' operator in non-incremental variable 'ENLIGHTENMENT_MODULES': '-connman' So how does this work? Non-incremental variable means it will reset whenever you assign to it. Thus, all you need to do is specify only what modules you want; anything not specified will be excluded. I want to have the defaults for it, except connman. The defaults are provided by the ebuild (and they can change from version to version; I can't keep track of that.) In your package.use x11-wm/enlightenment -enlightenment_modules_connman enlightenment_modules_module-name in general for each one you wanna turn off individually
