Re: [systemd-devel] [HEADS-UP] Intent to remove readahead from systemd

2014-09-26 Thread Samuli Suominen 

On 26/09/14 09:58, Tom Gundersen wrote:
> On Thu, Sep 25, 2014 at 6:40 PM, Pacho Ramos  wrote:
>> El jue, 25-09-2014 a las 16:44 +0200, Tom Gundersen escribió:
>>> On Thu, Aug 14, 2014 at 7:16 PM, Lennart Poettering
>>>  wrote:
 So, I think with the release after the upcoming one we should just
 remove it from the systemd package and just throw it on the pile of
 historic cruft. So, yeah, here's the advance warning that this will be
 happening...

 (Well, unless somebody from the community who cares and wants to invest
 the necessary time in it steps up and gives it the love it really
 needs. If nobody does until that release, I will delete the component
 from systemd).
>>> No one objected to this, so I pushed the patch deleting it. If anyone
>>> wants to resurrect this in an external repo, it should be simple
>>> enough to extract it from git.
>>>
>>> Cheers,
>>>
>>> Tom
>>> ___
>>> systemd-devel mailing list
>>> systemd-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> Is there any other readahead implementation around that we could migrate
>> to? Well, not sure many laptops with SSD are sold in your area but, at
>> least in mine, most people still have (and buy) setups with rotational
>> hard drives that have a clear gain when running readahead (well, I can
>> see it every time I reboot and login on gnome-shell if I don't use
>> readahead)
> I think the best bet would be someone who understands/knows/uses this
> stuff to resurrect systemd-readahead in a third-party repo and
> maintain it there. AFAIK, it was the best of the available options.
>
> Cheers,
>
> Tom

This sounds like the best option to me too, anyone can pick up the
systemd-readahead
code and create a e.g. github repository for it

+1

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] udevd: SAS: use SAS addr + PHY id in by-path whenever possible.

2014-09-22 Thread Samuli Suominen 

On 22/09/14 17:58, Tom Gundersen wrote:
> Hi Maurizio,
>
> On Mon, Sep 22, 2014 at 11:48 AM, Maurizio Lombardi  
> wrote:
>> This patch changes the naming scheme for sas disks. The original names used
>> disk's sas address and lun, the new scheme uses sas address of the
>> nearest expander (if available) and a phy id of the used connection.
>> If no expander is used, the phy id of hba phy is used.
>> Note that names that refer to RAID or other abstract devices are
>> unchanged.
> What's the problem with the current scheme, what's the benefit of the
> new one? Will this break backwards compatibility, if so, why is this
> justifiable?
>

I wonder if it will solve this one...

https://bugs.freedesktop.org/show_bug.cgi?id=63806

?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-216 (and git) fails to compile with Linux 3.7 headers (error: 'IFF_MULTI_QUEUE' undeclared)

2014-08-31 Thread Samuli Suominen 
Looks like src/shared/missing.h is missing IFF_MULTI_QUEUE

The relavent part of the build log, configured with --enable-networkd:
 
/bin/sh ./libtool  --tag=CC   --mode=compile x86_64-pc-linux-gnu-gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I/tmp/portage/sys-apps/systemd-216/work/systemd-216  
-include ./config.h -DPKGSYSCONFDIR=\"/etc/systemd\" 
-DSYSTEM_CONFIG_UNIT_PATH=\"/etc/systemd/system\" 
-DSYSTEM_DATA_UNIT_PATH=\"/lib/systemd/system\" -DSYSTEM_SYSVINIT_PATH=\"\" 
-DSYSTEM_SYSVRCND_PATH=\"\" -DUSER_CONFIG_UNIT_PATH=\"/etc/systemd/user\" 
-DUSER_DATA_UNIT_PATH=\"/usr/lib/systemd/user\" -DCERTIFICATE_ROOT=\"/etc/ssl\" 
-DCATALOG_DATABASE=\"/var/lib/systemd/catalog/database\" 
-DSYSTEMD_CGROUP_AGENT_PATH=\"/lib/systemd/systemd-cgroups-agent\" 
-DSYSTEMD_BINARY_PATH=\"/lib/systemd/systemd\" 
-DSYSTEMD_SHUTDOWN_BINARY_PATH=\"/lib/systemd/systemd-shutdown\" 
-DSYSTEMD_SLEEP_BINARY_PATH=\"/lib/systemd/systemd-sleep\" 
-DSYSTEMCTL_BINARY_PATH=\"/bin/systemctl\" 
-DSYSTEMD_TTY_ASK_PASSWORD_AGENT_BINARY_PATH=\"/bin/systemd-tty-ask-password-agent\"
 -DSYSTEMD_STDIO_BRIDGE_BINARY_PATH=\"/usr/bin/systemd-stdio-bridge\" 
-DROOTPREFIX=\"\" -
 DRANDOM_SEED_DIR=\"/var/lib/systemd/\" 
-DRANDOM_SEED=\"/var/lib/systemd/random-seed\" 
-DSYSTEMD_CRYPTSETUP_PATH=\"/lib/systemd/systemd-cryptsetup\" 
-DSYSTEM_GENERATOR_PATH=\"/lib/systemd/system-generators\" 
-DUSER_GENERATOR_PATH=\"/usr/lib/systemd/user-generators\" 
-DSYSTEM_SHUTDOWN_PATH=\"/lib/systemd/system-shutdown\" 
-DSYSTEM_SLEEP_PATH=\"/lib/systemd/system-sleep\" 
-DSYSTEMD_KBD_MODEL_MAP=\"/usr/share/systemd/kbd-model-map\" 
-DX_SERVER=\"/usr/bin/X\" -DUDEVLIBEXECDIR=\"/lib/udev\" 
-DPOLKIT_AGENT_BINARY_PATH=\"/usr/bin/pkttyagent\" 
-DQUOTACHECK=\"/usr/sbin/quotacheck\" -DKEXEC=\"/usr/sbin/kexec\" 
-DLIBDIR=\"/usr/lib64\" -DROOTLIBDIR=\"/lib64\" 
-DTEST_DIR=\"/tmp/portage/sys-apps/systemd-216/work/systemd-216/test\" -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src -I ./src/shared -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/shared -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/network -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/login -I
  /tmp/portage/sys-apps/systemd-216/work/systemd-216/src/journal -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/timedate -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/timesync -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/resolve -I ./src/resolve 
-I /tmp/portage/sys-apps/systemd-216/work/systemd-216/src/systemd -I ./src/core 
-I /tmp/portage/sys-apps/systemd-216/work/systemd-216/src/core -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/libudev -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/udev -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/udev/net -I ./src/udev 
-I /tmp/portage/sys-apps/systemd-216/work/systemd-216/src/libsystemd/sd-bus -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/libsystemd/sd-event -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/libsystemd/sd-rtnl -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/libsystemd/sd-network -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-21
 6/src/libsystemd-network -I 
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/libsystemd-terminal   
-pipe -Wall -Wextra -Wno-inline -Wundef -Wformat=2 -Wformat-security 
-Wformat-nonliteral -Wlogical-op -Wsign-compare -Wmissing-include-dirs 
-Wold-style-definition -Wpointer-arith -Winit-self 
-Wdeclaration-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn 
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls 
-Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels 
-Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings 
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result 
-Wno-typedef-redefinition -Werror=overflow -Wnested-externs -ffast-math 
-fno-common -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden 
-ffunction-sections -fdata-sections -fstack-protector -fPIE 
--param=ssp-buffer-size=4 -ffat-lto-objects   -O2 -pipe -march=native 
-frecord-gcc-switches -Wall -MT src/network/libsystemd_networkd_core_la-ne
 tworkd-dhcp4.lo -MD -MP -MF 
src/network/.deps/libsystemd_networkd_core_la-networkd-dhcp4.Tpo -c -o 
src/network/libsystemd_networkd_core_la-networkd-dhcp4.lo `test -f 
'src/network/networkd-dhcp4.c' || echo 
'/tmp/portage/sys-apps/systemd-216/work/systemd-216/'`src/network/networkd-dhcp4.c
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/network/networkd-netdev-tuntap.c:
 In function 'netdev_fill_tuntap_message':
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/network/networkd-netdev-tuntap.c:52:35:
 error: 'IFF_MULTI_QUEUE' undeclared (first use in this function)
 ifr->ifr_flags |= IFF_MULTI_QUEUE;
   ^
/tmp/portage/sys-apps/systemd-216/work/systemd-216/src/network/networkd-netdev-tuntap.c:52:35:
 note: each undeclared identifier is repor

Re: [systemd-devel] [PATCH] Removed PPC 32 bit LE architecture

2014-08-14 Thread Samuli Suominen 

On 11/08/14 17:14, Lennart Poettering wrote:
> On Mon, 11.08.14 15:57, Lennart Poettering (lenn...@poettering.net) wrote:
>
>> On Fri, 08.08.14 17:00, har...@redhat.com (har...@redhat.com) wrote:
>>
>>> From: Harald Hoyer 
>>>
>>> According to Brent Baude , who provided the patch,
>>> IBM doesn't want to support the PPC 32 bit LE architecture at all.
>> What is "support" supposed to mean? Does that mean that the silicon for
>> PPC32LE has and will never exist? Or does this mean that they are simply
>> not interested in supporting Linux on ppc32le like this with support
>> employees and stuff?
>>
>> I think if the silicon exists and people play around with it, we should
>> keep the thing probably. However, if this is a theoretic architecture
>> only, then let's kill it.
> Judging by this it's something that actually exists:
>
> http://lwn.net/Articles/408051/
>
> Hence I think we should leave the arch in... 
>
> Lennart
>

Thanks.

(As in, it's supported arch in Gentoo)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] #include src/shared/missing.h in src/shared/util.h for missing struct file_handle definition

2014-08-01 Thread Samuli Suominen 

On 01/08/14 18:31, Simon McVittie wrote:
> On 01/08/14 15:53, Simon McVittie wrote:
>> Best-practice in Autotools projects seems to be to include config.h at
>> the very top of every .c file, whether it is currently needed or not.
> Sorry, I'd missed that systemd uses "cc -include
> $(top_builddir)/config.h ...", which is even better. My issues with
> btrfs_ioctl_vol_args must have been caused by something else.
>
> S
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

nod. I've just tested the original patch I posted, seems to work here...
I suppose it's best to apply the initlal patch first, and see if someone
gets a failed build...


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] #include src/shared/missing.h in src/shared/util.h for missing struct file_handle definition

2014-08-01 Thread Samuli Suominen 

On 01/08/14 17:53, Simon McVittie wrote:
> On 01/08/14 15:43, Samuli Suominen wrote:
>> Please, #include "missing.h" in src/shared/util.h to fix the build for
>> old systems w/ no system header defining
>> the struct
> I ran into the same thing on a slightly odd system (Debian 7 with a
> backported kernel, so it has Linux 3.14 but only glibc 2.13)

Almost same. Same enough to be the same.

> and
> initially tried an identical patch, but it turned out to break the
> build, because missing.h redefines a bunch of stuff from 

