[gentoo-user] Per-package splitdebug FEATURE
Hi. I've turned on splitdebug feature (and -ggdb in CFLAGS) so debug information are saved and I can debug anything that crashes. I went to /usr/lib/debug, just out of curiosity, to see how much space was taken and I found that it was almost 2GB, which chromium + firefox adds up 1.5GB and python gets another 0.3. I would like to disable splitdebug for these specific packages now and in the future, so removing splitdebug from features, re-emerging them and then activating splitdebug again won't quite cut. I wonder if there's a way to active features to some specific packages, just like USE flags. Thank you. -- Leonardo
Re: [gentoo-user] systemd
On Monday, August 22, 2011 11:09:02 PM Stefan G. Weichinger wrote: Am 22.08.2011 20:29, schrieb Stefan G. Weichinger: update: edited the example in the gentoo-wiki now. replying to myself once more, which makes it feel more like a wiki or blog than a mailing-list ;-) There wasn't much to add. You provided a solution and the only reply I could come up with Well done would sound condescending. Which is why I decided not to. additional thoughts: * as there is readahead-support in systemd I assume I could get rid of preload: http://packages.gentoo.org/package/sys-apps/preload?arches=all As it isn't maintained actively anymore it maybe isn't of much use anymore anyway? I don't tend to use preload. Is it usefull in a non-systemd environment? As there is no related service-file for preload here, it is deactivated for now anyway (as long as I choose the systemd-using GRUB-line). * remember those cgroup-hacks back then? http://en.gentoo-wiki.com/wiki/Improve_responsiveness_with_cgroups Is that stuff still valid? Maybe, if you want to group stuff you're running yourself into seperate groups. The different services are grouped already. With systemd the whole use of cgroups changes fundamentally, I don't have the knowledge to decide if to use both in parallel. For now I disabled the stuff from the wiki (stop sourcing /etc/bash/local/cgrouprc) as it only gives me warnings ... What kind of warnings? Systemd already mounts the filesystem for it and starts poulating it. If your script does similar things, they might try to duplicate work? * found this blog-entry against systemd: http://monolight.cc/2011/05/the-systemd-fallacy/ I agree, it might be more useful on desktops ... so far I am still exploring and learning to get to the point to make a decision where and if to use. I think it is more useful on desktops and laptops, which get rebooted regularly. On a server that tends to run for months without a reboot, a fast init-system is important. And I don't really see the point of D-BUS on a server either. All the services that need to talk to each other already have working communication paths. I do intend to implement it on my desktop and netbook as I'd like to have those booting as fast as possible. -- Joost
Re: [gentoo-user] systemd
On Monday, August 22, 2011 11:09:02 PM Stefan G. Weichinger wrote: Am 22.08.2011 20:29, schrieb Stefan G. Weichinger: update: edited the example in the gentoo-wiki now. replying to myself once more, which makes it feel more like a wiki or blog than a mailing-list ;-) There wasn't much to add. You provided a solution and the only reply I could come up with Well done would sound condescending. Which is why I decided not to. additional thoughts: * as there is readahead-support in systemd I assume I could get rid of preload: http://packages.gentoo.org/package/sys-apps/preload?arches=all As it isn't maintained actively anymore it maybe isn't of much use anymore anyway? I don't tend to use preload. Is it usefull in a non-systemd environment? As there is no related service-file for preload here, it is deactivated for now anyway (as long as I choose the systemd-using GRUB-line). * remember those cgroup-hacks back then? http://en.gentoo-wiki.com/wiki/Improve_responsiveness_with_cgroups Is that stuff still valid? Maybe, if you want to group stuff you're running yourself into seperate groups. The different services are grouped already. With systemd the whole use of cgroups changes fundamentally, I don't have the knowledge to decide if to use both in parallel. For now I disabled the stuff from the wiki (stop sourcing /etc/bash/local/cgrouprc) as it only gives me warnings ... What kind of warnings? Systemd already mounts the filesystem for it and starts poulating it. If your script does similar things, they might try to duplicate work? * found this blog-entry against systemd: http://monolight.cc/2011/05/the-systemd-fallacy/ I agree, it might be more useful on desktops ... so far I am still exploring and learning to get to the point to make a decision where and if to use. I think it is more useful on desktops and laptops, which get rebooted regularly. On a server that tends to run for months without a reboot, a fast init-system is important. And I don't really see the point of D-BUS on a server either. All the services that need to talk to each other already have working communication paths. I do intend to implement it on my desktop and netbook as I'd like to have those booting as fast as possible. -- Joost
[gentoo-user] Re: Per-package splitdebug FEATURE
On 08/23/2011 09:17 AM, Leonardo Guilherme wrote:
Hi.
I've turned on splitdebug feature (and -ggdb in CFLAGS) so debug
information are saved and I can debug anything that crashes. I went to
/usr/lib/debug, just out of curiosity, to see how much space was taken
and I found that it was almost 2GB, which chromium + firefox adds up
1.5GB and python gets another 0.3. I would like to disable splitdebug
for these specific packages now and in the future, so removing
splitdebug from features, re-emerging them and then activating
splitdebug again won't quite cut.
I wonder if there's a way to active features to some specific
packages, just like USE flags.
There is. And it's a very powerful one even. First, remove -ggdb (I
use just -g though; if you don't need the extra info -ggdb gives, plain
-g will save you some space and time) from your CFLAGS and splitdebug
from your FEATURES in make.conf. Then, create a file:
/etc/portage/env/splitdebug.conf
with the following contents:
CFLAGS=${CFLAGS} -ggdb
CXXFLAGS=${CXXFLAGS} -ggdb
FEATURES=${FEATURES} splitdebug
Now, in /etc/portage/package.env, you can execute splitdebug.conf for
the packages you want. My package.env for example looks like:
sys-libs/glibc splitdebug.conf
media-libs/mesa splitdebug.conf
kde-base/kdelibs splitdebug.conf
kde-base/kwin splitdebug.conf
The result is that, for example, when glibc is emerged, splitdebug.conf
is executed which adds -ggdb to CFLAGS and CXXFLAGS (do not forget
CXXFLAGS!) and splitdebug to FEATURES.
As you can guess, you can create arbitrary .conf files like this; it
isn't in any way specific to splitdebug.
Re: [gentoo-user] Per-package splitdebug FEATURE
On Tuesday 23 Aug 2011 03:17:41 Leonardo Guilherme wrote:
I wonder if there's a way to active features to some specific
packages, just like USE flags.
Yes i think you can use /etc/portage/env for something like this
for eg
if you want to enable it for amarok
create a file /etc/portage/env/media-sound/amarok
with the contents
CFLAGS=-march=core2 -O1 -g
CXXFLAGS=${CFLAGS}
FEATURES=splitdebug
MAKEOPTS=-j3
--
- Yohan Pereira
A man can do as he will, but not will as he will - Schopenhauer
Re: [gentoo-user] Per-package splitdebug FEATURE
Thats what I call worthy information! Thank you so much, Yohan and Nikos!
FEATURES=${FEATURES} splitdebug
What if I want to use splitdebug always and just deactivate it to some
packages, -splitdebug on FEATURES will undo the splitdebug already
set?
like
FEATURES=${FEATURES} -splitdebug
Thanks again!
Re: [gentoo-user] systemd
Am 2011-08-23 08:27, schrieb Joost Roeleveld: On Monday, August 22, 2011 11:09:02 PM Stefan G. Weichinger wrote: Am 22.08.2011 20:29, schrieb Stefan G. Weichinger: update: edited the example in the gentoo-wiki now. replying to myself once more, which makes it feel more like a wiki or blog than a mailing-list ;-) There wasn't much to add. You provided a solution and the only reply I could come up with Well done would sound condescending. Which is why I decided not to. ok, yes I don't tend to use preload. Is it usefull in a non-systemd environment? I always had the impression that things started faster with preload, yes. Might be less of an impact with the new SSD I have in my desktop machine now. I didn't really miss it when switching to systemd (where I don't have a service-file for it yet). http://en.gentoo-wiki.com/wiki/Improve_responsiveness_with_cgroups Is that stuff still valid? Maybe, if you want to group stuff you're running yourself into seperate groups. The different services are grouped already. With systemd the whole use of cgroups changes fundamentally, I don't have the knowledge to decide if to use both in parallel. For now I disabled the stuff from the wiki (stop sourcing /etc/bash/local/cgrouprc) as it only gives me warnings ... What kind of warnings? Systemd already mounts the filesystem for it and starts poulating it. If your script does similar things, they might try to duplicate work? The code tries to write to its own dir: mkdir -p -m 0700 $cdir/user/$$ /dev/null 21 /bin/echo $$ $cdir/user/$$/tasks /bin/echo '1' $cdir/user/$$/notify_on_release But somehow the mkdir seems to fail as I get warnings from the two echo-statements, that their target-files do not exist, which lead me to the fact that $cdir/user/$$ does not exist. I think it is more useful on desktops and laptops, which get rebooted regularly. On a server that tends to run for months without a reboot, a fast init-system is important. You mean, not so important ? And I don't really see the point of D-BUS on a server either. All the services that need to talk to each other already have working communication paths. I do intend to implement it on my desktop and netbook as I'd like to have those booting as fast as possible. Yep, I agree. Stefan
Re: [gentoo-user] systemd
On Tuesday, August 23, 2011 10:30:38 AM Stefan G. Weichinger wrote: Am 2011-08-23 08:27, schrieb Joost Roeleveld: On Monday, August 22, 2011 11:09:02 PM Stefan G. Weichinger wrote: Am 22.08.2011 20:29, schrieb Stefan G. Weichinger: I don't tend to use preload. Is it usefull in a non-systemd environment? I always had the impression that things started faster with preload, yes. Might be less of an impact with the new SSD I have in my desktop machine now. I didn't really miss it when switching to systemd (where I don't have a service-file for it yet). Guess it doesn't have much of an improvement anymore? :) http://en.gentoo-wiki.com/wiki/Improve_responsiveness_with_cgroups Is that stuff still valid? Maybe, if you want to group stuff you're running yourself into seperate groups. The different services are grouped already. With systemd the whole use of cgroups changes fundamentally, I don't have the knowledge to decide if to use both in parallel. For now I disabled the stuff from the wiki (stop sourcing /etc/bash/local/cgrouprc) as it only gives me warnings ... What kind of warnings? Systemd already mounts the filesystem for it and starts poulating it. If your script does similar things, they might try to duplicate work? The code tries to write to its own dir: mkdir -p -m 0700 $cdir/user/$$ /dev/null 21 /bin/echo $$ $cdir/user/$$/tasks /bin/echo '1' $cdir/user/$$/notify_on_release But somehow the mkdir seems to fail as I get warnings from the two echo-statements, that their target-files do not exist, which lead me to the fact that $cdir/user/$$ does not exist. You could try adding ls-statements to see if it can set that op? Or try to run those commands. Where is $cdir pointing to? I think it is more useful on desktops and laptops, which get rebooted regularly. On a server that tends to run for months without a reboot, a fast init-system is important. You mean, not so important ? Yes, that's what I meant :) And I don't really see the point of D-BUS on a server either. All the services that need to talk to each other already have working communication paths. I do intend to implement it on my desktop and netbook as I'd like to have those booting as fast as possible. Yep, I agree. Stefan
Re: [gentoo-user] systemd
Am 2011-08-23 11:04, schrieb Joost Roeleveld: The code tries to write to its own dir: mkdir -p -m 0700 $cdir/user/$$ /dev/null 21 /bin/echo $$ $cdir/user/$$/tasks /bin/echo '1' $cdir/user/$$/notify_on_release But somehow the mkdir seems to fail as I get warnings from the two echo-statements, that their target-files do not exist, which lead me to the fact that $cdir/user/$$ does not exist. You could try adding ls-statements to see if it can set that op? Or try to run those commands. Where is $cdir pointing to? /sys/fs/cgroup which exists. I removed the /dev/null... part and now I see that I have a permission problem, my user isn't allowed to mkdir there. Will solve that ... otoh it might be overkill to create my own cgroups as systemd does it anyway, correct? S
Re: [gentoo-user] systemd
Am 2011-08-23 11:17, schrieb Stefan G. Weichinger: I removed the /dev/null... part and now I see that I have a permission problem, my user isn't allowed to mkdir there. Will solve that ... Rather easy to see: http://en.gentoo-wiki.com/wiki/Improve_responsiveness_with_cgroups brings the script /usr/local/sbin/cgroup_start which is started by openrc, but not by systemd. In there the perms would be set up for my user ... So the solution will be to teach systemd to start that script as well.
Re: [gentoo-user] Per-package splitdebug FEATURE
Le 23/08/11 à 04:02, Leonardo a tapoté : What if I want to use splitdebug always and just deactivate it to some packages Another way is to enable splitdebug globally, but not install debug files for specific packages : /etc/portage/env/do-not-install-debug-files.conf: INSTALL_MASK=/usr/lib/debug /etc/portage/env/package.env: www-client/firefox do-not-install-debug-files.conf If you are using FEATURES=buildpkg you can set INSTALL_MASK into make.conf : debug files will never be installed, but will be available into tbz2 packages.
[gentoo-user] cantarell latex package: error
Hello. I am having problems compiling a latex document (attached) which uses the cantarell package. pdflatex fails with the following messages: $ pdflatex test-cantarell [...] kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 raw-ot1-Cantarell-Regular-Slanted mktexpk: don't know how to create bitmap font for raw-ot1-Cantarell-Regular-Slanted. mktexpk: perhaps raw-ot1-Cantarell-Regular-Slanted is missing from the map file. kpathsea: Appending font creation commands to missfont.log. (see the transcript file for additional information) !pdfTeX error: pdflatex (file raw-ot1-Cantarell-Regular-Slanted): Font raw-ot1- Cantarell-Regular-Slanted at 600 not found == Fatal error occurred, no output PDF file produced! I am running ~amd64 gentoo Linux. Any clues? Romildo test-cantarell.tex Description: TeX document
[gentoo-user] New initscript for net-mail/fetchmail that allows multiple fetchmail daemons
Hi! I've just whupped up an initscript that allows multiple fetchmail daemons to run at the same time. Feel free to comment on Bug #380371 [1] Who knows, maybe you need a similar functionality provided by my initscript :-) [1] https://bugs.gentoo.org/show_bug.cgi?id=380371 Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
DBUS [was] Re: [gentoo-user] systemd
(renaming, because it feels like a rant thread is inevitable) On Tue, Aug 23, 2011 at 1:49 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Aug 23, 2011 at 1:17 PM, Stroller Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros. I don't see the problem with D-Bus. It's small (the only hard dependency it has is an XML parser), and it provides the Linux/UNIX (de facto) standard interprocess communication system. My chief gripe with D-Bus is that I've had X sessions disappear out from under me as a consequence of the daemon being restarted. Having a single point of failure like that is very, very scary. Otherwise, I like what it tries to do. -- :wq
Re: DBUS [was] Re: [gentoo-user] systemd
On Tue, Aug 23, 2011 at 2:35 PM, Michael Mol mike...@gmail.com wrote: On Tue, Aug 23, 2011 at 1:49 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Aug 23, 2011 at 1:17 PM, Stroller Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros. I don't see the problem with D-Bus. It's small (the only hard dependency it has is an XML parser), and it provides the Linux/UNIX (de facto) standard interprocess communication system. My chief gripe with D-Bus is that I've had X sessions disappear out from under me as a consequence of the daemon being restarted. Having a single point of failure like that is very, very scary. Otherwise, I like what it tries to do. Restarting or dying? If it's dying, it's a bug and should be reported. I haven't had a crash in dbus in years, and I think pretty much everyone agrees it's pretty stable nowadays. It even tries to handle gracefully thins like out-of-memory errors and things like that. If it's restarting, why on earth will someone restart the system bus with active X sessions? If the dbus daemon is restarted, it has to kick all the apps from the bus, including the session manager. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: DBUS [was] Re: [gentoo-user] systemd
On Tue, Aug 23, 2011 at 2:57 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Aug 23, 2011 at 2:35 PM, Michael Mol mike...@gmail.com wrote: On Tue, Aug 23, 2011 at 1:49 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Aug 23, 2011 at 1:17 PM, Stroller Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros. I don't see the problem with D-Bus. It's small (the only hard dependency it has is an XML parser), and it provides the Linux/UNIX (de facto) standard interprocess communication system. My chief gripe with D-Bus is that I've had X sessions disappear out from under me as a consequence of the daemon being restarted. Having a single point of failure like that is very, very scary. Otherwise, I like what it tries to do. Restarting or dying? If it's dying, it's a bug and should be reported. I haven't had a crash in dbus in years, and I think pretty much everyone agrees it's pretty stable nowadays. It even tries to handle gracefully thins like out-of-memory errors and things like that. I have no doubt a stellar amount of work has been done to gracefully handle problem scenarios. If it's restarting, why on earth will someone restart the system bus with active X sessions? If the dbus daemon is restarted, it has to kick all the apps from the bus, including the session manager. Because I generally update my desktop system while running X, and on at least two occasions, an update killed my X session by restarting DBUS on me On the other hand, sshd handles restarts without killing active sessions. These are solvable problems which DBUS hasn't solved yet for itself. High-availability is one of the best-researched fields in computer science, but DBUS doesn't handle that case, yet. -- :wq
Re: [gentoo-user] systemd
On Tue 23 August 2011 15:06:25 Canek Peláez Valdés did opine thusly: Now if it had similarities to say hal, I would instantly understand. But dbus is good and useful in all the ways that hal isn't. Wasn't. HAL is dead. From http://www.freedesktop.org/wiki/Software/hal Sadly, HAL is not yet dead. It lives still. It lives on the production database server I just happen to be rebooting as I type this (another story for another time) and will continue to live here for a very very long time indeed. Dale can confirm this. Dale will swear in a court of law with hand on bible than hal lives on in zombie form, infesting all the matter of his house and computers, infecting them with their undead zombieness. Ye gods, it's been a long hard day -- alan dot mckinnon at gmail dot com
Re: DBUS [was] Re: [gentoo-user] systemd
On Tue, Aug 23, 2011 at 3:08 PM, Michael Mol mike...@gmail.com wrote: On Tue, Aug 23, 2011 at 2:57 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Aug 23, 2011 at 2:35 PM, Michael Mol mike...@gmail.com wrote: On Tue, Aug 23, 2011 at 1:49 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Aug 23, 2011 at 1:17 PM, Stroller Reading that blog entry I found discouraging the idea that dbus might be required on my servers in the future, if systemd becomes popular with distros. I don't see the problem with D-Bus. It's small (the only hard dependency it has is an XML parser), and it provides the Linux/UNIX (de facto) standard interprocess communication system. My chief gripe with D-Bus is that I've had X sessions disappear out from under me as a consequence of the daemon being restarted. Having a single point of failure like that is very, very scary. Otherwise, I like what it tries to do. Restarting or dying? If it's dying, it's a bug and should be reported. I haven't had a crash in dbus in years, and I think pretty much everyone agrees it's pretty stable nowadays. It even tries to handle gracefully thins like out-of-memory errors and things like that. I have no doubt a stellar amount of work has been done to gracefully handle problem scenarios. If it's restarting, why on earth will someone restart the system bus with active X sessions? If the dbus daemon is restarted, it has to kick all the apps from the bus, including the session manager. Because I generally update my desktop system while running X, and on at least two occasions, an update killed my X session by restarting DBUS on me The update don't restart D-Bus: from the dbus-1.4.14 ebuild: elog To start the D-Bus system-wide messagebus by default elog you should add it to the default runlevel : elog \`rc-update add dbus default\` elog elog Some applications require a session bus in addition to the system elog bus. Please see \`man dbus-launch\` for more information. elog ewarn You must restart D-Bus \`/etc/init.d/dbus restart\` to run ewarn the new version of the daemon. ewarn Don't do this while X is running because it will restart your X as well. Emphasising: Don't do this while X is running because it will restart your X as well. So I will assume something went terribly wrong when updating, and again, if that's the case then it's a bug and should be reported. On the other hand, sshd handles restarts without killing active sessions. Because the daemon state for sshd is tiny compared with the one from D-Bus. Apples and oranges. These are solvable problems which DBUS hasn't solved yet for itself. High-availability is one of the best-researched fields in computer science, but DBUS doesn't handle that case, yet. Because it's not as easy as with systemd (which can also reexecute preserving state) or ssh. The state that D-Bus handles can be really, really big, because is a *generic* IPC. Not like Secure Shell, which only handles one type of session and a very limited set of messages. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] systemd
On Tue, Aug 23, 2011 at 3:43 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue 23 August 2011 15:06:25 Canek Peláez Valdés did opine thusly: Now if it had similarities to say hal, I would instantly understand. But dbus is good and useful in all the ways that hal isn't. Wasn't. HAL is dead. From http://www.freedesktop.org/wiki/Software/hal Sadly, HAL is not yet dead. It lives still. It lives on the production database server I just happen to be rebooting as I type this (another story for another time) and will continue to live here for a very very long time indeed. Dale can confirm this. Dale will swear in a court of law with hand on bible than hal lives on in zombie form, infesting all the matter of his house and computers, infecting them with their undead zombieness. Ye gods, it's been a long hard day I remember getting rid of HAL in one weekend, from all my computers. It was a long weekend, but it was not as bad as getting rid of Qt from all the computers in my office some years ago. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] systemd
Am 23.08.2011 21:43, schrieb Alan McKinnon: Sadly, HAL is not yet dead. It lives still. It lives on the production database server I just happen to be rebooting as I type this (another story for another time) and will continue to live here for a very very long time indeed. WHY is HAL installed on a database server? I still see desktop systems with HAL, last on an newish kubuntu of a friend, but on a server? For what is HAL needed there? Greetings Sebastian Beßler signature.asc Description: OpenPGP digital signature
Re: DBUS [was] Re: [gentoo-user] systemd
On Tue, Aug 23, 2011 at 3:47 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Aug 23, 2011 at 3:08 PM, Michael Mol mike...@gmail.com wrote: Because I generally update my desktop system while running X, and on at least two occasions, an update killed my X session by restarting DBUS on me The update don't restart D-Bus: from the dbus-1.4.14 ebuild: elog To start the D-Bus system-wide messagebus by default elog you should add it to the default runlevel : elog \`rc-update add dbus default\` elog elog Some applications require a session bus in addition to the system elog bus. Please see \`man dbus-launch\` for more information. elog ewarn You must restart D-Bus \`/etc/init.d/dbus restart\` to run ewarn the new version of the daemon. ewarn Don't do this while X is running because it will restart your X as well. Emphasising: Don't do this while X is running because it will restart your X as well. So I will assume something went terribly wrong when updating, and again, if that's the case then it's a bug and should be reported. I see. Apologies for the snark, but this feels like it leads to a Setup requires that you restart your computer to continue situation. (This becomes less and less of an exaggeration as more and more system components choose to route their traffic through D-Bus) On the other hand, sshd handles restarts without killing active sessions. Because the daemon state for sshd is tiny compared with the one from D-Bus. Apples and oranges. That doesn't really enter into it. To me, that means you would want to use something like shared memory (is there any multi-tasking operating system with protected memory which can't mmap?) and rigorous checks and controls for managing that state. Even sqlite can manage that. (Not that I'm suggesting you would use sqlite for tracking D-Bus state, just that you'd look at what they do with locks and integrity checks for guaranteeing integrity on shared memory with multiple consuming processes.) And, yes, upgrades on live data can be a royal PITA. Designing a system which can handle it requires careful attention and testing. The more anal you want to be about it, the more you start talking about writing provable and verifiable code and other stringent debugging, development and testing practices. Yet it's done. Last Friday, I sat at a table with someone who witnessed an IBM tech replace a CPU in a mainframe. Flip a switch, pull out the old part, insert the new part, flip the switch back on, everything's fine. Saturday, I listened to a guy present on how he dynamically reroutes live calls through a VOIP network based on hardware faults. These are solvable problems which DBUS hasn't solved yet for itself. High-availability is one of the best-researched fields in computer science, but DBUS doesn't handle that case, yet. Because it's not as easy as with systemd (which can also reexecute preserving state) or ssh. D-Bus wants to be a core system service, and *that's* what should be setting its design goals, not how difficult it would be for the system to be worthy of the core. Again, I really don't believe D-Bus is badly-written. I just think its community isn't fully aware of the trends of its position in the system, and what responsibilities it carries. -- :wq
Re: [gentoo-user] systemd
On Tue 23 August 2011 15:50:24 Canek Peláez Valdés did opine thusly: On Tue, Aug 23, 2011 at 3:43 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue 23 August 2011 15:06:25 Canek Peláez Valdés did opine thusly: Now if it had similarities to say hal, I would instantly understand. But dbus is good and useful in all the ways that hal isn't. Wasn't. HAL is dead. From http://www.freedesktop.org/wiki/Software/hal Sadly, HAL is not yet dead. It lives still. It lives on the production database server I just happen to be rebooting as I type this (another story for another time) and will continue to live here for a very very long time indeed. Dale can confirm this. Dale will swear in a court of law with hand on bible than hal lives on in zombie form, infesting all the matter of his house and computers, infecting them with their undead zombieness. Ye gods, it's been a long hard day I remember getting rid of HAL in one weekend, from all my computers. It was a long weekend, but it was not as bad as getting rid of Qt from all the computers in my office some years ago. Come to my work place, I have the perfect task for you: to excise perl-5.8.0 from all the many machines it's on, plus the atrocious in-house coding using it that no-one left understands, and all running on hardware that no-one can replace. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] systemd
On Tue, Aug 23, 2011 at 4:19 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue 23 August 2011 15:50:24 Canek Peláez Valdés did opine thusly: On Tue, Aug 23, 2011 at 3:43 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue 23 August 2011 15:06:25 Canek Peláez Valdés did opine thusly: Now if it had similarities to say hal, I would instantly understand. But dbus is good and useful in all the ways that hal isn't. Wasn't. HAL is dead. From http://www.freedesktop.org/wiki/Software/hal Sadly, HAL is not yet dead. It lives still. It lives on the production database server I just happen to be rebooting as I type this (another story for another time) and will continue to live here for a very very long time indeed. Dale can confirm this. Dale will swear in a court of law with hand on bible than hal lives on in zombie form, infesting all the matter of his house and computers, infecting them with their undead zombieness. Ye gods, it's been a long hard day I remember getting rid of HAL in one weekend, from all my computers. It was a long weekend, but it was not as bad as getting rid of Qt from all the computers in my office some years ago. Come to my work place, I have the perfect task for you: to excise perl-5.8.0 from all the many machines it's on, plus the atrocious in-house coding using it that no-one left understands, and all running on hardware that no-one can replace. Been there, done that. One of the reasons I got back to school to get my Computer Science PhD. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] systemd
On Tue 23 August 2011 22:16:30 Sebastian Beßler did opine thusly: Am 23.08.2011 21:43, schrieb Alan McKinnon: Sadly, HAL is not yet dead. It lives still. It lives on the production database server I just happen to be rebooting as I type this (another story for another time) and will continue to live here for a very very long time indeed. WHY is HAL installed on a database server? I still see desktop systems with HAL, last on an newish kubuntu of a friend, but on a server? For what is HAL needed there? I wish I knew why. The fellow that did the install might know. I'm betting it's because he clicked yes, yes, yes, yes, ok on the RHEL install CD dialogs. I can't fix it without running afoul of the Change Management process, and today's emergency reboot didn't leave me any time to poke around and determine the effect of removing hal. This is how life in corporate IT works -- alan dot mckinnon at gmail dot com
Re: DBUS [was] Re: [gentoo-user] systemd
On Tue, Aug 23, 2011 at 4:18 PM, Michael Mol mike...@gmail.com wrote:
On Tue, Aug 23, 2011 at 3:47 PM, Canek Peláez Valdés can...@gmail.com wrote:
On Tue, Aug 23, 2011 at 3:08 PM, Michael Mol mike...@gmail.com wrote:
Because I generally update my desktop system while running X, and on
at least two occasions, an update killed my X session by restarting
DBUS on me
The update don't restart D-Bus: from the dbus-1.4.14 ebuild:
elog To start the D-Bus system-wide messagebus by default
elog you should add it to the default runlevel :
elog \`rc-update add dbus default\`
elog
elog Some applications require a session bus in addition to the system
elog bus. Please see \`man dbus-launch\` for more information.
elog
ewarn You must restart D-Bus \`/etc/init.d/dbus restart\` to run
ewarn the new version of the daemon.
ewarn Don't do this while X is running because it will restart your X as
well.
Emphasising: Don't do this while X is running because it will restart
your X as well. So I will assume something went terribly wrong when
updating, and again, if that's the case then it's a bug and should be
reported.
I see. Apologies for the snark, but this feels like it leads to a
Setup requires that you restart your computer to continue situation.
(This becomes less and less of an exaggeration as more and more system
components choose to route their traffic through D-Bus)
And I think it's OK. To upgrade the kernel, we need a computer
restart. To upgrade the system bus, we need a system bus (service)
restart. To upgrade the session bus, we need a session restart
(logout/login). Nobody is saying that a bus restart needs a complete
computer restart (although I'm pretty sure some distros would do that
by default).
On the other hand, sshd handles restarts without killing active sessions.
Because the daemon state for sshd is tiny compared with the one from
D-Bus. Apples and oranges.
That doesn't really enter into it. To me, that means you would want to
use something like shared memory (is there any multi-tasking operating
system with protected memory which can't mmap?) and rigorous checks
and controls for managing that state. Even sqlite can manage that.
(Not that I'm suggesting you would use sqlite for tracking D-Bus
state, just that you'd look at what they do with locks and integrity
checks for guaranteeing integrity on shared memory with multiple
consuming processes.)
You are right, I stand corrected. And actually, D-Bus is very much
capable of restart without kicking out sessions (read Havoc
explanation in http://article.gmane.org/gmane.comp.freedesktop.dbus/7730).
The problem is that many apps don't handle this correctly, and the
D-Bus developers choose the safe option. If all the apps supported
gracefully the restart, there would be no problems.
And, yes, upgrades on live data can be a royal PITA. Designing a
system which can handle it requires careful attention and testing. The
more anal you want to be about it, the more you start talking about
writing provable and verifiable code and other stringent debugging,
development and testing practices.
It's a matter of cost-benefit. Given the open source community, I
think the PITA is not worth it in several cases, D-Bus being one of
them.
Yet it's done. Last Friday, I sat at a table with someone who
witnessed an IBM tech replace a CPU in a mainframe. Flip a switch,
pull out the old part, insert the new part, flip the switch back on,
everything's fine. Saturday, I listened to a guy present on how he
dynamically reroutes live calls through a VOIP network based on
hardware faults.
I have seen those kind of systems. And again, it's a matter of
cost-benefit: See the difference in budgets for that kind of systems
and our open source software stack.
D-Bus wants to be a core system service, and *that's* what should be
setting its design goals, not how difficult it would be for the system
to be worthy of the core.
Again, I really don't believe D-Bus is badly-written. I just think its
community isn't fully aware of the trends of its position in the
system, and what responsibilities it carries.
I think we are fully aware. The thing is, given the community
resources, D-Bus is good enough, which, as everybody knows, is the
enemy of (the impossible) perfect.
Just my 0.02 ${CURRENCY}.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] systemd
On 8/23/2011 1:43 PM, Alan McKinnon wrote: I can't fix it without running afoul of the Change Management process, and today's emergency reboot didn't leave me any time to poke around and determine the effect of removing hal. This is how life in corporate IT works I hate Corp CM and it's one of the reasons I stay in startups. It's job is to slow normal change down so much so that every change becomes an emergency. However next time I have to deal with one I am shoving mathematical proof of there is no rollback in systems down there throats. http://www.iu.hio.no/~mark/papers/totalfield.pdf For those that aren't ginormous systems nerds this bit sums it up nicely. There is a deeper issue with roll-back in partial systems. If a system is in contact with another system, e.g. receiving data, or if we have partitioned a system into loosely coupled pieces only one of which is being changed, then the other system becomes a part of the total system and we must write a hypothetical journal for the entire system in order to achieve a consistent rollback. kashani
Re: [gentoo-user] systemd
On Tue 23 August 2011 14:10:57 kashani did opine thusly: On 8/23/2011 1:43 PM, Alan McKinnon wrote: I can't fix it without running afoul of the Change Management process, and today's emergency reboot didn't leave me any time to poke around and determine the effect of removing hal. This is how life in corporate IT works I hate Corp CM and it's one of the reasons I stay in startups. It's job is to slow normal change down so much so that every change becomes an emergency. However next time I have to deal with one I am shoving mathematical proof of there is no rollback in systems down there throats. http://www.iu.hio.no/~mark/papers/totalfield.pdf Haven't read the pdf yet, but I just have to share this joke. Tonight's CM was an unscheduled emergency reboot. This gave me opportunity to do something I've been dying to do for ages, enter this: Install plan: reboot server Test plan:ping server Backout plan: unreboot server == :-) On the whole our CM process is sane. The manager knows how infrastructure works: If that undersea optical link goes down, I'm fixing it right now and to hell with the paperwork and process. Contrast with my gf's job at the bank. That one truly is a case where to change anything, she has to invent imaginary catastrophic emergencies. More often than not, she causes them in undetectable ways just to get her job done. For those that aren't ginormous systems nerds this bit sums it up nicely. There is a deeper issue with roll-back in partial systems. If a system is in contact with another system, e.g. receiving data, or if we have partitioned a system into loosely coupled pieces only one of which is being changed, then the other system becomes a part of the total system and we must write a hypothetical journal for the entire system in order to achieve a consistent rollback. kashani -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] systemd
Am 23.08.2011 11:22, schrieb Stefan G. Weichinger: http://en.gentoo-wiki.com/wiki/Improve_responsiveness_with_cgroups brings the script /usr/local/sbin/cgroup_start which is started by openrc, but not by systemd. In there the perms would be set up for my user ... So the solution will be to teach systemd to start that script as well. That was no big problem ... solved. Interesting observation right now: Wanted to extend a LV. Unmounted it, lvresize -L+5G ..., then resize2fs ... resize2fs told me that the LV is mounted and that is has to do online resizing. whoa. I unmounted it before! So it seems as if I would have to stop the related mount-service within systemd first ... That is an important thing to know IMO. Stefan
Re: [gentoo-user] Re: Plasma-runtime compilation problems
On Sun, 2011-08-21 at 11:55 -0700, walt wrote: On 08/20/2011 12:21 PM, Jeff Cranmer wrote: /usr/include/KDE/Plasma/../../plasma/service.h:321: error: previous definition of 'struct QMetaTypeIdPlasma::Service*' Hm, well purely a wild guess, but perhaps /usr/include/plasma/service.h is left over from an earlier plasma package and the compiler really shouldn't be using it. What package does that file belong to? I don't know. Pardon my ignorance, but how do I find out? Thanks Jeff
[gentoo-user] HP tablets run Gentoo?
They are just $99 so before I purchase one has anyone installed gentoo or embedded gentoo on one of these devices? Do all the necessary device drivers work? Is a port does not exist is it possible? Likely? I know little about the underlying hardware or any owner's opinion of these devices so all comments are welcome. Any caveats? James
[gentoo-user] OT: avahi problem
I have moved my network hosts from localdomain to wifi.localdomain, lan.localdomain etc. The main (gentoo) gateway is multihomeed and runs services for my home networks including cups and avahi to allow iThings to print. Since the move, avahi based printing fails with a cups error of moriah.local which appears to come from avahi via mdns. Grepping /etc for this string and trying to overide this with avahi-publish fails. All other services including non-avahi printing, dns etc work properly Where do I look next? BillK
[gentoo-user] CONFIG_IOMMU_SUPPORT???
Hi all, Can someone point me toward somehow enabling CONFIG_IOMMU_SUPPORT? It is apparently a kernel config option no required by virtualbox-drivers but I'm not finding it in the 3.0.3 kernel. I suspect there's something else I need to enable before this option becomes available? Unfortunately I haven't been able to Google what I need to do to find it. Thanks, Mark * Messages for package app-emulation/virtualbox-modules-4.1.2: * CONFIG_IOMMU_SUPPORT: is not set when it should be. * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. SNIP k2 linux # cat .config | grep IOMMU CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_AMD_IOMMU=y # CONFIG_AMD_IOMMU_STATS is not set CONFIG_IOMMU_HELPER=y CONFIG_IOMMU_API=y # CONFIG_IOMMU_DEBUG is not set # CONFIG_IOMMU_STRESS is not set k2 linux #
Re: [gentoo-user] Can't emerge gnome-base/librsvg; missing /usr/lib/libglib-2.0.la
110823 Walter Dnes wrote: Doing an update on my backup (i.e. 32-bit) intel desktop PC. Attempting to emerge gnome-base/librsvg-2.34.0 fails with... /bin/sh ./libtool --silent --tag=CC --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I. -DG_LOG_DOMAIN=\librsvg\ -DLIBRSVG_DATADIR=\/usr/share\ -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng14 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libcroco-0.6 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -DHAVE_LIBCROCO=1 -O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe -c -o librsvg_2_la-rsvg-xml.lo `test -f 'rsvg-xml.c' || echo './'`rsvg-xml.c CCLD librsvg-2.la /bin/grep: /usr/lib/libglib-2.0.la: No such file or directory /bin/sed: can't read /usr/lib/libglib-2.0.la: No such file or directory libtool: link: `/usr/lib/libglib-2.0.la' is not a valid libtool archive make[2]: *** [librsvg-2.la] Error 1 It looks like the problem I reported recently, which was solved by remerging gcc libtool , esp the latter. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] UPnP server/client recommendations
Hello All, I was wanting to set up a UPnP server so my wife could browse my music easily from her Windoze machine. What recommendations do you have on UPnP servers? Thanks, James Wall -- No trees were harmed in the sending of this message. However, a large number of electrons were terribly inconvenienced.
Re: [gentoo-user] CONFIG_IOMMU_SUPPORT???
Mark Knecht wrote: Hi all, Can someone point me toward somehow enabling CONFIG_IOMMU_SUPPORT? It is apparently a kernel config option no required by virtualbox-drivers but I'm not finding it in the 3.0.3 kernel. I suspect there's something else I need to enable before this option becomes available? Unfortunately I haven't been able to Google what I need to do to find it. Thanks, Mark * Messages for package app-emulation/virtualbox-modules-4.1.2: * CONFIG_IOMMU_SUPPORT: is not set when it should be. * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. SNIP k2 linux # cat .config | grep IOMMU CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_AMD_IOMMU=y # CONFIG_AMD_IOMMU_STATS is not set CONFIG_IOMMU_HELPER=y CONFIG_IOMMU_API=y # CONFIG_IOMMU_DEBUG is not set # CONFIG_IOMMU_STRESS is not set k2 linux # There are a few of them in different places. I'm not sure which one it claims to need as none seems to match the name exactly. Here is a way to search tho. When you type in make menuconfig and it comes up, hit the / key. That would the the question mark WITHOUT pressing the shift key. Type in IOMMU and hit return. From there you can scroll though with the arrow keys to find out which one you think fits. This si my results: root@fireball /usr/src/linux-3.0.3-gentoo # cat .config | grep IOMMU CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_AMD_IOMMU=y # CONFIG_AMD_IOMMU_STATS is not set CONFIG_IOMMU_HELPER=y CONFIG_IOMMU_API=y # CONFIG_IOMMU_DEBUG is not set # CONFIG_IOMMU_STRESS is not set root@fireball Yours looks the same as mine so not sure what to suggest other then the search above. Maybe you are Intel based where I am AMD based? Hope that helps. Dale :-) :-)
Re: [gentoo-user] systemd
Alan McKinnon wrote: On Tue 23 August 2011 15:06:25 Canek Peláez Valdés did opine thusly: Now if it had similarities to say hal, I would instantly understand. But dbus is good and useful in all the ways that hal isn't. Wasn't. HAL is dead. From http://www.freedesktop.org/wiki/Software/hal Sadly, HAL is not yet dead. It lives still. It lives on the production database server I just happen to be rebooting as I type this (another story for another time) and will continue to live here for a very very long time indeed. Dale can confirm this. Dale will swear in a court of law with hand on bible than hal lives on in zombie form, infesting all the matter of his house and computers, infecting them with their undead zombieness. Ye gods, it's been a long hard day Not here. I shot hal with a silver bullet and drove a stake into it a long time ago. If that thing even twitches, I'll go Navy Seals on it. O_O Man I love the 2nd amendment we have. ;-) Even the NSA wouldn't be able to bring that back. Dale :-) :-)
Re: [gentoo-user] CONFIG_IOMMU_SUPPORT???
On 23 August 2011 20:38, Mark Knecht markkne...@gmail.com wrote: Hi all, Can someone point me toward somehow enabling CONFIG_IOMMU_SUPPORT? It is apparently a kernel config option no required by virtualbox-drivers but I'm not finding it in the 3.0.3 kernel. I suspect there's something else I need to enable before this option becomes available? Unfortunately I haven't been able to Google what I need to do to find it. Thanks, Mark * Messages for package app-emulation/virtualbox-modules-4.1.2: * CONFIG_IOMMU_SUPPORT: is not set when it should be. * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. SNIP k2 linux # cat .config | grep IOMMU CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_AMD_IOMMU=y # CONFIG_AMD_IOMMU_STATS is not set CONFIG_IOMMU_HELPER=y CONFIG_IOMMU_API=y # CONFIG_IOMMU_DEBUG is not set # CONFIG_IOMMU_STRESS is not set k2 linux # I noticed the same. There does not appear to be any such option but luckily its absence does not appear to affect running VB at all.
Re: [gentoo-user] UPnP server/client recommendations
On 24 August 2011, at 04:56, James Wall wrote: ... I was wanting to set up a UPnP server so my wife could browse my music easily from her Windoze machine. What recommendations do you have on UPnP servers? http://old.nabble.com/Software-for-LCD-Data-Center-ts32300652.html
Re: [gentoo-user] CONFIG_IOMMU_SUPPORT???
On Wed, Aug 24, 2011 at 12:18 AM, Hilco Wijbenga hilco.wijbe...@gmail.comwrote: On 23 August 2011 20:38, Mark Knecht markkne...@gmail.com wrote: Hi all, Can someone point me toward somehow enabling CONFIG_IOMMU_SUPPORT? It is apparently a kernel config option no required by virtualbox-drivers but I'm not finding it in the 3.0.3 kernel. I suspect there's something else I need to enable before this option becomes available? Unfortunately I haven't been able to Google what I need to do to find it. IOMMU_SUPPORT is a derived value that becomes set when any of the various IOMMU devices are enabled. I enabled the IBM CALGARY IOMMU and the AMD IOMMU to get the VBox build to stop complaining. I was also getting complaints about PCI_STUB support from VBox, but the running VMs don't need the vboxpcistub.ko driver to work. -- G.Wolfe Woodbury
Re: DBUS [was] Re: [gentoo-user] systemd
On Tue, Aug 23, 2011 at 4:53 PM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Aug 23, 2011 at 4:18 PM, Michael Mol mike...@gmail.com wrote: You are right, I stand corrected. And actually, D-Bus is very much capable of restart without kicking out sessions (read Havoc explanation in http://article.gmane.org/gmane.comp.freedesktop.dbus/7730). The problem is that many apps don't handle this correctly, and the D-Bus developers choose the safe option. If all the apps supported gracefully the restart, there would be no problems. A very, very good writeup which provides a lot of explanation of the semantics of D-Bus connections. Very helpful, thanks for the link. What it tells me is that a D-Bus restart needs to be able to be done without dropping connections. I don't know the specifics of the bindings between libdbus and the daemon, but a first guess would be to spin up the upgraded daemon, hand over all live connections, and shut down the old daemon. That obviously requires newer daemons being able to talk with older libdbus (at least until the app itself is restarted), and newer libdbus being able to talk with older daemons (in the event that an app hits that vulnerable spot between when things have been installed but not upgraded). Obviously, this really depends on how much the libdbus protocol itself must be able to change going forward. And, yes, upgrades on live data can be a royal PITA. Designing a system which can handle it requires careful attention and testing. The more anal you want to be about it, the more you start talking about writing provable and verifiable code and other stringent debugging, development and testing practices. It's a matter of cost-benefit. Given the open source community, I think the PITA is not worth it in several cases, D-Bus being one of them. Personally, I suspect the balance will change as there's greater and greater dependency on D-Bus on long-uptime systems. Yet it's done. Last Friday, I sat at a table with someone who witnessed an IBM tech replace a CPU in a mainframe. Flip a switch, pull out the old part, insert the new part, flip the switch back on, everything's fine. Saturday, I listened to a guy present on how he dynamically reroutes live calls through a VOIP network based on hardware faults. I have seen those kind of systems. And again, it's a matter of cost-benefit: See the difference in budgets for that kind of systems and our open source software stack. True to an extent. I think it was four or five years ago, during the SCO lawsuit, when someone estimated the value of the Linux kernel at well over a billion dollars. Many for-profit companies contribute to the kernel and its architecture. If D-Bus becomes necessary to the operation of the majority of use cases, I suspect similar contribution paths will occur there. D-Bus wants to be a core system service, and *that's* what should be setting its design goals, not how difficult it would be for the system to be worthy of the core. Again, I really don't believe D-Bus is badly-written. I just think its community isn't fully aware of the trends of its position in the system, and what responsibilities it carries. I think we are fully aware. The thing is, given the community resources, D-Bus is good enough, which, as everybody knows, is the enemy of (the impossible) perfect. Very true. -- :wq
