Bug#1077489: Systemd user service file missing

[Gaudenz Steinlin]

Package: waybar
Version: 0.10.4-1
Severity: normal

The systemd user service file which was previously placed in
/usr/lib/systemd/user/waybar.service is missing from the package in
version 0.10.4-1. This causes waybar not to start anymore if using a
systemd user session to start it.

The service file template is still present in the upstream sources. So
this is likely a packaging bug somewhere.

Thanks,
Gaudenz


-- 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.9.10-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 waybar depends on:
ii  init-system-helpers 1.66
ii  libatkmm-1.6-1v52.28.4-1+b1
ii  libc6   2.39-6
ii  libcairomm-1.0-1v5  1.14.5-2
ii  libdbusmenu-gtk3-4  18.10.20180917~bzr492+repack1-3.1+b1
ii  libevdev2   1.13.2+dfsg-1
ii  libfmt9 9.1.0+ds1-2
ii  libgcc-s1   14-20240330-1
ii  libglib2.0-0t64 2.80.4-1
ii  libglibmm-2.4-1t64  2.66.7-1
ii  libgtk-3-0t64   3.24.43-1
ii  libgtk-layer-shell0 0.8.2-1+b1
ii  libgtkmm-3.0-1t64   3.24.9-1
ii  libinput10  1.26.0-1
ii  libjack-jackd2-0 [libjack-0.125]1.9.22~dfsg-2
ii  libjsoncpp251.9.5-6+b2
ii  libmpdclient2t642.22-1.1
ii  libnl-3-200 3.7.0-0.3
ii  libnl-genl-3-2003.7.0-0.3
ii  libpipewire-0.3-0t641.2.1-1
ii  libplayerctl2   2.4.1-2+b2
ii  libpulse0   16.1+dfsg1-5.1
ii  libsigc++-2.0-0v5   2.12.1-2
ii  libsndio7.0 1.9.0-0.3+b4
ii  libspdlog1.12 [libspdlog1.12-fmt9]  1:1.12.0+ds-2+b1
ii  libstdc++6  14-20240330-1
ii  libudev1256.4-2
ii  libupower-glib3 1.90.3-1+b1
ii  libwayland-client0  1.22.0-2.1+b1
ii  libwireplumber-0.5-00.5.5-1
ii  libxkbregistry0 1.6.0-1+b1

waybar recommends no packages.

Versions of packages waybar suggests:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  libayatana-appindicator3-1 [libappindicator3-1  0.5.93+really-1
]
ii  sway1.9-1+b1

-- no debconf information

Bug#1072244: Segmentation fault on startup

[Gaudenz Steinlin]

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_size(self, event):
 # when th

Bug#937184: Python 3 port of offlineimap underway

[Gaudenz Steinlin]

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#846950: Please explain what broke nfs-utils for you (Debian Bug #846950)

[Gaudenz Steinlin]

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

[Gaudenz Steinlin]

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

[Gaudenz Steinlin]

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#897338: Downgrading severity of 897338

[Gaudenz Steinlin]

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

[Gaudenz Steinlin]

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?

[Gaudenz Steinlin]

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#915160: nmu: nfs-ganesha_2.7.1-1

[Gaudenz Steinlin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu nfs-ganesha_2.7.1-1 . ANY . unstable . -m "Rebuild for libcephfs soname 
change"

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#913909: [Ceph-maintainers] Bug#913909: Bug#913909: ceph: FTBFS on i386 and mipsel (regression)

[Gaudenz Steinlin]

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#913909: [Ceph-maintainers] Bug#913909: Bug#913909: ceph: FTBFS on i386 and mipsel (regression)

[Gaudenz Steinlin]

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)

[Gaudenz Steinlin]

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#913909: [Ceph-maintainers] Bug#913909: ceph: FTBFS on i386 and mipsel (regression)

[Gaudenz Steinlin]

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'

[Gaudenz Steinlin]

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

[Gaudenz Steinlin]

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#907123: [Ceph-maintainers] Bug#907123: Ceph Mimic v13.2.x long term stable release series

[Gaudenz Steinlin]

Hi Milan

Milan Kupcevic  writes:

> Package: ceph
> Version: 10.2.5-7.2
> Severity: normal
>
>
> Please update ceph package to Mimic v13.2.x long term stable release
> series.[0]

Thanks for your report. I'm aware of the new release. As an upgrade from
Jewel to Mimic directly is not supported I would like to first get at
least one usable version of Luminous into the Debian archive. This way
we can point users at least to packages on snapshots.debian.org for the
Upgrade from Stretch to Buster.

I'm currently working on this. The progress can be seen in the
luminous/wip-gaudenz branch on salsa.debian.org.

The ceph maintainers team currently only consists of myself. I would be
happy to have more people on the team. Are you interested?

Gaudenz
-- 
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5

Bug#727604: zabbix-agent: Bad default hostname

[Gaudenz Steinlin]

Package: zabbix-agent
Version: 1:3.0.17+dfsg-1
Followup-For: Bug #727604

I just got bitten by this bug. It's still present in the
latest version in the Archive. And it breaks all active checks
by default. While this weird configuration is also present in the
upstream default configuration file for the agent, it would be nice to
at least fix it in Debian or to provide a patch for upstream to fix it
for everyone.

Gaudenz

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages zabbix-agent depends on:
ii  adduser  3.115
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libcurl3-gnutls  7.52.1-5+deb9u6
ii  libgnutls30  3.5.8-5+deb9u3
ii  libldap-2.4-22.4.44+dfsg-5+deb9u2
ii  lsb-base 9.20161125
ii  pciutils 1:3.5.2-1
ii  ucf  3.0036

Versions of packages zabbix-agent recommends:
ii  usbutils  1:007-4+b1

Versions of packages zabbix-agent suggests:
ii  logrotate  3.11.0-0.1

-- no debconf information

Bug#901280: Hangs when creating a new files or opening an existing file

[Gaudenz Steinlin]

Package: quickroute-gps
Version: 2.4-15
Severity: important

Hi

If I create a new file, select a map image and GPX route and then click
on OK, quickroute just hangs indefinitely without using much CPU. The
same happens when I open a QRT file created on Windows. The same map
image and GPX track work just fine in the Windows version of Quickroute.

There is an exception stacktrace in .config/QuickRoute/QuickRoute.log
(attached).

If you need the map image and GPX track to reproduce the bug I can send
them to you by private mail or upload them somewhere. 

Opening the JPG exported from Quickroute on Windows to our DOMA
archive [1] works also on Debian.

Gaudenz

[1] https://www.ubol.ch/DOMA/show_map.php?user=gaudenz&map=42

P.S.: Thanks for packageing Quickroute. I was very pleasantly surprised
when I discovered that it's now available in Debian. I hope this issue
can be resolved. And as you seem to know .Net and Mono I would also be
very pleased if you would package PurplePen. If you need help with
packageing or a sponsor for an upload I would be glad to assist.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages quickroute-gps depends on:
ii  libc62.27-3
ii  liblog4net1.2-cil1.2.10+dfsg-7
ii  libmono-corlib4.5-cil4.6.2.7+dfsg-1
ii  libmono-system-configuration4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-drawing4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-web-services4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-web4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-windows-forms4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil4.6.2.7+dfsg-1
ii  libmono-system4.0-cil4.6.2.7+dfsg-1
ii  mono-mcs 4.6.2.7+dfsg-1
ii  mono-runtime 4.6.2.7+dfsg-1

quickroute-gps recommends no packages.

quickroute-gps suggests no packages.

-- no debconf information
2018-06-10 22:06:25,463 INFO  
QuickRoute.BusinessEntities.Importers.Garmin.ANTAgent.AntpmImporter - 
1528661185.000 0.000 .ctor: AntpmImporter: /home/gaudenz/.config/antpm/
2018-06-10 22:06:41,300 ERROR QuickRoute.UI.Main - 1528661201.000 16.000 
Application_ThreadException: The type initializer for 'System.Console' threw an 
exception.   at (wrapper managed-to-native) 
System.Drawing.GDIPlus:GdipCreateFromXDrawable_linux (intptr,intptr,intptr&)
  at System.Drawing.Graphics.FromXDrawable (System.IntPtr drawable, 
System.IntPtr display) [0x0] in <1917aa1c39d94b1a91807b8cd9f03350>:0 
  at System.Drawing.Graphics.FromHwnd (System.IntPtr hwnd) [0x000fb] in 
<1917aa1c39d94b1a91807b8cd9f03350>:0 
  at System.Windows.Forms.Control.CreateGraphics () [0x0001c] in 
:0 
  at QuickRoute.Controls.ScrollableLabel.DrawText () [0x0] in 
<2cb7f5b7a9564c53bb101661c5f86a21>:0 
  at QuickRoute.Controls.ScrollableLabel.ScrollableLabel_LocationChanged 
(System.Object sender, System.EventArgs e) [0x0] in 
<2cb7f5b7a9564c53bb101661c5f86a21>:0 
  at (wrapper delegate-invoke) :invoke_void_object_EventArgs 
(object,System.EventArgs)
  at System.Windows.Forms.Control.OnLocationChanged (System.EventArgs e) 
[0x00023] in :0 
  at System.Windows.Forms.Control.UpdateBounds (System.Int32 x, System.Int32 y, 
System.Int32 width, System.Int32 height, System.Int32 clientWidth, System.Int32 
clientHeight) [0x000b0] in :0 
  at System.Windows.Forms.Control.UpdateBounds () [0x0002c] in 
:0 
  at System.Windows.Forms.Control.WmWindowPosChanged 
(System.Windows.Forms.Message& m) [0x00012] in 
:0 
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) 
[0x00157] in :0 
  at System.Windows.Forms.ScrollableControl.WndProc 
(System.Windows.Forms.Message& m) [0x0] in 
:0 
  at System.Windows.Forms.ContainerControl.WndProc 
(System.Windows.Forms.Message& m) [0x0003c] in 
:0 
  at System.Windows.Forms.UserControl.WndProc (System.Windows.Forms.Message& m) 
[0x00036] in :0 
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage 
(System.Windows.Forms.Message& m) [0x0] in 
:0 
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc 
(System.Windows.Forms.Message& m) [0xb] in 
:0 
  at System.Windows.Forms.NativeWindow.WndProc (System.IntPtr hWnd, 
System.Windows.Forms.Msg msg, System.IntPtr wParam, System.IntPtr lParam) 
[0x0008e] in :0 
2018-06-10 22:32:05,829 INFO  
QuickRoute.BusinessEntities.Importers.Garmin.ANTAgent.AntpmImporter - 
1528662725.000 0.000 .ctor: AntpmImporter: /home/gaudenz/.config/antpm/
2018-06-10 22:39:19,916 DEBUG QuickRoute.Common.LogUtil - 1528663159.000 
434.000 MonoFixMe:

Bug#893319: Crash when displaying Unicode 'ALARM CLOCK' (U+23F0) character

[Gaudenz Steinlin]

Package: emacs25
Version: 25.2+1-6+b1
Severity: normal
File: /usr/bin/emacs

When displaying a Unicode 'ALARM CLOCK' (U+23F0) character in a buffer
Emacs crashes.

To reproduce, just paste the character from
https://www.fileformat.info/info/unicode/char/23f0/index.htm into a
buffer.

I get the following output on the console:

emacs25:22934): Gtk-WARNING **: Allocating size to Emacs 0xdb2260 without 
calling gtk_widget_get_preferred_width/height(). How does the code know the 
size to allocate?
X protocol error: BadLength (poly request too large or internal Xlib length 
error) on protocol request 139
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
Fatal error 6: Aborted
(emacs25:22934): GLib-WARNING **: g_main_context_prepare() called recursively 
from within a source's check() or prepare() member.

(emacs25:22934): GLib-WARNING **: g_main_context_check() called recursively 
from within a source's check() or prepare() member.

Backtrace:
emacs25[0x50a53e]
emacs25[0x4f0b49]
emacs25[0x50a5e3]
emacs25[0x4c0990]
emacs25[0x4c4cd9]
emacs25[0x4c4d5b]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XError+0x11d)[0x7fbbb309122d]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x42157)[0x7fbbb308e157]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x42215)[0x7fbbb308e215]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XEventsQueued+0x55)[0x7fbbb308eb15]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XPending+0x57)[0x7fbbb30807e7]
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6840e)[0x7fbbb4ee540e]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_prepare+0x1c8)[0x7fbbb37fb678]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4b04b)[0x7fbbb37fc04b]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_pending+0x27)[0x7fbbb37fc1d7]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_events_pending+0xd)[0x7fbbb53a806d]
emacs25[0x4c1397]
emacs25[0x4f7a71]
emacs25[0x4f8105]
emacs25[0x5c689a]
emacs25[0x57b734]
emacs25[0x5c946c]
emacs25[0x5c9741]
emacs25[0x5c9a5c]
emacs25[0x443941]
emacs25[0x44b9a0]
emacs25[0x4663ff]
emacs25[0x46789e]
emacs25[0x5630de]
emacs25[0x4553ec]
emacs25[0x4fabab]
emacs25[0x4fd960]
emacs25[0x4ff3e4]
emacs25[0x563052]
emacs25[0x4f0f64]
emacs25[0x562fd1]
emacs25[0x4f0efb]
emacs25[0x4f57e7]
emacs25[0x4f5b0a]
emacs25[0x418e50]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7fbbae7f9a87]
...
Aborted

Gaudenz

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs25 depends on:
ii  emacs25-bin-common 25.2+1-6+b1
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.3-5
ii  libatk1.0-02.26.1-3
ii  libc6  2.27-2
ii  libcairo-gobject2  1.15.10-1
ii  libcairo2  1.15.10-1
ii  libdbus-1-31.12.6-2
ii  libfontconfig1 2.12.6-0.1
ii  libfreetype6   2.8.1-2
ii  libgdk-pixbuf2.0-0 2.36.11-1
ii  libgif75.1.4-2
ii  libglib2.0-0   2.54.3-2
ii  libgnutls303.5.18-1
ii  libgomp1   8-20180312-2
ii  libgpm21.20.7-5
ii  libgtk-3-0 3.22.28-1
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libm17n-0  1.7.0-3+b2
ii  libmagickcore-6.q16-5  8:6.9.9.34+dfsg-3+b1
ii  libmagickwand-6.q16-5  8:6.9.9.34+dfsg-3+b1
ii  libotf00.9.13-3+b1
ii  libpango-1.0-0 1.40.14-1
ii  libpangocairo-1.0-01.40.14-1
ii  libpng16-161.6.34-1
ii  librsvg2-2 2.40.20-2
ii  libselinux12.7-2+b1
ii  libsm6 2:1.2.2-1+b3
ii  libtiff5   4.0.9-4
ii  libtinfo5  6.1-1
ii  libx11-6   2:1.6.4-3
ii  libx11-xcb12:1.6.4-3
ii  libxcb11.13-1
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-1+b2
ii  libxinerama1   2:1.1.3-1+b3
ii  libxml22.9.4+dfsg1-6.1
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.8.dfsg-5

emacs25 recommends no packages.

Versions of packages emacs25 suggests:
pn  emacs25-common-non-dfsg  

-- no debconf information

Bug#891963: [Ceph-maintainers] Bug#891963: ceph: CVE-2018-7262

[Gaudenz Steinlin]

Hi 

Salvatore Bonaccorso  writes:
> Hi,
>
> the following vulnerability was published for ceph.
>
> CVE-2018-7262[0]:
> |Malformed HTTP requests handled in rgw_civetweb.cc:RGW::init_env() can
> |lead to NULL pointer dereference

Thanks for the information. I backported the upstream fix to the version
in stretch and I'm currently in the process of building the package
(takes several hours). How do you want me to proceed if the package
builds fine and testing does not result in any errors?

This may lead to a crash of the RGW process if sent a malformed HTTP
header which could result in a denial of service. Does this warrant an
upload to security or should this only be fixed via a stable point
release? Do you want to review the debdiff before the upload? The
debdiff of the test package I'm currently building is attached to this
mail.

FYI RGW is the part of Ceph which implements the Amazon S3 API on top of
the Ceph distributed storage.

Gaudenz



ceph_10.2.5-7.2+deb9u1.debdiff
Description: Binary data

-- 
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5


signature.asc
Description: PGP signature

Bug#890720: Request for new debian-switzerland list

[Gaudenz Steinlin]

Hi

Didier 'OdyX' Raboud  writes:

> Package: lists.debian.org
> Severity: wishlist
>
> The debian.ch association (recognized TO) uses the 'commun...@lists.debian.ch'
> list since, on privately-owned infrastructure. It's General Assembly has
> concluded that a hosting of this low-traffic list would be much better on
> Debian.org infrastructure, hence this request
>
> Name: debian-switzerl...@lists.debian.org
> Rationale: debian.ch association & Swiss events' coordination traffic; should
>  really be on Debian infrastructure if possible
> Short Description: Discussion list for Debian community in Switzerland
> Long Description: Discussion list for the Debian community - debian.ch
> Category: Other
> Subscription Policy: open
> Post Policy: open
> Web Archive: yes; please import the current commun...@lists.debian.ch list 
> archive
>
> I hereby invite commun...@lists.debian.ch subscribers to voice their
> interest/support on the Debian bug for the creation of that list.