Ah, should have verified with a full build. Nice catch!

> Thanks for reminding me to upstream this!

Likewise.

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [patch] #include src/shared/missing.h in src/shared/util.h for missing struct file_handle definition

2014-08-01 Thread Samuli Suominen 
Mike Frysinger pointed out util.h is using a struct defined in missing.h
but doesn't #include it:

util.h has:

union file_handle_union {
struct file_handle handle;
char padding[sizeof(struct file_handle) + MAX_HANDLE_SZ];
};

missing.h has:

#if !HAVE_DECL_NAME_TO_HANDLE_AT
struct file_handle {
unsigned int handle_bytes;
int handle_type;
unsigned char f_handle[0];
};

static inline int name_to_handle_at(int fd, const char *name, struct
file_handle *handle, int *mnt_id, int flags) {
return syscall(__NR_name_to_handle_at, fd, name, handle, mnt_id,
flags);
}
#endif

Please, #include "missing.h" in src/shared/util.h to fix the build for
old systems w/ no system header defining
the struct

Thanks!

- Samuli
>From 4e44677efbcc586716fe65ed044836877315b3f0 Mon Sep 17 00:00:00 2001
From: Samuli Suominen 
Date: Fri, 1 Aug 2014 17:38:38 +0300
Subject: [PATCH] Include missing.h in util.h for missing struct file_handle
 definition

---
 src/shared/util.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/shared/util.h b/src/shared/util.h
index 4529480..bfbcbcd 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -84,6 +84,7 @@
 #endif
 
 #include "macro.h"
+#include "missing.h"
 #include "time-util.h"
 
 /* What is interpreted as whitespace? */
-- 
2.0.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build-sys: check for intltool also when polkit is enabled

2014-07-31 Thread Samuli Suominen 

On 31/07/14 15:18, Robert Schiele wrote:
> intltool is needed for nls _and_ polkit, thus the check needs to be
> changed to do the test whenever one of them is enables.
>
> Without this build fails when configured with
> --disable-nls --enable-polkit
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 43b6eef..0802cfc 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -62,7 +62,7 @@ AS_IF([test x"$intltool_found" != xyes],
>])
>  
>  AM_NLS
> -AS_IF([test x"$enable_nls" != xno], [
> +AS_IF([test x"$enable_nls" != xno -o "x$enable_polkit" != xno], [
>  # intltoolize greps for '^(AC|IT)_PROG_INTLTOOL', so it needs to be on 
> its own line
>  IT_PROG_INTLTOOL([0.40.0])
>  ])

Isn't this scenario already covered by this existing configure.ac test...

AS_IF([test -z "$INTLTOOL_POLICY_RULE"], [
# If intltool is not available, provide a dummy rule to fail
generation of %.policy files with a meaningful error message
INTLTOOL_POLICY_RULE='%.policy: %.policy.in ; @echo "  ITMRG   " $@
&& echo "*** intltool support required to build target $@" && false'
AC_SUBST(INTLTOOL_POLICY_RULE)
])

...?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Forward from linux-raid@ ML: systemd-215 creates inactive MD devices upon stopping them

2014-07-24 Thread Samuli Suominen 
Forwarding to systemd-devel@ for
http://bugs.gentoo.org/show_bug.cgi?id=517986


 Original Message 
Subject:Re: udev 215 creates inactive MD devices upon stopping them
Date:   Thu, 24 Jul 2014 17:48:05 +0200
From:   Sebastian Parschauer 
To: systemd-de...@freedesktop.org, Kay Sievers 
CC: Linux RAID ,
artur.paszkiew...@intel.com, Francis Moreau 



[resending to the correct mailing list]

Hi,

as discussed on linux-raid, please fix the bug that udev 215 creates
inactive MD devices upon stopping them.

Reference: http://www.spinics.net/lists/raid/msg46676.html
Reported-by: Francis Moreau 

An open() call to /dev/mdX after creating it with mknod is enough to
create such inactive MD device.

According to Artur the issue is caused by this change in udev:

> commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> Author: Kay Sievers 
> Date:   Sun Apr 13 19:54:27 2014 -0700
>
>  udev: serialize/synchronize block device event handling with file locks
>
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
>
> It seems that they have already disabled this for dm for some reason,
> but not for md:
>
> commit e918a1b5a94f270186dca59156354acd2a596494
> Author: Kay Sievers 
> Date:   Tue Jun 3 16:49:38 2014 +0200
>
> udev: exclude device-mapper from block device ownership event locking
>
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=e918a1b5a94f270186dca59156354acd2a596494
>

Thanks,
Sebastian


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Warnings from recent commits

2014-07-21 Thread Samuli Suominen 

On 21/07/14 16:05, Thomas H.P. Andersen wrote:
> On Mon, Jul 21, 2014 at 4:18 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> On Thu, Jul 17, 2014 at 08:51:52PM +0200, Thomas H.P. Andersen wrote:
>>> From recent commits I have noticed the following new issues from
>>> static analysis with scan-build and with clang. I am not sure how they
>>> should be fixed (or even if) but I just though I would let you know.
>>>
>>> 1) src/shared/barrier.c in barrier_read starting at line 274
>>>
>>> if (pfd[1].revents) {
>>> len = read(b->them, &buf, sizeof(buf));
>>> ...
>>> } else if (pfd[0].revents & (POLLHUP | POLLERR | POLLNVAL)) {
>>> ...
>>> buf = BARRIER_ABORTION;
>>> }
>>>
>>> If neither if/else if are true then buf will be used unset.
>>>
>>> 2) src/resolve/resolved-dns-scope.c in dns_scope_tcp_socket
>>> if s->link is null then ifindex will not be set but will be used later in:
>>>
>>> } else if (srv->family == AF_INET6) {
>>> sa.in6.sin6_port = htobe16(53);
>>> sa.in6.sin6_addr = srv->address.in6;
>>> sa.in6.sin6_scope_id = ifindex;
>>> salen = sizeof(sa.in6);
>>>
>>> 3) I see a couple of these:
>>>
>>> In file included from src/resolve/resolved-gperf.c:8:
>>> In file included from ./src/resolve/resolved.h:34:
>>> In file included from ./src/resolve/resolved-dns-query.h:33:
>>> In file included from ./src/resolve/resolved-dns-scope.h:33:
>>> ./src/resolve/resolved-dns-cache.h:45:3: warning: redefinition of
>>> typedef 'DnsCacheItem' is a C11 feature [-Wtypedef-redefinition]
>>> } DnsCacheItem;
>>>   ^
>>> ./src/resolve/resolved-dns-cache.h:31:29: note: previous definition is here
>>> typedef struct DnsCacheItem DnsCacheItem;
>> I'd simply add -Wno-typedef-redefinition to CLAGS... This is one
>> of those cases where the medicine is worse than the disease.
> Fine by me. Typedef redefinition was added in gcc 4.6 so we will need that.
>

4.6 is the minimum dependency as-is, for eg. _Static_assert,
DISABLE_WARNING_{DECLARATION_AFTER_STATEMENT,FORMAT_NONLITERAL,MISSING_PROTOTYPES,NONNULL},
REENABLE_WARNING
Just to get the udev part of the systemd tree compiled with gcc-4.5 or
older, you need something like,
http://510524.bugs.gentoo.org/attachment.cgi?id=380992

Just saying, that 4.6 minimum wouldn't be a new thing, it's been around
for several releases now

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 04/10] rules: set default polling interval on removable devices as well

2014-07-16 Thread Samuli Suominen 

On 16/07/14 14:01, Kay Sievers wrote:
> On Wed, Jul 16, 2014 at 12:09 PM, Jon Severinsson  
> wrote:
>> From: Martin Pitt 
>>
>> The events_dfl_poll_msecs rule will not trigger if "block" is not a module, 
>> but
>> built in. This will avoid udisks etc. having to poll from userspace, and
>> provide proper ejection when the hardware eject button is pressed.
> This is all backwards, "block" can never be a module.
>
> The setiings from the rules should be applied just fine by coldplug,
> triggering the /sys/module/ directory.

This looks like identical issue to,

http://bugs.gentoo.org/show_bug.cgi?id=503536

I never figured it out. Can you take a look?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] using /dev/root in fstab

2014-07-07 Thread Samuli Suominen 

On 07/07/14 14:32, Michael Biebl wrote:
> 2014-07-07 10:14 GMT+02:00 Samuli Suominen :
>> We restore the /dev/root symlink in Gentoo same way Debian is restoring
>> it on non-systemd
> This has been removed from Debian's udev package a while ago
>
>
> http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commit;h=c4671ce8317acb765279d0c25011d75d94b7b8ef

Too bad Grub 1's grub-install script uses /dev/root by default and not
everyone has migrated to Grub 2,
also Quota's quotacheck command uses /dev/root on XFS file systems, also
'nilfs-utils' uses /dev/root,
also e2fsprogs e4defrag still uses /dev/root

If even e2fsprogs and quota would be fixed from those, I'd be
considering dropping it too
But, they are broken in every distribution

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] using /dev/root in fstab

2014-07-07 Thread Samuli Suominen 

On 07/07/14 07:29, microcai wrote:
>  a long ago, /dev/root is an symblic to real root device. no matter it is on 
> NFS or HDD, we can use  
>
> /dev/root / auto defaults 0 0 
>
> in fstab to mount / as readwrite.
>
> recently, I recall this old feature, and tryed to use it, but the system 
> failed to boot, waiting for /dev/root that never come up.
>
> how to bring back the good old feature that re-use the root device assigned 
> on 
> kernel command line ?
>

(This is ugly, I know.)

We restore the /dev/root symlink in Gentoo same way Debian is restoring
it on non-systemd
systems that still use sysvinit using a "workaround" like,

#!/bin/sh -e
#
# dev-root-link.sh: create /dev/root symlink
#
# Distributed under the terms of the GNU General Public License v2
#
# This is here because some software expects /dev/root to exist.
# For more information, see this bug:
# https://bugs.gentoo.org/show_bug.cgi?id=438380

RULESDIR=/run/udev/rules.d

[ -d $RULESDIR ] || mkdir -p $RULESDIR

eval $(udevadm info --export --export-prefix=ROOT_ --device-id-of-file=/
|| true)

[ "$ROOT_MAJOR" -a "$ROOT_MINOR" ] || exit 0

# btrfs filesystems have bogus major/minor numbers
[ "$ROOT_MAJOR" != 0 ] || exit 0

echo 'ACTION=="add|change", SUBSYSTEM=="block",
ENV{MAJOR}=="'$ROOT_MAJOR'", ENV{MINOR}=="'$ROOT_MINOR'",
SYMLINK+="root"' > $RULESDIR/61-dev-root-link.rules

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] Use dev_port for the ID of a network device.

2014-07-01 Thread Samuli Suominen 

