Bug#1072244: Segmentation fault on startup
Package: wxglade Version: 1.0.5+repack-2 Severity: grave Tags: patch Wxglade crashes with a segmentation fault on startup. See below for the output. This is fixed upstream by this commit: https://github.com/wxGlade/wxGlade/commit/05943a8374a24b862e76f03643a775c09582703f I also attached this as a patch to this bug report. Regards Gaudenz $ wxglade INFO: Starting wxGlade version "1.0.5+repack" on Python 3.11.9 INFO: Using wxPython 4.2.1 INFO: Loading "wconfig" modules from /usr/share/wxglade/widgets/widgets.txt: INFO: Load code generators: INFO: C++ generator loaded INFO: lisp generator loaded INFO: XRC generator loaded INFO: perl generator loaded INFO: python generator loaded INFO: Loading widgets from /usr/share/wxglade/widgets/widgets.txt: INFO: frame INFO: dialog INFO: panel INFO: notebook INFO: splitter_window INFO: button INFO: toggle_button INFO: bitmap_button INFO: spin_button INFO: text_ctrl INFO: choice INFO: combo_box INFO: list_box INFO: check_list_box INFO: checkbox INFO: radio_button INFO: radio_box INFO: spin_ctrl INFO: spin_ctrl_double INFO: slider INFO: gauge 22:45:39: Debug: Adding duplicate image handler for 'Windows bitmap file' 22:45:39: Debug: Adding duplicate animation handler for '1' type 22:45:39: Debug: Adding duplicate animation handler for '2' type INFO: calendar_ctrl INFO: generic_calendar_ctrl INFO: datepicker_ctrl INFO: list_ctrl INFO: tree_ctrl INFO: grid INFO: static_text INFO: hyperlink_ctrl INFO: static_line INFO: static_bitmap INFO: spacer INFO: property_grid_manager INFO: search_ctrl INFO: custom_widget INFO: menubar INFO: toolbar INFO: statusbar INFO: Load sizer generators: INFO: for C++ INFO: for lisp INFO: for XRC INFO: for perl INFO: for python Segmentation fault -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wxglade depends on: ii python3 3.11.8-1 ii python3-wxgtk4.0 4.2.1+dfsg-3+b2 wxglade recommends no packages. wxglade suggests no packages. -- no debconf information >From 05943a8374a24b862e76f03643a775c09582703f Mon Sep 17 00:00:00 2001 From: DietmarSchwertberger Date: Sat, 11 May 2024 19:27:49 +0200 Subject: [PATCH] destroy dummy panel later, to work around issue #547 --- main.py | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/main.py b/main.py index a0a410c8..a68d8c9b 100644 --- a/main.py +++ b/main.py @@ -89,10 +89,11 @@ def __init__(self, parent): sizer.Add(self.notebook, 1, wx.EXPAND, 0) # for GTK3: add a panel to determine page size -p = wx.Panel(self.notebook) +self._dummy_page = p = wx.Panel(self.notebook) self.notebook.AddPage(p, "panel") self._notebook_decoration_size = None p.Bind(wx.EVT_SIZE, self.on_panel_size) +self._edit_triggered = False # for MSW to avoid multiple calls to set_widget self.SetSizer(sizer) self.Layout() @@ -153,8 +154,12 @@ def create_editor(self, edit_widget): self.notebook.Hide() # remember the notebook page to be selected -selection = self.notebook.GetSelection() -select_page = self.pagenames[selection] if selection!=-1 else None +if self._dummy_page or not self.pagenames: +self._dummy_page = None +select_page = None +else: +selection = self.notebook.GetSelection() +select_page = self.pagenames[selection] if selection!=-1 else None # clear notebook pages #self.notebook.DeleteAllPages() # deletes also the windows on the pages @@ -231,6 +236,7 @@ def end_page(self, panel, sizer, header, select=False): def _set_page_size(self, scrolled): # set ScrolledWindow and Panel to available size; enable scrolling, if required # gets available size for notebook pages +if not self.pagenames: return # in initialization ws, hs = self.notebook.GetSize() ws -= self._notebook_decoration_size[0] hs -= self._notebook_decoration_size[1] @@ -257,13 +263,16 @@ def on_notebook_size(self, event): def on_panel_s
Bug#937184: Python 3 port of offlineimap underway
There is now a Python 3 port of offlineimap underway: https://github.com/OfflineIMAP/offlineimap/issues/670 AFAICS it looks promising. Please wait with removing from unstable. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#919898: Bug #919898 in ceph marked as pending
Control: tag -1 pending Hello, Bug #919898 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/5781cc593e70f0e1bb7d8b402edec681e3ec0875 Add Breaks/Replaces ceph-base (<< 12.2.10+dfsg1-1~) to ceph-common This is needed because the BASH completion file was moved to ceph-common in commit 8c03624e4099ea90bf0bfc9deac43f8755c6b13f. Closes: #919898 (this message was generated automatically) -- Greetings https://bugs.debian.org/919898
Bug#919898: Bug #919898 in ceph marked as pending
Control: tag -1 pending Hello, Bug #919898 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/678015acbbf7e8263212b8fd191a3ef463b4058d Add Breaks/Replaces ceph-base (<< 12.2.10+dfsg1-1~) to ceph-common This is needed because the BASH completion file was moved to ceph-common in commit 8c03624e4099ea90bf0bfc9deac43f8755c6b13f. Closes: #919898 (this message was generated automatically) -- Greetings https://bugs.debian.org/919898
Bug#846950: Please explain what broke nfs-utils for you (Debian Bug #846950)
Control: severity -1 normal Hi Felix I was working through the list of release critical bugs on nfs-utils and looked at this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846950 where you increased the severity to "grave" some time ago. But you did not explain how this broke your installation in a way that you think this is release critical. I agree that supporting all variables and possible configuration variants that are supported by the sysvinit scripts on systemd is a worthwile goal. I don't think this in itself is a release critical bug. You can always use systemd native methods like drop-in configuration snippets to achieve your goal. I'm downgrading the severity again at the moment, please feel free to upgrade again with an explanation how this actually breaks your system in a way that is not just a misconfiguration. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#901462: Turning off CONFIG_ACPI_DSDT is not enough
Hi I tried to work on this during the BSP in Bern. While I think that compatibility with QEMU 1.3 and older is no longer needed in Debian I failed to compile the package with CONFIG_ACPI_DSDT turned off. To me it looks like this is rather a runtime than a compile time option and the hex tables are still compiled into the binary even if this is turned off. As I don't understand enough of the reasons why this is not a compile time option, I'll give up for now and leave this to someone else. See also https://mail.coreboot.org/pipermail/seabios/2018-July/012370.html which unfortunately has no answer. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#891753: Will be fixed in Django 1.11.17
I looked into this issue at the BSP in Bern and it runs out that currently only the testsuite for Python 3.7 on Django 1.11.16 fails. All other Python versions as well as Django 2.1.x in experimental are fine. The next upstream minor release in the 1.11.x series will add Python 3.7 compatibility. I looked at the changes that are so far in the upstream repository and it looks like the following two commits are needed: b9e248975f3190fee245b30313c2744bf836bb1c [1.11.x] Refs #28814 -- Fixed test_runner failure on Python 3.7. 8deb0a8efd948855310c45064b109090596510e4 [1.11.x] Refs #28814 -- Fixed migrations crash with namespace packages on Python 3.7. So we can either cherry-pick these two into debian/patches or wait for the 1.11.17 release. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#909312: Please provide some more information for bug #909312
Control: severity -1 important Control: tags -1 +moreinfo Hi Nicola I had a look at your bug report against initramfs-tools today. To me this looks rather like a bug in the 4.16 kernel specific to your setup. But without additional information about the exact configuration of the system it's hard to tell. Could you please provide more information about your hardware and the exact kernel version you were testing? I let the kernel maintainers decide if they want to reassign the bug to the kernel package or not. I'm downgrading the severity for now as this does not seem to affect many systems. Thanks for your report Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#897338: Downgrading severity of 897338
Control: -1 severity normal As this is apparently does not happen without virtualbox and is fixed by installing virtualbox-guest-dkms and/or virtualbox-guest-x11 I'm downgrading this bug to normal. I let the SDDM maintainers decide if this is a bug at all or if this is expected if the hardware support is not present in virtualbox. I think the last two messages to this bug report are about a different problem with NVIDIA graphics which is not related to this bug report. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#892859: NMU for 2.4.2-0.1
Hi Jeremy and Guido I created an NMU to fix #904635 and #892859 by uploading the new upstream version 2.4.2 and fixing the autopkgtests to run the new pytest based testsuite. This also contains a patch to remove a dependency on pytest-relaxed from the tests. This dependency is not packaged in Debian and does not work with the pytest release in Debian. It's only used for 2 tests. I replaced the utility function used by the equivalent from pytest. I uploaded the packaged to delayed-10 so you have some time to review the changes and abort the upload if you disagree. I used your git repository on github to create the NMU. I created 3 pull requests which you can merge. If you prefer a traditional NMU diff just tell me. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#888133: virt-manager builds successfully, is there still a bug in libvirt?
As virt-manager 1.5 is now in unstable and testing and builds fine, I think this bug can be closed. I'm unsure why it got reassigned to libvirt and there is unfortunately no reasoning in the bug log. I don't think there is a bug in libvirt which needs fixing. If you agree, please close this report so other RC bug squashers don't waste time on it. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#913599: Bug #913599 in ceph marked as pending
Control: tag -1 pending Hello, Bug #913599 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/97dfb624787f5ee41fefba340a06c3ea69707be5 Fix detection of armel for NEON instructions The condition used number comparison (EQUAL) instead of string comparison (STREQUAL). Closes: #913599 (this message was generated automatically) -- Greetings https://bugs.debian.org/913599
Bug#913599: Bug #913599 in ceph marked as pending
Control: tag -1 pending Hello, Bug #913599 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/3b48d55a5b9c9e4fce3a3ef791556a11bf96f3db Use -mfloat-abi=softfp on armel for NEON instructions There was already a patch to do the same for Jewel, but it got removed when the build system changed to cmake because it patched an autotools file which was no longer present. This adds the same logic to the new cmake based build system. Closes: #913599 (this message was generated automatically) -- Greetings https://bugs.debian.org/913599
Bug#913599: Bug #913599 in ceph marked as pending
Control: tag -1 pending Hello, Bug #913599 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/fa7d0d84f736d0b8450572f3192a43ff7b3252c4 Use -mfloat-abi=softfp on armel for NEON instructions There was already a patch to do the same for Jewel, but it got removed when the build system changed to cmake because it patched an autotools file which was no longer present. This adds the same logic to the new cmake based build system. Closes: #913599 (this message was generated automatically) -- Greetings https://bugs.debian.org/913599
Bug#913599: Bug #913599 in ceph marked as pending
Control: tag -1 pending Hello, Bug #913599 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/d17fa35130e4716fd2a9351c69a0d79f133044bc Use -mfloat-abi=softfp on armel for NEON instructions There was already a patch to do the same for Jewel, but it got removed when the build system changed to cmake because it patched an autotools file which was no longer present. This adds the same logic to the new cmake based build system. Closes: #913599 (this message was generated automatically) -- Greetings https://bugs.debian.org/913599
Bug#913909: Bug #913909 in ceph marked as pending
Control: tag -1 pending Hello, Bug #913909 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/d34d35f1372dea2f8cc75fdb98e0357e2c52804c Fix build on i386 d/p/0002-core-local-array-type-conversions.patch, d/p/0003-Core-local-statistics.patch: Cherry pick rocksdb commits to resolve compatibility with gcc-6 on i386. Closes: #913909 (this message was generated automatically) -- Greetings https://bugs.debian.org/913909
Bug#913600: Bug #913600 in ceph marked as pending
Control: tag -1 pending Hello, Bug #913600 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/0a7cbd593bf5f246577197535c3febc1cea05259 Disable libboost-context on unsupported archs Only a limited set of architectures supports libboost-context and libboost-coroutine. This limits the use of these libraries to supported architectures. Disabling libboost-context also disables the RADOS GW Beast frontend. Closes: #913600 (this message was generated automatically) -- Greetings https://bugs.debian.org/913600
Bug#913600: Bug #913600 in ceph marked as pending
Control: tag -1 pending Hello, Bug #913600 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/ff60a338b54a961f95bf99c45ad25d3a8571aff9 Only enable RADOS GW Beast frontend on supported archs Only a limited set of architectures supports libboost-context and libboost-coroutine which are both required for the Beast frontend. Disable this frontend on unsupported architectures. Closes: #913600 (this message was generated automatically) -- Greetings https://bugs.debian.org/913600
Bug#913909: [Ceph-maintainers] Bug#913909: Bug#913909: ceph: FTBFS on i386 and mipsel (regression)
Hi Salvatore Bonaccorso writes: Hi Gaudenz, and hi James, On Mon, Nov 19, 2018 at 03:48:14PM +0100, Gaudenz Steinlin wrote: James Page writes: > https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/ceph/tree/debian/patches?h=ubuntu/xenial > I think I hit the same issue in Ubuntu a while back for which > I picked 3 rocksdb patches - see above URL - 000*.patch. Thanks James. It looks like these patches actually fix the build issue. I already had these patches applied to the build in unstable, but I did not make the connection to the infinite loop. Salvatore, do you agree to an upload of 10.2.11-2 with these patches to stretch-security? Or how should we proceed? Yes we should release a regression update for ceph via stretch-security. Can you ping us when you have it ready? I'm currently building a new fixed version (10.2.11-2). Should I just upload to stretch-security or do you want to have a look at it first? I attached the debdiff to the previous stretch-security upload. Gaudenz ceph_10.2.11-1to2.debdiff Description: Binary data > > Regards, > Salvatore > -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
Bug#913601: Bug #913601 in ceph marked as pending
Control: tag -1 pending Hello, Bug #913601 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/29b7ac56db9d7f52c81e8f3a5c75234f14ae83a9 Patch to check for atomic support during build Instead of building with -Wl,--as-needed -latomic an all architectures, this dynamically detects the need for linking against libatomic. This is cleaner. The previous approach of setting the linker flags with DEB_LDFLAGS_MAINT_APPEND added the flags to early on the command line so that not all objects were linked against libatomic. This lead to build failures on at least mips and mipsel. Closes: #913601 (this message was generated automatically) -- Greetings https://bugs.debian.org/913601
Bug#913909: [Ceph-maintainers] Bug#913909: Bug#913909: ceph: FTBFS on i386 and mipsel (regression)
James Page writes: https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/ceph/tree/debian/patches?h=ubuntu/xenial I think I hit the same issue in Ubuntu a while back for which I picked 3 rocksdb patches - see above URL - 000*.patch. Thanks James. It looks like these patches actually fix the build issue. I already had these patches applied to the build in unstable, but I did not make the connection to the infinite loop. Salvatore, do you agree to an upload of 10.2.11-2 with these patches to stretch-security? Or how should we proceed? Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#913909: [Ceph-maintainers] Bug#913909: ceph: FTBFS on i386 and mipsel (regression)
Salvatore Bonaccorso writes: Hi Gaudenz, On Sat, Nov 17, 2018 at 05:28:18PM +0100, Gaudenz Steinlin wrote: Salvatore Bonaccorso writes: > Hi, On Fri, Nov 16, 2018 at 09:00:06PM +0100, Salvatore > Bonaccorso wrote: > > Source: ceph Version: 10.2.11-1 Severity: serious > > Justification: FTBFS Control: affects -1 > > release.debian.org,security.debian.org Hi Gaudenz, The > > security update for ceph released as DSA-4339-1 FTBFS on > > i386 and mipsel. For i386 at least the build seem to hang. > After several atemps the mipsel build worked. The i386 > though still failed. I'll have a look. Is there anything special about the build environment? Not that I know of, the buildd environments for security builds should not diverge. What I know is that the testsuite hangs if run with eatmydata. But otherwise I'm unaware about any problems. Is this build done on amd64 or on i386? eatmydata should not be used. But according to the build log the following is given: Package: ceph Version: 10.2.11-1 Source Version: 10.2.11-1 Distribution: stretch-security Machine Architecture: amd64 Host Architecture: i386 Build Architecture: i386 Build Type: any And trying to reproduce on barriere.d.o lead to the same hanging result. I did the same and the build hanged as well. Retrying the hanging call with all the -O2 arguments removed succeeds. So this seems to be a bug in GCC with optimizations. I'm unsure on how to proceeed from here. It's quite clear this is not a bug in Ceph. Is there a chance that GCC will get fixed in stable? Would it make sense to open a bug on g++-6? To workaround this in Ceph I would need to find a way to disable optimizations just for this file on i386. Because I suspect that generally disabling -O2 would have some performance implications. The failing call is: /usr/lib/gcc/i686-linux-gnu/6/cc1plus -quiet -I . -I ./include -imultiarch i386-linux-gnu -D_GNU_SOURCE -D ROCKSDB_PLATFORM_POSIX -D ROCKSDB_LIB_IO_POSIX -D _LARGEFILE64_SOURCE -D OS_LINUX -D ROCKSDB_FALLOCATE_PRESENT -D SNAPPY -D ZLIB -D BZIP2 -D ROCKSDB_MALLOC_USABLE_SIZE -D ROCKSDB_PTHREAD_ADAPTIVE_MUTEX -D ROCKSDB_BACKTRACE -D ROCKSDB_RANGESYNC_PRESENT -D NDEBUG -isystem ./third-party/gtest-1.7.0/fused-src monitoring/statistics.cc -quiet -dumpbase statistics.cc -momit-leaf-frame-pointer -mtune=generic -march=i686 -auxbase-strip monitoring/statistics.o -g -g1 -g -g -g1 -g -g1 -O2 -O2 -O2 -O2 -Wformat=1 -Werror=format-security -Wextra -Wall -Wsign-compare -Wshadow -Wno-unused-parameter -Wformat=1 -Werror=format-security -Wformat=1 -Werror=format-security -Woverloaded-virtual -Wnon-virtual-dtor -Wno-missing-field-initializers -std=c++11 -fdebug-prefix-map=/home/gaudenz/ceph=. -fstack-protector-strong -fPIC -fdebug-prefix-map=/home/gaudenz/ceph=. -fstack-protector-strong -fdebug-prefix-map=/home/gaudenz/ceph=. -fstack-protector-strong -fno-builtin-memcmp -fno-omit-frame-pointer -o /tmp/ccWWcwWO.s Running in src/rocksdb. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#913601: Bug #913601 in ceph marked as pending
Control: tag -1 pending Hello, Bug #913601 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/5f4c156c772c8ce7d0df3756de5fef9755ad0dff Patch to check for atomic support during build Instead of building with -Wl,--as-needed -latomic an all architectures, this dynamically detects the need for linking against libatomic. This is cleaner. The previous approach of setting the linker flags with DEB_LDFLAGS_MAINT_APPEND added the flags to early on the command line so that not all objects were linked against libatomic. This lead to build failures on at least mips and mipsel. Closes: #913601 (this message was generated automatically) -- Greetings https://bugs.debian.org/913601
Bug#913909: [Ceph-maintainers] Bug#913909: ceph: FTBFS on i386 and mipsel (regression)
Salvatore Bonaccorso writes: Hi, On Fri, Nov 16, 2018 at 09:00:06PM +0100, Salvatore Bonaccorso wrote: Source: ceph Version: 10.2.11-1 Severity: serious Justification: FTBFS Control: affects -1 release.debian.org,security.debian.org Hi Gaudenz, The security update for ceph released as DSA-4339-1 FTBFS on i386 and mipsel. For i386 at least the build seem to hang. After several atemps the mipsel build worked. The i386 though still failed. I'll have a look. Is there anything special about the build environment? What I know is that the testsuite hangs if run with eatmydata. But otherwise I'm unaware about any problems. Is this build done on amd64 or on i386? Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#913601: [Ceph-maintainers] Bug#913601: ceph: FTBFS on mips/el: /usr/include/c++/8/bits/atomic_base.h:304: undefined reference to `__atomic_fetch_sub_8'
Hi Emilio Pozuelo Monfort writes: Your package failed to build on mips/el: /usr/bin/ld: CMakeFiles/ceph-mgr.dir/mgr/DaemonServer.cc.o: in function `RefCountedObject::~RefCountedObject()': /usr/include/c++/8/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/bin/ld: CMakeFiles/ceph-mgr.dir/mgr/DaemonServer.cc.o: in function `RefCountedObject::~RefCountedObject()': You may need to link with -latomic. As you can see from the rules file the package already links with -latomic by setting it in DEB_LDFLAGS_MAINT_APPEND. The problem is that cmake inserts this option before some of the object files so those don't get linked with libatomic. I'm working on a fix for this. Do you know which architectures in Debian actually need libatomic? I would like to avoid any unnecessary linking to it. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
Bug#913600: [Ceph-maintainers] Bug#913600: ceph: bd-uninst on several architectures: libboost-context1.67-dev not available
Hi Emilio Pozuelo Monfort writes: Your package can no longer be built on several architectures, as libboost-context is not built everywhere. Possible solutions would be: 1) Make that build-dep optional I don't think that's possible. Or do you have any pointers how Ceph could be built without libboost-context? The only option I see going in that direction is to use the embedded copy of Boost which ships with the Ceph sources. But I'd like to avoid that and I actually doubt this will build on these architectures if the Boost Debian package does not build. 2) Look if that boost library can now be built on more architectures Was the boost build disabled on these architectures? I was under the impression that we are just missing builds for these and that they will eventually get done. My time resources to work on other packages are a bit limited. Do you know why Boost is not built on these architectures? 3) Remove ceph from the affected architectures If we can't get this fixed and all the other architectures build fine this is probably the easiest option. However sad... See the affected architectures at https://buildd.debian.org/status/package.php?p=ceph I'm currently working on the build failures on mips, mipsel and armel. Gaudenz PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
Bug#896400: Bug #896400 in ceph marked as pending
Control: tag -1 pending Hello, Bug #896400 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/39f9d612884a4e829c32726ec4acf4321f69676d Depend on ceph-common for pythonX-cephfs The ceph_volume_client Python module included in pythonX-cephfs import ceph_argparse and ceph_daemon from ceph-common. As this is not a module built using setuptools dh_python does not automatically add this dependency. Closes: #896400 (this message was generated automatically) -- Greetings https://bugs.debian.org/896400
Bug#867465: Bug #867465 in ceph marked as pending
Control: tag -1 pending Hello, Bug #867465 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/dfbe7c3aa995926793daab7a2cc0040fbc6199dc Remove unnecessary ceph-base postrm script This script removed /etc/ceph and /var/log/ceph which were both not owned by ceph-base. There was no other code in the script so it could be removed. Closes: #867465 (this message was generated automatically) -- Greetings https://bugs.debian.org/867465
Bug#896400: Bug #896400 in ceph marked as pending
Control: tag -1 pending Hello, Bug #896400 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/726a5c84a0fdfec6448a5e2f49fa6d83d4cd57c6 Depend on ceph-common for pythonX-cephfs The ceph_volume_client Python module included in pythonX-cephfs import ceph_argparse and ceph_daemon from ceph-common. As this is not a module built using setuptools dh_python does not automatically add this dependency. Closes: #896400 (this message was generated automatically) -- Greetings https://bugs.debian.org/896400
Bug#867465: Bug #867465 in ceph marked as pending
Control: tag -1 pending Hello, Bug #867465 in ceph reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below, and you can check the diff of the fix at: https://salsa.debian.org/ceph-team/ceph/commit/fdd77aac08e0649c565c4d04bde97f31a1c78e8a Remove unnecessary ceph-base postrm script This script removed /etc/ceph and /var/log/ceph which were both not owned by ceph-base. There was no other code in the script so it could be removed. Closes: #867465 (this message was generated automatically) -- Greetings https://bugs.debian.org/867465
Bug#862075: tagged as pending
tag 862075 pending -- We believe that the bug #862075 you reported has been fixed in the Git repository. You can see the commit message below and/or inspect the commit contents at: http://anonscm.debian.org/cgit/pkg-ceph/ceph.git/diff/?id=a12798a (This message was generated automatically by 'git-post-receive-tag-pending-commitmsg' hook). --- commit a12798af80d903bbaa18d174a98ac5c6ae8b1204 Author: Gaudenz Steinlin <gaud...@debian.org> Date: Thu May 11 23:09:24 2017 +0200 Add fix-init-system-detection.patch This replaces the static init system detection by more appropriate runtime detection which also works if a Debian system is running with sysvinit. Closes: #862075
Bug#862075: [Ceph-maintainers] Bug#862075: ceph-detect-init: Platform is not supported.: debian 9.0
The first version of the patch did not work as expected. Attached is a
fixed version. Back to building and testing ...
bug_862075_v2.debdiff
Description: Binary data
Gaudenz Steinlin <gaud...@debian.org> writes:
> Control: forwarded -1 http://tracker.ceph.com/issues/19884
> Control: tags -1 +patch
>
> Simon McVittie <s...@debian.org> writes:
>
>> On Mon, 08 May 2017 at 11:16:48 +0200, Pim van den Berg wrote:
>>> As you can see ceph assumes our init system is sysvinit in stretch, while it
>>> is systemd.
>>
>> No, our init system is "either sysvinit or systemd, or maybe even Upstart".
>> get_init_system() in reportbug's reportbug.utils demonstrates how to detect
>> which one we're dealing with.
>>
>> (In particular, /run/systemd/system is the canonical way to probe for
>> a system where systemctl can be expected to work.)
>>
>
> There is already a patch proposed upstream doing exactly this. I
> modified it a bit to apply to the current version in stretch and removed
> some more code which is now unused to avoid confusion.
>
> My proposed debdiff is attached to this mail. I'm currently building the
> package and will then do some tests to verify that the patch works as
> expected with systemd and sysvinit. This will take some time (the build
> alone takes several hours).
>
> Gaudenz
>
>
>>> debian_codenames = {
>>> +'9': 'stretch',
>>
>> The codenames for what will become Debian 10 (buster) and Debian 11
>> (bullseye) are already known, precisely to be able to avoid this sort
>> of bug. However, if what Ceph really wants to know is a fact like
>> "what is the init system?", it should be probing for the init system,
>> not going via the OS vendor and version.
>>
>> S
>> ___
>> Ceph-maintainers mailing list
>> ceph-maintain...@lists.ceph.com
>> http://lists.ceph.com/listinfo.cgi/ceph-maintainers-ceph.com
>>
> --
> PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
> ___
> Ceph-maintainers mailing list
> ceph-maintain...@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-maintainers-ceph.com
--
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
Bug#862075: [Ceph-maintainers] Bug#862075: ceph-detect-init: Platform is not supported.: debian 9.0
Control: forwarded -1 http://tracker.ceph.com/issues/19884
Control: tags -1 +patch
Simon McVittie <s...@debian.org> writes:
> On Mon, 08 May 2017 at 11:16:48 +0200, Pim van den Berg wrote:
>> As you can see ceph assumes our init system is sysvinit in stretch, while it
>> is systemd.
>
> No, our init system is "either sysvinit or systemd, or maybe even Upstart".
> get_init_system() in reportbug's reportbug.utils demonstrates how to detect
> which one we're dealing with.
>
> (In particular, /run/systemd/system is the canonical way to probe for
> a system where systemctl can be expected to work.)
>
There is already a patch proposed upstream doing exactly this. I
modified it a bit to apply to the current version in stretch and removed
some more code which is now unused to avoid confusion.
My proposed debdiff is attached to this mail. I'm currently building the
package and will then do some tests to verify that the patch works as
expected with systemd and sysvinit. This will take some time (the build
alone takes several hours).
Gaudenz
bug_862075.debdiff
Description: Binary data
>> debian_codenames = {
>> +'9': 'stretch',
>
> The codenames for what will become Debian 10 (buster) and Debian 11
> (bullseye) are already known, precisely to be able to avoid this sort
> of bug. However, if what Ceph really wants to know is a fact like
> "what is the init system?", it should be probing for the init system,
> not going via the OS vendor and version.
>
> S
> ___
> Ceph-maintainers mailing list
> ceph-maintain...@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-maintainers-ceph.com
>
--
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
signature.asc
Description: PGP signature
Bug#809669: RC Bug NMU diff
Hi I uplaoded an NMU to unstable to fix this bug. I mostly used the debdiff prepared by Louis Bouchard but fixed the version number to be 0.93.1+nmu1 instead of 0.93.2 and actually fixed the systemd unit in the way proposed in this bug. The debdiff attached to the bug missed the critical changes. Gaudenz bug_809669.debdiff Description: Binary data -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#850906: tagged as pending
tag 850906 pending -- We believe that the bug #850906 you reported has been fixed in the Git repository. You can see the commit message below and/or inspect the commit contents at: http://anonscm.debian.org/cgit/pkg-ceph/ceph.git/diff/?id=e44a30d (This message was generated automatically by 'git-post-receive-tag-pending-commitmsg' hook). --- commit e44a30d304059fbf94d68623e10f296f4d0284fb Author: Gaudenz Steinlin <gaud...@debian.org> Date: Wed Jan 11 09:39:36 2017 +0100 Disable running dh_auto_install with parallel jobs There seems to be a race condition in make install which leads to random failures only seen on armel. The failure occurs when installing the Python modules. Closes: #850906
Bug#850906: [Ceph-maintainers] Bug#850906: ceph FTBFS on armel, libtool/linker related issues.
peter green <plugw...@p10link.net> writes: > Package: ceph > Version: 10.2.5-5 > Severity: serious > x-debbugs-cc: debian-...@lists.debian.org > > The most recent upload of ceph fixed the build on most architectures but > unfortunately armel is still failing. > > libtool: relink: g++ -fPIC -DPIC -shared -nostdlib > /usr/lib/gcc/arm-linux-gnueabi/6/../../../arm-linux-gnueabi/crti.o > /usr/lib/gcc/arm-linux-gnueabi/6/crtbeginS.o > java/native/.libs/libcephfs_jni_la-libcephfs_jni.o > java/native/.libs/libcephfs_jni_la-JniConstants.o -Wl,--whole-archive > ./.libs/libcommon.a -Wl,--no-whole-archive -Wl,--as-needed > -L/«PKGBUILDDIR»/debian/tmp/usr/lib/arm-linux-gnueabi > -L/usr/lib/arm-linux-gnueabi -lcephfs -ldl -lboost_thread -lboost_random > -lblkid -luuid -lrt -lboost_iostreams -lboost_system > -L/usr/lib/gcc/arm-linux-gnueabi/6 > -L/usr/lib/gcc/arm-linux-gnueabi/6/../../../arm-linux-gnueabi > -L/usr/lib/gcc/arm-linux-gnueabi/6/../../.. -L/lib/arm-linux-gnueabi -lstdc++ > -lm -lc -lgcc_s /usr/lib/gcc/arm-linux-gnueabi/6/crtendS.o > /usr/lib/gcc/arm-linux-gnueabi/6/../../../arm-linux-gnueabi/crtn.o -O2 -g > -fstack-protector-strong -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro > -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-soname > -Wl,libcephfs_jni.so.1 -o .libs/libcephfs_jni.so.1.0.0 > /usr/bin/ld: > /«PKGBUILDDIR»/debian/tmp/usr/lib/arm-linux-gnueabi/libcephfs.so: invalid > string offset 50471 >= 3194 for section `.strtab' > <--snip--> > libtool: warning: remember to run 'libtool --finish > /usr/lib/arm-linux-gnueabi' > make[5]: Leaving directory '/«PKGBUILDDIR»/src' > Makefile:32173: recipe for target 'install-am' failed > make[4]: *** [install-am] Error 2 > make[4]: Leaving directory '/«PKGBUILDDIR»/src' > Makefile:30865: recipe for target 'install-recursive' failed > make[3]: *** [install-recursive] Error 1 > make[3]: Leaving directory '/«PKGBUILDDIR»/src' > Makefile:32167: recipe for target 'install' failed > make[2]: *** [install] Error 2 > make[2]: Leaving directory '/«PKGBUILDDIR»/src' > Makefile:703: recipe for target 'install-recursive' failed > make[1]: *** [install-recursive] Error 1 > make[1]: Leaving directory '/«PKGBUILDDIR»' > dh_auto_install: make -j4 install DESTDIR=/«PKGBUILDDIR»/debian/tmp > AM_UPDATE_INFO_DIR=no returned exit code 2 > debian/rules:73: recipe for target 'binary-arch' failed > > This seems like a rather strange error, putting debian-arm in cc in > case anyone there has any ideas. I have seen these warnings (invalid string offset 50471 >= 3194 for section `.strtab') too. I don't know what causes them and if they are serious. But the actual build failure is somewhere else further up in the log. It has to do with running make install in parallel. If I disable parallel execution for the dh_auto_install step, the package builds fine at least on the armel porterbox. I'll do another upload with this fix. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
Aurelien Jarno <aurel...@aurel32.net> writes: > On 2017-01-05 14:00, Gaudenz Steinlin wrote: >> >> Hi >> >> Aurelien Jarno <aurel...@aurel32.net> writes: >> >> > On 2016-12-30 10:06, Emilio Pozuelo Monfort wrote: >> >> On 29/12/16 20:56, Gaudenz Steinlin wrote: >> > >> > The problem is indeed a memory issue, not that the buildd doesn't have >> > enough memory, but just that you can allocate only 2GB per process on a >> > 32-bit MIPS machine. As Emilio said, the above GCC flag should help to >> > reduce the memory usage by running the garbage collector more often. >> > >> > However gcc 6.3 seems to have improved the situation a bit, so I given >> > back the packages, I hope they will build now. Otherwise I have a patch >> > ready to change the GCC defaults. That said GCC upstream consider it's a >> > bug in the garbage collector [1], so that should be fixed instead and the >> > patch should be considered as a temporary workaround. >> > >> >> Aurelien thanks for taking care and resheduling the build. Unfortunately >> this did not solve the problem. But setting the following variables >> solves the virtual memory issue for me on the mipsel porterbox (eller): >> >> export DEB_CFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 >> export DEB_CXXFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 >> export DEB_CFLAGS_MAINT_STRIP= -O2 >> export DEB_CXXFLAGS_MAINT_STRIP= -O2 > > Thanks for testing that. > > I have found that the issue is also workarounded by keeping -O2 and > --param ggc-min-expand=5, which is a quite aggressive value. The patch I > have for GCC reduced the value to 30 (which corresponds to disabling the > heuristics). Also note that the build failure actually only concern the > testsuite, the code itself builds without any change. Thanks for the hint. I'll try another upload with --param ggc-min-expand=5. Unfortunately there is no easy way to disable the testsuite build without also disabling some debug binaries that are part of the binary packages. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5
Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
Emilio Pozuelo Monfort <po...@debian.org> writes: > On 05/01/17 14:00, Gaudenz Steinlin wrote: >> >> Hi >> >> Aurelien Jarno <aurel...@aurel32.net> writes: >> >>> On 2016-12-30 10:06, Emilio Pozuelo Monfort wrote: >>>> On 29/12/16 20:56, Gaudenz Steinlin wrote: >>> >>> The problem is indeed a memory issue, not that the buildd doesn't have >>> enough memory, but just that you can allocate only 2GB per process on a >>> 32-bit MIPS machine. As Emilio said, the above GCC flag should help to >>> reduce the memory usage by running the garbage collector more often. >>> >>> However gcc 6.3 seems to have improved the situation a bit, so I given >>> back the packages, I hope they will build now. Otherwise I have a patch >>> ready to change the GCC defaults. That said GCC upstream consider it's a >>> bug in the garbage collector [1], so that should be fixed instead and the >>> patch should be considered as a temporary workaround. >>> >> >> Aurelien thanks for taking care and resheduling the build. Unfortunately >> this did not solve the problem. But setting the following variables >> solves the virtual memory issue for me on the mipsel porterbox (eller): >> >> export DEB_CFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 >> export DEB_CXXFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 >> export DEB_CFLAGS_MAINT_STRIP= -O2 >> export DEB_CXXFLAGS_MAINT_STRIP= -O2 >> >> But unfortunately the build fails at another point. See the log below. >> I'm not sure how to fix this. If I understand it right these atomic >> operations are just not supported on mipsel[1]. Or is there a way to make >> them work? > > They are supported. You are probably missing -latomic. You are right, using -latomic fixes the issue. If I understand this right -latomic "emulates" the atomic operation if there is no direct support in the processor for it. What's the correct way to detect if -latomic is needed? Or is it safe to use -latomic everywhere on all architectures and let the linker/compiler do the right thing? I'd like to patch the build system in a way that can be sent upstream instead of working around it. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#849660: tagged as pending
tag 849660 pending -- We believe that the bug #849660 you reported has been fixed in the Git repository. You can see the commit message below and/or inspect the commit contents at: http://anonscm.debian.org/cgit/pkg-ceph/ceph.git/diff/?id=eeff8d6 (This message was generated automatically by 'git-post-receive-tag-pending-commitmsg' hook). --- commit eeff8d65bad5c8e2bdf966bfe725b75d63aa9bc5 Author: Gaudenz Steinlin <gaud...@debian.org> Date: Tue Dec 27 21:35:47 2016 +0100 Use -mfloat-abi=softfp on armel for NEON plugin Closes: #849660
Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
Hi Aurelien Jarno <aurel...@aurel32.net> writes: > On 2016-12-30 10:06, Emilio Pozuelo Monfort wrote: >> On 29/12/16 20:56, Gaudenz Steinlin wrote: > > The problem is indeed a memory issue, not that the buildd doesn't have > enough memory, but just that you can allocate only 2GB per process on a > 32-bit MIPS machine. As Emilio said, the above GCC flag should help to > reduce the memory usage by running the garbage collector more often. > > However gcc 6.3 seems to have improved the situation a bit, so I given > back the packages, I hope they will build now. Otherwise I have a patch > ready to change the GCC defaults. That said GCC upstream consider it's a > bug in the garbage collector [1], so that should be fixed instead and the > patch should be considered as a temporary workaround. > Aurelien thanks for taking care and resheduling the build. Unfortunately this did not solve the problem. But setting the following variables solves the virtual memory issue for me on the mipsel porterbox (eller): export DEB_CFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 export DEB_CXXFLAGS_MAINT_APPEND= --param ggc-min-expand=10 -O1 export DEB_CFLAGS_MAINT_STRIP= -O2 export DEB_CXXFLAGS_MAINT_STRIP= -O2 But unfortunately the build fails at another point. See the log below. I'm not sure how to fix this. If I understand it right these atomic operations are just not supported on mipsel[1]. Or is there a way to make them work? Gaudenz [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296 libtool: link: g++ -I/usr/include/nss -I/usr/include/nspr -Wall -Wtype-limits -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -fPIE -fstack-protector-strong -Wstrict-null-sentinel -I../src/gmock/include -I../src/gmock/include -I../src/gmock/gtest/include -I../src/gmock/gtest/include -g -fdebug-prefix-map=/home/gaudenz/ceph=. -fstack-protector-strong -Wformat -Werror=format-security --param ggc-min-expand=10 -O1 -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/ceph_test_cls_rgw test/cls_rgw/ceph_test_cls_rgw-test_cls_rgw.o /usr/lib/mipsel-linux-gnu/libatomic_ops.a -Wl,--as-needed ./.libs/librados.so ./.libs/libcls_rgw_client.a ../src/gmock/lib/.libs/libgmock_main.a ../src/gmock/lib/.libs/libgmock.a ../src/gmock/gtest/lib/.libs/libgtest.a ./.libs/libglobal.a -lpthread -lm ./.libs/libradostest.a ./.libs/libcommon.a -ldl -lboost_thread -lboost_random -lrt -lblkid -luuid -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -lboost_iostreams -lboost_system -pthread rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::load(std::memory_order) const': /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' rocksdb/librocksdb.a(memtable.o):/usr/include/c++/6/bits/atomic_base.h:396: more undefined references to `__atomic_load_8' follow rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)': /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::load(std::memory_order) const': /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' rocksdb/librocksdb.a(memtable.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)': /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' rocksdb/librocksdb.a(env_posix.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)': /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' /usr/include/c++/6/bits/atomic_base.h:374: undefined reference to `__atomic_store_8' rocksdb/librocksdb.a(env_posix.o): In function `std::__atomic_base::load(std::memory_order) const': /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' /usr/include/c++/6/bits/atomic_base.h:396: undefined reference to `__atomic_load_8' rocksdb/librocksdb.a(env_posix.o): In function `std::__atomic_base::store(unsigned long long, std::memory_order)': /usr/includ
Bug#849660: [Ceph-maintainers] Bug#849660: ceph: FTBFS on armel: error: field 'result' has incomplete type 'std::promise'
Hi Emilio Emilio Pozuelo Monfort <po...@debian.org> writes: > Source: ceph > Version: 10.2.5-2 > Severity: serious > > Your package failed to build on armel: > > utilities/backupable/backupable_db.cc:297:30: error: field 'result' has > incomplete type 'std::promise' > std::promise result; I'm already working on the build issues on armel. Unfortunately without much success until now. There are two main issues: Building the NEON optimized variant of jerasure fails. This can be fixed by either disabling NEON alltogether or by adding -mfloat-abi=softfp to compilation of the relevant files. The second solution would be preferable and builds OK. But I need to verify that this is really only an optional run time selected "plugin" and no other code get's NEON instructions as those are not generally available on armel machines. You can see this problem a bit further up in the build log. The second problem is much tricker to solve. Rocksdb relies on std::future which does not work on armel due to a GCC bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727621 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735 All my attempts to build ceph without rocksdb have failed so far. While it's easy to disable to build of rocksdb itself, linking then fails later because of missing symbols. I have not yet found a way to completely disable all components that use rocksdb even if I only build the client parts. If I can't find a solution soon I'll probably request the removal of ceph from armel. But this should only be a last resort option as there are quite a few reverse dependencies. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory
Hi Emilio Emilio Pozuelo Monfort <po...@debian.org> writes: > Source: ceph > Version: 10.2.5-2 > Severity: serious > > Your package failed to build on mips/el: > > g++ -DHAVE_CONFIG_H -I. -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE > -D__STDC_FORMAT_MACROS -D_GNU_SOURCE > -DCEPH_LIBDIR=\"/usr/lib/mipsel-linux-gnu\" > -DCEPH_PKGLIBDIR=\"/usr/lib/mipsel-linux-gnu/ceph\" > -DGTEST_USE_OWN_TR1_TUPLE=0 -D_REENTRANT-Wdate-time -D_FORTIFY_SOURCE=2 > -I/usr/include/nss -I/usr/include/nspr -Wall -Wtype-limits > -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security > -fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 > -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall > -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > --param=ssp-buffer-size=4 -fPIE -fstack-protector-strong > -Wstrict-null-sentinel -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. > -fstack-protector-strong -Wformat -Werror=format-security -c -o > tools/rbd/action/Resize.o tools/rbd/action/Resize.cc > virtual memory exhausted: Cannot allocate memory > Makefile:24792: recipe for target > 'test/encoding/ceph_dencoder-ceph_dencoder.o' failed I already noticed this and tried to contact m...@buildd.debian.org and mip...@buildd.debian.org. Unfortunately nobody responded yet, so I don't know if the message was even received or not. AFAIK these are the correct contact points for buildd issues. I don't think there is much I can do about this bug and I'm not convinced this is a issue in ceph. If the buildds are unable to build the package we can either completely remove ceph for mips/mipsel or try to only build the client part and have a reduced set of packages on these architectures. The second option would have the advantage that no changes to the reverse dependencies (notably qemu) are needed. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#840383: ceph: Mon crash on startup
Control: severity -1 normal Control: tags -1 unreproducible Hi Thanks for your bugreport. Sorry that it took so long to get back to you. The ceph maintenance team is currently understaffed and struggeling to keep up with the work. Hans Grobler <grob...@gmail.com> writes: > Package: ceph > Version: 0.80.11-1.1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > After an upgrade from 0.80.11-1, Ceph monitor start up results in > the crash seen below. The crash is repeatable / consistent and as a > result it is not possible to start the monitor with 0.80.11-1.1. OSDs > however start without problems with 0.80.11-1.1. > > Attempting to create a new monitor results in a similar crash on startup. > Reverting back to 0.80.11-1 allows the Ceph monitor to start as normal > (with the pre-upgrade leveldb). I tried to reproduce this in a clean environment but failed. So this certainly does not affect all users. I also uploaded a new upstream version (10.2.5) a few days ago, which is currently sitting in NEW. It would be nice if you could test this version once it's available in unstable. If you are eager to test, I can also provide you the debs. To be able to reproduce this I would need at least the commands you used to get the traces below and maybe also your /var/lib/ceph/mon/XXX directory to get the exact same monitor database. I suspect your database might have gotten corrupt somehow. But still thanks for testing and I would really appreciate if you could test the new upstream package. Gaudenz > > > 2016-10-11 06:35:54.781406 7f0d7abe57c0 -1 *** Caught signal (Aborted) ** > in thread 7f0d7abe57c0 > > ceph version 0.80.11 (8424145d49264624a3b0a204aedb127835161070) > 1: (()+0x4c7812) [0x55a47ae33812] > 2: (()+0x11100) [0x7f0d7a300100] > 3: (gsignal()+0xcf) [0x7f0d78929fdf] > 4: (abort()+0x16a) [0x7f0d7892b40a] > 5: (()+0x23275) [0x7f0d7a78c275] > 6: (()+0x170af) [0x7f0d7a7800af] > 7: (operator delete[](void*)+0x25d) [0x7f0d7a7a361d] > 8: (LevelDBStore::do_open(std::ostream&, bool)+0x69c) [0x55a47addf0ac] > 9: (main()+0xbc0) [0x55a47aabc120] > 10: (__libc_start_main()+0xf1) [0x7f0d789172b1] > 11: (_start()+0x2a) [0x55a47aacb98a] > NOTE: a copy of the executable, or `objdump -rdS ` is needed to > interpret this. > > --- begin dump of recent events --- > -12> 2016-10-11 06:35:54.776111 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command perfcounters_dump hook 0x55a47ca96020 > -11> 2016-10-11 06:35:54.776183 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command 1 hook 0x55a47ca96020 > -10> 2016-10-11 06:35:54.776212 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command perf dump hook 0x55a47ca96020 >-9> 2016-10-11 06:35:54.776218 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command perfcounters_schema hook 0x55a47ca96020 >-8> 2016-10-11 06:35:54.776224 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command 2 hook 0x55a47ca96020 >-7> 2016-10-11 06:35:54.776228 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command perf schema hook 0x55a47ca96020 >-6> 2016-10-11 06:35:54.776233 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command config show hook 0x55a47ca96020 >-5> 2016-10-11 06:35:54.776238 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command config set hook 0x55a47ca96020 >-4> 2016-10-11 06:35:54.776243 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command config get hook 0x55a47ca96020 >-3> 2016-10-11 06:35:54.776248 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command log flush hook 0x55a47ca96020 >-2> 2016-10-11 06:35:54.776261 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command log dump hook 0x55a47ca96020 >-1> 2016-10-11 06:35:54.776269 7f0d7abe57c0 5 asok(0x55a47cac2160) > register_command log reopen hook 0x55a47ca96020 > 0> 2016-10-11 06:35:54.781406 7f0d7abe57c0 -1 *** Caught signal (Aborted) > ** > in thread 7f0d7abe57c0 > > ceph version 0.80.11 (8424145d49264624a3b0a204aedb127835161070) > 1: (()+0x4c7812) [0x55a47ae33812] > 2: (()+0x11100) [0x7f0d7a300100] > 3: (gsignal()+0xcf) [0x7f0d78929fdf] > 4: (abort()+0x16a) [0x7f0d7892b40a] > 5: (()+0x23275) [0x7f0d7a78c275] > 6: (()+0x170af) [0x7f0d7a7800af] > 7: (operator delete[](void*)+0x25d) [0x7f0d7a7a361d] > 8: (LevelDBStore::do_open(std::ostream&, bool)+0x69c) [0x55a47addf0ac] > 9: (main()+0xbc0) [0x55a47aabc120] > 10: (__libc_start_main()+0xf1) [0x7f0d789172b1] > 11: (_start()+0x2a) [0x55a47aacb98a] > NOTE: a copy of the executable, or `objdump -rdS ` is needed to > interpret this. > > --- logging levels --- > 0/ 5 none > 0/ 1 lockdep > 0/ 1 context > 1/ 1 crush > 1/ 5 mds > 1/ 5 mds_balancer > 1/ 5 mds
Bug#844937: owncloud-client at risk of not being in stretch [was Re: Bug#844937: fixed in owncloud-client 2.2.4+dfsg-2]
Hi Sébastien Thanks for the heads up. I'm mostly just doing backports uploads. So if Sandro disagrees, go for his opinion. Sébastien Villemot <sebast...@debian.org> writes: > Dear owncloud-client maintainers, > > owncloud-client is scheduled for removal from testing on 2016-12-21, > because #844937 is not yet fixed in testing. And since packages will > not be allowed to enter back testing after 2017-01-06, there is a > significant risk that owncloud-client will not be part of stretch, > which would be a disservice to our users. > > The problem is that version 2.2.4+dfsg-2 (which has #844937 corrected) > failed to compile on mips* archs, and therefore cannot migrate to > testing. The root cause of this FTBFS is a nasty bug in binutils > (#844227 and its clones), so it is largely out of your control. Good catch. I had a quick look at the PTS page when I got the autoremoval mail, but thought that it will sort itself out because the bug is fixed. > > In order to avoid the removal of owncloud-client from testing, I > suggest to request the removal of owncloud-client binaries on mips > arches *in unstable* (hoping that ftpmasters will deal quickly enough > with the removal request). At least, that would allow non-mips users to > benefit from an owncloud-client package in stretch. > > Are you ok with this solution? If yes, I can do the removal request if > you are too busy to do so. Yes sounds like a good plan. If it builds again on mips the binaries will reenter testing. Gaudenz signature.asc Description: PGP signature
Bug#844701: Fix for 844701 breaks installation of valgrind
reopen -1 retitle -1 dpkg-maintscript-helper: fails if no version is given Hi The fix for #844701 included in the upload from earlier today breaks the installation of valgrind. Preparing to unpack .../valgrind_1%3a3.12.0-1_amd64.deb ... dpkg-maintscript-helper: error: dpkg: error: version '' has bad syntax: version string is empty dpkg: error processing archive /var/cache/apt/archives/valgrind_1%3a3.12.0-1_amd64.deb (--unpack): subprocess new pre-installation script returned error exit status 1 dpkg-maintscript-helper: error: dpkg: error: version '' has bad syntax: version string is empty The problem is that valgrind includes the follwoing preinst: #!/bin/sh set -e # Automatically added by dh_installdeb dpkg-maintscript-helper rm_conffile /etc/bash_completion.d/valgrind -- "$@" # End automatically added section According to the dpkg-maintscript-helper manpage it's valid to omit the prior-version. So this is perfectly legal. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#839138: Ceph maintainership status
Hi Adrian Thanks for the heads up. We were probably all a bit burried in work and neglected ceph a bit too much. James Page <james.p...@ubuntu.com> writes: > Hi Adrian > > On Mon, 17 Oct 2016 at 20:34 Adrian Bunk <b...@stusta.de> wrote: > >> Hi, >> >> first of all thanks for your past work on Ceph. >> >> The current status of the Ceph packages [1] does not look good. >> >> src:ceph has 3 RC bugs, from "maintainer address bounces" >> to "crashes since the latest NMU". >> > > I'll sort through those (see below). I had a short chat with James during the OpenStack Summit and I also intend to continue maintaining ceph. But it's really not feasible to do this alone (or even just me and James). So any help would be appreciated. Regarding the maintainer adress I would like to keep it pointing to the ceph-maintainers mailinglist. I like the idea of working together with the other distro maintainers. James said he will contact the mailinglist admin to see if we can configure the list in a way that it automatically accepts mails from the BTS (and other Debian systems). As already stated in the bug report, having a config snippet that works would be appreciated and speed this up. > > If you still intend to maintain Ceph, do the emails from the BTS >> actually reach you? If not, a list at Alioth might be a better option. > > >> It would also be OK if you would state that there is noone left active >> among the Ceph Maintainers, and that I can orphan the package for >> finding new maintainers. >> > > I'd like to continue maintaining Ceph in Debian; my time can be a little > sporadic as it is with a number of maintainers, so doing this by myself is > not a sustainable option so maybe a request for help is more appropriate > now than full orphaning. > > I fully intent to work on pushing the work I've done for Ubuntu on Ceph > Jewel packaging back into Debian at the start of November, but I really do > need help for testing of this. I can do some basic testing using VMs, but I also don't have a fancy test lab at hand... > > >> >> Regarding ceph-dkms, this is only in experimental and has an RC bug >> that it doesn't work with the jessie kernel. >> Is there anything left that is not in the upstream kernel? >> > > Not really - I think we should just drop that package. I completely agree that this package can be dropped. I think Dimitry insisted in keeping it during the time when he was still the primary maintainer of ceph. But he as stepped down since then. I have now requested it's removal. > > Note that we really do have a problem with upgrades in Debian - going > directly from firefly to jewel is an offline upgrade (at best). But maybe > that is better than the currently upstream unsupported version we have in > testing. We at least have to document this somewhere. I doubt that there are many production clusters still using the Debian firefly version from jessie as it's quite old and lacking many features. Gaudenz -- PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5 signature.asc Description: PGP signature
Bug#815880: Fails to update /etc/resolv.conf with network-manager 1.1.90
Package: dnssec-trigger
Version: 0.13~svn685-4+b1
Severity: grave
Tags: patch
The /usr/lib/dnssec-trigger/dnssec-trigger-script fails to update
/etc/resolv.conf with the version of network-manager now in
testing and unstable. The problem is that calls to
client.get_manager_running() return False even if NetworkManager is
running. This is caused by imporper initialization of the client object.
According to https://bugzilla.redhat.com/show_bug.cgi?id=1229337 the
client object should be created with NMClient.Client().new() instead of
just using NMClient.Client(). The attached patch fixes this and resolves
the issue.
The patch also adds the recommended GI version specification before
importing NMClient. This currently only avoids a warning and if you
don't like that part you can also apply the patch without it.
Gaudenz
-- System Information:
Debian Release: stretch/sid
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (100,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dnssec-trigger depends on:
ii gir1.2-networkmanager-1.0 1.1.90-6
ii init-system-helpers1.28
ii libc6 2.21-9
ii libgdk-pixbuf2.0-0 2.32.3-1.2
ii libglib2.0-0 2.46.2-3
ii libgtk2.0-02.24.29-1
ii libldns1 1.6.17-8
ii libssl1.0.21.0.2f-2
ii python 2.7.11-1
ii python-gi 3.18.2-2
ii python-lockfile1:0.10.2-2
ii unbound1.5.7-1
dnssec-trigger recommends no packages.
dnssec-trigger suggests no packages.
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/lib/dnssec-trigger/dnssec-trigger-script (from
dnssec-trigger package)
--- /usr/lib/dnssec-trigger/dnssec-trigger-script.orig 2016-02-25 10:17:23.296285495 +0100
+++ /usr/lib/dnssec-trigger/dnssec-trigger-script 2016-02-25 10:34:25.856239132 +0100
@@ -5,6 +5,8 @@
@author: Pavel Šimerda <psime...@redhat.com>
"""
+import gi
+gi.require_version('NMClient', '1.0')
from gi.repository import NMClient
import os, sys, shutil, glob, subprocess
import logging, logging.handlers
@@ -333,7 +335,7 @@
except AttributeError:
self.usage()
self.config = Config()
-self.client = NMClient.Client()
+self.client = NMClient.Client().new()
self.resolvconf = "/etc/resolv.conf"
self.resolvconf_backup = "/run/dnssec-trigger/resolv.conf.bak"
Bug#803669: Breaks QProcess in owncloud-client tests on mips an mipsel
Hi
Dmitry Shachnev <mity...@debian.org> writes:
> Hi Gaudenz,
>
> On Wed, 04 Nov 2015 15:51:40 +0100, Gaudenz Steinlin wrote:
>> The testcase from the upstream bug report does not work on the porter
>> box with 5.5.1+dfsg-6 as well. So this fix is either not applied to this
>> build or it's incomplete.
>>
>> This is the output from the test program:
>> (sid_mipsel-dchroot)gaudenz@eder:~/testcase$ ./testcase
>> 24 Calling waitForStarted()
>> 54 waitForStarted() returned true
>> 55 Calling waitForFinished()
>> 30086 waitForFinished() returned false
>> 30086 errorString() is "Process operation timed out"
>> QProcess: Destroyed while process ("/bin/true") is still running.
>
> Are you sure you were testing with 5.5.1+dfsg-6?
>
> This bug is definitely fixed there, here is the output of the same binary on
> the same machine:
>
> (sid_mipsel-dchroot)mitya57@eder:/home/gaudenz/testcase$ ./testcase
> 3 Calling waitForStarted()
> 9 waitForStarted() returned true
> 10 Calling waitForFinished()
> 11 waitForFinished() returned true
> 12 errorString() is "Unknown error"
>
> Tried multiple times to be completely sure.
You are absolutely right. I had the shell I was testing this running in
screen and forgot that I set an LD_LIBRARY_PATH there the other day to
be able to test different Qt versions. So LD_LIBRARY_PATH was still
pointing to the old Qt version. After clearing the variable everything
is fine.
Thanks again for the quick fix and sorry for the noise.
Gaudenz
signature.asc
Description: PGP signature
Bug#803669: Breaks QProcess in owncloud-client tests on mips an mipsel
Gaudenz Steinlin <gaud...@debian.org> writes:
> Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> writes:
>
>> forwarded 803669 https://bugreports.qt.io/browse/QTBUG-49168
>> tag 803669 upstream
>> thanks
>>
>> On Monday 02 November 2015 23:07:19 Gaudenz Steinlin wrote:
>> [snip]
>>> If I read the strace output right (attached) md5sum only tahkes less
>>> than 1 second. The long 2x30s delay comes from subsequent pselect calls
>>> which may be unrelated to waitForFinished, but related to the fact the
>>> QProcess tries to kill the no longer running md5sum process.
>>
>> You are right. My wonderful teammate Dmitry has filed [qtbug] upstream.
>>
>> [qtbug] <https://bugreports.qt.io/browse/QTBUG-49168>
>>
>> The fix should be already in unstable in 5.5.1+dfsg-6, we are waiting for
>> the
>> mips/mipsel buildds to pick the package. After that please try again.
>
> Now that -6 is on the mirror the porter box uses I retried the build but
> I still have the same build failure. So something is still missing here.
>
> Next I'll try the test program in the upstream bug report to see if that
> is fixed.
The testcase from the upstream bug report does not work on the porter
box with 5.5.1+dfsg-6 as well. So this fix is either not applied to this
build or it's incomplete.
This is the output from the test program:
(sid_mipsel-dchroot)gaudenz@eder:~/testcase$ ./testcase
24 Calling waitForStarted()
54 waitForStarted() returned true
55 Calling waitForFinished()
30086 waitForFinished() returned false
30086 errorString() is "Process operation timed out"
QProcess: Destroyed while process ("/bin/true") is still running.
The strace output from running the testcase is attached.
Gaudenz
testcase.trace
Description: Binary data
signature.asc
Description: PGP signature
Bug#803669: Breaks QProcess in owncloud-client tests on mips an mipsel
Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> writes: > forwarded 803669 https://bugreports.qt.io/browse/QTBUG-49168 > tag 803669 upstream > thanks > > On Monday 02 November 2015 23:07:19 Gaudenz Steinlin wrote: > [snip] >> If I read the strace output right (attached) md5sum only tahkes less >> than 1 second. The long 2x30s delay comes from subsequent pselect calls >> which may be unrelated to waitForFinished, but related to the fact the >> QProcess tries to kill the no longer running md5sum process. > > You are right. My wonderful teammate Dmitry has filed [qtbug] upstream. > > [qtbug] <https://bugreports.qt.io/browse/QTBUG-49168> > > The fix should be already in unstable in 5.5.1+dfsg-6, we are waiting for the > mips/mipsel buildds to pick the package. After that please try again. Now that -6 is on the mirror the porter box uses I retried the build but I still have the same build failure. So something is still missing here. Next I'll try the test program in the upstream bug report to see if that is fixed. Gaudenz signature.asc Description: PGP signature
Bug#803669: Breaks QProcess in owncloud-client tests on mips an mipsel
Source: qtbase-opensource-src
Version: 5.5.0+dfsg-3
Severity: serious
Setting the severity of this bug to serious because it causes another package
to fail to build from source.
This version of Qt breaks the tests of owncloud-sync on mips and mipsel. Test
also break
when compiling version 2.0.0+dfsg-1 of owncloud-client which previously
successfully built against the newer version of Qt. So I suspect this is
a bug in Qt and not in owncloud-client.
See here for the failing build logs:
https://buildd.debian.org/status/fetch.php?pkg=owncloud-client=mipsel=2.0.2%2Bdfsg-1=1445685652
I tried to debug this on the mipsel porter box but could not resovlve
the problem. This is what I found out:
- The problem is also present when running the tests with Qt
5.5.0+dfsg-3 so setting this version. This is the first version of Qt
5.5 available for mipsel. This is likely a bug introduced with Qt 5.5.
- This is the problematic part of the code in owncloud-client which
triggers the bug (see test/testfilesystem.h in owncloud-client):
https://anonscm.debian.org/cgit/pkg-owncloud/owncloud-client.git/tree/test/testfilesystem.h
26 QByteArray shellSum( const QByteArray& cmd, const QString& file )
27 {
28QProcess md5;
29QStringList args;
30args.append(file);
31md5.start(cmd, args);
32QByteArray sumShell;
33qDebug() << "File: "<< file;
34
35if( md5.waitForFinished() ) {
36
37 sumShell = md5.readAll();
38 sumShell = sumShell.left( sumShell.indexOf(' '));
39}
40return sumShell;
41 }
This is called twice during the test to compute a md5/sha1 sum with the
command
line tool to compare this against owncloud-clients internal implementation.
The
test then fails because this function returns an empty string instead of the
correct result.
- Running the test under strace shows that the md5sum/sha1sum call succeeds and
returns
the correct string. But apparently waitForFinished just hangs for 30s
(default timeout
value) and then returns an error.
At this point I'm out of ideas on how to further debug this. Help by Qt
maintainers or
mips porters would be appreciated.
Gaudenz
-- System Information:
Debian Release: stretch/sid
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (100,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libqt5core5a depends on:
ii libc6 2.19-22
ii libgcc1 1:5.2.1-22
ii libglib2.0-0 2.46.1-1
ii libicu55 55.1-5
ii libpcre16-3 2:8.35-7.2
ii libstdc++65.2.1-22
ii zlib1g1:1.2.8.dfsg-2+b1
Versions of packages libqt5core5a recommends:
ii qttranslations5-l10n 5.5.1-2
Versions of packages libqt5core5a suggests:
ii libthai0 0.1.22-2
-- no debconf information
Bug#801477: tagged as pending
tag 801477 pending -- We believe that the bug #801477 you reported has been fixed in the Git repository. You can see the commit message below and/or inspect the commit contents at: http://anonscm.debian.org/cgit/pkg-ceph/ceph.git/diff/?id=2d14828 (This message was generated automatically by 'git-post-receive-tag-pending-commitmsg' hook). --- commit 2d14828a0914964316c9977f3f60418496fe6a2b Author: Gaudenz Steinlin <gaud...@debian.org> Date: Mon Oct 12 16:25:21 2015 +0200 Add upstream patch to fix building without libatomic-ops Closes: #801477
Bug#801477: [Ceph-maintainers] Bug#801477: ceph: FTBFS on armel: common/RWLock.h:29:11: error: 'atomic_t' does not name a type
Hi Emilio Pozuelo Monfort <po...@debian.org> writes: > Source: ceph > Version: 0.80.10-1 > Severity: serious > > Hi, > > Thanks for the upload to fix the FTBFS in sid. Unfortunately this still failed > on armel: > > Excerpt from the log: > > In file included from common/HeartbeatMap.h:26:0, > from common/HeartbeatMap.cc:21: > common/RWLock.h:29:11: error: 'atomic_t' does not name a type > > See the full log at: > > https://buildd.debian.org/status/fetch.php?pkg=ceph=armel=0.80.10-1=1444230749 I hope this is fixed by upstream commit https://github.com/ceph/ceph/commit/2e09a2c22ab885f8ec81dbc55f2c8fc0f2984543 I'm doing a test build on a porter box right now and will upload a new revision if this succeeds. Gaudenz signature.asc Description: PGP signature
Bug#795178: tagged as pending
tag 795178 pending -- We believe that the bug #795178 you reported has been fixed in the Git repository. You can see the commit message below and/or inspect the commit contents at: http://anonscm.debian.org/cgit/pkg-ceph/ceph.git/diff/?id=c8b478a (This message was generated automatically by 'git-post-receive-tag-pending-commitmsg' hook). --- commit c8b478a038cd879f0088a5a462d98495f9257c2e Author: Gaudenz Steinlin <gaud...@debian.org> Date: Tue Oct 6 14:37:06 2015 +0200 Add upstream patch to fix compiling with boost 1.58 Closes: #795178
Bug#795178: fixed in ceph 0.94.3-1
Emilio Pozuelo Monfort <po...@debian.org> writes: > [ explicit Cc's as this goes to a list that seems to be moderated... ] > > On Sat, 26 Sep 2015 16:39:46 +0200 Emilio Pozuelo Monfort <po...@debian.org> > wrote: >> Can we have this fixed in unstable as well? ceph currently fails to build >> there >> and this is blocking various transitions. > > This is blocking the boost, icu, libleveldb and libsnappy transitions. I'll > try > to look at NMU'ing this if you don't have the time. > > FWIW the version in experimental failed to build on armel, so just uploading > that to sid wouldn't be the best solution... I'd prefer a targeted fix first > so > we can finish those transitions. I would prefer that too, but I don't have the capacity to port ceph 0.80.x to libboost1.58. Unless someone can provide a patch I'd go with just uploading what we have in experimental to unstable. I meant to do some more things before uploading to unstable (like using the new UIDs for the daemons and proper systemd support), but as it's blocking other transitions it's better to just upload to unstable soon. I'm not sure how to best solve the build failure on armel. Jerasure does runtime detection of ARM features, so NEON should be enabled for machines that support it. The error suggests that the -mfloat-abi=softfp compiler option needs to be set. But I'm not sure if this is the right thing to do on armel. Some help is needed here. Gaudenz
Bug#791445: [Ceph-maintainers] Bug#791445: ceph: uses bundled libjerasure library again
severity 791445 normal retitle 791445 Use system libjerasure with CPU optimizations thanks James Page james.p...@ubuntu.com writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/07/15 18:23, James Page wrote: The ceph Debian package git repository only contains very little reasoning about the change. James can you please expand on this a bit? In general I would prefer to have changes like this in their own commit and not mixed with unrelated changelog updates. Did the Hammer release not build with the jerasure in Debian or are you just afraid of unexpected results if the Debian package is built with another version of jerasure than what they ship in their source code? These would IMO be valid reasons to (temporarily) remove the patch. Re-basing the patch - which was turning out to be non-trivial - pushed me over the time I had todo this update; as the upload was to experimental only, I intended to revisit when time permitted. I dug into this in a bit more detail today; the Ceph package builds a number of difference loadable erasure coding plugins, enabling different cpu feature sets (generic, neon, sse3, sse4); each time Jerasure and gf-complete are statically linked into the module, built with the required flags to enable the right CPU instruction codes (build time, not runtime enablement). Loic, are there plans upstream to change this? To me the best solution would be to move the runtime detection into jerasure and gf-complete and then to dynamically link against these. With this other consumers of jerasure could also benefit from this and it would make the life of distribution package maintainers much easier. But then I don't know if there are technical reasons why it was implemented that way in the first place. Unless I'm reading the packaging wrong, the jerasure and gf-complete packages current disable any CPU specific extensions in order to have a completely generic library that works on any CPU. So using the system libraries effectively cripples any CPU optimization that might be achievable at runtime in Ceph. Considering this I think using the system jerasure is not an option in it's current state. Removing all CPU optimization does not look like the right thing to do. I set the bug severity and title accordingly. This does not mean that this bug does not need fixing. A solution to have both CPU optimizations and dynamic linking against the system library would be much prefered. But in the current state just reverting to use the system library does not look like the right thing to do. Gaudenz signature.asc Description: PGP signature
Bug#791445: [Ceph-maintainers] Bug#791445: Bug#791445: ceph: uses bundled libjerasure library again
[ Adding the jerasure maintainer to the CC ] Hi Loic Dachary l...@dachary.org writes: Hi, I'm co-maintainer of both jerasure and ceph. If the Debian jerasure package was orphaned, I would be happy to step in and maintain it as a standalone package. Jerasure was packaged without dialog with the jerasure upstream and I can understand that keeping it in sync with what ceph needs is significant work. Loic thanks for your offer to help with this. We definitively need some upstream assistence on this. IMO while the current approach to just use the bundled version is suboptimal, the previous approach to just unilaterally use a different version of jerasure than upstream is not good either. Currently ceph is AFAICS the only reverse dependency of jerasure. I don't know why Thomas packaged it in the first place. But if we want to keept the standalone package it might be the best for the ceph maintainers group to take over maintenance of the jerasure Debian package. I hope Thomas won't mind if we lower the burden for him a bit. The ceph Debian package git repository only contains very little reasoning about the change. James can you please expand on this a bit? In general I would prefer to have changes like this in their own commit and not mixed with unrelated changelog updates. Did the Hammer release not build with the jerasure in Debian or are you just afraid of unexpected results if the Debian package is built with another version of jerasure than what they ship in their source code? These would IMO be valid reasons to (temporarily) remove the patch. What's the ceph upstream position on splitting out jerasure and building against the standalone version? Is this considered supported? Are you willing to accept a patch which either uses a standalone jerausre for all builds or which introduces a configure flag to do so? As I understand the current situation the jerasure code is a submodule inside the ceph git repository and referencing a special v2-ceph branch. Is this going to stay like this or are you planing on integrating all this into jerasure and making this tight coupling obsolete. From a Distribution packagers standpoint the current situation is less than optimal. I would very much prefer to not have third party libraries bundled in the source code. But without upstream cooperation this is hard to solve, more so as the bundled library is also a modified version of the original jerasure code. BTW all said above similarly applies to gf-complete. I think these two dependencies have to be resolved in the same manner. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778618: [PKG-Openstack-devel] Bug#778618: Bug#778618: This patch is not enough
Moritz Muehlenhoff j...@inutil.org writes: On Fri, Feb 27, 2015 at 10:18:46PM +, Paul McMillan wrote: If you agree that the linked github patch is complete, I can do an upload if you lack the time to do so yourself. I can understand that sensitive security issues are involved, but a bit more verboseness would be nice. The linked patch on github is a true and complete fix for the original reported issue. Gaudenz, can you please upload a fixed package? Thomas already uploaded the fix to unstable, so this should be fine. Is a stable upload needed as well? Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778618: [PKG-Openstack-devel] Bug#778618: This patch is not enough
Thomas Goirand z...@debian.org writes: Hi, I'm not supposed to disclose too much yet, but I have to write in this bug still. The provided patch is *not enough* and the issue is still being discussed upstream. So I can't just patch novnc and be gone with it... I'll update this package as soon as upstream provides a working patch. Do you have a link to the upstream discussion? Or is this about an embargoed security issue? Cheers, Thomas Goirand (zigo) Paul McMillan p...@mcmillan.ws writes: Thomas Goirand's comment is in response to an unrelated upstream bug in a different software package. The linked github patch is a complete fix for the reported issue. -Paul I'm confused. What's true now, to which other upstream bug does this refer? Can both of you please clarify. We really need to solve this bug soon, otherwise significant parts of OpenStack will get removed from jessie and probably won't be allowed back in again. If you agree that the linked github patch is complete, I can do an upload if you lack the time to do so yourself. I can understand that sensitive security issues are involved, but a bit more verboseness would be nice. Gaudenz signature.asc Description: PGP signature
Bug#773354: please add breaks: live-tools ( 4.0.1-1)
Andreas Henriksson andr...@fatal.se writes: Hello Gaudenz Steinlin! On Mon, Feb 02, 2015 at 10:25:07PM +0100, Gaudenz Steinlin wrote: Hi Andreas My NMU was in no way meant to critice your maintenance of util-linux or to attack you. It's just that in the current phase of the release process it's time to fix these bugs and my aim is to help with that. As you stated that you are not very motivated to work on this bug I thought you would appreciate this help. I absolutely appreciate that you're interested in working on this and I in no way see it as a critisism of my work. If my replies sound harsh and annoyed it's only because I'm busy and low on both motivation for Debian-work and low on energy. Please don't let that distract you. Please try to help dig through what I'm saying for the point that is technically adressable. I'm sorry I'm not better at english which is a limiting factor for me being able to express myself more clearly. Hopefully what I write gives you some clues to what issues I might have spotted. Thanks for your kind explanation. Much appreciated. As you now uploaded a fixed version yourself, there is no need to do anything for me anymore. Thanks. I'll try to find a list of other packages affected by the live-tools bug and submit bug reports. Gaudenz signature.asc Description: PGP signature
Bug#773354: please add breaks: live-tools ( 4.0.1-1)
Hi Andreas Andreas Henriksson andr...@fatal.se writes: Hi! On Thu, Feb 05, 2015 at 01:46:22PM +0100, Gaudenz Steinlin wrote: [...] I'll try to find a list of other packages affected by the live-tools bug and submit bug reports. Fwiw, I noticed live-tools is targeted for auto-removal soon when reading through the recent release team announcement. Maybe fixing live-tools itself would be your first stop. I guess otherwise the workarounds aren't a good use of your time. I already fixed this RC bug before doing the util-linux upload. So this should be taken care of unless the release team does not approve the unblock request. And as packages are not automatically removed on upgrade the bug would even show up when live-tools is removed from testing. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775795: Patch to use /usr/sbin/service in Debian service provider
Hi Gaudenz Steinlin gaud...@debian.org writes: Stephen Gran sg...@debian.org writes: Hi, This one time, at band camp, Stig Sandbeck Mathisen said: Hello, Thanks for the patch. It looks like it has the correct solution, using the Debian abstraction layer over the alternative init systems. However, I've found a problem with it using the puppet resource command. Could you see if you find what causes it? The idea in my patch is to add the service_cmd definition to ensure that this provider is only choosen if the service command is available. But you can't use this command because of the way the provider works. The problem is that startcmd, stopcmd, etc. should return an array with the command and it's argument. The problem is probably that I replaced the hardcoded /usr/sbin/service by a variable after testing the patch and screwed that up somehow. I'm right now looking into this and will send a new patch as soon as it's fixed. Attached is an updated patch that uses a propoer Ruby constant for /usr/sbin/service. The first patch was botched by my Pythonistic approach to code this. If I understand Stephens patch correctly it directly executes the service comamnd during the call to XXXcmd. As far as I can see this is not the way things should work (looking at provider/service/base.rb). I did not manage to get this patch to run at all :-(. Gaudenz From 089cb15a2ec53831def122a958965e950709b664 Mon Sep 17 00:00:00 2001 From: Gaudenz Steinlin gaud...@debian.org Date: Thu, 5 Feb 2015 12:14:06 +0100 Subject: [PATCH] Use /usr/sbin/service in Debian service provider Closes: #775795 --- .../0004-debian-service-provider-use-service.patch | 56 ++ debian/patches/series | 1 + 2 files changed, 57 insertions(+) create mode 100644 debian/patches/0004-debian-service-provider-use-service.patch diff --git a/debian/patches/0004-debian-service-provider-use-service.patch b/debian/patches/0004-debian-service-provider-use-service.patch new file mode 100644 index 000..0a81c3e --- /dev/null +++ b/debian/patches/0004-debian-service-provider-use-service.patch @@ -0,0 +1,56 @@ +From: Gaudenz Steinlin gaud...@debian.org +Subject: Use /usr/sbin/service for service management on Debian + +In Debian jessie systemd will be the default init system. But the old system V +and other alternative init systems are still supported. /usr/sbin/service +provides an abstraction layer which is able to start, stop and restart +services independent of the init system used. + +Bug: https://tickets.puppetlabs.com/browse/PUP-2023 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775795 +--- +Index: puppet/lib/puppet/provider/service/debian.rb +=== +--- puppet.orig/lib/puppet/provider/service/debian.rb 2015-02-05 12:07:37.451292892 +0100 puppet/lib/puppet/provider/service/debian.rb 2015-02-05 12:13:06.500095957 +0100 +@@ -16,6 +16,11 @@ + # is resolved. + commands :invoke_rc = /usr/sbin/invoke-rc.d + ++ # This isn't being used directly, it's just here to ensure ++ # that the /usr/sbin/service binary is available. ++ SERVICE = /usr/sbin/service ++ commands :service_cmd = SERVICE ++ + defaultfor :operatingsystem = :debian + + # Remove the symlinks +@@ -61,4 +66,28 @@ + update_rc -f, @resource[:name], remove + update_rc @resource[:name], defaults + end ++ ++ # The start, stop, restart and status command use service ++ # this makes sure that these commands work with whatever init ++ # system is installed ++ def startcmd ++[SERVICE, @resource[:name], :start] ++ end ++ ++ # The stop command is just the init script with 'stop'. ++ def stopcmd ++[SERVICE, @resource[:name], :stop] ++ end ++ ++ def restartcmd ++(@resource[:hasrestart] == :true) [SERVICE, @resource[:name], :restart] ++ end ++ ++ # If it was specified that the init script has a 'status' command, then ++ # we just return that; otherwise, we return false, which causes it to ++ # fallback to other mechanisms. ++ def statuscmd ++(@resource[:hasstatus] == :true) [SERVICE, @resource[:name], :status] ++ end ++ + end diff --git a/debian/patches/series b/debian/patches/series index 471a23b..6543a01 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,3 +1,4 @@ 0001-Do-not-require-rubygems.patch 0002-Set-passenger-puppet-master-document-root.patch 0003-fix-puppet-master-logcheck-rule.patch +0004-debian-service-provider-use-service.patch -- 2.1.4 signature.asc Description: PGP signature
Bug#775795: Patch to use /usr/sbin/service in Debian service provider
Stephen Gran sg...@debian.org writes:
Hi,
This one time, at band camp, Stig Sandbeck Mathisen said:
Hello,
Thanks for the patch. It looks like it has the correct solution, using
the Debian abstraction layer over the alternative init systems.
However, I've found a problem with it using the puppet resource
command. Could you see if you find what causes it?
The idea in my patch is to add the service_cmd definition to ensure that
this provider is only choosen if the service command is available. But
you can't use this command because of the way the provider works. The
problem is that startcmd, stopcmd, etc. should return an array with the
command and it's argument.
The problem is probably that I replaced the hardcoded /usr/sbin/service
by a variable after testing the patch and screwed that up somehow. I'm
right now looking into this and will send a new patch as soon as it's
fixed.
If I understand Stephens patch correctly it directly executes the
service comamnd during the call to XXXcmd. As far as I can see this is
not the way things should work (looking at provider/service/base.rb).
Gaudenz
With puppet 3.7.22-1:
,
| root@dagon:~# puppet resource service apache2
| service { 'apache2':
| ensure = 'stopped',
| enable = 'true',
| }
`
With your patch:
,
| root@dagon:~# puppet resource service apache2
| Error: Could not run: undefined local variable or method `service' for
#Puppet::Type::Service::ProviderDebian:0x00029b9d88
`
Try this (lightly tested) one instead. The problem is in the definition
and use of the service command in the first patch.
Cheers,
--
-
| ,''`.Stephen Gran |
| : :' :sg...@debian.org |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
From 2eae3a2a71de50889535f0e917ac6f4ecaeb8975 Mon Sep 17 00:00:00 2001
From: Gaudenz Steinlin gaud...@soziologie.ch
Date: Sat, 31 Jan 2015 16:09:08 +0100
Subject: [PATCH] Use /usr/sbin/service in Debian service provider
Closes: #775795
---
.../0004-debian-service-provider-use-service.patch | 56
++
debian/patches/series | 1 +
2 files changed, 57 insertions(+)
create mode 100644
debian/patches/0004-debian-service-provider-use-service.patch
diff --git a/debian/patches/0004-debian-service-provider-use-service.patch
b/debian/patches/0004-debian-service-provider-use-service.patch
new file mode 100644
index 000..29a4277
--- /dev/null
+++ b/debian/patches/0004-debian-service-provider-use-service.patch
@@ -0,0 +1,56 @@
+From: Gaudenz Steinlin gaud...@debian.org
+Subject: Use /usr/sbin/service for service management on Debian
+
+In Debian jessie systemd will be the default init system. But the old system
V
+and other alternative init systems are still supported. /usr/sbin/service
+provides an abstraction layer which is able to start, stop and restart
+services independent of the init system used.
+
+Bug: https://tickets.puppetlabs.com/browse/PUP-2023
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775795
+---
+Index: puppet/lib/puppet/provider/service/debian.rb
+===
+--- puppet.orig/lib/puppet/provider/service/debian.rb2015-01-31
17:30:09.0 +0100
puppet/lib/puppet/provider/service/debian.rb 2015-01-31
23:05:10.477108925 +0100
+@@ -16,6 +16,11 @@
+ # is resolved.
+- commands :invoke_rc = /usr/sbin/invoke-rc.d
++ commands :invoke_rc = /usr/sbin/invoke-rc.d, :service = service
+
+ defaultfor :operatingsystem = :debian
+
+ # Remove the symlinks
+@@ -61,4 +66,28 @@
+ update_rc -f, @resource[:name], remove
+ update_rc @resource[:name], defaults
+ end
++
++ # The start, stop, restart and status command use service
++ # this makes sure that these commands work with whatever init
++ # system is installed
++ def startcmd
++service @resource[:name], start
++ end
++
++ # The stop command is just the init script with 'stop'.
++ def stopcmd
++service @resource[:name], stop
++ end
++
++ def restartcmd
++(@resource[:hasrestart] == :true) service @resource[:name], restart
++ end
++
++ # If it was specified that the init script has a 'status' command, then
++ # we just return that; otherwise, we return false, which causes it to
++ # fallback to other mechanisms.
++ def statuscmd
++(@resource[:hasstatus] == :true) service @resource[:name], status
++ end
++
+ end
diff --git a/debian/patches/series b/debian/patches/series
index 471a23b..6543a01 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3
Bug#773354: please add breaks: live-tools ( 4.0.1-1)
Hi Andreas My NMU was in no way meant to critice your maintenance of util-linux or to attack you. It's just that in the current phase of the release process it's time to fix these bugs and my aim is to help with that. As you stated that you are not very motivated to work on this bug I thought you would appreciate this help. Andreas Henriksson andr...@fatal.se writes: Hello Gaudenz Steinlin. On Mon, Feb 02, 2015 at 11:25:55AM +0100, Gaudenz Steinlin wrote: Of course a fix in util-linux can't solve problems resulting from other packages. All packages that call update-initramfs and don't depend on initramfs-tools need the same Breaks relation to live-tools. I don't know how many other such packages exist beside util-linux. Easy to find out thanks to the awesome codesearch: http://codesearch.debian.net/perpackage-results/update-initramfs/2/page_0 (Adding regexps to the query for filtering out only relevant matches is left as an exercise to the reader.) In other words, many That is why adding breaks IMHO is not a viable solution at all anywhere. That does not really help much because we don't need a list of packages that mention update-initramfs in some file but a list of packages that call update-initramfs in their maintainerscript without depending on initramfs-tools. I don't think codesearch is able to produce that list, but to me this seems like a quite special case. I would expect most packages that modify the initramfs to actually depend on initramfs-tools. But I agree that probably more packages than just util-linux need fixing for this. But this is outside the scope of this bug and as long as no other bugs are filed, it's hard to track. I also don't see a viable solution to this bug which fixes all of these problems in one go. I agree that fixing the problem with Breaks is a bit ugly and in theory adds the fix to the wrong package. But I currently don't see any viable other solution to this problem beside adding all these Breaks relations. An update to the stable version of live-tools does not seem practical to me. Do you see another way to fix this? Yes. Please read my previous mail to the bug report. So if I got you right, you would prefer to remove the update-initramfs call from util-linux's postinst. I'm fine with that. I can do another upload if you confirm that's your prefered solution. If initramfs-tools from current unstable really does not go into testing, then I agree that is probably the slightly better alternative. To me as an NMUer the Breaks seemd like the safer option as it's a no-op as long as live-tools is not installed on the same system. So there is less chance that the NMU breaks something. This is just one example out of several problems I see with your NMU. Which other problem do you see? Well, for one: Your NMU is RC buggy, given that you incorporated the previous NMU with bugs and all. Thanks for taking responsibility for that. ;) Well for one it was not my upload that introduced this RC bug. The version of the previous NMU was already in *testing* when I did my upload. IMO we are all colectively responsible for getting the jessie RC bug count down. So it's as much my responsibility to fix this as yours. ;-) But if I do another upload I will also fix the typo in the 4.1 NMU. I missed the fact that the 4.1 NMU did not fix the bug it claimed to fix. Please, again, also read my previous mail to the bug report you're trying to fix and you'll find a similar but IMHO much more valid reason to add a Breaks for another package (which is also that packages bug and not a bug in util-linux). I don't understand what you mean here. Maybe you should be a bit more explicit in your message instead of alluding to what others should do. As you probably understand, I'm trying to urge you into looking at the whole picture instead of just a tiny part. That way I'm sure you'll likely come up with much better solutions. I don't completely understand what you are aiming at. IMO I always considered the whole picture but I don't see why the grml-debootstrap issue is related. Yes it's an issue, yes it'might be solved with a Breaks (did not look into it very deeply). But it's not about update-initramfs and has a completely different cause. I don't see how these two issues can be solved together. They seem quite orthogonal to me. And last but not least the grml-debootstrap does not even have RC severity at the moment. If you as one of the util-linux maintainers think this is RC, please set the severity accordingly. Gaudenz P.S.: If you really don't like the upload and prefer the current state in testing you should also comment on the unblock bug which is #776765. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773354: please add breaks: live-tools ( 4.0.1-1)
Andreas Henriksson andr...@fatal.se writes: Hello Gaudenz Steinlin. On Sun, Feb 01, 2015 at 12:31:24PM +0100, Gaudenz Steinlin wrote: [...] - The version of live-tools in wheezy does not depend on initramfs-tools, but calls the original version of update-initramfs (diverted) without checking it's actually there. This is the underlying bug. This is bug #729810, fixed in jessie by adding the correct dependency. - On upgrade initramfs-tools is pulled in as a new dependency of live-tools. But util-linux is configured before live-tools and initramfs-tools are even unpacked. This is completely valid as util-linux does not depend on either of them and checks before calling update-initramfs if it exists. - The util-linux postinst no calls update-initramfs from the old version of live-tools. This version of update-initramfs is broken and thus the postinst fails. Voilà. [...] How does your patch deal with the situation where you have an affected wheezy system, you add jessie repos, then you do a partial upgrade (which is supposed to be supported in Debian) of just some package (not including util-linux) that runs update-initramfs? I bet you get the very same problem as before. Of course a fix in util-linux can't solve problems resulting from other packages. All packages that call update-initramfs and don't depend on initramfs-tools need the same Breaks relation to live-tools. I don't know how many other such packages exist beside util-linux. I agree that fixing the problem with Breaks is a bit ugly and in theory adds the fix to the wrong package. But I currently don't see any viable other solution to this problem beside adding all these Breaks relations. An update to the stable version of live-tools does not seem practical to me. Do you see another way to fix this? This is just one example out of several problems I see with your NMU. Which other problem do you see? Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773354: please add breaks: live-tools ( 4.0.1-1)
On 12/17/2014 6:27 PM, Daniel Baumann wrote: On 12/17/14 23:50, Andreas Henriksson wrote: I'd guess (without having looked) because live-tools diverts update-initramfs? no, it's about uptime. What? No this is not about uptime at all. The uptime diversion is a different bug. What happens here is the following: - The version of live-tools in wheezy does not depend on initramfs-tools, but calls the original version of update-initramfs (diverted) without checking it's actually there. This is the underlying bug. This is bug #729810, fixed in jessie by adding the correct dependency. - On upgrade initramfs-tools is pulled in as a new dependency of live-tools. But util-linux is configured before live-tools and initramfs-tools are even unpacked. This is completely valid as util-linux does not depend on either of them and checks before calling update-initramfs if it exists. - The util-linux postinst no calls update-initramfs from the old version of live-tools. This version of update-initramfs is broken and thus the postinst fails. Voilà. In theory the best solution would be to add a Breaks: util-linux (correct version) to live-tools in wheezy, but that's not practical. So the second best option is probably to add a Breaks as suggested to util-linux. I'll prepare a patch for this now. Gaudenz signature.asc Description: PGP signature
Bug#773354: please add breaks: live-tools ( 4.0.1-1)
Gaudenz Steinlin gaud...@debian.org writes: On 12/17/2014 6:27 PM, Daniel Baumann wrote: On 12/17/14 23:50, Andreas Henriksson wrote: I'd guess (without having looked) because live-tools diverts update-initramfs? no, it's about uptime. What? No this is not about uptime at all. The uptime diversion is a different bug. What happens here is the following: - The version of live-tools in wheezy does not depend on initramfs-tools, but calls the original version of update-initramfs (diverted) without checking it's actually there. This is the underlying bug. This is bug #729810, fixed in jessie by adding the correct dependency. - On upgrade initramfs-tools is pulled in as a new dependency of live-tools. But util-linux is configured before live-tools and initramfs-tools are even unpacked. This is completely valid as util-linux does not depend on either of them and checks before calling update-initramfs if it exists. - The util-linux postinst no calls update-initramfs from the old version of live-tools. This version of update-initramfs is broken and thus the postinst fails. Voilà. In theory the best solution would be to add a Breaks: util-linux (correct version) to live-tools in wheezy, but that's not practical. So the second best option is probably to add a Breaks as suggested to util-linux. I'll prepare a patch for this now. Done and uploaded now. I pushed the changes to the util-linux git repository on git.debian.org. The fix works, tested the upgrade in chroot. Gaudenz signature.asc Description: PGP signature
Bug#775795: Patch to use /usr/sbin/service in Debian service provider
Control: tags -1 +patch Hi I created a patch to use /usr/sbin/service as suggested earlier in this report to start/stop/status/restart services on Debian. I'm a bit reluctant to just NMU puppet and would prefer if one of the maintainers and/or Faidon could have a look at my patch first. If you approve I can then do the NMU if you are short on time. I tested the patch locally and as far as I can see it works fine with systemd and does call the right command. I don't have a system with system V handy to test on. Gaudenz From 2eae3a2a71de50889535f0e917ac6f4ecaeb8975 Mon Sep 17 00:00:00 2001 From: Gaudenz Steinlin gaud...@soziologie.ch Date: Sat, 31 Jan 2015 16:09:08 +0100 Subject: [PATCH] Use /usr/sbin/service in Debian service provider Closes: #775795 --- .../0004-debian-service-provider-use-service.patch | 56 ++ debian/patches/series | 1 + 2 files changed, 57 insertions(+) create mode 100644 debian/patches/0004-debian-service-provider-use-service.patch diff --git a/debian/patches/0004-debian-service-provider-use-service.patch b/debian/patches/0004-debian-service-provider-use-service.patch new file mode 100644 index 000..29a4277 --- /dev/null +++ b/debian/patches/0004-debian-service-provider-use-service.patch @@ -0,0 +1,56 @@ +From: Gaudenz Steinlin gaud...@debian.org +Subject: Use /usr/sbin/service for service management on Debian + +In Debian jessie systemd will be the default init system. But the old system V +and other alternative init systems are still supported. /usr/sbin/service +provides an abstraction layer which is able to start, stop and restart +services independent of the init system used. + +Bug: https://tickets.puppetlabs.com/browse/PUP-2023 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775795 +--- +Index: puppet/lib/puppet/provider/service/debian.rb +=== +--- puppet.orig/lib/puppet/provider/service/debian.rb 2015-01-31 17:30:09.0 +0100 puppet/lib/puppet/provider/service/debian.rb 2015-01-31 23:05:10.477108925 +0100 +@@ -16,6 +16,11 @@ + # is resolved. + commands :invoke_rc = /usr/sbin/invoke-rc.d + ++ # This isn't being used directly, it's just here to ensure ++ # that the /usr/sbin/service binary is available. ++ service = /usr/sbin/service ++ commands :service_cmd = service ++ + defaultfor :operatingsystem = :debian + + # Remove the symlinks +@@ -61,4 +66,28 @@ + update_rc -f, @resource[:name], remove + update_rc @resource[:name], defaults + end ++ ++ # The start, stop, restart and status command use service ++ # this makes sure that these commands work with whatever init ++ # system is installed ++ def startcmd ++[service, @resource[:name], :start] ++ end ++ ++ # The stop command is just the init script with 'stop'. ++ def stopcmd ++[service, @resource[:name], :stop] ++ end ++ ++ def restartcmd ++(@resource[:hasrestart] == :true) [service, @resource[:name], :restart] ++ end ++ ++ # If it was specified that the init script has a 'status' command, then ++ # we just return that; otherwise, we return false, which causes it to ++ # fallback to other mechanisms. ++ def statuscmd ++(@resource[:hasstatus] == :true) [service, @resource[:name], :status] ++ end ++ + end diff --git a/debian/patches/series b/debian/patches/series index 471a23b..6543a01 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,3 +1,4 @@ 0001-Do-not-require-rubygems.patch 0002-Set-passenger-puppet-master-document-root.patch 0003-fix-puppet-master-logcheck-rule.patch +0004-debian-service-provider-use-service.patch -- 2.1.4 signature.asc Description: PGP signature
Bug#774915: live-tools: diff for NMU version 4.0.2-1.1
Control: tags 774915 + patch Dear maintainer, I've prepared an NMU for live-tools (versioned as 4.0.2-1.1). The diff is attached to this message. Regards. Gaudenz diff -Nru live-tools-4.0.2/debian/changelog live-tools-4.0.2/debian/changelog --- live-tools-4.0.2/debian/changelog 2014-12-10 10:04:17.0 +0100 +++ live-tools-4.0.2/debian/changelog 2015-02-01 01:53:42.0 +0100 @@ -1,3 +1,10 @@ +live-tools (4.0.2-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Move removal of diversion to postinst (Closes: #774915) + + -- Gaudenz Steinlin gaud...@debian.org Sun, 01 Feb 2015 01:53:17 +0100 + live-tools (4.0.2-1) unstable; urgency=low * Removing left-over divertion on procps when upgrading from before diff -Nru live-tools-4.0.2/debian/live-tools.postinst live-tools-4.0.2/debian/live-tools.postinst --- live-tools-4.0.2/debian/live-tools.postinst 1970-01-01 01:00:00.0 +0100 +++ live-tools-4.0.2/debian/live-tools.postinst 2015-02-01 01:40:14.0 +0100 @@ -0,0 +1,14 @@ +#!/bin/sh +set -e + +if [ $1 = configure ] +then + # upgrade from live-tools 4.0.1 + if dpkg-divert --package live-tools --list | grep -F /usr/bin/uptime.orig.procps + then + dpkg-divert --package live-tools --quiet --remove --rename --divert /usr/bin/uptime.orig.procps /usr/bin/uptime + dpkg-divert --package live-tools --quiet --remove --rename --divert /usr/share/man/man1/uptime.orig.procps.1.gz /usr/share/man/man1/uptime.1.gz + fi +fi + +#DEBHELPER# diff -Nru live-tools-4.0.2/debian/live-tools.preinst live-tools-4.0.2/debian/live-tools.preinst --- live-tools-4.0.2/debian/live-tools.preinst 2014-12-10 10:04:17.0 +0100 +++ live-tools-4.0.2/debian/live-tools.preinst 2015-02-01 01:37:39.0 +0100 @@ -8,12 +8,6 @@ dpkg-divert --package live-tools --quiet --add --rename --divert /usr/sbin/update-initramfs.orig.initramfs-tools /usr/sbin/update-initramfs dpkg-divert --package live-tools --quiet --add --rename --divert /usr/share/man/man8/update-initramfs.orig.initramfs-tools.8.gz /usr/share/man/man8/update-initramfs.8.gz - # upgrade from live-tools 4.0.1 - if [ -e /usr/bin/uptime.orig.procps ] - then - dpkg-divert --package live-tools --quiet --remove --rename --divert /usr/bin/uptime.orig.procps /usr/bin/uptime - dpkg-divert --package live-tools --quiet --remove --rename --divert /usr/share/man/man1/uptime.orig.procps.1.gz /usr/share/man/man1/uptime.1.gz - fi ;; abort-upgrade) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774383: init script fails to start daemon
Package: designate-api
Version: 2014.1-15
Severity: grave
Tags: patch
The designate-api service fails to start because the NAME variable in
the init script is set to -api instead of designate-api. This is due
to using a substitution variable $SERVICE_NAME which is not defined. The
variable $PROJECT_NAME should be used instead. The patch below fixes
this issue.
Gaudenz
diff --git a/debian/designate-api.init.in b/debian/designate-api.init.in
index 52a69fd..ee7435f 100644
--- a/debian/designate-api.init.in
+++ b/debian/designate-api.init.in
@@ -17,4 +17,4 @@
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC=Designate DNSaaS API
PROJECT_NAME=designate
-NAME=${SERVICE_NAME}-api
+NAME=${PROJECT_NAME}-api
-- System Information:
Debian Release: 8.0
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (100,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773504: NMU patch on top of current GIT
Hi Please find attached the patch on top of the current git tree on Alioth for the NMU of version 2014.1.3-7.1. If you add me to the Alioth project I can also push these changes myself. Gaudenz From 6f8528cc0cd4d7c2bd0a8f2519971acec310cdf9 Mon Sep 17 00:00:00 2001 From: Gaudenz Steinlin gaud...@soziologie.ch Date: Tue, 30 Dec 2014 23:41:16 +0100 Subject: [PATCH] Fix changelog and add NMU version The two last changelog entries don't belong to the -7 release which is already uploaded. Also add bug number to changelog entry. --- debian/changelog | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/debian/changelog b/debian/changelog index b0c0add..3f354cc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +nova (2014.1.3-7.1) unstable; urgency=medium + + * Non-maintainer upload. + * Added avoid_changing_UUID_when_redefining_nwfilters.patch so that nova +continues to work with libvirt = 1.2.7 (Closes: #773504). + * Updated the es.po debconf translation, thanks to jathan +jathanblack...@openmailbox.org (Closes: #773483). + + -- Gaudenz Steinlin gaud...@debian.org Tue, 30 Dec 2014 23:41:04 +0100 + nova (2014.1.3-7) unstable; urgency=medium * Now init scripts depends on libvirtd and not libvirt-bin, as this has been @@ -11,10 +21,6 @@ nova (2014.1.3-7) unstable; urgency=medium openstack-pkg-tools (= 20~). * Only calls pkgos_dbc_postinst if the user asked for dbconf-common management. - * Added avoid_changing_UUID_when_redefining_nwfilters.patch so that nova -continues to work with libvirt = 1.2.7. - * Updated the es.po debconf translation, thanks to jathan -jathanblack...@openmailbox.org (Closes: #773483). -- Thomas Goirand z...@debian.org Wed, 10 Dec 2014 19:21:37 +0800 -- 2.1.4 signature.asc Description: PGP signature
Bug#770941: [PKG-Openstack-devel] Bug#770941: closed by Thomas Goirand z...@debian.org (Re: Bug#770941: closed by Thomas Goirand z...@debian.org (Re: Bug#770941: nova-common - Overrides database c
Hi Bastian Blank bastian.bl...@credativ.de writes: Control: reopen -1 On Wed, Nov 26, 2014 at 01:09:08AM +, Debian Bug Tracking System wrote: It is a valid DSN. In this: postgresql:///nova Where's the user and password? What's the hostname? User and password is not needed for ident auth, empty hostname is documented as using the unix socket. And the documentation tells:[1] | These URLs follow RFC-1738, and usually can include username, password, | hostname, database name as well as optional keyword arguments for | additional configuration. In some cases a file path is accepted, and in | others a “data source name” replaces the “host” and “database” portions. So they _can_ include, not they _must_ include. Also there are examples of this usage. If theoretically, this *may* be a valid DSN, but practically, I don't think you'd be using a DNS without a valid hostname, login and pass. It is valid in practice, otherwise it would not work in the first place. I tend to agree with Bastian here. This change must be preserved. And to me it also seems that having the database on the same host is a very valid and not only theoretical setup. But basically this is beyond the point (see below). And even if not, it must not change it. The idea behind the policy is that a config script shouldn't change a valid configuration, so that it is possible edit the configuration file, and that change be kept when installing or upgrading. No, the idea is that the user have all right to change it to whatever he wants. You can use ucf to do this task of merging config files. Again I tend to agree with Bastian. I can't see anything in policy (section 10.7.3) where the provision local changes must be preserved during a package upgrade is somehow limited to configurations the maintainer thinks are valid. While I can see some valid cases where you can change or upgrade a clearly non functioning config file. This is definitely not the case we are talking about. P.S: Please don't reopen the bug. The config and postinst scripts are doing exactly what I wanted them to do, and I feel like this is the correct behavior. If you don't like the current behavior, I welcome you to discuss it in the packaging list, but using BTS ping-pong isn't the way to do so. Please keep this bug open. There is obviously a bug somewhere in the maintainer scripts. Well, I don't think so. You can yourself refer to the ctte or I will. I don't think we need the ctte to solve this. Can't we just work together and find a solution? Gaudenz signature.asc Description: PGP signature
Bug#769395: [Ceph-maintainers] Bug#769395: ceph-dkms: module FTBFS for kernel 3.16.0-4
Hi Dmitry Smirnov only...@debian.org writes: On Thu, 13 Nov 2014 15:27:30 Gaudenz Steinlin wrote: Is this package still usefull? Perhaps it is not too useful right now but I'm planning to update it for kernel 3.16 eventually... Both the ceph filesystem module and the rbd module are included in the upstream kernel and AFAICS regularly updated. I would never needed ceph-dkms in first place if Ceph were maintained in kernel well enough... Hm, that surprises me. But I'm not too familiar with it as I'm mostly using the rbd backend to qemu. But before writing the above sentence I compared the code here https://github.com/ceph/ceph-client to the upstream linux kernel and could not find any differences. But then maybe I did not look at the right branches or the right repository at all. Maybe it's better to just remove this package. What's the rush? ceph-dkms is in experimental only... I agree there is no rush at all. If there is a good use case for the package and there is code around which is more up to date than what's included in 3.16 I'm all in favor of keeping the package. I just think there is not much point in keeping a package that's not updated and obsolete. On Thu, 13 Nov 2014 10:29:22 Ken Dreyer wrote: I was wondering the same. Could Debian users just rely on the kernel module in the main kernel package? That's pretty much the current situation -- we have ceph-dkms only in experimental so when needed we could test fixes promptly (or rapidly deploy hot-fixes when necessary). I tried to rely on kernel modules in main kernel package and failed miserably -- as consequence I had to make ceph-dkms to test and deploy critical fixes. We do not encourage ceph-dkms and it is available only to advanced users who know about experimental suite. Package even have a note that it is not suitable for release... It was not obvious to me that ceph-dkms is intended to always stay in experimental. If it's not intended to ever go into unstable/testing/stable I see no problem with the current state. If things really fail miserably I would prefer to have the relevant patches in a stable kernel update though. AFAIK the Debian kernel maintainers are open to adding backported fixes that are included into the upstream kernel in later versions. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769395: [Ceph-maintainers] Bug#769395: ceph-dkms: module FTBFS for kernel 3.16.0-4
Andreas Beckmann a...@debian.org writes: Package: ceph-dkms Version: 3.14+git20140429-1 Severity: serious The module fails to build for a recent kernel: /var/lib/dkms/ceph/3.14+git20140429/build/ceph/file.c:740:4: error: implicit declaration of function 'iov_iter_copy_from_user' [-Werror=implicit-function-declaration] /var/lib/dkms/ceph/3.14+git20140429/build/ceph/file.c:833:4: error: implicit declaration of function 'generic_segment_checks' [-Werror=implicit-function-declaration] /var/lib/dkms/ceph/3.14+git20140429/build/ceph/file.c:857:3: error: implicit declaration of function 'generic_file_aio_read' [-Werror=implicit-function-declaration] /var/lib/dkms/ceph/3.14+git20140429/build/ceph/file.c:982:3: error: implicit declaration of function 'generic_file_buffered_write' [-Werror=implicit-function-declaration] /var/lib/dkms/ceph/3.14+git20140429/build/ceph/file.c:1289:18: error: 'generic_file_splice_write' undeclared here (not in a function) Is this package still usefull? Both the ceph filesystem module and the rbd module are included in the upstream kernel and AFAICS regularly updated. Maybe it's better to just remove this package. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765132: user-mode-linux NMU
Hi Jakub Thanks for taking the time to do the user-mode-linux NMU. I was just looking into this because I was worried about nova being removed from testing. As this bug is already open for more than 2 weeks and kernel 3.13 was long gone from the archive before, I think you can directly upload this to unstable without going to the DELAYED queue. It was long obvious that the package can't be released in this state and the maintainers did not take any action. And testing is supposed to be frozen in less than 5 days. Please also submit an unblock bug on release.debian.org once the upload is in unstable. As the package won't reach testing before the freeze without this. (I guess you know this but just in case you did not think about it) Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Hi Mehdi Dogguy me...@dogguy.org writes: Control: reassign 764441 sinfo Control: fixed 764441 0.0.47-2 Le 2014-10-11 23:58, Gaudenz Steinlin a écrit : Hi Mehdi Dogguy me...@dogguy.org writes: Le 2014-10-09 22:55, Gaudenz Steinlin a écrit : I will certainly update the Conflict if we can't agree on a better solution in the next few days. But as the Conflict was a workaround from the begining I'd prefer a solution where we agree on different names for the commands instead. I very much agree with what you say, but I think it is rather late to find a stable name (where also upstream is confortable with) in time for Jessie. There are only a few days left before the freeze. For that reason, I prefer to keep the old (and not so nice) workaround and work on a better solution to implement in Jessie+1. I've now uploaded a package with the conflict updated to slurm-client. Thanks. This is very much appreciated! (and marked as such) Besides, please note that you should still conflict with the old binary package name to support partial upgrades. Just to be sure and to not have to do yet another upload. Adding a conflict against slurm-llnl ( 14.03.8-1) would be right, as according to the slurm-llnl changelog that's the version where the packages were renamed. And wouldn't it be better to also add a conflict on the slurm-client side? This would at least prevent a similar bug if the package get's renamed again. But I would still like to hear from the slurm maintainers and from Jürgen Rinas (sinfo upstream and Debian co-maintainer) about the possibility of renaming one of the commands. I would still very much prefer that solution. What is the meaning of sinfo in the context of tool for monitoring computer clusters using broadcasts? I don't know the reasons why this package was named sinfo. Maybe Jürgen can answer this question. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759559: RFH : Advice on bug/patch
Hi Martijn Martijn van Brummelen mart...@brumit.nl writes: Im not sure if the suggested patch is ok or not, or provide a better patch? I asked on debian devel mailinglist[0]]/irc but did not get much response. It would be a pitty if Jessie would be released without it. Can someone advice me on this? Surely not having the package in testing and thus jessie is the worst option. So there needs to be a fix for this bug very soon. Here are my thoughts about it: 1. IMO the severity and tags of this bug are overrated. One possible solution is to just downgrade this to wishlist and remove the security tag. I'm not at all convinced that this is a security problem in your package. One thing you have to make sure in this case is that you don't overwrite any configuration already in place. So if it's set to optional in the authentication phase before the upgrade it should stay at this setting. Everything else is a Debian Policy violation. Not overwriting the existing configuration solves the security problem. There is no security problem on new installs IMO. If someone installs a script that allows unconditional authentication and does not check the pam-script configuration, then this is a configuration error outside of your package. 2. Basically this is an issue about the right default policy for the authentication phase of libpam-scripts. This is IMO something you as the maintainer can decide. Every value is right in some cases and wrong in others. There is no single value that will suit everyone. I proposed sufficient as the default value, but I can live with every setting and agree that there are good reasons to change the setting. Probably optional is indeed the most conservative setting. But also the one that means that the setting must be changed for many use cases. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Hi Mehdi Dogguy me...@dogguy.org writes: Le 2014-10-09 22:55, Gaudenz Steinlin a écrit : I will certainly update the Conflict if we can't agree on a better solution in the next few days. But as the Conflict was a workaround from the begining I'd prefer a solution where we agree on different names for the commands instead. I very much agree with what you say, but I think it is rather late to find a stable name (where also upstream is confortable with) in time for Jessie. There are only a few days left before the freeze. For that reason, I prefer to keep the old (and not so nice) workaround and work on a better solution to implement in Jessie+1. I've now uploaded a package with the conflict updated to slurm-client. But I would still like to hear from the slurm maintainers and from Jürgen Rinas (sinfo upstream and Debian co-maintainer) about the possibility of renameing one of the commands. I would still very much prefer that solution. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Mehdi Dogguy me...@dogguy.org writes: Hi Gaudenz, On Wed, Oct 08, 2014 at 10:34:45AM +0200, Gaudenz Steinlin gaud...@debian.org wrote: Ralf Treinen trei...@free.fr writes: Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/sinfo /usr/share/man/man1/sinfo.1.gz This happends because the sinfo binary in slurm moved from slurm-llnl to slurm-client and now the conflict specified in sinfo is wrong. To restore the previous state, sinfo should update it's conflict to slurm-client with appropriate versioning. Since your package had a Conflicts, can you please update it? If you agree on that, can you also reassign this bug to src:sinfo so that it is tracked properly? I will certainly update the Conflict if we can't agree on a better solution in the next few days. But as the Conflict was a workaround from the begining I'd prefer a solution where we agree on different names for the commands instead. The conflict is especially bad as the packages are not just two completely unrelated pieces of software but a cluster monitoring software and a cluster resource manager and job scheduler. I can very well imagine that people want to install both on the same system. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764441: sinfo and slurm-client: error when trying to install together
Ralf Treinen trei...@free.fr writes: Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/sinfo /usr/share/man/man1/sinfo.1.gz This happends because the sinfo binary in slurm moved from slurm-llnl to slurm-client and now the conflict specified in sinfo is wrong. To restore the previous state, sinfo should update it's conflict to slurm-client with appropriate versioning. A better solution would be if one of the binaries would be renamed. I don't know what the sinfo command in slurm does, so I can't judge if it's easy to rename or not. Renameing the sinfo command in the sinfo package would be suboptimal at best because it's the main command of this package. Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759559: libpam-script: suggested patch
Hi Andreas B. Mundt a...@debian.org writes: Control: tags -1 + patch Hi, I think the patch below should address the issue. I am not completely sure about the *-Type: Additional, but from [1] and [2] and the links there I think it should be as below. This modification follows the principle of 'least surprise': Neither you are loged in without password as before with 'sufficient' and an arbitrary script exiting 0, nor you are unable to log in which might happen with 'required' and a script exiting non-zero. So I guess this is a good default. CC Gaudenz to allow for his input/comments too. Thanks for CCing me. I was not aware of your bug report before. IMO the proposed patch is wrong. If your pam script is not intended to authenticate users, then don't use it in the authentication phase. If the script is used to mount network shares or similar things, put it into the session phase. Having auth scripts be optional by default, just leads to a situation were everyone that want's to use a script for authentication has to modify the pam configuration as this default most certainly won't be right for his case. If you want to change the default, then better change it to required, but this has the disatvantage you discribed of fatal failures. Regards, Gaudenz -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725594: python-werkzeug: diff for NMU version 0.9.4+dfsg-1.1
tags 725594 + pending thanks Dear maintainer, I've prepared an NMU for python-werkzeug (versioned as 0.9.4+dfsg-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. I used the patch from the bug report by Sebastian Ramacher to fix the problem. The package is uploaded to DELAYED to give you a chance to fix it by completely disabling the failing tests if you prefer that. I mostly did this upload because this RC bug caused OpenStack ceilometer to be dropped from testing by an auto-removal. Regards. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ diff -Nru python-werkzeug-0.9.4+dfsg/debian/changelog python-werkzeug-0.9.4+dfsg/debian/changelog --- python-werkzeug-0.9.4+dfsg/debian/changelog 2013-12-03 19:54:01.0 +0100 +++ python-werkzeug-0.9.4+dfsg/debian/changelog 2014-01-06 19:12:29.0 +0100 @@ -1,3 +1,11 @@ +python-werkzeug (0.9.4+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Start memcached for tests, thanks to Sebastian Ramacher for the patch +(Closes: #725594) + + -- Gaudenz Steinlin gaud...@debian.org Mon, 06 Jan 2014 19:01:32 +0100 + python-werkzeug (0.9.4+dfsg-1) unstable; urgency=low * New upstream release diff -Nru python-werkzeug-0.9.4+dfsg/debian/rules python-werkzeug-0.9.4+dfsg/debian/rules --- python-werkzeug-0.9.4+dfsg/debian/rules 2013-08-08 21:52:30.0 +0200 +++ python-werkzeug-0.9.4+dfsg/debian/rules 2014-01-06 18:56:42.0 +0100 @@ -19,7 +19,10 @@ dh_auto_clean override_dh_auto_test: - http_proxy='' dh_auto_test + set -ex; \ + memcached -p 11211 -l 127.0.0.1 \ + trap kill $$! || true EXIT; \ + http_proxy='' dh_auto_test; \ override_dh_auto_install: dh_auto_install signature.asc Description: Digital signature
Bug#730626: No patch for CVE-2013-6396 available yet
tags 730626 -patch forwarded 730626 https://bugs.launchpad.net/python-swiftclient/+bug/1199783 Thanks Hi Salvatore Where did you find a patch for this issue? As you can see in the launchpad bug report[1] and the upstream review system[2] no final patch is available yet. Upstream is still working on a proper fix. I suggest to wait for upstream to find a proper fix as this is not in any Debian stable release. Thanks Gaudenz [1] https://bugs.launchpad.net/python-swiftclient/+bug/1199783 [2] https://review.openstack.org/#/c/33473/ -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ pgpifA0TGWUbp.pgp Description: PGP signature
Bug#733729: [Openstack-devel] Bug#733729: python-bootstrapform and python-django-taggit: error when trying to install together
Hi Ralf Treinen trei...@free.fr writes: Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/lib/python2.7/dist-packages/tests/__init__.py /usr/share/pyshared/tests/__init__.py Probably none of the two packages should contain these files. I don't think it's a good idea for any package to ship a python module with the name test without any namespace qualification. If the test should really be shipped as part of the package, they should probably live in bootstrapform.tests and django-taggit.test or similar. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732547: [Openstack-devel] Bug#732547: Does not preserve modifications to /etc/default/cinder-common
Hi Thomas
Thomas Goirand z...@debian.org writes:
On 12/19/2013 03:43 AM, Gaudenz Steinlin wrote:
This is some remaining from before I restarted working on the packaging
of OpenStack, and a feature which I just didn't touch. Each time I see
it, I think I should kill this functionality. Would you agree (and the
rest of the packaging team) that it's useless, since Debian has all the
needed tools to do that?
If nobody complains about it, I'll kill this thing completely, and will
do the same for Nova.
I'm not exactly sure what you are refering here with this thing. If
you mean the part that you can enable service in /etc/default/* files,
then I completely agree. I just did not mention this because it's not
really part of the bug, but IMO this is a bad way to control if a
service is started or not, there are much better ways to not start a
service (ie runlevels) and at the same time keeping the possiblity of
starting it from the command line with the normal init script.
So I'm very much in favor of this. But this does only work around this
instance of the bug and not solve the deeper issue which is somewhere
inside the pile of shell code in openstack-pkg-tools.
The problem doesn't lie at all in openstack-pkg-tools, which in itself
is policy compliant. Read what it does if you aren't convinced.
Nowhere did I say that openstack-pkg-tools is not policy compliant. The
part that concerns openstack-pkg-tools is not about policy compliance,
but just a simple bug. As I already wrote in the first mail, I read the
code. The code currently in cinder-common.config.in (which will be
removed) tries to do the right thing by useing pkgos_read_config, but
inside this function (which uses pkgos_inifile for the low level work) it
files to correctly read the value from the file. That's the underlying
bug that should also be fixed. I just went back and made a small test
case. The script is attached to this mail:
gaudenz@meteor:~/tmp$ ./test.sh
Testing pkgos_inifile WITHOUT section
Return value: NOT_FOUND
Expected return value: false
Testing pkgos_inifile WITH section
Return value: false
Expected return value: false
I guess the bug is somewhere in the handling of the NO_SECTION parameter
to pkgos_inifile.
Gaudenz
#!/bin/sh
. /usr/share/openstack-pkg-tools/pkgos_func
TESTFILE_NO_SECTION=$(tempfile)
TESTFILE_WITH_SECTION=$(tempfile)
CINDER_ENABLE=false
echo # defaults file for cinder daemons
# start cinder daemons from init.d script?
# only allowed values are \true\ and \false\,
# any change to this file will be reset on upgrades.
CINDER_ENABLE=${CINDER_ENABLE} ${TESTFILE_NO_SECTION}
echo # defaults file for cinder daemons
[test-section]
# start cinder daemons from init.d script?
# only allowed values are \true\ and \false\,
# any change to this file will be reset on upgrades.
CINDER_ENABLE=${CINDER_ENABLE} ${TESTFILE_WITH_SECTION}
echo Testing pkgos_inifile WITHOUT section
pkgos_inifile get ${TESTFILE_NO_SECTION} NO_SECTION CINDER_ENABLE
echo Return value: ${RET}
echo Expected return value: ${CINDER_ENABLE}
echo
echo Testing pkgos_inifile WITH section
pkgos_inifile get ${TESTFILE_WITH_SECTION} test-section CINDER_ENABLE
echo Return value: ${RET}
echo Expected return value: ${CINDER_ENABLE}
rm ${TESTFILE_NO_SECTION}
rm ${TESTFILE_WITH_SECTION}
--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
Bug#732547: Does not preserve modifications to /etc/default/cinder-common
Package: cinder-common Version: 2013.2.1-1 Severity: serious cinder-common fails to preserve modifications to the file /etc/default/cinder-common. There seems to be some code in the config script function manage_cinder_enable which tries to read the value from the file and set the debconf value accordingly, but this does not work. The value of CINDER_ENABLE is always set back to what was stored in debconf before. If you have problems reproducing this I can help with more information. But after looking at the config script for more than 1 hour I gave up. I hope that those who have written this piece of code can better spot the bugs. ;-) The bug should be easy to reproduce, just install cinder-common and answer the debconf question cinder/start_services, change the value in /etc/default/cinder-common and then reinstall to package (to simulate an upgrade). The result is that the local modification is not preserved. Gaudenz -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732547: [Openstack-devel] Bug#732547: Does not preserve modifications to /etc/default/cinder-common
Hi Thomas Thomas Goirand z...@debian.org writes: On 12/18/2013 11:52 PM, Gaudenz Steinlin wrote: Package: cinder-common Version: 2013.2.1-1 Severity: serious cinder-common fails to preserve modifications to the file /etc/default/cinder-common. There seems to be some code in the config script function manage_cinder_enable which tries to read the value from the file and set the debconf value accordingly, but this does not work. The value of CINDER_ENABLE is always set back to what was stored in debconf before. If you have problems reproducing this I can help with more information. But after looking at the config script for more than 1 hour I gave up. I hope that those who have written this piece of code can better spot the bugs. ;-) The bug should be easy to reproduce, just install cinder-common and answer the debconf question cinder/start_services, change the value in /etc/default/cinder-common and then reinstall to package (to simulate an upgrade). The result is that the local modification is not preserved. Gaudenz Hi, This is some remaining from before I restarted working on the packaging of OpenStack, and a feature which I just didn't touch. Each time I see it, I think I should kill this functionality. Would you agree (and the rest of the packaging team) that it's useless, since Debian has all the needed tools to do that? If nobody complains about it, I'll kill this thing completely, and will do the same for Nova. I'm not exactly sure what you are refering here with this thing. If you mean the part that you can enable service in /etc/default/* files, then I completely agree. I just did not mention this because it's not really part of the bug, but IMO this is a bad way to control if a service is started or not, there are much better ways to not start a service (ie runlevels) and at the same time keeping the possiblity of starting it from the command line with the normal init script. So I'm very much in favor of this. But this does only work around this instance of the bug and not solve the deeper issue which is somewhere inside the pile of shell code in openstack-pkg-tools. And AFAIK this is code you wrote and not code that existed before you started working on the openstack packages. I think you should also fix this bug or it will probably reappear in some form. The bug is somewhere hidden in the parsing of the cinder-common default file. But I agree that this is then no longer a serious bug and can be downgraded. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732367: Ceilometer 2013.2.1 depends on WSME=0.5b5,0.5b6
Package: ceilometer
Version: 2013.2.1-1
Severity: grave
Starting ceilometer-collector, ceilometer-agent-central or
ceilometer-api leads to an error containing the following
stacktrace (not at the end but this is the point where it fails):
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension Traceback (most recent
call last):
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension File
/usr/lib/python2.7/dist-packages/stevedore/extension.py, line 89, in
_load_plugins
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension invoke_kwds,
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension File
/usr/lib/python2.7/dist-packages/stevedore/named.py, line 57, in
_load_one_plugin
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension ep, invoke_on_load,
invoke_args, invoke_kwds,
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension File
/usr/lib/python2.7/dist-packages/stevedore/extension.py, line 101, in
_load_one_plugin
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension plugin = ep.load()
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension File
/usr/lib/python2.7/dist-packages/pkg_resources.py, line 1988, in load
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension if require:
self.require(env, installer)
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension File
/usr/lib/python2.7/dist-packages/pkg_resources.py, line 2001, in require
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension
working_set.resolve(self.dist.requires(self.extras),env,installer))
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension File
/usr/lib/python2.7/dist-packages/pkg_resources.py, line 588, in resolve
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension raise
VersionConflict(dist,req) # XXX put more info here
2013-12-17 10:10:09.917 17447 TRACE stevedore.extension VersionConflict: (WSME
0.5b6 (/usr/lib/python2.7/dist-packages),
Requirement.parse('WSME=0.5b5,0.5b6'))
This is due to the fix for the following bug in ceilometer:
https://bugs.launchpad.net/wsme/+bug/1240741
The bug above was already present in earlier version of ceilometer. It's now
just more obvious as ceilometer refuses to run with an incompatible
version of WSME. Unfortunately the incompatible version of WSME is
already in Debian unstable and testing.
I see two options to resolve this bug:
1) Make ceilometer compatible with WSME=0.5b6 by cherry-picking commit
e4a1a4fcefd4718e057cf8128c9a6c6b7c98ef59 from upstream. I'm currently
building a test package to see if that works.
2) Downgrade python-wsme to 0.5b5 with an epoch.
The first option is a bit more forward looking by fixing the actual
problem, while the second option avoids a diff to the official havanna
release of OpenStack.
Gaudenz
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732367: Ceilometer 2013.2.1 depends on WSME=0.5b5,0.5b6
Package: ceilometer
Followup-For: Bug #732367
The attached patch fixes this bug by cherry-picking a fix from upstream.
This makes ceilometer work with the version of python-wsme which is
currently in unstable and testing. The same bug was fixed in upstream
havana by pining wsme to 0.5b5, but this version is not available in
Debian.
Gaudenz
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From 9e9ab905c55bcfa769144557f266c8c5f5101ccb Mon Sep 17 00:00:00 2001
From: Gaudenz Steinlin gaud...@debian.org
Date: Tue, 17 Dec 2013 10:03:03 +0100
Subject: [PATCH] Fix for compatibility with WSME=0.5b6
Add fix for compatibility with WSME=0.5b6 taken from upstream commit
e4a1a4fcefd4718e057cf8128c9a6c6b7c98ef59.
---
debian/changelog | 7 +
debian/patches/WSME-0.5b6-compatibility.patch | 317 ++
debian/patches/series | 1 +
3 files changed, 325 insertions(+)
create mode 100644 debian/patches/WSME-0.5b6-compatibility.patch
diff --git a/debian/changelog b/debian/changelog
index 4685714..32f7da9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ceilometer (2013.2.1-3) UNRELEASED; urgency=medium
+
+ * Add fix for compatibility with WSME=0.5b6 taken from upstream commit
+e4a1a4fcefd4718e057cf8128c9a6c6b7c98ef59.
+
+ -- Gaudenz Steinlin gaud...@debian.org Tue, 17 Dec 2013 09:59:52 +0100
+
ceilometer (2013.2.1-2) unstable; urgency=medium
* Added missing version depends for python-iso8601 (needs = 0.1.8).
diff --git a/debian/patches/WSME-0.5b6-compatibility.patch b/debian/patches/WSME-0.5b6-compatibility.patch
new file mode 100644
index 000..e34fcfe
--- /dev/null
+++ b/debian/patches/WSME-0.5b6-compatibility.patch
@@ -0,0 +1,317 @@
+commit e4a1a4fcefd4718e057cf8128c9a6c6b7c98ef59
+Author: Julien Danjou jul...@danjou.info
+Date: Mon Sep 30 16:43:59 2013 +0200
+
+api: update for WSME 0.5b6 compliance
+
+This makes use of the mandatory option of WSME, that now works, to
+remove some of our custom validation code. This is needed for new
+versions of WSME that do more validation on their own.
+
+Fixes-Bug: #1240741
+
+Change-Id: Icb66d17066b515bebf3f3a326d84e18cbfce01ef
+Signed-off-by: Julien Danjou jul...@danjou.info
+
+--- a/ceilometer/api/controllers/v2.py
b/ceilometer/api/controllers/v2.py
+@@ -516,19 +516,19 @@
+ source = wtypes.text
+ The ID of the source that identifies where the sample comes from
+
+-counter_name = wtypes.text
++counter_name = wsme.wsattr(wtypes.text, mandatory=True)
+ The name of the meter
+ # FIXME(dhellmann): Make this meter_name?
+
+-counter_type = wtypes.text
++counter_type = wsme.wsattr(wtypes.text, mandatory=True)
+ The type of the meter (see :ref:`measurements`)
+ # FIXME(dhellmann): Make this meter_type?
+
+-counter_unit = wtypes.text
++counter_unit = wsme.wsattr(wtypes.text, mandatory=True)
+ The unit of measure for the value in counter_volume
+ # FIXME(dhellmann): Make this meter_unit?
+
+-counter_volume = float
++counter_volume = wsme.wsattr(float, mandatory=True)
+ The actual measured value
+
+ user_id = wtypes.text
+@@ -537,7 +537,7 @@
+ project_id = wtypes.text
+ The ID of the project or tenant that owns the resource
+
+-resource_id = wtypes.text
++resource_id = wsme.wsattr(wtypes.text, mandatory=True)
+ The ID of the :class:`Resource` for which the measurements are taken
+
+ timestamp = datetime.datetime
+@@ -561,11 +561,6 @@
+ super(Sample, self).__init__(counter_volume=counter_volume,
+ resource_metadata=resource_metadata,
+ timestamp=timestamp, **kwds)
+-# Seems the mandatory option doesn't work so do it manually
+-for m in ('counter_volume', 'counter_unit',
+- 'counter_name', 'counter_type', 'resource_id'):
+-if getattr(self, m) in (wsme.Unset, None):
+-raise wsme.exc.MissingArgument(m)
+
+ if self.resource_metadata in (wtypes.Unset, None):
+ self.resource_metadata = {}
+@@ -709,20 +704,12 @@
+ for e in pecan.request.storage_conn.get_samples(f, limit=limit)
+ ]
+
+-@wsme.validate([Sample])
+ @wsme_pecan.wsexpose([Sample], body=[Sample])
+-def post(self, body):
++def post(self, samples):
+ Post a list of new Samples to Ceilometer.
+
+-:param body: a list of samples within the request body.
++:param samples: a list of samples within the request body.
+
+-# Note:
+-# 1
Bug#732387: Adds user ceilometer to group nova and libvirt on every upgrade
Package: ceilometer-common Version: 2013.2.1-1 Severity: serious The ceilometer postinst scripts runs the following commands unconditionally on configure and even reconfigure: adduser ceilometer nova || true adduser ceilometer libvirt || true In the common case this is just annoying as the postinst prints The user `ceilometer' is already a member of `nova'. The user `ceilometer' is already a member of `libvirt'. during upgrades. But this is actually not respecting local admin configurations. If an administrator decides (for whatever reason) that the ceilometer user should not be part of these groups, this decision is reverted on every package upgrade. This violates Debian Policy section 10.7.3 which states that local modifications must be preserved. The user should only be added to these groups on first install. On upgrades the group membership should not be changed. Gaudenz -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729787: Does not remove everything on purge
Package: dspam Version: 3.10.1+dfsg-11 Severity: serious According to the Debian Policy packages should remove everything on purge. The dspam package does not remove /var/spool/dspam and /var/log/dspam if there are files (created by dspam) in there. The package should remove these directories in a postrm script if the package is purged. Gaudenz -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729072: Leaves behing /var/spool/postfix/spamass after purge
Package: spamass-milter Version: 0.3.2-1 Severity: serious If spamass-milter is run together with postfix the init script creates /var/spool/postfix/spamass, but this directory is not removed on purge (or when the daemon is stopped). According to policy a package must clean up everything it created on purge. I agree that this is only a minor policy violation without much real world negative impact. Feel free to downgrade if you don't think this is release critical. Gaudenz -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages spamass-milter depends on: ii adduser 3.113+nmu3 ii libc6 2.17-93 ii libgcc1 1:4.8.2-1 ii libmilter1.0.1 8.14.4-4.1 ii libstdc++6 4.8.2-1 pn spamc none Versions of packages spamass-milter recommends: ii postfix 2.10.2-1 pn spamassassin none spamass-milter suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709603: recommends the non existing package nvidia-settings-legacy-96xx
Package: nvidia-glx-legacy-96xx Version: 96.43.23-4 Severity: serious The 96xx series of the nvidia driver do not have their own settings package. You should probably recommend nvidia-settings-legacy-173xx which works also with the 96xx series. Gaudenz -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (50, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda
Hi Vince Vincent McIntyre vincent.mcint...@csiro.au writes: Sadly, this issue will probably be in wheezy as nobody digged enough to tackle this down and we get rid of it before the last version of D-I is released. Please see my working (for me), tested, waiting-for-review patch [1] sent to the -boot list yesterday. Do you know how the problem can be triggerd. As far as I remember only some installation from USB are affected and I don't know if the difference between those affected and those unaffected has ever been identified. If I know that I'm testing the right test case, I'm willing to try your patch. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706012: terminal activity does not start
Package: sugar-terminal-activity Version: 28-1 Severity: grave Tags: patch After starting (clicking) the terminal activity a message Terminal failed to start appears instead of the terminal activity. This is becuase this outdated version of the terminal activity has a wrong activity.info file. The attached patch fixes the problem for the terminal activity. Gaudenz -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sugar-terminal-activity depends on: ii python2.7.3-4 ii python-central0.6.17 ii python-cjson 1.0.5-4+b1 ii python-gtk2 2.24.0-3+b1 ii python-hippocanvas0.3.1-1.1 ii python-sugar-0.96 [python-sugar] 0.96.0-1 ii python-sugar-toolkit-0.96 [python-sugar-toolkit] 0.96.1-1 ii python-telepathy 0.15.19-2.1 ii python-vte1:0.28.2-5 sugar-terminal-activity recommends no packages. sugar-terminal-activity suggests no packages. -- no debconf information --- /usr/share/sugar/activities/Terminal.activity/activity/activity.info.orig 2013-04-23 16:21:22.88172 +0200 +++ /usr/share/sugar/activities/Terminal.activity/activity/activity.info 2013-04-23 16:21:44.23623 +0200 @@ -1,7 +1,7 @@ [Activity] name = Terminal activity_version = 28 -service_name = org.laptop.Terminal +bundle_id = org.laptop.Terminal exec = sugar-activity terminal.TerminalActivity icon = activity-terminal mime_types =
Bug#706017: jigsawpuzzle activity does not start
Package: sugar-jigsawpuzzle-activity Version: 8-1 Severity: grave The jigsaw puzzle activity does not start. It shows a message with Jigsaw Puzzle failed to start. See the attached log for a bit more details. Gaudenz -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sugar-jigsawpuzzle-activity depends on: ii python2.7.3-4 ii python-abiword0.8.0-11 ii python-central0.6.17 ii python-cjson 1.0.5-4+b1 ii python-gtk2 2.24.0-3+b1 ii python-hippocanvas0.3.1-1.1 ii python-sugar-0.96 [python-sugar] 0.96.0-1 ii python-sugar-toolkit-0.96 [python-sugar-toolkit] 0.96.1-1 ii python-telepathy 0.15.19-2.1 Versions of packages sugar-jigsawpuzzle-activity recommends: ii sugar-session-0.96 [sugar] 0.96.1-2.1 sugar-jigsawpuzzle-activity suggests no packages. -- no debconf information WARNING: gnome-keyring:: couldn't connect to: /run/user/gaudenz/keyring-ksGZBG/pkcs11: No such file or directory /usr/lib/python2.7/dist-packages/abiword/__init__.py:1: Warning: specified instance size for type `AbiWidget' is smaller than the parent type's `GtkBin' instance size from abiword import * /usr/lib/python2.7/dist-packages/abiword/__init__.py:1: Warning: g_type_get_qdata: assertion `node != NULL' failed from abiword import * Terminated by signal 11, pid 3687 data (None, open file 'fdopen', mode 'w' at 0x1bbc930, '7a51a54edc0c3581a10b7ec7ca29ab2c04cb7c41')
Bug#706018: record activity does not start
Package: sugar-record-activity Version: 82-1 Severity: grave Tags: patch The record activity does not start when clicked. Just the message Record failed to start appears. The attached patch fixes this. The record activity uses an outdated format for the activity.info file. Gaudenz -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sugar-record-activity depends on: ii python2.7.3-4 ii python-central0.6.17 ii python-cjson 1.0.5-4+b1 ii python-gtk2 2.24.0-3+b1 ii python-hippocanvas0.3.1-1.1 ii python-sugar-0.96 [python-sugar] 0.96.0-1 ii python-sugar-toolkit-0.96 [python-sugar-toolkit] 0.96.1-1 ii python-telepathy 0.15.19-2.1 Versions of packages sugar-record-activity recommends: ii sugar-session-0.96 [sugar] 0.96.1-2.1 sugar-record-activity suggests no packages. -- no debconf information --- /usr/share/sugar/activities/Record.activity/activity/activity.info.orig 2013-04-23 16:42:38.12806 +0200 +++ /usr/share/sugar/activities/Record.activity/activity/activity.info 2013-04-23 16:42:56.376000249 +0200 @@ -1,7 +1,7 @@ [Activity] name = Record bundle_id = org.laptop.RecordActivity -class = record.Record +exec = sugar-activity record.Record icon = activity-record activity_version = 82 show_launcher = yes
Bug#706019: physics activity does not start
Package: sugar-physics-activity Version: 7+dfsg-1 Severity: grave Tags: patch The physics activity does not start because of an outdated activity.info file. The attached patch fixes this. Gaudenz -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sugar-physics-activity depends on: ii python 2.7.3-4 ii python-box2d2.0.2+svn20100109.244-1+b1 ii python-central 0.6.17 ii python-cjson1.0.5-4+b1 ii python-elements 0.13+svn20090823.230+dfsg-2 ii python-gtk2 2.24.0-3+b1 ii python-hippocanvas 0.3.1-1.1 ii python-pkg-resources0.6.36-1 ii python-pygame 1.9.1release+dfsg-8 ii python-sugar-0.96 [python-sugar]0.96.0-1 ii python-sugar-toolkit-0.96 [python-sugar-toolki 0.96.1-1 ii python-telepathy0.15.19-2.1 sugar-physics-activity recommends no packages. sugar-physics-activity suggests no packages. -- no debconf information --- /usr/share/sugar/activities/Physics.activity/activity/activity.info.orig 2013-04-23 16:54:44.48808 +0200 +++ /usr/share/sugar/activities/Physics.activity/activity/activity.info 2013-04-23 16:54:58.02336 +0200 @@ -1,6 +1,6 @@ [Activity] name = Physics -service_name = org.laptop.physics +bundle_id = org.laptop.physics exec = sugar-activity activity.PhysicsActivity icon = activity-physics activity_version = 7
Bug#706020: connect activity does not start
Package: sugar-connect-activity Version: 22-1 Severity: grave The connect activity does not start because of an incompatible activity.info file. The attached patch fixes this. Gaudenz -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sugar-connect-activity depends on: ii python2.7.3-4 ii python-central0.6.17 ii python-cjson 1.0.5-4+b1 ii python-gtk2 2.24.0-3+b1 ii python-hippocanvas0.3.1-1.1 ii python-sugar-0.96 [python-sugar] 0.96.0-1 ii python-sugar-toolkit-0.96 [python-sugar-toolkit] 0.96.1-1 ii python-telepathy 0.15.19-2.1 Versions of packages sugar-connect-activity recommends: ii sugar-session-0.96 [sugar] 0.96.1-2.1 sugar-connect-activity suggests no packages. -- no debconf information --- /usr/share/sugar/activities/Connect.activity/activity/activity.info 2013-04-23 16:59:51.62120 +0200 +++ /usr/share/sugar/activities/Connect.activity/activity/activity.info.orig 2013-04-23 16:59:32.23995 +0200 @@ -1,7 +1,7 @@ [Activity] name = Connect bundle_id = org.laptop.Connect -exec = sugar-activity activity.ConnectActivity +class = activity.ConnectActivity icon = activity-connect activity_version = 22 show_launcher = yes
Bug#706021: irc activity does not start
Package: sugar-irc-activity Version: 8-1 Severity: grave The IRC activity does not start because of an incompatible activity.info file. The attached patch fixes this. Gaudenz -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sugar-irc-activity depends on: ii python2.7.3-4 ii python-central0.6.17 ii python-cjson 1.0.5-4+b1 ii python-gtk2 2.24.0-3+b1 ii python-hippocanvas0.3.1-1.1 ii python-sugar-0.96 [python-sugar] 0.96.0-1 ii python-sugar-toolkit-0.96 [python-sugar-toolkit] 0.96.1-1 ii python-telepathy 0.15.19-2.1 Versions of packages sugar-irc-activity recommends: ii sugar-session-0.96 [sugar] 0.96.1-2.1 sugar-irc-activity suggests no packages. -- no debconf information --- /usr/share/sugar/activities/IRC.activity/activity/activity.info.orig 2013-04-23 17:04:09.92343 +0200 +++ /usr/share/sugar/activities/IRC.activity/activity/activity.info 2013-04-23 17:04:26.688001317 +0200 @@ -1,6 +1,6 @@ [Activity] name = IRC activity_version = 8 -service_name = org.sugarlabs.IRC +bundle_id = org.sugarlabs.IRC icon = activity-ircchat exec = sugar-activity ircactivity.IRCActivity
