Bug#778747: [Pkg-openssl-devel] Bug#778747: Bug#778747: openssl: RFC 7465 says RC4 is broken, never to be used
❦ 20 février 2015 22:50 +0100, Kurt Roeckx : > Please note that RC4 in the default configuration should never be > negiotated by modern clients and servers. The problem is > administrators who think they know better changed somethign not to > use the defaults. If we adjust the defaults it's not going to fix > anything. Many administrators don't use the defaults because the defaults are most of the time inappropriate for a web server. At some time, RC4 was widely advertised as the preferred cipher because it was immune to BEAST and supported by all browsers from IE6. -- Watch out for off-by-one errors. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#662125: forked-daapd: scans whole DB on startup which takes ages
Control: tags -1 moreinfo Hi Tino, On Sun, 04 Mar 2012 11:21:48 +0100 Tino Keitel wrote: > Package: forked-daapd > Version: 0.19gcd-2 > Severity: normal > > Hi, > > whenever I start forked-daapd it takes several minutes until it gets usable. > > When I start it using the command > > $ forked -f -d 4 -D db,scan,config > > I see thousands of lines like this: > > db: Running query 'SELECT f.id, f.db_timestamp FROM files f WHERE f.path = > '/home/storage2/mp3/music/Tomte/Hinter all diesen Fenstern/08 - > Insecuritate.mp3';' > > It looks like it scans the whole library. There is no high disk usage or CPU > load during this, but it takes a view minutes. Forked-daapd does not react > to ctrl-C or SIGTERM for a while in that situation. When I try to access > forked-daapd using rhythmbox, it takes ~30 seconds to get the available > music. > > I expect forked-daapd to be instantly ready when nothing was changed in the > library, and only scan files that changed since the last DB update, which > should be fast enough. I also expect forked-daapd to respond to SIGTERM > within a few seconds. Could you please test the latest version in testing? It has quite some improvements and may have improved the situation. Cheers, Balint -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777646: pre-approval: unblock: dpkg/1.17.24
Hi!
On Wed, 2015-02-11 at 11:40:39 +0100, Andreas Beckmann wrote:
> + * Switch versioned Breaks for trigger cycles from << to <= relations (with
> +the necessary version adjustments).
>
> Your changelog and commit message describe the change in the wrong direction,
> the patch shows it the other way:
Nice catch! Fixed locally.
I'm attaching the two other patches targetted for 1.17.x. The revert
passes the functional test suite (although I've disabled three tests
that require dependency checks on trigger processing).
Thanks,
Guillem
From 567be0ef2128dc6add2261d376559ec0ea8de0e5 Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Fri, 20 Feb 2015 17:20:04 +0100
Subject: [PATCH] dpkg: Disable dependency checks on trigger processing
There are still trigger showing up this close to the Debian release,
which are hard to detect automatically as they are caused by maintainer
script actions.
The checks are only removed in the 1.17.x series, and will be kept in
force for the 1.18.x series.
Requested-by: Niels Thykier (Debian Release Manager)
---
debian/changelog | 4
src/trigproc.c | 12
2 files changed, 16 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 53f512f..da2bfcc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,6 +13,10 @@ dpkg (1.17.24) UNRELEASED; urgency=low
* Check that HAVE_DECL_SYS_SIGLIST is 0 instead of undefined, to fix a
build failure on uclibc based systems. Closes: #777044
Based on a patch by Alex Potapenko .
+ * Disable dependency checks on trigger processing. There are still trigger
+cycles showing up this close to the Debian release, which are hard to
+detect automatically as they are caused by maintainer script actions.
+Requested by Niels Thykier (Debian Release Manager).
-- Guillem Jover Mon, 02 Feb 2015 19:46:07 +0100
diff --git a/src/trigproc.c b/src/trigproc.c
index bb17346..77b4877 100644
--- a/src/trigproc.c
+++ b/src/trigproc.c
@@ -365,11 +365,18 @@ trigproc(struct pkginfo *pkg, enum trigproc_type type)
pkg->clientdata->trigprocdeferred = NULL;
if (pkg->trigpend_head) {
+/*
+ * Disable dependency checks on trigger processing only for the 1.17.x cycle
+ * as it is causing too much problems too close to the Debian jessie release.
+ */
+#if 0
enum dep_check ok;
+#endif
assert(pkg->status == PKG_STAT_TRIGGERSPENDING ||
pkg->status == PKG_STAT_TRIGGERSAWAITED);
+#if 0
if (dependtry > 1) {
gaveup = check_trigger_cycle(pkg);
if (gaveup == pkg)
@@ -421,6 +428,11 @@ trigproc(struct pkginfo *pkg, enum trigproc_type type)
if (gaveup == pkg)
return;
}
+#else
+ gaveup = check_trigger_cycle(pkg);
+ if (gaveup == pkg)
+ return;
+#endif
printf(_("Processing triggers for %s (%s) ...\n"),
pkg_name(pkg, pnaw_nonambig),
--
2.2.1.209.g41e5f3a
From ee90d408f0f549aa1e686270fddaf2edaa4ed45f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?=
Date: Wed, 11 Feb 2015 08:33:21 +0100
Subject: [PATCH] debian: drop myself from Uploaders
Cherry picked from commit 10ff6c4fc598dbc9697c825a8c8e1bf25caa2fcb.
Signed-off-by: Guillem Jover
---
debian/changelog | 3 +++
debian/control | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index da2bfcc..9ef67a9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,9 @@ dpkg (1.17.24) UNRELEASED; urgency=low
detect automatically as they are caused by maintainer script actions.
Requested by Niels Thykier (Debian Release Manager).
+ [ Raphaël Hertzog ]
+ * Drop myself from Uploaders.
+
-- Guillem Jover Mon, 02 Feb 2015 19:46:07 +0100
dpkg (1.17.23) unstable; urgency=low
diff --git a/debian/control b/debian/control
index 18fe580..12fb93f 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: dpkg
Section: admin
Priority: required
Maintainer: Dpkg Developers
-Uploaders: Guillem Jover , Raphaël Hertzog
+Uploaders: Guillem Jover
Origin: debian
Bugs: debbugs://bugs.debian.org
Homepage: https://wiki.debian.org/Teams/Dpkg
--
2.2.1.209.g41e5f3a
Bug#778884: emacs24: icon name set with absolute path in emacs24.desktop
Package: emacs24 Version: 24.4+1-4.1 Severity: minor Tags: newcomer Dear Maintainer, GNU emacs 24 has absolute icon name in /usr/share/applications/emacs24.desktop as Icon=/usr/share/icons/hicolor/scalable/apps/emacs24.svg. It should be this way: Icon=emacs24 This make emacs icon look odd in gnome-shell (and other related menus) when using icon themes like Moka icon theme, in which each icon has some unique style. Moka Icon theme: https://github.com/moka-project/moka-icon-theme Regards, Mohammed Sadiq -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages emacs24 depends on: ii emacs24-bin-common 24.4+1-4.1 ii gconf-service 3.2.6-3 ii libacl12.2.52-2 ii libasound2 1.0.28-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-13 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libdbus-1-31.8.12-3 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-2 ii libgconf-2-4 3.2.6-3 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgif44.1.6-11 ii libglib2.0-0 2.42.1-1 ii libgnutls-deb0-28 3.3.8-5 ii libgomp1 4.9.1-19 ii libgpm21.20.4-6.1+b2 ii libgtk-3-0 3.14.5-1 ii libice62:1.0.9-1+b1 ii libjpeg62-turbo1:1.3.1-11 ii libm17n-0 1.6.4-3 ii libmagickcore-6.q16-2 8:6.8.9.9-3 ii libmagickwand-6.q16-2 8:6.8.9.9-3 ii libotf00.9.13-2 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-01.36.8-3 ii libpng12-0 1.2.50-2+b2 ii librsvg2-2 2.40.5-1 ii libselinux12.3-2 ii libsm6 2:1.2.2-1+b1 ii libtiff5 4.0.3-12 ii libtinfo5 5.9+20140913-1+b1 ii libx11-6 2:1.6.2-3 ii libxft22.3.2-1 ii libxinerama1 2:1.1.3-1+b1 ii libxml22.9.1+dfsg1-4 ii libxpm41:3.5.11-1+b1 ii libxrandr2 2:1.4.2-1+b1 ii libxrender11:0.9.8-1+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 emacs24 recommends no packages. Versions of packages emacs24 suggests: pn emacs24-common-non-dfsg -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778877: [Pkg-gnupg-maint] Bug#778877: making the gnupg package reproducible
On Sat, February 21, 2015 01:32, Daniel Kahn Gillmor wrote: > Source: gnupg > Version: 1.4.18-6 > Severity: wishlist > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: timestamps_in_pe_binaries > > I believe that the gnupg package can be made reproducible with the > attached patch, which encourages the linker to omit the timestamp in > gpgv.exe. This was the only difference gnupg afaict. > > I plan to include this patch in the gnupg package in experimental soon. I'm Cc'ing Didier Raboud, who contributed the win32 build and can hopefully comment on this and/or test the change. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778883: ruby1.9.1: libruby1.9.1 shouldn't depend on ruby or an alternative should be create who doesn't depend on ruby
Package: ruby1.9.1 Version: 1.9.3.484-2 Severity: normal Dear Maintainer, According to: ruby1.9.1 (1.9.3.484-2) unstable; urgency=medium * new strategy for Ruby version transitions: - ruby1.9.1 depends on ruby - libruby1.9.1 depends on ruby1.9.1 * Drop alternatives entries. libruby1.9.1 now depends on ruby1.9.1. This causes than installations of packages such us vim-nox (who depends on libruby) pull the whole ruby programming language. It's my opinion it shouldn't be this way (unless the transition fixes some important bugs). In my opinion it could be suggested but not forced. Thanks for your consideration. -- System Information: Debian Release: wheezy/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Kernel: Linux 3.14.4-ck1-ck (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778882: speedtest-cli: Failed to parse list of speedtest.net servers
Package: speedtest-cli Version: 0.3.1-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Simply running speedtest-cli with no arguments: Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Failed to parse list of speedtest.net servers * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.19.0+ (SMP w/1 CPU core; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages speedtest-cli depends on: ii python2.7.8-3 ii python-pkg-resources 5.5.1-1 speedtest-cli recommends no packages. speedtest-cli suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775619: seaborn: FTBFS in jessie: Tests failures
On Fri, 20 Feb 2015, Mehdi Dogguy wrote: > What is the impact of disabling statsmodels 0.6 features in seaborn? > Also, AFAICS, the runtime error is not catched, so I guess the program > will just kill itself? not "kill" but throw an exception, and quite an informative one ;) > Why not just setting _has_statsmodels=False when statsmodels version > is older than 0.6? actually not a bad idea overall, but then we would need to differentiate in message since currently it might require user to "Please install statsmodels." which would otherwise be utterly confusing... overall -- I think it is ok for few of those methods to explicitly puke that "yeap -- need newer statsmodels" overall -- take it or RM it, I don't think I would spend more time on this one for jessie (unless new grave one comes up) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745082: Bug#763391: chfn and fakechroot
On 02/21/2015 12:12 AM, Daniel Kahn Gillmor wrote: > On Fri 2015-02-20 18:24:18 -0500, jhcha54008 wrote: >> May I ask if debootstrap ran in a fakechroot environment or as real root ? > > I'm curious about this too. Adrian, can you give more details? I always ran debootstrap as the regular root user. Except that on sh4, I ran bash in a screen so I could detach the session since debootstrap takes a while on these machines. What completely puzzles me that it does work without any issues on m68k and amd64 using the exact same command line albeit I did not use screen on both amd64 and m68k. I'm running the command on sh4 without screen now to see if that fixes it otherwise I don't really know yet what could be different on sh4. We need to figure out what part of the chain of scripts is responsible for taking out the quotes to the option argument of chfn. I am suspecting some Perl issue as adduser is written in Perl and the postinst script of systemd which actually runs adduser properly quotes the option argument for the gecos field. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778257: src:qtdeclarative-opensource-src: FTBFS on x32: JIT, symbols
On Saturday 21 February 2015 00:01:20 Adam Borowski wrote:
[snip]
> > Can you please send this upstream to https://codereview.qt-project.org/?
>
> I looked at the upstream website, and found it quite confusing. Thus, if
> you could forward the patch, it would be nice.
>
> > Or, if you can't do it, tell us that you license the patch under BSD
> > license and we will do that ourselves (needed because upstream has a
> > CLA).
> Sure. The patch appears to be too small to be copyrightable, but anyway, I
> hereby grant the right to use it under any license of your choice.
Thanks Adam! The patch is indeed too small to be copyrightable, so no problems
if Dmitry or I pushes the patch upstream.
> > > * updating the symbols file. s/!sparc64/!sparc64 !x32/ worked for me,
> > > as
> > >
> > > symbols you skip on every architecture need to be skipped on x32 too
> > > (how surprising...)
> >
> > No longer needed with the current Qt 5.4 packages (in experimental), where
> > the symbols mess has been fixed.
>
> I tried to check the patch against the packages in experimental, but one of
> dependencies (qtxmlpatterns) failed to build for me, for reasons that don't
> seem to be arch-dependent:
>
>
> CMake Error at
> /home/kilobyte/tmp/x32/exp/qtxmlpatterns-opensource-src-5.4.0/lib/cmake/Qt5
> XmlPatterns/Qt5XmlPatternsConfig.cmake:27 (message): The imported target
> "Qt5::XmlPatterns" references the file
>
> "/home/kilobyte/tmp/x32/exp/include/x86_64-linux-gnux32/qt5/"
>
> but this file does not exist. Possible reasons include:
>
> If it's supposed to work, I can poke around more. I wonder, though, if it
> would cost less human time to throw the patch in blindly for now.
Maybe you have your own Qt build somewhere? That path sounds like a .cmake
file coming from a personal build :-/
> It does require a change, though. Against sources from experimental it's:
> --- src/qml/jsruntime/qv4global_p.h~ 2014-12-05 17:25:11.0 +0100
> +++ src/qml/jsruntime/qv4global_p.h 2015-02-20 19:04:52.201925780 +0100
> @@ -69,9 +69,11 @@
> //
> // NOTE: This should match the logic in qv4targetplatform_p.h!
>
> -#if defined(Q_PROCESSOR_X86) && (defined(Q_OS_WINDOWS) ||
> defined(Q_OS_LINUX) || defined(Q_OS_QNX) || defined(Q_OS_FREEBSD)) +#if
> defined(Q_PROCESSOR_X86) && !defined(__ILP32__) \
> +&& (defined(Q_OS_WINDOWS) || defined(Q_OS_LINUX) || defined(Q_OS_QNX)
> || defined(Q_OS_FREEBSD)) #define V4_ENABLE_JIT
> -#elif defined(Q_PROCESSOR_X86_64) && (defined(Q_OS_WINDOWS) ||
> defined(Q_OS_LINUX) || defined(Q_OS_MAC) || defined(Q_OS_FREEBSD)) +#elif
> defined(Q_PROCESSOR_X86_64) && !defined(__ILP32__) \
> +&& (defined(Q_OS_WINDOWS) || defined(Q_OS_LINUX) || defined(Q_OS_MAC)
> || defined(Q_OS_FREEBSD)) #define V4_ENABLE_JIT
> #elif defined(Q_PROCESSOR_ARM_32)
>
>
> while against upstream's 5.4 git it's:
> --- a/src/qml/jsruntime/qv4global_p.h
> +++ b/src/qml/jsruntime/qv4global_p.h
> @@ -69,9 +69,11 @@ inline double trunc(double d) { return d > 0 ? floor(d) :
> ceil(d); } //
> // NOTE: This should match the logic in qv4targetplatform_p.h!
>
> -#if defined(Q_PROCESSOR_X86) && (defined(Q_OS_WIN) || defined(Q_OS_LINUX)
> || defined(Q_OS_QNX) || defined(Q_OS_FREEBSD)) +#if
> defined(Q_PROCESSOR_X86) && !defined(__ILP32__) \
> +&& (defined(Q_OS_WIN) || defined(Q_OS_LINUX) || defined(Q_OS_QNX) ||
> defined(Q_OS_FREEBSD)) #define V4_ENABLE_JIT
> -#elif defined(Q_PROCESSOR_X86_64) && (defined(Q_OS_WIN) ||
> defined(Q_OS_LINUX) || defined(Q_OS_MAC) || defined(Q_OS_FREEBSD)) +#elif
> defined(Q_PROCESSOR_X86_64) && !defined(__ILP32__) \
> +&& (defined(Q_OS_WIN) || defined(Q_OS_LINUX) || defined(Q_OS_MAC) ||
> defined(Q_OS_FREEBSD)) #define V4_ENABLE_JIT
> #elif defined(Q_PROCESSOR_ARM_32)
>
>
> (Ie, Q_OS_WIN vs Q_OS_WINDOWS).
We need to look at what's going to ship with 5.4.1, due to next week.
--
Those are my principles. If you don't like them I have others.
-- Groucho Marx
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
signature.asc
Description: This is a digitally signed message part.
Bug#778879: ITP: boomaga -- virtual printer for viewing a document before printing
tag 778879 pending thanks Waitin on the NEW queue. -- No subestimes el ancho de banda de un camión cargado de cintas. Andrew S. Tanenbaum Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#745082: chfn and fakechroot
On 02/21/2015 12:24 AM, jhcha54008 wrote: > May I ask if debootstrap ran in a fakechroot environment or as real root ? I haven't tried fakechroot, but the debootstrap call was done using the real root user. What makes you so sure this is actually an issue with fakechroot? I just tried --variant=fakechroot on my main amd64 machine and that worked without any issues. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713016: New upload?
Hi.
On Feb 19 2015, Michael Vogt wrote:
> If there are no objections I would like to do a upload with the patch
> of the package and add myself to the uploaders.
I worked a bit on the package, but I feel that it is not quite good yet
(e.g., no pristine-tar branch, the current debian/rules sucks, among other
things).
That being said, a bunch of lintian warnings were fixed and the package now
automatically respects hardening options (it wasn't hardened, as far as I
could see) and the build is considerably noisier (due to some really fishy
casts, format strings and so on).
Besides the repo on the Debian servers, I uploaded it to
https://github.com/rbrito/pkg-dvd-rw-tools
since, as I mentioned before, I like github's interface better.
If you want to add yourself to the uploaders, go ahead and let me know (send
me a pull request or whatever). I am quite limited on time and I think that
I could really use some help maintaining my packages.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778753: cabextract: Directory traversal (CVE pending)
On Thu, Feb 19, 2015 at 5:38 AM, Moritz Muehlenhoff wrote: > Upstream fix is here: > http://sourceforge.net/p/libmspack/code/217 > > Since unstable has a more recent version than testing, could you make > a targeted jessie upload with this patch? I've written a new patch from scratch to fix cabextract 1.4 and uploaded this to jessie-security as 1.4-6. Please let me know if there are any issues. I don't think I've had to do a security upload in the last 10 years or so, so I'm a bit out of practice. I don't have a new build for sid yet. Maybe tomorrow. Eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778881: binfmt-support.service activating (start) for ever, no console
Package: binfmt-support Version: 2.1.5-1 Severity: normal Dear Maintainer, * What led up to the situation? Booting up; now happening about once in four times. One reads that: [ Cylon eye ] A start job is running for Enable support for additional executable binary formats (3h 7min 57s / no limit) * What exactly did you do (or not do) that was effective (or ineffective)? Discovered that I can ssh in (when at home) and so I collected the information below. Alternatively I have pressed ^C on the console and/or CtrlAltDel and/or the power button. * What was the outcome of this action? Sometimes, the Cylon eye freezes and the clock stops counting up (or sometimes neither of these). Regardless, I have to hard reset eventually. * What outcome did you expect instead? Some sort of error message and perhaps a recovery mode login, or else some sort of closedown. A secondary observation: logging in over the network via ssh takes much longer than usual, as does then executing /bin/su - --8< $ date ; /bin/su - Fri 20 Feb 16:49:58 CST 2015 Password:(give me a couple of seconds to type the password) date ~# date Fri 20 Feb 16:50:52 CST 2015 ~# --8< Here are some outputs: $ systemctl status binfmt-support.service ● binfmt-support.service - Enable support for additional executable binary formats Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled) Active: activating (start) since Fri 2015-02-20 15:08:26 CST; 27min ago Docs: man:update-binfmts(8) Main PID: 654 (update-binfmts) CGroup: /system.slice/binfmt-support.service └─654 /usr/sbin/update-binfmts --enable $ ls -laR /etc/binfmt.d/ /run/binf* /usr/lib/binfmt.d/ /usr/lib/binfmt-support/ 2>&1 ls: cannot access /run/binf*: No such file or directory /etc/binfmt.d/: total 16 drwxr-xr-x 2 root root 4096 Aug 20 2014 . drwxr-xr-x 154 root root 12288 Feb 20 09:54 .. /usr/lib/binfmt.d/: total 40 drwxr-xr-x 2 root root 4096 Aug 20 2014 . drwxr-xr-x 149 root root 36864 Feb 20 09:54 .. /usr/lib/binfmt-support/: total 108 drwxr-xr-x 2 root root 4096 Oct 3 14:10 . drwxr-xr-x 149 root root 36864 Feb 20 09:54 .. -rwxr-xr-x 1 root root 63296 Aug 24 16:49 run-detectors $ ps ax PID TTY STAT TIME COMMAND 1 ?Ss 8:01 /sbin/init 2 ?S 0:00 [kthreadd] 3 ?S 0:59 [ksoftirqd/0] 5 ?S< 0:00 [kworker/0:0H] 6 ?S 0:00 [kworker/u4:0] 7 ?S 0:01 [rcu_sched] 8 ?S 0:00 [rcu_bh] 9 ?S 0:00 [migration/0] 10 ?S 0:00 [watchdog/0] 11 ?S 0:00 [watchdog/1] 12 ?S 0:00 [migration/1] 13 ?S 1:10 [ksoftirqd/1] 15 ?S< 0:00 [kworker/1:0H] 17 ?S< 0:00 [khelper] 18 ?S 0:00 [kdevtmpfs] 19 ?S< 0:00 [netns] 20 ?S 0:00 [khungtaskd] 21 ?S< 0:00 [writeback] 22 ?SN 0:00 [ksmd] 23 ?SN 0:00 [khugepaged] 24 ?S< 0:00 [crypto] 25 ?S< 0:00 [kintegrityd] 26 ?S< 0:00 [bioset] 27 ?S< 0:00 [kblockd] 28 ?S 0:00 [kworker/1:1] 29 ?S 0:00 [kswapd0] 30 ?S 0:00 [fsnotify_mark] 36 ?S< 0:00 [kthrotld] 37 ?S< 0:00 [ipv6_addrconf] 39 ?S< 0:00 [deferwq] 74 ?S< 0:00 [acpi_thermal_pm] 75 ?S< 0:00 [ata_sff] 77 ?S 0:00 [scsi_eh_0] 78 ?S< 0:00 [scsi_tmf_0] 79 ?S 0:00 [scsi_eh_1] 80 ?S< 0:00 [scsi_tmf_1] 82 ?S 0:00 [kworker/u4:3] 85 ?S< 0:00 [kworker/0:1H] 86 ?S< 0:00 [kworker/1:1H] 107 ?S 0:00 [jbd2/sda1-8] 108 ?S< 0:00 [ext4-rsv-conver] 141 ?Ss 0:00 /lib/systemd/systemd-journald 142 ?S 0:00 [kauditd] 168 ?S< 0:00 [firewire] 170 ?Ss 0:01 /lib/systemd/systemd-udevd 244 ?S< 0:00 [firewire_ohci] 246 ?S 0:00 [khubd] 247 ?S 0:00 [pccardd] 250 ?S< 0:00 [kpsmoused] 251 ?S< 0:00 [cfg80211] 252 ?S 0:00 [irq/18-mmc0] 263 ?S 0:01 [kworker/0:4] 265 ?S< 0:00 [hd-audio0] 274 ?S< 0:00 [iwl3945] 357 ?S< 0:00 [kworker/u5:0] 358 ?S< 0:00 [hci0] 359 ?S< 0:00 [hci0] 369 ?S< 0:00 [kworker/u5:2] 431 ?S 0:00 [jbd2/sda2-8] 432 ?S< 0:00 [ext4-rsv-conver] 436 ?S 0:00 [jbd2/sda3-8] 437 ?S< 0:00 [ext4-rsv-conver] 614 ?Ss 0:00 /sbin/rpcbind -w 623 ?Ss 0:00 /sbin/rpc.statd 628 ?S< 0:00 [rpciod] 631 ?S< 0:00 [nfsiod] 638 ?Ss 0:00 /usr/sbin/rpc.idmapd 643 ?
Bug#778880: xul-ext-https-everywhere: Breaks redirects with query string (e.g. deb.li/… to anonscm.d.o/cgit/…)
Package: xul-ext-https-everywhere
Version: 4.0.2-3
Severity: grave
Justification: Breaks iceweasel in a non-obvious way, potentially causes data
loss
Control: affects -1 iceweasel conkeror
Dear Lunar and Fabrizio,
If I enter the URL http://deb.li/3czsE into Iceweasel's location bar
with HTTPS Everywhere enabled, I end up at
https://anonscm.debian.org/cgit/pkg-perl/website.git/diff/?id= (which
says "Bad object name" due to the missing value behind "id=") instead of
https://anonscm.debian.org/cgit/pkg-perl/website.git/diff/?id=24f0998 as
expected.
The same URL and redirect chain works fine again, if I deactivate HTTPS
Everywhere in Iceweasel's tool bar. (It also works fine in the following
browsers/HTTP clients in Jessie: Chromium, Lynx, libwww-perl ("GET"),
Links2, Netsurf, Arora, and wget. I initially suspected Iceweasel itself
to be the culprit.)
I'm not sure which exact characteristic of this specific case causes the
misbehaviour, but I suspect it's query strings with ";" as delimiter.
Example redirect chain captured with wget:
→ wget -S --spider http://deb.li/3czsE
Spider mode enabled. Check if remote file exists.
--2015-02-21 01:56:09-- http://deb.li/3czsE
Resolving deb.li (deb.li)... 2001:470:1f0b:168f::4, 217.196.146.214
Connecting to deb.li (deb.li)|2001:470:1f0b:168f::4|:80... failed: Network is
unreachable.
Connecting to deb.li (deb.li)|217.196.146.214|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 302 FOUND
Date: Sat, 21 Feb 2015 00:56:09 GMT
Server: Apache/2.2.22 (Debian)
Content-Length: 365
Location:
http://anonscm.debian.org/gitweb/?p=pkg-perl/website.git;a=commitdiff;h=24f0998
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Location:
http://anonscm.debian.org/gitweb/?p=pkg-perl/website.git;a=commitdiff;h=24f0998
[following]
Spider mode enabled. Check if remote file exists.
--2015-02-21 01:56:09--
http://anonscm.debian.org/gitweb/?p=pkg-perl/website.git;a=commitdiff;h=24f0998
Resolving anonscm.debian.org (anonscm.debian.org)... 5.153.231.21
Connecting to anonscm.debian.org (anonscm.debian.org)|5.153.231.21|:80...
connected.
HTTP request sent, awaiting response...
HTTP/1.1 302 Found
Date: Sat, 21 Feb 2015 00:56:09 GMT
Server: Apache/2.2.22 (Debian)
Location: http://anonscm.debian.org/cgit/pkg-perl/website.git/diff/?id=24f0998
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
Location: http://anonscm.debian.org/cgit/pkg-perl/website.git/diff/?id=24f0998
[following]
Spider mode enabled. Check if remote file exists.
--2015-02-21 01:56:10--
http://anonscm.debian.org/cgit/pkg-perl/website.git/diff/?id=24f0998
Connecting to anonscm.debian.org (anonscm.debian.org)|5.153.231.21|:80...
connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Sat, 21 Feb 2015 00:56:10 GMT
Server: Apache/2.2.22 (Debian)
Expires: Tue, 18 Feb 2025 00:56:10 GMT
Last-Modified: Sat, 21 Feb 2015 00:56:10 GMT
X-Robots-Tag: noindex, nofollow
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.
Filing as RC as this will likely break many web applications in
non-obvious ways and potentially causes data loss (despite
non-reproducible data should not be handled in query strings, but
anyways).
Feel free to downgrade to important in case you don't agree with this
judgement. (Or to serious if you just don't agree with the reasoning,
but still think it's RC.) I at least think, this misbehaviour should be
fixed for Jessie, also because of its hidden character as users don't
see the redirect chain inside the browser.
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (909, 'testing'), (500, 'testing-updates'), (500,
'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages xul-ext-https-everywhere depends on:
ii conkeror 1.0~~pre-1+git150129+2307-~nightly1
ii icedove31.4.0-2
ii iceweasel 31.4.0esr-1
xul-ext-https-everywhere recommends no packages.
xul-ext-https-everywhere suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778879: ITP: boomaga -- virtual printer for viewing a document before printing
Package: wnpp Severity: wishlist Owner: "Lisandro Damián Nicanor Pérez Meyer" * Package name: boomaga Version : 0.6.2 Upstream Author : Alexander Sokolov * URL : https://github.com/Boomaga/boomaga * License : LGPL-2.1+ Programming Lang: C++ Description : virtual printer for viewing a document before printing Boomaga (BOOklet MAnager) is a virtual printer for viewing a document before printing it out using the physical printer. The program is very simple to work with. Running any program, click "print" and select "Boomaga" to see in several seconds (CUPS takes some time to respond) the Boomaga window open. If you print out one more document, it gets added to the previous one, and you can also print them out as one. Regardless of whether your printer supports duplex printing or not, you would be able to easily print on both sides of the sheet. - why is this package useful/relevant? Seems to make people's life easier :) - is it a dependency for another package? Not that I know of. - do you use it? Yes - if there are other packages providing similar functionality, how does it compare? Not that I know of. I have searched the web without luck. - how do you plan to maintain it? Personal package, but I'm open to comaintainers. I do follow Qt/KDE's team rules for packaging/keeping repos and I don't plan to change that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778878: apt (and /etc/cron.daily/apt as well) don't notify about failed package updates
Package: apt Version: 1.0.9.6 Severity: important Tags: security Hi Davit (et all). Just the same time we're having a similar discussion about this at with the security time, I got hit by it again in another manner. As we now all know, apt unfortunately doesn't tell people (adequately) when updating the package lists have failed, e.g.: # apt-get update Hit http://debian.mirror.lrz.de stable Release.gpg Err http://security.debian.o stable/updates Release.gpg Could not resolve 'security.debian.o' Err http://security.debin.o stable/updates Release.gpg Could not resolve 'security.debin.o' Hit http://debian.mirror.lrz.de stable-updates Release.gpg Err http://debian.mirror.lrz.d oldstable Release.gpg Could not resolve 'debian.mirror.lrz.d' Err http://debian.mirror.lrz.d stable Release.gpg Could not resolve 'debian.mirror.lrz.d' Err http://debian.mirror.lrz.d stable-updates Release.gpg Could not resolve 'debian.mirror.lrz.d' Hit http://debian.mirror.lrz.de stable Release Hit http://debian.mirror.lrz.de stable-updates Release Hit http://debian.mirror.lrz.de stable/main Sources Hit http://debian.mirror.lrz.de stable/contrib Sources Hit http://debian.mirror.lrz.de stable/non-free Sources Hit http://debian.mirror.lrz.de stable-updates/main Sources Hit http://debian.mirror.lrz.de stable-updates/contrib Sources Hit http://debian.mirror.lrz.de stable-updates/non-free Sources Reading package lists... Done W: Failed to fetch http://debian.mirror.lrz.d/debian/dists/oldstable/Release.gpg Could not resolve 'debian.mirror.lrz.d' W: Failed to fetch http://debian.mirror.lrz.d/debian/dists/stable/Release.gpg Could not resolve 'debian.mirror.lrz.d' W: Failed to fetch http://debian.mirror.lrz.d/debian/dists/stable-updates/Release.gpg Could not resolve 'debian.mirror.lrz.d' W: Failed to fetch http://security.debian.o/debian-security/dists/stable/updates/Release.gpg Could not resolve 'security.debian.o' W: Failed to fetch http://security.debin.o/debian-security/dists/stable/updates/Release.gpg Could not resolve 'security.debin.o' W: Some index files failed to download. They have been ignored, or old ones used instead. # echo $? 0 1) I've already expressed my concerns before, that Warning and exit=0 isn't enough here. People may depend on the package lists being up-to-date for example for unattended upgrades or checking for upgradable packages via Nagios (check_apt) and friends. An attacker can of course rather easily just block these downloads, thus if this doesn't get properly noted, he can easily prevent and further upgrades from being installed (with automated unattended upgrades) respectively prevent that people even notice that upgrades are available. So the first issue here is that apt is to silent about this. 2) The second problem is IMHO sepcifically in /etc/cron.daily/apt and would even persist when (1) is solved. That script is in principle really nice as it gives one quite powerful means to automatically handle some things (updating package lists, etc.) But a bit problem is, that it basically fails silently in all cases of problems. VERBOSE mode is of course not really a solution as this would give *always* warnings via cron. So the second issue is, that /etc/cron.daily/apt never tells people when anything didn't work (e.g. updates, upgrades, or whatever). So one has never a chance to notice this, and never a chance to fix it. In some cases of what it's intended to do (i.e. package list updates or upgrades) this may very easily have security implications (e.g. in combination with blocking attacks). Best wishes, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778876: linux-headers-3.19.0-trunk-amd64 is uninstallable.
Package: linux-headers-3.19.0-trunk-amd64 Version: 3.19-1~exp1 linux-headers-3.19.0-trunk-amd64 is uninstallable due to missing linux-kbuild-3.19 this also means that linux-image-3.19.0-trunk-amd64 is useless to anyone who needs dkms kernel modules. # apt-get -d -u -t experimental install linux-headers-3.19.0-trunk-amd64 linux-image-3.19.0-trunk-amd64 linux-support-3.19.0-trunk Reading package lists... Done Building dependency tree Reading state information... Done 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: linux-headers-3.19.0-trunk-amd64 : Depends: linux-kbuild-3.19 but it is not installable craig -- craig sanders -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778877: making the gnupg package reproducible
Source: gnupg Version: 1.4.18-6 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps_in_pe_binaries I believe that the gnupg package can be made reproducible with the attached patch, which encourages the linker to omit the timestamp in gpgv.exe. This was the only difference gnupg afaict. I plan to include this patch in the gnupg package in experimental soon. --dkg diff --git a/debian/rules b/debian/rules index f22c079..3180cd0 100755 --- a/debian/rules +++ b/debian/rules @@ -58,6 +58,7 @@ build-udeb/config.status: build-win32/config.status: dh_testdir (mkdir -p $(@D); cd $(@D); CFLAGS="-g -Os" \ + LDFLAGS="-Xlinker --no-insert-timestamp" \ ../configure $(CONFARGS) $(CONFARGS_MINIMAL) --host i686-w64-mingw32 ) # build ## signature.asc Description: PGP signature
Bug#778875: bootlogd: Can't open /etc/init.d/stop-bootlogd: No such file or directory
Package: bootlogd Version: 2.88dsf-58 Severity: normal Today I tried installing needrestart and it produced this error. Upon investigation I find this problem. # apt-get install --reinstall bootlogd Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 6 not upgraded. Need to get 58.7 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://ftp.us.debian.org/debian/ sid/main bootlogd amd64 2.88dsf-58 [58.7 kB] Fetched 58.7 kB in 1s (57.7 kB/s) (Reading database ... 605542 files and directories currently installed.) Preparing to unpack .../bootlogd_2.88dsf-58_amd64.deb ... Unpacking bootlogd (2.88dsf-58) over (2.88dsf-58) ... Processing triggers for man-db (2.7.0.2-5) ... Setting up bootlogd (2.88dsf-58) ... Can't open /etc/init.d/stop-bootlogd: No such file or directory This is a Sid system upgraded daily. Thank you for maintaining bootlogd. Bob -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages bootlogd depends on: ii libc6 2.19-15 ii lsb-base 4.1+Debian13+nmu1 bootlogd recommends no packages. bootlogd suggests no packages. -- Configuration Files: /etc/init.d/stop-bootlogd [Errno 2] No such file or directory: u'/etc/init.d/stop-bootlogd' /etc/init.d/stop-bootlogd-single [Errno 2] No such file or directory: u'/etc/init.d/stop-bootlogd-single' -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778874: terminator: Moving between terminals buggy
Package: terminator
Version: 0.97-4
Severity: minor
Tags: patch
Hi,
After having split the window a few times horizontally and vertically,
switching to a window ABOVE using Alt+Up sometimes chooses a terminal far away
from the obvious (unique) one which is directly above.
To reproduce: open a new terminator window, split vertically (Ctrl+Shift+E)
into A and B, split A and B both horizontally (Ctrl+Shift+O) into A1/A2 and
B1/B2. Make A1 a bit smaller, i.e., reduce its height so that it is smaller
than B1. Go to B2, press Alt+Up. You should obviously end up in B1, but you
end up in A1.
This has bugged me for quite a while, today I wrote a fix which you find
attached. The problem is in the function computing distance of other terminals
to the current one. It has an obvious typo for direction == 'up'. The patch
also fixes the return values for 'right' and 'left' even though they didn't
result in bugs.
Thanks for considering.
Regards,
Martin
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 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 terminator depends on:
ii gconf2 3.2.6-3
ii python-dbus 1.2.0-2+b3
ii python-gobject 3.14.0-1
ii python-gtk2 2.24.0-4
ii python-vte 1:0.28.2-5
pn python:any
Versions of packages terminator recommends:
ii python-gnome2 2.28.1+dfsg-1.1
ii python-keybinder 0.3.0-3
ii python-notify 0.1.1-4
ii xdg-utils 1.1.0~rc1+git20111210-7.3
terminator suggests no packages.
-- no debconf information
diff --git a/terminatorlib/util.py b/terminatorlib/util.py
index b8ad5ab..d1311ca 100755
--- a/terminatorlib/util.py
+++ b/terminatorlib/util.py
@@ -223,11 +223,11 @@ def get_nav_offset(edge, allocation, direction):
if direction == 'left':
return(edge - (allocation.x + allocation.width))
elif direction == 'right':
-return(edge + allocation.x)
+return(allocation.x - edge)
elif direction == 'up':
-return(edge - (allocation.y - allocation.height))
+return(edge - (allocation.y + allocation.height))
elif direction == 'down':
-return(edge + allocation.y)
+return(allocation.y - edge)
else:
raise ValueError('Unknown direction: %s' % direction)
Bug#778872: [Pkg-utopia-maintainers] Bug#778872: firewalld: breaks boot (probably LightDM)
control: tags -1 moreinfo Am 21.02.2015 um 00:55 schrieb Dominik George: > Package: firewalld > Version: 0.3.12-1 > Severity: critical > Justification: breaks the whole system > > firewalld has started breaking system boot. > > When the unit is enabled, the system boots normally until lightdm is > being started. LightDM then renders the mouse pointer persistently over > the tty, but never draws anything else. > > ttys are usable, but the system is in an unusable state. > > I tried purging firewalld and removing all remaining configuration, but > to no avail. > If purging the firewalld package does not solve the problem, how can firewalld break your system? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#778873: apt: make /etc/cron.daily/apt (and it's options) runnable more than daily
Package: apt Version: 1.0.9.6 Severity: wishlist Tags: security /etc/cron.daily/apt and it's related options provide some very nice means to keep one's archive up to date (e.g. doing regular apt-get updates) which in turn is particularly handy for either just monitoring (via Icinga or friends) whether package updates are available or unattended updating. However, unfortunately the script runs at most daily and also it's related options are with the time unit "days". Given recent things like GHOST, heardbleed, shell shock and so on, where upgrade (thanks to our security team!) were often avialable within just hours after publications (but exploits as well) it seems more and more crucial that package management lifecycle (i.e. update times) get shorter and shorter. Having to wait a full day, just to see that new security packages are there, when these might have gotten pushed to the servers by the security team just minutes after the last run of /etc/cron.daily/apt is IMHO simply too long. So my wish would be that this goes at least to hourly or even better cron.d/ so that people can chose whatever they want. Now apparently it's more than just moving cron script. ;) One solution wrt to the current definition of the options (which should of course remain backwards compatible with respect to the "day" unit) would be that each option get's an corresponding unit-option which defaults to "1 day" so e.g. for APT::Archives::MaxAge there would be a corresponding APT::Archives::MaxAge::Unit, which defaults to say 86400s and internally the script works with 1s resolution. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713016: New upload of dvd+rw-tools (was: Re: New upload?)
Hi, Michael.
On Feb 19 2015, Michael Vogt wrote:
> I tested the patch and it works for me too,
Not having a bluray disc/drive available, I wasn't able to test this
myself. (To be honest, I have never even *seen* a BD).
> I would really like to see this fix in Debian and want to help making this
> happen.
Would this have any chance of getting into the next stable?
> If there are no objections I would like to do a upload with the patch
> of the package and add myself to the uploaders.
Do you have changes ready already? The packaging is in a desperate need of a
facelift and adoption of best current practices (e.g., a pristine-tar
branch, updating many other things etc.).
I am taking a *brief* look at the packaging, but I would appreciate any kind
of help.
I think that I will put a copy of this under my github account, since I like
the user interface better there.
Also, as I have expressed in the past, I think that this "team" should be
merged with the other team that is taking care of, say, cdrkit and others.
Thanks for your interest,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778872: firewalld: breaks boot (probably LightDM)
Package: firewalld Version: 0.3.12-1 Severity: critical Justification: breaks the whole system -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 firewalld has started breaking system boot. When the unit is enabled, the system boots normally until lightdm is being started. LightDM then renders the mouse pointer persistently over the tty, but never draws anything else. ttys are usable, but the system is in an unusable state. I tried purging firewalld and removing all remaining configuration, but to no avail. I also verified that iptables does not contain any suspicious rules. - -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: systemd (via /run/systemd/system) Versions of packages firewalld depends on: ii dbus 1.8.16-1 ii gir1.2-glib-2.0 1.42.0-2.2 ii init-system-helpers 1.22 ii iptables 1.4.21-2+b1 ii policykit-1 0.105-8 ii python 2.7.8-3 ii python-dbus 1.2.0-2+b3 ii python-gi3.14.0-1 ii python-slip-dbus 0.6.0-2 Versions of packages firewalld recommends: ii ebtables 2.0.10.4-3 firewalld suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJOBAEBCAA4BQJU58ltMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZFTQ//TN8WV/3b4ekyp8/gWZOa A57aVaK1yj0XNVZTdTacIBLcao91H7351ELA+q41Bnz7v6QGYWEuFXfQkQaUfTBC d3aWXpHvGBqtKDtWjN4lOWK/lRN5JiaNFKEx8Pzn2srvBy9eoxFnDzQAMIbnVKyx 9Aj6CJg39BXCNnNYLfgxgx/sYfaitttBf6bPfCueicm3CDQMyCX3L5HrzRwicsIL AHL44cY4N7XElVqtbFSzGia6OAc9i4sUnm8ElOm2HLrMrpI+GSickzBHl7OE0tP0 q1cyHiUI5GyiLz29baem+SQgIt+ASaAgesD/+X+6UllyRSvg4CkJah6NqgAhy4Om Gf5osmvGfmlnRFsI1dTmwIk1GjlTyXfvnDXmhdXvZ3+cHwvfNWYEWwXDwEJkKugN srxxHwlIu56stb6isfuoNFOSMU/fhBVG6FZD2q4Wpl0H5MG1lk7cHPFtrmsRv3Kt E1p/7QFbVfIYjKvJ5tQZi5jPXMqZ7iS+3Q0t7hj1VVLUfuFZuPA9NttHZ21O/Vqw g4CrLrr/+x90gMv27puaIBCFFvOBFAbafAXbj0gUg78bBgYkmZ9e6aydpKuH4x5e OHqZ70Gyd55Z2TpH7Hz4xYz5tWquZJ3j2nY3kyXoEqwrH2kySN7YZt6wzY7WFWFa rogAQK606TLgO+52ReVzqhU= =qgEq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778871: opendkim: /etc/default/opendkim should allow to specify permissions for socket
Package: opendkim Version: 2.6.8-4 Severity: wishlist Dear Maintainer, when using a local socket for communication with opendkim milter the "opendkim" user and "opendkim" group are used as owner and group of the socket. Other milters such as amavisd-milter allow to configure special permissions for the socket which are applied in the init-script (e.g. /etc/init.d/amavid-milter). Right now only the umask can be adjusted in /etc/opendkim.conf. Take amavisd-milter which has the following options in /etc/default/amavid-milter: # Set these two options if you want the socket to have # special permissions (usefull mainly for postfix). MILTERSOCKETOWNER="postfix:postfix" MILTERSOCKETMODE="0660" Having something like this in opendkim would be nice in order to be able to set permissions to sockets in a more fine-grained manner w/o the need to add the "postfix" user to other groups or using other workarounds. PS: This also applies to "unstable: 2.9.2-2" -- System Information: Debian Release: 7.8 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages opendkim depends on: ii adduser 3.113+nmu3 ii libc6 2.13-38+deb7u7 ii libdb5.15.1.29-5 ii libldap-2.4-2 2.4.31-1+nmu2 ii liblua5.1-0 5.1.5-4+deb7u1 ii libmilter1.0.1 8.14.4-4 ii libopendkim72.6.8-4 ii libssl1.0.0 1.0.1e-2+deb7u14 ii libunbound2 1.4.17-3+deb7u2 ii libvbr2 2.6.8-4 ii lsb-base4.1+Debian8+deb7u1 opendkim recommends no packages. Versions of packages opendkim suggests: ii opendkim-tools 2.6.8-4 -- Configuration Files: /etc/default/opendkim changed [not included] /etc/opendkim.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778862: ispell: please make building .hash files reproducible
Control: tags -1 + patch
I attached a patch that initializes the parsed tables with 0,
before they are assigned to sflaglist.
diff --git a/debian/patches/0031-Initialize-table.patch b/debian/patches/0031-Initialize-table.patch
new file mode 100644
index 000..43f6c11
--- /dev/null
+++ b/debian/patches/0031-Initialize-table.patch
@@ -0,0 +1,51 @@
+Author: Reiner Herrmann
+Description: initialize table with zero to prevent uninitialized memory being written
+Bug-Debian: https://bugs.debian.org/778862
+
+Index: ispell-3.3.02/parse.y
+===
+--- ispell-3.3.02.orig/parse.y
ispell-3.3.02/parse.y
+@@ -205,6 +205,7 @@ static int nbasestrings = 0; /* Number
+ static struct flagent * table; /* Current table being built */
+ static int tblnum; /* Numer of entries in table */
+ static int tblsize = 0; /* Size of the flag table */
++static int tmp = 0;
+ static int ungrablen; /* Size of ungrab area */
+ %}
+
+@@ -898,7 +899,7 @@ table : flagdef
+ tblsize = centnum + TBLINC;
+ tblnum = 0;
+ table = (struct flagent *)
+- malloc (tblsize * (sizeof (struct flagent)));
++ calloc (tblsize, sizeof (struct flagent));
+ if (table == NULL)
+ {
+ yyerror (PARSE_Y_NO_SPACE);
+@@ -907,6 +908,7 @@ table : flagdef
+ }
+ else if (tblnum + centnum >= tblsize)
+ {
++tmp = tblsize;
+ tblsize = tblnum + centnum + TBLINC;
+ table = (struct flagent *)
+ realloc ((char *) table,
+@@ -916,6 +918,8 @@ table : flagdef
+ yyerror (PARSE_Y_NO_SPACE);
+ exit (1);
+ }
++memset(table + tmp * sizeof(struct flagent), 0,
++ tblsize * sizeof(struct flagent) - tmp * sizeof(struct flagent));
+ }
+ for (tblnum = 0; tblnum < centnum; tblnum++)
+ table[tblnum] = curents[tblnum];
+@@ -936,6 +940,8 @@ table : flagdef
+ yyerror (PARSE_Y_NO_SPACE);
+ exit (1);
+ }
++memset(table + tmp * sizeof(struct flagent), 0,
++ tblsize * sizeof(struct flagent) - tmp * sizeof(struct flagent));
+ }
+ for (i = 0; i < centnum; i++)
+ table[tblnum + i] = curents[i];
diff --git a/debian/patches/series b/debian/patches/series
index 06ebc04..a4f35d0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -24,3 +24,4 @@
0028-Fix-hardening-warnings.patch
0029-Generate-hex-in-fix8bit.patch
0030-Display-whole-multibyte-character.patch
+0031-Initialize-table.patch
signature.asc
Description: OpenPGP digital signature
Bug#778869: apt-config-auto-update: upses deprecated options
One more thing perhaps: In /etc/cron.daily/apt they suggest to use: /etc/apt/apt.conf.d/02periodic Of course you're free in the path but perhaps it makes sense to have that aligned? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#778870: TYPO3-CORE-SA-2015-001: Authentication Bypass
Package: typo3-src Severity: grave Tags: security Justification: user security hole Please see here for details: https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2015-001/ Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745082: Bug#763391: chfn and fakechroot
Control: forcemerge 774332 745082 763391 Le vendredi 20 février à 19h 02mn 31s (+0100), John Paul Adrian Glaubitz a écrit : >> PS: I would suggest merging 745082, 763391 and 774332. They seem to >> describe the exact same bug. I agree they look similar, and i'm inclined to think that the problem is with debootstrap itself. I'm doing the merge here into the bug that's open against debootstrap. hopefully it won't need to be split out again in the future :P On Fri 2015-02-20 18:24:18 -0500, jhcha54008 wrote: > May I ask if debootstrap ran in a fakechroot environment or as real root ? I'm curious about this too. Adrian, can you give more details? --dkg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778257: src:qtdeclarative-opensource-src: FTBFS on x32: JIT, symbols
On Fri, Feb 20, 2015 at 12:22:06PM +0300, Dmitry Shachnev wrote:
> On Thu, 12 Feb 2015 23:08:49 +0100, Adam Borowski wrote:
> > The fix needs two parts:
> > * applying the attached patch: fixing misdetection of x32 as i386/amd64
> > (a proper port of the JIT would be of course better, but take a good deal
> > more work)
>
> Can you please send this upstream to https://codereview.qt-project.org/?
I looked at the upstream website, and found it quite confusing. Thus, if
you could forward the patch, it would be nice.
> Or, if you can't do it, tell us that you license the patch under BSD license
> and we will do that ourselves (needed because upstream has a CLA).
Sure. The patch appears to be too small to be copyrightable, but anyway, I
hereby grant the right to use it under any license of your choice.
> > * updating the symbols file. s/!sparc64/!sparc64 !x32/ worked for me, as
> > symbols you skip on every architecture need to be skipped on x32 too
> > (how surprising...)
>
> No longer needed with the current Qt 5.4 packages (in experimental), where
> the symbols mess has been fixed.
I tried to check the patch against the packages in experimental, but one of
dependencies (qtxmlpatterns) failed to build for me, for reasons that don't
seem to be arch-dependent:
CMake Error at
/home/kilobyte/tmp/x32/exp/qtxmlpatterns-opensource-src-5.4.0/lib/cmake/Qt5XmlPatterns/Qt5XmlPatternsConfig.cmake:27
(message):
The imported target "Qt5::XmlPatterns" references the file
"/home/kilobyte/tmp/x32/exp/include/x86_64-linux-gnux32/qt5/"
but this file does not exist. Possible reasons include:
If it's supposed to work, I can poke around more. I wonder, though, if it
would cost less human time to throw the patch in blindly for now.
It does require a change, though. Against sources from experimental it's:
--- src/qml/jsruntime/qv4global_p.h~2014-12-05 17:25:11.0 +0100
+++ src/qml/jsruntime/qv4global_p.h 2015-02-20 19:04:52.201925780 +0100
@@ -69,9 +69,11 @@
//
// NOTE: This should match the logic in qv4targetplatform_p.h!
-#if defined(Q_PROCESSOR_X86) && (defined(Q_OS_WINDOWS) || defined(Q_OS_LINUX)
|| defined(Q_OS_QNX) || defined(Q_OS_FREEBSD))
+#if defined(Q_PROCESSOR_X86) && !defined(__ILP32__) \
+&& (defined(Q_OS_WINDOWS) || defined(Q_OS_LINUX) || defined(Q_OS_QNX) ||
defined(Q_OS_FREEBSD))
#define V4_ENABLE_JIT
-#elif defined(Q_PROCESSOR_X86_64) && (defined(Q_OS_WINDOWS) ||
defined(Q_OS_LINUX) || defined(Q_OS_MAC) || defined(Q_OS_FREEBSD))
+#elif defined(Q_PROCESSOR_X86_64) && !defined(__ILP32__) \
+&& (defined(Q_OS_WINDOWS) || defined(Q_OS_LINUX) || defined(Q_OS_MAC) ||
defined(Q_OS_FREEBSD))
#define V4_ENABLE_JIT
#elif defined(Q_PROCESSOR_ARM_32)
while against upstream's 5.4 git it's:
--- a/src/qml/jsruntime/qv4global_p.h
+++ b/src/qml/jsruntime/qv4global_p.h
@@ -69,9 +69,11 @@ inline double trunc(double d) { return d > 0 ? floor(d) :
ceil(d); }
//
// NOTE: This should match the logic in qv4targetplatform_p.h!
-#if defined(Q_PROCESSOR_X86) && (defined(Q_OS_WIN) || defined(Q_OS_LINUX) ||
defined(Q_OS_QNX) || defined(Q_OS_FREEBSD))
+#if defined(Q_PROCESSOR_X86) && !defined(__ILP32__) \
+&& (defined(Q_OS_WIN) || defined(Q_OS_LINUX) || defined(Q_OS_QNX) ||
defined(Q_OS_FREEBSD))
#define V4_ENABLE_JIT
-#elif defined(Q_PROCESSOR_X86_64) && (defined(Q_OS_WIN) || defined(Q_OS_LINUX)
|| defined(Q_OS_MAC) || defined(Q_OS_FREEBSD))
+#elif defined(Q_PROCESSOR_X86_64) && !defined(__ILP32__) \
+&& (defined(Q_OS_WIN) || defined(Q_OS_LINUX) || defined(Q_OS_MAC) ||
defined(Q_OS_FREEBSD))
#define V4_ENABLE_JIT
#elif defined(Q_PROCESSOR_ARM_32)
(Ie, Q_OS_WIN vs Q_OS_WINDOWS).
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778853: Update to 0.4.12
On 20.02.2015 19:40, Markus Koschany wrote: [...] > Version 0.4.12 was only released a few days ago. I guess I can package > that this weekend. If someone is interested in sponsoring the upload, > the package could then go to experimental as well. I have packaged 0.4.12 now. http://anonscm.debian.org/cgit/?pkg-games/minetest-v04x.git It would be great if we could drop even more patches, but I'm not sure how the current packing could be further improved. signature.asc Description: OpenPGP digital signature
Bug#778712: libparted2: Breakage of RAID GPT header
On Fri, 2015-02-20 at 15:59 -0500, Phillip Susi wrote: > It also shows no GPT either, because it is still seeing the stale > cached data where there is nothing on the drive but zeros. Sure, yes. The fdisk4 output does show GPT info for the RAID device (md126) it just modified, so it is presumably flushing info for only that RAID device upon writing the change (or simply combining the new info it has with the already retrieved cache data), and not bothering to flush anything else. Since the execution of 'fdisk -l' after using fdisk to create the GPT tables does not seem to have flushed the cache of the array members, I would conclude that fdisk does not automatically flush the caches when it feels there may be no point, and thus per your description of parted's behavior, parted must indeed have been responsible for flushing the cache and allowing fdisk to then gain a fresh view of things upon the second run of it. It may be fair to say that in many/most cases there indeed would be no point in fdisk just flushing this info for every disk; even here it would not actually be a problem if only it recognised these disks as members of a RAID array and thus completely ignored them as far as reading partition tables goes. > Right... fdisk flushes the cache on /dev/md127, but not /dev/sdb, > since it isn't operating on /dev/sdb. When you run parted -l, it > walks every disk in the system and as part of reading from each one, > flushes the cache, thus, /dev/sdb has its cache flushed, and reads the > new partition table from the disk. Yeah. I previously had no idea that caching would be involved here. Going back over those fdisk outputs I do notice now that for sdb it is outputting "Disklabel type: dos" when the cache has been flushed. Again, thanks for the help, and patience. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767659: Status
On Sun, 18 Jan 2015 at 21:27:49 +, Simon McVittie wrote: > On 18/01/15 14:34, Neil Williams wrote: > > For the benefit of the bug report, I've tried Simon's patch and I do not > > get the expected results. > > I might be misremembering, but I don't think evince's libevdocument-3-4 > is what used the new symbol in libpoppler: I think it's only > libpoppler-glib (in that particular dependency chain at least) that uses > it. http://codesearch.debian.net/results/getAlternateName/page_0 suggests that this version of events is accurate: we're not trying to prevent partial upgrades of the form new evince, old libpoppler-glib8, old libpoppler46 because evince doesn't call getAlternateName anyway. Rather, we're trying to prevent partial upgrades of the form new libpoppler-glib8, old libpoppler46 for which Neil's test results look fine. > (I don't know why people were doing those partial upgrades in the first > place.) Still no idea about that... S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778869: apt-config-auto-update: upses deprecated options
Package: apt-config-auto-update Version: 1.0.0-2 Severity: normal Hi. apt-config-auto-update uses the options: APT::Archives::MaxAge APT::Archives::MinAge APT::Archives::MaxSize which are however deprecated (see /etc/cron.daily/apt) in favour of: APT::Periodic::MaxAge APT::Periodic::MinAge APT::Periodic::MaxSize Perhaps you should replace these :) Cheers, Chris. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778868: unblock: activemq/5.6.0+dfsg1-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package activemq, the version 5.6.0+dfsg1-4 fixes two security
issues.
Thank you
unblock activemq/5.6.0+dfsg1-4
diff -Nru activemq-5.6.0+dfsg1/debian/changelog
activemq-5.6.0+dfsg1/debian/changelog
--- activemq-5.6.0+dfsg1/debian/changelog 2014-11-21 14:02:18.0
+0100
+++ activemq-5.6.0+dfsg1/debian/changelog 2015-02-18 20:04:41.0
+0100
@@ -1,3 +1,14 @@
+activemq (5.6.0+dfsg1-4) unstable; urgency=high
+
+ * Team upload.
+ * Fixed security issues (Closes: #777196)
+- CVE-2014-3612: JAAS LDAPLoginModule allows empty password authentication
+- CVE-2014-3600: XML External Entity expansion when evaluating XPath
+ expressions
+ * Standards-Version updated to 3.9.6 (no changes)
+
+ -- Emmanuel Bourg Wed, 18 Feb 2015 20:04:38 +0100
+
activemq (5.6.0+dfsg1-3) unstable; urgency=high
* Team upload.
diff -Nru activemq-5.6.0+dfsg1/debian/control
activemq-5.6.0+dfsg1/debian/control
--- activemq-5.6.0+dfsg1/debian/control 2014-09-29 09:26:05.0 +0200
+++ activemq-5.6.0+dfsg1/debian/control 2015-02-18 20:03:58.0 +0100
@@ -55,9 +55,9 @@
libxbean-java-doc,
libxpp3-java,
libxstream-java (>= 1.4)
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
Vcs-Git: git://anonscm.debian.org/pkg-java/activemq.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-java/activemq.git
+Vcs-Browser: http://anonscm.debian.org/cgit/pkg-java/activemq.git
Homepage: http://activemq.apache.org
Package: libactivemq-java
diff -Nru activemq-5.6.0+dfsg1/debian/patches/CVE-2014-3600.patch
activemq-5.6.0+dfsg1/debian/patches/CVE-2014-3600.patch
--- activemq-5.6.0+dfsg1/debian/patches/CVE-2014-3600.patch 1970-01-01
01:00:00.0 +0100
+++ activemq-5.6.0+dfsg1/debian/patches/CVE-2014-3600.patch 2015-02-18
19:42:35.0 +0100
@@ -0,0 +1,239 @@
+Description: Fix CVE-2014-3600: XML External Entity expansion when evaluating
XPath expressions.
+ This patch can be removed after upgrading to ActiveMQ 5.10.1 or later.
+Origin: backport, https://github.com/apache/activemq/commit/b9696ac
+Bug: https://issues.apache.org/jira/browse/AMQ-5333
+---
a/activemq-optional/src/main/java/org/apache/activemq/filter/JAXPXPathEvaluator.java
b/activemq-optional/src/main/java/org/apache/activemq/filter/JAXPXPathEvaluator.java
+@@ -21,11 +21,13 @@
+ import javax.jms.BytesMessage;
+ import javax.jms.JMSException;
+ import javax.jms.TextMessage;
++import javax.xml.parsers.DocumentBuilder;
+ import javax.xml.xpath.XPath;
+ import javax.xml.xpath.XPathConstants;
+ import javax.xml.xpath.XPathExpressionException;
+ import javax.xml.xpath.XPathFactory;
+
++import org.w3c.dom.Document;
+ import org.xml.sax.InputSource;
+
+ import org.apache.activemq.command.Message;
+@@ -61,8 +63,9 @@
+ private boolean evaluate(byte[] data) {
+ try {
+ InputSource inputSource = new InputSource(new
ByteArrayInputStream(data));
+-return ((Boolean)expression.evaluate(inputSource,
XPathConstants.BOOLEAN)).booleanValue();
+-} catch (XPathExpressionException e) {
++Document inputDocument = builder.parse(inputSource);
++return ((Boolean)xpath.evaluate(xpathExpression, inputDocument,
XPathConstants.BOOLEAN)).booleanValue();
++} catch (Exception e) {
+ return false;
+ }
+ }
+@@ -70,8 +73,9 @@
+ private boolean evaluate(String text) {
+ try {
+ InputSource inputSource = new InputSource(new StringReader(text));
+-return ((Boolean)expression.evaluate(inputSource,
XPathConstants.BOOLEAN)).booleanValue();
+-} catch (XPathExpressionException e) {
++Document inputDocument = builder.parse(inputSource);
++return ((Boolean)xpath.evaluate(xpathExpression, inputDocument,
XPathConstants.BOOLEAN)).booleanValue();
++} catch (Exception e) {
+ return false;
+ }
+ }
+---
a/activemq-core/src/main/java/org/apache/activemq/filter/XalanXPathEvaluator.java
b/activemq-core/src/main/java/org/apache/activemq/filter/XalanXPathEvaluator.java
+@@ -25,6 +25,8 @@
+ import javax.xml.parsers.DocumentBuilder;
+ import javax.xml.parsers.DocumentBuilderFactory;
+ import javax.xml.xpath.XPath;
++import javax.xml.xpath.XPathConstants;
++import javax.xml.xpath.XPathFactory;
+
+ import org.w3c.dom.Document;
+ import org.w3c.dom.traversal.NodeIterator;
+@@ -35,13 +37,20 @@
+ import org.apache.xpath.CachedXPathAPI;
+ import org.apache.xpath.objects.XObject;
+
+-
+ public class XalanXPathEvaluator implements XPathExpression.XPathEvaluator {
+
+-private final String xpath;
+-
+-public XalanXPathEvaluator(String xpath) {
+-this.xpath = xpath;
++private static final XPathFactory FACTORY = XPathFactory.newInstance();
++private final
Bug#778867: eeepc-acpi-scripts: Causes video corruption and freezes system when eeepc-acpi-scripts executes
Package: eeepc-acpi-scripts Version: 1.1.12 Severity: important Dear Maintainer, I performed an upgrade of my Asus EeePC 1000 from Squeeze to Wheezy back in November without any particular problems. The upgrade did NOT install the eeepc-acpi-scripts package, but it seemed like an appropiate package to have installed, so I later installed it manually. I later began to experience a problem with video corruption (that I had never experienced before) when the system was booting. It was not reproducible, occurring perhaps 25% of the time. As the problem was random in nature, I did not initially suspect the eeepc-acpi-scripts package was related to the problem. The corruption is best described as colored "snow" with *nothing* intelligible on the screen. None of the Alt-Fn keys would bring up another VT, I could not login remotely using ssh. I could not coax the system to perform a clean shutdown either, pressing the power button, or hitting ctrl-alt-del did nothing. All I could do was power down and reboot. The freezes were nasty enough that my /var/log directory got thoroughly trashed on one occassion, with about 20 log files ending up in /lost+found as a result of problems found by fsck on the reboot. It's worth noting that this video corruption also happened (just once) during a system *shutdown* after the X11 server exited. The messages at boot fly by so fast, so I installed bootlogd to better understand the normal boot sequence. At that point, it became obvious that when this problem happened it was when the eeepc-acpi-scripts in /etc/init was executed. After purging eeepc-acpi-scripts from my system, I have *not* seen the problem after well more than 20 boots. Sorry I can't provide more helpful information, but /var/log/messages and so forth contained nothing useful. My system has slightly modified hardware: ASUS EeePC 1000 (straight 1000, no letter suffix) Intel Ultimate N WiFi Link 5300 (replaced the factory wifi card) Upgraded to 2GB of RAM -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Versions of packages eeepc-acpi-scripts depends on: ii acpi-support 0.140-5+deb7u3 ii acpi-support-base 0.140-5+deb7u3 ii acpid 1:2.0.16-1+deb7u1 ii initscripts2.88dsf-41+deb7u1 ii pm-utils 1.4.1-9 ii rfkill 0.4-1 eeepc-acpi-scripts recommends no packages. Versions of packages eeepc-acpi-scripts suggests: ii alsa-utils 1.0.25-4 pn libnotify-bin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745082: chfn and fakechroot
Le vendredi 20 février à 19h 02mn 31s (+0100), John Paul Adrian Glaubitz a écrit : > Hi! > > I am running into the exact same problem when trying to create a > unstable chroot using debootstrap on one of our sh4 machines > using the following command line: > > debootstrap --no-check-gpg --include=apt,nano,aptitude,vim unstable > unstable-sh4-20150220-3 ftp://ftp.debian-ports.org/debian > > With the error message being: > > Setting up systemd (215-12) ... > Initializing machine ID from random generator. > chfn: PAM: Critical error - immediate abort > adduser: `/usr/bin/chfn -f systemd Time Synchronization > systemd-timesync' returned error code 1. Exiting. > dpkg: error processing package systemd (--configure): > subprocess installed post-installation script returned error exit status 1 > > The problem are apparently the missing quotes in the above command: > > root@yamato:/# /usr/bin/chfn -f systemd Time Synchronization > systemd-timesync > chfn: user 'Time' does not exist > root@yamato:/# > > Adding them fixes the problem: > > root@yamato:/# /usr/bin/chfn -f "systemd Time Synchronization" > systemd-timesync > root@yamato:/# > > I checked the systemd postinst and this script does indeed contain > quotes. For some reasons which I don't understand, adduser invokes > chfn in during the debootstrap process without the quotes. > > And what's even more crazy, the exact same command line does work > on m68k or amd64 machines, for example. The sh4 machine is up-to-date, > so it can be outdated packages either (unless I overlooked something). > > Any ideas? > > PS: I would suggest merging 745082, 763391 and 774332. They seem to > describe the exact same bug. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Hi, May I ask if debootstrap ran in a fakechroot environment or as real root ? Regards, JH Chatenet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721513: can you re-test with scdaemon 2.1.2 from experimental?
Tags: 721513 + moreinfo Hi there-- In https://bugs.debian.org/721513, you reported that scdaemon needed a workaround configuration setting to use the pinpad on your smartcard. Is this still the case with scdaemon 2.1.2 ? I'm sorry i don't have such a smartcard to test myself. --dkg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776276: unblock: open-iscsi/2.0.873+git0.3b4b4500-4
Hello Release Team, The last uploaded package is now 9 days old and hasn't migrated to Jessie. Does it not qualify for an exception at this timeline now ? On 01/31/2015 04:00 PM, Ritesh Raj Sarraf wrote: > > Thanks. I'll upload a new revision later today > > s3nt fr0m a $martph0ne, excuse typ0s > -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." signature.asc Description: OpenPGP digital signature
Bug#778822: patch for handling non ASCII and non UTF8 headers in headache
On Fri, Feb 20, 2015 at 05:23:04PM +0100, Virgile Prevosto wrote: > > I guess I still kind of hoped that the issue would be propagated to > Debian at some point, but I can understand that it wasn't important > enough to be handled by Ubuntu's bug managers > Sure. No problem. Do not hesitate to submit bugs directly to Debian next time. The only issue would be to reproduce the problem on a Debian machine, which is generally easy with OCaml packages (well, as long as there is not fishy binding stuff involved). Kind regards, -- Mehdi Dogguy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778841: Received an email from one of the sflphone developers
Seems like a dirver bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745901 https://bugzilla.redhat.com/show_bug.cgi?id=1054435 seems like there is a possible workaround: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745901#41 I can confirm removing fglrx and using the opensource ATI driver fixed the problem. I didnt have this problem in Arch Linux so maybe the bug is already fixed upstream in a newer version of fglrx or clutter.
Bug#778747: [Pkg-openssl-devel] Bug#778747: openssl: RFC 7465 says RC4 is broken, never to be used
On Fri, Feb 20, 2015 at 10:08:48PM +0100, Florian Schlichting wrote: > On Fri, Feb 20, 2015 at 06:25:44PM +0100, Kurt Roeckx wrote: > > On Fri, Feb 20, 2015 at 06:10:59PM +0100, Florian Schlichting wrote: > > > What servers, and what clients are we talking about here? > > > > You might want to look at those stats: > > https://lists.fedoraproject.org/pipermail/security/2015-February/002069.html > > I did, it's only about web servers and the numbers are not so different > from the ones I quoted, so it only serves to reinforce my earlier > argument, no? > > | RC4 still remains as the 3rd most popular cipher, despite loosing 1.3% > | share, at 80.5%. While servers that support only RC4 ciphers lost only > | 0.07% it places them at an all time low of 0.79% (3712 servers). Still > | a large part (13.8%) of servers prefer RC4 even if client supports > | better ciphers, a drop of only 1.4%. Significant number of servers > | also force RC4 in TLS1.1 or TLS1.2: 8.75% (drop of 0.7%). > > | Supported Ciphers Count Percent > | -+-+--- > ... > | RC4 3880.5871 > | RC4 Only 3712 0.7918 > | RC4 Preferred 64613 13.7832 > | RC4 forced in TLS1.1+ 41031 8.7527 > | x:FF 29 RC4 Only 541 0.1154 > | x:FF 29 RC4 Preferred 70622 15.065 > | x:FF 29 incompatible 136 0.029 > ... One of the probloms is those servers that currently prefer/force RC4 if it's available. That is administrators who have actually configured things in such a way. Removing RC4 from the default will not fix any of them. It's that 13.7% that is the problem. Please note that that 80% is those servers that support it, it doesn't say 80% of the connections will use that cipher. Removing RC4 from the default will most likely result in that percentage dropping but will have very little effect on the negiotated cipher. The ssl-pulse stats might look more useful for that, since it says 23.3% of the modern browsers will negiotate an RC4 cipher. But it tests far less servers. In any case both see the stats drop in the order of 1% per month. Please note that RC4 in the default configuration should never be negiotated by modern clients and servers. The problem is administrators who think they know better changed somethign not to use the defaults. If we adjust the defaults it's not going to fix anything. I consider the support of SSLv3 a more serious problem. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775456: ITP: qt-solutions -- libqtsingleapplication0: support for starting applications only once
Control: retitle 641812 ITP: qt-solutions -- libqtsingleapplication0: support for starting applications only once Control: owner 641812 ! Control: blocks 775456 by 641812 On Sat, Sep 17, 2011 at 11:12:09AM +0200, Sune Vuorela wrote: > On Saturday 17 September 2011 01:45:41 you wrote: > > An alternative would be to merge the relevant code into Sankore's main > > source, and tagging this obsoleted code as a candidate to be replaced as > > soon as possible. Is that solution better? > > Given that the QtSolution code is more example code than library code, I > think > that this is a better solution, yes, and it is also my recommendation to > other > users of QtSolution code. Not sure it’s a good idea to provide multiple convenience code copies in many places, but I may be missing something obvious. > My next suggestion would be to convert the bits that aren't in Qt proper into > proper libraries and use them and package them as such. My intent, while taking over this ITP, is simply to provide qtsingleapplication as a start (as needed by sankore, #775456). If other modules are worth packaging/sharing, it should be pretty easy to enlarge the build process for them. I’ll soon push a repository in alioth as debian-edu/pkg-team/qt-solutions.git, but don’t mind moving it to collab-maint or anywhere people wish once other modules are wanted. > The things that might be reasonable as actual libraries would be > - qtsoap (even though it is a quite bad soap implementation) > - qtsingleapplication > - qtcolor* > - qtpiemenu > - qtmmlwidget > - qtiocompressor > - qtservice > - qtlockedfile > > But it requires work to get these to a standard where they are worth using as > libraries. Regards David signature.asc Description: Digital signature
Bug#778815: [Pkg-xfce-devel] Bug#778815: lightdm: Fails load login screen with large ldap users database
On ven., 2015-02-20 at 09:31 +0100, Massimo BARBIERI wrote: > I have a Debian 8 client that authenticate users over an open-ldap > database. This has been done with libnss-ldapd libpam-ldapd nslcd. The > users database is huge and includes thousands of users. The problem is > that lightdm seems to try to download the complete lists of the users > and it fails to load the login screen. Do you use the userlist (greeter-hide-users=false in lightdm.conf)? That looks like #722317 anyway. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#770453: ufw: [INTL:pt_BR] Brazilian Portuguese debconf templates translation
Thank you for the translation. This has been added to bzr and will be in the next upload. -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature
Bug#767117: ufw: default settings after install block all connectivity
Thanks for the bug report. What is the output of: # /usr/share/ufw/check-requirements -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature
Bug#777150: ufw: Hi, adde a custom rule with geoip iptables modules wont load from ufw.
Thank you for the detailed report. The problem seems to be with iptables-restore and not ufw itself. Specifically, iptables-restore doesn't like the single quotes in '[UFW COUNTRY BLOCK] '. Therefore, add this instead to before.rules: -A ufw-before-input -m geoip --src-cc KR,CN,IN,RU,TR,VN,UA,BR,VE,JP -m limit --limit 3/minute -j LOG --log-level 4 --log-prefix "[UFW COUNTRY BLOCK] " -A ufw-before-input -m geoip --src-cc KR,CN,IN,RU,TR,VN,UA,BR,VE,JP -j DROP I'm not sure why iptables-restore is so particular here, but the various *.rules files are fed into iptables-restore directly without modification. After doing that I can 'ufw disable' and 'ufw enable' and it all works fine. After reboot I have: $ sudo iptables -t filter -nL ufw-before-input Chain ufw-before-input (1 references) target prot opt source destination ... LOGall -- 0.0.0.0/00.0.0.0/0-m geoip --source-country KR,CN,IN,RU,TR,VN,UA,BR,VE,JP limit: avg 3/min burst 5 LOG flags 0 level 4 prefix "[UFW COUNTRY BLOCK] " DROP all -- 0.0.0.0/00.0.0.0/0-m geoip --source-country KR,CN,IN,RU,TR,VN,UA,BR,VE,JP ufw-user-input all -- 0.0.0.0/00.0.0.0/0 Note, I was thinking you might need to add xt_geoip to IPT_MODULES in /etc/default/ufw, but they seemed to have autoloaded fine on boot. -- Jamie Strandboge http://www.ubuntu.com/ signature.asc Description: OpenPGP digital signature
Bug#773155: hello here is a screenshot of the gimp problem
Bug#778747: [Pkg-openssl-devel] Bug#778747: openssl: RFC 7465 says RC4 is broken, never to be used
On Fri, Feb 20, 2015 at 06:25:44PM +0100, Kurt Roeckx wrote: > On Fri, Feb 20, 2015 at 06:10:59PM +0100, Florian Schlichting wrote: > > What servers, and what clients are we talking about here? > > You might want to look at those stats: > https://lists.fedoraproject.org/pipermail/security/2015-February/002069.html I did, it's only about web servers and the numbers are not so different from the ones I quoted, so it only serves to reinforce my earlier argument, no? | RC4 still remains as the 3rd most popular cipher, despite loosing 1.3% | share, at 80.5%. While servers that support only RC4 ciphers lost only | 0.07% it places them at an all time low of 0.79% (3712 servers). Still | a large part (13.8%) of servers prefer RC4 even if client supports | better ciphers, a drop of only 1.4%. Significant number of servers | also force RC4 in TLS1.1 or TLS1.2: 8.75% (drop of 0.7%). | Supported Ciphers Count Percent | -+-+--- ... | RC4 3880.5871 | RC4 Only 3712 0.7918 | RC4 Preferred 64613 13.7832 | RC4 forced in TLS1.1+ 41031 8.7527 | x:FF 29 RC4 Only 541 0.1154 | x:FF 29 RC4 Preferred 70622 15.065 | x:FF 29 incompatible 136 0.029 ... => Disabling RC4 leads to better ciphers being used accross the board. Leaving it on will lead to RC4 still being used in a surprising number of cases even though better ciphers would be available. There is a small and slowly shrinking number of web servers that support nothing else, but see my remarks about web browsers in my previous email. Florian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778866: videotrans: movie-title terminates without doing anything
Package: videotrans Version: 1.6.1-2 Severity: grave Justification: renders package unusable I converted to mp4 files with "movie-to-dvd movie1.mp4 movie2.mp4". I made a background with "movie-make-title-simple -o title -m pal" Then I tried to create the .vob with "movie-title -o title.vob -t title movie1.m2v movie2.m2v", but that didn't have any effect. "Not having any effect" means that there was no output or files generated or anything else. Tje program just stops imediately without any message and the exit code 1. Doing some debugging I figured out that the script terminates at a read in line 279, but couldn't figure out why. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages videotrans depends on: ii dvdauthor 0.7.0-1.3 ii imagemagick 8:6.8.9.9-5 ii libav-tools 6:11.2-1 ii libc6 2.19-13 ii mjpegtools 1:2.1.0+debian-3 ii mplayer2 [mplayer] 2.0-728-g2c378c7-4+b1 videotrans recommends no packages. videotrans suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#617222: Patch
Hi there, Am 31.07.2013 um 14:48 schrieb Jan Wagner: > attached is a patch to use the /usr/share/mysql/mysqld_multi.server as > drop in replacement. Maybe the Provides-header needs to be adjusted. find attached a patch against the latest master branch of the debian package. Maybe the description needs some more tweaking. It's based on https://github.com/waja/mysql-5.5/tree/mysqld_multi Cheers, Jan. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK-- From 118ca7079a4eaf603abf8c72a3d986aeda810d1a Mon Sep 17 00:00:00 2001 From: Jan Wagner Date: Fri, 20 Feb 2015 21:38:00 +0100 Subject: [PATCH] Adding mysqld_multi.server_lsb-header.patch, provides LSB headers for example initscript (Closes: #617222) --- .../patches/mysqld_multi.server_lsb-header.patch | 29 ++ debian/patches/series | 1 + 2 files changed, 30 insertions(+) create mode 100644 debian/patches/mysqld_multi.server_lsb-header.patch diff --git a/debian/patches/mysqld_multi.server_lsb-header.patch b/debian/patches/mysqld_multi.server_lsb-header.patch new file mode 100644 index 000..0f9b5da --- /dev/null +++ b/debian/patches/mysqld_multi.server_lsb-header.patch @@ -0,0 +1,29 @@ +--- a/support-files/mysqld_multi.server.sh b/support-files/mysqld_multi.server.sh +@@ -14,8 +14,24 @@ + # Version 1.0 + # + +-basedir=/usr/local/mysql +-bindir=/usr/local/mysql/bin ++### BEGIN INIT INFO ++# Provides: mysql ++# Required-Start:$remote_fs $syslog ++# Required-Stop: $remote_fs $syslog ++# Should-Start: $network $time ++# Should-Stop: $network $time ++# Default-Start: 2 3 4 5 ++# Default-Stop: 0 1 6 ++# Short-Description: Start and stop multiple mysql database server daemon instances ++# Description: Controls multiple MySQL database server daemon instances ++### END INIT INFO ++ ++PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin ++NAME=mysqld_multi ++DESC=mysqld_multi ++ ++basedir=/usr ++bindir=/usr/bin + + if test -x $bindir/mysqld_multi + then diff --git a/debian/patches/series b/debian/patches/series index eab07fc..42c20f9 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -14,3 +14,4 @@ fix-mips64el-ftbfs.patch 50_mysql-test__db_test.patch fix-mysqlhotcopy-test-failure.patch mysqld_multi_confd.patch +mysqld_multi.server_lsb-header.patch signature.asc Description: OpenPGP digital signature
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/20/2015 3:44 PM, jnqnfe wrote: > I agree now that this might just be an fdisk caching issue, but I > don't think this bit is quiet as you describe. The actions taken > and results were as follows: 1) RAID array recreated. 2) fdisk used > to create GPT table on md126. 3) fdisk -l, showing no issues and no > info from MBR. It also shows no GPT either, because it is still seeing the stale cached data where there is nothing on the drive but zeros. > 4) parted -l, pointing out corrupt GPT table. 5) fdisk -l, now > showing info from the MBR and the error. > > So on the basis that fdisk is writing the same protected MBR that > parted does, it seems fdisk is failing to flush it's cache and see > the problem when asked to display info immediately following > creation of the partition tables. Then, either parted triggered a > cache flush (shared cache I presume?), or else fdisk managed to > flush the cache the second time around. > > So in conclusion, this whole confusing mess resulted from a > combination of: 1) parted being incapable of understanding RAID > array membership. 2) fdisk also being incapable of understanding > RAID array membership. 3) fdisk failing to flush a cache of > partition info. Right... fdisk flushes the cache on /dev/md127, but not /dev/sdb, since it isn't operating on /dev/sdb. When you run parted -l, it walks every disk in the system and as part of reading from each one, flushes the cache, thus, /dev/sdb has its cache flushed, and reads the new partition table from the disk. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU56AZAAoJENRVrw2cjl5RrtEIAJ+RgE2yKuIY+a3YeuF9ctyT xfZi6Uzdcz2UfaM1iWvJzdd6IUDgnDztajO4RYgl/XlMjS6efXtO3YixKsUI1Ajt 1Iv4rhPt2Asd+yFCX8fNkA6aGhvTGuHBvf21uWfUZRv05NC8ck7ro8d21RObQDsk KX5/c/PW3GTJDq1OrQsYygFCoFOocc5w60bu3vcHbGU7WPp561FTrQ4R4Sk1oZaH ln7W+QtfV+wYg7DnjvdMh2YRrIGfk3IoV4GibIFkn+6X5numGBs/O9/f8Q+4DyJC naMHOTQAGdzF5VxlNukeCkC7JlWPzEV1sFzxlB/DRhzb/F1Y8MGKCsLZexHEmSE= =kD25 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766922: xserver-xorg-video-radeon: resume from suspend/hibernate results in blank screen kernel > 3.16
Hi, Should this perhaps be reassigned to the linux kernel, since it seems tied to changes in kernel rather than in Xorg code? I experience what seems to be this same bug, on two quite similar laptops: Acer Aspire One 725 C6Ckk: lspci: [AMD/ATI] Wrestler [Radeon HD 6290] Xorg: "AMD Radeon HD 6200 Series Graphics" (ChipID = 0x9807) Acer Aspire One 725 C7Xkk: lspci: [AMD/ATI] Wrestler [Radeon HD 7290] Xorg: "PALM" (ChipID = 0x980a) Most recent working unstable/testing kernel is linux-image-3.14-2-amd64 3.14.15-2 - and problem goes away with the experimental linux-image-3.19.0-trunk-amd64 3.19-1~exp1. Here's a diff of Xorg logs from boot till after a sleep and wakeup comparing working and broken kernels, trimmed to leave out seemingly irrelevant info: --- 3.14.2/post-sleep/dmesg. +++ 3.18.0/post-sleep/dmesg. @@ -1,8 +1,9 @@ -Linux version 3.14-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-7) ) #1 SMP Debian 3.14.15-2 (2014-08-09) +Linux version 3.18.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 3.18.5-1~exp1 (2015-01-31) +ACPI: Early table checksum verification disabled -ACPI: IRQ2 used by override. -nr_irqs_gsi: 40 -NR_IRQS:33024 nr_irqs:712 16 +NR_IRQS:33024 nr_irqs:456 0 +Initializing cgroup subsys net_prio -tlb_flushall_shift: 6 +ftrace: allocating 21993 entries in 86 pages -bio: create slab at 0 -ACPI: No dock devices found. +vgaarb: setting as boot device: PCI::00:01.0 -ACPI: bus type PNP registered -pnp 00:01: Plug and Play ACPI device, IDs PNP0103 (active) -pnp 00:02: [dma 4] -pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active) -pnp 00:03: Plug and Play ACPI device, IDs PNP0c04 (active) -pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active) -pnp: PnP ACPI: found 10 devices +pnp: PnP ACPI: found 6 devices -ACPI: bus type PNP unregistered -pci :00:01.0: Boot video device +pci :00:01.0: Video device with shadowed ROM +zpool: loaded +ledtrig-cpu: registered to indicate activity on CPUs +radeon :00:01.0: radeon: MSI limited to 32-bit -bio: create slab at 1 +Process accounting resumed +rtc_cmos 00:01: System wakeup disabled by ACPI Tell me if useful that I produce similar against working 3.19 kernel, or if some other info is helpful. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778864: kde-baseapps: Include necessary patch for ownclouds dolphin plugin
Package: kde-baseapps
Version: 4:4.14.2-1
Severity: normal
Tags: patch
Hey,
With the opcomming owncloud-client 1.8.0, it also ships a plugin for
dolphin and dophin-kf5. But owncloud-client needs a patch in
kde-baseapps for a working plugin.
It would be great if that patch can be part of the debian kde-baseapps
packages.
regads,
sandro
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (600, 'unstable'), (500, 'testing'), (500, 'stable'), (110,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.19-0.towo-siduction-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages kde-baseapps depends on:
ii dolphin 4:4.14.2-1
ii kde-baseapps-bin 4:4.14.2-1
ii kdepasswd 4:4.14.2-1
ii kfind 4:4.14.2-1
ii konqueror 4:4.14.2-1
ii konsole 4:4.14.2-1
ii kwrite4:4.14.2-2
ii plasma-widget-folderview 4:4.14.2-1
Versions of packages kde-baseapps recommends:
ii konqueror-nsplugins 4:4.14.2-1
kde-baseapps suggests no packages.
-- debconf-show failed
>From 3a26dc77f8e988ea99b23c4d5a2c831ecc31c920 Mon Sep 17 00:00:00 2001
From: Olivier Goffart
Date: Thu, 17 Jul 2014 13:26:56 +0200
Subject: [PATCH] WIP: add KOverlayIconPlugin
---
.../src/kitemviews/kfileitemmodelrolesupdater.cpp | 35 -
.../src/kitemviews/kfileitemmodelrolesupdater.h| 9
lib/konq/CMakeLists.txt| 4 +-
lib/konq/koverlayiconplugin.cpp| 30
lib/konq/koverlayiconplugin.desktop| 4 ++
lib/konq/koverlayiconplugin.h | 57 ++
6 files changed, 137 insertions(+), 2 deletions(-)
create mode 100644 lib/konq/koverlayiconplugin.cpp
create mode 100644 lib/konq/koverlayiconplugin.desktop
create mode 100644 lib/konq/koverlayiconplugin.h
diff --git a/dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp b/dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp
index 0865d40..840a65d 100644
--- a/dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp
+++ b/dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp
@@ -28,9 +28,11 @@
#include
#include
#include
+#include
#include "private/kpixmapmodifier.h"
#include "private/kdirectorycontentscounter.h"
+#include
#include
#include
@@ -129,6 +131,17 @@ KFileItemModelRolesUpdater::KFileItemModelRolesUpdater(KFileItemModel* model, QO
m_directoryContentsCounter = new KDirectoryContentsCounter(m_model, this);
connect(m_directoryContentsCounter, SIGNAL(result(QString,int)),
this, SLOT(slotDirectoryContentsCountReceived(QString,int)));
+
+
+const KService::List pluginServices = KServiceTypeTrader::self()->query("KOverlayIconPlugin");
+
+for (KService::List::ConstIterator it = pluginServices.constBegin(); it != pluginServices.constEnd(); ++it) {
+KOverlayIconPlugin* plugin = (*it)->createInstance(this);
+if (plugin) {
+m_overlayIconsPlugin.append(plugin);
+connect(plugin, SIGNAL(overlaysChanged(KUrl,QStringList)), this, SLOT(slotOverlaysChanged(KUrl,QStringList)));
+}
+}
}
KFileItemModelRolesUpdater::~KFileItemModelRolesUpdater()
@@ -1075,7 +1088,11 @@ QHash KFileItemModelRolesUpdater::rolesData(const KFileIte
data.insert("type", item.mimeComment());
}
-data.insert("iconOverlays", item.overlays());
+QStringList overlays = item.overlays();
+foreach(KOverlayIconPlugin *it, m_overlayIconsPlugin) {
+overlays.append(it->getOverlays(item));
+}
+data.insert("iconOverlays", overlays);
#ifdef HAVE_BALOO
if (m_balooFileMonitor) {
@@ -1086,6 +1103,22 @@ QHash KFileItemModelRolesUpdater::rolesData(const KFileIte
return data;
}
+void KFileItemModelRolesUpdater::slotOverlaysChanged(const KUrl& url, const QStringList &)
+{
+KFileItem item = m_model->fileItem(url);
+if (item.isNull())
+return;
+int index = m_model->index(item);
+QHash data = m_model->data(index);
+QStringList overlays = item.overlays();
+foreach(KOverlayIconPlugin *it, m_overlayIconsPlugin) {
+overlays.append(it->getOverlays(item));
+}
+data.insert("iconOverlays", overlays);
+m_model->setData(index, data);
+}
+
+
void KFileItemModelRolesUpdater::updateAllPreviews()
{
if (m_state == Paused) {
diff --git a/dolphin/src/kitemviews/kfileitemmodelrolesupdater.h b/dolphin/src/kitemviews/kfileitemmodelrolesupdater.h
index a9e979a..6d3add0 100644
--- a/dolphin/src/kitemviews/kfileitemmodelrolesupdater.h
+++ b/dolphin/src/kitemviews/kfileitemmodelrolesupdater.h
@@ -32,6 +32,7 @@
#include
#include
+class KOverlayIconPlugin;
class KDirectoryContentsCounter;
class KFileItemModel;
Bug#778865: tiger: "check_runprocs.out.*" not include in mail report
Package: tiger Version: 1:3.2.3-12.1 Severity: normal Hi, Sorry my bad English # Checking running processes --FAIL-- [misc020f] The process 'vsftpd' has not been found running in the processes table. -- System Information: Debian Release: 8.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tiger depends on: ii binutils 2.24.90.20141023-1 ii bsdmainutils 9.0.6 ii debconf [debconf-2.0] 1.5.55 ii libc6 2.19-13 ii net-tools 1.60-26+b1 ii ucf3.0030 Versions of packages tiger recommends: pn chkrootkit ii exim4-daemon-light [mail-transport-agent] 4.84-7 pn john pn tripwire | aide Versions of packages tiger suggests: ii lsof 4.86+dfsg-1 -- debconf information: tiger/policy_adapt: tiger/mail_rcpt: root -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#637108: [debian-mysql] Bug#637108: mysqld_multi missing conf
Hi Norvald,
Am 20.02.2015 um 09:01 schrieb Norvald H. Ryeng:
> Thanks for the patch! I think we should fix this in jessie.
>
> Because of the new my.cnf setup (splitting MySQL, MariaDB and Percona),
> it should include /etc/mysql/mysql.conf.d/, too. The directory
> /etc/mysql/conf.d/ is now for client side settings, while
> /etc/mysql/{mysql|mariadb|percona}.conf.d/ is for server side settings.
>
> Unfortunately, the patch only covers one layer of includes, but I guess
> that's better than nothing. A proper fix would be to follow nested
> includes, but we'll have to wait for an upstream fix for that.
>
> As soon as there's an upstream fix, we can backport the patch, but that
> would probably be too late for jessie. I'm poking people upstream to
> increase priority and speed things up a bit.
find attached a patch against the latest master branch of the debian
package.
It's based on https://github.com/waja/mysql-5.5/tree/mysqld_multi
Cheers, Jan.
--
Never write mail to , you have been warned!
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS
PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
--END GEEK CODE BLOCK--
From 339908bc6feb5458d58e7fb404f2cc0c6304625f Mon Sep 17 00:00:00 2001
From: Jan Wagner
Date: Fri, 20 Feb 2015 20:36:35 +0100
Subject: [PATCH] Adding mysqld_multi_confd.patch, makes mysqld_multi reading
conf.d (Closes: #637108)
---
debian/patches/mysqld_multi_confd.patch | 10 ++
debian/patches/series | 1 +
2 files changed, 11 insertions(+)
create mode 100644 debian/patches/mysqld_multi_confd.patch
diff --git a/debian/patches/mysqld_multi_confd.patch b/debian/patches/mysqld_multi_confd.patch
new file mode 100644
index 000..ea62c8a
--- /dev/null
+++ b/debian/patches/mysqld_multi_confd.patch
@@ -0,0 +1,10 @@
+--- a/scripts/mysqld_multi.sh
b/scripts/mysqld_multi.sh
+@@ -487,6 +487,7 @@
+'@sysconfdir@/my.cnf',
+($ENV{MYSQL_HOME} ? "$ENV{MYSQL_HOME}/my.cnf" : undef),
+$opt{'extra-file'},
++ ,
+($ENV{HOME} ? "$ENV{HOME}/.my.cnf" : undef));
+ }
+
diff --git a/debian/patches/series b/debian/patches/series
index 14d8b17..eab07fc 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -13,3 +13,4 @@ fix-mips64el-ftbfs.patch
41_scripts__mysql_install_db.sh__no_test.patch
50_mysql-test__db_test.patch
fix-mysqlhotcopy-test-failure.patch
+mysqld_multi_confd.patch
signature.asc
Description: OpenPGP digital signature
Bug#778712: libparted2: Breakage of RAID GPT header
Control: severity -1 normal Control: close -1 thanks On Fri, 2015-02-20 at 15:12 -0500, Phillip Susi wrote: > I'm sorry; I misread what you said. I thought you said you had > removed the information about the individual disks that were members > of the array. No problem. > At this point the array contains a protective MBR that lists one > partition of type ee that occupies the whole array. Fdisk looks at > sdb and sees the same thing. Following the MBR is the GPT, part of > which is missing from sdb, so fdisk treats it as corrupt, and falls > back to printing only the MBR. Yes, I'm with you. > > So the phantom sdb1 device was not there when only fdisk was used > > (fdisk4), but does appear after using parted, whether using parted > > to create the partition table (fdisk 2, fdisk3), or as in the last > > test, only to view information (parted -l) after using fdisk > > (fdisk5). > > I see now. I think you are running into a cache aliasing issue here. > That is to say, that the MBR of sdb was read into the cache while the > drive was still blank, and when parted creates the gpt on the array, > it does in fact create that protective mbr partition, but fdisk does > not see it on sdb yet, since it is still holding the cached data from > earlier. Note that at this point fdisk reports that there is no > partition table of any kind, not just no sdb1. If you run blockdev > --flushbufs and then repeat the fdisk -l, sdb1 should show up. I agree now that this might just be an fdisk caching issue, but I don't think this bit is quiet as you describe. The actions taken and results were as follows: 1) RAID array recreated. 2) fdisk used to create GPT table on md126. 3) fdisk -l, showing no issues and no info from MBR. 4) parted -l, pointing out corrupt GPT table. 5) fdisk -l, now showing info from the MBR and the error. So on the basis that fdisk is writing the same protected MBR that parted does, it seems fdisk is failing to flush it's cache and see the problem when asked to display info immediately following creation of the partition tables. Then, either parted triggered a cache flush (shared cache I presume?), or else fdisk managed to flush the cache the second time around. So in conclusion, this whole confusing mess resulted from a combination of: 1) parted being incapable of understanding RAID array membership. 2) fdisk also being incapable of understanding RAID array membership. 3) fdisk failing to flush a cache of partition info. I'll reduce the severity of this bug report and close it now then. Thank you for helping get to the bottom of this. I will try to do a little further testing tomorrow to try and nail down more precise details of the caching behaviour, and then report that along against fdisk with a request for fdisk to also add understanding of RAID array membership. Thanks again :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778269: packaging for mkdocs -- vcs?
Hi Brian, thanks for working on packaging mkdocs. I wondered if I could fetch current state of packaging from somewhere (sorry if I have missed it in the report) -- wanted to give it a try. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778862: ispell: please make building .hash files reproducible
> [2]: https://packages.debian.org/jessie/lava-server Sorry, I pasted the wrong link. The correct one is: [2]: https://reproducible.debian.net/iitalian signature.asc Description: OpenPGP digital signature
Bug#778852: RFS: ismrmrd/1.2.1-1 [ITP #732360] -- ISMRM Raw Data Format.
Thanks Andreas, Can I ask you to re-upload ismrmrd please ? I forgot to change the maintainer field to d-med, but more importantly, did not license the debian/ folder under a license compatible with upstream, which could cause problems with patches in the future. Thanks ! For the D-M application, I am seriously considering it. Cheers, 2015-02-20 17:36 GMT+00:00 Andreas Tille : > Hi Ghislain, > > On Fri, Feb 20, 2015 at 05:05:50PM +, Ghislain Vaillant wrote: > > I have added an entry to the SoB tasks [1]. > > > > However, I cannot access the blends svn repository to update the imaging > > task file. > > Since I am a member of d-med on Alioth, I am supposed to have access, > right > > ? > > The following user groups have commit permissions: > > 1. Debian Developers > 2. Members of Blends team > > This has advantages and disadvantages - you have hit the latter. :-) > If you want to have commit permissions you can join group 1. (we talked > about this recently ;-)) or 2. (which is simple). Or you simply ask me > to commit something like this: > > $ svn diff > Index: imaging > === > --- imaging (Revision 4142) > +++ imaging (Arbeitskopie) > @@ -542,6 +542,8 @@ > > Depends: mia-tools, mialmpick, mia-viewit > > +Depends: ismrmrd-tools > + > ; Added by blends-inject 0.0.7. [Please note here if modified manually] > Suggests: connectomeviewer > Published-Authors: Gerhard S, Daducci A, Lemkaddem A, Meuli R, Thiran J-P > and Hagmann P > Index: imaging-dev > === > --- imaging-dev (Revision 4136) > +++ imaging-dev (Arbeitskopie) > @@ -169,3 +169,5 @@ > Depends: libedf-dev > > Depends: python-imageio > + > +Depends: libismrmrd-dev > > > ... which I did right now. > > > Thanks for your work on this > >Andreas. > > -- > http://fam-tille.de >
Bug#751909: ITP: libasr -- asynchronous DNS resolver
A preliminary copy of the package may be found under collab-maint; I intend to upload to NEW in the near future. http://anonscm.debian.org/cgit/collab-maint/libasr.git/ —RAK -- |_)|_/ Ryan Kavanagh | Debian Developer | \| \ http://ryanak.ca/ | GPG Key 4A11C97A signature.asc Description: Digital signature
Bug#777421: Not an RC bug
Control: severity -1 important I believe this isn't a RC bug, as it not seem to fall in any of these categories: == * makes unrelated software on the system (or the whole system) break * causes serious data loss * introduces a security hole on systems where you install the packages (these issues are "critical" severity) * makes the package in question unusable or mostly so * causes data loss * introduces a security hole allowing access to the accounts of users who use the package (these issues are "grave" severity) * in the maintainer's opinion, makes the package unsuitable for release (these issues are "serious" severity) === (package can still be used with tcpdump data) more info: https://release.debian.org/jessie/rc_policy.txt -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/20/2015 12:17 PM, jnqnfe wrote: > What? I very carefully went through every one of them before > sending to ensure that only information about the array (md126) and > the array members (sdb and sdc) were included. I have just checked > back over every one of those files attached to the original bug > report and none of them contain any info about sda. I'm sorry; I misread what you said. I thought you said you had removed the information about the individual disks that were members of the array. >> sdb1 shows up in fdisk2. > > Yes, but please review the initial bug report for when I created > each of the output files. I ran three tests using different tools > to create the GPT headers, first with gparted, then with parted, > then with fdisk. Before each test I deleted and recreated the RAID > array to try and achieve a fresh start (which checking fdisk and > parted info after doing so confirmed was a successful means of > resetting things). Files fdisk1 and parted1 demonstrate the state > of things directly after recreating the RAID array, without yet > attempting to write the partition table. Yes, at this point the disk is blank. > So, fdisk2 and parted2 show the state of things after using gparted > to write a GPT table to the array, and thus this phantom sdb1 > device exists, which fdisk doesn't like. At this point the array contains a protective MBR that lists one partition of type ee that occupies the whole array. Fdisk looks at sdb and sees the same thing. Following the MBR is the GPT, part of which is missing from sdb, so fdisk treats it as corrupt, and falls back to printing only the MBR. > So the phantom sdb1 device was not there when only fdisk was used > (fdisk4), but does appear after using parted, whether using parted > to create the partition table (fdisk 2, fdisk3), or as in the last > test, only to view information (parted -l) after using fdisk > (fdisk5). I see now. I think you are running into a cache aliasing issue here. That is to say, that the MBR of sdb was read into the cache while the drive was still blank, and when parted creates the gpt on the array, it does in fact create that protective mbr partition, but fdisk does not see it on sdb yet, since it is still holding the cached data from earlier. Note that at this point fdisk reports that there is no partition table of any kind, not just no sdb1. If you run blockdev - --flushbufs and then repeat the fdisk -l, sdb1 should show up. > Okay, I am aware that a protective MBR may be written alongside the > GPT tables and that the protective MBR may contain a partition > entry covering the entire disk. So you're suggesting that this may > be what this phantom sdb1 device is? Interesting. Yes, that is exactly what sdb1 is. You can see from the ID field being ee. > But, what is the explanation for it not appearing in fdisk ouput > after using fdisk to create the GPT tables in test #3? And > furthermore what is the explanation for it then suddenly appearing > after then running 'parted -l'? And if that is the case then that > would imply that fdisk also may not be properly paying attention to > the fact that these are array members. parted flushes the disk cache when opening it to make sure that it is reading the correct data. After that, fdisk also now sees it. > If fdisk is setting the protective MBR partition to the size of a > member disk, rather than the size of the array, that would explain > the fdisk error not showing up after using fdisk to create the > partition tables. And if parted is doing the opposite, setting the > array size here, that would explain the presence of the error in > fdisk output after using parted to do it. Which if so, begs the > question, which is right? Should fdisk be changed to use the array > size (alongside paying proper attention to array membership of > course), or should parted be using the disk size? Both of them are using the size of the array, which they should since that is the "disk" as far as they are concerned. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU55UUAAoJENRVrw2cjl5RM8UH/0tBf2Kz1MfNkZeOuMG4nfRV fx5iYdI0I5Zm5SEB1fYXJcKLwxfNb5h0sBs+BskmVcnJZioMm3foo9uHetFip4kA 2zBZfXmgI5akFbkYYq2H7q0wxwU4tDecCGOn9cOUeTA0GNCci4W/f6TfKugk504E aUzoQMh+qN8Fxycj1p+efa7voRgYiUjC8aaEUmswYRLdfgxKKLkhOKYZY31Kk3Qf i5zbLjeUrLPARlmUGOc2ON0ljzLm/QJ3p40iCTFVaJ9dQrUumLiH4bUc53rXY72S XAYeaCTim2gKTcGJD6VKMTa/EVlwjWgBPb12FsnFtha/Gv/oilahGVqz5cZlRro= =3W21 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778863: keepass2: 'enter master key on secure desktop' non-functional
Package: keepass Version: 2.28+dfsg-1 Severity: important Tags: security Keepass2 has an option 'enter master key on secure desktop' under the 'security' tab in the options window. This option however appears to have no affect. I understand that the option may be primarily aimed at recent versions of Windows, however I have seen password prompts in a gnome environment which at least look similar to those in Windows. Please assess whether it is possible to display the keepass password prompt via this mechanism, and whether there would be any security benefit at all in doing so in Linux. If not, please consider removing the option. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778862: ispell: please make building .hash files reproducible
Source: ispell Version: 3.3.02-6 Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness toolchain Hi! While working on Debian's “reproducible builds” effort [1], we have noticed that buildhash from ispell produces unreproducible .hash files (example [2]). After some investigation, I found out that those undeterministic lines come when "sflaglist" (which is a list of "flagent" structs) is written [3]. The problem is that "sizeof(struct flagent)" is 800 bytes, while the summed up size of the individual members is only 794 bytes [4]. So after those 794 bytes are written, the remaining 6 bytes are read from uninitialized memory (which is undeterministic). Packing the struct (__attribute__ ((__packed__))) would probably help, but is no solution as this would change the size of the .hash files and other tools reading them will probably have problems. The best solution is probably to initialize the whole sflaglist (or each flagent) with zero when it is allocated. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds [2]: https://packages.debian.org/jessie/lava-server [3]: https://sources.debian.net/src/ispell/3.3.02-6/buildhash.c/#L398 [4]: https://sources.debian.net/src/ispell/3.3.02-6/ispell.h/#L332 signature.asc Description: OpenPGP digital signature
Bug#778861: keeypass2: gui theme issues
Package: keepass2 Version: 2.28+dfsg-1 Using only the default Jessie/Gnome theme in my sid install, keepass2 is not rendering its interface properly. E.g. the background colour of the menubar and toolbar. See attached screenshot.
Bug#771857: caff: Please support GnuPG 2.1
In fact I changed that (r773) to symlink the agent's socket(s) instead; it's much cleaner as it doesn't spawn multiple agent in ~/.caff/gnupghome and the temporary directories. However caff won't work with gpg <= 2.1.2, due to gpg not flushing its standard output before the status prompts during the pruning. This bug has already been fixed upstream, see http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d2a70fd8 -- Guilhem. signature.asc Description: Digital signature
Bug#778860: [uscan] Followup for #764367 (downloads web page instead of file)
Package: devscripts Version: 2.15.1 Severity: normal Dear Maintainer, in 10/2014, a change in devscripts/uscan (#764367) broke watch files that use the sf redirector service. It was fixed in devscripts-2.14.8 by: ++ Strip the Referer header when using qa.debian.org's Sourceforge + redirector. When there's a foreign Referer header, Sourceforge responds + with a web page containing a redirect to the actual + file, causing uscan to save the web page rather than the file. (Closes: + #764367) (http://anonscm.debian.org/cgit/collab-maint/devscripts.git/commit/?id=fb0e6a67fc059acb89cf0ea7bc9b52cad43d5326) Now I cannot use the sf redirect service because I need to limit the search to the "freeplane%20stable/" folder (and the qa.debian.org redirect does not allow this). (I am using devscripts 2.15.1 in unstable) Here is my old watch file (which limits the search to the "freeplane%20stable/" folder): https://github.com/fnatter/freeplane-debian/blob/master/debian/watch But this fails for the same reason as in #764367: felix@debianunstable:~/freeplane-unstable/freeplane-debian$ uscan freeplane: Newer version (1.3.15) available on remote site: http://sourceforge.net/projects/freeplane/files/freeplane%20stable/freeplane_srcpure-1.3.15.tar.gz/download (local version is 1.3.12) Unknown or no compression used in ../freeplane_srcpure-1.3.15.tar.gz. at /usr/bin/mk-origtargz line 336. uscan: error: mk-origtargz --package freeplane --version 1.3.15 --compression gzip --directory .. --copyright-file debian/copyright ../freeplane_srcpure-1.3.15.tar.gz gave error exit status 255 wget http://sourceforge.net/projects/freeplane/files/freeplane%20stable/freeplane_srcpure-1.3.15.tar.gz/download works (beside the fact that it downloads as 'download'). --> would you consider fixing this (maybe add a "sourceforge.net/projects" special case as well or add a 'remove_referer' option?)? Thanks and Best Regards, Felix -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- Not present -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages devscripts depends on: ii dpkg-dev 1.17.23 ii libc62.19-15 ii perl 5.20.1-5 ii python3 3.4.2-2 pn python3:any Versions of packages devscripts recommends: ii at 3.1.16-1 ii dctrl-tools 2.23 ii debian-keyring 2014.12.10 ii dput0.9.6.4 ii equivs 2.0.9 ii fakeroot1.20.2-1 ii file1:5.22+15-1 ii gnupg 1.4.18-6 ii libdistro-info-perl 0.14 ii libencode-locale-perl 1.03-1 ii libjson-perl2.61-1 ii liblwp-protocol-https-perl 6.06-2 ii libparse-debcontrol-perl2.005-4 ii libsoap-lite-perl 1.11-1 ii liburi-perl 1.64-1 ii libwww-perl 6.08-1 ii lintian 2.5.30+deb8u3 ii man-db 2.7.0.2-5 ii patch 2.7.4-2 ii patchutils 0.3.3-1 ii python3-debian 0.1.25 ii python3-magic 1:5.22+15-1 ii sensible-utils 0.0.9 ii strace 4.9-2 ii unzip 6.0-16 ii wdiff 1.2.2-1 ii wget1.16-3 ii xz-utils5.1.1alpha+20120614-2+b3 Versions of packages devscripts suggests: ii bsd-mailx [mailx]8.1.2-0.20141216cvs-1 ii build-essential 11.7 pn cvs-buildpackage pn debbindiff pn devscripts-el ii gnuplot 4.6.6-2 ii gpgv 1.4.18-6 ii libauthen-sasl-perl 2.1600-1 ii libfile-desktopentry-perl0.07-1 ii libnet-smtp-ssl-perl 1.01-3 pn libterm-size-perl ii libtimedate-perl 2.3000-2 pn libyaml-syck-perl ii mutt 1.5.23-3 ii openssh-client [ssh-client] 1:6.7p1-3 pn svn-buildpackage ii w3m 0.5.3-19 -- no debconf information -- Felix Natter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#580120: mediatomb allows anyone to browse and export the whole filesystem
Package: mediatomb Version: 0.12.1-4 Followup-For: Bug #580120 Hello, I think this is not a bug. Just tell user that this feature allows anyone to browse '/' with the user mediatomb runs under (which is not root !)... Apache basic authentication could be setup very easily. Cheers, Michel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778762: A patch
Attached you find a patch which could be applied against latest debian master branch. It provides LSB headers for the example script, which works here (for mysql-5.5) fine. Maybe somebody want to use it as replacement for the stock mysql init script. In this case it maybe usefull to provide 'mysql' instead of 'mysqld_multi', but this is conflicting if the default init script is not removed from /etc/init.d. So I would suggest this change should be done by the users for his own (and risk :). Cheers, Jan. P.S. There is also a PR pending on github (https://github.com/ottok/mariadb-10.0), just in case. -- Never write mail to , you have been warned! -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y --END GEEK CODE BLOCK-- From 2f6a9756cd55bfdde844a4c52923f49680e8ea0a Mon Sep 17 00:00:00 2001 From: Jan Wagner Date: Fri, 20 Feb 2015 19:50:38 +0100 Subject: [PATCH] Adding mysqld_multi.server_lsb-header.patch, provides LSB headers for example initscript (Closes: #778762) --- .../patches/mysqld_multi.server_lsb-header.patch | 27 ++ debian/patches/series | 1 + 2 files changed, 28 insertions(+) create mode 100644 debian/patches/mysqld_multi.server_lsb-header.patch diff --git a/debian/patches/mysqld_multi.server_lsb-header.patch b/debian/patches/mysqld_multi.server_lsb-header.patch new file mode 100644 index 000..8911653 --- /dev/null +++ b/debian/patches/mysqld_multi.server_lsb-header.patch @@ -0,0 +1,27 @@ +--- a/support-files/mysqld_multi.server.sh b/support-files/mysqld_multi.server.sh +@@ -14,8 +14,22 @@ + # Version 1.0 + # + +-basedir=/usr/local/mysql +-bindir=/usr/local/mysql/bin ++### BEGIN INIT INFO ++# Provides: mysqld_multi ++# Required-Start: $local_fs $network $remote_fs $syslog ++# Required-Stop: $local_fs $network $remote_fs $syslog ++# Default-Start: 2 3 4 5 ++# Default-Stop: 0 1 6 ++# Short-Description: starting our several mysql daemons ++# Description: n/a ++### END INIT INFO ++ ++PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin ++NAME=mysqld_multi ++DESC=mysqld_multi ++ ++basedir=/usr ++bindir=/usr/bin + + if test -x $bindir/mysqld_multi + then diff --git a/debian/patches/series b/debian/patches/series index 969689c..63cb112 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -13,3 +13,4 @@ new_valid_certs.patch new_valid_certs_test_fix.patch reproducible-builds-fix-connect.patch mysqld_multi_confd.patch +mysqld_multi.server_lsb-header.patch signature.asc Description: OpenPGP digital signature
Bug#778859: tix: Multiarch support
Package: tix
Version: 8.4.3-6
Tags: patch
Usertags: origin-ubuntu ubuntu-patch vivid
In Ubuntu, we've applied the attached patch to achieve the following:
- debian/rules:
+ Fix build failure with Tcl/Tk multiarch locations.
+ Use dpkg-buildflags.
We thought you might be interested in doing the same.
diff -Nru tix-8.4.3/debian/rules tix-8.4.3/debian/rules
--- tix-8.4.3/debian/rules 2014-11-11 12:20:49.0 +0100
+++ tix-8.4.3/debian/rules 2015-02-20 18:44:32.0 +0100
@@ -18,14 +18,12 @@
SHELL=/bin/bash
-CFLAGS = -Wall -g
-
-ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-CFLAGS += -O0
-else
-CFLAGS += -O2
-endif
+CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)
+CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS)
+LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS)
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+
groff_version=`groff -v| grep "groff version"| sed -e 's/GNU groff version //'`
tk_version = 8.6
tix_version = 8.4.3
@@ -45,12 +43,13 @@
rm -rf build-static
mkdir build-static
cd build-static && ../configure \
+ CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--disable-shared \
- --with-tclconfig=/usr/lib/tcl$(tk_version) \
+ --with-tclconfig=/usr/lib/$(DEB_HOST_MULTIARCH)/tcl$(tk_version) \
--with-tclinclude=/usr/include/tcl$(tk_version)/tcl-private \
- --with-tkconfig=/usr/lib/tk$(tk_version) \
+ --with-tkconfig=/usr/lib/$(DEB_HOST_MULTIARCH)/tk$(tk_version) \
--with-tkinclude=/usr/include/tcl$(tk_version)/tk-private
$(MAKE) -C build-static
@@ -63,12 +62,13 @@
rm -rf build-shared
mkdir build-shared
cd build-shared && ../configure \
+ CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--enable-shared \
- --with-tclconfig=/usr/lib/tcl$(tk_version) \
+ --with-tclconfig=/usr/lib/$(DEB_HOST_MULTIARCH)/tcl$(tk_version) \
--with-tclinclude=/usr/include/tcl$(tk_version)/tcl-private \
- --with-tkconfig=/usr/lib/tk$(tk_version) \
+ --with-tkconfig=/usr/lib/$(DEB_HOST_MULTIARCH)/tk$(tk_version) \
--with-tkinclude=/usr/include/tcl$(tk_version)/tk-private
$(MAKE) -C build-shared \
Bug#767682: D-I: installer hangs on re-formatting ext4 partition (having grub in the partition boot record).
Control: severity -1 important Axel Beckert (2015-02-04): > Control: found -1 20150107 > Control: severity -1 serious > > Hi, > > MARTON Jozsef wrote: > > The formatting dialog hanged at 33%. > > > >* What outcome did you expect instead? > > > > To re-format /dev/sda3 creating a fresh ext4 filesystem. > > > > > > After examining the situation and killing the mkfs.ext4 process on a > > second virtual terminal, the installer gave a red screen error and > > returned to the partitioning menu. > > > > Invoking mkfs.ext4 manually on the sencond VT, it gave the yes-no > > question that follows (captured under the running Jessie install, so > > mke2fs version might be different). This might be the point where > > the installer hanged at. > > > > # mkfs.ext4 /dev/sda3 > > mke2fs 1.42.12 (29-Aug-2014) > > /dev/sda3 contains a ext4 file system > > last mounted on / on Sat Nov 1 20:18:44 2014 > > Proceed anyway? (y,n) > > We ran into this today with the current Jessie installer (labeled RC1 > IIRC). Context was the reinstallation of a computer with the same > partition layout. > > The question vanishes if a -F is passed to the mkfs.ext* call, so this > should be an easy fix: > >-F Force mke2fs to create a filesystem, even if the > specified device is not a partition on a block special > device, or if other parameters do not make sense. In > order to force mke2fs to create a filesystem even if the > filesystem appears to be in use or is mounted (a truly > dangerous thing to do), this option must be specified twice. > > > After formatting from the second VT, installer was able to continue > > without re-formatting the partition. An other solution was to zero > > out the forst few megabytes of sda3 using dd and /dev/zero to allow > > formatting by the installer. > > I consider both variants unsuitable for unexperienced users. A hanging > TUI without _any_ trace of reason, neither in the TUI no in the syslog > nor in the partman log must not happen. > > Raising the severity to serious because I think that this is a > scenario (reinstallation or retrying an incomplete installation) which > can happen often enough and will confuse users massively due no > feedback from the installer what happens. > > (D-I team: feel free to downgrade again to important if you disagree, > but I really would like to see this fixed for Jessie.) I don't think those usecases warrant to have this as a serious bug. That doesn't mean we shouldn't try and get this fixed (in wheezy and jessie). Any chance you could check and submit a patch? Mraw, KiBi. signature.asc Description: Digital signature
Bug#776978: [PATCH] freezing terminal when switching desktops
Hi Andreas, I actually did, but this old version of libvte is abandoned. Freezing does not happen with the current GNOME3 terminal and GTK3 version of libvte. see https://bugzilla.gnome.org/show_bug.cgi?id=744162 On Fri, Feb 20, 2015 at 7:44 PM, Andreas Henriksson wrote: > Control: tags -1 + patch > > Hello Jindřich Makovička! > > Thanks for your bug report and patch! > > Could you please open a report in the upstream bugzilla to > get your patch reviewed there? > > http://bugzilla.gnome.org > > Regards, > Andreas Henriksson -- Jindřich Makovička -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#776978: [PATCH] freezing terminal when switching desktops
Control: tags -1 + patch Hello Jindřich Makovička! Thanks for your bug report and patch! Could you please open a report in the upstream bugzilla to get your patch reviewed there? http://bugzilla.gnome.org Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775456: ITP: sankore -- interactive whiteboard interface
Hi, [ The last two messages didn’t make it to the bug log. My mistake, sorry, copying them after reordering. ] Le 13/02/2015 13:39, Miriam Ruiz a écrit : > 2015-02-13 17:58 GMT+01:00 David Prévot : >> On Fri, Feb 13, 2015 at 05:29:22PM +0100, Miriam Ruiz wrote: >>> 2015-02-13 16:48 GMT+01:00 David Prévot : >> The first challenging bit might be to get rid of the sankore-ThirdParty code copy from the build system, I’ll start working on that now. >> >>> The sankore-ThirdParty stuff hasn't changed since 2012 >> >> Noticed that. That’s one of the reason I’d like to get rid of it. >> >>> Have >>> you already mixed them or do you prefer for me to prepare a working >>> package from those sources and the current git repo? >> >> I’d highly prefer to be able to use the dependencies already in the >> archive (quazip trolltech xpdf), and eventually package them if >> needed, rather than depending on old (and potentially security-flawed) >> convenient code copies. >> >> If really needed, we may use the multiple tarball feature of format 3.0 >> (quilt) to add back the missing bits. > > Yeah forget about the 3rd party, I agree with you. I meant mixing in > the changes in the main program. Sure, feel free to start on getting rid of the ThirdParty tricks in order to make the package buildable again (I’m looking at it too, but have still no clear view/understanding of the program yet, so you’ll probably be a lot more efficient). I’ll push my work in progress in a separate branch in case I can make any progress, do not hesitate to do the same (I mean, even if it’s not working yet, something is better than nothing ;). On Sat, Feb 14, 2015 at 04:22:44PM +0100, Georges Khaznadar wrote: > David Prévot a écrit : > > On Fri, Jan 16, 2015 at 12:11:08PM +0100, Georges Khaznadar wrote: > > > I am enthusiastic about your ITP. If I can help, please tell me! > > > > Thanks, do not hesitate to apply into Debian Edu team membership on > > Alioth, where I initially intend to share the packaging work > I am subscribing my e-mail address to debian-...@lists.debian.org > ... then, what next ? I actually meant on Alioth [1], in order to have write access to the packaging repository [2]. 1: https://alioth.debian.org/projects/debian-edu 2: https://anonscm.debian.org/gitweb/?p=debian-edu/pkg-team/sankore.git Regards David signature.asc Description: OpenPGP digital signature
Bug#778853: Update to 0.4.12
On 20.02.2015 19:14, Martin Quinson wrote: > On Fri, Feb 20, 2015 at 06:27:45PM +0100, Calinou wrote: >> Package: minetest >> Severity: wishlist >> >> The current version is outdated (several months old), please update to >> 0.4.12. > > The new version is packaged, but we are waiting for the Debian release > to happen to upload the new version of minetest. > > Thanks for the reminder, though. > Mt. 0.4.11 is already in experimental but due to the freeze it hasn't been uploaded to unstable yet. https://packages.debian.org/source/experimental/minetest Version 0.4.12 was only released a few days ago. I guess I can package that this weekend. If someone is interested in sponsoring the upload, the package could then go to experimental as well. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#778858: jessie-pu: package openafs/1.6.9-2+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
The latest kernel (security) update included a KPI change, moving
d_alias to the d_u union in struct dentry. This KPI change caused
the openafs kernel module to FTBFS (#778196 for FTBFS report and
#778254 where I asked if unblocking the version in sid is reasonable).
While reviewing the patches present in sid but not jessie, I reported
#778851 (data corruption writing to large mmaped files).
This proposed update includes upstream's patches for both the issues
listed above, and no other changes.
Debdiff (to an unsigned local build on sid) attached.
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru openafs-1.6.9/debian/changelog openafs-1.6.9/debian/changelog
--- openafs-1.6.9/debian/changelog 2014-09-22 13:17:26.0 -0400
+++ openafs-1.6.9/debian/changelog 2015-02-20 12:55:38.0 -0500
@@ -1,3 +1,11 @@
+openafs (1.6.9-2+deb8u1) testing; urgency=high
+
+ * Import patches from upstream:
+- Avoid using stale data version after writepage. (Closes: #778851.)
+- Fix build when d_alias is in the d_u union. (Closes: #778196.)
+
+ -- Benjamin Kaduk Fri, 20 Feb 2015 12:55:06 -0500
+
openafs (1.6.9-2) unstable; urgency=medium
[ Russ Allbery ]
diff -Nru openafs-1.6.9/debian/patches/0003-Unix-CM-Avoid-using-stale-DV-in-afs_StoreAllSegments.patch openafs-1.6.9/debian/patches/0003-Unix-CM-Avoid-using-stale-DV-in-afs_StoreAllSegments.patch
--- openafs-1.6.9/debian/patches/0003-Unix-CM-Avoid-using-stale-DV-in-afs_StoreAllSegments.patch 1969-12-31 19:00:00.0 -0500
+++ openafs-1.6.9/debian/patches/0003-Unix-CM-Avoid-using-stale-DV-in-afs_StoreAllSegments.patch 2015-02-20 11:57:16.0 -0500
@@ -0,0 +1,74 @@
+From: Marc Dionne
+Date: Fri, 19 Dec 2014 10:11:53 -0500
+Subject: Unix CM: Avoid using stale DV in afs_StoreAllSegments
+
+It was reported in RT 131976 that on Linux some file
+corruption was observed when doing mmap writes to
+a file substantially larger than the cache size.
+
+osi_VM_StoreAllSegments drops locks and asks the OS to flush
+any dirty pages in the file 's mapping. This will trigger
+calls into our writepage op, and if the number of dirty
+cache chunks is too high (as will happen for a file larger
+than the cache size), afs_DoPartialWrite will recursively
+call afs_StoreAllSegments and some chunks will be written
+back to the server. After potentially doing this several
+times, control will return to the original afs_StoreAllSegments.
+
+At that point the data version that was stored before
+osi_VM_StoreAllSegments is no longer correct, leading to
+possible data corruption.
+
+Triggering this bug requires writing a file larger than the
+cache so that partial stores are done, and writing enough
+data to exceed the system's maximum dirty ratio and cause
+it to initiate writeback.
+
+To fix, just wait until after osi_VM_StoreAllSegments to
+look at and store the data version
+
+FIXES 131976
+
+Reviewed-on: http://gerrit.openafs.org/11644
+Tested-by: BuildBot
+Reviewed-by: Jeffrey Altman
+(cherry picked from commit b22c586bcdf785c489009ab96cbb572181cb9b09)
+
+Change-Id: I32a2f6f32d432fe4a2e21ebd4bb278a9d7e5499f
+Reviewed-on: http://gerrit.openafs.org/11656
+Tested-by: BuildBot
+Reviewed-by: Benjamin Kaduk
+Reviewed-by: Stephan Wiesand
+(cherry picked from commit 013e8db33fbec8b5db4ac5a1ec94a7f5b2afbc45)
+---
+ src/afs/afs_segments.c | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/src/afs/afs_segments.c b/src/afs/afs_segments.c
+index f407b49..1ea3311 100644
+--- a/src/afs/afs_segments.c
b/src/afs/afs_segments.c
+@@ -174,8 +174,6 @@ afs_StoreAllSegments(struct vcache *avc, struct vrequest *areq,
+
+ AFS_STATCNT(afs_StoreAllSegments);
+
+-hset(oldDV, avc->f.m.DataVersion);
+-hset(newDV, avc->f.m.DataVersion);
+ hash = DVHash(&avc->f.fid);
+ foreign = (avc->f.states & CForeign);
+ dcList = (struct dcache **)osi_AllocLargeSpace(AFS_LRALLOCSIZ);
+@@ -213,6 +211,14 @@ afs_StoreAllSegments(struct vcache *avc, struct vrequest *areq,
+ /*printf("Net down in afs_StoreSegments\n");*/
+ return ENETDOWN;
+ }
++
++/*
++ * Can't do this earlier because osi_VM_StoreAllSegments drops locks
++ * and can indirectly do some stores that increase the DV.
++ */
++hset(oldDV, avc->f.m.DataVersion);
++hset(newDV, avc->f.m.DataVersion);
++
+ ConvertWToSLock(&avc->lock);
+
+ /*
diff -Nru openafs-1.6.9/debian/patches/0004-Linux-d_alias-becomes-d_u.d_alias.patch openafs-1.6.9/debian/patches/0004-Linux-d_alias-becomes-d_u.d_alias.patch
--- openafs-1.6.9/debian/patches/0004-Linux-d_alias-becomes-d_u.d_
Bug#778857: package ola_0.9.1-1.1 FTBS on big-endian archs
Package: ola Version: 0.9.1-1.1 Severity: important Tags: sid User: debian-m...@lists.debian.org Hello, Package ola_0.9.1-1.1 FTBFS on big-endian architectures during testing phase. This problem is solved on upstream: https://github.com/OpenLightingProject/ola/pull/467 Upstream releases 0.9.3 and 0.9.4 build successfully on big-endian mips. Could someone please upload 0.9.4 to experimental? I will work on back-port of relevant changes for version 0.9.1-1.1. Thanks! Regards, Jurica
Bug#778853: Update to 0.4.12
On Fri, Feb 20, 2015 at 06:27:45PM +0100, Calinou wrote: > Package: minetest > Severity: wishlist > > The current version is outdated (several months old), please update to > 0.4.12. The new version is packaged, but we are waiting for the Debian release to happen to upload the new version of minetest. Thanks for the reminder, though. Mt. signature.asc Description: Digital signature
Bug#778856: gdm3: weird system start, random wifi netwoking issues
Package: gdm3 Version: 3.14.1-3 Severity: important The other day I switched back from linux 3.18-trunk (in experimental) to this 3.16 kernel. Also, installed virtualbox and did a couple of lvm snapshots/merges. Weird messages appears in syslog. Wifi suddenly stops working. I have to turn it on/off to get wifi working again. Find a ~700 lines syslog at the end of this mail. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gdm3 depends on: ii accountsservice 0.6.37-3+b1 ii adduser 3.113+nmu3 ii dconf-cli 0.22.0-1 ii dconf-gsettings-backend 0.22.0-1 ii debconf [debconf-2.0] 1.5.55 ii gir1.2-gdm3 3.14.1-3 ii gnome-session-bin 3.14.0-2 ii gnome-settings-daemon 3.14.2-2 ii gnome-shell 3.14.2-3+b1 ii gnome-terminal [x-terminal-emulator] 3.14.1-1 ii gsettings-desktop-schemas 3.14.1-1 ii libaccountsservice0 0.6.37-3+b1 ii libaudit1 1:2.4-1+b1 ii libc6 2.19-13 ii libcanberra-gtk3-00.30-2.1 ii libcanberra0 0.30-2.1 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libgdm1 3.14.1-3 ii libglib2.0-0 2.42.1-1 ii libglib2.0-bin2.42.1-1 ii libgtk-3-03.14.5-1 ii libpam-modules1.1.8-3.1 ii libpam-runtime1.1.8-3.1 ii libpam-systemd215-11 ii libpam0g 1.1.8-3.1 ii librsvg2-common 2.40.5-1 ii libselinux1 2.3-2 ii libsystemd0 215-11 ii libwrap0 7.6.q-25 ii libx11-6 2:1.6.2-3 ii libxau6 1:1.0.8-1 ii libxdmcp6 1:1.1.1-1+b1 ii libxrandr22:1.4.2-1+b1 ii lsb-base 4.1+Debian13+nmu1 ii metacity [x-window-manager] 1:3.14.3-1 ii mutter [x-window-manager] 3.14.2-1 ii policykit-1 0.105-8 ii ucf 3.0030 ii x11-common1:7.7+7 ii x11-xserver-utils 7.7+3+b1 ii xfce4-session [x-session-manager] 4.10.1-10 ii xfwm4 [x-window-manager] 4.10.1-3 ii xterm [x-terminal-emulator] 312-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.14.0-1 ii desktop-base 8.0.2 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii x11-xkb-utils 7.7+1 ii xserver-xephyr 2:1.16.4-1 ii xserver-xorg 1:7.7+7 ii zenity 3.14.0-1 Versions of packages gdm3 suggests: pn gnome-orca ii libpam-gnome-keyring 3.14.0-1+b1 -- Configuration Files: /etc/gdm3/greeter.gsettings c174f4b4052874d1918d18ccadb6a027 [Errno 2] No existe el fichero o el directorio: u'/etc/gdm3/greeter.gsettings c174f4b4052874d1918d18ccadb6a027' -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3 Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: (**) Power Button: Applying InputClass "evdev keyboard catchall" Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: (II) LoadModule: "evdev" Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so Feb 20 18:41:12 nostromo ModemManager[717]: Couldn't find support for device at '/sys/devices/pci:00/:00:1c.0/:02:00.0': not supported by any plugin Feb 20 18:41:12 nostromo ModemManager[717]: Couldn't find support for device at '/sys/devices/pci:00/:00:1c.1/:03:00.0': not supported by any plugin Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: (II) Module evdev: vendor="X.Org Foundation" Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: compiled for 1.16.0, module version = 2.9.0 Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: Module class: X.Org XInput Driver Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: ABI class: X.Org XInput driver, version 21.0 Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: (II) Using input driver 'evdev' for 'Power Button' Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: (**) Power Button: always reports core events Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: (**) evdev: Power Button: Device: "/dev/input/event4" Feb 20 18:41:12 nostromo gdm-Xorg-:0[1098]: (--) evdev: Power Bu
Bug#745082: chfn and fakechroot
Hi! I am running into the exact same problem when trying to create a unstable chroot using debootstrap on one of our sh4 machines using the following command line: debootstrap --no-check-gpg --include=apt,nano,aptitude,vim unstable unstable-sh4-20150220-3 ftp://ftp.debian-ports.org/debian With the error message being: Setting up systemd (215-12) ... Initializing machine ID from random generator. chfn: PAM: Critical error - immediate abort adduser: `/usr/bin/chfn -f systemd Time Synchronization systemd-timesync' returned error code 1. Exiting. dpkg: error processing package systemd (--configure): subprocess installed post-installation script returned error exit status 1 The problem are apparently the missing quotes in the above command: root@yamato:/# /usr/bin/chfn -f systemd Time Synchronization systemd-timesync chfn: user 'Time' does not exist root@yamato:/# Adding them fixes the problem: root@yamato:/# /usr/bin/chfn -f "systemd Time Synchronization" systemd-timesync root@yamato:/# I checked the systemd postinst and this script does indeed contain quotes. For some reasons which I don't understand, adduser invokes chfn in during the debootstrap process without the quotes. And what's even more crazy, the exact same command line does work on m68k or amd64 machines, for example. The sh4 machine is up-to-date, so it can be outdated packages either (unless I overlooked something). Any ideas? PS: I would suggest merging 745082, 763391 and 774332. They seem to describe the exact same bug. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778855: ITP: presentty -- Console-based presentation system
Package: wnpp Severity: wishlist Owner: Clint Byrum * Package name: presentty Version : 0.1.0 Upstream Author : James E. Blair * URL : https://gitorious.org/presentty * License : GPLv3 Programming Lang: Python Description : Console-based presentation system Presentty is a console-based presentation program where slides are authored in reStructuredText. Its features include, but are not limited to: Cross-fade animations, progressive list display, panning transitions, syntax highlighting, Cowsay and figlet integration, ANSI art, JPEG display. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778852: RFS: ismrmrd/1.2.1-1 [ITP #732360] -- ISMRM Raw Data Format.
Hi Ghislain, On Fri, Feb 20, 2015 at 05:05:50PM +, Ghislain Vaillant wrote: > I have added an entry to the SoB tasks [1]. > > However, I cannot access the blends svn repository to update the imaging > task file. > Since I am a member of d-med on Alioth, I am supposed to have access, right > ? The following user groups have commit permissions: 1. Debian Developers 2. Members of Blends team This has advantages and disadvantages - you have hit the latter. :-) If you want to have commit permissions you can join group 1. (we talked about this recently ;-)) or 2. (which is simple). Or you simply ask me to commit something like this: $ svn diff Index: imaging === --- imaging (Revision 4142) +++ imaging (Arbeitskopie) @@ -542,6 +542,8 @@ Depends: mia-tools, mialmpick, mia-viewit +Depends: ismrmrd-tools + ; Added by blends-inject 0.0.7. [Please note here if modified manually] Suggests: connectomeviewer Published-Authors: Gerhard S, Daducci A, Lemkaddem A, Meuli R, Thiran J-P and Hagmann P Index: imaging-dev === --- imaging-dev (Revision 4136) +++ imaging-dev (Arbeitskopie) @@ -169,3 +169,5 @@ Depends: libedf-dev Depends: python-imageio + +Depends: libismrmrd-dev ... which I did right now. Thanks for your work on this Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778853: Update to 0.4.12
Package: minetest Severity: wishlist The current version is outdated (several months old), please update to 0.4.12. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778854: ITP: libmime-lite-tt-perl -- generates MIME messages from Template Toolkit templates
Package: wnpp Owner: Christopher Hoskin Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libmime-lite-tt-perl Version : 0.02 Upstream Author : Yasuhiro Horiuchi * URL : https://metacpan.org/release/MIME-Lite-TT * License : Artistic or GPL-1+ Programming Lang: Perl Description : generates MIME messages from Template Toolkit templates MIME::Lite::TT is a wrapper around MIME::Lite which is used to create MIME messages. The text part of the message is generated from a Template::Toolkit template. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778747: [Pkg-openssl-devel] Bug#778747: openssl: RFC 7465 says RC4 is broken, never to be used
On Fri, Feb 20, 2015 at 06:10:59PM +0100, Florian Schlichting wrote: > Hi Kurt, > > > > To protect our users and comply with adopted Internet standards, openssl > > > in Debian should no longer include RC4 ciphers in the DEFAULT list of > > > ciphers, neither in Jessie nor supported stable / oldstable releases. > > > > I fully support that RFC. However I don't think it's a good idea > > to remove it from DEFAULT in jessie. Reasons not to are: > > - Many servers only support RC4 so clients still need to support > > RC4 to be able to talk to them. Hopefully this RFC will change > > that. > > What servers, and what clients are we talking about here? You might want to look at those stats: https://lists.fedoraproject.org/pipermail/security/2015-February/002069.html Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778712: libparted2: Breakage of RAID GPT header
On Fri, 2015-02-20 at 10:16 -0500, Phillip Susi wrote: > On 2/19/2015 2:24 PM, jnqnfe wrote: > > Firstly, I am not running fdisk or parted on the raw member disks, > > I am simply running generic 'fdisk -l' and 'parted -l' commands, > > which return information about all disks. To simplify matters I > > removed information about other disks in my system from the output > > I supplied, leaving only that pertaining to the array and array > > member disks. > > You did not; the output you supplied listed both sda and sdb. What? I very carefully went through every one of them before sending to ensure that only information about the array (md126) and the array members (sdb and sdc) were included. I have just checked back over every one of those files attached to the original bug report and none of them contain any info about sda. Do please note that in some of them sdc has been output before sdb, so perhaps you didn't look carefully enough and misread sdc for sda in these cases? I really don't know otherwise why on earth you think I've sent info about sda. > The GPT is 16 KiB but starts on sector 2, hence the last 2 sectors > fall onto the second disk. Okay, I'll take your word on that and thus that explains sufficiently why parted things there's corruption. > Because parted does not know anything about raid. I suppose it might > be nice if it could detect it and ignore those drives, but doing so > would require adding a dependency on udev or blkid. I'll mull the > idea over. Okay. I do think that it would be a very good idea for parted to do this. We can put that stuff to one side then and focus on this phantom sdb1 device... > > Furthermore, if you look at the fdisk output I supplied, you > > should notice that when I created the partition table with fdisk, > > everything was initially fine; no 'dev/sdb1' device exists (see > > fdisk4). However after running 'parted -l' to see what parted makes > > of the result of using fdisk, and then re-running 'fdisk -l' (I > > just happened to do so to be certain everything was fine, and found > > to my surprise it was not), you can see that now all of a sudden a > > /dev/sdb1' device exists. > > sdb1 shows up in fdisk2. Yes, but please review the initial bug report for when I created each of the output files. I ran three tests using different tools to create the GPT headers, first with gparted, then with parted, then with fdisk. Before each test I deleted and recreated the RAID array to try and achieve a fresh start (which checking fdisk and parted info after doing so confirmed was a successful means of resetting things). Files fdisk1 and parted1 demonstrate the state of things directly after recreating the RAID array, without yet attempting to write the partition table. So, fdisk2 and parted2 show the state of things after using gparted to write a GPT table to the array, and thus this phantom sdb1 device exists, which fdisk doesn't like. Starting afresh, I then did the same thing but using parted. You can see the state of things afterwards in fdisk3 and parted3. Again, as you can see in fdisk3, this phantom sdb1 device exists which fdisk doesn't like. No difference from using gparted. Finally I started things afresh once more and used fdisk to create the GPT partition table. The state of things after this according to fdisk (which I checked first) and which you can see in fdisk4 shows no sign of this phantom sdb1 device. So everything seems fine at this point according to fdisk. I then checked the state of things with parted, which you can see in file parted4. Then I checked fdisk one more time, and that phantom sdb1 device is back, as can be seem in fdisk5. So the phantom sdb1 device was not there when only fdisk was used (fdisk4), but does appear after using parted, whether using parted to create the partition table (fdisk 2, fdisk3), or as in the last test, only to view information (parted -l) after using fdisk (fdisk5). As I said in my last email, I am not outright claiming that parted is definitely directly responsible for creating this phantom device, but it is a pretty damning coincidence that it has so far only appeared after running parted. > The moment you created the GPT table on the raid array, it included > the protective MBR partition, and that is what fdisk is reporting > since the GPT is corrupt ( when viewed through the lens of the single > disk ). lsblk uses the blkid database which does recognize that the > disks are array components and filters them out. Okay, I am aware that a protective MBR may be written alongside the GPT tables and that the protective MBR may contain a partition entry covering the entire disk. So you're suggesting that this may be what this phantom sdb1 device is? Interesting. But, what is the explanation for it not appearing in fdisk ouput after using fdisk to create the GPT tables in test #3? And furthermore what is the explanation for it then suddenly appearing after then running 'parted -l'? And if that
Bug#778747: [Pkg-openssl-devel] Bug#778747: openssl: RFC 7465 says RC4 is broken, never to be used
Hi Kurt, > > To protect our users and comply with adopted Internet standards, openssl > > in Debian should no longer include RC4 ciphers in the DEFAULT list of > > ciphers, neither in Jessie nor supported stable / oldstable releases. > > I fully support that RFC. However I don't think it's a good idea > to remove it from DEFAULT in jessie. Reasons not to are: > - Many servers only support RC4 so clients still need to support > RC4 to be able to talk to them. Hopefully this RFC will change > that. What servers, and what clients are we talking about here? From reading the Chromium [0] and Firefox [1] bugs about this, I understand that payment processors in the US have a problem disabling RC4 on older setups while maintaining PCI compliance. SSL Pulse [2] counts around 1.5% of web sites surveyed that only support RC4. So major browsers like Iceweasel and Chromium may want to keep RC4 around as an option for those who need it (there's talk about a whitelist in [0]). [0] https://code.google.com/p/chromium/issues/detail?id=375342 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=999544 [2] https://www.trustworthyinternet.org/ssl-pulse/ However everybody else should get rid of RC4 now, not just on the server but also on the client side - and I'm particularly thinking of all the applications that use TLS beyond the web. It is a lot easier to remove RC4 ciphers from the DEFAULT list in openssl and to add it back in the very few web browsers that need it (and I'm not sure there are any at all that use openssl in Debian and rely on the DEFAULT), than to change the hundreds of other applications in Debian that use openssl to require "DEFAULT:!RC4". > - In practice if the other side supports something other than RC4 > it's likely that RC4 isn't used. Looking at SSL Pulse [2] again, 23.3% of sites will negotiate an RC4-based cipher with modern browsers, that's roughly a third of those having some RC4 suites enabled. Not all that unlikely, I'd say, and a reason why Google and Mozilla consider moving forward on the client side. I think disabling RC4 in the default list of suites in openssl and similar libraries like gnutls and libnss is the right thing to do, and I think it should be done now, unless we have a clear idea about what if anything this breaks and will need to be fixed beforehand. Florian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778852: RFS: ismrmrd/1.2.1-1 [ITP #732360] -- ISMRM Raw Data Format.
I have added an entry to the SoB tasks [1]. However, I cannot access the blends svn repository to update the imaging task file. Since I am a member of d-med on Alioth, I am supposed to have access, right ? Cheers, Ghis [1] https://wiki.debian.org/DebianPureBlends/SoB 2015-02-20 16:37 GMT+00:00 Ghislain Vaillant : > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for the following package: > > * Package name: ismrmrd > Version : 1.2.1-1 > Upstream Author : The ISMRMRD developers > * URL : http://ismrmrd.github.io/ > * License : Expat > Programming Lang: C++ > Description : ISMRM Raw Data Format > > The ISMRM raw data format is a specification of a common format > to represent and share magnetic resonance imaging raw and image > data. The ISMRMRD library is a C++ implementation of such format, > plus a set of tools to generate and validate ISMRMRD datasets. > > It builds the following binary packages: > libismrmrd1.2 -- shared library > libismrmrd-dev -- header and development files > libismrmrd-doc -- html documentation > ismrmrd-tools -- standalone executables > ismrmrd-schema -- validation schema > > These binary packages have been successfully tested over the past > few months using the following PPA: > https://launchpad.net/~ghisvail/+archive/ubuntu/ismrmrd > > The source package can be checked out at: > http://anonscm.debian.org/gitweb/?p=debian-med/ismrmrd.git > > This package will be maintained by the Debian-med Team and sponsored via > the Sponsorship of Blends. > > Best regards, > Ghis > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/54e762b6.5030...@gmail.com > >
Bug#740088: obconf --tab 6 ("Desktop Pager Settings" in LXDE) segfaults
Control: tags 740088 patch Control: severity serious It is upstream fixed: https://github.com/danakj/obconf/pull/5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778850: Acknowledgement (Missing 20-column_privilege_leak.patch file in postgresql-8.4 8.4.22-0ubuntu0.10.04.1 source package)
I've found a note here: https://bugs.launchpad.net/ubuntu/+source/postgresql-9.1/+bug/1418928 Martin Pitt (pitti) wrote on 2015-02-06:#4 The fix for the column privilege leaks in error messages (http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3a2063369 , CVE-2014-8161) backports really badly to 8.4, the code changed completely. I'm really afraid of breaking something, and the importance of that is low to medium only IMHO. So I skip this one for lucid. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778851: corrupted mmaped files in AFS
source: openafs version: 1.6.9-2 severity: grave control: fixed -1 1.6.10-4 A bug in OpenAFS's determination of the data version of a file can cause data loss when writing a file larer than the AFS cache and simultaneously exceeding the system's maximum dirty ratio. See http://rt.central.org/rt/Ticket/Display.html?id=131976&user=guest&pass=guest for details. This bug cannot currently be verified in jessie due to #778196, but source inspection confirms that it is present. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778852: RFS: ismrmrd/1.2.1-1 [ITP #732360] -- ISMRM Raw Data Format.
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for the following package: * Package name: ismrmrd Version : 1.2.1-1 Upstream Author : The ISMRMRD developers * URL : http://ismrmrd.github.io/ * License : Expat Programming Lang: C++ Description : ISMRM Raw Data Format The ISMRM raw data format is a specification of a common format to represent and share magnetic resonance imaging raw and image data. The ISMRMRD library is a C++ implementation of such format, plus a set of tools to generate and validate ISMRMRD datasets. It builds the following binary packages: libismrmrd1.2 -- shared library libismrmrd-dev -- header and development files libismrmrd-doc -- html documentation ismrmrd-tools -- standalone executables ismrmrd-schema -- validation schema These binary packages have been successfully tested over the past few months using the following PPA: https://launchpad.net/~ghisvail/+archive/ubuntu/ismrmrd The source package can be checked out at: http://anonscm.debian.org/gitweb/?p=debian-med/ismrmrd.git This package will be maintained by the Debian-med Team and sponsored via the Sponsorship of Blends. Best regards, Ghis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778822: patch for handling non ASCII and non UTF8 headers in headache
2015-02-20 14:42 GMT+01:00 Mehdi Dogguy : > > Who uses iso-latin-1 anyway? :-P > Well, back at the time of the Ubuntu report, we still had some, but I have to admit that I needed to forge one in order to check that the patch still apply nowadays ;-) > I'll try to look if it is possible to include this for Jessie (I have > some doubts). Otherwise, it will wait for Jessie's release. (Which means > if you get lucky, you'll have it in Ubuntu within 2 years! :D). Many thanks for the prompt reply in any case. I hope I won't me confronted again to a latin-1 header in the mean time ;-) > >> This issue has already been reported on Ubuntu's bts >> (https://bugs.launchpad.net/ubuntu/+source/headache/+bug/1083216) as >> I'm using Xubuntu 14.10, but it seems that noone there is interested >> in fixing it (issue was opened on 2012-11-26). > > > Thanks for noticing it! :-D I'd correct your sentence though: There is > no one there doing OCaml stuff (and speaking on Ubuntu, globally). It > is not supported (except the compiler itself). So, of course, no one > will ever reply. I guess I still kind of hoped that the issue would be propagated to Debian at some point, but I can understand that it wasn't important enough to be handled by Ubuntu's bug managers Best regards, -- E tutto per oggi, a la prossima volta Virgile -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778235: [Pkg-libvirt-maintainers] Bug#778235: libvirt0: Migration drops elements from XML
Hi,
so far I have tried the patch [1] on a wheezy-backports and a jessie
installation.
They both have libvirt 1.2.9 though slightly different builds.
When the patch is applied, the migrated XML is still based on actual XML
instead of the origin XML.
If I statically set (ref. attached/modified patch) the publicActual to
false after the if-clause the migrated XML is correctly based on the
origin XML.
So something seems to be wrong with that if-clause.
At the same time Laine Stump tried to reproduce the issue. His vanilla
1.2.9 is fixed with the patch [1] referenced in my initial bugreport.
I also tested the experimental debian sources for libvirt 1.2.12. While
these already contain [1] they exhibit the same issue that the migrated
XML is based on the actual XML instead of the origin.
Regards,
Martin Sofaru
[1]
http://libvirt.org/git/?p=libvirt.git;a=commit;h=db19a4a3c6f72e464bc3ad00e904d8df13887382
--- libvirt-1.2.9/src/conf/domain_conf.c2014-10-01 10:22:02.0 +0200
+++ libvirt-1.2.9_patched/src/conf/domain_conf.c2015-02-12 21:59:53.741436157 +0100
@@ -16735,18 +16735,25 @@
virDomainNetDefPtr def,
unsigned int flags)
{
-/* publicActual is true if we should report the current state in
- * def->data.network.actual *instead of* the config (*not* in
- * addition to)
- */
unsigned int actualType = virDomainNetGetActualType(def);
-bool publicActual
- = (def->type == VIR_DOMAIN_NET_TYPE_NETWORK && def->data.network.actual &&
- !(flags & (VIR_DOMAIN_XML_INACTIVE | VIR_DOMAIN_XML_INTERNAL_ACTUAL_NET)));
+bool publicActual = false;
const char *typeStr;
virDomainHostdevDefPtr hostdef = NULL;
char macstr[VIR_MAC_STRING_BUFLEN];
+/* publicActual is true if we should report the current state in
+ * def->data.network.actual *instead of* the config (*not* in
+ * addition to)
+ */
+if (def->type == VIR_DOMAIN_NET_TYPE_NETWORK &&
+def->data.network.actual &&
+!(flags & (VIR_DOMAIN_XML_INACTIVE |
+ VIR_DOMAIN_XML_INTERNAL_ACTUAL_NET |
+ VIR_DOMAIN_XML_MIGRATABLE)))
+publicActual = true;
+
+publicActual = false;
+
if (publicActual) {
if (!(typeStr = virDomainNetTypeToString(actualType))) {
virReportError(VIR_ERR_INTERNAL_ERROR,
Bug#778841: Fwd: sflphone-client-gnome Unable to initialize Clutter: The openGL version could not be determined
Seems like a dirver bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745901 https://bugzilla.redhat.com/show_bug.cgi?id=1054435 seems like there is a possible workaround: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745901#41 -stepan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778850: Missing 20-column_privilege_leak.patch file in postgresql-8.4 8.4.22-0ubuntu0.10.04.1 source package
Package: postgresql Version: 8.4.22-0ubuntu0.10.04.1 Changelog for this package contains: ... * Add 20-column_privilege_leak.patch: Fix information leak via constraint-violation error messages [CVE-2014-8161] ... But there is no such patch file. See: http://launchpadlibrarian.net/197335367/postgresql-8.4_8.4.22-0ubuntu0.10.04_8.4.22-0ubuntu0.10.04.1.diff.gz I think that means that CVE-2014-8161 is not fixed in this version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778849: Support restoring initrd on shutdown and pivoting into it
Package: initramfs-tools Version: 0.118 Severity: wishlist Dracut, which provides linux-initramfs-tool and is thus an alternative to initramfs-tools, supports restoring the initrd on shutdown and pivoting into it: https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_dracut_on_shutdown One example where this is needed is a ZFS root filesystem: A clean shutdown requires unmounting the root filesystem and exporting the ZFS storage pool containing that filesystem. Dracut modules may contain shutdown scripts which are called after the system has pivoted to the initrd. In the case of ZFS, the shutdown script looks like this: https://github.com/zfsonlinux/zfs/blob/master/dracut/90zfs/export-zfs.sh.in This is not specific to ZFS but affects anyone having the root filesystem on an LVM. Currently, dracut is the only option for these folks. It would be nice if initramfs-tools supported a shutdown procedure akin to dracut to give people a choice. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