On 01/07/14 16:20, Kay Sievers wrote:
> On Tue, Jul 1, 2014 at 3:11 PM, Thadeu Lima de Souza Cascardo
>  wrote:
>> For network devices on the same PCI function, dev_id should not be used,
>> since its purpose is for IPv6 support on interfaces with the same MAC
>> address.
>>
>> The new dev_port sysfs attribute should be used instead of dev_id.
> Applied.
>

I'm not complaining, merely verifying, does this mean that udev that
will be shipped
with systemd-215 will require at least Linux 3.15?

Thanks,
Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/3] build-sys: do not require intltool when building from archive

2014-06-24 Thread Samuli Suominen 
On 25/06/14 09:06, Filipe Brandenburger wrote:
> Hi Zbigniew,
>
> This set of patches does explicit handling of --disable-nls and some extra
> detection of intltool in order to make configure not fail when intltool is not
> present.

For reference, we are using this workaround to disable intltool when
it's not installed
in the Gentoo build script for a minimal build of selected components.
I'm only mentioning it here in case some other packagers need a workaround.

Executed right before starting ./configure:

sed -i -e '/INTLTOOL_APPLIED_VERSION=/s:=.*:=0.40.0:' configure
sed -i -e '/XML::Parser perl module is required for intltool/s|^|:|'
configure
eval export INTLTOOL_{EXTRACT,MERGE,UPDATE}=/bin/true
eval export {MSG{FMT,MERGE},XGETTEXT}=/bin/true

That's all.

Thanks,
Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev-212 and up on Sparc v8

2014-06-23 Thread Samuli Suominen 

On 23/06/14 15:30, Lennart Poettering wrote:
> On Sat, 21.06.14 09:05, Chase Rayfield (cusbr...@yahoo.com) wrote:
>
>>> If I interpret that correctly, systemd would need to define
>>> _sync_sub_and_fetch_4 when building for 32-bit processors which do not
>>> support the __sync_sub_and_fetch operation natively.
>> Yes exactly... I think libatomic_ops can help with that and I have
>> built it from git on Sparc v8 (This flag is required 
>> -DAO_NO_SPARC_V9). But I am not sure how to implement
>> __sync_sub_and_fetch with it. Details on getting it to build here:
>> https://github.com/ivmai/libatomic_ops/issues/9
>>
>> I can give a systemd developer access to a box to fix this on if someone 
>> wants to give it a shot. I believe the reason GCC doesn't provide an 
>> implementation there are some pretty huge trade offs to be made with 
>> either performance or functionality.
> Thanks, but please work with the gcc developers to solve this
> generically for all gcc users, instead of work around this limitation in
> every individual project independently. It's certainly time much better
> spent.
>
> Thanks,
>
> Lennart
>

IIRC, he told me when we discussed at IRC that systemd-udevd was the
showstopper, and rest of the 'core' system
built fine.
Mike seems to also think this should be solved in systemd,
http://bugs.gentoo.org/show_bug.cgi?id=514016#c9

But, too bad this goes beyond my knowledge a bit :-/

:/

Thanks,
Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev-212 and up on Sparc v8

2014-06-20 Thread Samuli Suominen 

On 21/06/14 08:38, Chase Rayfield wrote:
> udev up to version 208 builds correctly on Sparc v8. However 212 and
> greater does not.
>
> Complete build logs of 208 and 214 can be found here:
> https://bugs.gentoo.org/show_bug.cgi?id=514016
>
> Any suggestions or alternatives to how we can fix this would be
> appreciated.
>
> This affects old Sun hardware, Leon Sparc, and the sparc
> implementation being developed at temlib.org  it may also affect
> other architectures that I am not aware of.
>
> Thanks,
> Chase Rayfield
>
>

When I suggested you report this to the mailing list, I expected you to
extract
systemd tarball, run export CFLAGS="-mcpu=v8", ./configure and make
And post the output from that here
I also didn't expect the bug to be referenced, but instead the relavent
information
posted here, so non-Gentoo people don't have to parse the
Gentoo-specific bug

Sorry, I should have been more clear about it

Thanks,
Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options

2014-06-02 Thread Samuli Suominen 

On 03/06/14 01:48, Tom Gundersen wrote:
> On Sun, Jun 1, 2014 at 2:58 PM, Michael Biebl  wrote:
>> I quickly looked at the patch and it seems ok.
>> While glancing over Makefile.am I noticed that e.g. libsystemd_network
>> links against $(KMOD_LIBS).
>> That looks wrong to me (faulty commit is
>> 679be2a74241a70028438217bace423a1a45faa6), only
>> libsystemd-networkd-core really requires kmod
> Rather than try to sort this all out, I have now removed all the kmod
> code from networkd as we anyway do not want this long-term, the
> options requiring it are experimental (i.e., not documented) and the
> kernel fix making this all redundant is scheduled for the stable
> kernels.
>
> Please yell if there are still issues.
>
> Cheers,
>
> Tom

Lines 877-878 in configure.ac:

|AS_IF([test "x$have_networkd" = "xyes" -a "x$have_kmod" != "xyes"],
  [AC_MSG_ERROR([networkd requires kmod])])

Did you forget them?
|


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options

2014-06-01 Thread Samuli Suominen 

On 01/06/14 10:04, Tom Gundersen wrote:
>
>
> On 1 Jun 2014 06:31, "Lennart Poettering"  <mailto:lenn...@poettering.net>> wrote:
> >
> > On Sat, 31.05.14 19:43, Samuli Suominen (ssuomi...@gentoo.org
> <mailto:ssuomi...@gentoo.org>) wrote:
> >
> > >
> > >
> > > On 31/05/14 17:10, Samuli Suominen wrote:
> > > > On 31/05/14 14:14, Samuli Suominen wrote:
> > > >> 1. "libsystemd_network_la_SOURCES =" in Makefile.am includes
> > > >> "src/libsystemd-network/network-internal.h"
> > > >> and there is no anykind of #ifdef -logic behind it
> > > >>
> > > >> 2. "src/libsystemd-network/network-internal.h" has #include
> 
> > > >> and there is no anykind of #ifdef
> > > >> -logic behind it
> > > >>
> > > >> so kmod is hardcoded dependency in systemd-213:
> > > >>
> > > >>
> > > > This patch is a half-complete hack that only works with
> > > > --disable-networkd, as it only covers the files
> > > > that are outside of the #if NETWORKD in Makefile.am
> > > > As in, I've used this patch only for the package within Gentoo that
> > > > builds only udev, not rest of systemd,
> > > > that uses --disable-networkd
> > > > So consider this as proof of consept, not for inclusion
> > > >
> > > > - Samuli
> > > >
> > > >
> > > > ___
> > > > systemd-devel mailing list
> > > > systemd-devel@lists.freedesktop.org
> <mailto:systemd-devel@lists.freedesktop.org>
> > > > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> > >
> > > I just realized configure.ac <http://configure.ac> already has,
> > >
> > > AS_IF([test "x$have_networkd" = "xyes" -a "x$have_kmod" != "xyes"],
> > >   [AC_MSG_ERROR([networkd requires kmod])])
> > >
> > > So this patch should be considered for inclusion after all as-is. You
> > > should credit "Mike Gilbert  <mailto:flop...@gentoo.org>>" for
> > > the patch, not me.
> >
> > I'd prefer I we could fix this properly and allow networkd build without
> > kmod. I am very cool on linking against kmod from networkd anyway (in
> > particular since I want networkd to run without CAP_SYS_MODULE), so I
> > think this could be the least we should be doing...
>
> We should be able to drop the whole kmod thing from networkd any day
> now (a fix is in net-next). Merging it was probably a mistake in the
> first place.
>
>

So, how about applying the patch from this thread to fix the immediate
problem? (This reply isn't aimed specifically to you, but to anyone with
such
deciding/commit powers really.)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Drop the udev firmware loader

2014-05-31 Thread Samuli Suominen 

On 01/06/14 08:45, Lennart Poettering wrote:
> On Fri, 30.05.14 04:32, Michael Biebl (mbi...@gmail.com) wrote:
>
>> 2014-05-30 4:26 GMT+02:00 Greg KH :
>>
>>> You update systemd but you don't update the kernel?  How does that make
>>> any sense?
>> There might be very valid reasons why you need to stick with the old
>> kernel. As said, one example could be that the new one simply doesn't
>> boot. Requiring lock-step upgrades makes the system less
>> fault-tolerant.
>> So where possible this should be avoided.
> To make this clear, we expect that systemd and kernels are updated in
> lockstep. We explicitly do not support really old kernels with really
> new systemd. So far we had the focus to support up to 2y old kernels
> (which means 3.4 right now), but even that should be taken with a grain
> of salt, as we already made clear that soon after kdbus is merged into
> the kernel we'll probably make a hard requirement on it from the systemd
> side. 
>
> I am tempted to say that we should merge the firmware loader removal
> patch at the same time as the kdbus requirement is made. As that would
> be a clean cut anyway...
>
> Also note that at that point we intend to move udev onto kdbus as
> transport, and get rid of the userspace-to-userspace netlink-based
> tranport udev used so far. Unless the systemd-haters prepare another
> kdbus userspace until then this will effectively also mean that we will
> not support non-systemd systems with udev anymore starting at that
> point. Gentoo folks, this is your wakeup call.
>
>

I've already set minimum kernel required to 2.6.39 in >= 213, and I'd be
fine
setting it even higher. Talking only of the udev bit here.
I don't like dropping support for old versions, but if that's what
has to be done, I'll go with that.
Please, don't use this as an excuse to drop support for MinimalBuilds as
described
in wiki in some manner.
As in, if it's still possible to use some kernel, like kernel with
kdbus, and even
if it requires an userspace library like 'libsystemd-something' to go
with it, and still
get a udev one way or another, that can run standalone, we are all good.

I'd really hate to be forced to fork (or carry huge patchset) unnecessarily
(I'm not a systemd hater, I'm not a eudev lover, I'm simply working on what
is provided to me by *you*, udev upstream)

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options

2014-05-31 Thread Samuli Suominen 

On 31/05/14 20:45, Cristian Rodríguez wrote:
> El 31/05/14 13:00, Samuli Suominen escribió:
>> A proper git formatted patch for inclusion.
> IN my opinion, we should just make KMOD a mandatory dependency, drop all
> ifdefs, error out if not found.
>
>
>

I don't see why, people use CONFIG_MODULES=n kernels, but if whatever,
if that's what is decided, I'll go with that...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options

2014-05-31 Thread Samuli Suominen 
A proper git formatted patch for inclusion.

>From 9be13cce871d1d7275acee8bcb106cd2f9e909b7 Mon Sep 17 00:00:00 2001
From: Mike Gilbert 
Date: Sat, 31 May 2014 19:58:47 +0300
Subject: [PATCH] Fix building with --disable-kmod --disable-networkd when kmod
 is not installed.

---
 src/libsystemd-network/network-internal.c | 2 ++
 src/libsystemd-network/network-internal.h | 4 
 2 files changed, 6 insertions(+)

