On 04/25/2014 04:13 AM, Bruce Dubbs wrote:
Ken Moffat wrote:
On Thu, Apr 24, 2014 at 08:02:58PM -0500, Bruce Dubbs wrote:
Ken Moffat wrote:
Thanks for the pointer (I have not built systemd at the moment,
still trying to sort out enough details for me to have a chance of
getting the whole
On Wed, Apr 23, 2014 at 12:09:26AM -0500, Bruce Dubbs wrote:
Ken Moffat wrote:
On Sun, Apr 20, 2014 at 03:19:45PM -0500, Bruce Dubbs wrote:
Last night I was trying to figure out how to set the dmesg log level in
systemd. It turns out that it can be done with sysctl and set:
Ken Moffat wrote:
On Wed, Apr 23, 2014 at 12:09:26AM -0500, Bruce Dubbs wrote:
Ken Moffat wrote:
On Sun, Apr 20, 2014 at 03:19:45PM -0500, Bruce Dubbs wrote:
Last night I was trying to figure out how to set the dmesg log level in
systemd. It turns out that it can be done with sysctl and
On Thu, Apr 24, 2014 at 08:02:58PM -0500, Bruce Dubbs wrote:
Ken Moffat wrote:
Thanks for the pointer (I have not built systemd at the moment,
still trying to sort out enough details for me to have a chance of
getting the whole thing working). But your use of sysctl looks
Ken Moffat wrote:
On Thu, Apr 24, 2014 at 08:02:58PM -0500, Bruce Dubbs wrote:
Ken Moffat wrote:
Thanks for the pointer (I have not built systemd at the moment,
still trying to sort out enough details for me to have a chance of
getting the whole thing working). But your use of sysctl
On Sun, Apr 20, 2014 at 03:19:45PM -0500, Bruce Dubbs wrote:
Last night I was trying to figure out how to set the dmesg log level in
systemd. It turns out that it can be done with sysctl and set:
kernel.printk = 4 4 1 7
where the numbers are console_loglevel, default_message_loglevel,
Ken Moffat wrote:
On Sun, Apr 20, 2014 at 03:19:45PM -0500, Bruce Dubbs wrote:
Last night I was trying to figure out how to set the dmesg log level in
systemd. It turns out that it can be done with sysctl and set:
kernel.printk = 4 4 1 7
where the numbers are console_loglevel,
Le 20/04/2014 23:26, Ken Moffat a écrit :
I've no idea what that refers to, but it doesn't matter. I know
that (at least) you and Pierre use jhalfs, and for me that is
unusable (/scratch is an nfs mount on/from my server, I _really_ do
not want to try to build there - by the same token, I
Pierre Labastie wrote:
Le 20/04/2014 23:26, Ken Moffat a écrit :
I've no idea what that refers to, but it doesn't matter. I know
that (at least) you and Pierre use jhalfs, and for me that is
unusable (/scratch is an nfs mount on/from my server, I _really_ do
not want to try to build
Le 21/04/2014 20:49, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Le 20/04/2014 23:26, Ken Moffat a écrit :
I've no idea what that refers to, but it doesn't matter. I know
that (at least) you and Pierre use jhalfs, and for me that is
unusable (/scratch is an nfs mount on/from my server,
On Mon, Apr 21, 2014 at 03:28:01PM -0500, Bruce Dubbs wrote:
Pierre Labastie wrote:
Le 21/04/2014 20:49, Bruce Dubbs a écrit :
Pierre Labastie wrote:
Le 20/04/2014 23:26, Ken Moffat a écrit :
For convenience I also have scripts to mount and unmount virtual file
systems and to clean up
Ken Moffat wrote:
There is also a deeper difference - jhalfs was originally a tool for
builders. As an editor, my preference is to look at a new package
version on a completed system [ normally, just a DESTDIR ], see what
options I want to use [ e.g. omit static libs even in LFS, unless
BLFS Trac wrote:
Comment (by ken@…):
At the moment I'm still trying to absorb the systemd changes in LFS - my
own scripts now build a working LFS with eudev and _current_ LFS
bootscripts, and I'm fairly confident that the systemv-on-systemd build
will work when I test it. But I'm
On Sun, Apr 20, 2014 at 03:19:45PM -0500, Bruce Dubbs wrote:
BLFS Trac wrote:
Comment (by ken@…):
At the moment I'm still trying to absorb the systemd changes in LFS - my
own scripts now build a working LFS with eudev and _current_ LFS
bootscripts, and I'm fairly confident that
Em 20-04-2014 18:26, Ken Moffat escreveu:
On Sun, Apr 20, 2014 at 03:19:45PM -0500, Bruce Dubbs wrote:
BLFS Trac wrote:
My objective is to allow users that do not want to consider or even try
systemd to continue to do what they are already doing.
And you appear to be achieving that. I
(with a few packages from
BLFS). D-Bus is not started by default in the System V setup, but the
binaries are built and installed.
There is one minor change in sysvinit when there are four lines that
move files. If systemd is not installed, those are not needed. The
scripts in the new 7.1
BLFS). D-Bus is not started by default in the System V setup, but the
binaries are built and installed.
Yeah, but for the current LFS-svn bootscripts (see my post on -chat
from a few hours ago) the name/location of udevd and udevadm have
changed.
My impression is that you _have_
(with a few packages from
BLFS). D-Bus is not started by default in the System V setup, but the
binaries are built and installed.
Yeah, but for the current LFS-svn bootscripts (see my post on -chat
from a few hours ago) the name/location of udevd and udevadm have
changed.
That's right. You do need
On Sun, Apr 20, 2014 at 06:00:51PM -0500, Bruce Dubbs wrote:
Ken Moffat wrote:
On Sun, Apr 20, 2014 at 05:19:22PM -0500, Bruce Dubbs wrote:
However there is a method to their madness and
LFSers should be able to pick it up relatively quickly.
Don't get me started on what that
Ken Moffat wrote:
On Sun, Apr 20, 2014 at 06:00:51PM -0500, Bruce Dubbs wrote:
Ken Moffat wrote:
On Sun, Apr 20, 2014 at 05:19:22PM -0500, Bruce Dubbs wrote:
However there is a method to their madness and
LFSers should be able to pick it up relatively quickly.
Don't get me started
configure: Full test coverage (--enable-tests=yes) requires Python,
dbus-python, pygobject
checking for a Python interpreter with version = 2.6... python
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script
On 02/18/2014 05:48 PM, Armin K. wrote:
configure: Full test coverage (--enable-tests=yes) requires Python,
dbus-python, pygobject
checking for a Python interpreter with version = 2.6... python
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python
Em 18-02-2014 14:01, Armin K. escreveu:
On 02/18/2014 05:48 PM, Armin K. wrote:
configure: Full test coverage (--enable-tests=yes) requires Python,
dbus-python, pygobject
checking for a Python interpreter with version = 2.6... python
checking for python... /usr/bin/python
checking for
Hello,
I'd like to move D-Bus from required to recommended dependency. Since I
don't use D-Bus on my systems, is there any other package in the book
which requires VLC compiled with D-Bus support?
--
Igor Živković
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http
On 06/16/2013 01:22 PM, Igor Živković wrote:
Hello,
I'd like to move D-Bus from required to recommended dependency. Since I
don't use D-Bus on my systems, is there any other package in the book
which requires VLC compiled with D-Bus support?
Does it require any switches to disable
On 16.06.2013 13:30, Armin K. wrote:
On 06/16/2013 01:22 PM, Igor Živković wrote:
Hello,
I'd like to move D-Bus from required to recommended dependency. Since I
don't use D-Bus on my systems, is there any other package in the book
which requires VLC compiled with D-Bus support?
Does
On 06/16/2013 01:32 PM, Igor Živković wrote:
On 16.06.2013 13:30, Armin K. wrote:
On 06/16/2013 01:22 PM, Igor Živković wrote:
Hello,
I'd like to move D-Bus from required to recommended dependency. Since I
don't use D-Bus on my systems, is there any other package in the book
which requires
Igor Živković wrote:
Hello,
I'd like to move D-Bus from required to recommended dependency. Since I
don't use D-Bus on my systems, is there any other package in the book
which requires VLC compiled with D-Bus support?
Just to comment, I'd like ot point out that some packages, e.g
On 07/03/2012 01:05 AM, Bruce Dubbs wrote:
Armin K. wrote:
On 3.7.2012 0:43, Bruce Dubbs wrote:
I just ran into a problem with vlc caused by d-bus. The latest version
of d-bus does create /var/lib/dbus, but it does not populate it. vlc
filed with:
Hm, IIRC bootscript should run dbus
Armin K. wrote:
On 07/03/2012 01:05 AM, Bruce Dubbs wrote:
Armin K. wrote:
On 3.7.2012 0:43, Bruce Dubbs wrote:
I just ran into a problem with vlc caused by d-bus. The latest version
of d-bus does create /var/lib/dbus, but it does not populate it. vlc
filed with:
Hm, IIRC bootscript
I just ran into a problem with vlc caused by d-bus. The latest version
of d-bus does create /var/lib/dbus, but it does not populate it. vlc
filed with:
process 4644: D-Bus library appears to be incorrectly set up; failed to
read machine uuid: Failed to open /etc/machine-id: No such file
On 3.7.2012 0:43, Bruce Dubbs wrote:
I just ran into a problem with vlc caused by d-bus. The latest version
of d-bus does create /var/lib/dbus, but it does not populate it. vlc
filed with:
Hm, IIRC bootscript should run dbus-uuidgen --ensure before starting
dbus-daemon.
--
http
Armin K. wrote:
On 3.7.2012 0:43, Bruce Dubbs wrote:
I just ran into a problem with vlc caused by d-bus. The latest version
of d-bus does create /var/lib/dbus, but it does not populate it. vlc
filed with:
Hm, IIRC bootscript should run dbus-uuidgen --ensure before starting
dbus-daemon
Dubbs bruce.du...@gmail.com wrote:
Ragnar Thomsen wrote:
As mentioned in ticket #3103, D-bus starts at S20, while network
starts at S20 and netfs at S28.
Since D-Bus is installed on /usr, it should be started after the
network/netfs scripts.
AFAIK, d-bus is only needed for Xorg applications
DJ Lucas wrote:
While it was unpopular last time, or maybe just uninteresting, it's
as good a time as any to suggest ditching the static list all
together...let the dependency info in the scripts do what It's
intended to do?
Perhaps a little later. With the new tool chain packages we will be
As mentioned in ticket #3103, D-bus starts at S20, while network starts at S20
and netfs at S28.
Since D-Bus is installed on /usr, it should be started after the network/netfs
scripts.
Can D-Bus be moved to S30? Are there other bootscripts that need to be
re-prioritized?
-Ragnar
Ragnar Thomsen wrote:
As mentioned in ticket #3103, D-bus starts at S20, while network
starts at S20 and netfs at S28.
Since D-Bus is installed on /usr, it should be started after the
network/netfs scripts.
AFAIK, d-bus is only needed for Xorg applications. I would think any
time before
On Thu, Mar 08, 2012 at 09:41:08PM +, Ken Moffat wrote:
On Wed, Mar 07, 2012 at 12:08:29PM -0600, Bruce Dubbs wrote:
It probably would be reasonable to just replace any glib2 dependencies
in the book with pkg-config.
Sounds a good idea. My cable hardware upgrade went ok, so
On Fri, 09 Mar 2012 21:39:09 +
Ken Moffat zarniwh...@ntlworld.com wrote:
The following packages have glib2 as an optional dependency : qt4,
gtk-doc, pulseaudio.
I have no experience of trying to build any of these in the absence
of pkg-config. I assume it would be painful (needing to
On Fri, Mar 09, 2012 at 10:25:37PM +, Andrew Benton wrote:
On Fri, 09 Mar 2012 21:39:09 +
Ken Moffat zarniwh...@ntlworld.com wrote:
The following packages have glib2 as an optional dependency : qt4,
gtk-doc, pulseaudio.
I have no experience of trying to build any of these in
On Fri, Mar 09, 2012 at 11:46:25PM +, Ken Moffat wrote:
On Fri, Mar 09, 2012 at 10:25:37PM +, Andrew Benton wrote:
gtk-doc compiles fine without pkg-config but reading through the
configure script it does use pkg-config to find things like
gnome-doc-utils and glib-2.0.
Andy
On Fri, 09 Mar 2012 23:54:12 +
Ken Moffat zarniwh...@ntlworld.com wrote:
Thanks, but to be clear - are you saying gtk-doc won't use them
without pkg-config ?
I don't know. The way I look at it, configure worked without pkgconfig
so we can't say required but it definitely wanted to use
As a test of the new jhalfs/BLFS tools, I have tried
to compile 'accountservice' (the first package in the
book). The tool generated the following build order:
dbus libffi python2 pcre glib2 dbus-glib perl-xml-parser
intltool pkgconfig polkit accountsservice.
Knowing that libxml2 and expat were
Le 07/03/2012 18:01, Pierre Labastie a écrit :
See attached patch.
Forgotten, sorry.
Index: blfsbook/general/sysutils/dbus-bindings.xml
===
--- blfsbook.orig/general/sysutils/dbus-bindings.xml 2012-02-21 17:34:42.0 +0100
On Wed, Mar 07, 2012 at 06:01:32PM +0100, Pierre Labastie wrote:
As a test of the new jhalfs/BLFS tools, I have tried
to compile 'accountservice' (the first package in the
book). The tool generated the following build order:
dbus libffi python2 pcre glib2 dbus-glib perl-xml-parser
intltool
On Wed, Mar 07, 2012 at 06:37:42PM +0100, Pierre Labastie wrote:
Le 07/03/2012 18:01, Pierre Labastie a écrit :
See attached patch.
Forgotten, sorry.
Index: blfsbook/general/sysutils/dbus-bindings.xml
===
---
Pierre Labastie wrote:
The tool generated the following build order:
dbus libffi python2 pcre glib2 dbus-glib perl-xml-parser
intltool pkgconfig polkit accountsservice.
Proposed solution: add pkg-config as a required dependency,
and suppress glib2, since it is a dependency of pkg-config.
On Wed, 07 Mar 2012 18:01:32 +0100
Pierre Labastie pierre.labas...@neuf.fr wrote:
As a test of the new jhalfs/BLFS tools, I have tried
to compile 'accountservice' (the first package in the
book). The tool generated the following build order:
dbus libffi python2 pcre glib2 dbus-glib
Le 07/03/2012 19:34, Andrew Benton a écrit :
On Wed, 07 Mar 2012 18:01:32 +0100
Pierre Labastiepierre.labas...@neuf.fr wrote:
As a test of the new jhalfs/BLFS tools, I have tried
to compile 'accountservice' (the first package in the
book). The tool generated the following build order:
dbus
On Thu, 15 Dec 2011 19:10:04 -0600
Bruce Dubbs bruce.du...@gmail.com wrote:
More on D_BUS. The install creates /var/run/dbus, but that will go away
with a reboot. We need to figure out a way to create it upon boot.
The first LFS boot script, mountvirtfs, does:
mkdir -p /run
mount -n
On Fri, 16 Dec 2011 00:46:48 -0600
Bruce Dubbs bruce.du...@gmail.com wrote:
This is getting complicated. I can build and install dbus-1.4.16.tar.gz
without noticing any problems.
In order to run the tests, I need:
D-Bus GLib Bindings (update to 0.98)
D-Bus Python Bindings (update
Andrew Benton wrote:
On Fri, 16 Dec 2011 00:46:48 -0600
Bruce Dubbs bruce.du...@gmail.com wrote:
This is getting complicated. I can build and install dbus-1.4.16.tar.gz
without noticing any problems.
In order to run the tests, I need:
D-Bus GLib Bindings (update to 0.98)
D-Bus Python
On Thu, Dec 15, 2011 at 07:10:04PM -0600, Bruce Dubbs wrote:
More on D_BUS. The install creates /var/run/dbus, but that will go away
with a reboot. We need to figure out a way to create it upon boot.
Is that a theoretical problem, or is it actually broken on your
system ? The dbus init.d
Ken Moffat wrote:
On Thu, Dec 15, 2011 at 07:10:04PM -0600, Bruce Dubbs wrote:
More on D_BUS. The install creates /var/run/dbus, but that will go away
with a reboot. We need to figure out a way to create it upon boot.
Is that a theoretical problem, or is it actually broken on your
Andrew Benton wrote:
On Fri, 16 Dec 2011 20:27:29 +
Ken Moffat zarniwh...@ntlworld.com wrote:
Ah, I see, you build dbus but not the bootscripts. AFAIK, the
bootscript has been required for a long time. I see no obvious
reason to add dbus-launch to .xinitrc.
I also see no reason to
On Fri, Dec 16, 2011 at 06:03:42PM -0600, Bruce Dubbs wrote:
I suspect (but am not sure) that dbus is not very useful on a non-gui
desktop or server. If that's the case, then launching via dbus-launch
to .xinitrc makes sense.
I've always thought that for *my* uses, dbus was a build-time
On 12/16/2011 6:03 PM, Bruce Dubbs wrote:
I'm not an expert in how dbus is used, but if you do not use the
bootscript and do use the dbus-launch, isn't that sufficient?
My understanding with D-Bus is that you must launch the system
deamon so that it will respond to user requests.
The system
On Fri, 16 Dec 2011 18:03:42 -0600
Bruce Dubbs bruce.du...@gmail.com wrote:
I'm not an expert in how dbus is used, but if you do not use the
bootscript and do use the dbus-launch, isn't that sufficient?
Yes, I think so. I'm going to delete the dbus bootscripts on my systems
and just start it
Ken Moffat wrote:
On Fri, Dec 16, 2011 at 06:03:42PM -0600, Bruce Dubbs wrote:
I suspect (but am not sure) that dbus is not very useful on a non-gui
desktop or server. If that's the case, then launching via dbus-launch
to .xinitrc makes sense.
I've always thought that for *my* uses, dbus
Wayne Blaszczyk wrote:
On 15/12/11 16:28, Bruce Dubbs wrote:
Wayne,
In the D-BUS instructions, what does this mean?
useradd -c D-BUS Message Daemon User -d /dev/null \
-u 18 -g messagebus -s /bin/false messagebus || [ $? == 9 ]
Accidental update from a script?
-- Bruce
On Thu, 15 Dec 2011 16:25:17 -0600
Bruce Dubbs bruce.du...@gmail.com wrote:
Also, the construct is not explained. I think it should be removed.
I agree it should be explained, then people can make an informed
choice. I don't mind that it's different from the other pages where
useradd is used.
pages where
useradd is used.
I still don't see the value:
$ sudo useradd -c D-BUS Message Daemon User -d /dev/null -u 18 -g
messagebus -s /bin/false messagebus || [ $? == 9 ]
$ sudo useradd -c D-BUS Message Daemon User -d /dev/null -u 18 -g
messagebus -s /bin/false messagebus || [ $? == 9
On Thu, Dec 15, 2011 at 11:44:48PM +, Andrew Benton wrote:
On Thu, 15 Dec 2011 16:25:17 -0600
Bruce Dubbs bruce.du...@gmail.com wrote:
Also, the construct is not explained. I think it should be removed.
I agree it should be explained, then people can make an informed
choice. I
tar -xf dbus-1.4.16.tar.gz
cd dbus-1.4.16
./configure --enable-tests --enable-asserts
Full test coverage (--enable-modular-tests=yes or --enable-tests=yes)
requires dbus-glib
-
But the D-Bus GLib Bindings require D-Bus to be installed. The required
sequence appears to be:
Install D-Bus
More on D_BUS. The install creates /var/run/dbus, but that will go away
with a reboot. We need to figure out a way to create it upon boot.
The first LFS boot script, mountvirtfs, does:
mkdir -p /run
mount -n /run || failed=1
mkdir -p /run/{var,lock,shm}
The /etc/sysconfig/rc.site is sourced
On 12/15/2011 07:10 PM, Bruce Dubbs wrote:
More on D_BUS. The install creates /var/run/dbus, but that will go away
with a reboot. We need to figure out a way to create it upon boot.
The first LFS boot script, mountvirtfs, does:
mkdir -p /run
mount -n /run || failed=1
mkdir -p
DJ Lucas wrote:
On 12/15/2011 07:10 PM, Bruce Dubbs wrote:
More on D_BUS. The install creates /var/run/dbus, but that will go away
with a reboot. We need to figure out a way to create it upon boot.
The first LFS boot script, mountvirtfs, does:
mkdir -p /run
mount -n /run || failed=1
/dbus/dbus-1.4.16.tar.gz
tar -xf dbus-1.4.16.tar.gz
cd dbus-1.4.16
./configure --enable-tests --enable-asserts
Full test coverage (--enable-modular-tests=yes or --enable-tests=yes)
requires dbus-glib
-
But the D-Bus GLib Bindings require D-Bus to be installed. The required
that it's different from the other pages where
useradd is used.
I still don't see the value:
$ sudo useradd -c D-BUS Message Daemon User -d /dev/null -u 18 -g
messagebus -s /bin/false messagebus || [ $? == 9 ]
$ sudo useradd -c D-BUS Message Daemon User -d /dev/null -u 18 -g
messagebus
Wayne,
In the D-BUS instructions, what does this mean?
useradd -c D-BUS Message Daemon User -d /dev/null \
-u 18 -g messagebus -s /bin/false messagebus || [ $? == 9 ]
Accidental update from a script?
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http
On 15/12/11 16:28, Bruce Dubbs wrote:
Wayne,
In the D-BUS instructions, what does this mean?
useradd -c D-BUS Message Daemon User -d /dev/null \
-u 18 -g messagebus -s /bin/false messagebus || [ $? == 9 ]
Accidental update from a script?
-- Bruce
No, not accidental
Hi all,
If our target for BLFS is LFS-6.7, what version of D-Bus should we
put in the book? The BLFS book's version of D-Bus is way behind in
version updates, but I know there is compatibility issues with the
deprecation of HAL, etc.
Does anyone (Dan, could you pitch in and help out
On Tue, Nov 9, 2010 at 4:52 PM, Randy McMurchy
ra...@linuxfromscratch.org wrote:
Hi all,
If our target for BLFS is LFS-6.7, what version of D-Bus should we
put in the book? The BLFS book's version of D-Bus is way behind in
version updates, but I know there is compatibility issues
Dan Nicholson wrote these words on 11/09/10 20:01 CST:
The tight coupling between D-Bus and HAL should be gone. HAL is in
compatibility mode and should work with any recent D-Bus. A lot of
apps have moved away from HAL but it'll still be needed in spots.
I haven't looked closely at D-Bus
Hi all,
I know this has been briefly discussed, but I think I remember
someone not too long ago having an issue with a non-standard
D-Bus services directory and having to use an
/etc/dbus-1/session-local.conf file and it messing something up.
I'm strictly going on something *I think* I remember
On Fri, Mar 12, 2010 at 02:06:45PM -0600, Randy McMurchy wrote:
Bruce Dubbs wrote these words on 03/12/10 13:02 CST:
As a note, ps is now printing a uid instead of the name if the name is
too long. Changing the names s/haldaemon/hald/ and s/messagebus/msgbus/
in /etc/passwd provides the
Hi all,
I would like to update the book to version 1.2.20 of D-Bus and version
0.5.14 of HAL (D-Bus bindings to current versions as well. Has anyone
had any problems with these versions, or know anything that keeps us from
updating the packages? They build fine for me, but I'm not sure I use
Randy McMurchy wrote:
Hi all,
I would like to update the book to version 1.2.20 of D-Bus and version
0.5.14 of HAL (D-Bus bindings to current versions as well. Has anyone
had any problems with these versions, or know anything that keeps us from
updating the packages? They build fine for me
Bruce Dubbs wrote these words on 03/12/10 13:02 CST:
As a note, ps is now printing a uid instead of the name if the name is
too long. Changing the names s/haldaemon/hald/ and s/messagebus/msgbus/
in /etc/passwd provides the user name.
That has been standard behavior for years and years. I
Randy McMurchy wrote:
Bruce Dubbs wrote these words on 03/12/10 13:02 CST:
As a note, ps is now printing a uid instead of the name if the name is
too long. Changing the names s/haldaemon/hald/ and s/messagebus/msgbus/
in /etc/passwd provides the user name.
That has been standard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Has anyone got any objections to split the D-Bus Bindings packages into
their own individual pages? Reason, less clutter on an individual page.
eggdbus is another D-Bus binding package.
Regards,
Wayne.
-BEGIN PGP SIGNATURE-
Version: GnuPG
Wayne Blaszczyk wrote:
Has anyone got any objections to split the D-Bus Bindings packages into
their own individual pages? Reason, less clutter on an individual page.
eggdbus is another D-Bus binding package.
Well, since you are soliciting opinions, I'd prefer they all
stay on one page, but I
Under D-Bus we use the --libexec flag to put the files in
/usr/lib/dbus-1.0. However, with the Glib bindings we don't do that even
though it puts files in /usr/libexec. I think that we should use
--libexecdir for the bindings, '--libexecdir=/usr/lib/dbus-1.0/dbus-glib'
should be suitable
I ran into a problem with D-Bus today. I was running vmware and all of a
sudden, it wouldn't start any more. vmplayer wouldn't work either.
Running gdb indicated a segfault in dbus, so I stopped dbus and vmplayer
started
working.
I'm running dbus-1.0.2 right now. Does anyone have any
On 7/14/07, Randy McMurchy [EMAIL PROTECTED] wrote:
BTW, I'm using HAL-0.5.9.1 and the most recent hal-info tarball using
the book instructions. Seems to be fine. If you want, I can update the
book. One thing I did was modify the configure script so that it will
accept the most recent version
for the D-Bus Qt3 bindings and putting it on anduin?
http://www.linuxfromscratch.org/~dnicholson/downloads/dbus-qt3-0.62.tar.bz2
http://www.linuxfromscratch.org/~dnicholson/downloads/dbus-qt3.txt
You can roll a snapshot yourself, but I don't think the ones on the
freedesktop page are going to work
Dan Nicholson wrote these words on 07/12/07 08:11 CST:
Thanks for your help, Jens. That's what happened when I tested them,
too. Randy, how do you feel about using the snapshot I rolled a few
months ago for the D-Bus Qt3 bindings and putting it on anduin?
Sounds fine to me. I'm a few hours
On 7/10/07, Jens Stroebel [EMAIL PROTECTED] wrote:
Just a question regarding dbus-hal-KDE interaction; I have the right
impression when I think it's still nescessary to use the dbus-0.69 qt
bindings if one wants the KDE desktop to show device icons when e.g. an
USB stick is plugged in, right?
in, right?
I don't know anything about the dbus-0.69 qt bindings. In fact, I was
doing the updates to packages that list HAL as a dependency (did the
D-Bus dependencies yesterday) when you sent this message.
For KDE (and K3b) I've included in the HAL dependency a note saying the
Qt3 bindings
On 7/10/07, Randy McMurchy [EMAIL PROTECTED] wrote:
I've also put a note on both packages that this combination has not yet
been tested by the BLFS team. I will be testing it shortly, but wanted
to clarify the book first.
A while back I checked what would build, and the tarball from the dbus
Dan Nicholson wrote:
[...snip...]
Yes, they're still needed, we just haven't gotten that far yet. If
you'd like to be the guinea pig, please see this post from a couple
months ago when I was investigating this.
[...]
If you use KDE with the HAL backend, I'd appreciate if you
On 7/10/07, Jens Stroebel [EMAIL PROTECTED] wrote:
As far as I can tell, the combination of
dbus-1.0.2
dbus-qt3-0.62
dbus-glib-0.74
hal-0.5.9
qt-3.3.8
builds fine and works with regards to KDE being able to offer device
icons for appearingUSB sticks/CDs
Great. If you wouldn't
to post the hal diff a bit later, but it might not make a lot
of sense until the dbus core + bindings gets worked out.
Dan,
I went back and reviewed our old thread about D-Bus/HAL and forgot
that you had already created the D-Bus-1.0.2 page and modified bootscript.
Would you care to update the D
Dan Nicholson wrote these words on 07/09/07 14:34 CST:
Yeah, I found my patch. I'll start massaging it into current form.
I'll try to get that in in the next few days so things don't get too
broken. The core vs. bindings dependencies could take some iterations.
You can start making changes on
On 7/9/07, Randy McMurchy [EMAIL PROTECTED] wrote:
I went back and reviewed our old thread about D-Bus/HAL and forgot
that you had already created the D-Bus-1.0.2 page and modified bootscript.
Would you care to update the D-Bus page? The one you made (it is still
available) looks good to me
section from d-bus and the mention of it on the hal page. This is
because it will just be replaced with dependencies on dbus-glib and
optional dbus-python for hal-device-manager, which I'll note. It just
didn't seem worth it to keep the all that text in sync when it would
go away after the rest
Hi all,
I want to put the D-Bus bindings in a separate package. I'm leaning
to putting it in Chapter 8 - 'General Libraries' but they probably
would be just as valid (functionally speaking) in Chapter 12 -
Programming as they really are nothing but programming support stubs
for various languages
On 7/8/07, Randy McMurchy [EMAIL PROTECTED] wrote:
However, since the BLFS use of them will be to support the building
of other packages, I lean to the General Libraries.
Seems fine to me. I don't know if it's that important.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
On 4/26/07, Dan Nicholson [EMAIL PROTECTED] wrote:
I have a couple changes to make on dbus that Bruce and others
suggested. I have to test out the make check make clean, but I
think it's safe. Are you still handling the bindings? Should I commit
the dbus change?
I'm just going to push out
On 4/27/07, Dan Nicholson [EMAIL PROTECTED] wrote:
On 4/26/07, Dan Nicholson [EMAIL PROTECTED] wrote:
I have a couple changes to make on dbus that Bruce and others
suggested. I have to test out the make check make clean, but I
think it's safe. Are you still handling the bindings? Should
1 - 100 of 212 matches
Mail list logo