Thanks to Didier for finally tackling this issue. I'm all in favor of
creating the new list.

Gaudenz, with his debian.ch Secretary hat

>
> OdyX, with hir debian.ch President hat
> ___
> community mailing list
> commun...@lists.debian.ch
> https://lists.debian.ch/mailman/listinfo/community
-- 
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5


signature.asc
Description: PGP signature

Bug#888920: RM: passepartout -- ROM; Unmaintained upstream and very low popcon

[Gaudenz Steinlin]

Package: ftp.debian.org
Severity: normal

Please remove passepartout from unstable. It's no longer maintained
upstream since some years and has practically zero users left.

Gaudenz

Bug#883596: Wron exit code of dhcp_release6

[Gaudenz Steinlin]

Hi Simon

Simon Kelley  writes:

> On 05/12/17 15:00, Gaudenz Steinlin wrote:
>> 
>> Hi
>> 
>> Sorry for the incomplete bug report. I wanted to resume a reported I did
>> not finish with reportbug, but it decided to send the backup copy as is
>> instead of letting me edit it before sending.
>> 
>> Looking at the code the wrong error code results from the return code of
>> the parse_packet function which is passed through via
>> send_release_packet to main and used as exit code there. Returning -1
>> from main results in an exit code of 255 in the shell.
>> 
>> Gaudenz
>> 
>
>
> Are  sure that this isn't a real error? From a quick look, successfully
> doing the release results in a reply with a STATUS_CODE structure
> containing a SUCCESS status value, which is zero. This is returned via
> parse_packet and send_release_packet to main, and results in a zero
> return code. A -1 return from parse_packet implies no STATUS_CODE or
> IA_NA in the reply, which is an error.

I had another look now and took a tcpdump capture. The successfull reply
does not has STATUS_CODE SUCCES, but no IA_NA option set. Which in turn
gives a return -1. But looking at RFC3315 18.2.6 this is the correct
behaviour. If the release is successful, no IA_NA option should be sent.
IA_NA options should only be sent for those addresses where no binding
was found on the server.

Looking at the packet capture I also saw that always two release
requests are sent. This is because the code does not wait at all after
sending the packet and immediately calls recvfrom. In the next iteration
it then first sends the release packet again before processing the
answer of the previous releas packet. This is not really a problem, but
it looked a bit odd in the capture.

See below for the full content of the 4 packets in question. You can
also see that the reply to the second release packet contains an IA_NA
option with NoBinding. This is correct as the binding is already
released by the first packet. But this packet is no longer processed by
dhcp_release6 as it already exited after the first reply.

BTW the DHCP server used is dnsmasq 2.68.

Gaudenz

Frame 263: 146 bytes on wire (1168 bits), 146 bytes captured (1168 bits)
Ethernet II, Src: fa:16:3e:15:e3:67 (fa:16:3e:15:e3:67), Dst: 
IPv6mcast_01:00:02 (33:33:00:01:00:02)
Internet Protocol Version 6, Src: fe80::f816:3eff:fe15:e367, Dst: ff02::1:2
0110  = Version: 6
        = Traffic Class: 0x00 (DSCP: CS0, 
ECN: Not-ECT)
  00..      = Differentiated Services 
Codepoint: Default (0)
  ..00      = Explicit Congestion 
Notification: Not ECN-Capable Transport (0)
        = Flow Label: 0x0
Payload Length: 92
Next Header: UDP (17)
Hop Limit: 1
Source: fe80::f816:3eff:fe15:e367
Destination: ff02::1:2
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 546, Dst Port: 547
Source Port: 546
Destination Port: 547
Length: 92
Checksum: 0x578c [unverified]
[Checksum Status: Unverified]
[Stream index: 2]
DHCPv6
Message type: Release (8)
Transaction ID: 0x00
Client Identifier
Option: Client Identifier (1)
Length: 14
Value: 0001000121ba76befa163e9a7c26
DUID: 0001000121ba76befa163e9a7c26
DUID Type: link-layer address plus time (1)
Hardware type: Ethernet (1)
DUID Time: Dec  6, 2017 10:37:02.0 CET
Link-layer address: fa:16:3e:9a:7c:26
Server Identifier
Option: Server Identifier (2)
Length: 14
Value: 0001000121b965c5fa163e23f3e0
DUID: 0001000121b965c5fa163e23f3e0
DUID Type: link-layer address plus time (1)
Hardware type: Ethernet (1)
DUID Time: Dec  5, 2017 15:12:21.0 CET
Link-layer address: fa:16:3e:23:f3:e0
Identity Association for Non-temporary Address
Option: Identity Association for Non-temporary Address (3)
Length: 40
Value: 3e9a7c26000500182a060c0100011902...
IAID: 3e9a7c26
T1: 0
T2: 0
IA Address
Option: IA Address (5)
Length: 24
Value: 2a060c01000119027a120018
IPv6 address: 2a06:c01:1:1902::7a12:18
Preferred lifetime: 0
Valid lifetime: 0

Frame 264: 124 bytes on wire (992 bits), 124 bytes captured (992 bits)
Ethernet II, Src: fa:16:3e:23:f3:e0 (fa:16:3e:23:f3:e0), Dst: fa:16:3e:15:e3:67 
(fa:16:3e:15:e3:67)
Internet Protocol Version 6, Src: fe80::f816:3eff:fe23:f3e0, Dst: 
fe80::f816:3eff:fe15:e367
0110  = Version: 6
 1100       = Traffic Class: 0xc0 (DSCP: CS6, 
ECN: Not-ECT)
 1

Bug#883596: Wron exit code of dhcp_release6

[Gaudenz Steinlin]

Hi

Sorry for the incomplete bug report. I wanted to resume a reported I did
not finish with reportbug, but it decided to send the backup copy as is
instead of letting me edit it before sending.

Looking at the code the wrong error code results from the return code of
the parse_packet function which is passed through via
send_release_packet to main and used as exit code there. Returning -1
from main results in an exit code of 255 in the shell.

Gaudenz

-- 
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5


signature.asc
Description: PGP signature

Bug#883596: wrong exit code of dhcp_release6

[Gaudenz Steinlin]

Package: dnsmasq-utils
Version: 2.78-1
Severity: normal

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Gaudenz Steinlin 
To: Debian Bug Tracking System 
Subject: wrong exit code of dhcp_release6
Bcc: Gaudenz Steinlin 

Package: dnsmasq-utils
Version: 2.78-1
Severity: normal

The dhcp_release6 tool exits with code 255 if it successfully releases
the lease. It should exit with code 0 in this case.

Looking at the code this is because

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq-utils depends on:
ii  libc6  2.25-2

dnsmasq-utils recommends no packages.

dnsmasq-utils suggests no packages.

-- no debconf information

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq-utils depends on:
ii  libc6  2.25-2

dnsmasq-utils recommends no packages.

dnsmasq-utils suggests no packages.

-- no debconf information

Bug#869191: pristine-tar: pristine-xz failed to reproduce build of ../util-linux_2.30.1.orig.tar.xz

[Gaudenz Steinlin]

Package: pristine-tar
Version: 1.42
Followup-For: Bug #869191

I have the same problem with iproute2:

gaudenz@moebius:~/tmp$ debcheckout --git-track '*' iproute2
declared git repository at 
https://anonscm.debian.org/git/collab-maint/pkg-iproute.git
git clone https://anonscm.debian.org/git/collab-maint/pkg-iproute.git iproute2 
...
Cloning into 'iproute2'...
remote: Counting objects: 19205, done.
remote: Compressing objects: 100% (5946/5946), done.
remote: Total 19205 (delta 14280), reused 17772 (delta 12994)
Receiving objects: 100% (19205/19205), 4.20 MiB | 4.83 MiB/s, done.
Resolving deltas: 100% (14280/14280), done.
Branch pristine-tar set up to track remote branch pristine-tar from origin.
Branch upstream set up to track remote branch upstream from origin.
gaudenz@moebius:~/tmp$ cd iproute2/
gaudenz@moebius:~/tmp/iproute2$ git remote add upstream 
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
gaudenz@moebius:~/tmp/iproute2$ git fetch upstream
remote: Counting objects: 1505, done.
remote: Compressing objects: 100% (707/707), done.
remote: Total 1505 (delta 965), reused 1144 (delta 787)
Receiving objects: 100% (1505/1505), 924.28 KiB | 5.96 MiB/s, done.
Resolving deltas: 100% (965/965), done.
>From https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2
 * [new branch]flag-names -> upstream/flag-names
 * [new branch]iproute2-4.1.x -> upstream/iproute2-4.1.x
 * [new branch]master -> upstream/master
 * [new branch]net-next   -> upstream/net-next
 * [new tag]   v4.13.0-> v4.13.0
gaudenz@moebius:~/tmp/iproute2$ gbp import-orig --uscan
gbp:info: Launching uscan...
uscan: Newest version of iproute2 on remote site is 4.13.0, local version is 
4.9.0
uscan:=> Newer package available from
  http://kernel.org/pub/linux/utils/net/iproute2/iproute2-4.13.0.tar.xz
gpgv: Signature made Die 05 Sep 2017 18:39:32 CEST
gpgv:using RSA key 9F6FC345B05BE7E766B83C8F80A77F6095CDE47E
gpgv: Good signature from "Stephen Hemminger (Microsoft corporate) 
"
gpgv: aka "Stephen Hemminger "
gpgv: aka "Stephen Hemminger "
gpgv: aka "Stephen Hemminger "
gpgv: aka "Stephen Hemminger "
gpgv: aka "Stephen Hemminger (Microsoft open source server) 
"
gpgv: aka "[invalid image]"
gbp:info: Using uscan downloaded tarball ../iproute2_4.13.0.orig.tar.xz
What is the upstream version? [4.13.0] 
gbp:info: Importing '../iproute2_4.13.0.orig.tar.xz' to branch 'upstream'...
gbp:info: Source package is iproute2
gbp:info: Upstream version is 4.13.0
gbp:error: Import of ../iproute2_4.13.0.orig.tar.xz failed: Couldn't commit to 
'pristine-tar' with upstream '5ff19684ca409e7f15535de9f9e2688cf2c5d936': 
pristine-xz failed to reproduce build of ../iproute2_4.13.0.orig.tar.xz
(Please file a bug report.)
pristine-tar: failed to generate delta
gbp:error: Error detected, Will roll back changes.
gbp:info: Rolling back branch upstream by resetting it to 
22abf4c1e38534ec6ca01a866a9f24f8b13d0e5c
gbp:info: Rolling back branch pristine-tar by resetting it to 
1cfabbd88ca05224e084e384a48080556e1e871c
gbp:error: Rolled back changes after import error.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pristine-tar depends on:
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.24-17
ii  perl5.26.0-8
ii  tar 1.29b-2
ii  xdelta  1.1.3-9.1+b1
ii  xdelta3 3.0.11-dfsg-1+b1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages pristine-tar recommends:
ii  bzip2 1.0.6-8.1
ii  pbzip21.1.9-1+b1
ii  xz-utils  5.2.2-1.3

pristine-tar suggests no packages.

-- no debconf information

Bug#879854: Please package new upstream version 4.13.0

[Gaudenz Steinlin]

Package: iproute2
Version: 4.9.0-2
Severity: wishlist

Hi

The newer upstream version supports the vrf functionality included in
recent Linux kernels. I locally updated the repository from pkg-iproute
to the latest upstream release 4.13.0. The package built without any
further changes. I'm running this without any problems.

If you don't have the time to update the package yourself, just tell me
and I can do an upload. I can also just push my changes to the GIT
repository if you prefer to do the upload yourself.

There was one minor glitch while updateing the repository that
pristine-tar was unable to cope with the upstream tar.xz tarball. We
have to either not use pristine-tar for this release or use the .tar.gz
version. This is a bug in pristine-tar's handling of xz compression and
has nothing to do with iproute2. This is probably the same as 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869191

Gaudenz

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iproute2 depends on:
ii  libc62.24-17
ii  libdb5.3 5.3.28-13.1
ii  libelf1  0.170-0.1
ii  libmnl0  1.0.4-2
ii  libselinux1  2.7-2

Versions of packages iproute2 recommends:
pn  libatm1   
ii  libxtables12  1.6.1-2+b1

Versions of packages iproute2 suggests:
ii  iproute2-doc  4.9.0-2

-- no debconf information

Bug#868785: Excessive memory usage of isenkramd

[Gaudenz Steinlin]

Package: isenkram
Version: 0.33
Severity: important

Hi

isenkramd uses about 4GB of memory on my system:

UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
gaudenz  17872 1  0 1563539 3959688 2 Jul11 ?  00:03:08 /usr/bin/python 
/usr/bin/isenkramd

IMO this is way to much for this small daemon.

Don't know if this is related, but lsof shows that it opened
/usr/lib/os-release 301 times:

gaudenz@moebius:~$ lsof -p 17872 | grep os-release | wc -l
301

Gaudenz

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages isenkram depends on:
ii  gir1.2-gtk-3.0 3.22.16-1
ii  gir1.2-gudev-1.0   230-3
ii  gir1.2-notify-0.7  0.7.7-2
ii  gir1.2-packagekitglib-1.0  1.1.5-2
ii  isenkram-cli   0.33
ii  packagekit 1.1.5-2
ii  python 2.7.13-2
ii  python-gi  3.22.0-2+b1

isenkram recommends no packages.

isenkram suggests no packages.

-- no debconf information

Bug#864495: unblock: ceph/10.2.5-7.2