diff --git a/src/libsystemd-network/network-internal.c b/src/libsystemd-network/network-internal.c
index 261603f..31d7bc2 100644
--- a/src/libsystemd-network/network-internal.c
+++ b/src/libsystemd-network/network-internal.c
@@ -327,6 +327,7 @@ int net_parse_inaddr(const char *address, unsigned char *family, void *dst) {
 return 0;
 }
 
+#if HAVE_KMOD
 int load_module(struct kmod_ctx *ctx, const char *mod_name) {
 struct kmod_list *modlist = NULL, *l;
 int r;
@@ -361,6 +362,7 @@ int load_module(struct kmod_ctx *ctx, const char *mod_name) {
 
 return r;
 }
+#endif
 
 void serialize_in_addrs(FILE *f, const char *key, struct in_addr *addresses, size_t size) {
 unsigned i;
diff --git a/src/libsystemd-network/network-internal.h b/src/libsystemd-network/network-internal.h
index c08cddd..3e4018e 100644
--- a/src/libsystemd-network/network-internal.h
+++ b/src/libsystemd-network/network-internal.h
@@ -24,7 +24,9 @@
 #include 
 #include 
 #include 
+#if HAVE_KMOD
 #include 
+#endif
 
 #include "udev.h"
 #include "condition-util.h"
@@ -67,7 +69,9 @@ int net_parse_inaddr(const char *address, unsigned char *family, void *dst);
 
 int net_get_unique_predictable_data(struct udev_device *device, uint8_t result[8]);
 
+#if HAVE_KMOD
 int load_module(struct kmod_ctx *ctx, const char *mod_name);
+#endif
 
 void serialize_in_addrs(FILE *f, const char *key, struct in_addr *addresses, size_t size);
 int deserialize_in_addrs(struct in_addr **addresses, size_t *size, const char *string);
-- 
1.9.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options

2014-05-31 Thread Samuli Suominen 

On 31/05/14 17:10, Samuli Suominen wrote:
> On 31/05/14 14:14, Samuli Suominen wrote:
>> 1. "libsystemd_network_la_SOURCES =" in Makefile.am includes
>> "src/libsystemd-network/network-internal.h"
>> and there is no anykind of #ifdef -logic behind it
>>
>> 2. "src/libsystemd-network/network-internal.h" has #include 
>> and there is no anykind of #ifdef
>> -logic behind it
>>
>> so kmod is hardcoded dependency in systemd-213:
>>
>>
> This patch is a half-complete hack that only works with
> --disable-networkd, as it only covers the files
> that are outside of the #if NETWORKD in Makefile.am
> As in, I've used this patch only for the package within Gentoo that
> builds only udev, not rest of systemd,
> that uses --disable-networkd
> So consider this as proof of consept, not for inclusion
>
> - Samuli
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

I just realized configure.ac already has,

AS_IF([test "x$have_networkd" = "xyes" -a "x$have_kmod" != "xyes"],
  [AC_MSG_ERROR([networkd requires kmod])])

So this patch should be considered for inclusion after all as-is. You
should credit "Mike Gilbert " for
the patch, not me.

Thanks,
Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options

2014-05-31 Thread Samuli Suominen 

On 31/05/14 14:14, Samuli Suominen wrote:
> 1. "libsystemd_network_la_SOURCES =" in Makefile.am includes
> "src/libsystemd-network/network-internal.h"
> and there is no anykind of #ifdef -logic behind it
>
> 2. "src/libsystemd-network/network-internal.h" has #include 
> and there is no anykind of #ifdef
> -logic behind it
>
> so kmod is hardcoded dependency in systemd-213:
>
>

This patch is a half-complete hack that only works with
--disable-networkd, as it only covers the files
that are outside of the #if NETWORKD in Makefile.am
As in, I've used this patch only for the package within Gentoo that
builds only udev, not rest of systemd,
that uses --disable-networkd
So consider this as proof of consept, not for inclusion

- Samuli
This only works with --disable-networkd as it doesn't cover all of the files. As in, this is Gentoo specific
hack for >=sys-fs/udev-213 only.

http://lists.freedesktop.org/archives/systemd-devel/2014-May/019634.html
http://bugs.gentoo.org/511924

--- src/libsystemd-network/network-internal.c
+++ src/libsystemd-network/network-internal.c
@@ -327,6 +327,7 @@ int net_parse_inaddr(const char *address, unsigned char *family, void *dst) {
 return 0;
 }
 
+#if HAVE_KMOD
 int load_module(struct kmod_ctx *ctx, const char *mod_name) {
 struct kmod_list *modlist = NULL, *l;
 int r;
@@ -361,6 +362,7 @@ int load_module(struct kmod_ctx *ctx, const char *mod_name) {
 
 return r;
 }
+#endif
 
 void serialize_in_addrs(FILE *f, const char *key, struct in_addr *addresses, size_t size) {
 unsigned i;
--- src/libsystemd-network/network-internal.h
+++ src/libsystemd-network/network-internal.h
@@ -24,7 +24,9 @@
 #include 
 #include 
 #include 
+#if HAVE_KMOD
 #include 
+#endif
 
 #include "udev.h"
 #include "condition-util.h"
@@ -67,7 +69,9 @@ int net_parse_inaddr(const char *address, unsigned char *family, void *dst);
 
 int net_get_unique_predictable_data(struct udev_device *device, uint8_t result[8]);
 
+#if HAVE_KMOD
 int load_module(struct kmod_ctx *ctx, const char *mod_name);
+#endif
 
 void serialize_in_addrs(FILE *f, const char *key, struct in_addr *addresses, size_t size);
 int deserialize_in_addrs(struct in_addr **addresses, size_t *size, const char *string);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options

2014-05-31 Thread Samuli Suominen 
1. "libsystemd_network_la_SOURCES =" in Makefile.am includes
"src/libsystemd-network/network-internal.h"
and there is no anykind of #ifdef -logic behind it

2. "src/libsystemd-network/network-internal.h" has #include 
and there is no anykind of #ifdef
-logic behind it

so kmod is hardcoded dependency in systemd-213:



/bin/sh ./libtool  --tag=CC   --mode=compile x86_64-pc-linux-gnu-gcc -std=gnu99 
-DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-fs/udev-213/work/systemd-213  
-include ./config.h -DPKGSYSCONFDIR=\"/etc/systemd\" -DSYSTEM_CONFIG_UNIT_P
ATH=\"/etc/systemd/system\" -DSYSTEM_DATA_UNIT_PATH=\"/lib/systemd/system\" 
-DSYSTEM_SYSVINIT_PATH=\"/etc/init.d\" -DSYSTEM_SYSVRCND_PATH=\"/etc/rc.d\" 
-DUSER_CONFIG_UNIT_PATH=\"/etc/systemd/user\" -DUSER_DATA_UNIT_PATH=\"/usr/l
ib/systemd/user\" -DCATALOG_DATABASE=\"/var/lib/lib/systemd/catalog/database\" 
-DSYSTEMD_CGROUP_AGENT_PATH=\"/lib/systemd/systemd-cgroups-agent\" 
-DSYSTEMD_BINARY_PATH=\"/lib/systemd/systemd\" 
-DSYSTEMD_SHUTDOWN_BINARY_PATH=\"/l
ib/systemd/systemd-shutdown\" 
-DSYSTEMD_SLEEP_BINARY_PATH=\"/lib/systemd/systemd-sleep\" 
-DSYSTEMCTL_BINARY_PATH=\"/bin/systemctl\" 
-DSYSTEMD_TTY_ASK_PASSWORD_AGENT_BINARY_PATH=\"/bin/systemd-tty-ask-password-agent\"
 -DSYSTEMD_S
TDIO_BRIDGE_BINARY_PATH=\"/usr/bin/systemd-stdio-bridge\" -DROOTPREFIX=\"\" 
-DRANDOM_SEED_DIR=\"/var/lib/lib/systemd/\" 
-DRANDOM_SEED=\"/var/lib/lib/systemd/random-seed\" 
-DSYSTEMD_CRYPTSETUP_PATH=\"/lib/systemd/systemd-cryptset
up\" -DSYSTEM_GENERATOR_PATH=\"/lib/systemd/system-generators\" 
-DUSER_GENERATOR_PATH=\"/usr/lib/systemd/user-generators\" 
-DSYSTEM_SHUTDOWN_PATH=\"/lib/systemd/system-shutdown\" 
-DSYSTEM_SLEEP_PATH=\"/lib/systemd/system-sleep\"
 -DSYSTEMD_KBD_MODEL_MAP=\"/usr/share/systemd/kbd-model-map\" 
-DX_SERVER=\"/usr/bin/X\" -DUDEVLIBEXECDIR=\"/lib/udev\" 
-DPOLKIT_AGENT_BINARY_PATH=\"/usr/bin/pkttyagent\" 
-DQUOTACHECK=\"/usr/sbin/quotacheck\" -DKEXEC=\"/usr/sbin/
kexec\" -I /var/tmp/portage/sys-fs/udev-213/work/systemd-213/src -I 
./src/shared -I /var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/shared -I 
/var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/network -I /var/tmp/portag
e/sys-fs/udev-213/work/systemd-213/src/login -I 
/var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/journal -I 
/var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/timedate -I 
/var/tmp/portage/sys-fs/udev-213/work/systemd-213
/src/timesync -I /var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/resolve 
-I /var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/systemd -I ./src/core 
-I /var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/core -I /var/
tmp/portage/sys-fs/udev-213/work/systemd-213/src/libudev -I 
/var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/udev -I 
/var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/udev/net -I ./src/udev -I 
/var/tmp/portage/sys-fs/ud
ev-213/work/systemd-213/src/libsystemd/sd-bus -I 
/var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/libsystemd/sd-event -I 
/var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/libsystemd/sd-rtnl -I 
/var/tmp/portage/sys-fs/ud
ev-213/work/systemd-213/src/libsystemd-network  
-DFIRMWARE_PATH="\"/lib/firmware/updates/\", \"/lib/firmware/\""  -pipe -Wall 
-Wextra -Wno-inline -Wundef -Wformat=2 -Wformat-security -Wformat-nonliteral 
-Wlogical-op -Wsign-compa
re -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self 
-Wdeclaration-after-statement -Wfloat-equal -Wsuggest-attribute=noreturn 
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarati
ons -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 
-Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter 
-Wno-missing-field-initializers -Wno-unused-result -Werror=overflow 
-Wnested-externs
 -ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing 
-fvisibility=hidden -ffunction-sections -fdata-sections -fstack-protector -fPIE 
--param=ssp-buffer-size=4   -I/usr/include/blkid -I/usr/include/uuid   -marc
h=native -O2 -mtune=native -pipe -c -o 
src/udev/libudev_core_la-udev-builtin-firmware.lo `test -f 
'src/udev/udev-builtin-firmware.c' || echo 
'/var/tmp/portage/sys-fs/udev-213/work/systemd-213/'`src/udev/udev-builtin-firmware.c
In file included from 
/var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/udev/net/link-config.c:41:0:
/var/tmp/portage/sys-fs/udev-213/work/systemd-213/src/libsystemd-network/network-internal.h:27:21:
 fatal error: libkmod.h: No such file or directory
 #include 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Drop the udev firmware loader

2014-05-30 Thread Samuli Suominen 

On 30/05/14 17:13, Greg KH wrote:
> On Fri, May 30, 2014 at 12:50:50PM +0300, Samuli Suominen wrote:
>> On 30/05/14 09:17, Cristian Rodríguez wrote:
>>> El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió:
>>>> On 30/05/14 04:55, Greg KH wrote:
>>>>> On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew
>>>>> Jędrzejewski-Szmek wrote:
>>>>>> On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote:
>>>>>>> As discussed ad-nauseum previously, it is the kernel's task
>>>>>>> to load firmware, not udev's.
>>>>>> I think this patch is a bad idea - it makes things harder for people
>>>>>> who, for whatever reason, good or bad, run older kernels. At the same
>>>>>> time, our maintenance burden is pretty much zero.
>>>>> What kernel version are you thinking still needs this, that would ever
>>>>> want to have a new version of systemd on it?
>>>> We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch
>>>> would be very harmful
>>>> to us (Gentoo)
>>> Really ? the minimum requirements are:
>>>
>>> REQUIREMENTS:
>>>Linux kernel >= 3.0
>>>Linux kernel >= 3.3 for loop device partition support features
>>> with nspawn
>>>Linux kernel >= 3.8 for Smack support
>>>
>>> Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ...
>>>
>>>
>> You are right, this fhandle business is new, but we have 208 for kernels
>> with no CONFIG_FHANDLE, and 212/213 for ones without,
>> I have plans on keeping 208 for a long time in tree (it's on my TODO
>> list to apply the patch that adds CONFIG_FHANDLE to our
>> special kernel sources, but it's not done yet)
>> We have embedded uses for eg. Genesis Efika MX (arm neon processor) with
>> special kernel patches 2.6.32.* series, just to name
>> one I personally use, and I know we have more of these uses, all ARM related
> Then stick with those old systemd/udev versions for those kernels,
> nothings wrong with that.

Yes there is, it means an extra step for the users to mask newer versions,
and burden for maintainers to backtrack patches for bugfixes for old version

>
>> But seriously, if at all possible, please keep the firmware thing for
>> like this year in the code, it would be greately appericiated
> Why would 6 months make any difference for removing it then vs. now?

Because new kernel patchsets are being written, some are semi-ready in
various
version controls, some are not, giving time for upstreams to migrate is
usually
good idea, expecting everyone is ready when you say "jump" is not realistic

If it's really not a big problem to maintain the firmware loader for
some time
longer, please just do that :/

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Drop the udev firmware loader

2014-05-30 Thread Samuli Suominen 

On 30/05/14 09:17, Cristian Rodríguez wrote:
> El vie 30 may 2014 01:41:37 CLT, Samuli Suominen escribió:
>>
>> On 30/05/14 04:55, Greg KH wrote:
>>> On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew
>>> Jędrzejewski-Szmek wrote:
>>>> On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote:
>>>>> As discussed ad-nauseum previously, it is the kernel's task
>>>>> to load firmware, not udev's.
>>>> I think this patch is a bad idea - it makes things harder for people
>>>> who, for whatever reason, good or bad, run older kernels. At the same
>>>> time, our maintenance burden is pretty much zero.
>>> What kernel version are you thinking still needs this, that would ever
>>> want to have a new version of systemd on it?
>>
>> We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch
>> would be very harmful
>> to us (Gentoo)
>
> Really ? the minimum requirements are:
>
> REQUIREMENTS:
>Linux kernel >= 3.0
>Linux kernel >= 3.3 for loop device partition support features
> with nspawn
>Linux kernel >= 3.8 for Smack support
>
> Also. libudev now uses name_to_handle_at() which appeared in 2.6.39 ...
>
>

You are right, this fhandle business is new, but we have 208 for kernels
with no CONFIG_FHANDLE, and 212/213 for ones without,
I have plans on keeping 208 for a long time in tree (it's on my TODO
list to apply the patch that adds CONFIG_FHANDLE to our
special kernel sources, but it's not done yet)
We have embedded uses for eg. Genesis Efika MX (arm neon processor) with
special kernel patches 2.6.32.* series, just to name
one I personally use, and I know we have more of these uses, all ARM related

But seriously, if at all possible, please keep the firmware thing for
like this year in the code, it would be greately appericiated

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Drop the udev firmware loader

2014-05-29 Thread Samuli Suominen 

On 30/05/14 04:55, Greg KH wrote:
> On Fri, May 30, 2014 at 03:40:52AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
>> On Thu, May 29, 2014 at 08:54:22PM -0400, Cristian Rodríguez wrote:
>>> As discussed ad-nauseum previously, it is the kernel's task
>>> to load firmware, not udev's.
>> I think this patch is a bad idea - it makes things harder for people
>> who, for whatever reason, good or bad, run older kernels. At the same
>> time, our maintenance burden is pretty much zero.
> What kernel version are you thinking still needs this, that would ever
> want to have a new version of systemd on it?

We use systemd's udevd on old as Linux 2.6.32.61 succesfully, this patch
would be very harmful
to us (Gentoo)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev too late renaming network interfaces

2014-05-13 Thread Samuli Suominen 

On 13/05/14 16:43, Grant wrote:
>>> I'm on Gentoo and when the system tries to start my network interfaces
>>> at boot, I get:
>>>
>>> Cannot find device "enp0s20u2u1"
>>>  *   ERROR: interface enp0s20u2u1 does not exist
>>>  *   Ensure that you have loaded the correct kernel module for your hardware
>>>  * ERROR: net.enp0s20u2u1 failed to start
>>>  * Bringing up interface enp0s20u2u2
>>> Cannot find device "enp0s20u2u2"
>>>  *   ERROR: interface enp0s20u2u2 does not exist
>>>  *   Ensure that you have loaded the correct kernel module for your hardware
>>>  * ERROR: net.enp0s20u2u2 failed to start
>>>
>>> It seems udev is taking too long to rename my USB ethernet interfaces
>>> from eth0 and eth1 to the above names.  Once the system is booted, I
>>> can start the interfaces just fine.  I do like the renaming
>>> functionality so I can plug any USB ethernet adapter into a particular
>>> USB port and it will work without changes so I'd rather not disable
>>> that.  Everything is built into the kernel, I'm not loading any
>>> modules.  I have 5 Dell XPS 13 systems and only one is exhibiting this
>>> problem.
>> Is your network configuration system waiting at all for network devices
>> to show up? If not, it's not really compatible who modern network
>> devices work, in particularly USB devices.
>>
>> It needs to wait with libudev until the network devices it is interested
>> in have been reported initialized by udev.
>
> Thank you Tom and Lennart.  I'm not sure what to call my network
> configuration system.  It's default Gentoo stuff, just initscrips in
> runlevels.  To confirm, I should file a Gentoo bug?
>
>

Are you using dhcpcd with this device? It's USE="udev" in Gentoo that
makes net-misc/dhcpcd link against libudev
for initialization to make sure it's ready.

And this networking system is called net-misc/netifrc:

https://git.overlays.gentoo.org/gitweb/?p=proj/netifrc.git;a=summary

It's not programmed in C, so it's not using libudev, however, there is
/etc/init.d/net.lo that is part of the net-misc/netifrc
package, and net.lo has sys-apps/openrc specific depend() { } section,
so it's very much possible that net.lo init
script should have dependency on /etc/init.d/udev init script to ensure
it's initialized early enough
I suppose this could be the problem if you are not using dhcpcd, or it's
built wrongly, without USE="udev"

So yeah, file a Gentoo bug and provide necessary information there, if
this didn't help you

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Samuli Suominen 

On 08/04/14 19:16, Cristian Rodríguez wrote:
> El 08/04/14 03:04, Samuli Suominen escribió:
>
>> This is the *only* patch we are carrying for udev currently, otherwise
>> uClibc builds work fine, so please at least consider what
>> I just said.
>
> All this "locale_t" thing is standarized in POSIX 2008, . it is up to
> the particular libc to keep up with standards.
>
> systemd requires glibc, this is known and clear since the beginning.

systemd-udevd doesn't, albeit their is secure_getenv but it's currently
used only for logging, and note that there is still sysv support in the
source tree
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Samuli Suominen 

On 08/04/14 15:25, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Apr 08, 2014 at 09:04:37AM +0300, Samuli Suominen wrote:
>> File src/shared/util.h is using locale_t which isn't used by the
>> strictly udev parts of the systemd code, I propose to move
>> this to a different header, so it is only used where it's actually required.
> I see the usefulness of disabling localization for lots of people,
> e.g. embedded. So what about simply adding a --disable-locale switch,
> and then having a patch like what you attached with a conditional
> using that, and in addition disabling the installation of .po files?
>
> Zbyszek

I've seen this proposal shot down earlier in the bugzilla.fd.o, which is why
I suggested merely keeping the existing code and moving it to a more
specific header.

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-08 Thread Samuli Suominen 

On 08/04/14 18:52, Lennart Poettering wrote:
> On Tue, 08.04.14 09:04, Samuli Suominen (ssuomi...@gentoo.org) wrote:
>
> I am sorry, but we are not interested in carrying compat code for exotic
> libc's. We have made this clear in the past. The onus is on those libc's
> to be compatible with glibc and POSIX and all these things, and systemd
> is not the place to deal with the complexity if they don't implement the
> same API.
>
> Please work with the uclibc people to add the missing APIs so that they
> stay compatible with glibc.
>
>

Please, read again what I suggested. I didn't suggest for the patch that
I attached to be merged.
I was merely suggesting moving the use of locale_t into it's own header.
As in, moving existing code to a different file and being more specific
where it's used in Makefile.am

The code would be same, just new file introduced, no hacks/compat code
to carry around

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-07 Thread Samuli Suominen 
I can work on a patch that creates the new header, if this is something
you'd be willing to consider.

On 08/04/14 09:04, Samuli Suominen wrote:
> First, some history, we have within Gentoo been pushing changes to
> uClibc head for functions that are used
> by the udev code of systemd, that were prior to that, only in glibc.
> I assume this is the way you want to see things integrated, to not carry
> uClibc specific hacks in systemd's code.
>
> However, sometime after 204, unconditional use of locale_t was applied
> to src/shared/util.h, and that same header
> is used also in udev parts of the systemd build, and that is something
> we can't change in uClibc to keep on supporting
> NLS-less builds of it.
>
> File src/shared/util.h is using locale_t which isn't used by the
> strictly udev parts of the systemd code, I propose to move
> this to a different header, so it is only used where it's actually required.
>
> I'm attaching the patch we are currently using to workaround the
> problem, not because it should be applied in systemd's code,
> but only to demonstrate the part of the header that should get it's own
> header, only to demonstrate the problem we
> are having.
>
> This is the *only* patch we are carrying for udev currently, otherwise
> uClibc builds work fine, so please at least consider what
> I just said.
>
> - Samuli
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Move use of locale_t to different shared file, so that udev can still be built without it (MinimalBuild)

2014-04-07 Thread Samuli Suominen 
First, some history, we have within Gentoo been pushing changes to
uClibc head for functions that are used
by the udev code of systemd, that were prior to that, only in glibc.
I assume this is the way you want to see things integrated, to not carry
uClibc specific hacks in systemd's code.

However, sometime after 204, unconditional use of locale_t was applied
to src/shared/util.h, and that same header
is used also in udev parts of the systemd build, and that is something
we can't change in uClibc to keep on supporting
NLS-less builds of it.

File src/shared/util.h is using locale_t which isn't used by the
strictly udev parts of the systemd code, I propose to move
this to a different header, so it is only used where it's actually required.

I'm attaching the patch we are currently using to workaround the
problem, not because it should be applied in systemd's code,
but only to demonstrate the part of the header that should get it's own
header, only to demonstrate the problem we
are having.

This is the *only* patch we are carrying for udev currently, otherwise
uClibc builds work fine, so please at least consider what
I just said.

- Samuli

Fix building with uClibc, since if NLS is disabled, locale_t is missing, and if it's enabled,
we still can't be sure the glibc way of using locale_t works for uClibc

Thanks to Mike Frysinger for the patch

--- src/shared/util.h
+++ src/shared/util.h
@@ -849,6 +849,7 @@
 _r_;\
 })
 
+#ifndef __UCLIBC__
 struct _locale_struct_ {
 locale_t saved_locale;
 locale_t new_locale;
@@ -874,6 +875,9 @@
  }  \
  !_saved_locale_.quit; }) ; \
  _saved_locale_.quit = true)
+#else
+#define RUN_WITH_LOCALE(mask, loc)
+#endif
 
 bool id128_is_valid(const char *s) _pure_;
 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Masking .network files

2014-04-05 Thread Samuli Suominen 
On 05/04/14 12:26, Tom Gundersen wrote:
> matching file will be applied. The 'masking' logic that you know from
> unit files does not really make much sense for .network files (but
> maybe this is something we should change...). Symlinks to /dev/null
> are just treated as empty .network files, so their meaning is "no
> [Match] section", which matches everything and "no [Network] section",
> which does nothing. I suppose this may be used to express "ignore any
> subsequent .network files", but I doubt that is a particularly useful
> thing to do.

I know you are talking about .network files, but can I get verify on...

You can still override /lib/systemd/network/99-default.link by
symlinking /etc/systemd/network/99-default.link to /dev/null, right?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] git requires now linux api userspace headers >= 3.13 to build?

