[systemd-devel] Broken build and CI strategy
Dear Lennart, the systemd build is currently broken[1] and judging from the commit history it appears that this happened more than once. Besides fixing the build you might want to consider adopting another strategy. In mature software projects the following is quite common: a.) Create a .travis.yml, sync your repo to github[2] and have travis-ci build your code. My .travis.yml file for systemd is here[3]. Travis can send email to the repo owners/travis owners on failed builds. b.) Use a combination of gerrit/jenkins. E.g. if you don't want to have broken builds in master. One would push changes for review to Gerrit, these would be automatically build on a Jenkins system and if they compile they can be integrated into the main repository. The workflow is used in projects like coreboot. cheers holger [1] https://travis-ci.org/zecke/systemde/builds/8530934 [2] github can create official mirrors of repositories but they only sync a couple of times/once a day. [3] https://github.com/zecke/systemde/blob/master/.travis.yml ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, Jun 28, 2013 at 8:50 AM, Holger Hans Peter Freyther hol...@freyther.de wrote: Dear Lennart, the systemd build is currently broken[1] and judging from the commit history it appears that this happened more than once. Besides fixing the build you might want to consider adopting another strategy. In mature software projects the following is quite common: a.) Create a .travis.yml, sync your repo to github[2] and have travis-ci build your code. My .travis.yml file for systemd is here[3]. Travis can send email to the repo owners/travis owners on failed builds. b.) Use a combination of gerrit/jenkins. E.g. if you don't want to have broken builds in master. One would push changes for review to Gerrit, these would be automatically build on a Jenkins system and if they compile they can be integrated into the main repository. The workflow is used in projects like coreboot. there already is a jenkins ci for systemd kindly provided by Pantheon: http://systemd.getpantheon.com:8080/jenkins/ The output of which can be seen on IRC. The problems always seem to come from non-standard/broken setups cheers holger [1] https://travis-ci.org/zecke/systemde/builds/8530934 [2] github can create official mirrors of repositories but they only sync a couple of times/once a day. [3] https://github.com/zecke/systemde/blob/master/.travis.yml ___ 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] Please review the patch about support the samsung series 2 Fn+keys.
Hello. This is dongjun jang. Please review the attached patch for the samsung series 3 Fn+F* keys(keymap and forced release events). This patch is for 300E5EV/300E4EV/270E5EV/270E4EV which is samsung series3 models. If you have any feedback, please let me know. Thank-you samsung-series-3-keyboard.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, Jun 28, 2013 at 09:05:40AM +0200, Peter Sztanojev wrote: On Fri, Jun 28, 2013 at 8:50 AM, Holger Hans Peter Freyther there already is a jenkins ci for systemd kindly provided by Pantheon: http://systemd.getpantheon.com:8080/jenkins/ The jenkins script is still using make test (which is like calling make /tmp), to execute the tests one would need to call make check but we already had this and it wasn't changed... The output of which can be seen on IRC. The problems always seem to come from non-standard/broken setups Could you please elaborate on standard vs. non-standard/broken setups. travis is building on a clean VM and installing most of the packages specified in the README file. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, Jun 28, 2013 at 9:18 AM, Holger Hans Peter Freyther hol...@freyther.de wrote: On Fri, Jun 28, 2013 at 09:05:40AM +0200, Peter Sztanojev wrote: On Fri, Jun 28, 2013 at 8:50 AM, Holger Hans Peter Freyther there already is a jenkins ci for systemd kindly provided by Pantheon: http://systemd.getpantheon.com:8080/jenkins/ The jenkins script is still using make test (which is like calling make /tmp), to execute the tests one would need to call make check but we already had this and it wasn't changed... So this issue is about tweaking how jenkins does its job? I have added David Strauss to the CC, hopefully he won't mind. The output of which can be seen on IRC. The problems always seem to come from non-standard/broken setups Could you please elaborate on standard vs. non-standard/broken setups. travis is building on a clean VM and installing most of the packages specified in the README file. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, Jun 28, 2013 at 09:43:08AM +0200, Peter Sztanojev wrote: So this issue is about tweaking how jenkins does its job? I have added David Strauss to the CC, hopefully he won't mind. Well, that is one part. make test really just checks if the test/ directory exists, it doesn't really contribute to the quality control. The other thing with make check is that it is failing if the build system doesn't run systemd[1] or fails if the installed version is not new enough (debian still ships systemd 44 that doesn't have catalogs so the catalog test fails). The output of which can be seen on IRC. The problems always seem to come from non-standard/broken setups Could you please elaborate on standard vs. non-standard/broken setups. travis is building on a clean VM and installing most of the packages specified in the README file. systemd currently does not link on default Debian/Ubuntu systems. Could you please elaborate how this is a non-standard/broken setup? I can make it link by installing binutils-gold, if systemd now requires gold, could you please update the configure.ac and README to reflect this? holger [1] https://travis-ci.org/zecke/systemde/builds/8531920 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Please review the patch about support the samsung series 2 Fn+keys.
Hello Dongjun Jang,
장동준 [2013-06-28 7:09 +]:
Please review the attached patch for the samsung series 3 Fn+F* keys(keymap
and forced release events).
This patch is for 300E5EV/300E4EV/270E5EV/270E4EV which is samsung series3
models.
This looks good by and large, but I wonder about the product matching:
+ENV{DMI_VENDOR}==[sS][aA][mM][sS][uU][nN][gG]*,
ATTR{[dmi/id]product_name}==300E5EV/300E4EV/270E5EV/270E4EV,
RUN+=keyboard-force-release.sh $devpath samsung-series-3
This is called series-3, but only applies to very specific models.
Will other, similar, models use the same keymap? I. e. would it be
appropriate to generalize this to something like
+ENV{DMI_VENDOR}==[sS][aA][mM][sS][uU][nN][gG]*,
ATTR{[dmi/id]product_name}==300*|270E*, RUN+=keyboard-force-release.sh
$devpath samsung-series-3
(Please note that alternatives are specified with |, not with / as in
your patch). This rule would apply to any model that starts with 300
or 270E. Perhaps it can be generalized even further.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Please review the patch about support the samsung series 2 Fn+keys.
Hello again,
장동준 [2013-06-28 8:15 +]:
Please review the attached patch for the samsung series 3 Fn+F* keys(keymap
and forced release events).
This patch is for samsung series3 models.
Ah, I sent my reply to your first patch at the same time when you sent this
second patch.
+ENV{DMI_VENDOR}==[sS][aA][mM][sS][uU][nN][gG]*,
ATTR{[dmi/id]product_name}==*300E5*|*300E4*|*300E7*|*270E5*|*270E4*,
RUN+=keyboard-force-release.sh $devpath samsung-series-3
So you already fixed the | and generalized these a bit. I still
wonder if it would be appropriate to use 300*|270*?
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Please review the patch about support the samsung series 2 Fn+keys.
Hello Martin Pitt.
At first, I sorry about first patch, it is just test patch for my test PC.
It's my mistake.
As your opinion, I discussed about this issue with our firmware engineer.
He said he can not guarantee about this.
Because Product ID 300*, 270* will be expanded, And firmware have possibility
to change.
I think it have some risk...
Honestly, it's out of my control.
I'm sorry about that.
Thanks.
-Dongjun
--- Original Message ---
Sender : Martin Pittmartin.p...@ubuntu.com
Date : 2013-06-28 17:18 (GMT+09:00)
Title : Re: [systemd-devel] Please review the patch about support the samsung
series 2 Fn+keys.
Hello again,
장동준 [2013-06-28 8:15 +]:
Please review the attached patch for the samsung series 3 Fn+F* keys(keymap
and forced release events).
This patch is for samsung series3 models.
Ah, I sent my reply to your first patch at the same time when you sent this
second patch.
+ENV{DMI_VENDOR}==[sS][aA][mM][sS][uU][nN][gG]*,
ATTR{[dmi/id]product_name}==*300E5*|*300E4*|*300E7*|*270E5*|*270E4*,
RUN+=keyboard-force-release.sh $devpath samsung-series-3
So you already fixed the | and generalized these a bit. I still
wonder if it would be appropriate to use 300*|270*?
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
pnbsp;/ppnbsp;/p
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] makefile:put macros file to the correct place
Zbigniew Jędrzejewski-Szmek píše v Čt 27. 06. 2013 v 17:00 +0200: On Thu, Jun 27, 2013 at 04:30:12PM +0200, Vaclav Pavlin wrote: From: Fedora systemd team systemd-ma...@redhat.com --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 3a196a6..c3988e8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -65,7 +65,7 @@ pkgconfigdatadir=$(datadir)/pkgconfig pkgconfiglibdir=$(libdir)/pkgconfig polkitpolicydir=$(datadir)/polkit-1/actions bashcompletiondir=@bashcompletiondir@ -rpmmacrosdir=$(sysconfdir)/rpm +rpmmacrosdir=$(prefix)/lib/rpm/macros.d Is this a recent change in rpmbuild? I don't see any macros in the new dir on FC19, and even don't have the dir on FC18... Zbyszek RPM guys removed systemd from default build-requires in buildroot by mistake. So we discussed how to do it so that systemd does not have to be default require for all packages that ship unit files. The result of this discussion was that we create a subpackage that will contain only rpm macro files. Michal Schmidt then suggested we could follow this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=846679 and move macro file to the new location. And yes, this applies only for F19+. Vaclav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Please review the patch about support the samsung series 2 Fn+keys.
Hello Dongjun, 장동준 [2013-06-28 8:44 +]: As your opinion, I discussed about this issue with our firmware engineer. He said he can not guarantee about this. Because Product ID 300*, 270* will be expanded, And firmware have possibility to change. I think it have some risk... Honestly, it's out of my control. I'm sorry about that. No worries, thanks for checking. So let's take the specific matches for now, we can always enlarge them later on. I adjusted your patch to current trunk and pushed: http://cgit.freedesktop.org/systemd/systemd/commit/?id=cda4380d9ffb Thank you! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] makefile:put macros file to the correct place
- Original Message - Zbigniew Jędrzejewski-Szmek píše v Čt 27. 06. 2013 v 17:00 +0200: On Thu, Jun 27, 2013 at 04:30:12PM +0200, Vaclav Pavlin wrote: From: Fedora systemd team systemd-ma...@redhat.com --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 3a196a6..c3988e8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -65,7 +65,7 @@ pkgconfigdatadir=$(datadir)/pkgconfig pkgconfiglibdir=$(libdir)/pkgconfig polkitpolicydir=$(datadir)/polkit-1/actions bashcompletiondir=@bashcompletiondir@ -rpmmacrosdir=$(sysconfdir)/rpm +rpmmacrosdir=$(prefix)/lib/rpm/macros.d Is this a recent change in rpmbuild? I don't see any macros in the new dir on FC19, and even don't have the dir on FC18... Zbyszek RPM guys removed systemd from default build-requires in buildroot by mistake. So we discussed how to do it so that systemd does not have to be default require for all packages that ship unit files. The result of this discussion was that we create a subpackage that will contain only rpm macro files. We used to have systemd-units for that, and it did not really work out to be useful and we merged it back. Why would it work today? It seems to be a pretty pattern to have a pkg-filesystem.rpm for larger projects. A package that contains the skeleton of empty directories. Should the empty directories also go into that package? Does the pkgconfig file needs to be packaged along with rpm macro file? Michal Schmidt then suggested we could follow this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=846679 and move macro file to the new location. And yes, this applies only for F19+. Nice. Maybe some day we will really have a clean /etc, with packages not messing around in it. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] makefile:put macros file to the correct place
Le vendredi 28 juin 2013 à 10:50 +0200, Václav Pavlín a écrit : Zbigniew Jędrzejewski-Szmek píše v Čt 27. 06. 2013 v 17:00 +0200: On Thu, Jun 27, 2013 at 04:30:12PM +0200, Vaclav Pavlin wrote: From: Fedora systemd team systemd-ma...@redhat.com --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 3a196a6..c3988e8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -65,7 +65,7 @@ pkgconfigdatadir=$(datadir)/pkgconfig pkgconfiglibdir=$(libdir)/pkgconfig polkitpolicydir=$(datadir)/polkit-1/actions bashcompletiondir=@bashcompletiondir@ -rpmmacrosdir=$(sysconfdir)/rpm +rpmmacrosdir=$(prefix)/lib/rpm/macros.d Is this a recent change in rpmbuild? I don't see any macros in the new dir on FC19, and even don't have the dir on FC18... Zbyszek RPM guys removed systemd from default build-requires in buildroot by mistake. So we discussed how to do it so that systemd does not have to be default require for all packages that ship unit files. The result of this discussion was that we create a subpackage that will contain only rpm macro files. This is funny, we just did the same on openSUSE Factory. Our package name is systemd-rpm-macros -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: fix a typo in systemd.socket.xml
Signed-off-by: Łukasz Stelmach l.stelm...@samsung.com --- man/systemd.socket.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml index 0d5652b..515412d 100644 --- a/man/systemd.socket.xml +++ b/man/systemd.socket.xml @@ -388,7 +388,7 @@ on the received socket before exiting. However, it must not unlink the socket from a filesystem. It -should note invoke +should not invoke citerefentryrefentrytitleshutdown/refentrytitlemanvolnum2/manvolnum/citerefentry on sockets it got with varnameAccept=false/varname, but -- 1.7.9.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, 28.06.13 08:50, Holger Hans Peter Freyther (hol...@freyther.de) wrote: Heya, Dear Lennart, the systemd build is currently broken[1] and judging from the commit So, it builds fine (make check) on Fedora 18/19, which is what I check against. It also builds fine on Pantheon's Jenkins instance. If it breaks on Ubuntu, then I am sorry for that, but this is a bit out of my reach. Ubuntu is not what we test against (Ubuntu doesn't even use systemd). I'd be happy to get this fixed, but it's really not that our boundless unprofessionalism caused this. This kind of issue will always happen, since we cannot afford a test system that builds systemd for all distributions of this world. (And Ubuntu *is* kind of an exotic choice for systemd development.) history it appears that this happened more than once. Besides fixing the build you might want to consider adopting another strategy. Well, mistakes do happen. There's no checking possible that would be truly comprehensive and cover all corner cases. In fact, that's the whole reason why technologies such as CI exist at all in the first place. In mature software projects the following is quite common: a.) Create a .travis.yml, sync your repo to github[2] and have travis-ci build your code. My .travis.yml file for systemd is here[3]. Travis can send email to the repo owners/travis owners on failed builds. This certainly sounds like a good idea to do. I presume travis uses Debian or Ubuntu for its builders? That would certainly complement the Fedora-based Pantheon Jenkins instance nicely. Is there some IRC bot for travis? b.) Use a combination of gerrit/jenkins. E.g. if you don't want to have broken builds in master. One would push changes for review to Gerrit, these would be automatically build on a Jenkins system and if they compile they can be integrated into the main repository. The workflow is used in projects like coreboot. I certainly prefer post-build CIs servers. I think it's OK if things do break every other month or so, as long as they are fixed quickly. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, 28.06.13 10:06, Holger Hans Peter Freyther (hol...@freyther.de) wrote: Well, that is one part. make test really just checks if the test/ directory exists, it doesn't really contribute to the quality control. The other thing with make check is that it is failing if the build system doesn't run systemd[1] or fails if the installed version is not new enough (debian still ships systemd 44 that doesn't have catalogs so the catalog test fails). Happy to see this fixed. THis is not the usual setup we build things on. We are all Fedora-based. The problems always seem to come from non-standard/broken setups Could you please elaborate on standard vs. non-standard/broken setups. travis is building on a clean VM and installing most of the packages specified in the README file. systemd currently does not link on default Debian/Ubuntu systems. Could you please elaborate how this is a non-standard/broken setup? Well, the systemd core developers are all on Fedora, and Ubuntu doesn't even use systemd, so it's a bit of an exotic choice. I mean, I am not saying that it is an excuse for elaving this broken, I am just trying to point out why we didn't notice this. I can make it link by installing binutils-gold, if systemd now requires gold, could you please update the configure.ac and README to reflect this? We use the normal Fedora linker, which I think is normal ld, not gold. We should certainly be able to make this work for any linker. Patch appreciated, as we do not run these systems ourselves. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
2013/6/28 Lennart Poettering lenn...@poettering.net: On Fri, 28.06.13 10:06, Holger Hans Peter Freyther (hol...@freyther.de) wrote: Well, that is one part. make test really just checks if the test/ directory exists, it doesn't really contribute to the quality control. The other thing with make check is that it is failing if the build system doesn't run systemd[1] Being able to run the systemd test suite without having systemd as pid 1 would certainly be nice, as we could then activate the test suite as part of our (Debian) build process and it would be run on all the different architectures. Cheers, Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
2013/6/28 Holger Hans Peter Freyther hol...@freyther.de: systemd currently does not link on default Debian/Ubuntu systems. v44, v204 and git master all build and link fine on my pretty standard Debian sid system, so I can't reproduce the problem, at least not on Debian. Cheers, Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, Jun 28, 2013 at 03:44:35PM +0200, Michael Biebl wrote: v44, v204 and git master all build and link fine on my pretty standard Debian sid system, so I can't reproduce the problem, at least not on Debian. Which linker and which system do you run it on? A clean build on my Debian Testing (i386) and Ubuntu 12.04 (travis, amd64) with GNU ld.bfd are both failing. GNU gold can link it on boths targets. I will not spend time to analyze it... cheers holger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
2013/6/28 Holger Hans Peter Freyther hol...@freyther.de: On Fri, Jun 28, 2013 at 03:44:35PM +0200, Michael Biebl wrote: v44, v204 and git master all build and link fine on my pretty standard Debian sid system, so I can't reproduce the problem, at least not on Debian. Which linker and which system do you run it on? A clean build on my Debian Testing (i386) and Ubuntu 12.04 (travis, amd64) with GNU ld.bfd are both failing. GNU gold can link it on boths targets. As I wrote, standard and up-to-date Debian sid, so the software which comes with it: [michael@pluto ~]$ ll /usr/bin/ld lrwxrwxrwx 1 root root 6 Jun 20 12:51 /usr/bin/ld - ld.bfd [michael@pluto ~]$ apt-cache policy binutils binutils: Installiert: 2.23.52.20130620-1 Installationskandidat: 2.23.52.20130620-1 Versionstabelle: *** 2.23.52.20130620-1 0 500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix a typo in systemd.socket.xml
On Fri, Jun 28, 2013 at 12:40 PM, Łukasz Stelmach l.stelm...@samsung.com wrote: Signed-off-by: Łukasz Stelmach l.stelm...@samsung.com --- man/systemd.socket.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml index 0d5652b..515412d 100644 --- a/man/systemd.socket.xml +++ b/man/systemd.socket.xml @@ -388,7 +388,7 @@ on the received socket before exiting. However, it must not unlink the socket from a filesystem. It -should note invoke +should not invoke citerefentryrefentrytitleshutdown/refentrytitlemanvolnum2/manvolnum/citerefentry on sockets it got with varnameAccept=false/varname, but -- 1.7.9.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel To whoever reviews these patches, note that this change is included in the large grammar patch I submitted yesterday. So this is just a heads-up that either this patch or my patch won't apply cleanly depending on commit order. Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, Jun 28, 2013 at 04:01:08PM +0200, Lennart Poettering wrote: Maybe this is simply broken automake dependency info somewhere left in your tree? I did the git clean but I still wondered, this is why I created the .travis.yml. Before I was building a branch that contained some of my RFC patches, now it is master + the .travis.yml and it is failing in the same way[1]. cheers holger PS: Yes, travis does support IRC notifications[2] [1] https://travis-ci.org/zecke/systemde/builds/8542339 [2] http://about.travis-ci.org/docs/user/notifications/#IRC-notification ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] tmpfiles, man: Add xattr support to tmpfiles
This patch makes it possible to set extended attributes on files created by tmpfiles. This can be especially used to set SMACK security labels on volatile files and directories. It is done by adding new line of type t. Such line should contain attributes in Argument field, using following format: name=value All other fields are ignored. If value contains spaces, then it must be surrounded by quotation marks. User can also put quotation mark in value by escaping it with backslash. Example: D /var/run/cups - - - - t /var/run/cups - - - - security.SMACK64=printing --- I've used t because IMHO a will be better for acl. To sum up: when t is met and it's not in hashmap, then it will be added. Then if other line for the same file appears, then it replaces SET_XATTR item in hashmap and has extended attributes added. If item earler existed in hashmap, then extended attributes are merged to existing entry. This means that there can be more than one t lines for one file. There is also posibility to have standalone t line. I hope that this is desired behaviour. regards, Maciej --- man/tmpfiles.d.xml | 26 - src/tmpfiles/tmpfiles.c | 274 ++-- 2 files changed, 285 insertions(+), 15 deletions(-) diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml index 519f9bc..92157b5 100644 --- a/man/tmpfiles.d.xml +++ b/man/tmpfiles.d.xml @@ -229,6 +229,21 @@ L/tmp/foobar ---- /dev/null/programlisting place of normal path names./para/listitem /varlistentry + +varlistentry +termvarnamet/varname/term +listitemparaSet extended +attributes on item. It should be +used with conjunction with other +types (only d, D, f, F, L, p, c, b, z +makes sense). If used as a standalone +line, then commandsystemd-tmpfiles +/command will try to set extended +attributes on specified path. +This can be especially used to set +SMACK labels. +/para/listitem +/varlistentry /variablelist /refsect2 @@ -242,7 +257,7 @@ L/tmp/foobar ---- /dev/null/programlisting objects. For z, Z lines if omitted or when set to - the file access mode will not be modified. This parameter is ignored for x, r, -R, L lines./para +R, L, t lines./para /refsect2 refsect2 @@ -254,7 +269,7 @@ L/tmp/foobar ---- /dev/null/programlisting omitted or when set to - the default 0 (root) is used. For z, Z lines when omitted or when set to - the file ownership will not be modified. -These parameters are ignored for x, r, R, L lines./para +These parameters are ignored for x, r, R, L, t lines./para /refsect2 refsect2 @@ -307,8 +322,10 @@ L/tmp/foobar ---- /dev/null/programlisting minor formatted as integers, separated by :, e.g. 1:3. For f, F, w may be used to specify a short string that is written to the file, -suffixed by a newline. Ignored for all other +suffixed by a newline. Fot t determines extended +attributes to be set. Ignored for all other lines./para + /refsect2 /refsect1 @@ -320,7 +337,8 @@ L/tmp/foobar ---- /dev/null/programlisting paracommandscreen/command needs two directories created at boot with specific modes and ownership./para programlistingd /var/run/screens 1777 root root 10d -d /var/run/uscreens 0755 root root 10d12h/programlisting +d /var/run/uscreens 0755 root root 10d12h +t /var/run/screen - - - - user.name=John Koval security.SMACK64=screen/programlisting /example /refsect1 diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c index 555347a..098413f 100644 --- a/src/tmpfiles/tmpfiles.c +++ b/src/tmpfiles/tmpfiles.c @@ -39,6 +39,9 @@ #include glob.h #include fnmatch.h #include sys/capability.h +#ifdef HAVE_XATTR +#include
Re: [systemd-devel] Broken build and CI strategy
2013/6/28 Michael Biebl mbi...@gmail.com: 2013/6/28 Holger Hans Peter Freyther hol...@freyther.de: On Fri, Jun 28, 2013 at 04:01:08PM +0200, Lennart Poettering wrote: Maybe this is simply broken automake dependency info somewhere left in your tree? I did the git clean but I still wondered, this is why I created the .travis.yml. Before I was building a branch that contained some of my RFC patches, now it is master + the .travis.yml and it is failing in the same way[1]. cheers holger PS: Yes, travis does support IRC notifications[2] [1] https://travis-ci.org/zecke/systemde/builds/8542339 [2] http://about.travis-ci.org/docs/user/notifications/#IRC-notification The build log was useful, thanks Since I was able to reproduce the build failure in a wheezy chroot (but interestingly not sid), I ran a git bisect in said wheezy chroot. The build failure seems to be caused by 4ad490007b70e6ac18d3cb04fa2ed92eba1451fa is the first bad commit commit 4ad490007b70e6ac18d3cb04fa2ed92eba1451fa Author: Lennart Poettering lenn...@poettering.net Date: Thu Jun 27 04:14:27 2013 +0200 core: general cgroup rework That said, I don't understand, why this commit breaks the build with that (older) toolchain. Neither bootctl nor libsystemd-id128.so is using cg_create(). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, Jun 28, 2013 at 07:05:35PM +0200, Michael Biebl wrote: That said, I don't understand, why this commit breaks the build with that (older) toolchain. Neither bootctl nor libsystemd-id128.so is using cg_create(). at the same time it has an undefined reference... $ nm -D .libs/libsystemd-id128.so | grep cg_create U cg_create ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: link libsystemd-id128.so with libsystemd-label
Fixes build on debian wheezy: ./.libs/libudev.so: undefined reference to `cg_create' Appears to have no influence on the resulting binaries and libraries. Cf. b5fafdf63f. --- Hi Michael, hi Holger, could you check if this fixes the build for you? Best, Zbyszek Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.am b/Makefile.am index 3ab1475..f5a25a8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1999,6 +1999,7 @@ libudev_la_LDFLAGS = \ libudev_la_LIBADD = \ libsystemd-shared.la \ + libsystemd-label.la \ libsystemd-daemon-internal.la \ libsystemd-id128-internal.la @@ -2662,6 +2663,7 @@ libsystemd_id128_la_LDFLAGS = \ libsystemd_id128_la_LIBADD = \ libsystemd-shared.la \ + libsystemd-label.la \ libsystemd-daemon-internal.la libsystemd_id128_internal_la_SOURCES = \ -- 1.8.2.562.g931e949 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: link libsystemd-id128.so with libsystemd-label
Am 29.06.2013 05:34, schrieb Zbigniew Jędrzejewski-Szmek: Fixes build on debian wheezy: ./.libs/libudev.so: undefined reference to `cg_create' Appears to have no influence on the resulting binaries and libraries. Cf. b5fafdf63f. --- Hi Michael, hi Holger, could you check if this fixes the build for you? It does indeed. Thanks, Zbyszek P.S: still don't unerstand though, why 4ad4900 broke the build. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