[Gaudenz Steinlin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package ceph

I know this is really late. The 10.2.5-7.1 upload which fixes an upgrade
issue (#864161). Did not build on all buildds due to reasons unrelated
to the upload. Adrian Bunk tried to fix this with a second NMU which
built on all arches but did not migrate today because the unblock hint
applied for -7.1 referenced the wrong version.  I was not aware
that the unblock hint needs to be updated so I expected the package to
migrate. Is there any chance this can still get into stretch before the
release?

The debdiff of the second NMU is attached. The only change is to include
less debugging information into the debug packages on 32bit arches to
reduce the space used by the build.

Regards
Gaudenz

unblock ceph/10.2.5-7.2

-- System Information:
Debian Release: 9.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 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru ceph-10.2.5/debian/changelog ceph-10.2.5/debian/changelog
--- ceph-10.2.5/debian/changelog2017-06-06 09:08:30.0 +0200
+++ ceph-10.2.5/debian/changelog2017-06-07 10:39:39.0 +0200
@@ -1,3 +1,11 @@
+ceph (10.2.5-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with -g1 instead of -g on 32bit architectures to fix
+FTBFS due to the 2GB/3GB address space limits.
+
+ -- Adrian Bunk   Wed, 07 Jun 2017 11:39:39 +0300
+
 ceph (10.2.5-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ceph-10.2.5/debian/rules ceph-10.2.5/debian/rules
--- ceph-10.2.5/debian/rules2017-05-11 23:00:46.0 +0200
+++ ceph-10.2.5/debian/rules2017-06-07 10:39:39.0 +0200
@@ -2,6 +2,14 @@
 # -*- makefile -*-
 #export DH_VERBOSE=1
 
+# Reduce size of debug symbols to fix FTBFS due to the
+# 2GB/3GB address space limits on 32bit
+DEB_HOST_ARCH_BITS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_BITS)
+ifeq (32,$(DEB_HOST_ARCH_BITS))
+   export DEB_CFLAGS_MAINT_APPEND = -g1
+   export DEB_CXXFLAGS_MAINT_APPEND = -g1
+endif
+
 # Limit parallel builds to 2 for now
 
 # minimise needless linking and link to libatomic

Bug#862075: [Ceph-maintainers] Bug#862075: ceph-detect-init: Platform is not supported.: debian 9.0

[Gaudenz Steinlin]

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  writes:

> Control: forwarded -1 http://tracker.ceph.com/issues/19884
> Control: tags -1 +patch
>
> Simon McVittie  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

[Gaudenz Steinlin]

Control: forwarded -1 http://tracker.ceph.com/issues/19884
Control: tags -1 +patch

Simon McVittie  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#861973: unblock: unattended-upgrades/0.93.1+nmu1

[Gaudenz Steinlin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package unattended-upgrades

The version 0.93.1+nmu1 fixes bug #809669. The debdiff is attached.

I used the fix proposed in the bug report in the NMU. It's based on the
work by Louis Bouchard plus actually includes the fix which was missing
in his debdiff. I also adjusted the version to be correct for an NMU.

I reproduced the bug and tested the fix using a VM with a separate /var. 
Every thing worked as expected.

Gaudenz

unblock unattended-upgrades/0.93.1+nmu1

-- System Information:
Debian Release: 9.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 4.9.0-2-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)
diff -Nru unattended-upgrades-0.93.1/debian/changelog 
unattended-upgrades-0.93.1+nmu1/debian/changelog
--- unattended-upgrades-0.93.1/debian/changelog 2016-12-11 11:31:26.0 
+0100
+++ unattended-upgrades-0.93.1+nmu1/debian/changelog2017-05-06 
19:42:14.0 +0200
@@ -1,3 +1,37 @@
+unattended-upgrades (0.93.1+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Louis Bouchard ]
+  * Fix the unattended-upgrades.service unit not correctly working:
+- d/rules : Remove the override_dh_installinit. The stop option is no 
longer
+  available so the command falls back to default. This is the normal
+  behavior so the override is not required
+- d/unattended-upgrades.init : Add Default-Start runlevels, otherwise the 
+  unattended-upgrades.service unit cannot be enabled on boot
+- d/postinst : Cleanup the stop symlinks created by the wrong
+  override_dh_installinit. Without that, the systemd unit cannot be
+  enabled correctly.
+  Force disable the service before deb-systemd-helper runs so the old 
+  symlink is not left dangling (workaround for Debian Bug #797108).
+  Force enable and start of the systemd unit to work around Debian Bug
+  #797108 which fails to enable systemd units correctly when WantedBy=
+  statement is changed which is the case here.
+- d/unattended-upgrades.service : Fix the service so it runs correctly on
+  shutdown :
+Remove DefaultDependencies=no : Breaks normal shutdown dependencies
+Set After= to network.target and local-fs.target. Since our service is
+now ExecStop, it will run before network and local-fs become
+unavailable. Add RequiresMountsFor=/var/log /var/run /var/lib /boot : 
+Necessary if /var is a separate file system. Set WantedBy= to
+multi-user.target
+- Add DEP8 tests to verify the following :
+  Verify that the unattended-upgrades.service unit is enabled and started.
+  Verify that InstallOnShutdown works when configured.
+(Closes: #809669)
+
+ -- Gaudenz Steinlin   Sat, 06 May 2017 19:42:14 +0200
+
 unattended-upgrades (0.93.1) unstable; urgency=medium
 
   [ Brian Murray ]
diff -Nru unattended-upgrades-0.93.1/debian/postinst 
unattended-upgrades-0.93.1+nmu1/debian/postinst
--- unattended-upgrades-0.93.1/debian/postinst  2016-12-11 11:31:26.0 
+0100
+++ unattended-upgrades-0.93.1+nmu1/debian/postinst 2017-05-06 
19:41:53.0 +0200
@@ -61,6 +61,20 @@
 && [ -f /etc/rc6.d/S[0-9][0-9]unattended-upgrades ] ; then
 update-rc.d -f unattended-upgrades remove
 fi
+# Recover from broken dh_installinit override in versions < 0.93.1+nmu1
+if dpkg --compare-versions "$2" lt "0.93.1+nmu1"; then
+if [ -f /etc/rc0.d/K[0-9][0-9]unattended-upgrades ] \
+&& [ -f /etc/rc6.d/K[0-9][0-9]unattended-upgrades ] ; then
+   update-rc.d -f unattended-upgrades remove
+   fi
+   # If running systemd, explicitely disable the service otherwise
+   # the shutdown.target symlink will remain (See Debian Bug #797108)
+   if [ -d /run/systemd/system ]; then
+   if deb-systemd-helper --quiet was-enabled 
unattended-upgrades.service; then
+   deb-systemd-helper disable unattended-upgrades.service 
>/dev/null || true
+   fi
+   fi
+   fi
 ;;
 
 abort-upgrade|abort-remove|abort-deconfigure)
@@ -77,6 +91,21 @@
 
 #DEBHELPER#
 
+# Explicitly enable and start the service. Debian Bug #797108 for 
+# deb-systemd-helper fails to correctly enable the unit. It checks for 
+# enablement using the content of the WantedBy= which has changed so it
+# sees the service as disable and will not enable it.
+case "$1" in
+configure)
+if dpkg --compare-versions "$2

Bug#809669: RC Bug NMU diff

[Gaudenz Steinlin]

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#856964: Option search in dnssec-trigger.conf is ignored

[Gaudenz Steinlin]

Package: dnssec-trigger
Version: 0.13-6
Severity: important

Since a recent upgrade of dnssec-trigger the "search" option to set
custom search domains is ignored. Looking at the dnssec-trigger-script
which writes resolv.conf it does not even look at this option.

While this does not make the package unusable I consider it quite
important to be able to set custom search domains. If possible it would
be nice this could be fixed for stretch.

Gaudenz

-- System Information:
Debian Release: 9.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 4.9.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.6.2-1
ii  init-system-helpers1.47
ii  libc6  2.24-9
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.50.3-1
ii  libgtk2.0-02.24.31-2
ii  libldns2   1.7.0-1
ii  libssl1.1  1.1.0e-1
ii  python 2.7.13-2
ii  python-gi  3.22.0-2
ii  python-lockfile1:0.12.2-2
ii  unbound1.6.0-3

dnssec-trigger recommends no packages.

dnssec-trigger suggests no packages.

-- Configuration Files:
/etc/dnssec-trigger/dnssec-trigger.conf changed [not included]
/etc/dnssec.conf changed [not included]

-- no debconf information

Bug#850906: [Ceph-maintainers] Bug#850906: ceph FTBFS on armel, libtool/linker related issues.

[Gaudenz Steinlin]

peter green  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#850509: [Ceph-maintainers] Bug#850509: missing systemd targets

[Gaudenz Steinlin]

Control: tags -1 +pending

Hi Hans

Hans Grobler  writes:

> Package: ceph
> Version: 10.2.5-3
>
> Dear Maintainer,
>
> A number of systemd target files are missing, for example
> ceph-mon.target and ceph-osd.target. See
> http://tracker.ceph.com/issues/15573
>  for a similar upstream bug.
> Please include these so that auto-start can be properly configured and
> make the Debian packages consistent with the official documentation
> (e.g. http://docs.ceph.com/docs/master/rados/operations/operating/
> ).

Thanks for your report and the links. I really missed these targets.
This is now fixed in the GIT repository and will be part of the next
upload. I'm currently trying to fix some build failures but have now
hopefully resolved all of these. If the currently running mipsel build
succeeds, I'll do another upload tomorrow.

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

[Gaudenz Steinlin]

Aurelien Jarno  writes:

> On 2017-01-05 14:00, Gaudenz Steinlin wrote:
>> 
>> Hi
>> 
>> Aurelien Jarno  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

[Gaudenz Steinlin]

Emilio Pozuelo Monfort  writes:

> On 05/01/17 14:00, Gaudenz Steinlin wrote:
>> 
>> Hi
>> 
>> Aurelien Jarno  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#849657: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory

[Gaudenz Steinlin]

Hi

Aurelien Jarno  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_posi

Bug#849660: [Ceph-maintainers] Bug#849660: ceph: FTBFS on armel: error: field 'result' has incomplete type 'std::promise'

[Gaudenz Steinlin]

Hi Emilio

Emilio Pozuelo Monfort  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

[Gaudenz Steinlin]

Hi Emilio

Emilio Pozuelo Monfort  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#849538: jessie-pu: package ceph/0.80.7-2+deb8u2

[Gaudenz Steinlin]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi

I would like to update ceph with the next stable point release to fix
the 4 security issues listed below. These are all minor issues which did
not warrant a DSA on their own, but are still worth fixing.

https://security-tracker.debian.org/tracker/CVE-2016-9579
https://security-tracker.debian.org/tracker/CVE-2016-5009
https://security-tracker.debian.org/tracker/CVE-2016-7031
https://security-tracker.debian.org/tracker/CVE-2016-8626

The complete debdiff is attached below. I have already built the
package, but not yet uploaded. As soon as I get your OK I'll upload the
package.

Gaudenz

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-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)
diff -Nru ceph-0.80.7/debian/changelog ceph-0.80.7/debian/changelog
--- ceph-0.80.7/debian/changelog	2016-01-15 10:42:14.0 +0100
+++ ceph-0.80.7/debian/changelog	2016-12-28 10:47:36.0 +0100
@@ -1,3 +1,14 @@
+ceph (0.80.7-2+deb8u2) jessie; urgency=medium
+
+  * [78329e] Upstream fix for CVE-2016-9579 (short CORS request)
+(Closes: #849048)
+  * [514d48] Upstream fix for CVE-2016-5009 (mon DoS) (Closes: #829661)
+  * [7ae81b] Upstream fix for CVE-2016-7031 (anonymous read on ACL)
+(Closes: #838026)
+  * [86ac46] Upstream fix for CVE-2016-8626 (RGW DoS) (Closes: #844200)
+
+ -- Gaudenz Steinlin   Wed, 28 Dec 2016 10:47:36 +0100
+
 ceph (0.80.7-2+deb8u1) jessie; urgency=medium
 
   * [61b5e0] Patch to fix CVE-2015-5245 applied from upstream (Closes: #798567)
diff -Nru ceph-0.80.7/debian/gbp.conf ceph-0.80.7/debian/gbp.conf
--- ceph-0.80.7/debian/gbp.conf	2016-01-15 10:41:01.0 +0100
+++ ceph-0.80.7/debian/gbp.conf	2016-12-27 21:47:49.0 +0100
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = jessie-security
+debian-branch = jessie
 pristine-tar = True
 
 [import-orig]
diff -Nru ceph-0.80.7/debian/patches/cve-2016-5009_mon_dos.patch ceph-0.80.7/debian/patches/cve-2016-5009_mon_dos.patch
--- ceph-0.80.7/debian/patches/cve-2016-5009_mon_dos.patch	1970-01-01 01:00:00.0 +0100
+++ ceph-0.80.7/debian/patches/cve-2016-5009_mon_dos.patch	2016-12-28 10:47:27.0 +0100
@@ -0,0 +1,99 @@
+commit b78a1be835706e7dabc505be343945d0ac05697d
+Author: Kefu Chai 
+Date:   Thu Jun 30 13:24:22 2016 +0800
+
+mon: Monitor: validate prefix on handle_command()
+
+Fixes: http://tracker.ceph.com/issues/16297
+
+Signed-off-by: You Ji 
+(cherry picked from commit 7cb3434fed03a5497abfd00bcec7276b70df0654)
+
+Conflicts:
+src/mon/Monitor.cc (the signature of Monitor::reply_command()
+changed a little bit in master, so adapt the
+commit to work with the old method)
+
+--- a/src/mon/Monitor.cc
 b/src/mon/Monitor.cc
+@@ -2214,7 +2214,19 @@
+ return;
+   }
+ 
+-  cmd_getval(g_ceph_context, cmdmap, "prefix", prefix);
++  // check return value. If no prefix parameter provided,
++  // return value will be false, then return error info.
++  if(!cmd_getval(g_ceph_context, cmdmap, "prefix", prefix)) {
++reply_command(m, -EINVAL, "command prefix not found", 0);
++return;
++  }
++
++  // check prefix is empty
++  if (prefix.empty()) {
++reply_command(m, -EINVAL, "command prefix must not be empty", 0);
++return;
++  }
++
+   if (prefix == "get_command_descriptions") {
+ bufferlist rdata;
+ Formatter *f = new_formatter("json");
+@@ -2235,6 +2247,15 @@
+   boost::scoped_ptr f(new_formatter(format));
+ 
+   get_str_vec(prefix, fullcmd);
++
++  // make sure fullcmd is not empty.
++  // invalid prefix will cause empty vector fullcmd.
++  // such as, prefix=";,,;"
++  if (fullcmd.empty()) {
++reply_command(m, -EINVAL, "command requires a prefix to be valid", 0);
++return;
++  }
++
+   module = fullcmd[0];
+ 
+   // validate command is in leader map
+--- a/src/test/librados/cmd.cc
 b/src/test/librados/cmd.cc
+@@ -49,6 +49,41 @@
+   rados_buffer_free(buf);
+   rados_buffer_free(st);
+ 
++  cmd[0] = (char *)"";
++  ASSERT_EQ(-EINVAL, rados_mon_command(cluster, (const char **)cmd, 1, "{}", 2, &buf, &buflen, &st, &stlen));
++  rados_buffer_free(buf);
++  rados_buffer_free(st);
++
++  cmd[0] = (char *)"{}";
++  ASSERT_EQ(-EINVAL, rados_mon_command(cluster, (const char **)cmd, 1, "", 0, &buf, &buflen, &st, &stlen));
++  rados_buffer_free(buf);
++  rados_buffer_free(st);
++
++  cmd[0] = (char *)"{\"abc\":\

Bug#838026: Sorry for not closing the ceph security reports properly

[Gaudenz Steinlin]

Hi Salvatore

Thanks for closing these bugs and sorry for not closing these properly.
I'm currently the only one left on the "Ceph maintainers team" and so my
top priority was to at least get something uploaded and through new.
Thus I forgot to check all the bug reports to see which ones were closed
with the new upstream release. Sorry for that and sorry for making the
life of the security harder than necessary.

Which of the bugs do you think also warant an upload to stable?

Gaudenz

-- 
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5


signature.asc
Description: PGP signature

Bug#840383: ceph: Mon crash on startup

[Gaudenz Steinlin]

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  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_locker
>   1/ 5 mds_log
>   1/ 5 mds_log_expire
>   1/ 5 mds_migrator
>   0/ 1 buffer
>   0/ 1 timer
>   0/ 1 filer
>   0/ 1 striper
>   0/ 1 objecter
>   0/ 5 rados
>   0/ 5 rbd
>   0/ 5 journaler
>   0/ 5 objectcacher
>   0/ 5 client
>   0/ 5 osd
>   0/ 5 optracker
>   0/ 5 objclass
>   1/ 3 filestore
>   1/ 3 keyvaluestore
>   1/

Bug#844937: owncloud-client at risk of not being in stretch [was Re: Bug#844937: fixed in owncloud-client 2.2.4+dfsg-2]

[Gaudenz Steinlin]

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  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#847267: Updating the discover-data Uploaders list

[Gaudenz Steinlin]

Package: discover-data
Version: 2.2013.01.11
Followup-For: Bug #847267

Please also remove myself from the uploaders list. I have not done any
work on the package in recent years.

Thanks,
Gaudenz

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.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)

discover-data depends on no packages.

Versions of packages discover-data recommends:
ii  pciutils  1:3.5.2-1

discover-data suggests no packages.

-- no debconf information

Bug#848424: Please remove me from uploaders

[Gaudenz Steinlin]

Package: discover
Version: 2.1.2-7
Severity: wishlist

Please remove my name from the uploaders filed. I haven't done any work
on this package for years. As I have been removed from the pkg-discover
alioth group I cannot do this myself.

Thanks,
Gaudenz

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.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 discover depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-8
ii  libdiscover2   2.1.2-7
ii  libexpat1  2.2.0-1
ii  libusb-0.1-4   2:0.1.12-30

discover recommends no packages.

Versions of packages discover suggests:
ii  lsb-base  9.20161125

-- debconf information excluded

Bug#844701: Fix for 844701 breaks installation of valgrind

[Gaudenz Steinlin]

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#843763: New upstream version 2.2

[Gaudenz Steinlin]

Package: ansible
Version: 2.1.1.0-1
Severity: wishlist

Ansible 2.2 was released some time ago. Would be nice to have this in
unstable soon to make sure it get's into the Stretch release.

I did a local test build from your git repository and the only change
needed was to refresh the quilt debian patch.

Thanks,
Gaudenz

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.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 ansible depends on:
ii  python-crypto 2.6.1-6+b1
ii  python-httplib2   0.9.1+dfsg-1
ii  python-jinja2 2.8-1
ii  python-netaddr0.7.18-2
ii  python-paramiko   2.0.0-1
ii  python-pkg-resources  28.7.1-1
ii  python-yaml   3.12-1
pn  python:any

Versions of packages ansible recommends:
ii  python-selinux  2.6-1

Versions of packages ansible suggests:
pn  sshpass  

-- no debconf information

Bug#842359: RM: ceph-dkms/experimental -- ROM; outdated and no longer needed

[Gaudenz Steinlin]

Package: ftp.debian.org
Severity: normal

This package is outdated and the ceph client kernel module is long
since included in the upstream Linux kernel. The dkms package is no
longer needed.

Bug#839205: openorienteering-mapper: New version available on Github

[Gaudenz Steinlin]

Hi Kai

"Kai Pastor, DG0YT"  writes:

> Package: openorienteering-mapper
> Version: 0.6.3-2
>
> Dear Maintainer,
>
> OpenOrienteering Mapper is developed on Github
> (https://github.com/OpenOrienteering/mapper/).
> The current release is 0.6.5.
> The watch file in Debian needs to be corrected to point to Github 
> instead of Sourceforge.

Thanks for the message. I did not notice that you switch the official
location for the source release tarballs. Is this right, that you no
longer manually build the tarballs but the github generated tarballs
from tags are also the official releases? I'm fine with that, just want
to make sure that I can update the watch file to point to the right URL.

It would also be nice if you could point to the Debian packages at least
for people running Debian testing/unstable or the next Ubuntu release.
These contain many improvements over the automatically built packages
from the OpenSUSE service.

Gaudenz

Bug#829038: owncloud-client: FTBFS in testing (LaTeX Error: File `iftex.sty' not found)

[Gaudenz Steinlin]

Santiago Vila  writes:

> Package: src:owncloud-client
> Version: 2.2.1+dfsg-1
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> Severity: serious
>
> Dear maintainer:
>
> This package currently fails to build in stretch:
>
> 
> [...]
> make[6]: Entering directory 
> '/<>/owncloud-client-2.2.1+dfsg/obj-x86_64-linux-gnu/doc/latex'
> pdflatex  'ownCloudClientManual.tex'
> This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) 
> (preloaded format=pdflatex)
>  restricted \write18 enabled.
> entering extended mode
> (./ownCloudClientManual.tex
> LaTeX2e <2016/03/31> patch level 1
> Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
> (./sphinxmanual.cls
> Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
> (/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
> Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
> (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))
>
> ! LaTeX Error: File `iftex.sty' not found.
> 

I belive this is fixed in version 2.2.1+dfsg-2 currently in
experimental. Sandro, any plans to upload this to unstable?

Gaudenz

Bug#828823: Don't include cloud-initramfs-growroot in cloud images

[Gaudenz Steinlin]

Package: openstack-debian-images
Version: 1.13
Severity: wishlist
Tags: patch

Please remove cloud-initramfs-growroot from the images at least for
testing/unstable. Newer kernels (since 3.8) can change the partition of
the root filesystem while it's mounted, so this is no longer needed.
There is support for growing the root partition already in cloud-init.
All other major distributions use this mechanism.

The advantage of growing the partition with cloud-init is that the
behavior can be overriden by an external data source (metadata server,
config drive, ...) without modifying the image. The behavior of
cloud-initramfs-growroot can not be overriden in this way.

This would also be nice to have in jessie. The required kernel support
is available in jessie, but cloud-init from backports is needed to
activate the growpart module.

The attached patch removes cloud-initramfs-growroot from the image (not
for wheezy).

Gaudenz

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.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)
diff --git a/build-openstack-debian-image b/build-openstack-debian-image
index 44a1149..035e1e6 100755
--- a/build-openstack-debian-image
+++ b/build-openstack-debian-image
@@ -207,7 +207,7 @@ if [ "${RELEASE}" = "wheezy" ] ; then
 	# apt-get -t wheezy-backports install cloud-init cloud-utils cloud-initramfs-growroot
 	NEEDED_PACKAGES=${NEEDED_PACKAGES},python,python-paramiko,python-argparse,python-cheetah,python-configobj,python-oauth,python-software-properties,python-yaml,python-boto,python-prettytable,initramfs-tools,python-requests,acpid,acpi-support-base,ntp,unscd
 else
-	NEEDED_PACKAGES=${NEEDED_PACKAGES},cloud-init,cloud-utils,cloud-initramfs-growroot,dbus,libpam-systemd,ntp,unscd
+	NEEDED_PACKAGES=${NEEDED_PACKAGES},cloud-init,cloud-utils,dbus,libpam-systemd,ntp,unscd
 fi
 
 # This is a workaround for python3-cryptography failing to install
diff --git a/build-openstack-debian-image.1 b/build-openstack-debian-image.1
index 3a62123..e2c777b 100644
--- a/build-openstack-debian-image.1
+++ b/build-openstack-debian-image.1
@@ -11,8 +11,8 @@ build\-openstack\-debian\-image \- build a Debian image to be used with OpenStac
 The
 .I build\-openstack\-debian\-image
 shell script will build a Debian image which can be used in an OpenStack IaaS
-cloud. The resulting (Qcow2 and raw images) contains initramfs\-growroot so
-that the root partition will be resized (during the initramfs phase, before
+cloud. The resulting (Qcow2 and raw images) contains cloud\-init growpart support
+so that the root partition will be resized (during the initramfs phase, before
 mouting anything) to match the flavor selected when using "nova boot". Later on
 during the boot process, cloud\-init will resize the root partition on the fly
 (resize is performed when the partition is already mounted read\-write, since

Bug#814891: management interface does not show node statistics

[Gaudenz Steinlin]

Hi Thomas

Thomas Goirand  writes:

> Hi Gaudenz,
>
> I'm a bit frustrated to see this bug has been left opened for so long
> with no resolution, and would like to work on it, as I'm attempting to
> clean the BTS as much as possible.
>
> In your earlier reply, you've suggested to find the commit from upstream
> fixing the issue. Would you be able to do so yourself?

Sorry but currently I don't have the time to do that and I'm personally
no longer using this package.

Gaudenz

Bug#820120: Please include interfaces.d in /etc/network/interfaces

[Gaudenz Steinlin]

Package: openstack-debian-images
Severity: normal

The default Debian /etc/network/interfaces file contains a line 

source /etc/network/interfaces.d/*

since at least wheezy. Please also include this line in the /e/n/i file
generated by openstack-debian-images. And maybe even put the 3 interface
configurations into separate files in interfaces.d.

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)

Bug#818649: power.d scripts are not run at all

[Gaudenz Steinlin]

Package: pm-utils
Version: 1.4.1-16
Severity: important

Hi

The scripts in /usr/lib/pm-utils/power.d are not run at all when power
is plugged or unplugged. If I understand this correctly upower used to
call pm-powersave but the code to do this was removed in recent
versions. For some time there was a --enable-deprecated switch to upower
which was used in Debian, but the corresponding code has been removed
from upower.

acpid also calls pm-powersave from /etc/acpi/power.sh, but checks for
upower before doing this. So as long as upower is running this does not
work either. But the jessie release notes [1] recommend to uninstall
acpid if using logind (which is probably used on most laptop system).

I don't have a good suggestion on how to fix this, but IMO this should
be at least documented somewhere in the package and the scripts should
be removed if they are no longer executed by anything.

Another option would be to add a udev rule like suggested in the Arch
wiki. [2] 

Feel free to reassign this bug to a more appropriate package.

Gaudenz

[1]
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#idp36451200

[2]
https://wiki.archlinux.org/index.php/Power_management#Using_a_script_and_an_udev_rule

-- 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 pm-utils depends on:
ii  powermgmt-base  1.31+nmu1

Versions of packages pm-utils recommends:
ii  ethtool  1:4.2-1
ii  hdparm   9.43-2
ii  kbd  2.0.3-2
ii  procps   2:3.3.11-3
ii  vbetool  1.1-3

Versions of packages pm-utils suggests:
pn  cpufrequtils
pn  radeontool  
ii  wireless-tools  30~pre9-8

-- no debconf information

Bug#818159: Setting x-www-browser alternative to firefox starts firefox-esr

[Gaudenz Steinlin]

Package: firefox
Version: 46.0~b1-1
Severity: important

Setting the x-www-browser alternative to firefox does not work because
the logic in /usr/bin/firefox to detect which version should be started
fails. The problem is that $0 in this case is /usr/bin/x-www-browser and
the script then checks for /usr/bin/x-www-browser.real instead of
/usr/bin/firefox.real.

I'm not sure what the purpose of the /usr/bin/firefox script is. If it's
only there to allow starting firefox-esr as firefox as long as the
firefox package is not installed, then it could be simplyfied to just
check for /usr/bin/firefox.real and start that if it exists and start
firefox-esr otherwise. Like this it would no longer use $0 and not
depend on the name it's called.

Another option to solve this issue would be to let the alternative point 
to firefox.real directly.

Gaudenz

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled

Name: Certificate Patrol
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/certpat...@psyc.eu
Package: xul-ext-certificatepatrol
Status: enabled

Name: Debian buttons
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{8fb11c5b-84eb-4da0-9128-292eacce2dcb}
Package: xul-ext-debianbuttons
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: Deutsch (DE) Language Pack locale
Location: 
/usr/lib/firefox/browser/extensions/langpack...@firefox.mozilla.org.xpi
Package: firefox-l10n-de
Status: enabled

Name: DNSSEC/TLSA Validator
Location: ${PROFILE_EXTENSIONS}/dns...@nic.cz
Status: enabled

Name: Element Hiding Helper for Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/elemhidehel...@adblockplus.org
Package: xul-ext-adblock-plus-element-hiding-helper
Status: enabled

Name: Ember Inspector
Location: ${PROFILE_EXTENSIONS}/ember-inspec...@emberjs.com.xpi
Status: user-disabled

Name: Extended DNSSEC Validator
Location: ${PROFILE_EXTENSIONS}/extended-valida...@os3sec.org
Status: user-disabled

Name: Firebug
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/fire...@software.joehewitt.com
Package: xul-ext-firebug
Status: enabled

Name: Firefox Hello Beta
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: Flashblock
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{3d7eb24f-2740-49df-8937-200b1cc08f8a}
Package: xul-ext-flashblock
Status: enabled

Name: Français Language Pack locale
Location: 
/usr/lib/firefox/browser/extensions/langpack...@firefox.mozilla.org.xpi
Package: firefox-l10n-fr
Status: enabled

Name: Ghostery
Location: ${PROFILE_EXTENSIONS}/fire...@ghostery.com.xpi
Status: enabled

Name: GNOME Keyring integration
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/gnome-keyring-integrat...@sebastianwick.net
Package: xul-ext-gnome-keyring
Status: user-disabled

Name: HTTPS-Everywhere
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/https-everywhere-...@eff.org
Package: xul-ext-https-everywhere
Status: enabled

Name: JS Deminifier
Location: ${PROFILE_EXTENSIONS}/jsdeminif...@murphy.ben.name.xpi
Status: enabled

Name: Lightbeam
Location: ${PROFILE_EXTENSIONS}/jid1-f9uj2thwoam...@jetpack.xpi
Status: enabled

Name: Monkeysphere
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/tls-xul-...@monkeysphere.info
Package: xul-ext-monkeysphere
Status: enabled

Name: NoScript
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{73a6fe31-595d-460b-a920-fcc0f8843232}
Package: xul-ext-noscript
Status: enabled

Name: Operator
Location: ${PROFILE_EXTENSIONS}/{95C9A302-8557-4052-91B7-2BB6BA33C885}.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: PrefBar
Location: ${PROFILE_EXTENSIONS}/{8A6C82A1-F6C9-481a-AAE7-C96444C9A754}
Status: enabled

Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpnsxq-...@jetpack.xpi
Status: enabled

Name: Send Tab to Device
Location: ${PROFILE_EXTENSIONS}/jid1-mdjma7if6lo...@jetpack.xpi
Status: enabled

Name: ShareMeNot
Location: ${PROFILE_EXTENSIONS}/shareme...@franziroesner.com.xpi
Status: user-disabled

Name: User Agent Switcher
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}
Package: xul-ext-useragentswitcher
Status: enabled

Name: Video WithOut Flash
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/v...@drev.com
Package: xul-ext-video-without-flash
Status: enabled

Name: WOT
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f

Bug#815156: [PKG-Openstack-devel] Bug#815156: Bug#815156: Bug#815156: Bug#815156: New upstream release 0.1.6

[Gaudenz Steinlin]

Thomas Goirand  writes:

>> I still can't push my changes and did not receive a reply from you.
>> Would you prefer an upload without pushing the changes? Is there some
>> reason why you don't want to add me to the project or did you forget
>> about it?
>> 
>> Gaudenz
>
> None of the above. I was expecting you would do a request to join. Never
> mind, I have just added you on Alioth using your Debian account
> username. Welcome to the team! :)

Thanks. Glad it was only misunderstanding. Sorry I did not think about
the possibility to do a join request on Alioth.

Gaudenz

Bug#815156: [PKG-Openstack-devel] Bug#815156: Bug#815156: New upstream release 0.1.6

[Gaudenz Steinlin]

Gaudenz Steinlin  writes:

> Hi Thomas
>
> Thomas Goirand  writes:
>
>> On 02/19/2016 09:44 PM, Gaudenz Steinlin wrote:
>>> Package: spice-html5
>>> Severity: wishlist
>>> 
>>> Please upgrade spice-html5 to the latest upstream version which is
>>> currently 0.1.6. This fixes SSL access to the console from the Web
>>> Browser to the Websocket proxy.
>>> 
>>> I did a test build and the upgrade is as simple as just upgrading to the
>>> latest version without any changes to the Debian packageing. If you want
>>> I can directly commit this to the GIT repository or even do an upload to
>>> unstable.
>>> 
>>> Gaudenz
>>
>> Gaudenz,
>>
>> By all means, your contribution is welcome! Please do commit to the git,
>> and upload to Sid. Feel free to add yourself in the Uploaders fields.
>
> I have now prepared an upload to unstable, however I can't push my
> changes to the GIT repository because of missing access rights. Can you
> please add me to the Alioth group. I did not upload the package just now
> because of this.

I still can't push my changes and did not receive a reply from you.
Would you prefer an upload without pushing the changes? Is there some
reason why you don't want to add me to the project or did you forget
about it?

Gaudenz


signature.asc
Description: PGP signature

Bug#815880: Fails to update /etc/resolv.conf with network-manager 1.1.90

[Gaudenz Steinlin]

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 
 """
 
+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#815156: [PKG-Openstack-devel] Bug#815156: New upstream release 0.1.6

[Gaudenz Steinlin]

Hi Thomas

Thomas Goirand  writes:

> On 02/19/2016 09:44 PM, Gaudenz Steinlin wrote:
>> Package: spice-html5
>> Severity: wishlist
>> 
>> Please upgrade spice-html5 to the latest upstream version which is
>> currently 0.1.6. This fixes SSL access to the console from the Web
>> Browser to the Websocket proxy.
>> 
>> I did a test build and the upgrade is as simple as just upgrading to the
>> latest version without any changes to the Debian packageing. If you want
>> I can directly commit this to the GIT repository or even do an upload to
>> unstable.
>> 
>> Gaudenz
>
> Gaudenz,
>
> By all means, your contribution is welcome! Please do commit to the git,
> and upload to Sid. Feel free to add yourself in the Uploaders fields.

I have now prepared an upload to unstable, however I can't push my
changes to the GIT repository because of missing access rights. Can you
please add me to the Alioth group. I did not upload the package just now
because of this.

>
> The only requirement is that you don't change the git based workflow,
> and check that the package builds fine in Jenkins (so, join
> #debian-openstack-commits and check the result from the bot), so that we
> make sure we have a working backports.

I just merged the upstream tag into the debian/unstable branch. I hope
that's what you mean by "don't change the git based workflow". If there
are more things I should consider, please point me to the right
documentation.

As upstream does not currently release any tarballs I just created one
with git archive.

I'll check the Jenkins results once the package is uploaded.

Gaudenz


signature.asc
Description: PGP signature

Bug#814891: [PKG-Openstack-devel] Bug#814891: management interface does not show node statistics

[Gaudenz Steinlin]

Hi Thomas

Thomas Goirand  writes:

> Hi Benedikt,
>
> So, according to what you wrote, there's a missing feature in Jessie.
> But the general policy is to *not* add new features to the Stable branch
> of Debian, and likely, the release team would refuse such an update.

It's not a missing feature but a broken feature. The same feature was
working in wheezy and is working in stretch. Also the log attached to
the original report clearly shows that the feature was not just removed
but is broken but intended to be present.

> So I don't understand how any action can be made on this bug.
>
> Could you explicit what you expect the rabbitmq package maintainers to
> do in this case?

Bug severities are ultimately your call to decide upon but I would treat
this as an RC bug in a package in stable, try to find the upstream
commit that fixes it, apply this as a patch to the version in stable and
upload to stable-proposed-updates.

AFAIK the stable release team is commited to fixing RC bugs in stable
updates even if they are only found after the release.

I would consider this RC because it's a regression and because it makes
it impossible to monitor the node. You need the node statistics for
effective monitoring. Running something like RabbitMQ in production
without monitoring is not an option IMO.

Gaudenz

P.S.: I tried to set the correct version information on this bug so that
it's clear that it only affects stable. I hope I got it right, feel free
to adjust if my commands did not do the right thing (TM).


signature.asc
Description: PGP signature

Bug#815156: New upstream release 0.1.6

[Gaudenz Steinlin]

Package: spice-html5
Severity: wishlist

Please upgrade spice-html5 to the latest upstream version which is
currently 0.1.6. This fixes SSL access to the console from the Web
Browser to the Websocket proxy.

I did a test build and the upgrade is as simple as just upgrading to the
latest version without any changes to the Debian packageing. If you want
I can directly commit this to the GIT repository or even do an upload to
unstable.

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)

Bug#812627: Please upgrade to new development branch 1.9.X

[Gaudenz Steinlin]

Source: wine-development
Severity: wishlist

Dear wine maintainers

The 1.7.X development release branch is not current anymore. Please
upgrade wine-development to the 1.9.X development releases.

Thanks,
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)

Bug#784373: [Ceph-maintainers] Bug#784373: jessie-pu: package ceph/0.80.9-2 (pre approval)

[Gaudenz Steinlin]

Control: clone 784373 -1
Control: retitle -1 jessie-pu: package ceph/0.80.7-2+deb8u1
Control: retitle 784373 jessie-pu: package ceph/0.80.11-1 (pre approval)

Hi 

Gaudenz Steinlin  writes:

> Hi Julien
>
> Do you need any additional information? I would like to have a decision
> on this soon as I really want to get at least CVE-2015-5245 fixed in the
> next Debian stable release. This is a minor security issue which was
> defered by the Security Team to a stable update and there was no DSA
> issued for it.
>
> To be able to prepare the upload for the stable release I need to know
> if you agree to follow the upstream maintenance releases or if I have to
> do an upload with only the security issue fixed. If I got the timing
> right, the next point release is still scheduled for 24th January. So
> there is only little time left to prepare the upload.
>
> As this is now undecided for quite a long time I would even prefer a NACK
> to having this unresolved any longer if you don't feel comfortable with
> the idea of having the maintenance releases in stable. This way I at
> least know that I don't have to bother anymore.
>
> If you don't want to rush things but are in gernal fine with the idea.
> I'm also fine with only fixing the security bug now as the time is quite
> tight and uploading 0.80.11 for the Debian 8.4 point release.

As I did not get any feedback I have now uploaded ceph/0.80.7-2+deb8u1
with only the security bug fixed. I think this is really the minimum
that should go into the next stable point release and I don't think
there is any concern about this. I cloned the original bug report to
track this jessie-pu request. The debdiff to the version currently in
stable is attached. It's minimal.

I would still appreciate an answer on #784373. Even if it's just the
stable team does not currently have the resources to evaluate this
request and therefore declines to make an exception to the usual stable
update rules. This would not be the answer I had hoped for, but at least
I then know that I don't have to invest more time into the 0.80.X series
of ceph.

Gaudenz

diff -Nru ceph-0.80.7/debian/changelog ceph-0.80.7/debian/changelog
--- ceph-0.80.7/debian/changelog	2014-12-11 02:55:49.0 +0100
+++ ceph-0.80.7/debian/changelog	2016-01-15 10:42:14.0 +0100
@@ -1,3 +1,9 @@
+ceph (0.80.7-2+deb8u1) jessie; urgency=medium
+
+  * [61b5e0] Patch to fix CVE-2015-5245 applied from upstream (Closes: #798567)
+
+ -- Gaudenz Steinlin   Fri, 15 Jan 2016 10:41:27 +0100
+
 ceph (0.80.7-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru ceph-0.80.7/debian/gbp.conf ceph-0.80.7/debian/gbp.conf
--- ceph-0.80.7/debian/gbp.conf	2014-12-11 02:33:33.0 +0100
+++ ceph-0.80.7/debian/gbp.conf	2016-01-15 10:41:01.0 +0100
@@ -1,5 +1,5 @@
 [DEFAULT]
-#debian-branch = experimental
+debian-branch = jessie-security
 pristine-tar = True
 
 [import-orig]
diff -Nru ceph-0.80.7/debian/patches/CVE-2015-5245.patch ceph-0.80.7/debian/patches/CVE-2015-5245.patch
--- ceph-0.80.7/debian/patches/CVE-2015-5245.patch	1970-01-01 01:00:00.0 +0100
+++ ceph-0.80.7/debian/patches/CVE-2015-5245.patch	2016-01-15 10:41:01.0 +0100
@@ -0,0 +1,35 @@
+From ad5507fe0bf72ed5bdf8353e315cc9092c740144 Mon Sep 17 00:00:00 2001
+From: Yehuda Sadeh 
+Date: Thu, 30 Jul 2015 14:47:15 -0700
+Subject: [PATCH] rgw: url encode exposed bucket
+
+Fixes: #12537
+Don't send the bucket name back without url encoding it.
+
+Signed-off-by: Yehuda Sadeh 
+
+The patch below is an adapted version for ceph 0.80.7 to only contain
+the necessary changes to fix this vulnerability. Neither the quoting 
+of the bucket name nor the missing \r are fixed.
+(see http://tracker.ceph.com/issues/9254 and http://tracker.ceph.com/issues/11860)
+
+---
+ src/rgw/rgw_rest.cc | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/src/rgw/rgw_rest.cc
 b/src/rgw/rgw_rest.cc
+@@ -272,8 +272,11 @@
+ {
+   int expose_bucket = g_conf->rgw_expose_bucket;
+   if (expose_bucket) {
+-if (!s->bucket_name_str.empty())
+-  s->cio->print("Bucket: \"%s\"\n", s->bucket_name_str.c_str());
++if (!s->bucket_name_str.empty()) {
++  string b;
++  url_encode(s->bucket_name_str, b);
++  s->cio->print("Bucket: \"%s\"\n", b.c_str());
++}
+   }
+ }
+ 
diff -Nru ceph-0.80.7/debian/patches/series ceph-0.80.7/debian/patches/series
--- ceph-0.80.7/debian/patches/series	2014-12-11 02:33:47.0 +0100
+++ ceph-0.80.7/debian/patches/series	2016-01-15 10:41:01.0 +0100
@@ -14,6 +14,7 @@
 bash-completion.patch
 rbdmap1-mount.patch
 rbdmap2-hooks.patch
+CVE-2015-5245.patch
 
 ## Debian
 rbdmap3-lazyumount.patch


signature.asc
Description: PGP signature

Bug#784373: [Ceph-maintainers] Bug#784373: jessie-pu: package ceph/0.80.9-2 (pre approval)

[Gaudenz Steinlin]

Hi Julien

Do you need any additional information? I would like to have a decision
on this soon as I really want to get at least CVE-2015-5245 fixed in the
next Debian stable release. This is a minor security issue which was
defered by the Security Team to a stable update and there was no DSA
issued for it.

To be able to prepare the upload for the stable release I need to know
if you agree to follow the upstream maintenance releases or if I have to
do an upload with only the security issue fixed. If I got the timing
right, the next point release is still scheduled for 24th January. So
there is only little time left to prepare the upload.

As this is now undecided for quite a long time I would even prefer a NACK
to having this unresolved any longer if you don't feel comfortable with
the idea of having the maintenance releases in stable. This way I at
least know that I don't have to bother anymore.

If you don't want to rush things but are in gernal fine with the idea.
I'm also fine with only fixing the security bug now as the time is quite
tight and uploading 0.80.11 for the Debian 8.4 point release.

Gaudenz

Gaudenz Steinlin  writes:

> [ CCing the upstream package maintainers list ]
>
> Hi
>
> Julien Cristau  writes:
>
>> On Fri, Sep 18, 2015 at 22:57:27 +0200, Gaudenz Steinlin wrote:
>>
>>> 
>>> Hi debian-release
>>> 
>>> Gaudenz Steinlin  writes:
>>> 
>>> > Gaudenz Steinlin  writes:
>>> >> I'd like to update ceph in jessie to the latest upstream bugfix release.
>>> >> The version of ceph in jessie is a long term support (LTS) release which
>>> >> will receive updates at least until January 2016. Updates will be bugfix
>>> >> only. New features go into new release which are developed in parallel.
>>> >> See at the end of this report for the upstream changelog.
>>> >>
>>> >> See http://ceph.com/docs/master/releases/ for the ceph release timeline
>>> >> and support statement.
>>> >>
>>> >
>>> > Just as an additional data point, Ubuntu has a "Minor Release Exception"
>>> > for stable updates for their ceph package [1].
>>> 
>>> In the meantime another stable point release of ceph 0.80 (0.80.10) was
>>> released and on top of that there is a (minor) security issue which
>>> won't be fixed through a security update but which would be nice to fix
>>> by a stable update (see bug #798567 / CVE-2015-5245)).
>>> 
>>> As another stable update has passed, it would be nice if someone of the
>>> stable release team could comment on this and eventually decide if they
>>> are OK with the proposal to follow the ceph stable branch or if they
>>> don't like it and would prefer an update just fixing the security bug.
>>> It would be nice to have a decision soon, so that there is enough time
>>> to prepare and test the update for the next stable point release.
>>> 
>> What does the QA process on upstream's bugfix releases, and on the
>> Debian side for the proposed stable updates, look like?
>
> The QA processes on the upstream side are quite extensive. They run
> integration and upgrade tests on a regular basis. They use their test
> framework theutology[1] for these tests. Their QA configuration is
> available in the ceph-qa-suite repository [2].
>
> Unfortunately it's not easy to see how this testing is actually done and
> if the tests all pass at release time. Maybe someone from upstream Ceph
> can shed some more light on this and explain things in more detail. Some
> test results can be seen on Pulpito [3] but it's not clear to me how
> these results relate to actual releases.
>
> The QA on the Debian side is not as extensive. My resources are limited,
> but I do run my builds on my own test infrastructure. But I expect the
> changes to the Debian packaging side to be fairly minimal.
>
>>
>> So far I'm leaning towards rejecting this request, as I don't want to
>> spend that much time reviewing these changes, and as you see we're
>> already way behind on stable update requests.
>
> I don't think it's reasonable to expect the release team to review the
> upstream changes. If you don't trust them enough to not break things,
> then we should not upgrade the package. On the other hand other major
> Linux distribution do trust them enough as I wrote in my initial
> request.
>
> If you agree to do these stable updates they have to be done in a
> similar way to the postgres and linux kernel updates. I don't think the
> release team or any Debian 

Bug#810784: should match email adress case insensitive when sending encrypted mail

[Gaudenz Steinlin]

Package: notmuch-emacs
Version: 0.21-3
Severity: normal

When sending encrypted mail the key lookup to encrypt to is done case
sensitive on the mail address. As mail addresses are case insensitive
this should be done case insensitive. Otherwise keys for users which for
some reason have uppercase letters in their email address in the key UID
are not found.

Gaudenz

P.S.: I'm not completely sure if this part of the mail sending is done
by notmuch-emacs or some other part of emacs. Feel free to reassign as
appropriate.

-- 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 notmuch-emacs depends on:
ii  emacs24 24.5+1-3
ii  emacsen-common  2.0.8
ii  notmuch 0.21-3

notmuch-emacs recommends no packages.

notmuch-emacs suggests no packages.

-- no debconf information

Bug#784373: [Ceph-maintainers] jessie-pu: package ceph/0.80.9-2 (pre approval)

[Gaudenz Steinlin]

[ CCing the upstream package maintainers list ]

Hi

Julien Cristau  writes:

> On Fri, Sep 18, 2015 at 22:57:27 +0200, Gaudenz Steinlin wrote:
>
>> 
>> Hi debian-release
>> 
>> Gaudenz Steinlin  writes:
>> 
>> > Gaudenz Steinlin  writes:
>> >> I'd like to update ceph in jessie to the latest upstream bugfix release.
>> >> The version of ceph in jessie is a long term support (LTS) release which
>> >> will receive updates at least until January 2016. Updates will be bugfix
>> >> only. New features go into new release which are developed in parallel.
>> >> See at the end of this report for the upstream changelog.
>> >>
>> >> See http://ceph.com/docs/master/releases/ for the ceph release timeline
>> >> and support statement.
>> >>
>> >
>> > Just as an additional data point, Ubuntu has a "Minor Release Exception"
>> > for stable updates for their ceph package [1].
>> 
>> In the meantime another stable point release of ceph 0.80 (0.80.10) was
>> released and on top of that there is a (minor) security issue which
>> won't be fixed through a security update but which would be nice to fix
>> by a stable update (see bug #798567 / CVE-2015-5245)).
>> 
>> As another stable update has passed, it would be nice if someone of the
>> stable release team could comment on this and eventually decide if they
>> are OK with the proposal to follow the ceph stable branch or if they
>> don't like it and would prefer an update just fixing the security bug.
>> It would be nice to have a decision soon, so that there is enough time
>> to prepare and test the update for the next stable point release.
>> 
> What does the QA process on upstream's bugfix releases, and on the
> Debian side for the proposed stable updates, look like?

The QA processes on the upstream side are quite extensive. They run
integration and upgrade tests on a regular basis. They use their test
framework theutology[1] for these tests. Their QA configuration is
available in the ceph-qa-suite repository [2].

Unfortunately it's not easy to see how this testing is actually done and
if the tests all pass at release time. Maybe someone from upstream Ceph
can shed some more light on this and explain things in more detail. Some
test results can be seen on Pulpito [3] but it's not clear to me how
these results relate to actual releases.

The QA on the Debian side is not as extensive. My resources are limited,
but I do run my builds on my own test infrastructure. But I expect the
changes to the Debian packaging side to be fairly minimal.

>
> So far I'm leaning towards rejecting this request, as I don't want to
> spend that much time reviewing these changes, and as you see we're
> already way behind on stable update requests.

I don't think it's reasonable to expect the release team to review the
upstream changes. If you don't trust them enough to not break things,
then we should not upgrade the package. On the other hand other major
Linux distribution do trust them enough as I wrote in my initial
request.

If you agree to do these stable updates they have to be done in a
similar way to the postgres and linux kernel updates. I don't think the
release team or any Debian developer reviews all upstream changes there.
So it's really a matter of trust.

Upstream also provides their own Debian packages which are always
updated to the latest bugfix point releases. I guess many users use
these packages instead of the packages from Debian because they are
up to date wrt bugfix releases. IMO this is sad as I think Debian should
aim at providing the most useful experience out of the box without 3rd
party repositories.

Gaudenz

[1] https://github.com/ceph/teuthology
[2] https://github.com/ceph/ceph-qa-suite/tree/firefly
[3] http://pulpito.ceph.com/?branch=firefly


signature.asc
Description: PGP signature

Bug#757945: Incorrectly changes DEP-11 data

[Gaudenz Steinlin]

Package: approx
Version: 5.5-2+b1
Followup-For: Bug #757945

Control: -1 severity important

The DEP-11 data added to the mirrors contains icons-*.tar.gz files.
These can change on every archive update and are not versioned. They
should definitely not be cached like source archives which don't change.

Increasing severity as upgrades now fail if the appstream package is
installed.

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=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages approx depends on:
ii  adduser   3.113+nmu3
ii  bzip2 1.0.6-8
ii  curl  7.45.0-1+b1
ii  debconf [debconf-2.0] 1.5.58
ii  libc6 2.21-4
ii  libpcre3  2:8.35-8
ii  openbsd-inetd [inet-superserver]  0.20140418-2
ii  rsyslog [system-log-daemon]   8.14.0-2
ii  update-inetd  4.43
ii  xz-utils  5.1.1alpha+20120614-2.1

approx recommends no packages.

Versions of packages approx suggests:
pn  libconfig-model-approx-perl  

-- Configuration Files:
/etc/approx/approx.conf changed [not included]

-- debconf information:
  approx/port: 

Bug#808277: Fails with filenames which contain spaces

[Gaudenz Steinlin]

Package: ucf
Version: 3.0031
Severity: normal

UCF fails for files which contain spaces. See the test case below. It also 
fails if only the source 
or destination file contain spaces.

gaudenz@moebius:~/tmp/ucf-test$ tree
.
├── dest
├── lib
│   └── cache
└── source
└── file with space

4 directories, 1 file
gaudenz@moebius:~/tmp/ucf-test$ sudo ucf --debug=5 --state-dir ./lib 
source/file\ with\ space dest/file\ with\ space
The new start file is  `/home/gaudenz/tmp/ucf-test/source/file
/home/gaudenz/tmp/ucf-test/with
/home/gaudenz/tmp/ucf-test/space\'
The destination is `/home/gaudenz/tmp/ucf-test/dest/file
/home/gaudenz/tmp/ucf-test/with
/home/gaudenz/tmp/ucf-test/space\' 
(`\/home\/gaudenz\/tmp\/ucf\-test\/dest\/file\ 
\/home\/gaudenz\/tmp\/ucf\-test\/with\ \/home\/gaudenz\/tmp\/ucf\-test\/space\')
The history is kept under  \'/home/gaudenz/tmp/ucf-test/source/file\'
The file may be cached at \'./lib/cache/:home:gaudenz:tmp:ucf-test:dest:file 
:home:gaudenz:tmp:ucf-test:with :home:gaudenz:tmp:ucf-test:space\'
The destination file does not exist.
The old md5sum does not exist.
The new file does not exist.
Historical md5sums are not available
The new start file is  `/home/gaudenz/tmp/ucf-test/source/file
/home/gaudenz/tmp/ucf-test/with
/home/gaudenz/tmp/ucf-test/space\'
The destination is `/home/gaudenz/tmp/ucf-test/dest/file
/home/gaudenz/tmp/ucf-test/with
/home/gaudenz/tmp/ucf-test/space\' 
(`\/home\/gaudenz\/tmp\/ucf\-test\/dest\/file\ 
\/home\/gaudenz\/tmp\/ucf\-test\/with\ \/home\/gaudenz\/tmp\/ucf\-test\/space\')
The history is kept under  \'/home/gaudenz/tmp/ucf-test/source/file\'
The file may be cached at \'./lib/cache/:home:gaudenz:tmp:ucf-test:dest:file 
:home:gaudenz:tmp:ucf-test:with :home:gaudenz:tmp:ucf-test:space\'


-- 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=de_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ucf depends on:
ii  coreutils  8.23-4
ii  debconf1.5.58

ucf recommends no packages.

ucf suggests no packages.

-- debconf information:
* ucf/changeprompt_threeway: keep_current
  ucf/conflicts_found:
  ucf/title:
* ucf/changeprompt: keep_current
* ucf/show_diff:

Bug#804883: QNAM does not report correct NetworkAccessibility (was: Regression: OwnCloud client fails to reconnect when network starts up)

[Gaudenz Steinlin]

Control: -1 retitle QNAM does not report correct NetworkAccessibility

[ Resending this to the Debian Qt/KDE maintainers as it only made it to
the Owncloud maintainers list. Sorry about my confusion how the BTS
would handle this. This is about Debian bug #804883 ]

Hi

Some context for the QT maintainers: This is about a bug in
owncloud-client which fails to reconnect to the server if the network
connection is lost. This is quite annoying because after every suspend
of your machine you have to restart the client because it does not
reconnect.

This bug in onwcloud-client is caused by a bug in QT. The upstream
bugreport is https://bugreports.qt.io/browse/QTBUG-46323.

There is a patch merged upstream, but it's not in any released version
yet: https://codereview.qt-project.org/#/c/121724/

I locally compiled QT with the fix applied and can confirm that this
fixes the oncloud-client issue for me. To be able to apply the patch I
had to pull in a second patch as a dependency:
https://bugreports.qt.io/browse/QTBUG-47471
https://codereview.qt-project.org/#/c/123087/2

The patch to the Debian package I used is attached. Thanks for
considering this until a fixed version is released upstream. It fixes a
very annoying bug in owncloud-client.

Gaudenz

From bf47964d9f8902dbdaae310786ae8118e2d20fb0 Mon Sep 17 00:00:00 2001
From: Gaudenz Steinlin 
Date: Mon, 16 Nov 2015 15:31:37 +0100
Subject: [PATCH] Add patches to fix QT bugs #46323 and #47471

Closes: #804883
---
 debian/patches/qtbug-46323.patch | 233 +++
 debian/patches/qtbug-47471.patch | 146 
 debian/patches/series|   4 +
 3 files changed, 383 insertions(+)
 create mode 100644 debian/patches/qtbug-46323.patch
 create mode 100644 debian/patches/qtbug-47471.patch

diff --git a/debian/patches/qtbug-46323.patch b/debian/patches/qtbug-46323.patch
new file mode 100644
index 000..fcc444e
--- /dev/null
+++ b/debian/patches/qtbug-46323.patch
@@ -0,0 +1,233 @@
+From bb281eea179d50a413f4ec1ff172d27ee48d3a41 Mon Sep 17 00:00:00 2001
+From: Lorn Potter 
+Date: Fri, 17 Jul 2015 15:32:23 +1000
+Subject: [PATCH] Make sure networkAccessibilityChanged is emitted
+
+Task-number: QTBUG-46323
+Change-Id: I8297072b62763136f457ca6ae15282d1c22244f4
+Reviewed-by: Timo Jyrinki 
+Reviewed-by: Alex Blasche 
+---
+ src/network/access/qnetworkaccessmanager.cpp   | 70 +++---
+ src/network/access/qnetworkaccessmanager_p.h   | 14 -
+ .../tst_qnetworkaccessmanager.cpp  | 31 +-
+ 3 files changed, 77 insertions(+), 38 deletions(-)
+
+diff --git a/src/network/access/qnetworkaccessmanager.cpp b/src/network/access/qnetworkaccessmanager.cpp
+index 84931cb..f9e9513 100644
+--- a/src/network/access/qnetworkaccessmanager.cpp
 b/src/network/access/qnetworkaccessmanager.cpp
+@@ -278,7 +278,8 @@ static void ensureInitialized()
+ 
+ \snippet code/src_network_access_qnetworkaccessmanager.cpp 4
+ 
+-Network requests can be reenabled again by calling
++Network requests can be re-enabled again, and this property will resume to
++reflect the actual device state by calling
+ 
+ \snippet code/src_network_access_qnetworkaccessmanager.cpp 5
+ 
+@@ -467,16 +468,12 @@ QNetworkAccessManager::QNetworkAccessManager(QObject *parent)
+ qRegisterMetaType >();
+ 
+ #ifndef QT_NO_BEARERMANAGEMENT
+-if (!d->networkSessionRequired) {
+-// if a session is required, we track online state through
+-// the QNetworkSession's signals
+-connect(&d->networkConfigurationManager, SIGNAL(onlineStateChanged(bool)),
+-SLOT(_q_onlineStateChanged(bool)));
+-}
+-// we would need all active configurations to check for
+-// d->networkConfigurationManager.isOnline(), which is asynchronous
+-// and potentially expensive. We can just check the configuration here
+-d->online = (d->networkConfiguration.state() & QNetworkConfiguration::Active);
++// if a session is required, we track online state through
++// the QNetworkSession's signals if a request is already made.
++// we need to track current accessibility state by default
++//
++connect(&d->networkConfigurationManager, SIGNAL(onlineStateChanged(bool)),
++SLOT(_q_onlineStateChanged(bool)));
+ #endif
+ }
+ 
+@@ -946,7 +943,8 @@ QNetworkConfiguration QNetworkAccessManager::activeConfiguration() const
+ void QNetworkAccessManager::setNetworkAccessible(QNetworkAccessManager::NetworkAccessibility accessible)
+ {
+ Q_D(QNetworkAccessManager);
+-d->defaultAccessControl = false;
++
++d->defaultAccessControl = accessible == NotAccessible ? false : true;
+ 
+ if (d->networkAccessible != accessible) {
+ NetworkAccessibility previous = networkAccessible();
+@@ -965,6 +963,10 @@ void QNetworkAccessManager::setNetworkAccessible(QNetworkAccessManager::NetworkA
+ QNetwork

Bug#804883: QNAM does not report correct NetworkAccessibility (was: Regression: OwnCloud client fails to reconnect when network starts up)

[Gaudenz Steinlin]

Control: reassign -1 qtbase-opensource-src
Control: affects -1 owncloud-client
Control: tags -1 +patch

Hi

Some context for the QT maintainers: This is about a bug in
owncloud-client which fails to reconnect to the server if the network
connection is lost. This is quite annoying because after every suspend
of your machine you have to restart the client because it does not
reconnect.

This bug in onwcloud-client is caused by a bug in QT. The upstream
bugreport is https://bugreports.qt.io/browse/QTBUG-46323.

There is a patch merged upstream, but it's not in any released version
yet: https://codereview.qt-project.org/#/c/121724/

I locally compiled QT with the fix applied and can confirm that this
fixes the oncloud-client issue for me. To be able to apply the patch I
had to pull in a second patch as a dependency:
https://bugreports.qt.io/browse/QTBUG-47471
https://codereview.qt-project.org/#/c/123087/2

The patch to the Debian package I used is attached. Thanks for
considering this until a fixed version is released upstream. It fixes a
very annoying bug in owncloud-client.

Gaudenz
From bf47964d9f8902dbdaae310786ae8118e2d20fb0 Mon Sep 17 00:00:00 2001
From: Gaudenz Steinlin 
Date: Mon, 16 Nov 2015 15:31:37 +0100
Subject: [PATCH] Add patches to fix QT bugs #46323 and #47471

Closes: #804883
---
 debian/patches/qtbug-46323.patch | 233 +++
 debian/patches/qtbug-47471.patch | 146 
 debian/patches/series|   4 +
 3 files changed, 383 insertions(+)
 create mode 100644 debian/patches/qtbug-46323.patch
 create mode 100644 debian/patches/qtbug-47471.patch

diff --git a/debian/patches/qtbug-46323.patch b/debian/patches/qtbug-46323.patch
new file mode 100644
index 000..fcc444e
--- /dev/null
+++ b/debian/patches/qtbug-46323.patch
@@ -0,0 +1,233 @@
+From bb281eea179d50a413f4ec1ff172d27ee48d3a41 Mon Sep 17 00:00:00 2001
+From: Lorn Potter 
+Date: Fri, 17 Jul 2015 15:32:23 +1000
+Subject: [PATCH] Make sure networkAccessibilityChanged is emitted
+
+Task-number: QTBUG-46323
+Change-Id: I8297072b62763136f457ca6ae15282d1c22244f4
+Reviewed-by: Timo Jyrinki 
+Reviewed-by: Alex Blasche 
+---
+ src/network/access/qnetworkaccessmanager.cpp   | 70 +++---
+ src/network/access/qnetworkaccessmanager_p.h   | 14 -
+ .../tst_qnetworkaccessmanager.cpp  | 31 +-
+ 3 files changed, 77 insertions(+), 38 deletions(-)
+
+diff --git a/src/network/access/qnetworkaccessmanager.cpp b/src/network/access/qnetworkaccessmanager.cpp
+index 84931cb..f9e9513 100644
+--- a/src/network/access/qnetworkaccessmanager.cpp
 b/src/network/access/qnetworkaccessmanager.cpp
+@@ -278,7 +278,8 @@ static void ensureInitialized()
+ 
+ \snippet code/src_network_access_qnetworkaccessmanager.cpp 4
+ 
+-Network requests can be reenabled again by calling
++Network requests can be re-enabled again, and this property will resume to
++reflect the actual device state by calling
+ 
+ \snippet code/src_network_access_qnetworkaccessmanager.cpp 5
+ 
+@@ -467,16 +468,12 @@ QNetworkAccessManager::QNetworkAccessManager(QObject *parent)
+ qRegisterMetaType >();
+ 
+ #ifndef QT_NO_BEARERMANAGEMENT
+-if (!d->networkSessionRequired) {
+-// if a session is required, we track online state through
+-// the QNetworkSession's signals
+-connect(&d->networkConfigurationManager, SIGNAL(onlineStateChanged(bool)),
+-SLOT(_q_onlineStateChanged(bool)));
+-}
+-// we would need all active configurations to check for
+-// d->networkConfigurationManager.isOnline(), which is asynchronous
+-// and potentially expensive. We can just check the configuration here
+-d->online = (d->networkConfiguration.state() & QNetworkConfiguration::Active);
++// if a session is required, we track online state through
++// the QNetworkSession's signals if a request is already made.
++// we need to track current accessibility state by default
++//
++connect(&d->networkConfigurationManager, SIGNAL(onlineStateChanged(bool)),
++SLOT(_q_onlineStateChanged(bool)));
+ #endif
+ }
+ 
+@@ -946,7 +943,8 @@ QNetworkConfiguration QNetworkAccessManager::activeConfiguration() const
+ void QNetworkAccessManager::setNetworkAccessible(QNetworkAccessManager::NetworkAccessibility accessible)
+ {
+ Q_D(QNetworkAccessManager);
+-d->defaultAccessControl = false;
++
++d->defaultAccessControl = accessible == NotAccessible ? false : true;
+ 
+ if (d->networkAccessible != accessible) {
+ NetworkAccessibility previous = networkAccessible();
+@@ -965,6 +963,10 @@ void QNetworkAccessManager::setNetworkAccessible(QNetworkAccessManager::NetworkA
+ QNetworkAccessManager::NetworkAccessibility QNetworkAccessManager::networkAccessible() const
+ {
+ Q_D(const QNetworkAccessManager);
++
++if (d->networkConfiguration.state().

Bug#803669: Breaks QProcess in owncloud-client tests on mips an mipsel

[Gaudenz Steinlin]

Hi

Dmitry Shachnev  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]

Gaudenz Steinlin  writes:

> Lisandro Damián Nicanor Pérez Meyer  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

[Gaudenz Steinlin]

Lisandro Damián Nicanor Pérez Meyer  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

[Gaudenz Steinlin]

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&arch=mipsel&ver=2.0.2%2Bdfsg-1&stamp=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#801572: [buildd-tools-devel] Bug#801572: sbuild-update -u not saved

[Gaudenz Steinlin]

And here goes the attachment...

D: Setting Config=Sbuild::ConfBase=HASH(0x2668058)
D: Setting Session ID=
D: Setting Chroot ID=/
D: Setting Defaults=HASH(0x3851e00)
D: Setting Split=1
D: Setting Split=0
D: Setting Config=Sbuild::ConfBase=HASH(0x2668058)
D: Setting Chroots=HASH(0x3868008)
Found schroot chroot: :jessie-amd64
  Aliases 
  Location 
  Name jessie-amd64
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :jessie-amd64-local
  Aliases 
  Location 
  Name jessie-amd64-local
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :jessie-amd64-local-tmpfs
  Aliases 
  Location 
  Name jessie-amd64-local-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :jessie-amd64-tmpfs
  Aliases 
  Location 
  Name jessie-amd64-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :jessie-i386
  Aliases 
  Location 
  Name jessie-i386
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :jessie-i386-local
  Aliases 
  Location 
  Name jessie-i386-local
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :jessie-i386-local-tmpfs
  Aliases 
  Location 
  Name jessie-i386-local-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :jessie-i386-tmpfs
  Aliases 
  Location 
  Name jessie-i386-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :sid-amd64
  Aliases 
  Location 
  Name sid-amd64
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :sid-amd64-local
  Aliases 
  Location 
  Name sid-amd64-local
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :sid-amd64-local-tmpfs
  Aliases 
  Location 
  Name sid-amd64-local-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :sid-amd64-tmpfs
  Aliases 
  Location 
  Name sid-amd64-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :sid-i386
  Aliases 
  Location 
  Name sid-i386
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :sid-i386-tmpfs
  Aliases 
  Location 
  Name sid-i386-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :squeeze-amd64
  Aliases 
  Location 
  Name squeeze-amd64
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :squeeze-amd64-local
  Aliases 
  Location 
  Name squeeze-amd64-local
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :squeeze-amd64-tmpfs
  Aliases 
  Location 
  Name squeeze-amd64-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :squeeze-amd64-tmpfs-local
  Aliases 
  Location 
  Name squeeze-amd64-tmpfs-local
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-amd64
  Aliases 
  Location 
  Name wheezy-amd64
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-amd64-local
  Aliases 
  Location 
  Name wheezy-amd64-local
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-amd64-local-tmpfs
  Aliases 
  Location 
  Name wheezy-amd64-local-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-amd64-tmpfs
  Aliases 
  Location 
  Name wheezy-amd64-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-i386
  Aliases 
  Location 
  Name wheezy-i386
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-i386-local
  Aliases 
  Location 
  Name wheezy-i386-local
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-i386-local-tmpfs
  Aliases 
  Location 
  Name wheezy-i386-local-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-i386-tmpfs
  Aliases 
  Location 
  Name wheezy-i386-tmpfs
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :jessie-amd64
  Aliases 
  Location 
  Name jessie-amd64
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :jessie-i386
  Aliases 
  Location 
  Name jessie-i386
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :sid-amd64
  Aliases 
  Location 
  Name sid-amd64
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :sid-i386
  Aliases 
  Location 
  Name sid-i386
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :squeeze-amd64
  Aliases 
  Location 
  Name squeeze-amd64
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-amd64
  Aliases 
  Location 
  Name wheezy-amd64
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-amd64-local
  Aliases 
  Location 
  Name wheezy-amd64-local
  Namespace 
  Priority 0
  Session Purged 0
Found schroot chroot: :wheezy-i386
  Aliases 
  Location 
  Name wheezy-i386
  Namespace 
  Priority 0
  Session Purged 0
D: Setting Chroots=HASH(0x3871b98)
D: Setting Config=Sbuild::ConfBase=HASH(0x2668058)
D: Setting Session ID=
D: Setting Chroot ID=chroot:sid-amd64
D: Setting Defaults=HASH(0x38522f8)
D: Setting Chroots=Sbuild::ChrootInfoSchroot=HASH(0x3867f30)

Bug#801572: [buildd-tools-devel] Bug#801572: sbuild-update -u not saved

[Gaudenz Steinlin]

Hi

Raphael Hertzog  writes:

> Hi,
>
> On Mon, 12 Oct 2015, Jérémy Lal wrote:
>> doing sbuild-update -udcar sid-amd64-sbuild
>> does update some packages.
>> If i do it again, it does the same thing.
>> Same for just -u.
>> This is not happening with sbuild 0.65.2-1.1.
>>
>> [sid-amd64-sbuild]
>> type=directory
>> union-type=overlay
>
> You are asking for an "overlay" chroot, so you want to update the source
> of the chroot, not the chroot itself.
>
> The correct command to use was always “sbuild-update [options]
> source:sid-amd64-sbuild”.
>
> At least that's my understanding and what my own chroot update scripts
> have been doing for ages.

I just ran into the same problem and this does not solve it. Attached is the
debug output (std output and error) from running sbuild-update with the
following command:
/usr/bin/sbuild-update -u source:sid-amd64 --debug
  ^^

If I rerun the same command again it downloads the same pdiffs again, so
apparently the source chroot was not updated. The same happens when
updating packages with -d or -g. The packages are installed, but not
into the source chroot.

sbuild-update seems to use a non source:* chroot even if asked to do so.
I can also confirm this by the fact that it creates an LVM snapshot for
the chroot session. My chroots are LVM snapshot based:

[sid-amd64]
type=lvm-snapshot
device=/dev/moebius/sid-amd64-chroot
lvm-snapshot-options=--size 2G
description=Debian sid/amd64 autobuilder
groups=root,sbuild
root-groups=root,sbuild
source-root-groups=root,sbuild
command-prefix=/var/cache/ccache-sbuild/sbuild-setup,eatmydata

This used to work in the past even without the explicit "source:"
qualifier. But it should at least work with it.

Gaudenz


signature.asc
Description: PGP signature

Bug#801477: [Ceph-maintainers] Bug#801477: ceph: FTBFS on armel: common/RWLock.h:29:11: error: 'atomic_t' does not name a type

[Gaudenz Steinlin]

Hi

Emilio Pozuelo Monfort  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&arch=armel&ver=0.80.10-1&stamp=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#800756: [Ceph-maintainers] Bug#800756: Your message to Ceph-maintainers awaits moderator approval

[Gaudenz Steinlin]

Hi

Emilio Pozuelo Monfort  writes:

> Source: ceph
> Severity: serious
>
> Hi,
>
> Policy 3.3 says:
>
> "The email address given in the Maintainer control field must accept mail from
> those role accounts in Debian used to send automated mails regarding the
> package. This includes non-spam mail from the bug-tracking system, all mail 
> from
> the Debian archive maintenance software, and other role accounts or automated
> processes that are commonly agreed on by the project."

This has already been reported as #760538. I just merged the reports.
Unfortunately there is not much I can do about this at the moment short
of changing the maintainer adress away from the common ceph-maintainers
list which includes the package maintainers for ceph of most Linux
distributions. Having this as the the maintainer address proved to be
very usefull as it allows upstream and other distro maintainers to chime
in on bug reports that are not purely Debian specific.

As discussed in #760538 it also at least contentious if a moderated list
violates paragraph 3.3. of the Debian Policy as it does accept these
mails, they are just not forwarded to list subscribers until manual
approval. The list does not reject those mails.

I myself would prefer a setup where mail from the Debian BTS and FTP
Masters would be exempt from moderation. Is there an example mailman
configuration I can forward to the list owners? Or ist there a canonical
list of sender addresses? This would greatly help resolve this issue.

Gaudenz

Bug#795178: fixed in ceph 0.94.3-1

[Gaudenz Steinlin]

Emilio Pozuelo Monfort  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  
> 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#800400: ITP: ruby-puppet-syntax -- Syntax checks for Puppet manifests, templates, and Hiera YAML

[Gaudenz Steinlin]

Package: wnpp
Severity: wishlist
Owner: Gaudenz Steinlin 

* Package name: ruby-puppet-syntax
  Version : 2.0.0
  Upstream Author : Dan Carley
* URL : https://github.com/gds-operations/puppet-syntax
* License : Expat
  Programming Lang: Ruby
  Description : Syntax checks for Puppet manifests, templates, and Hiera 
YAML

 Puppet lets you centrally manage every important aspect of your
 system using a cross-platform specification language that manages all
 the separate elements normally aggregated in different files, like
 users, cron jobs, and hosts, along with obviously discrete elements
 like packages, services, and files.
 . 
 This ruby module provides syntax checks for Puppet manifests,
 templates and Hiera YAML.

 I intend to maintain this as part of the Ruby Extras Maintainer Team.

Bug#799976: wish: support passwd/root-login=false AND passwd/make-user=false

[Gaudenz Steinlin]

Lennart Sorensen  writes:

> On Thu, Sep 24, 2015 at 11:50:59PM +0200, Simon Josefsson wrote:
>> Package: debian-installer
>> Severity: wishlist
>> 
>> On some system that I preseed-install, I don't want any root password
>> set nor do I want a normal user account.  I get access to the system via
>> SSH, using a public-key that I populate using a late_command.
>
> So you want a system that you can not fix if it needs to prompt for a
> root password to manually run fsck?  There are after all a few times
> where being able to login as root directly on the console is required.
> Not allowing ssh with a pasword as root is a good diea (and the default
> these days), but that does not mean you don't still need a root
> password.

This is not true. If you boot a system with a disabled root account into
single user mode this is detected and you get a root shell without
entering a password. At least for jessie and earlier systems. See man
sulogin. For testing and up the manpages says that the --force option to
sulogin is needed for this, but this is not invoked by sysvinit or the
systemd emergency service.

And if everything else fails, you can still use init=/bin/bash as long
as you have console and boot loader access.

Gaudenz


signature.asc
Description: PGP signature

Bug#799976: wish: support passwd/root-login=false AND passwd/make-user=false

[Gaudenz Steinlin]

Simon Josefsson  writes:

>> Simon Josefsson  writes:
>> 
>> > Package: debian-installer
>> > Severity: wishlist
>> >
>> > On some system that I preseed-install, I don't want any root
>> > password set nor do I want a normal user account.  I get access to
>> > the system via SSH, using a public-key that I populate using a
>> > late_command.
>> 
>> If you want a work-around for this in the meantime, have a look at:
>> 
>>   http://hands.com/d-i/jessie/start.cfg
>>   http://hands.com/d-i/jessie/classes/late_script
>> 
>> and search for ERASEME
>> 
>> I preseed the crypted password, which satisfies the scripting, and
>> then blank it in the late script if it's still set to the magic
>> string.
>
> Nice trick, thanks for sharing.  I still believe it would be useful to
> support this behaviour out of the box, it should be what most people
> preseeding machines that never will be used through a console wants.

This is already supported but probably not documented. Just use the
following settings in your preseed file:

d-i passwd/make-user boolean false
d-i passwd/root-password-crypted password *

This sets the entry for root in /etc/shadow to '*' which effectively
means the password is disabled. You can still log in with an ssh key
though.

Gaudenz


signature.asc
Description: PGP signature

Bug#798567: [Ceph-maintainers] jessie-pu: package ceph/0.80.9-2 (pre approval)

[Gaudenz Steinlin]

Hi debian-release

Gaudenz Steinlin  writes:

> Gaudenz Steinlin  writes:
>> I'd like to update ceph in jessie to the latest upstream bugfix release.
>> The version of ceph in jessie is a long term support (LTS) release which
>> will receive updates at least until January 2016. Updates will be bugfix
>> only. New features go into new release which are developed in parallel.
>> See at the end of this report for the upstream changelog.
>>
>> See http://ceph.com/docs/master/releases/ for the ceph release timeline
>> and support statement.
>>
>
> Just as an additional data point, Ubuntu has a "Minor Release Exception"
> for stable updates for their ceph package [1].

In the meantime another stable point release of ceph 0.80 (0.80.10) was
released and on top of that there is a (minor) security issue which
won't be fixed through a security update but which would be nice to fix
by a stable update (see bug #798567 / CVE-2015-5245)).

As another stable update has passed, it would be nice if someone of the
stable release team could comment on this and eventually decide if they
are OK with the proposal to follow the ceph stable branch or if they
don't like it and would prefer an update just fixing the security bug.
It would be nice to have a decision soon, so that there is enough time
to prepare and test the update for the next stable point release.

Gaudenz

Bug#798567: [Ceph-maintainers] Bug#798567: Bug#798567: ceph: CVE-2015-5245: Rados rest gateway returns requested bucket name raw in Bucket response header

[Gaudenz Steinlin]

Hi

Gaudenz Steinlin  writes:

> Hi
>
> Salvatore Bonaccorso  writes:
>
>> Source: ceph
>> Version: 0.80.7-2
>> Severity: important
>> Tags: security upstream
>> Forwarded: http://tracker.ceph.com/issues/12537
>>
>> Hi,
>>
>> the following vulnerability was published for ceph.
>>
>> CVE-2015-5245[0]:
>> Ceph: Rados rest gateway returns requested bucket name raw in Bucket 
>> response header
>>
>> If you fix the vulnerability please also make sure to include the
>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>>
>> For further information see:
>>
>> [0] https://security-tracker.debian.org/tracker/CVE-2015-5245
>> [1] http://tracker.ceph.com/issues/12537
>
> I fail to see how this is a security issue. It's clearly a bug, but
> AFAICS you can only shoot yourself in the foot with it. There is no
> explanation in the upstream issue tracker why this was assigned a CVE
> ID. But as I'm by no means an expert on these issues I would appreciate
> someone else looking at this. Do other distros plan an update for this?
>
> If my assessment is correct I think we can fix this with a stable
> update. I already tried to convince the stable release team to allow
> minor updates to stable. See #784373. A backport to the stable firefly
> branch (which is in Debian stable) is in progress upstream.

I'm a bit lost on the status of this bug. Do I interpret
https://security-tracker.debian.org/tracker/source-package/ceph right in
that this means the security team thinks this does not warrant a DSA? Or
does this just mean that no DSA has been issued yet?

I'm still a bit unsure about the severity of this issue. As far as I
understand it, an attacker would have to trick someone into requesting a
specially crafted bucket name. How realistic is this in the context of
the RADOS gateway?

I prepared an update which fixes this bug for stable. If the security
team want's to issue a DSA I can upload this. I alos attached the patch
to this mail, in case you want to do an upload yourself. If the security
team does not want to issue a DSA please say so, I'll then try to get
this fixed by a stable update.

Gaudenz

commit 61b5e0389099bab8bcd196a76eb7a66cb6f5c63e
Author: Gaudenz Steinlin 
Date:   Fri Sep 11 10:27:26 2015 +0200

Patch to fix CVE-2015-5245 applied from upstream

Refreshed the patch to apply onto the firefly sources and to only
contain the chages to fix the vulnerability.

Closes: #798567

diff --git a/debian/patches/CVE-2015-5245.patch b/debian/patches/CVE-2015-5245.patch
new file mode 100644
index 000..c929c0e
--- /dev/null
+++ b/debian/patches/CVE-2015-5245.patch
@@ -0,0 +1,35 @@
+From ad5507fe0bf72ed5bdf8353e315cc9092c740144 Mon Sep 17 00:00:00 2001
+From: Yehuda Sadeh 
+Date: Thu, 30 Jul 2015 14:47:15 -0700
+Subject: [PATCH] rgw: url encode exposed bucket
+
+Fixes: #12537
+Don't send the bucket name back without url encoding it.
+
+Signed-off-by: Yehuda Sadeh 
+
+The patch below is an adapted version for ceph 0.80.7 to only contain
+the necessary changes to fix this vulnerability. Neither the quoting 
+of the bucket name nor the missing \r are fixed.
+(see http://tracker.ceph.com/issues/9254 and http://tracker.ceph.com/issues/11860)
+
+---
+ src/rgw/rgw_rest.cc | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/src/rgw/rgw_rest.cc
 b/src/rgw/rgw_rest.cc
+@@ -272,8 +272,11 @@
+ {
+   int expose_bucket = g_conf->rgw_expose_bucket;
+   if (expose_bucket) {
+-if (!s->bucket_name_str.empty())
+-  s->cio->print("Bucket: \"%s\"\n", s->bucket_name_str.c_str());
++if (!s->bucket_name_str.empty()) {
++  string b;
++  url_encode(s->bucket_name_str, b);
++  s->cio->print("Bucket: \"%s\"\n", b.c_str());
++}
+   }
+ }
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 8625fda..8ac47ad 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -14,6 +14,7 @@ backfill-prio.patch
 bash-completion.patch
 rbdmap1-mount.patch
 rbdmap2-hooks.patch
+CVE-2015-5245.patch
 
 ## Debian
 rbdmap3-lazyumount.patch


signature.asc
Description: PGP signature

Bug#797962: [PKG-Openstack-devel] Bug#797962: Bug#797962: Bug#797962: openstack-debian-images: Built images do not include aptitude

[Gaudenz Steinlin]

Control: -1 +patch


Thomas Goirand  writes:

> On 09/17/2015 06:36 PM, Gaudenz Steinlin wrote:
>> Michael Fincham  writes:
>> 
>>> Package: openstack-debian-images
>>> Version: 1.4
>>> Severity: normal
>>>
>>> Dear maintainer,
>>>
>>> Previously the phrase "Aptitude is the current preferred package management 
>>> tool for the Debian system." appeared in the Debian documentation.
>>>
>>> Is the omission of aptitude from the images built by
>>> openstack-debian-image an accident? If so, can it be added?
>> 
>> "Unfortunately" Thomas already went ahead and added aptitude to the
>> image. You don't say which documentation you are refering to. Is this
>> current documentation for jessie from Debian? If so it should be fixed.
>> 
>> Aptitude is not part of the Debian default install anymore and thus
>> should not be part of the OpenStack images either. Thomas would you
>> consider removing it again?
>
> Yes, I would. But I have no time to work on this, and I also consider
> this a very minor issue (and frankly, I don't care that much about it).
> So I very much would welcome anyone to do the work and fix. Do you want
> to do it, Gaudenz?

Patch attached. If you give me permission, I can also push this directly
to the repo.

Gaudenz
From 2d3413e043dd3c8bc7a45470923d41fe550d2474 Mon Sep 17 00:00:00 2001
From: Gaudenz Steinlin 
Date: Fri, 18 Sep 2015 16:33:25 +0200
Subject: [PATCH] Remove aptitude from package list

It's not installed by debootstrap by default and the cloud images should
be as similar to a normal Debian install as possible. There is no need
for two package managers in cloud images.
---
 build-openstack-debian-image | 2 +-
 debian/changelog | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/build-openstack-debian-image b/build-openstack-debian-image
index b850e04..7d2fa36 100755
--- a/build-openstack-debian-image
+++ b/build-openstack-debian-image
@@ -158,7 +158,7 @@ if [ -z "${USER_LOGIN}" ] ; then
 	USER_LOGIN=debian
 fi
 
-NEEDED_PACKAGES=sudo,adduser,locales,extlinux,openssh-server,linux-image-amd64,euca2ools,file,kbd,aptitude
+NEEDED_PACKAGES=sudo,adduser,locales,extlinux,openssh-server,linux-image-amd64,euca2ools,file,kbd
 if [ "${RELEASE}" = "wheezy" ] ; then
 	# These are needed by cloud-init and friends, and since we don't want backports of them,
 	# but just normal packages from Wheezy, we resolve dependencies by hand, prior to using
diff --git a/debian/changelog b/debian/changelog
index b96faaf..716bd46 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+openstack-debian-images (1.7) UNRELEASED; urgency=medium
+
+  * Remove aptitude from package list. It's not installed by default by
+debootstrap.
+
+ -- Gaudenz Steinlin   Fri, 18 Sep 2015 16:32:11 +0200
+
 openstack-debian-images (1.6) unstable; urgency=medium
 
   * Added aptitude as installed packages. (Closes: #797962)
-- 
2.5.1



signature.asc
Description: PGP signature

Bug#797962: [PKG-Openstack-devel] Bug#797962: openstack-debian-images: Built images do not include aptitude

[Gaudenz Steinlin]

Hi

Michael Fincham  writes:

> Hi Gaudenz,
>
> I should have been more verbose in my original report :)
>
> On Thu, 17 Sep 2015 18:36:55 +0200, Gaudenz Steinlin  
> wrote:
>>  You don't say which documentation you are refering to. Is this
>> current documentation for jessie from Debian? If so it should be fixed.
>
> When I said "previously" I meant:
>
> From at least some time in 2006/2007 until August of 2010, 
> <https://www.debian.org/doc/manuals/debian-reference/ch02.en.html> contained 
> the phrase (I've just checked this with archive.org).
>
> Some of us who made the switch to aptitude when this was the advice
> have just continued using it - it was only recently I discovered that
> the recommendation has changed to apt-get.

Also to be clear, there is nothing wrong with using aptitude. I use it
myself. This bug is just about which package manager should be installed
in the official Debian OpenStack image.

>
>> Aptitude is not part of the Debian default install anymore and thus
>> should not be part of the OpenStack images either.
>
> I've just installed a fresh Jessie VM with all the defaults and it
> does still come with aptitude installed, thus my surprise that it was
> missing from the cloud image.

By Jessie VM you mean you used the debian-installer to install into a
traditional VM, not the cloud image, right? Then it depends if you
select the "Standard system" task or not (which is selected by default).
The standard system on jessie still contains aptitude, but the cloud
image does not install this task. As it's meant to be as small as
possible it only contains what debootstrap installs.

Gaudenz


signature.asc
Description: PGP signature

Bug#797962: [PKG-Openstack-devel] Bug#797962: openstack-debian-images: Built images do not include aptitude

[Gaudenz Steinlin]

Michael Fincham  writes:

> Package: openstack-debian-images
> Version: 1.4
> Severity: normal
>
> Dear maintainer,
>
> Previously the phrase "Aptitude is the current preferred package management 
> tool for the Debian system." appeared in the Debian documentation.
>
> Is the omission of aptitude from the images built by
> openstack-debian-image an accident? If so, can it be added?

"Unfortunately" Thomas already went ahead and added aptitude to the
image. You don't say which documentation you are refering to. Is this
current documentation for jessie from Debian? If so it should be fixed.

Aptitude is not part of the Debian default install anymore and thus
should not be part of the OpenStack images either. Thomas would you
consider removing it again?

More so I don't think it's a good idea to have more than one package
management tool in a cloud image which should by definitiion be as small
as possible. If you prefer aptitude it's just an apt-get away, so very
easy to install.

Gaudenz


signature.asc
Description: PGP signature

Bug#798567: [Ceph-maintainers] Bug#798567: ceph: CVE-2015-5245: Rados rest gateway returns requested bucket name raw in Bucket response header

[Gaudenz Steinlin]

Hi

Salvatore Bonaccorso  writes:

> Source: ceph
> Version: 0.80.7-2
> Severity: important
> Tags: security upstream
> Forwarded: http://tracker.ceph.com/issues/12537
>
> Hi,
>
> the following vulnerability was published for ceph.
>
> CVE-2015-5245[0]:
> Ceph: Rados rest gateway returns requested bucket name raw in Bucket response 
> header
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2015-5245
> [1] http://tracker.ceph.com/issues/12537

I fail to see how this is a security issue. It's clearly a bug, but
AFAICS you can only shoot yourself in the foot with it. There is no
explanation in the upstream issue tracker why this was assigned a CVE
ID. But as I'm by no means an expert on these issues I would appreciate
someone else looking at this. Do other distros plan an update for this?

If my assessment is correct I think we can fix this with a stable
update. I already tried to convince the stable release team to allow
minor updates to stable. See #784373. A backport to the stable firefly
branch (which is in Debian stable) is in progress upstream.

Gaudenz


signature.asc
Description: PGP signature

Bug#798323: Building for i386 on amd64 tries to install amd64 packages into i386 chroot

[Gaudenz Steinlin]

Package: sbuild
Version: 0.65.2-1.1
Severity: important

Hi

The sbuild NMU to experimental broke building packages for i386 on an
amd64 host with an i386 chroot and setting personality=linux32 in the
schroot configuration. sbuild tries to wrongly install
build-essential:amd64 and fakeroot:amd64 into this chroot. It should
instead install i386 packages. See the attached build log for details.
Downgrading to the sbuild 0.65.2-1 fixes the problem.

I guess the problem is caused by some of the fixes for cross build
support which went into the NMU.

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.1.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 sbuild depends on:
ii  adduser 3.113+nmu3
ii  apt-utils   1.0.10.2
ii  libsbuild-perl  0.65.2-1
ii  perl5.20.2-6

Versions of packages sbuild recommends:
ii  debootstrap  1.0.72
ii  fakeroot 1.20.2-1

Versions of packages sbuild suggests:
pn  deborphan  
ii  wget   1.16.3-3

-- Configuration Files:
/etc/sbuild/sbuild.conf changed:
$build_arch_all = 1;
$build_source = 1;
$run_lintian = 1;
$purge_build_directory = 'successful';
$purge_session = 'successful';
1;


-- no debconf information
sbuild (Debian sbuild) 0.65.2 (24 Mar 2015) on moebius.durcheinandertal.private

╔══╗
║ owncloud-client 2.0.0+dfsg-1~bpo8+1 (i386) 08 Sep 2015 00:18 ║
╚══╝

Package: owncloud-client
Version: 2.0.0+dfsg-1~bpo8+1
Source Version: 2.0.0+dfsg-1~bpo8+1
Distribution: jessie-backports
Machine Architecture: amd64
Host Architecture: i386
Build Architecture: i386

I: NOTICE: Log filtering will replace 
'build/owncloud-client-pLFbSI/owncloud-client-2.0.0+dfsg' with '«PKGBUILDDIR»'
I: NOTICE: Log filtering will replace 'build/owncloud-client-pLFbSI' with 
'«BUILDDIR»'
I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/jessie-i386-42fc61d4-1d1f-4d26-8660-ba04a5cffb6c' with 
'«CHROOT»'

┌──┐
│ Update chroot│
└──┘

Ign http://localhost: jessie InRelease
Hit http://localhost: jessie Release.gpg
Hit http://localhost: jessie Release
Hit http://localhost: jessie/main Sources
Hit http://localhost: jessie/main i386 Packages
Hit http://localhost: jessie/main Translation-en
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

┌──┐
│ Fetch source files   │
└──┘


Local sources
─

/home/gaudenz/debian/owncloud/owncloud-client_2.0.0+dfsg-1~bpo8+1.dsc exists in 
/home/gaudenz/debian/owncloud; copying to chroot

Check architectures
───


Check dependencies
──

Merged Build-Depends: build-essential:amd64, fakeroot:amd64
Filtered Build-Depends: build-essential:amd64, fakeroot:amd64
dpkg-deb: building package `sbuild-build-depends-core-dummy' in 
`/«BUILDDIR»/resolver-H1NAEB/apt_archive/sbuild-build-depends-core-dummy.deb'.
OK
Ign file: ./ InRelease
Get:1 file: ./ Release.gpg [299 B]
Get:2 file: ./ Release [2119 B]
Ign file: ./ Translation-en
Reading package lists...
Reading package lists...

┌──┐
│ Install core build dependencies (apt-based resolver) │
└──┘

Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 sbuild-build-depends-core-dummy : Depends: build-essential:amd64 but it is not 
installable
   Depends: fakeroot:amd64 but it is not 
installable
E: Unable to correct problems, you have held broken packages.
apt-get failed.
Package installat

Bug#798260: Don't buffer terminal output in post_upload_command

[Gaudenz Steinlin]

Package: dput-ng
Version: 1.10
Severity: wishlist

I use dput-ng to upload packages to a custom reprepro managed
repository. This repository uses a repository key protected by a
password. I configured dput-ng to run the following post_upload_command:

ssh -t repre...@packages.lernstick.ch 'reprepro -V -V -b lernstick 
processincoming incoming'

After processing the incoming directory this command asks for the
archive key password to sign the new Release file. But because dput-ng
buffers all terminal output the password prompt is not visible. But it's
possible to blindly type the password and sign the file. After the
command finishes, dput-ng shows the complete command output including
the password prompts.

dput-ng should not buffer the output and display the prompt immediately.

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.1.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 dput-ng depends on:
ii  python-dput  1.10
pn  python:any   

Versions of packages dput-ng recommends:
ii  bash-completion  1:2.1-4.2

dput-ng suggests no packages.

-- no debconf information

Bug#466997: Desktop file still not right

[Gaudenz Steinlin]

Thanks for the prompt fix!

Gaudenz

Gunter Königsmann  writes:

> Thanks for the bug report!
>
> Will fixed it in the next release that will take place in the next few 
> weeks: 
> https://github.com/andrejv/wxmaxima/commit/cb185daafc9163ca8cd5e51cc3c7f374d652986c
>
> Kind regards,
>
> Gunter.

Bug#466997: Desktop file still not right

[Gaudenz Steinlin]

Hi

I'm reopening this ancient bug because the desktop file still leaves
much room for improvement. Please use the attached desktop file which
includes a way to open wxmaxima files and which adds a comment and the
correct Categories.

Gaudenz


wxMaxima.desktop
Description: Binary data

Bug#796965: AttributeError: 'SubDict' object has no attribute 'has_key'

[Gaudenz Steinlin]

Package: obnam
Followup-For: Bug #796965

Fixed: 1.12-1

Hi

This bug has been fixed in version 1.12-1 and is only present if
pure-paramiko is set to true (which is not the default). It's caused by a 
change in
paramiko. The relevant commit in paramiko upstream is this:
https://github.com/paramiko/paramiko/commit/66cfa97cce92b1d60383d178887b18dddb999fc1

This commit causes paramiko to derive SubDict from collections.MutableMapping
instead of UserDict.DictMixin. MutableMapping does not have a has_key
method. The first upstream version to contain this change is paramiko
1.14.0.

The bug might still be a candidate for a stable update, but as it does
not affect the default configuration I'm not sure about this.

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.1.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 obnam depends on:
ii  libc6 2.19-19
ii  python2.7.9-1
ii  python-cliapp 1.20150701-1
ii  python-fuse   2:0.2.1-11
ii  python-larch  1.20131130-1
ii  python-paramiko   1.15.2-1
ii  python-tracing0.8-1
ii  python-ttystatus  0.23-1
ii  python-yaml   3.11-2

obnam recommends no packages.

obnam suggests no packages.

-- no debconf information

Bug#796045: nmu: leveldb_1.18.3

[Gaudenz Steinlin]

Julien Cristau  writes:

> On Tue, Aug 18, 2015 at 21:52:08 +0200, Gaudenz Steinlin wrote:
>
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: binnmu
>> 
>> nmu leveldb_1.18.3 . ALL . unstable . -m "Rebuild for libsnappy transition"
>> 
>> leveldb has already been uploaded for it's own transition before the
>> upload of snappy for it's transition. So leveldb needs another rebuild
>> to be compiled against libsnappy1v5.
>> 
> We don't really want individual requests for binNMUs for g++5 followup
> transitions.  This will be taken care of in due time.

That's fine for me as long as it get's eventually done. I originally
submitted this request because this is a bit a special situation where
leveldb unfortunately did the gcc5 transition rename before all it's
dependencies (namely snappy) were renamed. So leveldb is now that snappy
was renamed uninstallable in sid and needs a binNMU. This currently
makes all dependencies of leveldb FTBS in sid as the build depends can't
be installed. In my case I'd like to verify that ceph is fine for the
gcc5 transition which is currently not possible without building local
packages.

Gaudenz


signature.asc
Description: PGP signature

Bug#731709: EFI support for ISO images

[Gaudenz Steinlin]

Hi

At Lernstick we use the patch attached to create ISO images which boot
on EFI systems. This does not include adding a EFI bootloader to the
image. We do that with config/includes.binary which is of course not a
complete solution.

The debian-cd folks (Steve McIntyre) did a lot of testing to find the
right combination of xorriso options to create an image which boots on
most EFI hardware. Because there are lots of broken implementations out
there.

The patch also adds a dependency on xorriso.

Gaudenz

commit c048047fb581e407db6059bd7de48b36f49a1baf
Author: Gaudenz Steinlin 
Date:   Wed Apr 30 10:50:39 2014 +0200

Option to include an EFI image into ISO images

--efi-boot option to include an EFI boot image as an alternative El
Torrito boot image into the ISO image. This is necessary for booting an
ISO image on most EFI implementations. Booting the ISO image also works
from USB devices when writeing the image directly to the device. The EFI
boot files must be present in binary/efi/boot already. Use a binary hook
or include to copy the files to this directory.

This code is an adaption of similar code present in debian-cd.

diff --git a/functions/defaults.sh b/functions/defaults.sh
index a1040d7..5b93698 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -700,6 +700,9 @@ Set_defaults ()
 		esac
 	fi
 
+	# Setting efi boot
+	LB_EFI_BOOT="${LB_EFI_BOOT:-false}"
+
 	# Setting checksums
 	case "${LB_MODE}" in
 		progress-linux)
diff --git a/manpages/en/lb_config.1 b/manpages/en/lb_config.1
index 4ef252a..2a6557a 100644
--- a/manpages/en/lb_config.1
+++ b/manpages/en/lb_config.1
@@ -41,6 +41,8 @@
 .br
 	[\fB\-\-bootloader\fR grub|grub2|syslinux]
 .br
+	[\fB\-\-efi\-boot\fR true|false]
+.br
 	[\fB\-\-cache\fR true|false]
 .br
 	[\fB\-\-cache\-indices\fR true|false]
@@ -265,6 +267,8 @@ sets boot parameters specific to debian\-installer, if included.
 sets boot parameters specific to debian\-live. A complete list of boot parameters can be found in the \fIlive\-boot\fR(7) and \fIlive\-config\fR(7) manual pages.
 .IP "\fB\-\-bootloader\fR grub|grub2|syslinux" 4
 defines which bootloader is being used in the generated image. This has only an effect if the selected binary image type does allow to choose the bootloader. For example, if you build a iso, always syslinux (or more precise, isolinux) is being used. Also note that some combinations of binary images types and bootloaders may be possible but live\-build does not support them yet. \fBlb config\fR will fail to create such a not yet supported configuration and give a explanation about it. For hdd images on amd64 and i386, the default is syslinux.
+.IP "\fB\-\-efi\-boot\fR true|false" 4
+control if an EFI boot image should be included as an alternate El Torrito image. This is necessary for booting an ISO image under EFI on most implementations. Booting the ISO image also works from USB devices when writeing the image directly to the device. The EFI boot files must be present in binary/efi/boot already. Use a binary hook or include to copy the files to this directory.
 .IP "\fB\-\-cache\fR true|false" 4
 defines globally if any cache should be used at all. Different caches can be controlled through the their own options.
 .IP "\fB\-\-cache\-indices\fR true|false" 4
diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso
index 44a9418..0b0d5db 100755
--- a/scripts/build/binary_iso
+++ b/scripts/build/binary_iso
@@ -144,6 +144,30 @@ case "${LB_BOOTLOADER}" in
 		;;
 esac
 
+if [ "${LB_EFI_BOOT}" = "true" ]
+then
+	XORRISO_VER=$(xorriso --version 2>&1 | awk '
+			/^xorriso version/ {
+split($4, ver, ".")
+print ver[1]*1+ver[2]*100+ver[3]
+			}')
+	# Ugh - different code here depending on the version of xorriso we've got
+	if [ $XORRISO_VER -le 10202 ] ; then
+		# 1.2.2 shipping in Wheezy
+		# Tell xorriso to create a secondary ElTorito boot record for the
+		# EFI bootloader
+		XORRISO_OPTIONS="${XORRISO_OPTIONS} -eltorito-alt-boot --efi-boot efi.img"
+		# Add the efi image as a FAT partition too, so our CD image will
+		# also boot on a USB key (like isohybrid, just implemented
+		# differently)
+		XORRISO_OPTIONS="${XORRISO_OPTIONS} -append_partition 2 0x01 binary/efi.img"
+
+	elif [ $XORRISO_VER -gt 10202 ] ; then
+		XORRISO_OPTIONS="${XORRISO_OPTIONS} -eltorito-alt-boot -e efi.img -no-emul-boot"
+		XORRISO_OPTIONS="${XORRISO_OPTIONS} -isohybrid-gpt-basdat -isohybrid-apm-hfsplus"
+	fi
+fi
+
 #if [ "${LB_DEBIAN_INSTALLER}" != "live" ]
 #then
 #	XORRISO_OPTIONS="${XORRISO_OPTIONS} -m ${XORRISO_EXCLUDE}"
@@ -181,6 +205,34 @@ else
 	echo "#!/bin/sh" > binary.sh
 fi
 
+if [ "${LB_EFI_BOOT}" = "true" ]
+then
+# The code below is adapted from tools/boot/jessie/boot-x

Bug#796045: nmu: leveldb_1.18.3

[Gaudenz Steinlin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu leveldb_1.18.3 . ALL . unstable . -m "Rebuild for libsnappy transition"

leveldb has already been uploaded for it's own transition before the
upload of snappy for it's transition. So leveldb needs another rebuild
to be compiled against libsnappy1v5.

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.1.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)

Bug#795572: getallheaders for php-fpm patch ignores Content-Type and Content-Length headers

[Gaudenz Steinlin]

Package: php5-fpm
Version: 5.6.9+dfsg-0+deb8u1
Severity: normal

The php5 package in Debian carries a patch to add the getallheaders
function to FastCGI (fpm) build. This function is not supported for this
build upstream at all. See
debian/patches/0046-getallheaders-for-php-fpm-62596.patch

This patch works for "normal" headers which are translated to HTTP_XXX
environment variables by PHP, but it does not work for the Content-Type
and Content-Length headers. There is code in the patch that is supposed
to cover this case, but it does not work. The two headers are missing
from the array returned by getallheaders.

Here is sample code to demonstrate the issue.

# cat getallheaders.php


$ POST -U -H "X-DUMMY: my test header" -c text/xml 
http://myserver/getallheaders.php
Please enter content (text/xml) to be POSTed:
adsflkj öalksjdf ölkjasdf
POST https://ubol.ch/getallheaders.php
User-Agent: lwp-request/6.09 libwww-perl/6.13
Content-Length: 28
Content-Type: text/xml
X-DUMMY: my test header

array(5) {
  ["Te"]=>
  string(18) "deflate,gzip;q=0.3"
  ["Connection"]=>
  string(9) "TE, close"
  ["Host"]=>
  string(7) "myserver"
  ["User-Agent"]=>
  string(33) "lwp-request/6.09 libwww-perl/6.13"
  ["X-Dummy"]=>
  string(14) "my test header"
}
array(37) {
[...]
  ["FCGI_ROLE"]=>
  string(9) "RESPONDER"
  ["SCRIPT_URL"]=>
  string(18) "/getallheaders.php"
  ["SCRIPT_URI"]=>
  string(33) "http://myserver/getallheaders.php";
  ["HTTP_TE"]=>
  string(18) "deflate,gzip;q=0.3"
  ["HTTP_CONNECTION"]=>
  string(9) "TE, close"
  ["HTTP_HOST"]=>
  string(7) "ubol.ch"
  ["HTTP_USER_AGENT"]=>
  string(33) "lwp-request/6.09 libwww-perl/6.13"
  ["CONTENT_LENGTH"]=>
  string(2) "28"
  ["CONTENT_TYPE"]=>
  string(8) "text/xml"
  ["HTTP_X_DUMMY"]=>
  string(14) "my test header"
[...]
}

As you can see, the Content-Type and Content-Length headers are being sent and
also end up in the $_SERVER array, but they are not returned by getallheaders.

To be honest I'm not sure if it's a good idea to carry a patch which
changes upstream behavior like this. While it solves the issue for code
that unconditionally calls getallheaders it breaks code (like in my
case) which checks for getallheaders and only uses the function if it
exists. My code was then broken because the getallheaders implementation
was not the same as when running as an Apache module.

I found and investigated this buug on a jessie system, but the patch in
question is the same in the current unstable version of PHP.

Gaudenz