2014-03-31 Thread Samuli Suominen 
User reported me today, http://bpaste.net/show/195803/

IFLA_VLAN_PROTOCOL is not defined before 3.12, but even with 3.12 there are 
different errors, so at least >= 3.13 is now required


/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:66:10:
 error: 'IFLA_VLAN_PROTOCOL' undeclared here (not in a function)
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:66:9:
 error: array index in initializer not of integer type
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:66:9:
 error: (near initialization for 'rtnl_link_info_data_vlan_types')
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:69:52:
 error: 'IFLA_BOND_MAX' undeclared here (not in a function)
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:10:
 error: 'IFLA_BOND_MODE' undeclared here (not in a function)
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9:
 error: array index in initializer not of integer type
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9:
 error: (near initialization for 'rtnl_link_info_data_bond_types')
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9:
 error: field name not in record or union initializer
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9:
 error: (near initialization for 'rtnl_link_info_data_bond_types')
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:10:
 error: 'IFLA_BOND_ACTIVE_SLAVE' undeclared here (not in a function)
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9:
 error: array index in initializer not of integer type
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9:
 error: (near initialization for 'rtnl_link_info_data_bond_types')
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9:
 error: field name not in record or union initializer
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9:
 error: (near initialization for 'rtnl_link_info_data_bond_types')
