[ Sorry for the lag. ]
Michael Biebl bi...@debian.org (2014-09-02):
Am 02.09.2014 10:03, schrieb Ritesh Raj Sarraf:
And by the way, can someone please shed some more light on Debian bug:
760182
Per the bug report, there is no systemd support in d-i. Which then means
that I need to
On Tuesday 02 September 2014 01:33 PM, Ritesh Raj Sarraf wrote:
Could you elaborate a bit more, why those are needed?
What is upstream doing about this?
The block storage has many components that work closely with one another.
Take an example, root fs on LVM on Multipath on iSCSI.
The flow
On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote:
My inclination is to ship both, the systemd service files and the
init scripts, in their current form along with whatever
limitations each may have, and let the user choose.
I did not get any comment on this. How are others doing similar
stuff
On Wednesday 03 September 2014 06:51 PM, Henrique de Moraes Holschuh wrote:
On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote:
My inclination is to ship both, the systemd service files and the
init scripts, in their current form along with whatever
limitations each may have, and let the user
On Monday 01 September 2014 07:48 PM, Michael Biebl wrote:
In native init scripts, we did a lot of check before starting and
shutting down the daemon. Things like checking the root device, or
tiggering LVM Volume Group activitation. They were easily done in shell.
What would the systemd team
On Tuesday 02 September 2014 12:46 AM, Christian Hofstaedtler wrote:
In native init scripts, we did a lot of check before starting and shutting
down the daemon. Things like checking the root device, or tiggering LVM
Volume Group activitation. They were easily done in shell.
What would the
On Tuesday 02 September 2014 03:00 AM, Michael Biebl wrote:
Also, please don't simply override the lintian warning [1]. It is there
for a reason.
[1]
http://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=0783f2ec40f512adfda04c542c5ed38b53bf1247
Yes. After having talked to
Am 02.09.2014 10:03, schrieb Ritesh Raj Sarraf:
And by the way, can someone please shed some more light on Debian bug:
760182
Per the bug report, there is no systemd support in d-i. Which then means
that I need to disable systemd support ?
In your udeb build, yes. That typically means you
Am 02.09.2014 10:03, schrieb Ritesh Raj Sarraf:
And by the way, can someone please shed some more light on Debian bug:
760182
Per the bug report, there is no systemd support in d-i. Which then means
that I need to disable systemd support ?
In your udeb build, yes. That typically means you
On Sunday 31 August 2014 12:30 AM, Lucas Nussbaum wrote:
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part (hopefully):
cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall
Am 01.09.2014 12:50, schrieb Ritesh Raj Sarraf:
I fixed this one by adding a build-dep to systemd dev library. But for
some reason, the build is failing on all architectures. But the same
builds fine in my pbuilder. Any help ??
Looking at the build logs [1], the package itself builds fine but
* Ritesh Raj Sarraf r...@debian.org, 2014-09-01, 16:20:
cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -Wunused -Wstrict-prototypes -fPIC
Am 01.09.2014 13:25, schrieb Michael Biebl:
Am 01.09.2014 12:50, schrieb Ritesh Raj Sarraf:
I fixed this one by adding a build-dep to systemd dev library. But for
some reason, the build is failing on all architectures. But the same
builds fine in my pbuilder. Any help ??
Looking at the
On Mon, 1 Sep 2014 13:24:20 +0200 Jakub Wilk jw...@debian.org wrote:
* Ritesh Raj Sarraf r...@debian.org, 2014-09-01, 16:20:
cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector
Am 01.09.2014 13:37, schrieb Michael Biebl:
Am 01.09.2014 13:25, schrieb Michael Biebl:
Am 01.09.2014 12:50, schrieb Ritesh Raj Sarraf:
I fixed this one by adding a build-dep to systemd dev library. But for
some reason, the build is failing on all architectures. But the same
builds fine in my
On Monday 01 September 2014 05:56 PM, Michael Biebl wrote:
By quickly glancing over the package, I also noted that you ship a
systemd .service file named multipathd.service but the SysV init scripts
are named /etc/init.d/multipath-tools and
/etc/init.d/multipath-tools-boot (not quite sure why
Am 01.09.2014 15:05, schrieb Ritesh Raj Sarraf:
On Monday 01 September 2014 05:56 PM, Michael Biebl wrote:
If you have further questions, please don't hesitate to ask the
pkg-systemd-maintainers mailing list.
In native init scripts, we did a lot of check before starting and
shutting down
In native init scripts, we did a lot of check before starting and shutting
down the daemon. Things like checking the root device, or tiggering LVM
Volume Group activitation. They were easily done in shell.
What would the systemd team recommend for it ?
That probably depends on why you were
Am 01.09.2014 14:26, schrieb Michael Biebl:
Am 01.09.2014 13:37, schrieb Michael Biebl:
By quickly glancing over the package, I also noted that you ship a
systemd .service file named multipathd.service but the SysV init scripts
are named /etc/init.d/multipath-tools and
Source: multipath-tools
Version: 0.5.0-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20140830 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build on
amd64.
Relevant part (hopefully):
cc -g
20 matches
Mail list logo
