Bug#1063565: different build results based on timestamps of configure.in and aclocal.m4
Package: src:weex
Version: 2.8.4.2
Tags: patch
The weex's Makefile _may_ run aclocal/autoconf/configure in dh_auto_build
depending on the timestamp comparison of files configure.in and aclocal.m4
(for details, manually run `dh_auto_configure` then check `make --debug`).
Non-maintainers might be unaware of this, and get unexpected build results,
e.g., _not_ link against `libssl` (which even segfaults in 2.8.3! LP: #1811817),
if they just `cp/scp -r` files, for example (not the most precise
copy, arguably,
but also unexpected to _silently_ produce such a different result and impact).
Ideally, `dh_autoreconf` would update `configure` in `dh_auto_configure`,
but it still fails (bug 929050) and needs more work that is very specific to
the project/package, apparently, and thus better handled by maintainers.
So, for now, in order to make the builds more deterministic and not implicitly
rely on the timestamps of the two files, let's just ensure `debian/rules` does
explicitly update the timestamp as required to keep current build behavior.
Thanks,
Mauricio
test steps:
$ dpkg-source -x weex_2.8.4.2.dsc
$ cp -r weex-2.8.4.2 weex-2.8.4.2-copy
$ ls -l --full-time weex-2.8.4.2{,-copy}/{aclocal.m4,configure.in}
-rw-rw-r-- 1 ubuntu ubuntu 183326 2024-02-09 15:10:04.563181675 +
weex-2.8.4.2-copy/aclocal.m4
-rw-rw-r-- 1 ubuntu ubuntu 2134 2024-02-09 15:10:04.563181675 +
weex-2.8.4.2-copy/configure.in
-rw-rw-r-- 1 ubuntu ubuntu 183326 2014-09-19 21:35:12.0 +
weex-2.8.4.2/aclocal.m4
-rw-rw-r-- 1 ubuntu ubuntu 2134 2017-02-08 14:03:36.0 +
weex-2.8.4.2/configure.in
original directory:
$ cd weex-2.8.4.2
$ dpkg-buildpackage -b -uc
...
dh_auto_configure
...
checking for SSL_library_init in -lssl... no
...
dh_auto_build
...
checking for OPENSSL_init_ssl in -lssl... yes
...
$ ldd ./debian/weex/usr/bin/weex | grep libssl
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x7ff1214d9000)
copy directory:
$ cd ../weex-2.8.4.2-copy
$ dpkg-buildpackage -b -uc
...
dh_auto_configure
...
checking for SSL_library_init in -lssl... no
...
dh_auto_build
...
$ ldd ./debian/weex/usr/bin/weex | grep libssl
$
--
Mauricio Faria de Oliveira
weex-touch-configurein.debdiff
Description: Binary data
Bug#1054805: Please update crash to 8.0.3
Package: src:crash Version: 8.0.2-1 Severity: wishlist Hi Troy, If at all possible, could you please update Debian sid to crash 8.0.3? I'm happy to try helping prepare it, although I don't have upload rights. Thanks, -- Mauricio Faria de Oliveira
Bug#1018084: Salsa MR
Merge Request submitted on Salsa: https://salsa.debian.org/openstack-team/services/cinder/-/merge_requests/2 cheers, -- Mauricio Faria de Oliveira
Bug#1018084: "Failed to re-export volume, setting to ERROR" with "tgtadm: failed to send request hdr to tgt daemon, Transport endpoint is not connected" on cinder-volume service start
R cinder.volume.manager six.reraise(self.value[0], self.value[1], self.value[2]) 9950 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager File "/usr/lib/python2.7/dist-packages/retrying.py", line 200, in call 9951 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager attempt = Attempt(fn(*args, **kwargs), attempt_number, False) 9952 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager File "/usr/lib/python2.7/dist-packages/cinder/volume/targets/tgt.py", line 141, in create_iscsi_target 9953 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager run_as_root=True) 9954 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager File "/usr/lib/python2.7/dist-packages/cinder/utils.py", line 126, in execute 9955 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager return processutils.execute(*cmd, **kwargs) 9956 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager File "/usr/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 424, in execute 9957 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager cmd=sanitized_cmd) 9958 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager ProcessExecutionError: Unexpected error while running command. 9959 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf tgtadm --lld iscsi --op show --mode target 9960 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager Exit code: 107 9961 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager Stdout: u'' 9962 2022-08-10 06:23:23.398 3932 ERROR cinder.volume.manager Stderr: u'tgtadm: failed to send request hdr to tgt daemon, Transport endpoint is not connected\n' Launchpad/Ubuntu bug: https://bugs.launchpad.net/bugs/1987663 cheers, -- Mauricio Faria de Oliveira
Bug#998416: debdiff and test steps
Oh, and this: > [...] or include the patch but change the defaults > to "no" Sorry, I didn't realize the values meant to be defaults; I just looked at whether the lines were commented out. So, sure, I can change that. Just let me know and I can update the MR in Salsa. -- Mauricio Faria de Oliveira
Bug#998416: debdiff and test steps
Hey Gustavo, Please excuse the delay in replying; apparently I didn't get the email. > I don't think users expect the behaviour of `netfilter-persistent start` > to change from "reset all rules to a known state" to > "add known rules on top of what's running", in my use case at least I > relay/trust that netfilter-persistent will clean any manually added > rules. Agree. The patch provides an option to do that, but not by default (no change). Some users/scenarios would benefit from it (below.) > What's the usercase you have in mind? I think the feature is useful but > I'd not change the defaults for the start action, I'm open to add a new > action (start-no-flush?) or include the patch but change the defaults > to "no" The use case is better interoperability with ufw, as iptables-persistent runs later in the boot process, and flushes ufw's rules, so ufw status shows inactive/disabled (can't find its rules) even if it's correctly setup. This is an issue for ufw users in some Ubuntu cloud images/providers, where iptables-persistent ships pre-configured platform/vendor rules (e.g., rootfs's iSCSI server), and users run ufw for their firewall rules. In that case, having the new option (not flushing existing rules) would allow both tools to coexist, each one with their own/different purpose. Since the changes are gated by a non-default option, and would need a manual switch (or preconfiguration during the image build process), hopefully that's not too much of an inconvenience, and still might help where needed. Would that be OK? cheers, -- Mauricio Faria de Oliveira
Bug#998416: debdiff and test steps
On Thu, Nov 4, 2021 at 7:40 PM gustavo panizzo wrote: [...] > On Wed, Nov 03, 2021 at 06:19:39PM -0300, Mauricio Oliveira wrote: [...] > >Debdiff attached. I'll try and submit a proper git-based merge > >once account on Salsa is made available. For now, just keeping > >the changes here too. [...] > cool thanks, i'll apply and upload soon Hey Gustavo. If that helps, I just submitted this as a MR on Salsa. [1] Thanks! [1] https://salsa.debian.org/debian/iptables-persistent/-/merge_requests/3 -- Mauricio Faria de Oliveira
Bug#998416: iptables-persistent: option for not flushing existing rules when starting/loading
Package: src:iptables-persistent Version: 1.0.15 Severity: wishlist Tags: patch -- Mauricio Faria de Oliveira
Bug#990836: Patch v2
Sending a debdiff v2, which uses a separate patch file for the (same) change. This should be simpler to isolate/revert if/once hwmatch is available on non-pc/i386 platforms, and also is better on documentation too, including DEP3 Bug- headers. cheers, -- Mauricio Faria de Oliveira grub2_hwmatch_v2.debdiff Description: Binary data
Bug#990836: grub2: fix "error: can't find command `hwmatch'." on efi-amd64
Package: src:grub2 Version: 2.04-19 Tags: patch When booting on x86_64 EFI this error message might be observed: error: can't find command `hwmatch'. It's usually seen on a serial console; depending on settings such as GRUB_TERMINAL=serial, GRUB_TIMEOUT_STYLE=hidden, and /etc/grub.d/10_linux:gfxpayload_dynamic="1" (Ubuntu default), and is easily reproducible with a KVM guest. The issue seems to be that d/p/gfxpayload-dynamic.patch only creates it in grub-core/commands/**i386/pc**/hwmatch.c, thus it's not available in other grub platforms. While it might be interesting to try and enable/fix that for other platforms, it would be nice to have a trivial fix that can more easily be considered to backport to stable releases. Since hwmatch apparently never worked on non-i386/pc, simply replacing the broken call with the equivalent behavior would be sufficient. That equivalent behavior is linux_gfx_mode=keep, despite the error. This happens because in the error case the grub shell evaluates `if hwmatch ...; then` to true and later evaluates `if [ $match = 0 ]; then` to true as well, as it's undefined, which does `set linux_gfx_mode=keep`. The attached debdiff addresses the issue by checking for the $grub_platform variable, and only calling hwmatch if that is 'pc', where hwmatch is available; otherwise, just use 'keep' to keep the current behavior. Before: error: can't find command `hwmatch'. ... grub> hwmatch error: can't find command `hwmatch'. grub> echo $grub_platform efi grub> echo $linux_gfx_mode keep After: ... grub> hwmatch error: can't find command `hwmatch'. grub> echo $grub_platform efi grub> echo $linux_gfx_mode keep Tested on Bullseye RC2. cheers, -- Mauricio Faria de Oliveira grub2_hwmatch.debdiff Description: Binary data
Bug#946313: debian/tests/basic-smoke: debootstrap stable might fail on future releases
Package: src:docker.io Version: 19.03.4+dfsg2-2 Tags: patch Hi, With the release of Debian Buster, docker.io/debian/tests/basic-smoke started to fail on Ubuntu Xenial [1]. Hopefully this bug report might help Debian too. Two failures happened on debootstrap: 1) The Release file signature check failed, as archive signatures changed across the stretch/buster stable releases, and the debian-archive-keyring in Xenial lacked the keys needed to check the signature. This could be worked around with 'debootstrap --no-check-gpg'. 2) The Unpacking stage failed, apparently due script changes needed (it works on Bionic, which is a newer release than Xenial). Both problems indicate that, for the sake of build / test reproducibility, the release used to debootstrap should not change, which is not the case with the 'stable' suite. Otherwise, eventually debian-archive-keyring and/or debootstrap might become out-of-date and stop working with the newer Debian stable releases, leading to false-positives of regressions in autopkgtest in Debian too. [1] https://bugs.launchpad.net/bugs/1855481 Hope this helps, -- Mauricio Faria de Oliveira docker.io_basic-smoke_buster.debdiff Description: Binary data
Bug#916041: Patch with IP address check
Hi Magnus, Ed,
This is the patch provided by Ed Spiridonov,
with an IP address check (not permitted for SNI)
provided by David Zuelke, currently in Ubuntu Eoan.
Hope this helps,
--
Mauricio Faria de Oliveira
Bug-Debian: https://bugs.debian.org/916041
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1834340
Description:
Google IMAP servers require SNI if TLSv1.3 is used,
otherwise it sends a self-signed certificate which
fails validation.
OpenSSL support/versions:
- TLSv1.3 on 1.1.1,
- a2i_IPADDRESS() on 0.9.8'ish,
- SSL_set_tlsext_host_name() on 0.9.8'ish/1.0.0;
per 'git blame/describe' and the CHANGES file.
So check for TLSv1.3 support / OpenSSL 1.1.1
not to incur behavior changes on pre-TLSv1.3,
and set host_name to 'host' (ssl_open_verify()
validates this, via 'ssl_last_host' variable)
This patch just combines these two patches:
- BTS#916041 (message #5) by Ed Spiridonov,
- LP#916041 (comment #6) by David Zuelke.
Author: Mauricio Faria de Oliveira
Index: uw-imap-2007f~dfsg/src/osdep/unix/ssl_unix.c
===
--- uw-imap-2007f~dfsg.orig/src/osdep/unix/ssl_unix.c
+++ uw-imap-2007f~dfsg/src/osdep/unix/ssl_unix.c
@@ -266,6 +266,14 @@ static char *ssl_start_work (SSLSTREAM *
/* create connection */
if (!(stream->con = (SSL *) SSL_new (stream->context)))
return "SSL connection failed";
+#if OPENSSL_VERSION_NUMBER >= 0x10101000
+ /* Use SNI in case server requires it with TLSv1.3.
+ * Literal IP addresses not permitted per RFC 6066. */
+ if (!a2i_IPADDRESS(host)) {
+ERR_clear_error();
+SSL_set_tlsext_host_name(stream->con,host);
+ }
+#endif
bio = BIO_new_socket (stream->tcpstream->tcpsi,BIO_NOCLOSE);
SSL_set_bio (stream->con,bio,bio);
SSL_set_connect_state (stream->con);
Bug#909011: libuv1 calls readlink() with buffer size zero for /proc/self
Thanks, Dominique! On Tue, Sep 18, 2018 at 10:23 AM Dominique Dumont wrote: > > On Monday, 17 September 2018 13:58:54 CEST you wrote: > > Package: libuv1 > > Version: 1.20.3 > > Tags: patch > > Patched and released. Thanks for the patch > > All the best > > Dod > > -- Mauricio Faria de Oliveira
Bug#909011: libuv1 calls readlink() with buffer size zero for /proc/self
Package: libuv1
Version: 1.20.3
Tags: patch
libuv1 calls readlink() with buffer size zero for /proc/self due to
downstream patch 'path_max'.
This breaks a nodejs test-case on chroot, containers, and s390x (in
Ubuntu at least), on which /dev/stdin is a symlink pointing to
/proc/self/fd/0.
On sid chroot:
# apt-get update
# apt-get install nodejs strace
# apt-get source nodejs
# cd nodejs-*
The /dev/stdin device is a symlink to /proc/self/...
# ls -l /dev/stdin
lrwxrwxrwx 1 root root 15 Sep 14 13:40 /dev/stdin -> /proc/self/fd/0
The lstat() call reports 'st_size' of zero for /proc/self:
# strace -e lstat \
stat /proc/self \
2>&1 | grep -e lstat -e File: -e Size:
lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
File: /proc/self -> 15804
Size: 0 Blocks: 0 IO Block: 1024 symbolic link
This causes libuv1 to call readlink() with a buffer size of zero, and
hit EINVAL:
# strace -f -e lstat,readlink \
node test/parallel/test-fs-realpath-pipe.js
[pid 15906] lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3780, ...}) = 0
[pid 15907] lstat("/dev/stdin", {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0
[pid 15909] lstat("/dev/stdin", {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0
[pid 15909] readlink("/dev/stdin", "/proc/self/fd/0", 15) = 15
[pid 15906] lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid 15907] lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
[pid 15909] lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
[pid 15909] readlink("/proc/self", 0x7ffa38000b40, 0) = -1 EINVAL
(Invalid argument)
With this patch applied, the call to readlink() has a non-zero buffer
size and returns correctly:
# dpkg -i libuv1_1.23.0-1+fixpathmax1_amd64.deb
# strace -f -e lstat,readlink \
node test/parallel/test-fs-realpath-pipe.js
[pid 31068] lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3780, ...}) = 0
[pid 31068] lstat("/dev/stdin", {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0
[pid 31068] lstat("/dev/stdin", {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0
[pid 31068] readlink("/dev/stdin", "/proc/self/fd/0", 15) = 15
[pid 31068] lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid 31068] lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
[pid 31068] lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
[pid 31068] readlink("/proc/self", "31068", 256) = 5
[pid 31068] lstat("/proc/31068", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
[pid 31068] lstat("/proc/31068/fd", {st_mode=S_IFDIR|0500,
st_size=0, ...}) = 0
[pid 31068] lstat("/proc/31068/fd/0", {st_mode=S_IFLNK|0700,
st_size=64, ...}) = 0
[pid 31068] lstat("/proc/31068/fd/0", {st_mode=S_IFLNK|0700,
st_size=64, ...}) = 0
[pid 31068] readlink("/proc/31068/fd/0", "socket:[266186]", 64) = 15
Thanks,
--
Mauricio Faria de Oliveira
sid-libuv1-path_max_zero_st_size.debdiff
Description: Binary data
Bug#844339: [PATCH v3 2/4] libvirt-daemon-system.{config,templates,postinst,NEWS}: warn if allocated uid/gid is taken
Hi Guido, On 11/18/2016 05:43 PM, Mauricio Faria de Oliveira wrote: If you're OK w/ my suggestions, would you apply the guard snippet, or would prefer a v4 of this particular patch submitted? Did you have a chance to check this? Wondering how you'd prefer to continue with this one. Thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#844339: [PATCH v3 2/4] libvirt-daemon-system.{config,templates,postinst,NEWS}: warn if allocated uid/gid is taken
Guido, On 11/18/2016 04:24 PM, Guido Günther wrote: I'm failing to spot how you make sure you only run on new installations. [snip] Oops. You're right. Not sure where my head was at. It passed tests due to debconf again; sorry. I thought of not doing a whole-file guard, but an early exit, to keep it short. Is this snippet OK with you? # Only perform this check/warning on new installations # (precisely: when not creating neither user nor group). if getent passwd libvirt-qemu >/dev/null \ && getent group libvirt-qemu >/dev/null; then exit 0 fi > +# Check if allocated UID/GID are assigned to a different user/group. > +UID_TO_NAME="$(getent passwd $LIBVIRT_QEMU_UID | cut -d: -f1)" > +GID_TO_NAME="$(getent group $LIBVIRT_QEMU_GID | cut -d: -f1)" > + > +if ( [ -n "$UID_TO_NAME" ] && [ "$UID_TO_NAME" != 'libvirt-qemu' ] ) \ > +|| ( [ -n "$GID_TO_NAME" ] && [ "$GID_TO_NAME" != 'libvirt-qemu' ] ) > \ I think this can be shortened to: if [ "$UID_TO_NAME" != 'libvirt-qemu' ] || [ "$GID_TO_NAME" != 'libvirt-qemu' ]; then Hm, but if the uid/gid is not taken, then getent output is null, which is != 'libvirt-qemu', so the warning shows up incorrectly. If you're OK w/ my suggestions, would you apply the guard snippet, or would prefer a v4 of this particular patch submitted? Thanks, -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#844339: [PATCH v3 2/4] libvirt-daemon-system.{config,templates,postinst,NEWS}: warn if allocated uid/gid is taken
If the uid/gid that is allocated for libvirt-qemu (64055)
is already in use by another user/group, stop/ask user if
it is OK to continue (e.g., no plans with guest migration
over NFS) or abort to go fix the problem.
This warning is only displayed on new installations. The
default value is 'yes'/continue/do not abort, thus not to
disrupt automated installations.
On existing installations, no warning is displayed - just
a NEWS file is provided.
Signed-off-by: Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com>
---
debian/libvirt-daemon-system.NEWS | 22 ++
debian/libvirt-daemon-system.config| 26 ++
debian/libvirt-daemon-system.postinst | 3 +++
debian/libvirt-daemon-system.templates | 18 ++
4 files changed, 69 insertions(+)
create mode 100755 debian/libvirt-daemon-system.config
create mode 100644 debian/libvirt-daemon-system.templates
diff --git a/debian/libvirt-daemon-system.NEWS
b/debian/libvirt-daemon-system.NEWS
index 977abdb..94367e5 100644
--- a/debian/libvirt-daemon-system.NEWS
+++ b/debian/libvirt-daemon-system.NEWS
@@ -1,3 +1,25 @@
+libvirt (2.4.0-2uidgid3) UNRELEASED; urgency=medium
+
+ libvirt-daemon-system now uses the allocated uid and gid 64055
+ for the libvirt-qemu user and group on new installations, when
+ the uid/gid is available (otherwise a debconf warning is shown).
+
+ On existing installations, which have different uid/gid values
+ assigned, the recommended procedure is to reassign the uid/gid
+ (might require considerations for ownership/permission changes).
+ No debconf warning is shown in this case; only this NEWS entry.
+
+ This change is in order to prevent I/O errors during migration
+ of guests with disk image files shared over NFS, caused by the
+ different uid/gid ownership between the source and destination
+ host systems, which leads to access/permission errors with NFS.
+
+ If guest migration over NFS is not a requirement in the system,
+ there should not be any impact to the guests for not using the
+ allocated uid/gid.
+
+ -- Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com> Thu, 18 Nov 2016
13:56:38 -0200
+
libvirt (1.2.9~rc1-1) experimental; urgency=medium
libvirtd now uses PolicyKit instead of unix socket domain permissions for r/w
diff --git a/debian/libvirt-daemon-system.config
b/debian/libvirt-daemon-system.config
new file mode 100755
index 000..caf0ac2
--- /dev/null
+++ b/debian/libvirt-daemon-system.config
@@ -0,0 +1,26 @@
+#!/bin/sh -e
+
+# Source debconf library.
+. /usr/share/debconf/confmodule
+
+# Allocated UID and GID for libvirt-qemu
+LIBVIRT_QEMU_UID=64055
+LIBVIRT_QEMU_GID=64055
+
+# Check if allocated UID/GID are assigned to a different user/group.
+UID_TO_NAME="$(getent passwd $LIBVIRT_QEMU_UID | cut -d: -f1)"
+GID_TO_NAME="$(getent group $LIBVIRT_QEMU_GID | cut -d: -f1)"
+
+if ( [ -n "$UID_TO_NAME" ] && [ "$UID_TO_NAME" != 'libvirt-qemu' ] ) \
+|| ( [ -n "$GID_TO_NAME" ] && [ "$GID_TO_NAME" != 'libvirt-qemu' ] ) \
+then
+ # Ask if the user would like to continue or abort installation.
+ db_input high libvirt-daemon-system/id_warning || true
+ db_go
+ db_get libvirt-daemon-system/id_warning
+ if [ "$RET" = "false" ]; then
+ exit 1
+ fi
+fi
+
+exit 0
diff --git a/debian/libvirt-daemon-system.postinst
b/debian/libvirt-daemon-system.postinst
index 99e9fec..f36b806 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -17,6 +17,9 @@ set -e
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package
+# Source debconf library.
+. /usr/share/debconf/confmodule
+
add_users_groups()
{
if ! getent group libvirt >/dev/null; then
diff --git a/debian/libvirt-daemon-system.templates
b/debian/libvirt-daemon-system.templates
new file mode 100644
index 000..7e1594b
--- /dev/null
+++ b/debian/libvirt-daemon-system.templates
@@ -0,0 +1,18 @@
+Template: libvirt-daemon-system/id_warning
+Type: boolean
+Default: true
+Description: Continue with incorrect libvirt-qemu user/group ID(s)?
+ The user/group ID (uid/gid) allocated for libvirt-qemu (64055)
+ seems to be taken by another user/group, thus it is not possible
+ to create the user/group with this numeric ID.
+ .
+ The migration of guests with disk image files shared over NFS
+ requires a static libvirt-qemu user and group ID (uid and gid)
+ between the source and destination host systems.
+ .
+ If guest migration over NFS is not required, you can continue
+ the installation.
+ .
+ In order to resolve this problem, do not continue the installation,
+ release the 64055 uid/gid (which might involve permission changes),
+ then install this package again.
--
2.10.2
Bug#844339: [PATCH v3 4/4] update changelog
Signed-off-by: Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com>
---
debian/changelog | 9 +
1 file changed, 9 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 70f3b31..643e29f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libvirt (2.4.0-2uidgid3) UNRELEASED; urgency=medium
+
+ * Use allocated uid/gid for libvirt-qemu if possible (Closes: #844339)
+[...] libvirt-daemon-system.postinst: use allocated uid/gid if possible
+[...] libvirt-daemon-system.{config,templates,postinst,NEWS}: warn if
allocated uid/gid is taken
+[...] libvirt-daemon-system.post{inst,rm}: quiet output for debconf
+
+ -- Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com> Thu, 18 Nov 2016
13:56:38 -0200
+
libvirt (2.4.0-2) unstable; urgency=medium
* [f964983] Unbreak rebuilding docs with release tarballs (Closes: #842452)
--
2.10.2
Bug#844339: [PATCH v3 3/4] libvirt-daemon-system.postinst: use allocated uid/gid if possible
Use the allocated uid/gid for libvirt-qemu
when creating the user/group, if not taken.
In case it's taken, the user has been asked
to continue or abort the installation, thus
if we are here, it is OK to proceed and not
use the allocated uid/gid.
Signed-off-by: Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com>
---
debian/libvirt-daemon-system.postinst | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/debian/libvirt-daemon-system.postinst
b/debian/libvirt-daemon-system.postinst
index f36b806..3730783 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -20,6 +20,10 @@ set -e
# Source debconf library.
. /usr/share/debconf/confmodule
+# Allocated UID and GID for libvirt-qemu
+LIBVIRT_QEMU_UID=64055
+LIBVIRT_QEMU_GID=64055
+
add_users_groups()
{
if ! getent group libvirt >/dev/null; then
@@ -31,6 +35,13 @@ add_users_groups()
fi
# user and group libvirt runs qemu/kvm instances with
if ! getent passwd libvirt-qemu >/dev/null; then
+
+# set uid if available (expected); don't fail otherwise.
+PARAMETER_UID=''
+if ! getent passwd $LIBVIRT_QEMU_UID >/dev/null; then
+PARAMETER_UID="--uid $LIBVIRT_QEMU_UID"
+fi
+
adduser --quiet \
--system \
--ingroup kvm \
@@ -40,10 +51,18 @@ add_users_groups()
--home /var/lib/libvirt \
--no-create-home \
--gecos "Libvirt Qemu" \
+$PARAMETER_UID \
libvirt-qemu
fi
if ! getent group libvirt-qemu >/dev/null; then
-addgroup --quiet --system libvirt-qemu
+
+# set gid if available (expected); don't fail otherwise.
+PARAMETER_GID=''
+if ! getent group $LIBVIRT_QEMU_GID >/dev/null; then
+PARAMETER_GID="--gid $LIBVIRT_QEMU_GID"
+fi
+
+addgroup --quiet --system $PARAMETER_GID libvirt-qemu
adduser --quiet libvirt-qemu libvirt-qemu
fi
}
--
2.10.2
Bug#844339: [PATCH v3 1/4] libvirt-daemon-system.post{inst,rm}: quiet output for debconf
Add some --quiet arguments and /dev/null redirects
in order to make the scripts safe for debconf.
Signed-off-by: Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com>
---
debian/libvirt-daemon-system.postinst | 8
debian/libvirt-daemon-system.postrm | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/debian/libvirt-daemon-system.postinst
b/debian/libvirt-daemon-system.postinst
index d0d670d..99e9fec 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -20,7 +20,7 @@ set -e
add_users_groups()
{
if ! getent group libvirt >/dev/null; then
-addgroup --system libvirt
+addgroup --quiet --system libvirt
fi
if ! getent group kvm >/dev/null; then
@@ -41,7 +41,7 @@ add_users_groups()
fi
if ! getent group libvirt-qemu >/dev/null; then
addgroup --quiet --system libvirt-qemu
-adduser libvirt-qemu libvirt-qemu
+adduser --quiet libvirt-qemu libvirt-qemu
fi
}
@@ -106,8 +106,8 @@ case "$1" in
# Force virtlockd to reexec if enabled
if [ -d /run/systemd/system ]; then
- ! systemctl is-active -q virtlogd || systemctl reload
virtlogd.service
- ! systemctl is-active -q virtlockd || systemctl reload
virtlockd.service
+ ! systemctl is-active -q virtlogd || systemctl reload
virtlogd.service >/dev/null
+ ! systemctl is-active -q virtlockd || systemctl reload
virtlockd.service >/dev/null
fi
# Force refresh of capabilties (#731815)
diff --git a/debian/libvirt-daemon-system.postrm
b/debian/libvirt-daemon-system.postrm
index 62d9b4b..179ed93 100644
--- a/debian/libvirt-daemon-system.postrm
+++ b/debian/libvirt-daemon-system.postrm
@@ -22,15 +22,15 @@ set -e
case "$1" in
purge)
if getent group libvirt >/dev/null; then
- delgroup libvirt || true
+ delgroup libvirt >/dev/null || true
fi
if getent passwd libvirt-qemu >/dev/null; then
- deluser libvirt-qemu || true
+ deluser libvirt-qemu >/dev/null || true
fi
if getent group libvirt-qemu >/dev/null; then
- delgroup libvirt-qemu || true
+ delgroup libvirt-qemu >/dev/null || true
fi
# Clean up logs and cached capabilities
--
2.10.2
Bug#844339: [PATCH v2 2/4] libvirt-daemon-system.{config,templates,postinst}: warn if allocated uid/gid cannot be used
On 11/18/2016 06:24 AM, Guido Günther wrote: Exactly. That's why NEWS.Debian is nicer iff the user libvirt-qemu exists but with "wrong" (legacy) uid/gid on existing installations and Debconf is better for new installations where the uid/gid is already taken. Thanks for the debconf/NEWS.Debian clarifications; finally got it! Totally agree w/ your point now. I'll spin the v3 w/ those changes. cheers, -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#844339: [PATCH v2 2/4] libvirt-daemon-system.{config,templates,postinst}: warn if allocated uid/gid cannot be used
On 11/17/2016 05:37 PM, Guido Günther wrote: I'm basically fine with all of this (but did not du any actual testing) Cool. but we should not warn if the user/group already exists (even with the wrong uid). Otherwise we'd warn over and over again, we don't want to force users to change existing installations. Actually the warning is not repeated; the answer is saved by debconf. If you just install/upgrade after having answered the question once, it doesn't show up. You only get it again in intentional cases: 1) dpkg-reconfigure 2) apt-get purge && re-install 3) remove its 'Flags: seen' line from /var/cache/debconf/config.dat If we want to notify users of existing installations we have a Debian.NEWS for this that can explain that switching to uid/git 64055 is recommended. Good point. I can write a snippet for that too if you want, but not sure it's enough depending on your decision about how/when to notify users (paragraph below). IMHO the only important case to warn about is the case where user or group does not yet exist _and_ the uid/gid is already taken by another user or group. What do you think? Well, I still think it's also important to warn when the user/group already exists (with a different uid/gid). The main reason is to help users not to hit a known problem, and help maintainers not to get unnecessary bug reports, or having to debug it again (it was hard to debug/trace this, the root cause is very subtle, and the stack components pile up -- I ended up strace'ing qemu, found EACCES in read/write syscalls, and had to understand how NFS had come up with this type of error -- not that I'm proud, I imagine it's easy for people more experienced w/ the virtualization stack; just a story). If existing installations are never told about this, they didn't even have a chance to try to fix their environment not to hit it, and I guess it's a valid expectation from the packages to set up things up correctly so not to hit problems (of course this case is not easy/automatic to resolve..) (some systems will never hit it because users were just created in the same order on source/destination hosts; but that's luck) On the other hand, I'm not sure how disruptive such a warning is for automated deployments/upgrades, specially because the default is to abort the install (perhaps we should change it). Anyway, just trying to provide some pondering and other thoughts/ views on the matter, with the intention it may help :- ) Let me know what/how you'd like it in the patches and I'll spin v3 ;- ) Thanks a lot for working on this! Glad to contribute; thanks for the great suggestions/pointers. -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#844339: [PATCH v2 1/4] libvirt-daemon-system.post{inst,rm}: quiet output for debconf
Add some --quiet arguments and /dev/null redirects
in order to make the scripts safe for debconf.
Signed-off-by: Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com>
---
debian/libvirt-daemon-system.postinst | 8
debian/libvirt-daemon-system.postrm | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/debian/libvirt-daemon-system.postinst
b/debian/libvirt-daemon-system.postinst
index d0d670d..99e9fec 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -20,7 +20,7 @@ set -e
add_users_groups()
{
if ! getent group libvirt >/dev/null; then
-addgroup --system libvirt
+addgroup --quiet --system libvirt
fi
if ! getent group kvm >/dev/null; then
@@ -41,7 +41,7 @@ add_users_groups()
fi
if ! getent group libvirt-qemu >/dev/null; then
addgroup --quiet --system libvirt-qemu
-adduser libvirt-qemu libvirt-qemu
+adduser --quiet libvirt-qemu libvirt-qemu
fi
}
@@ -106,8 +106,8 @@ case "$1" in
# Force virtlockd to reexec if enabled
if [ -d /run/systemd/system ]; then
- ! systemctl is-active -q virtlogd || systemctl reload
virtlogd.service
- ! systemctl is-active -q virtlockd || systemctl reload
virtlockd.service
+ ! systemctl is-active -q virtlogd || systemctl reload
virtlogd.service >/dev/null
+ ! systemctl is-active -q virtlockd || systemctl reload
virtlockd.service >/dev/null
fi
# Force refresh of capabilties (#731815)
diff --git a/debian/libvirt-daemon-system.postrm
b/debian/libvirt-daemon-system.postrm
index 62d9b4b..179ed93 100644
--- a/debian/libvirt-daemon-system.postrm
+++ b/debian/libvirt-daemon-system.postrm
@@ -22,15 +22,15 @@ set -e
case "$1" in
purge)
if getent group libvirt >/dev/null; then
- delgroup libvirt || true
+ delgroup libvirt >/dev/null || true
fi
if getent passwd libvirt-qemu >/dev/null; then
- deluser libvirt-qemu || true
+ deluser libvirt-qemu >/dev/null || true
fi
if getent group libvirt-qemu >/dev/null; then
- delgroup libvirt-qemu || true
+ delgroup libvirt-qemu >/dev/null || true
fi
# Clean up logs and cached capabilities
--
2.10.2
Bug#844339: [PATCH v2 3/4] libvirt-daemon-system.postinst: use allocated uid/gid if possible
Use the allocated uid/gid for libvirt-qemu
when creating the user/group, if not taken.
If the user/group already exists or uid/gid
are already in use, the user has been asked
to continue or abort the installation, thus
if we are here, it is OK to proceed and not
use the allocated uid/gid.
Signed-off-by: Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com>
---
debian/libvirt-daemon-system.postinst | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/debian/libvirt-daemon-system.postinst
b/debian/libvirt-daemon-system.postinst
index f36b806..3730783 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -20,6 +20,10 @@ set -e
# Source debconf library.
. /usr/share/debconf/confmodule
+# Allocated UID and GID for libvirt-qemu
+LIBVIRT_QEMU_UID=64055
+LIBVIRT_QEMU_GID=64055
+
add_users_groups()
{
if ! getent group libvirt >/dev/null; then
@@ -31,6 +35,13 @@ add_users_groups()
fi
# user and group libvirt runs qemu/kvm instances with
if ! getent passwd libvirt-qemu >/dev/null; then
+
+# set uid if available (expected); don't fail otherwise.
+PARAMETER_UID=''
+if ! getent passwd $LIBVIRT_QEMU_UID >/dev/null; then
+PARAMETER_UID="--uid $LIBVIRT_QEMU_UID"
+fi
+
adduser --quiet \
--system \
--ingroup kvm \
@@ -40,10 +51,18 @@ add_users_groups()
--home /var/lib/libvirt \
--no-create-home \
--gecos "Libvirt Qemu" \
+$PARAMETER_UID \
libvirt-qemu
fi
if ! getent group libvirt-qemu >/dev/null; then
-addgroup --quiet --system libvirt-qemu
+
+# set gid if available (expected); don't fail otherwise.
+PARAMETER_GID=''
+if ! getent group $LIBVIRT_QEMU_GID >/dev/null; then
+PARAMETER_GID="--gid $LIBVIRT_QEMU_GID"
+fi
+
+addgroup --quiet --system $PARAMETER_GID libvirt-qemu
adduser --quiet libvirt-qemu libvirt-qemu
fi
}
--
2.10.2
Bug#844339: [PATCH v2 2/4] libvirt-daemon-system.{config,templates,postinst}: warn if allocated uid/gid cannot be used
If the libvirt-qemu user/group already exists with different
uid/gid than the allocated numeric ID (64055), or if this ID
is already in use by another user/group, stop/ask user if it
is OK to continue (e.g., no plans to perform guest migration
over NFS) or abort to go fix the problem.
Signed-off-by: Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com>
---
debian/libvirt-daemon-system.config| 30 ++
debian/libvirt-daemon-system.postinst | 3 +++
debian/libvirt-daemon-system.templates | 19 +++
debian/rules | 1 +
4 files changed, 53 insertions(+)
create mode 100755 debian/libvirt-daemon-system.config
create mode 100644 debian/libvirt-daemon-system.templates
diff --git a/debian/libvirt-daemon-system.config
b/debian/libvirt-daemon-system.config
new file mode 100755
index 000..27ce292
--- /dev/null
+++ b/debian/libvirt-daemon-system.config
@@ -0,0 +1,30 @@
+#!/bin/sh -e
+
+# Source debconf library.
+. /usr/share/debconf/confmodule
+
+# Allocated UID and GID for libvirt-qemu
+LIBVIRT_QEMU_UID=64055
+LIBVIRT_QEMU_GID=64055
+
+# Check if libvirt-qemu user/group is assigned a different UID/GID or
vice-versa.
+NAME_TO_UID="$(getent passwd libvirt-qemu | cut -d: -f3)"
+NAME_TO_GID="$(getent group libvirt-qemu | cut -d: -f3)"
+UID_TO_NAME="$(getent passwd $LIBVIRT_QEMU_UID | cut -d: -f1)"
+GID_TO_NAME="$(getent group $LIBVIRT_QEMU_GID | cut -d: -f1)"
+
+if ( [ -n "$NAME_TO_UID" ] && [ "$NAME_TO_UID" != "$LIBVIRT_QEMU_UID" ] ) \
+|| ( [ -n "$NAME_TO_GID" ] && [ "$NAME_TO_GID" != "$LIBVIRT_QEMU_GID" ] ) \
+|| ( [ -n "$UID_TO_NAME" ] && [ "$UID_TO_NAME" != 'libvirt-qemu' ] ) \
+|| ( [ -n "$GID_TO_NAME" ] && [ "$GID_TO_NAME" != 'libvirt-qemu' ] ) \
+then
+ # Ask if the user would like to continue or abort installation.
+ db_input high libvirt-daemon-system/id_warning || true
+ db_go
+ db_get libvirt-daemon-system/id_warning
+ if [ "$RET" = "false" ]; then
+ exit 1
+ fi
+fi
+
+exit 0
diff --git a/debian/libvirt-daemon-system.postinst
b/debian/libvirt-daemon-system.postinst
index 99e9fec..f36b806 100644
--- a/debian/libvirt-daemon-system.postinst
+++ b/debian/libvirt-daemon-system.postinst
@@ -17,6 +17,9 @@ set -e
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package
+# Source debconf library.
+. /usr/share/debconf/confmodule
+
add_users_groups()
{
if ! getent group libvirt >/dev/null; then
diff --git a/debian/libvirt-daemon-system.templates
b/debian/libvirt-daemon-system.templates
new file mode 100644
index 000..57193b0
--- /dev/null
+++ b/debian/libvirt-daemon-system.templates
@@ -0,0 +1,19 @@
+Template: libvirt-daemon-system/id_warning
+Type: boolean
+Default: false
+Description: Continue with incorrect libvirt-qemu user/group ID(s)?
+ This system seems to already have a libvirt-qemu user and/or
+ group with different ID(s) than the allocated (64055) or the
+ numeric ID is already taken by another user/group.
+ .
+ The migration of guests with disk image files shared over NFS
+ requires a static libvirt-qemu user and group ID (uid and gid)
+ between the source and destination host systems.
+ .
+ If guest migration over NFS is not required you can continue
+ the installation.
+ .
+ In order to resolve this problem, do not continue the installation,
+ remove the libvirt-qemu user/group and/or the 64055 uid/gid (which
+ might involve changing permissions for its owned files) and try to
+ install this package again.
diff --git a/debian/rules b/debian/rules
index 6e0a416..ec9d90d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -159,6 +159,7 @@ override_dh_auto_test:
fi
override_dh_install-arch:
+ dh_installdebconf
dh_install
# Copy upstream files to debian/ so dh_* can find them
--
2.10.2
Bug#844339: PATCH v2 on the way
Hi Guido, I'll submit the patches w/ the debconf-based warning message. It looked good during tests. The test procedure I used is to verify the libvirt-daemon-system package installation in the following scenarios: 0) no libvirt-qemu user/group, no 64055 uid/gid 1) libvirt-qemu user/group with 64055 uid/gid 2) libvirt-qemu user w/ different uid 3) libvirt-qemu group w/ different gid 4) another user w/ allocated uid 5) another group w/ allocated gid In tests 0,1 no warning message is displayed. In tests 2-5 the warning message is displayed. If the user chooses not to continue, the package installation fails: dpkg: error processing package libvirt-daemon-system (--install): subprocess installed post-installation script returned error exit status 1 Processing triggers for systemd (215-17+deb8u5) ... Errors were encountered while processing: libvirt-daemon-system (and the install after fixing user/group/uid/gid works correctly) And if the user chooses to continue, the package installation proceeds normally and finishes successfully (with different uid/gid, of course). I believe all that is following the expected behavior. P.S.: On a side note, please see [1] (thanks Christian Ehrhardt for pointing this out.) Do you plan to update the package with that change, and if so, would like to see these patches following that, or change it all after/if these patches are applied? Thanks! [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833#174 -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#844339: [PATCH v2 4/4] changelog update
Signed-off-by: Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com>
---
debian/changelog | 9 +
1 file changed, 9 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 70f3b31..0573a25 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libvirt (2.4.0-2uidgid21) UNRELEASED; urgency=medium
+
+ * Use allocated uid/gid for libvirt-qemu if possible (Closes: #844339)
+[6cc96c2] libvirt-daemon-system.post{inst,rm}: quiet output for debconf
+[d361670] libvirt-daemon-system.{config,templates,postinst}: warn if
allocated uid/gid cannot be used
+[4b37b9e] libvirt-daemon-system.postinst: use allocated uid/gid if possible
+
+ -- Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com> Thu, 17 Nov 2016
10:33:48 -0200
+
libvirt (2.4.0-2) unstable; urgency=medium
* [f964983] Unbreak rebuilding docs with release tarballs (Closes: #842452)
--
2.10.2
Bug#844339: [Pkg-libvirt-maintainers] Bug#844339: patch for sid
On 11/16/2016 05:42 PM, Guido Günther wrote:
No, you need to use getent or similar since the user/group might not be in
/etc/{passwd,group} (e.g. ldap).
Oh, right.
Thanks for this; getent turned out to be a very good option;
no group changes required.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
Bug#844339: [Pkg-libvirt-maintainers] Bug#844339: patch for sid
Hi Guido, On 11/15/2016 08:00 AM, Guido Günther wrote: What do you think of a debconf warning message/prompt, which > asks the user to confirm that it's OK not to use the uid/gid values, > and explains about the potential problem w/ guest migration over NFS? Although it adds some complexity it makes the most sense. Are you going to look into this? Yup. Looking. Meanwhile, is it a problem if the primary group of libvirt-qemu user changes from kvm to libvirt-qemu (ie, adduser --ingroup), then later the user is added to the kvm group (ie, adduser libvirt-qemu kvm) ? This would help to check the gid in the debconf config script, since it can only use essential packages (ie, coreutils's id command), and the id command can only return the gid of the primary group. A more conservative option is to directly grep for libvirt-qemu pattern in /etc/group. That should work as well. Do you prefer either one? Thanks, -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#844339: [Pkg-libvirt-maintainers] Bug#844339: patch for sid
Hi Guido, Thanks for the review. On 11/14/2016 03:54 PM, Guido Günther wrote: +# Allocated UID and GID for libvirt-qemu > +libvirt_qemu_uid=64055 > +libvirt_qemu_gid=64055 Please use all caps for the variable names. Okay; including the "parameter_(u|g)id" variables below. (like another function that uses all caps for variables in the function-scope that are not for-loops variables) > + # set uid if available (expected); don't fail otherwise. > + parameter_uid='' > + if ! getent passwd $libvirt_qemu_uid >/dev/null; then > + parameter_uid="--uid $libvirt_qemu_uid" > + fi i wonder if _silently_ ignoring uid because it's already taken is the right action. Did you check what other packages with reserved uids/gids do in this case? Nice catch. Looking at the list, the ones which still use the allocated uid/gid (grep'ing for adduser, addgroup, uid, gid) - netqmail and plan: abort the installation - linux-grsec-base: silently proceeds w/out groups (addgroup || true) We should at least put out a warning or fail (which might not be nice since the problem might not be easily solvable by the person installing the package e.g. if users come from LDAP). Sure. What do you think of a debconf warning message/prompt, which asks the user to confirm that it's OK not to use the uid/gid values, and explains about the potential problem w/ guest migration over NFS? cheers, -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#844339: patch for sid
Patch attached now.
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru libvirt-2.3.0/debian/changelog libvirt-2.3.0/debian/changelog
--- libvirt-2.3.0/debian/changelog 2016-10-16 10:14:45.0 -0400
+++ libvirt-2.3.0/debian/changelog 2016-10-28 07:21:00.0 -0400
@@ -1,3 +1,10 @@
+libvirt (2.4.0-1uidgid1) UNRELEASED; urgency=medium
+
+ * debian/libvirt-daemon-system.postinst: set libvirt-qemu UID/GID
+if available; don't fail otherwise. (Closes: #)
+
+ -- Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com> Wed, 26 Oct 2016
11:05:38 -0200
+
libvirt (2.4.0-1) unstable; urgency=medium
* [abba3b7] New upstream version 2.4.0
diff -Nru libvirt-2.3.0/debian/libvirt-daemon-system.postinst
libvirt-2.3.0/debian/libvirt-daemon-system.postinst
--- libvirt-2.3.0/debian/libvirt-daemon-system.postinst 2016-09-29
03:25:56.0 -0400
+++ libvirt-2.3.0/debian/libvirt-daemon-system.postinst 2016-10-28
07:21:00.0 -0400
@@ -17,6 +17,10 @@
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package
+# Allocated UID and GID for libvirt-qemu
+libvirt_qemu_uid=64055
+libvirt_qemu_gid=64055
+
add_users_groups()
{
if ! getent group libvirt >/dev/null; then
@@ -28,6 +32,13 @@
fi
# user and group libvirt runs qemu/kvm instances with
if ! getent passwd libvirt-qemu >/dev/null; then
+
+ # set uid if available (expected); don't fail otherwise.
+ parameter_uid=''
+ if ! getent passwd $libvirt_qemu_uid >/dev/null; then
+ parameter_uid="--uid $libvirt_qemu_uid"
+ fi
+
adduser --quiet \
--system \
--ingroup kvm \
@@ -37,10 +48,18 @@
--home /var/lib/libvirt \
--no-create-home \
--gecos "Libvirt Qemu" \
+$parameter_uid \
libvirt-qemu
fi
if ! getent group libvirt-qemu >/dev/null; then
-addgroup --quiet --system libvirt-qemu
+
+ # set gid if available (expected); don't fail otherwise.
+ parameter_gid=''
+ if ! getent group $libvirt_qemu_gid >/dev/null; then
+ parameter_gid="--gid $libvirt_qemu_gid"
+ fi
+
+addgroup --quiet --system $parameter_gid libvirt-qemu
adduser libvirt-qemu libvirt-qemu
fi
}
Bug#844339: libvirt: use allocated uid/gid for libvirt-qemu
Package: libvirt-daemon-system Version: 2.4.0-1 Tags: patch During guest migration over NFS, I/O errors might happen in the guest if the disk image files are owned by different uid/gid in the 2 hosts. This problem is described in more detail in LP #1637601. This patch assigns the uid/gid allocated in #843881 for libvirt-qemu if the user/group does not exist yet, in order to avoid that problem. Thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#843881: request uid and gid allocation for libvirt-qemu
On 11/11/2016 07:44 PM, Colin Watson wrote: You can go ahead and make use of this immediately in Debian/Ubuntu. Okay; thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#843881: request uid and gid allocation for libvirt-qemu
Package: base-passwd Version: 3.5.40 X-Debbugs-CC: pkg-libvirt-maintain...@lists.alioth.debian.org Hi, I'd like to request an uid and gid for the libvirt-qemu user/group. This is in support of guest migration with disk images over NFS. That requires the same uid/gid on source and target host systems, otherwise IO requests for disk images (owned by libvirt-qemu) fail with -EACCES, which causes IO errors in a guest undergoing migration. The patches for libvirt will be submitted if the allocation is granted. (patches for sid & Ubuntu currently attached in Launchpad bug #1637601) According to 'base-passwd/README', this message has also been directly sent to base-passwd@p.d.o (as follows). This bug report is for tracking purposes, if that helps. > You *may not* use any uids or gids in the 6-64999 range without > *first* requesting an allocation from base-pas...@packages.debian.org > and waiting for confirmation that the allocation has been granted. Thank you, -- Mauricio Faria de Oliveira IBM Linux Technology Center
Bug#782400: multipath-tools: libmultipath: fix discovery of devices with empty rev sysfs attribute
Hi Ritesh, On 08/10/2015 09:04 AM, Ritesh Raj Sarraf wrote: I'll look into this soon. But lowering the severity because, from the description, it is again specific to one family of controllers. This week, I intend to work on both the patches. Sure, thanks. BTW, Hannes authored himself a patch like the one proposed [1], but it seems not posted to dm-devel (I didn't notice it earlier). I'd expect this to give some reassurance that something like it is more likely to go upstream. :) Regards, [1] https://github.com/hreinecke/multipath-tools/commit/beb31f5c63a7414db393fca31fc9de7a44c6 -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752891: systemtap: build on ppc64el
Hi Vincent, On 07/31/2015 02:59 PM, Vincent Bernat wrote: Is there some change on this issue? Would ppc64el works out of the box with systemtap 2.8 and the current userland in sid? I'm not sure - I couldn't work further on this. Currently, Fernando (CC) may have a better understanding on the topic. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782400: multipath-tools: libmultipath: fix discovery of devices with empty rev sysfs attribute
Hi Ritesh, On 06/21/2015 06:16 AM, Ritesh Raj Sarraf wrote: Given that mulitpath doesn't do a release very often, I plan on rebasing on the latest git repo (which includes many of Hannes' fixes). They only reason I'm procrastinating is because neither of our patches have been accepted/pushed by Christoph. BTW, Christophe recently mentioned release plans on the mailing list ([dm-devel] Next release plans?), catching up with inbox around the summer holidays, but I don't know which timeframe that actually is. Maybe those patches get in too. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787666: multipath-tools: discussion about devname of mpath[0-9]+ vs. mpath[a-z]+
Control: notfound -1 multipath-tools/0.5.0-7 Control: found -1 multipath-tools/0.4.9-3 Control: fixed -1 multipath-tools/0.4.9+git0.4dfdaf2b-1 Control: close -1 Ritesh, On 06/09/2015 07:41 AM, Ritesh Raj Sarraf wrote: Regarding the option for Debian to stay on devnames like mpath[0-9]+ rather than that adopted upstream, mpath[a-z]+ (patch 0002).. snip By 0002, you mean debian/patches/0002-Make-user_friendly_names-compatible-to-multipath-too.patch ??? That patch is no more in use. It was dropped long ago. Oops; sorry, I didn't check it correctly. I mistakenly checked 0.4.9-3, where Ubuntu branched off some years ago. I see the patch was dropped a few months later. Apologies. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787666: multipath-tools: discussion about devname of mpath[0-9]+ vs. mpath[a-z]+
Package: src:multipath-tools Version: 0.5.0-7 Severity: wishlist Hi Ritesh, Regarding the option for Debian to stay on devnames like mpath[0-9]+ rather than that adopted upstream, mpath[a-z]+ (patch 0002).. Do you mind explaining to me if there's any particular reasons for that? Or how (un)likely is it to switch over to upstream? (I'd know of one point, that is Jessie using the old number-suffix). Another point is, if that doesn't change, is it possible in the mean time to move patch 0002 to the end of the series, and add support for alias_prefix [1], so to ease the addition of upstream/backport patches (i.e., before the last patch in the series)? Thanks! [1] Add alias_prefix to get multipath names based on storage type commit b36393b528a28ea2f0777caabc28cf61ded27a13 -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782400: multipath-tools: libmultipath: fix discovery of devices with empty rev sysfs attribute
On Thu, 2015-05-28 at 12:21 +0530, Ritesh Raj Sarraf wrote: No. It has nothing to do with the patch. These days I don't work on storage, i.e. don't have a team that spends the time on these tools. So I keep the upstream first policy, for now. Even my patch (kpartx) is very trivial but 've put it on hold until Christoph accepts it. If this really doesn't work in the long run, we may re-visit it. Ok, got it. Thanks for clarifying, I had misunderstood that. Regards, Mauricio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782400: multipath-tools: libmultipath: fix discovery of devices with empty rev sysfs attribute
Hi Ritesh, On Wed, 2015-05-27 at 23:40 +0530, Ritesh Raj Sarraf wrote: OKay!! THanks. I'll put this one on hold then. The other one, is already ready for Unstable. And as I write, I'm also preparing the same for Jessie+U1. Thanks! Do you think it would be a problem to include the patch? As explained the commit message, I think it's an obvious fix for the regression introduced (with 'chomp', or similar name) for the case when the sysfs attribute 'rev' contains only spaces -- because the 'chomp' (or similarly named) function will remove all spaces from the string, so its size will be zero (so, the check for size greater than, but not 'or equal to', will surely fail). Kind regards, Mauricio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782487: sg3-utils: provide udev rules for multipath-tools [PATCH v2]
On 05/13/2015 08:54 AM, Ritesh Raj Sarraf wrote: So something in between 1.39..1.40 has changed. I can't see much on the packaging side. So it is either upstream's build, or else our toolchain. Unfortunately, I haven't been able to root cause it. So this will have to wait until I look at it again. Ok, thank you. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782487: sg3-utils: provide udev rules for multipath-tools [PATCH v2]
Hi Ritesh, On 05/12/2015 07:28 AM, Ritesh Raj Sarraf wrote: On Tuesday 12 May 2015 03:52 PM, Ritesh Raj Sarraf wrote: Didn't build proper. These are arch dependent packages and their libraries / binaries vanished. THis has nothing to do with you patches. Looks like something got broken in the build environment with 1.40. Nice. I was wondering what could have gone wrong, as it built alright on my test (dpkg-buildpackage) before submitting it. On 05/12/2015 06:31 AM, Ritesh Raj Sarraf wrote: Should we add this as a Recommends for multipath-tools ? Hm. I think so, but perhaps as Depends? (reasoning below) :) Well, unfortunately I don't have a system now to test the following on, but I believe even when not booting from multipath disks, one will need the sg3-utils udev rules to export the SCSI_IDENT udev properties too.. so the disks can be discovered by multipath. I guess the other udev property (ID_WWN) is set automatically from disks from storage systems/fibrechannel, but that's not the case for local/SAS disks, for example (which need the SCSI_IDENT ones). So, to cover all cases, I believe multipath-tools should bring the new sg3-utils-udev package w/ udev rules in, I'm just not sure with which requirement (either Depends or Recommends). Do you have an opinion on that? (I'm new to the multipath world). I may be able to check that scenario in some time. Thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782487: sg3-utils: provide udev rules for multipath-tools [PATCH v2]
Package: src:sg3-utils
Hi Ritesh,
Please consider this patch instead.
I noticed the previous one has bug in the initramfs hook.
If there's nothing in initramfs's /usr/bin, sg_inq is copied
as /usr/bin (file), rather than /usr/bin/sq_inq;
This breaks multipath discovery because the ID_SCSI udev properties
(from sg_inq --export) doesn't show up.
$ interdiff sg3-utils_udev-rules.debdiff sg3-utils_udev-rules_v2.debdiff
[snip]
@@ -27,7 +27,7 @@
done
}
-copy_exec /usr/bin/sg_inq /usr/bin
+copy_exec /usr/bin/sg_inq
add_udev_rules
Thanks!
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru sg3-utils-1.39/debian/changelog sg3-utils-1.39/debian/changelog
--- sg3-utils-1.39/debian/changelog 2014-09-29 05:01:40.0 -0300
+++ sg3-utils-1.39/debian/changelog 2015-04-12 19:49:18.0 -0300
@@ -1,3 +1,14 @@
+sg3-utils (1.39-1udevrules1) UNRELEASED; urgency=medium
+
+ * sg3-utils-udev (new binary package): provide the udev rules for SCSI-ID
+mappings and symlinks at boot time for multipath-tools:
+- debian/control: add sg3-utils-udev
+- debian/rules: build it with override_dh_{install,clean}
+- debian/initramfs/hooks: add_udev_rules() and copy_exec() 'sg_inq' to
initramfs
+- debian/sg3-utils-udev.post{inst,rm}: call update-initramfs
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Sun, 12 Apr 2015
19:22:02 -0300
+
sg3-utils (1.39-1) unstable; urgency=medium
* [a3a22b2] Imported Upstream version 1.39
diff -Nru sg3-utils-1.39/debian/control sg3-utils-1.39/debian/control
--- sg3-utils-1.39/debian/control 2014-04-03 03:37:10.0 -0300
+++ sg3-utils-1.39/debian/control 2015-04-12 19:21:27.0 -0300
@@ -62,3 +62,18 @@
Developer files (i.e. headers and a static library) which are associated with
the utilities in the sg3-utils package.
+Package: sg3-utils-udev
+Architecture: all
+Depends: sg3-utils, initramfs-tools
+Description: utilities for devices using the SCSI command set (udev rules)
+ Most OSes have SCSI pass-through interfaces that enable user space programs
+ to send SCSI commands to a device and fetch the response. With SCSI to ATA
+ Translation (SAT) many ATA disks now can process SCSI commands. Typically
+ each utility in this package implements one SCSI command. See the draft
+ standards at www.t10.org for SCSI command definitions plus SAT. ATA
+ commands are defined in the draft standards at www.t13.org . For a mapping
+ between supported SCSI and ATA commands and utility names in this package
+ see the COVERAGE file.
+ .
+ udev rules which are associated with the utilities in the sg3-utils package.
+
diff -Nru sg3-utils-1.39/debian/initramfs/hooks
sg3-utils-1.39/debian/initramfs/hooks
--- sg3-utils-1.39/debian/initramfs/hooks 1969-12-31 21:00:00.0
-0300
+++ sg3-utils-1.39/debian/initramfs/hooks 2015-04-12 19:21:27.0
-0300
@@ -0,0 +1,33 @@
+#!/bin/sh
+# (based on multipath-tools-boot)
+
+PREREQS=udev
+
+prereqs() { echo $PREREQS; }
+
+case $1 in
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+if [ ! -x /usr/bin/sg_inq ]; then
+ exit 0
+fi
+
+. /usr/share/initramfs-tools/hook-functions
+
+add_udev_rules()
+{
+ for rules in 55-scsi-sg3_id.rules 58-scsi-sg3_symlink.rules; do
+if [ -e /lib/udev/rules.d/$rules ]; then
+ cp -p /lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/
+fi
+ done
+}
+
+copy_exec /usr/bin/sg_inq
+
+add_udev_rules
+
diff -Nru sg3-utils-1.39/debian/rules sg3-utils-1.39/debian/rules
--- sg3-utils-1.39/debian/rules 2014-04-03 03:37:10.0 -0300
+++ sg3-utils-1.39/debian/rules 2015-04-12 19:21:27.0 -0300
@@ -16,10 +16,32 @@
DEB_HOST_ARCH_OS := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS 2/dev/null)
PKG_VERS=$(shell dpkg-parsechangelog | sed -rne 's,^Version: ([^-]+).*,\1,p')
+INITRAMFS=$(CURDIR)/debian/sg3-utils-udev/usr/share/initramfs-tools/
+
get-orig-source:
uscan --force-download --rename --repack --download-version=$(PKG_VERS)
--destdir=.
%:
dh $@ --with autoreconf
+override_dh_install:
+ dh_testdir
+ dh_install
+
+ [ ! -f scripts/55-scsi-sg3_id.rules ] || cp
scripts/55-scsi-sg3_id.rules debian/sg3-utils-udev.scsi-sg3_id.udev
+ [ ! -f scripts/58-scsi-sg3_symlink.rules ] || cp
scripts/58-scsi-sg3_symlink.rules debian/sg3-utils-udev.scsi-sg3_symlink.udev
+
+ dh_installudev -psg3-utils-udev --priority=55 --name=scsi-sg3_id
+ dh_installudev -psg3-utils-udev --priority=58 --name=scsi-sg3_symlink
+
+ install -D -m 755 debian/initramfs/hooks $(INITRAMFS)/hooks/sg3-utils
+
+override_dh_clean:
+ dh_testdir
+
+ rm -f debian/sg3-utils-udev.scsi-sg3_id.udev
+ rm -f debian/sg3-utils-udev.scsi-sg3_symlink.udev
+
+ dh_clean
+
.PHONY: get-orig-source
diff -Nru sg3-utils-1.39/debian/sg3-utils-udev.postinst
sg3-utils-1.39/debian
Bug#782363: multipath-tools-boot: include dm-service-time in initramfs (new default path selector)
Hi Ritesh, On 04/21/2015 10:14 AM, Ritesh Raj Sarraf wrote: On Saturday 11 April 2015 04:29 AM, Mauricio Faria de Oliveira wrote: May you please consider the attached patch for an upload for jessie? Sorry. I haven't been on top of it. I'll push it for unstable for now. Later we'll do an s-p-u and propose it for jessie. Great, thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782400: multipath-tools: libmultipath: fix discovery of devices with empty rev sysfs attribute
Hey Ritesh, On 04/21/2015 10:23 AM, Ritesh Raj Sarraf wrote: Is this been merged upstream ? No, I haven't seen any reply to it on dm-devel nor commits. I have the impression there's some delay between those 2 points. I just pinged Hannes on the mailing list, in case he has some time to check/acknowledge it, so we may have an idea if that's eventually going upstream or requires more changes, before including in Debian. Thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782487: sg3-utils: provide udev rules for multipath-tools
Hi Ritesh, On 04/21/2015 02:34 PM, Ritesh Raj Sarraf wrote: On Thursday 16 April 2015 07:56 PM, Serge Cohen wrote: Is it possible to raise the severity level of this bug to make it RC, and is there a chance that both bugs (782487 and 782488) are solved before the release so that the installation on systems relying on multipath would not require workaround to be functional ? Thanks for reporting the issue. But at this time, this will not make into Jessie. Yeah, that's certainly understandable.. specially* with a release date this Saturday. :-) I usually mention/ask for upload to Jessie just to signal the intention to put it in the stable release (similarly to CC:sta...@vger.kernel.org in LKML), although I sure enough understand and expect some constraints (e.g., personal time, testing time, feasibility etc.) to sometimes make things not the way some users want, but the way a majority of users may benefit more, by at least following the right Debian process. This is one gripe I have with Debian Enterprise users. I always get bug reports at the very last minute. ... Ugh, yeah. I notice that too and feel unfortunate to be in that position this time. It's really unfortunate timing in this occasion; something I, personally, work to improve where I can, but sometimes, sadly, it still happens. ... What most users don't realize is that many of us Debian Developers are really pure volunteers. :-) We aren't paid by anyone to work on it, thus the commitment and reaction to a bug report heavily depends on when I have the time. For sure. Again, thanks a bunch for really looking at the patches/emails I have been bugging (literally) you with. :) It's not always that way in other packages/scenarios, and even non-volunteers (for workload or other reasons). Anyways... I'll be looking into packaging 1.40 soon. I don't like the idea to introduce a new package, but then let me check first. Thanks. If that helps, the rationale I adopted to decide to split the udev rules out in a new package is a conservative one, based on these ideas: - People that are used to install sg-utils just to get its binaries, so will, rather than all of sudden have new udev rules/attributes for their disks and a mysterious initramfs-update for no apparent/required reason. - If there's no requirement for those udev rules until now, there isn't. So, just put it in a small package that provides them, and let reverse- dependencies exist where they are actually required. - I also thought of following the existing convention of -boot suffix (e.g., multipath-tools, kpartx) when there are changes to the initramfs, but for some reason I preferred the -udev suffix, perhaps because that's clear enough, but I don't recall right now :) @Mauricio: Again, thank you. Your reports and patches are really helpful to me. Always glad to contribute, Ritesh. Again, thank you for your time and effort on multipath-tools et al. :) Best regards, -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782400: multipath-tools: libmultipath: fix discovery of devices with empty rev sysfs attribute
Oops, please use this version (-v2).
When the forwarded patch is applied in the source package, the change
ends up in cciss_sysfs_pathinfo() rather than scsi_sysfs_pathinfo():
Hunk #1 succeeded at 783 (offset -312 lines).
This version has the change in the right place, plus quilt refresh.
Thanks!
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru multipath-tools-0.5.0/debian/changelog
multipath-tools-0.5.0/debian/changelog
--- multipath-tools-0.5.0/debian/changelog 2015-04-13 05:26:21.0
+0530
+++ multipath-tools-0.5.0/debian/changelog 2015-04-13 05:30:14.0
+0530
@@ -1,3 +1,9 @@
+multipath-tools (0.5.0-6pathselector1blankrev1) UNRELEASED; urgency=medium
+
+ * 0014-libmultipath-discovery-blank-rev-attr.patch: fix discovery of devices
with blank rev.
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Sat, 11 Apr 2015
12:40:19 -0300
+
multipath-tools (0.5.0-6pathselector1) UNRELEASED; urgency=medium
* initramfs/hooks: include dm-service-time in initramfs (new default path
selector).
diff -Nru
multipath-tools-0.5.0/debian/patches/0014-libmultipath-discovery-blank-rev-attr.patch
multipath-tools-0.5.0/debian/patches/0014-libmultipath-discovery-blank-rev-attr.patch
---
multipath-tools-0.5.0/debian/patches/0014-libmultipath-discovery-blank-rev-attr.patch
1970-01-01 05:30:00.0 +0530
+++
multipath-tools-0.5.0/debian/patches/0014-libmultipath-discovery-blank-rev-attr.patch
2015-04-13 05:31:34.0 +0530
@@ -0,0 +1,37 @@
+Forwarded: https://www.redhat.com/archives/dm-devel/2015-April/msg00049.html
+From b7ec63e727880aa709c2aa7b6029dba9ad7d9d74 Mon Sep 17 00:00:00 2001
+From: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com
+Date: Sat, 11 Apr 2015 12:02:29 -0300
+Subject: [PATCH] libmultipath: fix discovery of devices with sysfs attr
containing only spaces
+
+commit 43c61e979521b17d9f50ea8e722682c33d0b7d69 causes sysfs_get_attr() to
+return 0 if attr contains only spaces, and scsi_sysfs_pathinfo() to return 1
+in 'if (sysfs_get_attr() = 0)'; this breaks the device's discovery.
+
+Changing the comparison operator '=' to '' allows discovery to continue.
+
+This affects some IPR controllers (rev sysfs attr):
+
+ # grep . /sys/block/sda/device/{vendor,model,rev} | tr ' ' '#'
+ /sys/block/sda/device/vendor:IBM#
+ /sys/block/sda/device/model:IPR-0###5EC99A00
+ /sys/block/sda/device/rev:
+
+Signed-off-by: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com
+---
+ libmultipath/discovery.c |2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+Index: multipath-tools-0.5.0/libmultipath/discovery.c
+===
+--- multipath-tools-0.5.0.orig/libmultipath/discovery.c
multipath-tools-0.5.0/libmultipath/discovery.c
+@@ -661,7 +661,7 @@ scsi_sysfs_pathinfo (struct path * pp)
+
+ condlog(3, %s: product = %s, pp-dev, pp-product_id);
+
+- if (sysfs_get_rev(parent, pp-rev, SCSI_REV_SIZE) = 0)
++ if (sysfs_get_rev(parent, pp-rev, SCSI_REV_SIZE) 0)
+ return 1;
+
+ condlog(3, %s: rev = %s, pp-dev, pp-rev);
diff -Nru multipath-tools-0.5.0/debian/patches/series
multipath-tools-0.5.0/debian/patches/series
--- multipath-tools-0.5.0/debian/patches/series 2014-09-05 17:42:48.0
+0530
+++ multipath-tools-0.5.0/debian/patches/series 2015-04-13 05:30:14.0
+0530
@@ -4,3 +4,4 @@
0011-patch-udev-rule.patch
0012-format-security-build-fixes.patch
0013-fix-spelling-error.patch
+0014-libmultipath-discovery-blank-rev-attr.patch
Bug#782487: sg3-utils: provide udev rules for multipath-tools
Package: src:sg3-utils
Version: 1.39-1
Tags: patch
Hi Ritesh,
This patch creates the binary package sg3-utils-udev, which installs
the upstream udev rules in the initramfs, so SCSI_IDENT_* properties
are defined for multipath-tools/-boot to correctly whitelist sd devs.
May you please consider it for an upload to jessie?
Thanks!
Details:
---
Package and installed/initramfs files:
# dpkg-deb -c sg3-utils-udev_1.39-1udevrules1_all.deb
drwxr-xr-x root/root 0 2015-04-13 04:32 ./
drwxr-xr-x root/root 0 2015-04-13 04:31 ./usr/
drwxr-xr-x root/root 0 2015-04-13 04:31 ./usr/share/
drwxr-xr-x root/root 0 2015-04-13 04:31
./usr/share/initramfs-tools/
drwxr-xr-x root/root 0 2015-04-13 04:31
./usr/share/initramfs-tools/hooks/
-rwxr-xr-x root/root 485 2015-04-13 04:31
./usr/share/initramfs-tools/hooks/sg3-utils
drwxr-xr-x root/root 0 2015-04-13 04:31 ./usr/share/doc/
drwxr-xr-x root/root 0 2015-04-13 04:31
./usr/share/doc/sg3-utils-udev/
-rw-r--r-- root/root 3907 2015-04-13 04:19
./usr/share/doc/sg3-utils-udev/changelog.Debian.gz
-rw-r--r-- root/root 2804 2014-04-03 12:07
./usr/share/doc/sg3-utils-udev/copyright
-rw-r--r-- root/root 21142 2014-06-12 19:05
./usr/share/doc/sg3-utils-udev/changelog.gz
drwxr-xr-x root/root 0 2015-04-13 04:31 ./lib/
drwxr-xr-x root/root 0 2015-04-13 04:31 ./lib/udev/
drwxr-xr-x root/root 0 2015-04-13 04:31 ./lib/udev/rules.d/
-rw-r--r-- root/root 1878 2015-04-13 04:31
./lib/udev/rules.d/58-scsi-sg3_symlink.rules
-rw-r--r-- root/root 2468 2015-04-13 04:31
./lib/udev/rules.d/55-scsi-sg3_id.rules
# dpkg -i
{sg3-utils-udev,sg3-utils,libsgutils2-2}_1.39-1udevrules1_*.deb
...
Setting up sg3-utils-udev (1.39-1udevrules1) ...
update-initramfs: deferring update (trigger activated)
...
Processing triggers for initramfs-tools (0.119) ...
update-initramfs: Generating /boot/initrd.img-3.19.0-trunk-powerpc64le
...
# gzip -dc /boot/initrd.img | cpio -t | grep sg
118989 blocks
bin/dmesg
usr/bin/sg_inq
usr/lib/libsgutils2.so.2
lib/modules/3.19.0-trunk-powerpc64le/kernel/drivers/scsi/sg.ko
lib/udev/rules.d/58-scsi-sg3_symlink.rules
lib/udev/rules.d/55-scsi-sg3_id.rules
# ls -l /lib/udev/rules.d/*scsi-sg3*.rules
-rw-r--r-- 1 root root 2468 Apr 12 19:50
/lib/udev/rules.d/55-scsi-sg3_id.rules
-rw-r--r-- 1 root root 1878 Apr 12 19:50
/lib/udev/rules.d/58-scsi-sg3_symlink.rules
After reboot (i.e., udev changes active), the SCSI/SCSI_IDENT properties
are defined:
# udevadm info -q property /dev/sda
DEVLINKS=/dev/disk/by-id/scsi-0IBM_IPR-0_5EC99A00_0
/dev/disk/by-id/scsi-1IBM_IPR-0_5EC99A000430
/dev/disk/by-path/pci-0001:08:00.0-scsi-0:2:3:0
DEVNAME=/dev/sda
DEVPATH=/devices/pci0001:00/0001:00:00.0/0001:01:00.0/0001:02:08.0/0001:08:00.0/host0/target0:2:3/0:2:3:0/block/sda
DEVTYPE=disk
ID_BUS=scsi
ID_MODEL=IPR-0_5EC99A00
ID_MODEL_ENC=IPR-0\x20\x20\x205EC99A00
ID_PATH=pci-0001:08:00.0-scsi-0:2:3:0
ID_PATH_TAG=pci-0001_08_00_0-scsi-0_2_3_0
ID_SCSI=1
ID_SERIAL=1IBM_IPR-0_5EC99A000430
ID_SERIAL_SHORT=IBM_IPR-0_5EC99A000430
ID_TYPE=disk
ID_VENDOR=IBM
ID_VENDOR_ENC=IBM\x20\x20\x20\x20\x20
MAJOR=8
MINOR=0
SCSI_IDENT_LUN_T10=IBM_IPR-0_5EC99A000430
SCSI_IDENT_LUN_VENDOR=0
SCSI_IDENT_PORT_RELATIVE=53722
SCSI_IDENT_PORT_TARGET_PORT_GROUP=0xd1da
SCSI_MODEL=IPR-0_5EC99A00
SCSI_MODEL_ENC=IPR-0\x20\x20\x205EC99A00
SCSI_TPGS=1
SCSI_TYPE=disk
SCSI_VENDOR=IBM
SCSI_VENDOR_ENC=IBM\x20\x20\x20\x20\x20
SUBSYSTEM=block
USEC_INITIALIZED=94634646
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru sg3-utils-1.39/debian/changelog sg3-utils-1.39/debian/changelog
--- sg3-utils-1.39/debian/changelog 2014-09-29 05:01:40.0 -0300
+++ sg3-utils-1.39/debian/changelog 2015-04-12 19:49:18.0 -0300
@@ -1,3 +1,14 @@
+sg3-utils (1.39-1udevrules1) UNRELEASED; urgency=medium
+
+ * sg3-utils-udev (new binary package): provide the udev rules for SCSI-ID
+mappings and symlinks at boot time for multipath-tools:
+- debian/control: add sg3-utils-udev
+- debian/rules: build it with override_dh_{install,clean}
+- debian/initramfs/hooks: add_udev_rules() and copy_exec() 'sg_inq' to
initramfs
+- debian/sg3-utils-udev.post{inst,rm}: call update-initramfs
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Sun, 12 Apr 2015
19:22:02 -0300
+
sg3-utils (1.39-1) unstable; urgency=medium
* [a3a22b2] Imported Upstream version 1.39
diff -Nru sg3-utils-1.39/debian/control sg3-utils-1.39/debian
Bug#782488: multipath-tools: updates for compatibility with property blacklist
Package: src:multipath-tools
Version: 0.5.0-6
Severity: serious
Tags: patch
Hi Ritesh,
multipath-tools 0.5.0 contains commit multipath: Implement 'property'
blacklist, which started to blacklist devices that don't have any of
the whitelisted udev properties - initially, ID_WWN or ID_SCSI_VPD.
AFAICT, neither is set by udev rules installed by default in Debian,
rendering any SCSI disk blacklisted.
After 0.5.0, commit Use 'SCSI_IDENT_.*' as the default property
whitelist changed that to SCSI_IDENT_.* or ID_WWN.
The SCSI_IDENT_* attributes are defined by sg3-utils's udev rules,
but the current sg3-utils package doesn't install them.
I submitted a patch in #782487 that creates sg3-utils-udev to install
them, and to put them plus dependencies in the initramfs, as properties
must be defined on disk detection (even for non'-boot' multipath-tools).
With that patch for sg3-utils and the attached patch, the SCSI devices
are not anymore blacklisted by default.
May you please consider them for an upload to jessie? Thanks!
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru multipath-tools-0.5.0/debian/changelog
multipath-tools-0.5.0/debian/changelog
--- multipath-tools-0.5.0/debian/changelog 2015-04-13 05:30:14.0
+0530
+++ multipath-tools-0.5.0/debian/changelog 2015-04-13 05:43:44.0
+0530
@@ -1,3 +1,11 @@
+multipath-tools (0.5.0-6pathselector1blankrev1property1) UNRELEASED;
urgency=medium
+
+ * Updates for compatibility with commit multipath: Implement 'property'
blacklist.
+- debian/control: multipath-tools: add dependency on sg3-utils-udev
+- debian/patches/0015-libmultipath-property-whitelist-SCSI_IDENT.patch
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Sun, 12 Apr 2015
19:18:01 -0300
+
multipath-tools (0.5.0-6pathselector1blankrev1) UNRELEASED; urgency=medium
* 0014-libmultipath-discovery-blank-rev-attr.patch: fix discovery of devices
with blank rev.
diff -Nru multipath-tools-0.5.0/debian/control
multipath-tools-0.5.0/debian/control
--- multipath-tools-0.5.0/debian/control2014-09-06 15:22:50.0
+0530
+++ multipath-tools-0.5.0/debian/control2015-04-13 05:43:44.0
+0530
@@ -12,7 +12,7 @@
Package: multipath-tools
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, udev (= 0.124), initscripts (=
2.85-16),
- kpartx (= ${binary:Version}), lsb-base (= 3), libaio1 (= 0.3.106-8)
+ kpartx (= ${binary:Version}), lsb-base (= 3), libaio1 (= 0.3.106-8),
sg3-utils-udev
Breaks: multipath-tools-initramfs (= 1.0.1),
multipath-tools-boot (= 0.4.8+git0.761c66f-2~)
Suggests: multipath-tools-boot
diff -Nru
multipath-tools-0.5.0/debian/patches/0015-libmultipath-property-whitelist-SCSI_IDENT.patch
multipath-tools-0.5.0/debian/patches/0015-libmultipath-property-whitelist-SCSI_IDENT.patch
---
multipath-tools-0.5.0/debian/patches/0015-libmultipath-property-whitelist-SCSI_IDENT.patch
1970-01-01 05:30:00.0 +0530
+++
multipath-tools-0.5.0/debian/patches/0015-libmultipath-property-whitelist-SCSI_IDENT.patch
2015-04-13 05:43:44.0 +0530
@@ -0,0 +1,29 @@
+Origin:
http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=d041591e42b69e2ff99d9cc5cc83ccde3207
+From: Hannes Reinecke h...@suse.de
+Date: Thu, 10 Apr 2014 10:21:52 + (+0200)
+Subject: Use 'SCSI_IDENT_.*' as the default property whitelist
+X-Git-Url:
http://git.opensvc.com/gitweb.cgi?p=multipath-tools%2F.git;a=commitdiff_plain;h=d041591e42b69e2ff99d9cc5cc83ccde3207
+
+Use 'SCSI_IDENT_.*' as the default property whitelist
+
+59-scsi-sg_utils.rules export the VPD pages as
+SCSI_IDENT_association_type.
+So whenever we have a SCSI_IDENT_* property we know it
+has come from VPD pages and we have a legit device.
+
+Signed-off-by: Hannes Reinecke h...@suse.de
+---
+
+diff --git a/libmultipath/blacklist.c b/libmultipath/blacklist.c
+index cea128c..30c5031 100644
+--- a/libmultipath/blacklist.c
b/libmultipath/blacklist.c
+@@ -196,7 +196,7 @@ setup_default_blist (struct config * conf)
+ if (store_ble(conf-blist_devnode, str, ORIGIN_DEFAULT))
+ return 1;
+
+- str = STRDUP((ID_SCSI_VPD|ID_WWN));
++ str = STRDUP((SCSI_IDENT_.*|ID_WWN));
+ if (!str)
+ return 1;
+ if (store_ble(conf-elist_property, str, ORIGIN_DEFAULT))
diff -Nru multipath-tools-0.5.0/debian/patches/series
multipath-tools-0.5.0/debian/patches/series
--- multipath-tools-0.5.0/debian/patches/series 2015-04-13 05:30:14.0
+0530
+++ multipath-tools-0.5.0/debian/patches/series 2015-04-13 05:43:44.0
+0530
@@ -5,3 +5,4 @@
0012-format-security-build-fixes.patch
0013-fix-spelling-error.patch
0014-libmultipath-discovery-blank-rev-attr.patch
+0015-libmultipath-property-whitelist-SCSI_IDENT.patch
Bug#782488: multipath-tools: updates for compatibility with property blacklist
Details: --- Before patches: # multipath -v3 ... Apr 12 20:07:51 | sda: blacklisted, udev property missing Apr 12 20:07:51 | sdb: blacklisted, udev property missing Apr 12 20:07:51 | sdc: blacklisted, udev property missing Apr 12 20:07:51 | sdd: blacklisted, udev property missing Apr 12 20:07:51 | sde: blacklisted, udev property missing Apr 12 20:07:51 | sdf: blacklisted, udev property missing Apr 12 20:07:51 | sdg: blacklisted, udev property missing Apr 12 20:07:51 | sdh: blacklisted, udev property missing Apr 12 20:07:51 | sdi: blacklisted, udev property missing Apr 12 20:07:51 | sdj: blacklisted, udev property missing Apr 12 20:07:51 | sdk: blacklisted, udev property missing Apr 12 20:07:51 | sdl: blacklisted, udev property missing Apr 12 20:07:51 | dm-0: blacklisted, udev property missing Apr 12 20:07:51 | dm-1: blacklisted, udev property missing Apr 12 20:07:51 | dm-2: blacklisted, udev property missing Apr 12 20:07:51 | dm-3: blacklisted, udev property missing Apr 12 20:07:51 | dm-4: blacklisted, udev property missing Apr 12 20:07:51 | dm-5: blacklisted, udev property missing Apr 12 20:07:51 | dm-6: blacklisted, udev property missing Apr 12 20:07:51 | dm-7: blacklisted, udev property missing Apr 12 20:07:51 | dm-8: blacklisted, udev property missing = no paths = ... After patches + reboot: Apr 13 06:08:10 | sda: udev property SCSI_IDENT_LUN_T10 whitelisted Apr 13 06:08:10 | sda: not found in pathvec Apr 13 06:08:10 | sda: mask = 0x3f Apr 13 06:08:10 | sda: dev_t = 8:0 Apr 13 06:08:10 | sda: size = 554287104 Apr 13 06:08:10 | sda: vendor = IBM Apr 13 06:08:10 | sda: product = IPR-0 5EC99A00 Apr 13 06:08:10 | sda: rev = Apr 13 06:08:10 | sda: h:b:t:l = 0:2:3:0 Apr 13 06:08:10 | sda: path state = running Apr 13 06:08:10 | sda: 4252 cyl, 128 heads, 32 sectors/track, start at 0 Apr 13 06:08:10 | sda: serial = Apr 13 06:08:10 | sda: get_state Apr 13 06:08:10 | sda: path checker = tur (controller setting) Apr 13 06:08:10 | sda: checker timeout = 30 ms (internal default) Apr 13 06:08:10 | sda: state = up Apr 13 06:08:10 | sda: uid_attribute = ID_SERIAL (internal default) Apr 13 06:08:10 | sda: uid = 1IBM_IPR-0_5EC99A000430 (udev) Apr 13 06:08:10 | sda: detect_prio = 1 (config file default) Apr 13 06:08:10 | sda: prio = alua (controller setting) Apr 13 06:08:10 | sda: prio args = (null) (controller setting) Apr 13 06:08:10 | reported target port group is 53722 Apr 13 06:08:10 | aas = 80 [active/optimized] [preferred] Apr 13 06:08:10 | sda: alua prio = 50 ... = paths list = uuidhcildev dev_t pri dm_st chk_st vend/prod/rev 1IBM_IPR-0_5EC99A000410 0:2:0:0 sdb 8:16 50 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC99A0003F0 0:2:1:0 sdc 8:32 50 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC99A0003D0 0:2:2:0 sdd 8:48 50 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC99A000430 0:2:3:0 sda 8:0 50 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC94760 0:2:4:0 sde 8:64 50 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC94780 0:2:5:0 sdf 8:80 50 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC99A000410 1:2:0:0 sdg 8:96 10 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC99A0003F0 1:2:1:0 sdh 8:112 10 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC99A0003D0 1:2:2:0 sdi 8:128 10 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC99A000430 1:2:3:0 sdj 8:144 10 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC94760 1:2:4:0 sdk 8:160 10 undef ready IBM,IPR-0 5EC 1IBM_IPR-0_5EC94780 1:2:5:0 sdl 8:176 10 undef ready IBM,IPR-0 5EC multipath-tools-boot is functional (root fs on multipath disk): root@debian:~# df / Filesystem 1K-blocksUsed Available Use% Mounted on /dev/dm-5 261562524 4828280 243424548 2% / -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782400: multipath-tools: libmultipath: fix discovery of devices with empty rev sysfs attribute
Package: src:multipath-tools
Version: 0.5.0-6
Severity: serious
Tags: patch
Forwarded: https://www.redhat.com/archives/dm-devel/2015-April/msg00049.html
Hi Ritesh,
I noticed some IPR controllers with multipath support may have only
spaces in the rev sysfs attribute, which breaks a device's discovery
(example below got no paths at all).
May you please consider this (forwarded) patch for Jessie?
Thank you.
Example:
---
The disks in this IPR controller:
# grep . /sys/block/sda/device/{vendor,model,rev} | tr ' ' '#'
/sys/block/sda/device/vendor:IBM#
/sys/block/sda/device/model:IPR-0###5EC99A00
/sys/block/sda/device/rev:
All of them (6 disks, 2 paths per disk):
# grep . /sys/block/sd*/device/rev | tr ' ' '#'
/sys/block/sda/device/rev:
/sys/block/sdb/device/rev:
/sys/block/sdc/device/rev:
/sys/block/sdd/device/rev:
/sys/block/sde/device/rev:
/sys/block/sdf/device/rev:
/sys/block/sdg/device/rev:
/sys/block/sdh/device/rev:
/sys/block/sdi/device/rev:
/sys/block/sdj/device/rev:
/sys/block/sdk/device/rev:
/sys/block/sdl/device/rev:
Comparison of 'multipath -v3' without/with the patch
(notice 'no paths' vs. 'paths list')
# diff -u multipath-v3.no-timestamp.{old,new}
...
sda: vendor = IBM
sda: product = IPR-0 5EC99A00
+ sda: rev =
+ sda: h:b:t:l = 0:2:0:0
+ sda: tgt_node_name =
+ sda: path state = running
+ sda: 4252 cyl, 128 heads, 32 sectors/track, start at 0
...
+ sda: alua prio = 50
sdb: ...
...
-= no paths =
+= paths list =
+uuidhcildev dev_t pri dm_st chk_st
vend/prod/rev
+1IBM_IPR-0_5EC99A000410 0:2:0:0 sda 8:0 50 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC99A0003F0 0:2:1:0 sdb 8:16 50 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC99A0003D0 0:2:2:0 sdc 8:32 50 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC99A000430 0:2:3:0 sdd 8:48 50 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC94760 0:2:4:0 sde 8:64 50 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC94780 0:2:5:0 sdf 8:80 50 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC99A000410 1:2:0:0 sdg 8:96 10 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC99A0003F0 1:2:1:0 sdh 8:112 10 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC99A0003D0 1:2:2:0 sdi 8:128 10 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC94780 1:2:3:0 sdj 8:144 10 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC94760 1:2:4:0 sdk 8:160 10 undef ready
IBM,IPR-0 5EC
+1IBM_IPR-0_5EC99A000430 1:2:5:0 sdl 8:176 10 undef ready
IBM,IPR-0 5EC
...
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782400: multipath-tools: libmultipath: fix discovery of devices with empty rev sysfs attribute
On 04/11/2015 01:00 PM, Mauricio Faria de Oliveira wrote:
Tags: patch
It helps to attach the patch :)
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru multipath-tools-0.5.0/debian/changelog
multipath-tools-0.5.0/debian/changelog
--- multipath-tools-0.5.0/debian/changelog 2015-03-04 05:53:28.0
-0300
+++ multipath-tools-0.5.0/debian/changelog 2015-04-11 12:48:01.0
-0300
@@ -1,3 +1,9 @@
+multipath-tools (0.5.0-6pathselector1blankrev1) UNRELEASED; urgency=medium
+
+ * 0014-libmultipath-discovery-blank-rev-attr.patch: fix discovery of devices
with blank rev.
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Sat, 11 Apr 2015
12:40:19 -0300
+
multipath-tools (0.5.0-6pathselector1) UNRELEASED; urgency=medium
* initramfs/hooks: include dm-service-time in initramfs (new default path
selector).
diff -Nru
multipath-tools-0.5.0/debian/patches/0014-libmultipath-discovery-blank-rev-attr.patch
multipath-tools-0.5.0/debian/patches/0014-libmultipath-discovery-blank-rev-attr.patch
---
multipath-tools-0.5.0/debian/patches/0014-libmultipath-discovery-blank-rev-attr.patch
1969-12-31 21:00:00.0 -0300
+++
multipath-tools-0.5.0/debian/patches/0014-libmultipath-discovery-blank-rev-attr.patch
2015-04-11 12:48:06.0 -0300
@@ -0,0 +1,40 @@
+Forwarded: https://www.redhat.com/archives/dm-devel/2015-April/msg00049.html
+From b7ec63e727880aa709c2aa7b6029dba9ad7d9d74 Mon Sep 17 00:00:00 2001
+From: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com
+Date: Sat, 11 Apr 2015 12:02:29 -0300
+Subject: [PATCH] libmultipath: fix discovery of devices with sysfs attr
containing only spaces
+
+commit 43c61e979521b17d9f50ea8e722682c33d0b7d69 causes sysfs_get_attr() to
+return 0 if attr contains only spaces, and scsi_sysfs_pathinfo() to return 1
+in 'if (sysfs_get_attr() = 0)'; this breaks the device's discovery.
+
+Changing the comparison operator '=' to '' allows discovery to continue.
+
+This affects some IPR controllers (rev sysfs attr):
+
+ # grep . /sys/block/sda/device/{vendor,model,rev} | tr ' ' '#'
+ /sys/block/sda/device/vendor:IBM#
+ /sys/block/sda/device/model:IPR-0###5EC99A00
+ /sys/block/sda/device/rev:
+
+Signed-off-by: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com
+---
+ libmultipath/discovery.c |2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
+index 4582a20..dde57c0 100644
+--- a/libmultipath/discovery.c
b/libmultipath/discovery.c
+@@ -1095,7 +1095,7 @@ scsi_sysfs_pathinfo (struct path * pp)
+
+ condlog(3, %s: product = %s, pp-dev, pp-product_id);
+
+- if (sysfs_get_rev(parent, pp-rev, SCSI_REV_SIZE) = 0)
++ if (sysfs_get_rev(parent, pp-rev, SCSI_REV_SIZE) 0)
+ return 1;
+
+ condlog(3, %s: rev = %s, pp-dev, pp-rev);
+--
+1.7.1
+
diff -Nru multipath-tools-0.5.0/debian/patches/series
multipath-tools-0.5.0/debian/patches/series
--- multipath-tools-0.5.0/debian/patches/series 2014-09-05 09:12:48.0
-0300
+++ multipath-tools-0.5.0/debian/patches/series 2015-04-11 12:48:06.0
-0300
@@ -4,3 +4,4 @@
0011-patch-udev-rule.patch
0012-format-security-build-fixes.patch
0013-fix-spelling-error.patch
+0014-libmultipath-discovery-blank-rev-attr.patch
Bug#782363: multipath-tools: include dm-service-time in initramfs: patch attached
Control: tags -1 patch Oops, forgot the patch tag. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782363: multipath-tools-boot: include dm-service-time in initramfs (new default path selector)
Package: src:multipath-tools
Version: 0.5.0-6
Severity: serious
Hi Ritesh,
With the default path selector changing to dm-service-time [1], it's not
possible to boot from multipath currently, as it's not in the initramfs:
# multipath -v3
...
... | mpathg: assembled map [1 queue_if_no_path 1 alua 2 1 service-time
0 1 1 8:80 1 service-time 0 1 1 8:176 1]
... | mpathg: set ACT_CREATE (map does not exist)
[...] device-mapper: table: 254:0: multipath: unknown path selector type
...
May you please consider the attached patch for an upload for jessie?
# gzip -dc /boot/initrd.img | cpio -t | grep dm-service-time
118384 blocks
lib/modules/.../kernel/drivers/md/dm-service-time.ko
Thanks!
Links:
[1]
http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=c015b128103e7a6426d124a38cd679a181573b88
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru multipath-tools-0.5.0/debian/changelog
multipath-tools-0.5.0/debian/changelog
--- multipath-tools-0.5.0/debian/changelog 2015-03-04 05:53:28.0
-0300
+++ multipath-tools-0.5.0/debian/changelog 2015-04-10 14:57:34.0
-0300
@@ -1,3 +1,9 @@
+multipath-tools (0.5.0-6pathselector1) UNRELEASED; urgency=medium
+
+ * initramfs/hooks: include dm-service-time in initramfs (new default path
selector).
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Fri, 10 Apr 2015
14:51:30 -0300
+
multipath-tools (0.5.0-6) unstable; urgency=medium
[ Mauricio Faria de Oliveira ]
diff -Nru multipath-tools-0.5.0/debian/initramfs/hooks
multipath-tools-0.5.0/debian/initramfs/hooks
--- multipath-tools-0.5.0/debian/initramfs/hooks2014-09-05
06:12:29.0 -0300
+++ multipath-tools-0.5.0/debian/initramfs/hooks2015-04-10
14:50:53.0 -0300
@@ -48,7 +48,7 @@
[ -r /etc/multipath.conf ] cp /etc/multipath.conf $DESTDIR/etc/
add_bindings
-for x in dm-multipath dm-round-robin dm-emc; do
+for x in dm-multipath dm-service-time dm-round-robin dm-emc; do
manual_add_modules ${x}
done
Bug#779579: installer broken: multipath-udeb depends on non-existent libgcc1 udeb
On 03/04/2015 06:43 AM, Cyril Brulebois wrote: Mauricio Faria de Oliveiramauri...@linux.vnet.ibm.com (2015-03-03): (BTW, espeakup-udeb is broken too; that approach no longer works.) (JFTR: espeakup certainly runs properly in the netboot-gtk mini.iso when selecting speech synthesis.) Ah, thanks for clarifying. I didn't know of that context/option; sorry. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779579: installer broken: multipath-udeb depends on non-existent libgcc1 udeb
Hi Ritesh, On 03/04/2015 06:12 AM, Ritesh Raj Sarraf wrote: Thanks Mauricio. I've uploaded the package and raised an unblock request. Debian Bug #779701 Hopefully, this will be unblocked immediate. Thanks! I just tested the package in incoming.d.o and it's OK. If you or Cyril could please educate me: For it to reach the d-i Packages file (so it's available for installs), does it require a d-i rebuild, or it's an automatic process? (I'm unsure; there's no multipath-udeb listed in d-i build log.) -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779579: installer broken: multipath-udeb depends on non-existent libgcc1 udeb
On 03/04/2015 08:32 AM, Ritesh Raj Sarraf wrote: d-i images are built weekly. So, if the unblock goes through, it'll migrate into testing, and then the next d-i weekly snapshot should include it. Got it. Thanks. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779579: installer broken: multipath-udeb depends on non-existent libgcc1 udeb
On 03/04/2015 09:25 AM, Cyril Brulebois wrote: For udebs that aren't used during the debian-installer build process (as in: source package going through build.debian.org like other packages, or being built daily -- see d-i.debian.org), they're either fetch from the installation image (CD/DVD/USB flash drive etc.) or from the network. That's the case for multipath-udeb, so you won't need a d-i (re)build, just the propagation of the relevant package to testing, and a subsequent installation image build, e.g. a weekly installation image build, or a full release. Very educational. Thanks, Cyril. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779579: installer broken: multipath-udeb depends on non-existent libgcc1 udeb
Control: tags -1 patch
Hi Siresh,
On 03/03/2015 08:32 AM, Mauricio Faria de Oliveira wrote:
Sure, I can try and should send a patch soon.
I've modified the build-arch target to build multipath-udeb first,
and store its output in a different directory; and the install target
to use that dir only for dh_install of multipath-udeb.
May you please consider it for an upload?
The solution ended up being to statically link to libgcc. I implemented
Cyril's suggestion, adopted by espeakup-udeb, but unfortunately it didnt
remove the references to libgcc. (verified with objdump runtime test).
(BTW, espeakup-udeb is broken too; that approach no longer works.)
~ # anna-install espeakup-udeb
~ # espeakup
espeakup: error while loading shared libraries: libgcc_s.so.1: cannot
open shared object file: No such file or directory
With the patch applied, the multipath command runs fine:
~ # multipath -l
multipath: error while loading shared libraries: libgcc_s.so.1: cannot
open shared object file: No such file or directory
~ # udpkg -i multipath-udeb_0.5.0-5mauricfo1_ppc64el.udeb
(Reading database...)
(Updating database...)
~ # multipath -l
~ # echo $?
0
Here's a check that changes are contained in the multipath-udeb package.
The references to libgcc are gone, only libpthread remains (which is OK,
as it exists in the installer). The nm/sed tests are based on Cyril's
earlier statement (thanks).
udeb (no libgcc):
$ dpkg-deb -x multipath-udeb_0.5.0-5mauricfo1_ppc64el.udeb lib-udeb
$ objdump -x lib-udeb/lib/libmultipath.so.0 | grep libgcc
$ { nm -D lib-udeb/lib/libmultipath.so.0 | sed -n 's,^.*U ,,p'; nm -D
/lib/powerpc64le-linux-gnu/libgcc_s.so.1 | sed -n 's,.*[^U] ,,p'; } |
sort | uniq -d
pthread_mutex_lock
pthread_mutex_unlock
~ # find /lib -name 'libpthread*'
/lib/libpthread.so.0
/lib/libpthread-2.19.so
deb (no change; still references libgcc)
$ dpkg-deb -x multipath-tools_0.5.0-5mauricfo1_ppc64el.deb lib-deb
$ objdump -x lib-deb/lib/libmultipath.so.0 | grep libgcc
NEEDED libgcc_s.so.1
required from libgcc_s.so.1:
$ { nm -D lib-deb/lib/libmultipath.so.0 | sed -n 's,^.*U ,,p'; nm -D
/lib/powerpc64le-linux-gnu/libgcc_s.so.1 | sed -n 's,.*[^U] ,,p'; } |
sort | uniq -d
__gcc_personality_v0
pthread_mutex_lock
pthread_mutex_unlock
_Unwind_Resume
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru multipath-tools-0.5.0/debian/changelog
multipath-tools-0.5.0/debian/changelog
--- multipath-tools-0.5.0/debian/changelog 2014-09-16 06:29:29.0
-0300
+++ multipath-tools-0.5.0/debian/changelog 2015-03-03 15:54:28.0
-0300
@@ -1,3 +1,9 @@
+multipath-tools (0.5.0-5mauricfo1) UNRELEASED; urgency=medium
+
+ * Build multipath-udeb with static libgcc (Closes: #779579)
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Tue, 03 Mar 2015
15:52:58 -0300
+
multipath-tools (0.5.0-5) unstable; urgency=medium
* [5f967eb] Better daemon status in init's status action.
diff -Nru multipath-tools-0.5.0/debian/rules multipath-tools-0.5.0/debian/rules
--- multipath-tools-0.5.0/debian/rules 2014-09-05 09:14:33.0 -0300
+++ multipath-tools-0.5.0/debian/rules 2015-03-03 15:50:32.0 -0300
@@ -27,7 +26,7 @@
build: build-arch build-indep
-build-arch: build-stamp
+build-arch: build-multipath-udeb-stamp build-stamp
build-indep: build-stamp
build-stamp:
@@ -39,15 +38,30 @@
touch $@
+# multipath-udeb: build separately; don't reference dynamic libgcc at runtime
(#779579)
+build-multipath-udeb-stamp:
+ dh_testdir
+
+ DEB_CFLAGS_MAINT_APPEND=-static-libgcc $(MAKE) $(OPTFLAGS) LIB=lib
+
+ # store files for install target
+ mkdir -p $(CURDIR)/debian/tmp-multipath-udeb/sbin
+ $(MAKE) install INSTALL_PROGRAM=$(INSTALL_PROGRAM)
DESTDIR=$(CURDIR)/debian/tmp-multipath-udeb LIB=lib
+
+ $(MAKE) clean
+
+ touch $@
+
clean-tree:
$(MAKE) clean
clean: clean-tree
dh_testdir
- rm -f build-stamp
+ rm -f build-stamp build-multipath-udeb-stamp
dh_prep
debconf-updatepo
rm -rf debian/*.debhelper.log
+ rm -rf debian/tmp-multipath-udeb
install:
dh_testdir
@@ -58,7 +72,8 @@
mkdir -p $(CURDIR)/debian/tmp/sbin
$(MAKE) install INSTALL_PROGRAM=$(INSTALL_PROGRAM)
DESTDIR=$(CURDIR)/debian/tmp LIB=lib
install -m 755 debian/dmsetup_env $(CURDIR)/debian/tmp/lib/udev/
- dh_install -X.rules --fail-missing --sourcedir=$(CURDIR)/debian/tmp
+ dh_install -X.rules --fail-missing -Nmultipath-udeb
--sourcedir=$(CURDIR)/debian/tmp
+ dh_install -X.rules --fail-missing -pmultipath-udeb
--sourcedir=$(CURDIR)/debian/tmp-multipath-udeb
# initramfs stuff:
install -D -m 755 debian/initramfs
Bug#779579: installer broken: multipath-udeb depends on non-existent libgcc1 udeb
Cyril, thanks for the /very clear/ pointers to the problem/solution. :) Ritesh, On 03/03/2015 04:26 AM, Ritesh Raj Sarraf wrote: Will you be in a position to try out the changes that Cyril has proposed ? Sure, I can try and should send a patch soon. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779579: installer broken: multipath-udeb depends on non-existent libgcc1 udeb
Hi Ritesh, Thanks for looking into this. On 03/02/2015 04:40 PM, Ritesh Raj Sarraf wrote: libgcc1 package is available in the archive. I'm not sure why it isn't present in your install media. Can you point out the udeb? It's not listed in sid d-i Packages file, nor in the jessie CD ISO, at least: $ curl -s ftp://ftp.debian.org/debian/dists/sid/main/debian-installer/binary-amd64/Packages.xz | xzgrep '^Package: libgcc1' | wc -l 0 $ find jessie-rc-iso/pool/ -name 'libgcc*' jessie-rc-iso/pool/main/g/gcc-4.9/libgcc1_4.9.1-19_ppc64el.deb And there's no udeb in the gcc-4.9 pool dir: ftp://ftp.debian.org/debian/pool/main/g/gcc-4.9/ -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779579: installer broken: multipath-udeb depends on non-existent libgcc1 udeb
Package: src:multipath-tools Version: 0.5.0-5 During a multipath installation (disk-detect/multipath/enable=true), the multipath binary fails to run because libgcc is missing: ~ # grep 'multipath\|libgcc' /var/log/syslog | grep -v kernel | cut -d' ' -f5- anna-install: Installing multipath-udeb anna[3505]: DEBUG: resolver (libgcc1): package doesn't exist (ignored) anna[3505]: DEBUG: retrieving multipath-modules-3.16.0-4-powerpc64le-di 3.16.7-ckt4-3 anna[3505]: DEBUG: retrieving multipath-udeb 0.5.0-5 disk-detect: /sbin/multipath: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory disk-detect: No multipath devices detected main-menu[191]: (process:3777): multipath: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory [snip; repeat] This can be verified in d-i's Packages file [1]: Package: multipath-udeb Source: multipath-tools Version: 0.5.0-5 [...] Depends: [...], libgcc1, [...] which has no such package: $ curl -s ftp://ftp.debian.org/debian/dists/sid/main/debian-installer/binary-amd64/Packages.xz | xzgrep '^Package: libgcc1' | wc -l 0 [1] ftp://ftp.debian.org/debian/dists/sid/main/debian-installer/binary-amd64/ -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779579: [work-around] installer broken: multipath-udeb depends on non-existent libgcc1 udeb
Observation.. An work-around is to download install the libgcc1.so file manually: ~ # multipath -l multipath: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory ~ # wget -O /tmp/libgcc1.deb ftp://ftp.br.debian.org/debian/pool/main/g/gcc-4 .9/libgcc1_4.9.2-10_ppc64el.deb ar p /tmp/libgcc1.deb data.tar.xz | xzcat | tar x ./lib/powerpc64le-linux ~ # multipath -l ~ # echo $? 0 -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766695: atlas: add ppc64el support
Hi Sébastien, Please disregard the previous e-mails. I believe your point below is now addressed. On 10/25/2014 03:39 PM, Sébastien Villemot wrote: Also, I really dislike the kludge consisting in modifying the quilt series file. Isn't it rather possible to use a standard patch (applied on all arches) based on #ifdefs? Yes. The attached patch now does that. Is it in a better position for starting a conversation w/ the Release Team? I reviewed the patches, and all - except for one - were using cpp conditionals (#if/#else/#endif) properly. Their changes are trivial and small, well localized to the minimal changes required to powerpc. 1) ++ #if defined(__powerpc64__) (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) ++ ... ++ #endif 2) +- #if defined(ATL_USE64BITS) ++ #if defined(ATL_USE64BITS) _CALL_ELF != 2 3) ++ #if _CALL_ELF == 2 ++ /* ABIv2 */ ++ ... ++ #else ++ /* ABIv1 */ + ... ++ #endif That exception was a patch removing some optimized cases from lists. I replaced it with another patch that uses #if/#else/#endif per-arch, leaving the original source code as-is on non-ppc64el arches. 4) ++#if defined(__powerpc64__) (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) ++/* FIXME: port to little-endian powerpc64. */ ++#else ++ + ... ++ ++#endif/* little-endian powerpc64 */ That said, AFAICT, the changes do not pose any problem to other powerpc-based ports. I could successfully build atlas on ppc64el with it, and will perform/report of builds on powerpc and ppc64 shortly. -- Mauricio Faria de Oliveira IBM Linux Technology Center diff -Nru atlas-3.10.2/debian/archdefs/README atlas-3.10.2/debian/archdefs/README --- atlas-3.10.2/debian/archdefs/README 2014-07-12 07:23:26.0 -0300 +++ atlas-3.10.2/debian/archdefs/README 2014-10-28 07:46:40.0 -0200 @@ -16,5 +16,6 @@ - mips: ATLAS 3.10.1 / gabrielli.debian.org / sid / 2013-07-27 - mipsel: ATLAS 3.10.1 / eder.debian.org / sid / 2013-06-07 - powerpc: ATLAS 3.10.1 / partch.debian.org / sid / 2013-06-06 +- ppc64el: ATLAS 3.10.2 / pastel.debian.net / sid / 2014-10-24 - s390x: ATLAS 3.10.1 / zelenka.debian.org / sid / 2013-06-06 - sparc: ATLAS 3.10.1 / smetana.debian.org / wheezy / 2013-06-06 diff -Nru atlas-3.10.2/debian/changelog atlas-3.10.2/debian/changelog --- atlas-3.10.2/debian/changelog 2014-10-15 16:35:41.0 -0300 +++ atlas-3.10.2/debian/changelog 2014-10-28 09:28:17.0 -0200 @@ -1,3 +1,17 @@ +atlas (3.10.2-4ppc64el2) UNRELEASED; urgency=medium + + * Add ppc64el support (work in progress) +- debian/patches/ (thanks, Michael Normand et al). + - atlas-new_archdef_for_ppc64le.patch + - atlas.3.10.2-ppc64le_abiv2_step2.patch + - atlas.3.10.2-ppc64le_abiv2_step3.patch + - atlas.3.10.2-ppc64le_ifdef_files_with_lvx.patch +- debian/archdefs/ppc64el/GENERIC64LE.tar.bz2: archdefs/timings, + currently the same file for POWER7, POWER7+ and POWER8 systems. +- debian/archdefs/README: updated accordingly. + + -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Thu, 28 Oct 2014 09:28:00 -0200 + atlas (3.10.2-4) unstable; urgency=medium [ Alastair McKinstry ] diff -Nru atlas-3.10.2/debian/patches/atlas-new_archdef_for_ppc64le.patch atlas-3.10.2/debian/patches/atlas-new_archdef_for_ppc64le.patch --- atlas-3.10.2/debian/patches/atlas-new_archdef_for_ppc64le.patch 1969-12-31 21:00:00.0 -0300 +++ atlas-3.10.2/debian/patches/atlas-new_archdef_for_ppc64le.patch 2014-10-28 07:46:40.0 -0200 @@ -0,0 +1,38 @@ +Origin: https://bugzilla.redhat.com/show_bug.cgi?id=1080073#c43 +Forwarded: http://sourceforge.net/p/math-atlas/patches/66/ +Description: Append 'LE' to archdef on little-endian PowerPC64 + For more details, see: + https://bugzilla.redhat.com/show_bug.cgi?id=1080073#c40 +Last-Update: 2014-10-24 +Subject: atlas new archdef for ppc64le +From: Michel Normand norm...@linux.vnet.ibm.com +Date: Sun, 13 Jun 2014 18:02:47 +0200 + +Need to define different archdef names +for ppc64 (that is Big Endian) and ppc64le (that is Little Endian). +This is already done upstream in atlas 3.11.30 with issue +https://sourceforge.net/p/math-atlas/patches/66/ + +Required at least as long as I need the bypass of +atlas.3.10.2-ppc64le_do_not_use_files_with_lvx.patch + +Signed-off-by: Michel Normand norm...@linux.vnet.ibm.com +--- + CONFIG/src/SpewMakeInc.c |4 + 1 file changed, 4 insertions(+) + +Index: ATLAS/CONFIG/src/SpewMakeInc.c +=== +--- ATLAS.orig/CONFIG/src/SpewMakeInc.c ATLAS/CONFIG/src/SpewMakeInc.c +@@ -542,6 +542,10 @@ int main(int nargs, char **args) +fprintf(fpout, # -\n); +fprintf(fpout
Bug#766695: atlas: add ppc64el support
On 10/28/2014 10:10 AM, Mauricio Faria de Oliveira wrote: That said, AFAICT, the changes do not pose any problem to other powerpc-based ports. I could successfully build atlas on ppc64el with it, and will perform/report of builds on powerpc and ppc64 shortly. powerpc: built successfully. ppc64: in progress (seems it will take longer; no archdef) As only powerpc is affect as far as jessie is concerned, would you have any comments on the v2 debdiff, and about talking to the Release Team for authorizing an upload? Thank you, -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766695: atlas: add ppc64el support
On 10/28/2014 05:14 PM, Sébastien Villemot wrote: Thanks Mauricio for your work. It looks much better now, and I will definitely ask the Release Team for getting this into Jessie (probably in a few days though). Great! Thanks a *lot*, Sébastien. If you have the time, I'd ask you to please give any news once avail. :) -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766695: atlas: add ppc64el support
On 10/28/2014 12:57 PM, Mauricio Faria de Oliveira wrote: I could successfully build atlas on ppc64el with it, and will perform/report of builds on powerpc and ppc64 shortly. powerpc: built successfully. ppc64: in progress (seems it will take longer; no archdef) ppc64: built successfully too. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766695: atlas: add ppc64el support
Hi Sébastien, On 10/25/2014 03:39 PM, Sébastien Villemot wrote: However I am not sure to understand some bits of it. Why do you add a new POWER8 architecture type, if you are using the GENERIC one? It is either one or the other. My impression is that atlas.3.10.2-add_power8_cpu.patch is unneeded. Yes, I agree. The reason for it to be there is just to follow as close as possible to what (we expect) would be upstream in some time, so the package downstream didn't differ much. That one can certainly be removed (and the 'if ppc64el' bits for generic on debian/rules that cope with it). Also, I really dislike the kludge consisting in modifying the quilt series file. Isn't it rather possible to use a standard patch (applied on all arches) based on #ifdefs? Indeed not the most elegant way (kludging the quilt series). It's being used because one of the patched files modifies a non-preprocessed file (AFAICT) - the cases/optimized routines one -, thus it seems not to be possible to use an #ifdef (which would look way better). Do you happen to know another way/suggestion for it? I'd be happy to rework the patches/mechanism in another way that fits the source pkg/ maintainers preferences. May you please consider it for an upload? (specially for making jessie) Note that it's now too late to upload this patch before the freeze (because the freeze starts on November 5, and there is a 10-day migration delay). However, we may obtain the permission of the Release Team to upload this patch to jessie; simplifying this patch as much as possible will increase the possibility of having this happening. Ok, that's certainly understandable. With the above comments (can drop power8 patch and its associated piece for generic arch in debian/rules, and asking for alternative mechanisms for non-#ifdef patches), what do you think is a good way to go? Thank you, -- Mauricio Faria de Oliveira IBM Linux Technology Center. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766695: atlas: add ppc64el support
Sébastien, I'd like to ask you a few more questions, if you have the time. On 10/25/2014 03:39 PM, Sébastien Villemot wrote: Also, I really dislike the kludge consisting in modifying the quilt series file. Isn't it rather possible to use a standard patch (applied on all arches) based on #ifdefs? Would it help if it were kludged in a different way, not touching the original series file, but just applying the additional series on another .pc directory? I've received a nice suggestion on this. Otherwise, following the patch applied to all arches (more relevantly, powerpc and ppc64), how to make sure it's tested enough? Is just the package build status a good evidence, or could you recommend/point out some more testing documentation/procedures? - I'm not familiar with the atlas build system, so it would be nice to have your point. Thank you, -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766695: atlas: add ppc64el support
Package: src:atlas Version: 3.10.2-4 Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el Hi atlas maintainers, This patch adds support for the ppc64el port. It contains: 1) the patch-set authored by Michael Normand (submitted upstream, also documented in [1]) 2) a packaging change, to restrict the patch-set to ppc64el builds only; it touches common powerpc code, which is certainly not desirable for other powerpc-based ports at this moment (bugs/freeze/jessie). 3) an archdef tarball (attached separately) May you please consider it for an upload? (specially for making jessie) Thank you, [1] https://bugzilla.redhat.com/show_bug.cgi?id=1080073#c40 -- Mauricio Faria de Oliveira IBM Linux Technology Center GENERIC64LE.tar.bz2 Description: application/bzip diff -Nru atlas-3.10.2/debian/archdefs/README atlas-3.10.2/debian/archdefs/README --- atlas-3.10.2/debian/archdefs/README 2014-07-12 07:23:26.0 -0300 +++ atlas-3.10.2/debian/archdefs/README 2014-10-24 19:45:37.0 -0200 @@ -16,5 +16,6 @@ - mips: ATLAS 3.10.1 / gabrielli.debian.org / sid / 2013-07-27 - mipsel: ATLAS 3.10.1 / eder.debian.org / sid / 2013-06-07 - powerpc: ATLAS 3.10.1 / partch.debian.org / sid / 2013-06-06 +- ppc64el: ATLAS 3.10.2 / pastel.debian.net / sid / 2014-10-24 - s390x: ATLAS 3.10.1 / zelenka.debian.org / sid / 2013-06-06 - sparc: ATLAS 3.10.1 / smetana.debian.org / wheezy / 2013-06-06 diff -Nru atlas-3.10.2/debian/changelog atlas-3.10.2/debian/changelog --- atlas-3.10.2/debian/changelog 2014-10-15 16:35:41.0 -0300 +++ atlas-3.10.2/debian/changelog 2014-10-24 19:45:37.0 -0200 @@ -1,3 +1,15 @@ +atlas (3.10.2-4ppc64el1) UNRELEASED; urgency=medium + + * Add ppc64el support (work in progress) +- debian/patches/ppc64el/ (thanks, Michael Normand et al). +- debian/rules: restrict ppc64el patches to ppc64el builds. +- debian/rules: different 'GENERIC' first number in ARCHs due to POWER8. +- debian/archdefs/ppc64el/GENERIC64LE.tar.bz2: archdefs/timings, + currently the same file for POWER7, POWER7+ and POWER8 systems. +- debian/archdefs/README: updated accordingly. + + -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Thu, 24 Oct 2014 20:02:00 -0200 + atlas (3.10.2-4) unstable; urgency=medium [ Alastair McKinstry ] diff -Nru atlas-3.10.2/debian/patches/ppc64el/atlas-new_archdef_for_ppc64le.patch atlas-3.10.2/debian/patches/ppc64el/atlas-new_archdef_for_ppc64le.patch --- atlas-3.10.2/debian/patches/ppc64el/atlas-new_archdef_for_ppc64le.patch 1969-12-31 21:00:00.0 -0300 +++ atlas-3.10.2/debian/patches/ppc64el/atlas-new_archdef_for_ppc64le.patch 2014-10-24 19:45:37.0 -0200 @@ -0,0 +1,38 @@ +Origin: https://bugzilla.redhat.com/show_bug.cgi?id=1080073#c43 +Forwarded: http://sourceforge.net/p/math-atlas/patches/66/ +Description: Append 'LE' to archdef on little-endian PowerPC64 + For more details, see: + https://bugzilla.redhat.com/show_bug.cgi?id=1080073#c40 +Last-Update: 2014-10-24 +Subject: atlas new archdef for ppc64le +From: Michel Normand norm...@linux.vnet.ibm.com +Date: Sun, 13 Jun 2014 18:02:47 +0200 + +Need to define different archdef names +for ppc64 (that is Big Endian) and ppc64le (that is Little Endian). +This is already done upstream in atlas 3.11.30 with issue +https://sourceforge.net/p/math-atlas/patches/66/ + +Required at least as long as I need the bypass of +atlas.3.10.2-ppc64le_do_not_use_files_with_lvx.patch + +Signed-off-by: Michel Normand norm...@linux.vnet.ibm.com +--- + CONFIG/src/SpewMakeInc.c |4 + 1 file changed, 4 insertions(+) + +Index: ATLAS/CONFIG/src/SpewMakeInc.c +=== +--- ATLAS.orig/CONFIG/src/SpewMakeInc.c ATLAS/CONFIG/src/SpewMakeInc.c +@@ -542,6 +542,10 @@ int main(int nargs, char **args) +fprintf(fpout, # -\n); +fprintf(fpout,ARCH = %s, machnam[mach]); +fprintf(fpout, %d, ptrbits); ++ /* for ppc64le archi add 'LE' characters */ ++ #if defined(__powerpc64__) (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) ++ fprintf(fpout, %s, LE); ++ #endif +if (ISAX) + fprintf(fpout, %s, ISAXNAM[ISAX]); +if (!USEIEEE) diff -Nru atlas-3.10.2/debian/patches/ppc64el/atlas.3.10.2-add_power8_cpu.patch atlas-3.10.2/debian/patches/ppc64el/atlas.3.10.2-add_power8_cpu.patch --- atlas-3.10.2/debian/patches/ppc64el/atlas.3.10.2-add_power8_cpu.patch 1969-12-31 21:00:00.0 -0300 +++ atlas-3.10.2/debian/patches/ppc64el/atlas.3.10.2-add_power8_cpu.patch 2014-10-24 19:45:37.0 -0200 @@ -0,0 +1,138 @@ +Origin: https://bugzilla.redhat.com/show_bug.cgi?id=1080073#c37 +Forwarded: http://sourceforge.net/p/math-atlas/patches/67/ +Description: Add IBM POWER8 pieces + The original patch for 3.10.2 was backported to apply on top + of 'debian/patches/generic.diff' - trivial changes to hunks + of 'ATLAS/CONFIG
Bug#764745: linux: ppc64el: disable CONFIG_CMDLINE committed, makes jessie?
Package: src:linux Thanks, Ben, I see this was committed quickly! Is there any estimate of when 3.16.5-2 will be uploaded to sid? Kind regards, -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764745: linux: ppc64el: disable CONFIG_CMDLINE committed, makes jessie?
On 10/22/2014 10:45 AM, Mauricio Faria de Oliveira wrote: Is there any estimate of when 3.16.5-2 will be uploaded to sid? Ah, just asking because it's desirable to have it fixed mainly for d-i (in some of the next spins). -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765370: xutils-dev: fix CCOPTIONS/LDOPTIONS causing FTBFS on sciplot on ppc64el [PATCH]
Hi Julien, On 10/15/2014 05:45 AM, Julien Cristau wrote: The 'add ppc64el support' patch seems to make the other one unnecessary, since -mminimal-toc is only added for ppc64architecture, which wouldn't apply to ppc64el? Am I missing something? It happens the patch doesn't disable the ppc64architecture, it just adds the ppc64el architecture - so if you're in powerpc64 and little endian, both are defined (see there's no #else in this piece): + # ifdef __powerpc64__ ++# ifdef __LITTLE_ENDIAN__ ++#ifndef Ppc64elArchitecture ++# define Ppc64elArchitecture ++#endif ++# endif + # ifndef Ppc64Architecture + # define Ppc64Architecture + # endif I haven't discussed the patch with its author. Do you believe this point should be handled differently? (i.e., use an #else) One thing I had in mind when writing the other patch was trying not to modify existing stuff, so not to break what used it before, so maybe that fits here too - ppc64el is also some sort of ppc64, except for the endianness-dependent pieces. Also, have any of these patches been sent upstream? I don't think so. I'd be happy to submit them (w/ the other author's acknowledgement) if you/other maintainers are OK w/ them (as you're more experienced - I only looked at a small piece for fixing it). Thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765370: xutils-dev: fix CCOPTIONS/LDOPTIONS causing FTBFS on sciplot on ppc64el [PATCH]
On 10/15/2014 12:17 PM, Julien Cristau wrote: On Wed, Oct 15, 2014 at 11:56:31 -0300, Mauricio Faria de Oliveira wrote: It happens the patch doesn't disable the ppc64architecture, it just adds the ppc64el architecture - so if you're in powerpc64 and little endian, both are defined (see there's no #else in this piece): Ah, right, I must have been blind... ... This way seems to be how mips is handled, so let's leave it as-is. Haha, no problem. Ok. One thing I had in mind when writing the other patch was trying not to modify existing stuff, so not to break what used it before, so maybe that fits here too - ppc64el is also some sort of ppc64, except for the endianness-dependent pieces. I wonder if the -mminimal-toc thing is actually needed on BE ppc64. It seems to have been introduced by https://bugs.freedesktop.org/show_bug.cgi?id=303 but I don't know why. Well, I can't say of it in CCOPTIONS, because it's a valid CC option; but in LDOPTIONS, it's certainly wrong (it's not an emulation mode). BTW, I just noticed sciplot FTBFS on ppc64 too, for the same reason [1]. So if we could just remove that, it seems like it'd be easier all around. There are legitimate reasons one may want -mminimal-toc in CCOPTIONS (I don't understand much of it, but have seen it elsewhere). That said, I certainly wouldn't want to break its users/packages. It would be enough to just remove it from LDOPTIONS for ppc64/el. If you recommend to forward and discuss this upstream, perharps to understand how this happened, I would be willing to help/ask. If you have the time and a quick way to track to the point where CCOPTIONS were added to LDOPTIONS it might help. I can try/learn later, otherwise. What you'd prefer? Thanks for your time and attention. [1] http://buildd.debian-ports.org/status/package.php?p=sciplotsuite=sid -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765354: llvm-defaults: lldb: fix FTBFS on ppc64el/arm64 (patch)
Package: src:llvm-defaults Version: 0.24 Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el The recent packaging changes for (not) building lldb do FTBFS on ppc64el [1] and arm64 [2]. Sorry for not catching it earlier. The attached patch fixes it by adding lldb to no_packages on non-LLDB_SUPPORTED archs, so that 'dh_builddeb -Nlldb' may happen. May you please consider it for an upload? Thanks! Details: Before: dh_builddeb -a -Nllvm-gcc dpkg-deb: building package `llvm' in `../llvm_3.5-24_ppc64el.deb'. ... dpkg-deb: error: failed to open package info file `debian/lldb/DEBIAN/control' for reading: No such file or directory dh_builddeb: dpkg-deb --build debian/lldb .. returned exit code 2 debian/rules:220: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 After: dh_builddeb -a -Nllvm-gcc -Nlldb dpkg-deb: building package `llvm' in `../llvm_3.5-24ppc64el1_ppc64el.deb'. ... dpkg-genchanges: warning: package lldb in control file but not in files list dpkg-genchanges: including full source code in upload dpkg-source --after-build llvm-defaults-0.24 dpkg-buildpackage: full upload; Debian-native package (full source is included) Links: -- [1] https://buildd.debian.org/status/fetch.php?pkg=llvm-defaultsarch=ppc64elver=0.24stamp=1411681277 [2] https://buildd.debian.org/status/fetch.php?pkg=llvm-defaultsarch=arm64ver=0.24stamp=1413020888 -- Mauricio Faria de Oliveira IBM Linux Technology Center diff -Nru llvm-defaults-0.24/debian/changelog llvm-defaults-0.24ppc64el1/debian/changelog --- llvm-defaults-0.24/debian/changelog 2014-09-25 05:40:37.0 -0300 +++ llvm-defaults-0.24ppc64el1/debian/changelog 2014-10-14 08:54:47.0 -0300 @@ -1,3 +1,9 @@ +llvm-defaults (0.24ppc64el1) UNRELEASED; urgency=medium + + * Don't dh_builddeb lldb on non-LLDB_SUPPORTED archs (fix FTBFS on ppc64el/arm64). + + -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Tue, 14 Oct 2014 08:52:50 -0300 + llvm-defaults (0.24) unstable; urgency=medium * Upload in unstable diff -Nru llvm-defaults-0.24/debian/rules llvm-defaults-0.24ppc64el1/debian/rules --- llvm-defaults-0.24/debian/rules 2014-09-03 06:07:52.0 -0300 +++ llvm-defaults-0.24ppc64el1/debian/rules 2014-10-14 08:52:37.0 -0300 @@ -51,12 +51,14 @@ distribution := $(shell lsb_release -is) all_packages := llvm llvm-runtime llvm-dev libllvm-ocaml-dev clang libclang1 libclang-dev +no_packages:= llvm-gcc # must be built? LLDB_SUPPORTED=amd64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 s390 s390x sparc alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32 powerpc mips mipsel ifneq (,$(filter $(DEB_HOST_ARCH),$(LLDB_SUPPORTED))) all_packages += lldb +else +no_packages += lldb endif -no_packages := llvm-gcc # must be built? packages := $(filter-out $(no_packages), $(all_packages))
Bug#765370: xutils-dev: fix CCOPTIONS/LDOPTIONS causing FTBFS on sciplot on ppc64el [PATCH]
Package: src:xutils-dev Version: 1:7.7+3 Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el The attached patch adds the ppc64el pieces and fixes a FTBFS on sciplot (and potentially others), avoiding to pass -mminimal-toc from CCOPTIONS to LDOPTIONS (because it's incorrect for 'ld -mvalue'). May you please consider it for an upload? Thanks! Details: The fixed FTBFS error [1]: ld -shared -o libsciplot.so.1.36 SciPlot.o SciPlotUtil.o -mminimal-toc -lXm [...] -soname libsciplot.so.1 -lc ld: unrecognised emulation mode: minimal-toc Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim elf32ppclinux elf32ppc elf32ppcsim elf64ppc make[2]: *** [shared] Error 1 [1] https://buildd.debian.org/status/fetch.php?pkg=sciplotarch=ppc64elver=1.36-16stamp=1410447072 -- Mauricio Faria de Oliveira IBM Linux Technology Center diff -Nru xutils-dev-7.7+3/debian/changelog xutils-dev-7.7+3ppc64el1/debian/changelog --- xutils-dev-7.7+3/debian/changelog 2014-05-21 16:46:36.0 -0300 +++ xutils-dev-7.7+3ppc64el1/debian/changelog 2014-10-14 10:49:40.0 -0300 @@ -1,3 +1,12 @@ +xutils-dev (1:7.7+3ppc64el1) UNRELEASED; urgency=medium + + * 98_ppc64el-not-ld-options.diff: Add DefaultNotLDOptions/NOTLDOPTIONS for +filtering out CCOPTIONS that are not valid LDOPTIONS (cause linker errors). + * 99_ppc64el.diff: Add support for ppc64el as little-endian ppc64. +(Credits: Adam Conrad) + + -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Tue, 14 Oct 2014 10:45:41 -0300 + xutils-dev (1:7.7+3) unstable; urgency=medium * gccmakedep 1.0.3. diff -Nru xutils-dev-7.7+3/debian/patches/98_ppc64el-not-ld-options.diff xutils-dev-7.7+3ppc64el1/debian/patches/98_ppc64el-not-ld-options.diff --- xutils-dev-7.7+3/debian/patches/98_ppc64el-not-ld-options.diff 1969-12-31 21:00:00.0 -0300 +++ xutils-dev-7.7+3ppc64el1/debian/patches/98_ppc64el-not-ld-options.diff 2014-10-14 10:44:36.0 -0300 @@ -0,0 +1,34 @@ +Description: Some CCOPTIONS are not valid LDOPTIONS (e.g., -mminimal-toc), so filter-out NOTLDOPTIONS +Author: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com +Last-Update: 2014-10-14 + +diff -Nru xorg-cf-files.orig/Imake.tmpl xorg-cf-files/Imake.tmpl +--- a/xorg-cf-files/Imake.tmpl 2014-10-14 10:02:03.0 -0300 b/xorg-cf-files/Imake.tmpl 2014-10-14 10:24:50.0 -0300 +@@ -2165,6 +2165,7 @@ + + CDEBUGFLAGS = DefaultCDebugFlags + CCOPTIONS = DefaultCCOptions /* to distinguish from param flags */ ++ NOTLDOPTIONS = DefaultNotLDOptions /* not to be used as linker options */ + /* + * STD_INCLUDES contains system-specific includes + * TOP_INCLUDES specifies how to get to /usr/include or its build substitute +@@ -2179,6 +2180,7 @@ + LDPRELIB = LdPreLib $(INSTALLED_LIBS) + LDPOSTLIB = LdPostLib + LDOPTIONS = $(CDEBUGFLAGS) $(CCOPTIONS) $(EXTRA_LDOPTIONS) $(THREADS_LDFLAGS) $(LOCAL_LDFLAGS) $(LDPRELIBS) ++LDOPTIONS := $(filter-out $(NOTLDOPTIONS),$(LDOPTIONS)) + CXXLDOPTIONS = $(CXXDEBUGFLAGS) $(CXXOPTIONS) $(EXTRA_LDOPTIONS) $(THREADS_CXXLDFLAGS) $(LOCAL_LDFLAGS) $(LDPRELIBS) + +LDLIBS = $(LDPOSTLIBS) $(THREADS_LIBS) $(SYS_LIBRARIES) $(EXTRA_LIBRARIES) +diff -Nru xorg-cf-files.orig/linux.cf xorg-cf-files/linux.cf +--- a/xorg-cf-files.orig/linux.cf 2014-10-14 10:02:03.0 -0300 b/xorg-cf-files/linux.cf 2014-10-14 10:21:52.0 -0300 +@@ -1005,6 +1005,7 @@ + + #ifdef Ppc64Architecture + # define DefaultCCOptions -mminimal-toc ++# define DefaultNotLDOptions -mminimal-toc + # ifndef OptimizedCDebugFlags + # define OptimizedCDebugFlagsDefaultGcc2Ppc64Opt GccAliasingArgs + # endif diff -Nru xutils-dev-7.7+3/debian/patches/99_ppc64el.diff xutils-dev-7.7+3ppc64el1/debian/patches/99_ppc64el.diff --- xutils-dev-7.7+3/debian/patches/99_ppc64el.diff 1969-12-31 21:00:00.0 -0300 +++ xutils-dev-7.7+3ppc64el1/debian/patches/99_ppc64el.diff 2014-10-14 10:44:41.0 -0300 @@ -0,0 +1,32 @@ +Description: Add support for ppc64el as little-endian ppc64. +Author: Adam Conrad adcon...@ubuntu.com +Origin: https://launchpadlibrarian.net/160111286/xutils-dev_1:7.7~1ubuntu5_1:7.7~1ubuntu6.diff.gz +Last-Update: 2014-10-14 + +diff -Nru xutils-dev-7.7~1ubuntu5/xorg-cf-files/Imake.cf xutils-dev-7.7~1ubuntu6/xorg-cf-files/Imake.cf +--- xutils-dev-7.7~1ubuntu5/xorg-cf-files/Imake.cf 2013-07-30 12:22:15.0 -0600 xutils-dev-7.7~1ubuntu6/xorg-cf-files/Imake.cf 2013-12-18 05:22:24.0 -0700 +@@ -930,6 +930,11 @@ + # undef __powerpc__ + # endif + # ifdef __powerpc64__ ++# ifdef __LITTLE_ENDIAN__ ++#ifndef Ppc64elArchitecture ++# define Ppc64elArchitecture ++#endif ++# endif + # ifndef Ppc64Architecture + # define Ppc64Architecture + # endif +diff -Nru xutils-dev-7.7~1ubuntu5/xorg-cf-files/Imake.tmpl xutils-dev-7.7
Bug#764745: linux: ppc64el: disable CONFIG_CMDLINE{,_BOOT}
Package: src:linux
Version: 3.16.3-2
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
Hi maintainers,
The patch attached disables CONFIG_CMDLINE_BOOT on ppc64el, diverging
from the ppc64 config.
It renders the console useless / unresponsive after kernel boots.
The problem is the CONFIG_CMDLINE value in ppc64 (specifically
console=tty0) is incorrect for ppc64el platforms (pseries, powernv).
This happens only when no kernel parameters are used, as that default
cmdline is used. It's unlikely (the reason this came up just now),
but it's easily hit on netboot installer, when there's usually no
kernel parameters (at least on a first try). The CDs are unaffected:
all boot with 'BOOT_IMAGE=/install/vmlinux -- quiet'.
Either way, as the CONFIG_CMDLINE value has only been used to specify
console devices, and the kernel autodetects/enables those correctly
on ppc64el platforms, it's OK to disable CONFIG_CMDLINE boot on ppc64el.
May you please consider it for an upload?
(patches provided for jessie/sid experimental)
Additional info:
The ppc64 config remains identical w/ this change:
- current package:
$ ar -p linux-image-3.16-2-powerpc64_3.16.3-2_ppc64.deb data.tar.xz |
tar xJ -O ./boot/config-3.16-2-powerpc64 | grep CMDLINE
# CONFIG_BLK_CMDLINE_PARSER is not set
# CONFIG_CMDLINE_PARTITION is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=console=hvsi0 console=hvc0 console=ttyS0,9600
console=tty0
# CONFIG_CMDLINE_FORCE is not set
- this build:
$ grep CMDLINE debian/build/build_ppc64_none_powerpc64/.config
# CONFIG_BLK_CMDLINE_PARSER is not set
# CONFIG_CMDLINE_PARTITION is not set
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=console=hvsi0 console=hvc0 console=ttyS0,9600
console=tty0
# CONFIG_CMDLINE_FORCE is not set
Console devices autodetected correctly:
- guest (pseries)
~ # dmesg | grep command
[0.00] Kernel command line:
~ # dmesg | grep console
[0.00] bootconsole [udbg0] enabled
[0.001535] console [hvc0] enabled
[0.001981] bootconsole [udbg0] disabled
- non-virtualized (powernv)
~ # dmesg | grep command
[0.00] Kernel command line:
~ # dmesg | grep console
[0.00] bootconsole [udbg0] enabled
[0.004514] console [hvc0] enabled
[0.005631] bootconsole [udbg0] disabled
[1.498333] hvc0: raw protocol on /ibm,opal/consoles/serial@0 (boot
console)
[1.499063] hvc1: hvsi protocol on /ibm,opal/consoles/serial@1
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru linux-3.16.3/debian/changelog linux-3.16.3/debian/changelog
--- linux-3.16.3/debian/changelog 2014-09-20 06:43:41.0 -0300
+++ linux-3.16.3/debian/changelog 2014-10-10 13:36:47.0 -0300
@@ -1,3 +1,14 @@
+linux (3.17~rc5-1~exp1ppc64el1) UNRELEASED; urgency=medium
+
+ * [ppc64el] Disable CONFIG_CMDLINE{,_BOOL} usage for setting consoles:
+- The value of ppc64 is incorrect for ppc64el (specifically, console=tty0),
+ rendering the console useless (blank and unresponsive) if no kernel
parameters
+ are specified (e.g., debian-installer netboot).
+- It's not needed currently: the kernel correctly autodetects the console
+ on ppc64el platforms (hvc0 on pseries, hvc0 and hvc1 on powernv).
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Fri, 10 Oct 2014
13:10:00 -0300
+
linux (3.17~rc5-1~exp1) experimental; urgency=medium
* New upstream release candidate
diff -Nru linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64
linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64
--- linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64
2014-09-16 15:31:23.0 -0300
+++ linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64
2014-10-10 13:09:39.0 -0300
@@ -9,7 +9,6 @@
CONFIG_PPC_64K_PAGES=y
## end choice
CONFIG_SCHED_SMT=y
-CONFIG_CMDLINE=console=hvsi0 console=hvc0 console=ttyS0,9600 console=tty0
CONFIG_KERNEL_START=0xc000
##
diff -Nru linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64-be
linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64-be
--- linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64-be
2014-08-09 14:52:47.0 -0300
+++ linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64-be
2014-10-10 13:09:38.0 -0300
@@ -1,4 +1,9 @@
##
+## file: arch/powerpc/Kconfig
+##
+CONFIG_CMDLINE=console=hvsi0 console=hvc0 console=ttyS0,9600 console=tty0
+
+##
## file: arch/powerpc/platforms/cell/Kconfig
##
CONFIG_PPC_IBM_CELL_BLADE=y
diff -Nru linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64-le
linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64-le
--- linux-3.16.3/debian/config/kernelarch-powerpc/config-arch-64-le
2014-08-09 16:42:11.0
Bug#748911: src:opal: FTBFS on 64 bits arch
Hi YunQiang, On 09/27/2014 01:12 AM, YunQiang Su wrote: Can any ppc64el and arm64 guys help to test this patch? On 10/07/2014 11:58 PM, YunQiang Su wrote: I will NMU ptlib with the attached debdiff. If you don't agree with it, please cancel it or ask me to do it. Sorry for missing this one for a few days. For ppc64el, there's a small change required, because the machine name is powerpc64le (suffix 'le' vs. 'el'): $ sed 's,ppc64el | powerpc64el,powerpc64le,' -i ptlib.debdiff With that change, the ptlib package built successfully, and configure messages changed: from: configure: WARNING: CPU powerpc64le not recognized - proceed with caution! configure: OSTYPE set to linux configure: OSRELEASE set to 3.16-trunk-powerpc64le configure: MACHTYPE set to powerpc64le to: configure: OSTYPE set to linux configure: OSRELEASE set to 3.16-trunk-powerpc64le configure: MACHTYPE set to ppc64 Thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762476: gccxml: add ppc64el support (patch available; fixes FTBFS)
Package: src:gccxml Version: 0.9.0+git20140716-1 Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el This trivial patch fixes gccxml FTBFS on ppc64el [1], by adding bits for 'powerpc64le-unknown-linux-gnu' in 'GCC/gcc/config.gcc'. May you please consider it for an upload? With it applied the package builds successfully, and test-suite passed: make[1]: Entering directory '/build/gccxml-0.9.0+git20140716/obj-powerpc64le-linux-gnu' Running tests... /usr/bin/ctest --force-new-ctest-process -j8 Test project /build/gccxml-0.9.0+git20140716/obj-powerpc64le-linux-gnu Start 1: gxConfiguration.cxx Start 2: gxConfiguration.h Start 3: gxDocumentation.cxx Start 4: gxDocumentation.h Start 5: gxFlagsParser.cxx Start 6: gxFlagsParser.h Start 7: gxFront.cxx Start 8: gxSystemTools.cxx 1/13 Test #6: gxFlagsParser.h .. Passed0.47 sec 2/13 Test #7: gxFront.cxx .. Passed0.53 sec 3/13 Test #8: gxSystemTools.cxx Passed0.54 sec 4/13 Test #2: gxConfiguration.h Passed0.55 sec Start 9: gxSystemTools.h Start 10: TestFullPathInclude.cxx Start 11: TestUsualInclude.cxx Start 12: cmath.cc 5/13 Test #1: gxConfiguration.cxx .. Passed2.51 sec 6/13 Test #3: gxDocumentation.cxx .. Passed2.50 sec 7/13 Test #4: gxDocumentation.h Passed2.50 sec 8/13 Test #5: gxFlagsParser.cxx Passed2.50 sec 9/13 Test #12: cmath.cc . Passed0.30 sec Start 13: complex.cc 10/13 Test #11: TestUsualInclude.cxx . Passed0.45 sec 11/13 Test #9: gxSystemTools.h .. Passed0.55 sec 12/13 Test #10: TestFullPathInclude.cxx .. Passed0.55 sec 13/13 Test #13: complex.cc ... Passed0.41 sec 100% tests passed, 0 tests failed out of 13 Total Test time (real) = 3.22 sec make[1]: Leaving directory '/build/gccxml-0.9.0+git20140716/obj-powerpc64le-linux-gnu' [...] dpkg-genchanges ../gccxml_0.9.0+git20140716-1ppc64el1_ppc64el.changes [1] https://buildd.debian.org/status/fetch.php?pkg=gccxmlarch=ppc64elver=0.9.0%2Bgit20140716-1stamp=1410448207 -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762476: gccxml: add ppc64el support (patch available; fixes FTBFS)
Package: src:gccxml
Tags: patch
It helps if the patch is actually attached. :)
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru gccxml-0.9.0+git20140716/debian/changelog
gccxml-0.9.0+git20140716/debian/changelog
--- gccxml-0.9.0+git20140716/debian/changelog 2014-07-16 05:51:59.0
-0300
+++ gccxml-0.9.0+git20140716/debian/changelog 2014-09-22 14:56:21.0
-0300
@@ -1,3 +1,9 @@
+gccxml (0.9.0+git20140716-1ppc64el1) UNRELEASED; urgency=medium
+
+ * Add 'powerpc64le-unknown-linux-gnu' to 'GCC/gcc/config.gcc' (fix FTBFS).
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Mon, 22 Sep 2014
14:55:55 -0300
+
gccxml (0.9.0+git20140716-1) unstable; urgency=medium
* Team upload.
diff -Nru gccxml-0.9.0+git20140716/debian/patches/ppc64el-config-gcc.patch
gccxml-0.9.0+git20140716/debian/patches/ppc64el-config-gcc.patch
--- gccxml-0.9.0+git20140716/debian/patches/ppc64el-config-gcc.patch
1969-12-31 21:00:00.0 -0300
+++ gccxml-0.9.0+git20140716/debian/patches/ppc64el-config-gcc.patch
2014-09-22 14:56:59.0 -0300
@@ -0,0 +1,31 @@
+Index: gccxml-0.9.0+git20140716/GCC/gcc/config.gcc
+===
+--- gccxml-0.9.0+git20140716.orig/GCC/gcc/config.gcc
gccxml-0.9.0+git20140716/GCC/gcc/config.gcc
+@@ -301,7 +301,7 @@ powerpc*-*-*)
+ extra_headers=ppc-asm.h altivec.h spe.h
+ need_64bit_hwint=yes
+ case x$with_cpu in
+- xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456]|xrs64a)
++
xpowerpc64|xpowerpc64le|xdefault64|x6[23]0|x970|xG5|xpower[3456]|xrs64a)
+ cpu_is_64bit=yes
+ ;;
+ esac
+@@ -1692,7 +1692,7 @@ pdp11-*-*)
+ # tmake_file=${tmake_file} rs6000/t-fprules rs6000/t-fprules-fpbit
+ # extra_headers=
+ # ;;
+-powerpc64-*-linux*)
++powerpc64-*-linux* | powerpc64le-*-linux*)
+ tm_file=${tm_file} dbxelf.h elfos.h svr4.h freebsd-spec.h
rs6000/sysv4.h
+ test x$with_cpu != x || cpu_is_64bit=yes
+ test x$cpu_is_64bit != xyes || tm_file=${tm_file} rs6000/default64.h
+@@ -2870,7 +2870,7 @@ case ${target} in
+ eval with_$which=405
+ ;;
+| common \
+- | power | power[23456] | powerpc | powerpc64 \
++ | power | power[23456] | powerpc | powerpc64 |
powerpc64le \
+ | rios | rios1 | rios2 | rsc | rsc1 | rs64a \
+ | 401 | 403 | 405 | 405fp | 440 | 440fp | 505 \
+ | 601 | 602 | 603 | 603e | ec603e | 604 \
diff -Nru gccxml-0.9.0+git20140716/debian/patches/series
gccxml-0.9.0+git20140716/debian/patches/series
--- gccxml-0.9.0+git20140716/debian/patches/series 2014-07-16
05:16:21.0 -0300
+++ gccxml-0.9.0+git20140716/debian/patches/series 2014-09-22
14:56:34.0 -0300
@@ -1,2 +1,3 @@
01_remove-xatexit.diff
debian-tests
+ppc64el-config-gcc.patch
Bug#761926: closed by s...@debian.org (Steve M. Robbins) (Bug#761926: fixed in boost1.55 1.55.0+dfsg-3)
On 09/19/2014 02:24 AM, Debian Bug Tracking System wrote: #761926: boost1.55: fix libkolabxml test-suite error on ppc64el It has been closed by...@debian.org (Steve M. Robbins). Thanks, Steve! -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761926: boost1.55: fix libkolabxml test-suite error on ppc64el
Package: boost1.55
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
This patch fixes this test-suite error of libkolabxml on ppc64el [1].
It is from the boost library shipped with IBM Advance Toolchain, which
is getting fixes/improvements for the Power architecture (e.g.,ppc64el)
that should be submitted upstream soon.
May you please consider it for an upload meanwhile?
Thank you!
[1]
https://buildd.debian.org/status/fetch.php?pkg=libkolabxmlarch=ppc64elver=1.0.2-1stamp=1410666021
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru boost1.55-1.55.0+dfsg/debian/changelog
boost1.55-1.55.0+dfsg/debian/changelog
--- boost1.55-1.55.0+dfsg/debian/changelog 2014-06-10 06:16:51.0
-0300
+++ boost1.55-1.55.0+dfsg/debian/changelog 2014-09-16 17:11:18.0
-0300
@@ -1,3 +1,9 @@
+boost1.55 (1.55.0+dfsg-2ppc64el1) UNRELEASED; urgency=medium
+
+ * ppc64el-fp_traits-ibm-long-double.patch: fix libkolabxml FTBFS on ppc64el.
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Tue, 16 Sep 2014
16:40:22 -0300
+
boost1.55 (1.55.0+dfsg-2) unstable; urgency=medium
* Disable pch on arm64, to avoid FTBFS. (Closes: #750956)
diff -Nru
boost1.55-1.55.0+dfsg/debian/patches/ppc64el-fp_traits-ibm-long-double.patch
boost1.55-1.55.0+dfsg/debian/patches/ppc64el-fp_traits-ibm-long-double.patch
---
boost1.55-1.55.0+dfsg/debian/patches/ppc64el-fp_traits-ibm-long-double.patch
1969-12-31 21:00:00.0 -0300
+++
boost1.55-1.55.0+dfsg/debian/patches/ppc64el-fp_traits-ibm-long-double.patch
2014-09-16 17:11:24.0 -0300
@@ -0,0 +1,45 @@
+Origin:
https://github.com/boost-at/boost_1_55_0/commit/4426b41dab6bb8d110ebda00e0b199b640c7896a
+From: Adhemerval Zanella azane...@linux.vnet.ibm.com
+Date: Tue, 22 Apr 2014 14:31:19 -0500
+Subject: [PATCH] math: Fix fp_traits for IBM long double
+
+This patch fixes the fp_traits_non_native template specialization for
+IBM long double. Current interface does not work correctly for the type
+due the fact for some operations (sign manipulation, for instance), both
+double should be manipulated. For other operations that only require
+the 32 most significand bits (isinf/isnan for instance), the double
+specialization is suffice.
+
+This fixes the issues for getometry test in PPC64LE environment with no
+regreesions on PPC64BE.
+---
+ boost/math/special_functions/detail/fp_traits.hpp | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/boost/math/special_functions/detail/fp_traits.hpp
b/boost/math/special_functions/detail/fp_traits.hpp
+index 50c034d..72ebd4e 100644
+--- a/boost/math/special_functions/detail/fp_traits.hpp
b/boost/math/special_functions/detail/fp_traits.hpp
+@@ -359,6 +359,13 @@ struct fp_traits_non_nativelong double,
extended_double_precision
+
+ // PowerPC extended double precision format (128 bits)
+
++// Current 'fp_traits_non_native' does not work correctly with IBM long double
++// due the fact for some operations, like sign manipulation, the algorithm
++// should manipulate both 'double' value. For algorithms that only depend on
++// the most significand 32 bits (for instance, isinf or isnan), using the
++// template double especialization is suffice.
++
++#if 0
+ template
+ struct fp_traits_non_nativelong double, extended_double_precision
+ {
+@@ -391,7 +398,7 @@ struct fp_traits_non_nativelong double,
extended_double_precision
+ BOOST_STATIC_ASSERT(false);
+ #endif
+ };
+-
++#endif
+
+ // long double (64 bits), Motorola 68K
+
diff -Nru boost1.55-1.55.0+dfsg/debian/patches/series
boost1.55-1.55.0+dfsg/debian/patches/series
--- boost1.55-1.55.0+dfsg/debian/patches/series 2013-12-28 21:14:48.0
-0200
+++ boost1.55-1.55.0+dfsg/debian/patches/series 2014-09-16 17:11:24.0
-0300
@@ -7,3 +7,4 @@
boost-1.55.0-001-log_fix_dump_avx2.patch
ELFv2-libboost1.54-dev-context-asm.patch
boost-python-examples.patch
+ppc64el-fp_traits-ibm-long-double.patch
Bug#761934: libkolabxml: add ppc64el symbols (fix FTBFS)
Package: src:libkolabxml Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el Hi, The attached patch adds ppc64el to the symbols file, fixing libkolabxml FTBFS. The changes are: $ sed 's,!ppc64,!ppc64 !ppc64el,' -i debian/libkolabxml1.symbols $ sed 's, ppc64, ppc64 ppc64el,' -i debian/libkolabxml1.symbols With it applied (and a patch for boost1.55 from #761926), the package builds successfully on ppc64el. (build log attached). [...] dpkg-genchanges -sa ../libkolabxml_1.0.2-1ppc64el1_ppc64el.changes dpkg-genchanges: including full source code in upload dpkg-source --after-build libkolabxml-1.0.2 dpkg-buildpackage: full upload (original source is included) May you please consider it for an upload? Thanks! -- Mauricio Faria de Oliveira IBM Linux Technology Center libkolabxml-ppc64el-symbols.debdiff.xz Description: application/xz libkolabxml_1.0.2-1ppc64el1_ppc64el.build.xz Description: application/xz
Bug#761466: libkolabxml: FTBFS test-case failure fixed with boost1.55 patch
Problem in boost1.55 library. Please see #761926. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749060: klibc: fix segfault on ppc64el: change severity
retitle 749060 klibc: ppc64el: segfault in dyn-linked binaries severity 749060 important tags 749060 patch upstream thanks -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754213: closed by Ben Hutchings b...@decadent.org.uk (Bug#754213: fixed in linux-tools 3.16-2)
Hi Ben, On 09/09/2014 09:51 AM, Debian Bug Tracking System wrote: #754213: linux-tools: build on ppc64el It has been closed by Ben Hutchingsb...@decadent.org.uk. Thanks /a lot/ for properly fixing this and providing that detailed explanation, it was very educational for me - really appreciated. The package has just made the archive [1], and I can successfully install it and run 'perf stat sleep 1' on ppc64el, for example. I believe your general fix should also work for ppc64 and alpha, which have an original bug report for this issue (#747151). The package build still wasn't attempted on those arches [2, 3], but in gratefulness, trying to provide some useful service back, I'll keep an eye there and report on that bug. Best regards, [1] https://buildd.debian.org/status/fetch.php?pkg=linux-toolsarch=ppc64elver=3.16-2stamp=1410267819 [2] http://buildd.debian-ports.org/status/package.php?p=linux-toolssuite=sida=alpha [3] http://buildd.debian-ports.org/status/package.php?p=linux-toolssuite=sida=ppc64 -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760844: git FTBFS on ppc64el
Hi Jonathan, On 09/08/2014 04:54 PM, Jonathan Nieder wrote: [Subject: package build finished successfully, although] Please keep in mind that these appear as emails in a crowded inbox, where the subject line can provide useful context. Apologies. I believe I provided such great example of a totally context- free / useless subject line. :-) Thanks for the respectful reminder. It looks like the same bug as #757402, which is a bug in the testsuite (not in git itself). What's odd is that ppc64el the corresponding problem doesn't seem to be 100% reproducible --- e.g. in the log you mentioned, the packaging runs tests twice, and they failed the first time and passed the second time. Based on your knowledge of the arch, does that make sense? Would limiting a process to a 64k stack with ulimit -s 64 be expected to make it sometimes fail and sometimes succeed? I'll have to take a deeper look at that soon. Although the ELFv2 ABI (introduced in/for ppc64el) has differences/reductions in stack frame [1], that should be set/assembly written at compile-time - so it isn't expected to vary at run-time. (we should expect consistency there :) I'm not familiar with the git/testsuite, so I may be missing something. Maybe it's something in it or the environment. So I'll set-up some time to go through it and analyze this issue soon. Thanks for the pointers and context. [1] https://sourceware.org/ml/binutils/2013-10/msg00371.html -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749060: [PATCH] [klibc] ppc64: ELFv2: Load TOC value in system call stub
This fixes a segmentation fault in the system call's error handling path with
dynamically-linked binaries on PowerPC64 little endian. The system call stub
wasn't loading up r2 with the appropriate TOC value in its global entry point.
The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent
one can also be found in the LOCALENTRY macro in glibc [2].
On the ELFv2 ABI (see [1]):
- The global entry point is expected to load up r2 with the appropriate TOC
value for this function.
- The local entry point expects r2 to be set up to the current TOC.
The problem happened with dynamically-linked binaries because:
- the system call is an indirect call (via global entry point) from the binary
to the shared library, landing in the syscall stub (which didn't load up r2
with the TOC of the shared library)
- its branch to __syscall_error is a direct call (via local entry point) within
the shared library, landing in the function (which expects r2 to be set up to
that TOC)
- when the function attempts to store errno (in an address relative to the
TOC),
that address incorrectly pointed to a read-only segment -- segmentation
fault.
The problem didn't happen with statically-linked binaries because the TOC value
wasn't different on that case.
Thanks and credits to Alan Modra and Ulrich Weigand, for helping with this and
pointing out the solution.
[1] https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01141.html
[2] https://www.sourceware.org/ml/libc-alpha/2013-11/msg00315.html
Signed-off-by: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com
---
usr/klibc/arch/ppc64/sysstub.ph |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/usr/klibc/arch/ppc64/sysstub.ph b/usr/klibc/arch/ppc64/sysstub.ph
index b3f6e38..a0c6d41 100644
--- a/usr/klibc/arch/ppc64/sysstub.ph
+++ b/usr/klibc/arch/ppc64/sysstub.ph
@@ -18,6 +18,9 @@ sub make_sysstub($@) {
#if _CALL_ELF == 2
.type ${fname},\@function
${fname}:
+0: addis 2,12,(.TOC.-0b)\@ha
+ addi2,2,(.TOC.-0b)\@l
+ .localentry ${fname},.-${fname}
#else
.section .opd,aw
.balign 8
--
1.7.1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749060: [klibc] [PATCH] ppc64: ELFv2: Load TOC value in system call stub
On 09/09/2014 07:17 PM, Mauricio Faria de Oliveira wrote: This fixes a segmentation fault in the system call's error handling path with dynamically-linked binaries on PowerPC64 little endian. The system call stub wasn't loading up r2 with the appropriate TOC value in its global entry point. Test results on Debian ppc64el. Probably too detailed, but documented. Before: --- Test-case: 'stat.shared' segfaults with a non-existing file $ rm -f no-file $ usr/klibc/tests/stat no-file no-file: No such file or directory $ usr/klibc/tests/stat.shared no-file Segmentation fault Test-suite: Comparing statically- vs. dinamically-linked binaries. One difference: fcntl's return code. $ find usr/klibc/tests/ -type f -executable -not -name '*.g' -not -name '*.shared' \ | while read test; do $test /dev/null 21; rc=$?; [ $rc -ne 0 ] echo failed: $test (rc: $rc); done | sort failed: usr/klibc/tests/fcntl (rc: 1) failed: usr/klibc/tests/fnmatch (rc: 139) failed: usr/klibc/tests/testrand48 (rc: 1) $ find usr/klibc/tests/ -type f -executable -not -name '*.g' -name '*.shared' \ | while read test; do $test /dev/null 21; rc=$?; [ $rc -ne 0 ] echo failed: $test (rc: $rc); done | sort failed: usr/klibc/tests/fcntl.shared (rc: 139) failed: usr/klibc/tests/fnmatch.shared (rc: 139) failed: usr/klibc/tests/testrand48.shared (rc: 1) Generated instructions: No r2 setup before branch to local entry point (+8 offset). (gdb) disass Dump of assembler code for function stat: = 0x0f007854 +0: li r0,106 0x0f007858 +4: sc 0x0f00785c +8: bnslr 0x0f007860 +12:b 0xf012cb4 __syscall_error+8 End of assembler dump. After: - Test-case: 'stat.shared' no longer segfaults with a non-existing file $ rm -f no-file $ usr/klibc/tests/stat no-file no-file: No such file or directory $ usr/klibc/tests/stat.shared no-file no-file: No such file or directory Test-suite: No regressions introduced. No differences between statically- vs. dynamically-linked binaries. $ find usr/klibc/tests/ -type f -executable -not -name '*.g' -not -name '*.shared' | while read test; do $test /dev/null 21; rc=$?; [ $rc -ne 0 ] echo failed: $test (rc: $rc); done | sort failed: usr/klibc/tests/fcntl (rc: 1) failed: usr/klibc/tests/fnmatch (rc: 139) failed: usr/klibc/tests/testrand48 (rc: 1) $ find usr/klibc/tests/ -type f -executable -not -name '*.g' -name '*.shared' | while read test; do $test /dev/null 21; rc=$?; [ $rc -ne 0 ] echo failed: $test (rc: $rc); done | sort failed: usr/klibc/tests/fcntl.shared (rc: 1) failed: usr/klibc/tests/fnmatch.shared (rc: 139) failed: usr/klibc/tests/testrand48.shared (rc: 1) Generated instructions Now r2 _is_ setup before branch to local entry point (+8 offset). (gdb) disass Dump of assembler code for function stat: = 0x0f007a84 +0: lis r2,3843 0x0f007a88 +4: addir2,r2,-3816 0x0f007a8c +8: li r0,106 0x0f007a90 +12:sc 0x0f007a94 +16:bnslr 0x0f007a98 +20:b 0xf0131cc __syscall_error+8 End of assembler dump. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749060: klibc: fix segfault on ppc64el: patch submitted upstream
Package: src:klibc
Hi maks,
This problem is finally understood and fixed, thanks to Alan Modra and
Ulrich Weigand (binutils / ELFv2 experts).
The patch was submitted upstream. Here's a debdiff for your convenience.
I would ask you (or a non-maintainer) to consider it for an upload,
since any initrd generated without it fails to boot, with a segfault.
Thank you,
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru klibc-2.0.3/debian/changelog klibc-2.0.3/debian/changelog
--- klibc-2.0.3/debian/changelog2014-04-21 14:52:41.0 -0300
+++ klibc-2.0.3/debian/changelog2014-09-09 19:37:02.0 -0300
@@ -1,3 +1,10 @@
+klibc (2.0.3-1ppc64el1) UNRELEASED; urgency=medium
+
+ * Add ppc64el-load-toc-syscall-stub.patch: fix segfault on dynamically-linked
+binaries on ppc64el. (Closes: #749060)
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Tue, 09 Sep 2014
19:33:37 -0300
+
klibc (2.0.3-1) unstable; urgency=medium
* New upstream release (arm64, ppc64) (closes: #698018, #744884)
diff -Nru klibc-2.0.3/debian/patches/ppc64el-load-toc-syscall-stub.patch
klibc-2.0.3/debian/patches/ppc64el-load-toc-syscall-stub.patch
--- klibc-2.0.3/debian/patches/ppc64el-load-toc-syscall-stub.patch
1969-12-31 21:00:00.0 -0300
+++ klibc-2.0.3/debian/patches/ppc64el-load-toc-syscall-stub.patch
2014-09-09 19:35:38.0 -0300
@@ -0,0 +1,55 @@
+Subject: [klibc] [PATCH] ppc64: ELFv2: Load TOC value in system call stub
+Origin: http://www.zytor.com/pipermail/klibc/2014-September/003603.html
+
+This fixes a segmentation fault in the system call's error handling path with
+dynamically-linked binaries on PowerPC64 little endian. The system call stub
+wasn't loading up r2 with the appropriate TOC value in its global entry point.
+
+The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent
+one can also be found in the LOCALENTRY macro in glibc [2].
+
+On the ELFv2 ABI (see [1]):
+ - The global entry point is expected to load up r2 with the appropriate TOC
+ value for this function.
+ - The local entry point expects r2 to be set up to the current TOC.
+
+The problem happened with dynamically-linked binaries because:
+ - the system call is an indirect call (via global entry point) from the binary
+ to the shared library, landing in the syscall stub (which didn't load up r2
+ with the TOC of the shared library)
+ - its branch to __syscall_error is a direct call (via local entry point)
within
+ the shared library, landing in the function (which expects r2 to be set up
to
+ that TOC)
+ - when the function attempts to store errno (in an address relative to the
TOC),
+ that address incorrectly pointed to a read-only segment -- segmentation
fault.
+
+The problem didn't happen with statically-linked binaries because the TOC value
+wasn't different on that case.
+
+Thanks and credits to Alan Modra and Ulrich Weigand, for helping with this and
+pointing out the solution.
+
+[1] https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01141.html
+[2] https://www.sourceware.org/ml/libc-alpha/2013-11/msg00315.html
+
+Signed-off-by: Mauricio Faria de Oliveira mauricfo at linux.vnet.ibm.com
+---
+ usr/klibc/arch/ppc64/sysstub.ph |3 +++
+ 1 files changed, 3 insertions(+), 0 deletions(-)
+
+diff --git a/usr/klibc/arch/ppc64/sysstub.ph b/usr/klibc/arch/ppc64/sysstub.ph
+index b3f6e38..a0c6d41 100644
+--- a/usr/klibc/arch/ppc64/sysstub.ph
b/usr/klibc/arch/ppc64/sysstub.ph
+@@ -18,6 +18,9 @@ sub make_sysstub($@) {
+ #if _CALL_ELF == 2
+ .type ${fname},\@function
+ ${fname}:
++0:addis 2,12,(.TOC.-0b)\@ha
++ addi2,2,(.TOC.-0b)\@l
++ .localentry ${fname},.-${fname}
+ #else
+ .section .opd,aw
+ .balign 8
+--
+1.7.1
diff -Nru klibc-2.0.3/debian/patches/series klibc-2.0.3/debian/patches/series
--- klibc-2.0.3/debian/patches/series 2014-04-21 14:10:10.0 -0300
+++ klibc-2.0.3/debian/patches/series 2014-09-09 19:33:26.0 -0300
@@ -4,3 +4,4 @@
insmod
multiarch-include-path
Fix-minimal-mv-to-work-across-fs
+ppc64el-load-toc-syscall-stub.patch
Bug#760844: package build finished successfully, although
Package: src:git Hi Andi, Thanks for spotting this one. Although that failure is indeed in the build log, the build finishes successfully [0]. Do you think it's a more serious problem? The packages was built and installed in the archive some time ago [1], and the git binary is in the binary package: git_2.1.0-1_ppc64el.deb [...] -rwxr-xr-x root/root 1895560 2014-09-08 20:45 ./usr/lib/git-core/git [...] Kind regards, [0] https://buildd.debian.org/status/fetch.php?pkg=gitarch=ppc64elver=1%3A2.1.0-1stamp=1410201979 [1] https://buildd.debian.org/status/package.php?a=ppc64elsuite=sidp=git -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759389: linux: ppc64el: do NOT switch to vmlinu*z*
Hi Aurelien, On 08/29/2014 06:49 PM, Aurelien Jarno wrote: On Fri, Aug 29, 2014 at 10:15:47AM -0300, Mauricio Faria de Oliveira wrote: I have to ask you to please revert the vmlinu*z* patch. Some of the ppc64el target platforms can only boot vmlinu*x* (no support for compressed kernels). Really sorry for taking your time. No problem, I have just reverted this. Thanks for reverting it. (If it's not too much too ask, now that the revert-panic [for me] ended) We can drop the patch 'ppc64el-disable-zImage.patch' now that the zImage targets (i.e., zImage.pseries) don't cause build errors anymore. The attached debdiff does that. It was actually part of the previous patch.. so I probably should have asked you to just revert the 'defines' changes previously.. apologies; but I couldn't let go another thing like this w/out re-testing it. :/ I have successfully built linux-3.16-1~exp1 with it, and booted on that platform I mentioned (just to /triple/-check the vmlinux file had no sign of vmlinuz compression whatsoever.. even knowing this is dumb :). Thanks again. Embarrassingly funny, -- Mauricio Faria de Oliveira IBM Linux Technology Center diff -Nru linux-3.16/debian/changelog linux-3.16/debian/changelog --- linux-3.16/debian/changelog 2014-08-09 20:58:13.0 + +++ linux-3.16/debian/changelog 2014-09-02 12:00:33.0 + @@ -1,3 +1,11 @@ +linux (3.16-1~exp1ppc64el1) UNRELEASED; urgency=medium + + * [ppc64el] debian/patches/debian/ppc64el-disable-zImage.patch: remove patch. +The 'powerpc/boot: 64bit little endian wrapper' patch-set is in linux 3.16, +thus the default make/image-y target is OK now. + + -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Thu, 21 Aug 2014 15:25:35 -0300 + linux (3.16-1~exp1) experimental; urgency=medium * New upstream release: http://kernelnewbies.org/Linux_3.16 diff -Nru linux-3.16/debian/patches/debian/ppc64el-disable-zImage.patch linux-3.16/debian/patches/debian/ppc64el-disable-zImage.patch --- linux-3.16/debian/patches/debian/ppc64el-disable-zImage.patch 2014-06-16 12:08:34.0 + +++ linux-3.16/debian/patches/debian/ppc64el-disable-zImage.patch 1970-01-01 00:00:00.0 + @@ -1,49 +0,0 @@ -From: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com -Date: Wed, 4 Jun 2014 09:06:27 -0300 -Subject: ppc64el: kernel: patch: temporarily disable zImage - -Debian ppc64el will wait for the 'powerpc/boot: 64bit little endian wrapper' -(zImage) patches upstream rather than shipping 32-bit tools for zImage. The -patches are currently in Ben Herrenschmidt's linux-next tree [1]. - -The patches are not being carried over instead of this workaround because, -even without both, the build process does produces vmlinux, only failing for -zImage. So, it's ok to just work-around this for now, as we pick vmlinux. - -The workaround patch just avoids this build error: - - [...] - LD vmlinux - SYSMAP System.map - [...] - WRAParch/powerpc/boot/zImage.pseries - ld: unrecognised emulation mode: elf32ppc - Supported emulations: elf64lppc elf32lppc elf32lppclinux elf32lppcsim - make[6]: *** [arch/powerpc/boot/zImage.pseries] Error 1 - make[5]: *** [zImage] Error 2 - -[1] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?qt=grepq=powerpc%2Fboot -(15 commits with message prefix 'powerpc/boot:' dated of 2014-04-28) - -Signed-off-by: Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com -Index: linux-3.14.2/arch/powerpc/boot/Makefile -=== linux-3.14.2.orig/arch/powerpc/boot/Makefile 2014-05-02 16:52:37.0 -0300 -+++ linux-3.14.2/arch/powerpc/boot/Makefile2014-05-07 09:39:11.0 -0300 -@@ -344,6 +344,15 @@ - $(obj)/%.dtb: $(src)/dts/%.dts FORCE - $(call if_changed_dep,dtc) - -+# Debian ppc64el will wait for the 'powerpc/boot: 64bit little endian wrapper' -+# (zImage) patches upstream rather than shipping 32-bit tools for zImage. -+# This makes the next conditional block to pick vmlinux.strip as image-y. -+ifdef CONFIG_PPC64 -+ifdef CONFIG_CPU_LITTLE_ENDIAN -+image-y := -+endif -+endif -+ - # If there isn't a platform selected then just strip the vmlinux. - ifeq (,$(image-y)) - image-y := vmlinux.strip diff -Nru linux-3.16/debian/patches/series linux-3.16/debian/patches/series --- linux-3.16/debian/patches/series2014-08-07 20:27:15.0 + +++ linux-3.16/debian/patches/series2014-09-02 12:00:33.0 + @@ -6,7 +6,6 @@ debian/mips-disable-werror.patch debian/arch-sh4-fix-uimage-build.patch debian/powerpcspe-omit-uimage.patch -debian/ppc64el-disable-zImage.patch features/all/Kbuild-kconfig-Verbose-version-of-listnewconfig.patch # Fixes/improvements to firmware loading
Bug#754093: debian-installer: ppc64el: do NOT switch to vmlinu*z*
Hi, Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com: We would like to switch the kernel on ppc64el to vmlinuz starting with 3.16 (introduction of zImage support for 64el). Please do NOT apply the vmlinu*z* patch. Just ignore it. Some of the ppc64el target platforms can only boot vmlinu*x* (no support for compressed kernels). Really sorry for taking your time. (the build-dep on grub-ieee1275-bin is still needed, as explained) -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759389: linux: ppc64el: do NOT switch to vmlinu*z*
Hi Aurelien, On 08/27/2014 04:42 AM, Aurelien Jarno wrote: Thanks, I have just committed this patch, it will be in the next upload. I have to ask you to please revert the vmlinu*z* patch. Some of the ppc64el target platforms can only boot vmlinu*x* (no support for compressed kernels). Really sorry for taking your time. -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759550: ruby-ffi: (tracking bug) fix FTBFS on ppc64el (variadic arguments call)
Package: src:ruby-ffi Version: 1.9.3debian-2 Tags: patch pending User: debian-powe...@lists.debian.org Usertags: ppc64el Hi, Antonio. This bug is just to track the test-suite failure on ppc64el due to variadic arguments call, so we can put a bug number on wanna-build. I see you already committed a patch for that on debian source repository [1], to be released at your convenience. Building from that commit (debcheckout) builds successfully on ppc64el. (build log attached) Thanks, [1] http://anonscm.debian.org/cgit/pkg-ruby-extras/ruby-ffi.git/commit/?id=e963c03845fa40c3761940ad9cc4ef620487d2c0 -- Mauricio Faria de Oliveira IBM Linux Technology Center ruby-ffi_1.9.3debian-3_ppc64el.build.xz Description: application/xz
Bug#754213: (no subject)
Package: src:linux Hi Ben, On 08/26/2014 05:05 AM, Ben Hutchings wrote: The first build failure (requiring __SANE_USERSPACE_TYPES__) appears to be fixed upstream in 3.16. [...] I'm still hitting that w/ 3.16 (linux-tools from trunk, plus .orig from 3.16~rc7~exp1 or upstream 3.16.1 -- not usual, but I believe it was supposed to work). May you please point where/commit/excerpt you see this fixed? I could only find a related commit for MIPS [1], but nothing for powerpc. Thanks! Build log excerpt: gcc -include real-lsb-32/types.h -I/root/linux-tools-3.16/include -S -o real-lsb-32/devicetable-offsets.s /root/linux-tools-3.16/scripts/mod/devicetable-offsets.c In file included from ./real-lsb-32/types.h:1:0, from command-line:0: /root/linux-tools-3.16/include/linux/types.h:149:9: error: unknown type name 'u32' typedef u32 dma_addr_t; ^ /root/linux-tools-3.16/include/linux/types.h:165:9: error: unknown type name 'u32' typedef u32 phys_addr_t; ^ Makefile.real:16: recipe for target 'real-lsb-32/devicetable-offsets.s' failed [1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=f4b3aa7cd9d32407670e67238c5ee752bb98f481 -- Mauricio Faria de Oliveira IBM Linux Technology Center -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720689: cernlib: fix FTBFS with GNU make 3.82+ (patch available)
Package: src:cernlib
Version: 20061220+dfsg3-4
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el
Hi,
The attached patch (trivial) fixes the issue w/ debian.control.new.
It was suggested/provided by Michael Tautschnig on a previous message,
and I'am attaching a debdiff w/ it for your convenience.
I can confirm the comparison of debian/control{ , .new} is now passing.
Currently it would fail as in [1]
Thanks!
[1]
https://buildd.debian.org/status/fetch.php?pkg=cernlibarch=ppc64elver=20061220%2Bdfsg3-4stamp=1408774563
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru cernlib-20061220+dfsg3/debian/cernlib-debian.mk
cernlib-20061220+dfsg3/debian/cernlib-debian.mk
--- cernlib-20061220+dfsg3/debian/cernlib-debian.mk 2013-08-24
06:16:07.0 -0300
+++ cernlib-20061220+dfsg3/debian/cernlib-debian.mk 2014-08-28
10:16:21.0 -0300
@@ -177,7 +177,7 @@
-chmod a+x $(ADDONDIR)/scripts/[a-z]*
debian/control.new: $(wildcard debian/control.d/*.control)
- cat $^ $@
+ cat $(sort $^) $@
debian/control: debian/control.new
cp -f $ $@
diff -Nru cernlib-20061220+dfsg3/debian/changelog
cernlib-20061220+dfsg3/debian/changelog
--- cernlib-20061220+dfsg3/debian/changelog 2013-08-24 06:16:07.0
-0300
+++ cernlib-20061220+dfsg3/debian/changelog 2014-08-28 10:22:37.0
-0300
@@ -1,3 +1,12 @@
+cernlib (20061220+dfsg3-4ppc64el1) UNRELEASED; urgency=medium
+
+ * Fix 'debian/control.new' for GNU make 3.82+ (Closes: #720689)
+Thanks Michael Tautschnig. New versions of GNU make don't 'sort' the output
+of 'wildcard' anymore. This is reported in the following GNU make announce:
+https://lists.gnu.org/archive/html/info-gnu/2010-07/msg00023.html
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Thu, 28 Aug 2014
10:03:28 -0300
+
cernlib (20061220+dfsg3-4) unstable; urgency=low
* cernlib-base-dev: depends on dpkg-dev to fix Multiarch support.
Bug#720689: cernlib: build successful on ppc64el
Package: src:cernlib FYI, the build w/ the mentioned patch finishes succesfully on ppc64el. (log attached) -- Mauricio Faria de Oliveira IBM Linux Technology Center cernlib-20061220+dfsg3-ppc64el1_ppc64el.build.xz Description: application/xz
Bug#752415: mozjs: fix FTBFS on ppc64el: add to symbols file (patch available)
Package: src:mozjs
Version: 1.8.5-1.0.0+dfsg-4.2
Tags: patch
Hi,
I'm attaching an updated patch for current mozjs on sid, which
fails to build on ppc64el [1].
May you please consider it for an upload?
With it applied the package builds successfully:
[...]
dh_makeshlibs
-O--sourcedirectory=/root/mozjs-1.8.5-1.0.0\+dfsg/js/src
dh_shlibdeps -O--sourcedirectory=/root/mozjs-1.8.5-1.0.0\+dfsg/js/src
[...]
dpkg-buildpackage: full upload (original source is included)
Thanks!
[1]
https://buildd.debian.org/status/fetch.php?pkg=mozjsarch=ppc64elver=1.8.5-1.0.0%2Bdfsg-4.2stamp=1408831880
--
Mauricio Faria de Oliveira
IBM Linux Technology Center
diff -Nru mozjs-1.8.5-1.0.0+dfsg/debian/changelog
mozjs-1.8.5-1.0.0+dfsg/debian/changelog
--- mozjs-1.8.5-1.0.0+dfsg/debian/changelog 2014-08-23 17:54:37.0
-0300
+++ mozjs-1.8.5-1.0.0+dfsg/debian/changelog 2014-08-28 12:27:19.0
-0300
@@ -1,3 +1,9 @@
+mozjs (1.8.5-1.0.0+dfsg-4.2ppc64el1) UNRELEASED; urgency=medium
+
+ * Add ppc64el to symbols file (thanks Fernando Seiti Furusato) (Closes:
#752415)
+
+ -- Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com Thu, 28 Aug 2014
12:25:57 -0300
+
mozjs (1.8.5-1.0.0+dfsg-4.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru mozjs-1.8.5-1.0.0+dfsg/debian/libmozjs185-1.0.symbols
mozjs-1.8.5-1.0.0+dfsg/debian/libmozjs185-1.0.symbols
--- mozjs-1.8.5-1.0.0+dfsg/debian/libmozjs185-1.0.symbols 2014-04-02
15:00:53.0 -0300
+++ mozjs-1.8.5-1.0.0+dfsg/debian/libmozjs185-1.0.symbols 2014-08-28
12:25:44.0 -0300
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 1.8.5-1.0.0+dfsg amd64 armel armhf hurd-i386 i386
ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
+# SymbolsHelper-Confirmed: 1.8.5-1.0.0+dfsg amd64 armel armhf hurd-i386 i386
ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc ppc64el s390 s390x sparc
libmozjs185.so.1.0 libmozjs185-1.0 #MINVER#
(arch=armhf)InjectJaegerReturn@Base 1.8.5-1.0.0+dfsg
JS_AddArgumentFormatter@Base 1.8.5-1.0.0+dfsg
@@ -529,16 +529,16 @@
(arch=armhf)JaegerThrowpoline@Base 1.8.5-1.0.0+dfsg
(arch=armhf)JaegerTrampoline@Base 1.8.5-1.0.0+dfsg
(arch=armhf)JaegerTrampolineReturn@Base 1.8.5-1.0.0+dfsg
- (arch=!amd64 !arm64 !ia64 !kfreebsd-amd64
!s390x)_Z12js_EnumerateP9JSContextP8JSObject11JSIterateOpPN2js5ValueEPi@Base
1.8.5-1.0.0+dfsg
- (arch=amd64 arm64 ia64 kfreebsd-amd64
s390x)_Z12js_EnumerateP9JSContextP8JSObject11JSIterateOpPN2js5ValueEPl@Base
1.8.5-1.0.0+dfsg
+ (arch=!amd64 !arm64 !ia64 !kfreebsd-amd64 !ppc64el
!s390x)_Z12js_EnumerateP9JSContextP8JSObject11JSIterateOpPN2js5ValueEPi@Base
1.8.5-1.0.0+dfsg
+ (arch=amd64 arm64 ia64 kfreebsd-amd64 ppc64el
s390x)_Z12js_EnumerateP9JSContextP8JSObject11JSIterateOpPN2js5ValueEPl@Base
1.8.5-1.0.0+dfsg
_Z14js_DateGetDateP9JSContextP8JSObject@Base 1.8.5-1.0.0+dfsg
_Z14js_DateGetYearP9JSContextP8JSObject@Base 1.8.5-1.0.0+dfsg
_Z14js_DateIsValidP9JSContextP8JSObject@Base 1.8.5-1.0.0+dfsg
_Z14js_IntervalNowv@Base 1.8.5-1.0.0+dfsg
_Z15js_DateGetHoursP9JSContextP8JSObject@Base 1.8.5-1.0.0+dfsg
_Z15js_DateGetMonthP9JSContextP8JSObject@Base 1.8.5-1.0.0+dfsg
- (arch=!amd64 !arm64 !ia64 !kfreebsd-amd64
!s390x)_Z15js_FindPropertyP9JSContextiPP8JSObjectS3_PP10JSProperty@Base
1.8.5-1.0.0+dfsg
- (arch=amd64 arm64 ia64 kfreebsd-amd64
s390x)_Z15js_FindPropertyP9JSContextlPP8JSObjectS3_PP10JSProperty@Base
1.8.5-1.0.0+dfsg
+ (arch=!amd64 !arm64 !ia64 !kfreebsd-amd64 !ppc64el
!s390x)_Z15js_FindPropertyP9JSContextiPP8JSObjectS3_PP10JSProperty@Base
1.8.5-1.0.0+dfsg
+ (arch=amd64 arm64 ia64 kfreebsd-amd64 ppc64el
s390x)_Z15js_FindPropertyP9JSContextlPP8JSObjectS3_PP10JSProperty@Base
1.8.5-1.0.0+dfsg
_Z15js_IsTypedArrayP8JSObject@Base 1.8.5-1.0.0+dfsg
_Z16js_CloseIteratorP9JSContextP8JSObject@Base 1.8.5-1.0.0+dfsg
_Z16js_IsArrayBufferP8JSObject@Base 1.8.5-1.0.0+dfsg
@@ -546,8 +546,8 @@
_Z16js_ValueToSourceP9JSContextRKN2js5ValueE@Base 1.8.5-1.0.0+dfsg
_Z17js_DateGetMinutesP9JSContextP8JSObject@Base 1.8.5-1.0.0+dfsg
_Z17js_DateGetSecondsP9JSContextP8JSObject@Base 1.8.5-1.0.0+dfsg
- (arch=!amd64 !arm64 !ia64 !kfreebsd-amd64
!s390x)_Z17js_LookupPropertyP9JSContextP8JSObjectiPS2_PP10JSProperty@Base
1.8.5-1.0.0+dfsg
- (arch=amd64 arm64 ia64 kfreebsd-amd64
s390x)_Z17js_LookupPropertyP9JSContextP8JSObjectlPS2_PP10JSProperty@Base
1.8.5-1.0.0+dfsg
+ (arch=!amd64 !arm64 !ia64 !kfreebsd-amd64 !ppc64el
!s390x)_Z17js_LookupPropertyP9JSContextP8JSObjectiPS2_PP10JSProperty@Base
1.8.5-1.0.0+dfsg
+ (arch=amd64 arm64 ia64 kfreebsd-amd64 ppc64el
s390x)_Z17js_LookupPropertyP9JSContextP8JSObjectlPS2_PP10JSProperty@Base
1.8.5-1.0.0+dfsg
_Z17js_ObjectIsRegExpP8JSObject@Base 1.8.5-1.0.0+dfsg
(subst)_Z18JS_StructuredCloneP9JSContext{uint64_t}P{uint64_t}PFP8JSObjectS0_P23JSStructuredCloneReaderjjPvEPK26JSStructuredCloneCallbacksS6_@Base
1.8.5-1.0.0+dfsg