/var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:69:21:
 warning: 'rtnl_link_info_data_bond_types' defined but not used 
[-Wunused-variable]
make[2]: *** [src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo] 
Error 1


I remember reading a while back here >= 3.7 being required and that being 
reworked to not require so new, but looks like something backfired there...

- Samuli

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] Add -lresolv to libsystemd_intenal_la_LIBADD to prevent underlinking issues

2014-03-25 Thread Samuli Suominen 

On 26/03/14 03:38, Kay Sievers wrote:
> On Mon, Mar 17, 2014 at 1:43 AM, Lennart Poettering
>  wrote:
>> On Sun, 16.03.14 19:49, Samuli Suominen (ssuomi...@gentoo.org) wrote:
>>
>>> On 16/03/14 15:52, Zbigniew Jędrzejewski-Szmek wrote:
>>>> On Sun, Mar 16, 2014 at 10:10:15AM +0200, Samuli Suominen wrote:
>>>>> Since -Wl,-fuse-ld=gold addition, this happens on IA64 arch where 
>>>>> binutils's ld gold doesn't support --gc-sections yet:
>>>> Maybe you should just use bfd linker then? Gold was only necessary for the
>>>> ifunc stuff, which is gone anyway. This might to be a better solution, 
>>>> since
>>>> otherwise everything gets an extra lib.
>>> -lresolv is used elsewhere in Makefile.am too, like in
>>> libsystemd_la_LIBADD and test_resolve_LDADD
>>>
>>> src/libsystemd/sd-resolve/sd-resolve.c: ret =
>>> res_search   at line 432
>>> src/libsystemd/sd-resolve/sd-resolve.c: ret =
>>> res_query at line 430
>>>
>>> then sd-resolve.c is in libsystemd_internal_la_SOURCES, so adding
>>> -lresolv to libsystemd_internal_la_LIBADD is not a workaround,
>>> but the correct thing to do
>> We probably should much rather create a separate internal convenience
>> lib for sd-resolve so that the -lresolv dep isn't pulled into everything
>> that uses any API of sd-id128, sd-login, sd-bus, ...
> A workaround should be in the current release.
>
> Kay

I was worried about this one. Thanks! It's really appericiated!

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] Add -lresolv to libsystemd_intenal_la_LIBADD to prevent underlinking issues

2014-03-16 Thread Samuli Suominen 

On 16/03/14 15:52, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Mar 16, 2014 at 10:10:15AM +0200, Samuli Suominen wrote:
>> Since -Wl,-fuse-ld=gold addition, this happens on IA64 arch where binutils's 
>> ld gold doesn't support --gc-sections yet:
> Maybe you should just use bfd linker then? Gold was only necessary for the
> ifunc stuff, which is gone anyway. This might to be a better solution, since
> otherwise everything gets an extra lib.

-lresolv is used elsewhere in Makefile.am too, like in
libsystemd_la_LIBADD and test_resolve_LDADD

src/libsystemd/sd-resolve/sd-resolve.c: ret =
res_search   at line 432
src/libsystemd/sd-resolve/sd-resolve.c: ret =
res_query at line 430

then sd-resolve.c is in libsystemd_internal_la_SOURCES, so adding
-lresolv to libsystemd_internal_la_LIBADD is not a workaround,
but the correct thing to do

>
> LDFLAGS=-Wl,-fuse=bfd ?

we can do that too, but the underlinking issue should still be fixed...
gold is just a more strict linker, which is good, and relying upon
--gc-sections
to 'accidentally' bring in correct libs, is bad practise

>
> Zbyszek
>
>> libtool: link: ia64-unknown-linux-gnu-gcc -shared  -fPIC -DPIC  
>> src/libudev/.libs/libudev_la-libudev.o 
>> src/libudev/.libs/libudev_la-libudev-list.o src/libudev/.libs/libudev_la-libu
>> dev-util.o src/libudev/.libs/libudev_la-libudev-device.o 
>> src/libudev/.libs/libudev_la-libudev-enumerate.o 
>> src/libudev/.libs/libudev_la-libudev-monitor.o src/libudev/.libs/libudev_l
>> a-libudev-queue.o src/libudev/.libs/libudev_la-libudev-hwdb.o  
>> -Wl,--whole-archive ./.libs/libsystemd-internal.a 
>> ./.libs/libsystemd-shared.a -Wl,--no-whole-archive  -Wl,--as-needed
>>  -lrt -ldl  -O2 -Wl,--no-undefined -Wl,--gc-sections -Wl,-z -Wl,relro -Wl,-z 
>> -Wl,now -Wl,-fuse-ld=gold 
>> -Wl,--version-script=/tmp/systemd-211/src/libudev/libudev.sym -Wl,-O1
>> -pthread -Wl,-soname -Wl,libudev.so.1 -o .libs/libudev.so.1.4.0
>> cc1: warning: ./src/core: No such file or directory [enabled by default]
>> /usr/lib/gcc/ia64-unknown-linux-gnu/4.7.3/../../../../ia64-unknown-linux-gnu/bin/ld:
>>  Warning: gc-sections option ignored
>> ./.libs/libsystemd-internal.a(libsystemd_internal_la-sd-resolve.o): In 
>> function `handle_request':
>> /tmp/systemd-211/src/libsystemd/sd-resolve/sd-resolve.c:432: undefined 
>> reference to `__res_search'
>> /tmp/systemd-211/src/libsystemd/sd-resolve/sd-resolve.c:430: undefined 
>> reference to `__res_query'
>> collect2: error: ld returned 1 exit status
>> make: *** [libudev.la] Error 1
>>
>> Patch adds -lresolv to libsystemd_internal_la_LIBADD = accordingly, so 
>> building works with or without --gc-sections working properly.
>>
>> See also, http://bugs.gentoo.org/show_bug.cgi?id=504700
>>
>>
>> From 2b9ae40d830596eda80cc5bc5252c6685cb75eaa Mon Sep 17 00:00:00 2001
>> From: Samuli Suominen 
>> Date: Sat, 15 Mar 2014 20:40:24 +0200
>> Subject: [PATCH] Link against -lresolv to prevent linker errors like:
>>  /usr/lib/gcc/ia64-unknown-linux-gnu/4.7.3/../../../../ia64-unknown-
>>  linux-gnu/bin/ld: Warning: gc-sections option ignored
>>  ./.libs/libsystemd-internal.a(libsystemd_internal_la-sd-resolve.o):
>>  In function `handle_request':
>>  /tmp/systemd-211/src/libsystemd/sd-resolve/sd-resolve.c:432: undefined
>>  reference to '__res_search'
>>  /tmp/systemd-211/src/libsystemd/sd-resolve/sd-resolve.c:430: undefined
>>  reference to '__res_query'
>>  
>>  IA64 arch with -fuse-ld=gold doesn't support --gc-sections, which
>>  revealed the underlinking. See Gentoo bug 504700.
>>
>> ---
>>  Makefile.am | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 9e01cd5..4b8a081 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -2121,7 +2121,8 @@ libsystemd_internal_la_CFLAGS = \
>>  -pthread
>>  
>>  libsystemd_internal_la_LIBADD = \
>> -$(RT_LIBS)
>> +$(RT_LIBS) \
>> +-lresolv
>>  
>>  noinst_LTLIBRARIES += \
>>  libsystemd-internal.la
>> -- 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [patch] Add -lresolv to libsystemd_intenal_la_LIBADD to prevent underlinking issues

