Bruce Dubbs wrote:
> Bryan Kadzban wrote:
>
>> Probably also want to double check whether any of the following are
>> still being built or checked for:
>>
>> acl (libsystemd-acl.la)
>> tcpwrap (see if configure is checking for it)
>> hostnamed (systemd-hostnamed)
>> timedated (systemd-timedate
Bryan Kadzban wrote:
> Probably also want to double check whether any of the following are
> still being built or checked for:
>
> acl (libsystemd-acl.la)
> tcpwrap (see if configure is checking for it)
> hostnamed (systemd-hostnamed)
> timedated (systemd-timedated)
> localed (libsystemd-dbu
Bruce Dubbs wrote:
> I grabbed the current git version of Makefile.am and applied the patch
> with no errors. autoreconf also works without error.
>
> ./configure --disable-systemd --with-usb-ids-path=no \
> --with-pci-ids-path=no
>
> ...
>
> configure: error: Package requirements
Bryan Kadzban wrote:
> DJ Lucas wrote:
>> On 06/03/2012 02:03 PM, Bruce Dubbs wrote:
>>> Bryan, I tried the patch you submitted to linux-hotplug yesterday:
>>>
>>> systemd-make-systemd-optional.patch
>>>
>>> It doesn't apply cleanly to either systemd-183 or -184.
>> It applies with offsets to git m
DJ Lucas wrote:
> On 06/03/2012 02:03 PM, Bruce Dubbs wrote:
>> Bryan, I tried the patch you submitted to linux-hotplug yesterday:
>>
>> systemd-make-systemd-optional.patch
>>
>> It doesn't apply cleanly to either systemd-183 or -184.
>
> It applies with offsets to git master...which hopefully s
On 06/03/2012 02:03 PM, Bruce Dubbs wrote:
> Bryan, I tried the patch you submitted to linux-hotplug yesterday:
>
> systemd-make-systemd-optional.patch
>
> It doesn't apply cleanly to either systemd-183 or -184.
>
>
It applies with offsets to git master...which hopefully soon will be -185.
git://a
Bryan, I tried the patch you submitted to linux-hotplug yesterday:
systemd-make-systemd-optional.patch
It doesn't apply cleanly to either systemd-183 or -184.
-- Bruce
patching file Makefile.am
Hunk #1 succeeded at 201 (offset -1 lines).
Hunk #2 succeeded at 448 (offset -1 lines).
Hunk #3 su
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> You are not doing this in an LFS Chapter 6 type of environment. I did
>> this and immediately got:
>
> Yeah, you're right, see my reply to Ken. No system in the proper state
> to test that at the moment. :-(
>
>> Anouther problem is that src/shared
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> Perhaps it's because I invested so much work in the last couple of days,
>> but I am leaning towards static linking of udevd and udevadm. At least
>> the udev part.
>
> ldd /usr/bin/Xorg
> linux-vdso.so.1 => (0x7fff4455c000)
> li
Bruce Dubbs wrote:
> You are not doing this in an LFS Chapter 6 type of environment. I did
> this and immediately got:
Yeah, you're right, see my reply to Ken. No system in the proper state
to test that at the moment. :-(
> Anouther problem is that src/shared/util.c is needed to build the ude
Ken Moffat wrote:
> My first thought was "I wonder how he's disabled the tests for
> intltool and XML::Parser?". You're on a completed system.
Arg, you're right of course. (I don't have a chapter-6-level system
handy to use for testing, hence my comment earlier about missing some of
the required
Bruce Dubbs wrote:
> Perhaps it's because I invested so much work in the last couple of days,
> but I am leaning towards static linking of udevd and udevadm. At least
> the udev part.
ldd /usr/bin/Xorg
linux-vdso.so.1 => (0x7fff4455c000)
libudev.so.0 => /usr/lib64/libudev.s
Ken Moffat wrote:
>
> Obviously /lib64 because you are on multilib. We'll use /lib, but
> I guess the shared lib needs to be accessible from /usr/lib.
We really don't want udev libraries on /usr. They are used early in the
boot process before (potentially) mounting /usr.
Perhaps it's becaus
On Wed, May 30, 2012 at 11:48:22AM -0500, Bruce Dubbs wrote:
>
> You are not doing this in an LFS Chapter 6 type of environment. I did
> this and immediately got:
>
> ./configure: line 12067: intltool-update: command not found
> checking for intltool >= 0.40.0... found
> configure: error: Your
Bryan Kadzban wrote:
> Bryan Kadzban wrote:
>> Upgrading kmod now; will see what I hit next. This might just work;
>> let's see. :-)
>
> Got it to compile all the binaries (I think) we need, by removing a
> couple of totally unnecessary dependencies from libsystemd-label. :-)
>
> Reformatting
On Tue, May 29, 2012 at 11:24:39PM -0700, Bryan Kadzban wrote:
>
> seems to generate the right set of binaries and files under
> /tmp/udev-test. Of course we still have to rename
> /lib/udev/systemd-udevd to plain old /lib/udev/udevd. (Or change the
> target in rootlibexecdir, actually. Looks like
On Tue, May 29, 2012 at 10:32:29PM -0700, Bryan Kadzban wrote:
> Bryan Kadzban wrote:
> > Upgrading kmod now; will see what I hit next. This might just work;
> > let's see. :-)
>
> Got it to compile all the binaries (I think) we need, by removing a
> couple of totally unnecessary dependencies f
Bryan Kadzban wrote:
> DBUS_CFLAGS=" " \
> DBUS_LIBS=" " \
> BLKID_CFLAGS="-I/usr/include/blkid" \
> BLKID_LIBS="-L/lib64 -lblkid" \
> KMOD_CFLAGS="-I/usr/include" \
> KMOD_LIBS="-L/lib64 -lkmod" \
> ./configure --prefix=/usr \
> --with-rootprefix='' \
> --bindir=/sbin \
>
Bryan Kadzban wrote:
> Upgrading kmod now; will see what I hit next. This might just work;
> let's see. :-)
Got it to compile all the binaries (I think) we need, by removing a
couple of totally unnecessary dependencies from libsystemd-label. :-)
Reformatting ./configure so the flags look clos
Bryan Kadzban wrote:
> Bryan Kadzban wrote:
>> Let me see if I can hack anything up.
>
> Still poking.
OK (now that I'm replying to myself here :-) ), I think I have something
that's looking promising. This makes it all the way through configure,
and part of the way through "make udevd", without
Bryan Kadzban wrote:
> Bruce Dubbs wrote:
>> I came up with one problem that I need advice on. I can't build the
>> keymap program becasue I'm missing keys-from-name.h and
>> keys-to-name.h. The systemd configure/make command generates them
>> using gperf. In udev-182, there are over 70 entries i
Bruce Dubbs wrote:
> I came up with one problem that I need advice on. I can't build the
> keymap program becasue I'm missing keys-from-name.h and
> keys-to-name.h. The systemd configure/make command generates them
> using gperf. In udev-182, there are over 70 entries in
> src/keymap/keymaps. Th
Bruce Dubbs wrote:
> I still need to create install.sh
This is what I came up with:
---
cd build
SBIN=/sbin
UDEVLIBEXECDIR=/lib/udev
cp -v udevadm $SBIN
mkdir -p $UDEVLIBEXECDIR/{rules.d,devices/pts}
mknod -m 0666 $UDEVLIBEXECDIR/devices/null c 1 3
cp -v udevd accelerometer scsi_i
OK, I've been able to build udev from the systemd sources in the LFS
Chapter 6 environment. Here is the procedure:
1. Place make.sh and cfg.h in the top level systemd directory
2. Comment out an unneeded header that we don't have
sed -i -e 's#^.*capability.h#//&#' src/shared/util.c
3. Run
On Tue, May 29, 2012 at 12:55:36AM -0500, Bruce Dubbs wrote:
>
> The script I built to compile and link the programs is fairly long (and
> ugly to my taste), but also pretty straight forward. I haven't tested
> the programs yet, but the build is clean.
>
> If we have to, we can create a 'patch
I've been able to build udevadm, udevd, and accelerometer in the new
distribution. I had to build each file separately and come up with the
link scripts, but none of the spurious packages are needed. I'll check
the other libexec programs tomorrow.
Optimally we need to get upstream to split th
On Mon, May 28, 2012 at 07:27:18PM -0500, Bruce Dubbs wrote:
>
> Well there is also:
>
> sed -i -e "s,systemd.*-,,gi" man/udev.7 man/*udev*.8
>^ ^^
> :)
>
Yes, much nicer :)
> And of course after installation:
>
> pushd /usr/share/man/man8
> mv
LFS Trac wrote:
> Comment(by ken@…):
>
> For the man pages (without renaming until after the build/install), the
> slackware sed isn't enough to catch the systemd\- items in the text, nor
> the SYSTEMD\- header on systemd-udevd.8. The following sed fixes all of
> this, and (applied before con
28 matches
Mail list logo