2014-03-16 Thread Samuli Suominen 
Since -Wl,-fuse-ld=gold addition, this happens on IA64 arch where binutils's ld 
gold doesn't support --gc-sections yet:

libtool: link: ia64-unknown-linux-gnu-gcc -shared  -fPIC -DPIC  
src/libudev/.libs/libudev_la-libudev.o 
src/libudev/.libs/libudev_la-libudev-list.o src/libudev/.libs/libudev_la-libu
dev-util.o src/libudev/.libs/libudev_la-libudev-device.o 
src/libudev/.libs/libudev_la-libudev-enumerate.o 
src/libudev/.libs/libudev_la-libudev-monitor.o src/libudev/.libs/libudev_l
a-libudev-queue.o src/libudev/.libs/libudev_la-libudev-hwdb.o  
-Wl,--whole-archive ./.libs/libsystemd-internal.a ./.libs/libsystemd-shared.a 
-Wl,--no-whole-archive  -Wl,--as-needed
 -lrt -ldl  -O2 -Wl,--no-undefined -Wl,--gc-sections -Wl,-z -Wl,relro -Wl,-z 
-Wl,now -Wl,-fuse-ld=gold 
-Wl,--version-script=/tmp/systemd-211/src/libudev/libudev.sym -Wl,-O1
-pthread -Wl,-soname -Wl,libudev.so.1 -o .libs/libudev.so.1.4.0
cc1: warning: ./src/core: No such file or directory [enabled by default]
/usr/lib/gcc/ia64-unknown-linux-gnu/4.7.3/../../../../ia64-unknown-linux-gnu/bin/ld:
 Warning: gc-sections option ignored
./.libs/libsystemd-internal.a(libsystemd_internal_la-sd-resolve.o): In function 
`handle_request':
/tmp/systemd-211/src/libsystemd/sd-resolve/sd-resolve.c:432: undefined 
reference to `__res_search'
/tmp/systemd-211/src/libsystemd/sd-resolve/sd-resolve.c:430: undefined 
reference to `__res_query'
collect2: error: ld returned 1 exit status
make: *** [libudev.la] Error 1

Patch adds -lresolv to libsystemd_internal_la_LIBADD = accordingly, so building 
works with or without --gc-sections working properly.

See also, http://bugs.gentoo.org/show_bug.cgi?id=504700


>From 2b9ae40d830596eda80cc5bc5252c6685cb75eaa Mon Sep 17 00:00:00 2001
From: Samuli Suominen 
Date: Sat, 15 Mar 2014 20:40:24 +0200
Subject: [PATCH] Link against -lresolv to prevent linker errors like:
 /usr/lib/gcc/ia64-unknown-linux-gnu/4.7.3/../../../../ia64-unknown-
 linux-gnu/bin/ld: Warning: gc-sections option ignored
 ./.libs/libsystemd-internal.a(libsystemd_internal_la-sd-resolve.o):
 In function `handle_request':
 /tmp/systemd-211/src/libsystemd/sd-resolve/sd-resolve.c:432: undefined
 reference to '__res_search'
 /tmp/systemd-211/src/libsystemd/sd-resolve/sd-resolve.c:430: undefined
 reference to '__res_query'
 
 IA64 arch with -fuse-ld=gold doesn't support --gc-sections, which
 revealed the underlinking. See Gentoo bug 504700.

---
 Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 9e01cd5..4b8a081 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2121,7 +2121,8 @@ libsystemd_internal_la_CFLAGS = \
 	-pthread
 
 libsystemd_internal_la_LIBADD = \
-	$(RT_LIBS)
+	$(RT_LIBS) \
+	-lresolv
 
 noinst_LTLIBRARIES += \
 	libsystemd-internal.la
-- 
1.9.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] Fix AC_PATH_PROG usage in configure.ac for systems with (still) bin vs. sbin distiction

2014-03-10 Thread Samuli Suominen 

On 10/03/14 13:23, Michael Olbrich wrote:
> On Sun, Mar 09, 2014 at 08:49:58PM +0100, Michael Biebl wrote:
>> 2014-03-08 8:52 GMT+01:00 Samuli Suominen :
>>> If eg. setcap is in /sbin and user is building as a normal user without
>>> $PATH having /sbin, the build system
>>> will default to /usr/sbin/setcap as it's defined in AC_PATH_PROG and
>>> fail during the build with 'setcap: command not found'
>>>
>>> For example, my $PATH as normal user:
>>>
>>> $ echo $PATH
>>> /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2
>>>
>>> I see Debian and Ubuntu carries a patch that changes these hardcoded
>>> paths to what they have, but that's equally
>>> unwise.
>> We do patch those defaults so we don't have to actually build-depend
>> on all those packages.
>> Your patch doesn't really help with that.
> You don't need a patch for that. Just set the corresponding configure cache
> value:
> export ac_cv_path_QUOTAON=/sbin/quotaon
> [...]
> ./configure ...
>
>

I'm aware of the possibility for exporting ac_cv_ values (those that are
present in eg. config.log after ./configure)

But the problem for what the patch was submitted remains, when setcap
is in /sbin/setcap instead of /usr/sbin/setcap, and the build system lacks
the capability of checking sbin directories, it will set it to wrong value,
and then try to *use it* during the build:
Makefile.am:-$(SETCAP) cap_dac_override,cap_sys_ptrace=ep
$(DESTDIR)$(bindir)/systemd-detect-virt
resulting in a 'command not found' message, however because it's
prefixed with -
it's non-fatal, but that's how you miss it to begin with.

Why not search sbin directories, if the patch is this easy?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] Fix AC_PATH_PROG usage in configure.ac for systems with (still) bin vs. sbin distiction

2014-03-09 Thread Samuli Suominen 

On 09/03/14 21:49, Michael Biebl wrote:
> 2014-03-08 8:52 GMT+01:00 Samuli Suominen :
>> If eg. setcap is in /sbin and user is building as a normal user without
>> $PATH having /sbin, the build system
>> will default to /usr/sbin/setcap as it's defined in AC_PATH_PROG and
>> fail during the build with 'setcap: command not found'
>>
>> For example, my $PATH as normal user:
>>
>> $ echo $PATH
>> /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2
>>
>> I see Debian and Ubuntu carries a patch that changes these hardcoded
>> paths to what they have, but that's equally
>> unwise.
> We do patch those defaults so we don't have to actually build-depend
> on all those packages.
> Your patch doesn't really help with that.
>

That's true...

Still, the patch is the correct thing to do, otherwise building systemd
on a box without superuser's $PATH causes
misconfigures, and it'd be weird to require root privileges for an
userspace application like this,
when even kernel is recommended to be built as normal user

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Minor improvement to footnote in http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

2014-03-08 Thread Samuli Suominen 
To footnote of http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

"Because libcap doesn't have a pkg-config file yet, you can `export
ac_cv_search_cap_init=yes` and `export
ac_cv_header_sys_capability_h=yes` to skip the
matching AC_CHECK_HEADERS and AC_SEARCH_LIBS checks from configure.ac."

No worries if it doesn't get added this way, so minor thing

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] Fix AC_PATH_PROG usage in configure.ac for systems with (still) bin vs. sbin distiction

2014-03-08 Thread Samuli Suominen 
This version of the patch is likely more agreeable. No reason to add
/usr/bin:/bin again to $PATH as it should be safe to expect at least
they are there,
or otherwise the system is really *broken*. :-)


On 08/03/14 09:52, Samuli Suominen wrote:
> If eg. setcap is in /sbin and user is building as a normal user without
> $PATH having /sbin, the build system
> will default to /usr/sbin/setcap as it's defined in AC_PATH_PROG and
> fail during the build with 'setcap: command not found'
>
> For example, my $PATH as normal user:
>
> $ echo $PATH
> /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2
>
> I see Debian and Ubuntu carries a patch that changes these hardcoded
> paths to what they have, but that's equally
> unwise.
> And since sbin is by definion a superuser directory, and some
> distributions indeed still make this distiction, this
> patch is cheap to apply, no regressions to others.
>
> Ref, http://www.delorie.com/gnu/docs/autoconf/autoconf_41.html
>
> Thanks!
>
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

>From 7a0300dddefa8cfbb5ca4af20901df41ba177a82 Mon Sep 17 00:00:00 2001
From: Samuli Suominen 
Date: Sat, 8 Mar 2014 09:49:29 +0200
Subject: [PATCH] Find the tools for users with no /sbin:/usr/sbin in PATH
 since some systems still make the distiction between bin and sbin.

---
 configure.ac | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 880672d..597dc14 100644
--- a/configure.ac
+++ b/configure.ac
@@ -65,16 +65,16 @@ AC_PROG_CC_C99
 AC_PATH_PROG([M4], [m4])
 AC_PATH_PROG([XSLTPROC], [xsltproc])
 
-AC_PATH_PROG([QUOTAON], [quotaon], [/usr/sbin/quotaon])
-AC_PATH_PROG([QUOTACHECK], [quotacheck], [/usr/sbin/quotacheck])
+AC_PATH_PROG([QUOTAON], [quotaon], [/usr/sbin/quotaon], [$PATH:/usr/sbin:/sbin])
+AC_PATH_PROG([QUOTACHECK], [quotacheck], [/usr/sbin/quotacheck], [$PATH:/usr/sbin:/sbin])
 
-AC_PATH_PROG([SETCAP], [setcap], [/usr/sbin/setcap])
+AC_PATH_PROG([SETCAP], [setcap], [/usr/sbin/setcap], [$PATH:/usr/sbin:/sbin])
 
-AC_PATH_PROG([KILL], [kill], [/usr/bin/kill])
+AC_PATH_PROG([KILL], [kill], [/usr/bin/kill], [$PATH:/usr/sbin:/sbin])
 
-AC_PATH_PROG([KMOD], [kmod], [/usr/bin/kmod])
+AC_PATH_PROG([KMOD], [kmod], [/usr/bin/kmod], [$PATH:/usr/sbin:/sbin])
 
-AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec])
+AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], [$PATH:/usr/sbin:/sbin])
 
 M4_DEFINES=
 
-- 
1.9.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [patch] Fix AC_PATH_PROG usage in configure.ac for systems with (still) bin vs. sbin distiction

2014-03-07 Thread Samuli Suominen 
If eg. setcap is in /sbin and user is building as a normal user without
$PATH having /sbin, the build system
will default to /usr/sbin/setcap as it's defined in AC_PATH_PROG and
fail during the build with 'setcap: command not found'

For example, my $PATH as normal user:

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2

I see Debian and Ubuntu carries a patch that changes these hardcoded
paths to what they have, but that's equally
unwise.
And since sbin is by definion a superuser directory, and some
distributions indeed still make this distiction, this
patch is cheap to apply, no regressions to others.

Ref, http://www.delorie.com/gnu/docs/autoconf/autoconf_41.html

Thanks!


>From 7a0300dddefa8cfbb5ca4af20901df41ba177a82 Mon Sep 17 00:00:00 2001
From: Samuli Suominen 
Date: Sat, 8 Mar 2014 09:49:29 +0200
Subject: [PATCH] Find the tools for users with no /sbin:/usr/sbin in PATH
 since some systems still make the distiction between bin and sbin.

---
 configure.ac | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 880672d..597dc14 100644
--- a/configure.ac
+++ b/configure.ac
@@ -65,16 +65,16 @@ AC_PROG_CC_C99
 AC_PATH_PROG([M4], [m4])
 AC_PATH_PROG([XSLTPROC], [xsltproc])
 
-AC_PATH_PROG([QUOTAON], [quotaon], [/usr/sbin/quotaon])
-AC_PATH_PROG([QUOTACHECK], [quotacheck], [/usr/sbin/quotacheck])
+AC_PATH_PROG([QUOTAON], [quotaon], [/usr/sbin/quotaon], [$PATH:/usr/bin:/bin:/usr/sbin:/sbin])
+AC_PATH_PROG([QUOTACHECK], [quotacheck], [/usr/sbin/quotacheck], [$PATH:/usr/bin:/bin:/usr/sbin:/sbin])
 
-AC_PATH_PROG([SETCAP], [setcap], [/usr/sbin/setcap])
+AC_PATH_PROG([SETCAP], [setcap], [/usr/sbin/setcap], [$PATH:/usr/bin:/bin:/usr/sbin:/sbin])
 
-AC_PATH_PROG([KILL], [kill], [/usr/bin/kill])
+AC_PATH_PROG([KILL], [kill], [/usr/bin/kill], [$PATH:/usr/bin:/bin:/usr/sbin:/sbin])
 
-AC_PATH_PROG([KMOD], [kmod], [/usr/bin/kmod])
+AC_PATH_PROG([KMOD], [kmod], [/usr/bin/kmod], [$PATH:/usr/bin:/bin:/usr/sbin:/sbin])
 
-AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec])
+AC_PATH_PROG([KEXEC], [kexec], [/usr/sbin/kexec], [$PATH:/usr/bin:/bin:/usr/sbin:/sbin])
 
 M4_DEFINES=
 
-- 
1.9.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Process Manager?

2014-03-02 Thread Samuli Suominen 

On 03/03/14 03:48, David Farning wrote:
> Over the last couple of weeks I have been looking over and testing the
> systemd. Thanks for all the hard work and interesting ideas.
>
> One issue that has come to mind is the quality and structure of the
> documentation. The quality and clarity of the documentation can be as
> important as the quality and clarity of the code.  As a relatively
> young project the scope and implementation has shifted as new ideas
> have been tested.
>
> This has resulted in two areas of mis-communication:
> 1. What is systemd?
> 2. What is systemd... now?
>
> One suggestion would be to refer to systemd as a 'process manager.'

well, sys-apps/systemd is part of the virtual/service-manager in Gentoo,
so we call it 'service manager'

just saying :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to build systemd with statically linking

2014-03-02 Thread Samuli Suominen 

On 01/03/14 22:07, Lennart Poettering wrote:
> On Sat, 01.03.14 20:36, Samuli Suominen (ssuomi...@gentoo.org) wrote:
>
>> On 01/03/14 20:11, Lennart Poettering wrote:
>>> On Sat, 01.03.14 17:46, Ȳ�翵 (j-zero.hw...@samsung.com) wrote:
>>>
>>>> Hello,
>>>>
>>>> I've tried to build systemd(v43) with statically linking.
>>>>
>>>> I revised Makefile.am and spec file but it was not built statically.
>>> We do not support static linking. We probably should turn this off
>>> entirely in the build system if there is a way, to make sure people get
>>> a clean error.
>> configure.ac already has:
>>
>> AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static
>> is not supported by systemd])])
>>
>> as the user was trying to build version 43, that'd explain why he didn't
>> see it, as that snippet wasn't added
>> at that time yet.
>> in any case, please don't make the building of libudev.a any more harder
>> than it is now, i know it has it's
>> pitfalls, and it shouldn't be officially supported in any way, but if
>> you know what you are doing, you can,
>> by removing this snippet from configure.ac, get a semi-working libudev.a
>> which is a prerequisite for
>> building static lvm2/cryptsetup binaries
> Why would you do something like that? That's just broken.
>
> Also the API between udevd and libudev is not stable, you should never
> mix different implementations.
>
> Lennart
>

Well, believe it or not, there are people using udev with alternate
service managers
like runit or openrc with a crypted / and a sep. /usr, without initramfs
And such an setup takes quite a knowledge to setup, so the same people
capable
of doing that, are well aware of the pitfall of mandatory recompile of
the static
binaries in case of an upgrade
I've talked about this with cryptsetup upstream ever since the
configure.ac snippet
was added to systemd, and even cryptsetup upstream *wants* to support such
configuration and sees no reason to remove the support for it
As in, their configure.ac is specifically designed to support building
--enable-static-binaries,
or similar
Same goes for LVM2
Ie. their configure.ac's have calls to `pkg-config --static --libs
libudev $any other package required`
and result ends up in vars like CRYPTSETUP_STATIC_LIBS= or LVM2_STATIC_LIBS=

So, if it's possible, even with some hackery, someone will for sure do it :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to build systemd with statically linking

2014-03-01 Thread Samuli Suominen 

On 01/03/14 20:11, Lennart Poettering wrote:
> On Sat, 01.03.14 17:46, Ȳ�翵 (j-zero.hw...@samsung.com) wrote:
>
>> Hello,
>>
>> I've tried to build systemd(v43) with statically linking.
>>
>> I revised Makefile.am and spec file but it was not built statically.
> We do not support static linking. We probably should turn this off
> entirely in the build system if there is a way, to make sure people get
> a clean error.

configure.ac already has:

AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static
is not supported by systemd])])

as the user was trying to build version 43, that'd explain why he didn't
see it, as that snippet wasn't added
at that time yet.
in any case, please don't make the building of libudev.a any more harder
than it is now, i know it has it's
pitfalls, and it shouldn't be officially supported in any way, but if
you know what you are doing, you can,
by removing this snippet from configure.ac, get a semi-working libudev.a
which is a prerequisite for
building static lvm2/cryptsetup binaries

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] build-sys: Also move libsystemd-journal to rootlibdir

2014-02-25 Thread Samuli Suominen 

On 24/02/14 18:34, Kay Sievers wrote:
> On Mon, Feb 24, 2014 at 4:04 PM, Alexey Shabalin  wrote:
>
>> Needed only libudev-install-hook, not more.
> It does not matter for proper filesystem layouts where everything is
> in one location, in /usr. The split of / vs. /usr never made much
> sense, it's a very incomplete and broken model.
>
> For legacy systems putting all systemd libs in / will always work,
> while putting some stuff in / and other in /usr needs to be checked
> case-by-case for every system.
>
> Systemd does don't care about fragile optimizations or doing cosmetics
> for legacy filesystem layouts, it just makes it work as long as
> needed. And for that it uses the simplest and safest option, so things
> should stay as they are now.

Thanks, I appericiate that -- for keeping them as they are.
The way --enable-split-usr, together with fine-grained
--with-root{libdir,prefix}, as they are now, are perfect for splitting
files where
they belong to. Then again, I can only speak for udev, as I'm only
building and installing it's files.

Thanks,
Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unmentioned 209 change: 80-net-name-slot.rules is gone

2014-02-21 Thread Samuli Suominen 

On 21/02/14 17:37, Colin Guthrie wrote:
> 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 21/02/14 13:58 did
> gyre and gimble:
>> On Fri, Feb 21, 2014 at 02:24:58PM +0100, Tom Gundersen wrote:
>>> On Fri, Feb 21, 2014 at 3:29 AM, Jason A. Donenfeld  wrote:
 Hey guys,

 This commit caught me by surprise:

 http://git.zx2c4.com/systemd/commit/?id=daeb71a36a98834664e4d95773a3629b746f4db8

 It wasn't in the NEWS or the mailing list post for 209, so when
 updating I encountered a bit of unexpected behavior. I see that I can
 disable persistent names using net.ifnames=0 in my kernel command
 line. Still not certain what the equivalent of the udev rule override
 is, though.
>>> Yeah, that should have been in the NEWS. Sorry about that.
>>>
>>> This is what we do in Arch to preserve the behavior form v208:
>>> .
>> It should still be added... Lots of people look at NEWS in the web git
>> interface, or long after the release.
> I updated the wiki page:
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
>
> Col
>
>
>

udev/rules.d/80-net-setup-link.rules is only a trigger for
systemd/network/99-default.link.rules where the actual
order of preference is recorded
wouldn't it be better to override the actual configuration, where you
can easily change the order of preference the interfaces get
renamed to, than the dummy trigger?

because the upstream wiki was updated to mention the .rules, then
someone changed my instructions here:
https://wiki.gentoo.org/index.php?title=Udev/upgrade&diff=110279&oldid=110235
and that looks like an regression, rather than improvement, to me

can we record the overriding of 99-default.link instead of
80-net-setup-link.rules, please?

- Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [patch] Install 99-default.link to rootprefix instead of prefix (as required)

2014-02-21 Thread Samuli Suominen 
By passing --rootprefix= you can get systemd-udevd installed to
/lib/systemd, as opposed to /usr/lib/systemd
And by logic, network configuration is needed to accompany the daemon
since /usr might not be mounted yet,
the network configuration needs to go to same prefix with the systemd-udevd

Currently we are overriding networkdir= at `make install` argument in
Gentoo's package
for udev, but obviously that is only a workaround.

This patch fixes things.

Other than this, I've had no issues with building, packaging, and
running udev separately without systemd from the systemd tree.
Keep up the great work! Thanks!

- Samuli
>From 44180dccea7ea9dee2c40f012d6b0b3e558c0e0b Mon Sep 17 00:00:00 2001
From: Samuli Suominen 
Date: Fri, 21 Feb 2014 16:14:51 +0200
Subject: [PATCH] With --rootprefix= systemd-udevd gets installed to
 /lib/systemd, and since the network configuration is also required during
 early boot, it should be available there with it. Using --prefix= is not an
 option since it would put everything, including pkg-config files, man pages,
 documentation, to / which is not wanted. This commit puts 99-default.link to
 /lib/systemd/network/ when required.

---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index f6c22bd..1fc23f7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -87,7 +87,7 @@ userunitdir=$(prefix)/lib/systemd/user
 userpresetdir=$(prefix)/lib/systemd/user-preset
 tmpfilesdir=$(prefix)/lib/tmpfiles.d
 sysctldir=$(prefix)/lib/sysctl.d
-networkdir=$(prefix)/lib/systemd/network
+networkdir=$(rootprefix)/lib/systemd/network
 pkgincludedir=$(includedir)/systemd
 systemgeneratordir=$(rootlibexecdir)/system-generators
 usergeneratordir=$(prefix)/lib/systemd/user-generators
-- 
1.8.5.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel