Bug#740250: imagemagick: CVE-2014-1947 CVE-2014-1958 CVE-2014-2030
Sorry to all we are affected by 1947, commit 43a7754127073ebf0dce2b59cb370c27ae5fbd58 Author: cristy cristy@aa41f4f7-0bf4-0310-aa73-e5a19afd5a74 Date: Sun Feb 16 21:48:05 2014 + Link are incomplete. Will fix asap On Fri, Feb 28, 2014 at 11:20 AM, Bastien ROUCARIES roucaries.bastien+imagemag...@gmail.com wrote: We are not affected by CVE-2014-1947: but by CVE-2014-2030 On Thu, Feb 27, 2014 at 2:45 PM, Moritz Muehlenhoff j...@inutil.org wrote: Package: imagemagick Severity: grave Tags: security Justification: user security hole The CVE assignments are a bit tricky, please see http://www.openwall.com/lists/oss-security/2014/02/12/2 for the thread on oss-security. CVE-2014-1958 http://trac.imagemagick.org/changeset/14801 CVE-2014-1947: http://trac.imagemagick.org/changeset/13736 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#740481: wims-moodle: [INTL:ru] Russian debconf templates translation
Package: wims-moodle Version: 4.0-11 Severity: wishlist Tags: l10n patch Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * 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 lines *** Russian debconf templates translation is attached. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf armel Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ru.po.gz Description: GNU Zip compressed data
Bug#740457: eyed3: please package newer upstream release
On Sat, 01 Mar 2014, tony mancill wrote: Package: eyed3 Severity: wishlist Dear Maintainer, Please consider updating python-eyed3 to a newer upstream release. The latest release of gpodder (and perhaps others) now uses = 0.7. I already tried. Unfortunatly the buildsystem changed and is broken now, my python knowledge is limited and I wasn't able to build it. If you manage to get it running, drop me a patch and I'll release an update. Alex P.S. this is related to https://bitbucket.org/nicfit/eyed3/commits/475ea13 and https://github.com/paver/paver/issues/112 pgpcXNCOs9i8Z.pgp Description: PGP signature
Bug#733381: Bug #733381: gpx2shp: FTBFS: geod_set.c:32:2: error: too few arguments to function 'pj_ell_set'
Hi again, But as I already uploaded the 0.71 file to Debian, the archive software is not going to accept a file with a different MD5-sum and the same version. Perhaps I should make up my own version number 0.71.0 or something like that. I can make it back and set the new number of version. Is it better for you? Regards, Toshi. Petter Reinholdtsen p...@hungry.comさん： [HIRAOKA, Toshihiro] Hi Petter, Hi. :) Sorry, I forget these things. I just replaced the file. Thank you! But as I already uploaded the 0.71 file to Debian, the archive software is not going to accept a file with a different MD5-sum and the same version. Perhaps I should make up my own version number 0.71.0 or something like that. -- Happy hacking Petter Reinholdtsen HIRAOKA, Toshihiro AzukiMap K.K. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739213: FTBFS against libav10
Hi,
the attached patch should fix this bug.
--
Anton KhirnovIndex: avifile-0.7.48~20090503.ds/lib/aviread/FFReadStream.cpp
===
--- avifile-0.7.48~20090503.ds.orig/lib/aviread/FFReadStream.cpp 2014-03-01 07:53:20.0 +
+++ avifile-0.7.48~20090503.ds/lib/aviread/FFReadStream.cpp 2014-03-01 07:55:35.028095554 +
@@ -12,32 +12,32 @@
AVM_BEGIN_NAMESPACE;
-static int get_fcc(enum CodecID id)
+static int get_fcc(enum AVCodecID id)
{
const struct id2fcc {
- enum CodecID id;
+ enum AVCodecID id;
uint32_t fcc;
} id2fcct[] = {
- { CODEC_ID_MPEG1VIDEO, RIFFINFO_MPG1 },
- { CODEC_ID_MPEG1VIDEO, mmioFOURCC('P', 'I', 'M', '1') },
- { CODEC_ID_MPEG2VIDEO, RIFFINFO_MPG2 },
- { CODEC_ID_H263, mmioFOURCC('H', '2', '6', '3') },
- { CODEC_ID_H263P, mmioFOURCC('H', '2', '6', '3') },
- { CODEC_ID_H263I, mmioFOURCC('I', '2', '6', '3') },
- { CODEC_ID_H264, mmioFOURCC('H', '2', '6', '4') },
- { CODEC_ID_MSMPEG4V3, mmioFOURCC('D', 'I', 'V', '3') },
- { CODEC_ID_MPEG4, mmioFOURCC('D', 'I', 'V', 'X') },
- { CODEC_ID_MSMPEG4V2, mmioFOURCC('M', 'P', '4', '2') },
- { CODEC_ID_FLV1, mmioFOURCC('F', 'L', 'V', '1') },
- { CODEC_ID_MJPEG, mmioFOURCC('M', 'J', 'P', 'G') },
- { CODEC_ID_DTS, 0x10 },
- { CODEC_ID_MP2, 0x50 },
- { CODEC_ID_MP3, 0x55 },
- { CODEC_ID_AC3, WAVE_FORMAT_DVM },
- { CODEC_ID_AAC, 'M' | ('P' 8) }, // MP4A
- { CODEC_ID_DVVIDEO, mmioFOURCC('D', 'V', 'S', 'D') },
- { CODEC_ID_DVAUDIO, ('D' 8) | 'A' },
- { CODEC_ID_NONE }
+ { AV_CODEC_ID_MPEG1VIDEO, RIFFINFO_MPG1 },
+ { AV_CODEC_ID_MPEG1VIDEO, mmioFOURCC('P', 'I', 'M', '1') },
+ { AV_CODEC_ID_MPEG2VIDEO, RIFFINFO_MPG2 },
+ { AV_CODEC_ID_H263, mmioFOURCC('H', '2', '6', '3') },
+ { AV_CODEC_ID_H263P, mmioFOURCC('H', '2', '6', '3') },
+ { AV_CODEC_ID_H263I, mmioFOURCC('I', '2', '6', '3') },
+ { AV_CODEC_ID_H264, mmioFOURCC('H', '2', '6', '4') },
+ { AV_CODEC_ID_MSMPEG4V3, mmioFOURCC('D', 'I', 'V', '3') },
+ { AV_CODEC_ID_MPEG4, mmioFOURCC('D', 'I', 'V', 'X') },
+ { AV_CODEC_ID_MSMPEG4V2, mmioFOURCC('M', 'P', '4', '2') },
+ { AV_CODEC_ID_FLV1, mmioFOURCC('F', 'L', 'V', '1') },
+ { AV_CODEC_ID_MJPEG, mmioFOURCC('M', 'J', 'P', 'G') },
+ { AV_CODEC_ID_DTS, 0x10 },
+ { AV_CODEC_ID_MP2, 0x50 },
+ { AV_CODEC_ID_MP3, 0x55 },
+ { AV_CODEC_ID_AC3, WAVE_FORMAT_DVM },
+ { AV_CODEC_ID_AAC, 'M' | ('P' 8) }, // MP4A
+ { AV_CODEC_ID_DVVIDEO, mmioFOURCC('D', 'V', 'S', 'D') },
+ { AV_CODEC_ID_DVAUDIO, ('D' 8) | 'A' },
+ { AV_CODEC_ID_NONE }
};
//printf(TRANSLATE %d0x%x\n, id, id);
for (const struct id2fcc* p = id2fcct; p-id; p++)
@@ -60,7 +60,7 @@
AVM_WRITE(FF stream, Starttime:% PRId64 Duration:%fs\n, m_StartTime, m_dLength);
//printf(codec %d %.4s\n, avs-codec-codec_id, avs-codec-codec_tag);
//printf(CODECRA %d %d %d\n, avs-codec-frame_rate, avs-codec-frame_rate_base, avs-r_frame_rate_base);
-if (0 avs-codec-codec_id == CODEC_ID_MPEG1VIDEO)
+if (0 avs-codec-codec_id == AV_CODEC_ID_MPEG1VIDEO)
{
m_pAvContext = avcodec_alloc_context3(NULL);
//AVCodec* codec = avcodec_find_encoder(avs-codec-codec_id);
@@ -252,7 +252,7 @@
wfx.cbSize = (uint16_t)(wfx.cbSize + avs-codec-extradata_size);
}
- if (avs-codec-codec_id == CODEC_ID_AAC) {
+ if (avs-codec-codec_id == AV_CODEC_ID_AAC) {
// hmm currenly hack - ffmpeg seems to fail properly detect this stream
wfx.nChannels = 2;
wfx.nSamplesPerSec = 44100;
Index: avifile-0.7.48~20090503.ds/plugins/libffmpeg/FFAudioDecoder.cpp
===
--- avifile-0.7.48~20090503.ds.orig/plugins/libffmpeg/FFAudioDecoder.cpp 2014-03-01 07:53:20.0 +
+++ avifile-0.7.48~20090503.ds/plugins/libffmpeg/FFAudioDecoder.cpp 2014-03-02 08:03:38.747337206 +
@@ -17,6 +17,8 @@
avcodec_close(m_pAvContext);
free(m_pAvContext);
}
+avresample_free(avr);
+av_frame_free(frame);
}
int FFAudioDecoder::Convert(const void* in_data, size_t in_size,
@@ -53,25 +55,58 @@
m_pAvContext = 0;
return -1;
}
+frame = av_frame_alloc();
+if (!frame)
+return -1;
}
//printf(%0lx %0lx %0lx %0lx\n, ((long*)in_data)[0], ((long*)in_data)[1], ((long*)in_data)[2], ((long*)in_data)[3]);
+
AVPacket avpkt;
av_init_packet(avpkt);
avpkt.data = (uint8_t*)in_data;
avpkt.size = (int)in_size;
-int framesz = AVCODEC_MAX_AUDIO_FRAME_SIZE;
-#ifdef HAVE_AVCODEC_DECODE_AUDIO3
-int hr = avcodec_decode_audio3(m_pAvContext, (int16_t*)out_data, framesz, avpkt);
-#else
-int hr = avcodec_decode_audio2(m_pAvContext, (int16_t*)out_data, framesz,
- avpkt.data, avpkt.size);
-#endif
-//printf(CONVERT ins: %d outs:% PRIsz fs:%d h:%d\n, avpkt.size, out_size, framesz, hr);
+
+int got_output;
+int hr = avcodec_decode_audio4(m_pAvContext, frame, got_output, avpkt);
+
if (size_read)
*size_read = (hr 0) ? 1 : hr;
-if
Bug#739956: Fails with linux-vdso.so.1 not found
Le 2014-03-01 00:27, Yuri D'Elia a écrit : So what's broken currently on amd64? (because that's the only platform I'm planning to use anyway). Currently pstack rely on a frame pointer to exist. Of course, this is not the case when a program is compiled with -O2 for instance. I'm currently working on a fix but at a very slow pace because everytime I work on it I only have a few minutes and it's about the time I need to remember where I left off. If I can find 1 hour one day, and I hope I will soon, I could fix it once and for all. In the mean time, did you try latest version from the git repo I gave you the link? Did it fix the problem for you? Best regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740482: RFS: [RC][security] imagemagick/8:6.7.7.10-8
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package imagemagick * Package name: imagemagick Version : 8:6.7.7.10-8 Section : graphics It builds those binary packages: imagemagick - image manipulation programs imagemagick-common - image manipulation programs -- infrastructure imagemagick-dbg - debugging symbols for ImageMagick imagemagick-doc - document files of ImageMagick libmagick++-dev - object-oriented C++ interface to ImageMagick - development files libmagick++5 - object-oriented C++ interface to ImageMagick libmagickcore-dev - low-level image manipulation library - development files libmagickcore5 - low-level image manipulation library libmagickcore5-extra - low-level image manipulation library - extra codecs libmagickwand-dev - image manipulation library - development files libmagickwand5 - image manipulation library perlmagick - Perl interface to the ImageMagick graphics routines To access further information about this package, please visit the following URL: http://mentors.debian.net/package/imagemagick Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/i/imagemagick/imagemagick_6.7.7.10-8.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: Fix three security bug Regards, bastien roucaries -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740463: libelmersolver-6.1.so links with both GPL-licensed and GPL-incompatible libraries
On Sat, 1 Mar 2014 23:50:15 +0100 Anton Gladky wrote: (D) link elmer against libmetis and libmumps to escape linkage against SCOTCH. If it is possible, of course. Hi Anton, yes, METIS (the serial version) seems to be under the Apache License v2.0 which is compatible with the GNU GPL v3 (but not with the GNU GPL v2). Hence, as long as libelmersolver-6.1 is not linked with other Apache-v2-incompatible libraries, this fourth strategy could also solve the licensing issue. Of course, assuming it is technically feasible, as you said. Please note that, although METIS is Free Software under the Apache License v2.0, its parallel version ParMETIS seems [1] to be restricted to educational/research purposes, thus being non-free software. [1] http://glaros.dtc.umn.edu/gkhome/metis/parmetis/download It would be great if someone managed to get in touch with ParMETIS copyright holders and persuaded them to re-license it under DFSG-free and GPL-compatible terms. The Apache License v2.0 would be very good, but it would be even greater, if the chosen license were GPL-v2-and-v3-compatible (such as the GNU GPL v2 or later, the GNU LGPL v2.1, or even the Expat license or the 3-clause BSD license...). Anton, do you have any contact with ParMETIS copyright holders? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgppqIffVzN_Y.pgp Description: PGP signature
Bug#740463: libelmersolver-6.1.so links with both GPL-licensed and GPL-incompatible libraries
On Sat, 01 Mar 2014 23:13:00 +0100 Francesco Poli (wintermute) wrote: [...] Since SCOTCH used to be LGPL-licensed (before switching to CeCILL-C! oh nooo!), I got in touch with the main author of SCOTCH (François Pellegrini) and tried to persuade him that SCOTCH should be re-licensed [...] Just to be clear: what I attempted to persuade François to do is to (get the necessary paperwork to) re-license SCOTCH back under the GNU LGPL v2.1 or, at least, to dual-license it under the GNU LGPL v2.1 or the CeCILL-C v1.0 (at the recipient's choice). -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp5qmLMaAtoq.pgp Description: PGP signature
Bug#740483: libglib2.0-0: GLib-GObject-CRITICAL **: gtype.c:2720: You forgot to call g_type_init()
Package: libglib2.0-0 Version: 2.38.2-5 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? starting xfce4-terminal, for example (but problem occurs for other programs as well) * What exactly did you do (or not do) that was effective (or ineffective)? see above * What was the outcome of this action? xfce4-terminal crashes, reproducible every time (process:20585): GLib-GObject-CRITICAL **: gtype.c:2720: You forgot to call g_type_init() (process:20585): GLib-GObject-CRITICAL **: gtype.c:2720: You forgot to call g_type_init() (process:20585): GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed (process:20585): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed (process:20585): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed (process:20585): GLib-GObject-CRITICAL **: gtype.c:2720: You forgot to call g_type_init() (process:20585): GLib-GObject-CRITICAL **: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed (process:20585): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed (process:20585): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed (process:20585): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed (process:20585): GLib-GObject-CRITICAL **: g_object_new: assertion 'G_TYPE_IS_OBJECT (object_type)' failed ** GLib-GIO:ERROR:gdbusconnection.c:6816:get_uninitialized_connection: assertion failed: (ret != NULL) Abgebrochen * What outcome did you expect instead? xfce4-terminal should start I tried to replace libglib2.0-0 by the version from experimental; to no effect. *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libglib2.0-0 depends on: ii libc6 2.17-97 ii libffi63.0.13-12 ii libpcre3 1:8.31-2 ii libselinux12.2.2-1 ii multiarch-support 2.17-97 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages libglib2.0-0 recommends: ii libglib2.0-data 2.38.2-5 ii shared-mime-info 1.2-1 libglib2.0-0 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#740484: Broken libcryptsetup.so symlink: /sbin/ldconfig.real: Cannot mmap file
Package: libcryptsetup-dev Version: 2:1.6.4-1 Severity: grave During the latest cryptsetup update, I got this error message: Processing triggers for libc-bin (2.18-3) ... /sbin/ldconfig.real: Cannot mmap file /usr/lib/x86_64-linux-gnu/libcryptsetup.so. Indeed, /usr/lib/x86_64-linux-gnu/libcryptsetup.so is not a symlink to the actual shared library, but a symlink pointing to /lib ls -al /usr/lib/x86_64-linux-gnu/libcryptsetup.so lrwxrwxrwx 1 root root 4 Mär 2 01:33 /usr/lib/x86_64-linux-gnu/libcryptsetup.so - /lib -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcryptsetup-dev depends on: ii libcryptsetup4 2:1.6.4-1 libcryptsetup-dev recommends no packages. libcryptsetup-dev 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#477463: Somewhat a misnomer
On 2014-03-02 02:48:16 -0500, George Gensure wrote: So this problem is less about color and wrapping as it is rxvt's (and as you've noted, xterm's) treatment of the CSI_EL escape sequence, which is emitted by grep --color=always, surrounding the matched text as follows: \E[01;31m\E[Kmatch\E[m\[K Omitting the \E[K sequences in this pattern correctly displays colored characters at the end of a line with no strangeness surrounding the wrapping. I'm stepping through the ECMA spec now to see if it prescribes what is happening, and to try to discern the way to avoid the line mangling seen here. I will follow up with xterm as well to identify this as an inconsistency. It seems to be a bug in grep: https://bugs.debian.org/477461 I suppose that this bug should be reassigned to grep and merged with 477461. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715504: [Build-common-hackers] Bug#715504: Please call dh_install before dh_systemd_*
tags 715504 help moreinfo thanks Quoting Michael Stapelberg (2013-07-09 21:14:08) When trying to update the miredo package (which uses cdbs), I realized that dh_systemd_enable, dh_installinit and dh_systemd_start are called _before_ dh_install. dh_install is used in this case to install miredo.service into the files for the “miredo” package (as opposed to “miredo-server”). dh_systemd_enable is called _before_ dh_install and therefore cannot find any unit files. Debhelper’s dh(1) does it in the right order: it first calls dh_install, then dh_systemd_enable. This affects all packages that ship a systemd service file upstream. It does not affect the packages which ship a systemd service file in debian/, which is why it was not found when testing :-). Thanks for the bugreport. I have honestly no clue about systemd, so need some more specific hand-holding here, please. A patch would be quite welcome, but just very specific description on which exact calls need to be moved before/after which exact other calls is also useful. It seems in fact that this initial bugreport does that, in that it talks solely about dh_systemd_enable needing execution after dh_install. But subject talks about dh_systemd_* and a follow-up also talks about other calls than dh_systemd_enable. I need help here. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#511153: tzsetup-udeb: time zone list in tzsetup out of date wrt glibc/tzdata time
Quoting Cyril Brulebois (k...@debian.org): Actually, there might me other cases like this one as I haven't seen anyone actively trying to cope with changes in tzdata to align tzsetup with them (such as the recent nightmare in Argentinian timezones). what should we do about this bug report? IIRC, there have been a few moments in various releases, where the list of possible timezones for multi-TZ countries have been updated. So, in short, it can be closed, IMHO. signature.asc Description: Digital signature
Bug#740485: linux-image-3.11-2-amd64: trackpad events are not always generated
Package: src:linux Version: 3.11.10-1 Severity: important I got a kernel freeze and had to reboot. But since the reboot, trackpad events are not always generated. -- Package-specific info: ** Version: Linux version 3.11-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04) ** Command line: root=/dev/mapper/xvii-root ro quiet reboot=pci ** Not tainted ** Kernel log: [ 21.595515] nouveau [ PTHERM][:01:00.0] FAN control: PWM [ 21.595524] nouveau [ PTHERM][:01:00.0] fan management: disabled [ 21.595535] nouveau [ PTHERM][:01:00.0] internal sensor: yes [ 21.595759] [TTM] Zone kernel: Available graphics memory: 2024018 kiB [ 21.595761] [TTM] Initializing pool allocator [ 21.595765] [TTM] Initializing DMA pool allocator [ 21.595775] nouveau [ DRM] VRAM: 256 MiB [ 21.595777] nouveau [ DRM] GART: 1048576 MiB [ 21.595781] nouveau [ DRM] TMDS table version 2.0 [ 21.595783] nouveau [ DRM] DCB version 4.0 [ 21.595785] nouveau [ DRM] DCB outp 00: 01000323 00010034 [ 21.595787] nouveau [ DRM] DCB outp 01: 02011300 0028 [ 21.595789] nouveau [ DRM] DCB outp 02: 02022386 0f200010 [ 21.595791] nouveau [ DRM] DCB outp 03: 02022332 00020010 [ 21.595793] nouveau [ DRM] DCB outp 04: 040333a6 0f200010 [ 21.595795] nouveau [ DRM] DCB outp 05: 04033312 00020010 [ 21.595796] nouveau [ DRM] DCB conn 00: 0041 [ 21.595799] nouveau [ DRM] DCB conn 01: 0100 [ 21.595801] nouveau [ DRM] DCB conn 02: 5246 [ 21.595802] nouveau [ DRM] DCB conn 03: a346 [ 21.611861] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 21.611864] [drm] No driver support for vblank timestamp query. [ 21.611868] nouveau [ DRM] ACPI backlight interface available, not registering our own [ 21.612078] nouveau [ DRM] 4 available performance level(s) [ 21.612082] nouveau [ DRM] 0: core 169MHz shader 338MHz memory 100MHz voltage 900mV fanspeed 100% [ 21.612085] nouveau [ DRM] 1: core 275MHz shader 550MHz memory 250MHz voltage 900mV fanspeed 100% [ 21.612088] nouveau [ DRM] 2: core 500MHz shader 1000MHz memory 400MHz voltage 1090mV fanspeed 100% [ 21.612091] nouveau [ DRM] 3: core 580MHz shader 1450MHz memory 400MHz voltage 1170mV fanspeed 100% [ 21.612093] nouveau [ DRM] c: core 275MHz shader 550MHz memory 249MHz voltage 900mV [ 21.630243] nouveau [ DRM] MM: using M2MF for buffer copies [ 21.689299] nouveau [ DRM] allocated 1440x900 fb: 0x6, bo 88011898b800 [ 21.689388] fbcon: nouveaufb (fb0) is primary device [ 21.743787] dell_wmi: Received unknown WMI event (0x11) [ 21.854252] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_0.3M (0c45:63f8) [ 21.868541] input: Laptop_Integrated_Webcam_0.3M as /devices/pci:00/:00:1a.7/usb7/7-6/7-6:1.0/input/input14 [ 21.868593] usbcore: registered new interface driver uvcvideo [ 21.868593] USB Video Class driver (1.1.1) [ 21.876042] iwlwifi :0c:00.0: CONFIG_IWLWIFI_DEBUG disabled [ 21.876043] iwlwifi :0c:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [ 21.876044] iwlwifi :0c:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [ 21.876046] iwlwifi :0c:00.0: CONFIG_IWLWIFI_P2P enabled [ 21.876047] iwlwifi :0c:00.0: Detected Intel(R) Ultimate N WiFi Link 5300 AGN, REV=0x24 [ 21.876157] iwlwifi :0c:00.0: L1 Enabled; Disabling L0S [ 21.903592] iwlwifi :0c:00.0: RF_KILL bit toggled to disable radio. [ 22.261214] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [ 23.024260] Console: switching to colour frame buffer device 180x56 [ 23.027225] nouveau :01:00.0: fb0: nouveaufb frame buffer device [ 23.027227] nouveau :01:00.0: registered panic notifier [ 23.027231] [drm] Initialized nouveau 1.1.1 20120801 for :01:00.0 on minor 0 [ 23.031064] dell_wmi: Received unknown WMI event (0x11) [ 25.581878] EXT4-fs (dm-1): re-mounted. Opts: (null) [ 26.105243] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro [ 27.123137] lp: driver loaded but no devices found [ 27.279500] ppdev: user-space parallel port driver [ 27.469544] fuse init (API version 7.22) [ 27.507963] loop: module loaded [ 27.973827] Adding 9928700k swap on /dev/mapper/xvii-swap_1. Priority:-1 extents:1 across:9928700k [ 29.398211] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem [ 29.402008] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null) [ 38.364359] RPC: Registered named UNIX socket transport module. [ 38.364363] RPC: Registered udp transport module. [ 38.364365] RPC: Registered tcp transport module. [ 38.364366] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 38.436999] FS-Cache: Loaded [ 38.612556] FS-Cache: Netfs 'nfs' registered for caching [ 38.702021] Installing knfsd (copyright (C) 1996
Bug#673644: Message at end of successful install talks about floppies (should be updated)
Quoting Cyril Brulebois (k...@debian.org): _Description: Installation complete Installation is complete, so it is time to boot into your new system. - Make sure to remove the installation media (CD-ROM, floppies), so that - you boot into the new system rather than restarting the installation. + Make sure to remove the installation media (CD-ROM, DVD-ROM, USB flash + disk), so that you boot into the new system rather than restarting the + installation. Maybe try to be more generic so that we don't have to change this when CD-ROM, DVD or USB flash disk are considered obsolete as well? Something like Make to to remove the installation media so that signature.asc Description: Digital signature
Bug#740486: opendkim: FTBFS on mipsen (test failures)
Source: opendkim Version: 2.9.0-2 Severity: serious Justification: fails to build from source (but built successfully in the past) Control: block 658829 with -1 Hi, opendkim fails to build on the mips and mipsel buildds, see the logs linked from https://buildd.debian.org/status/package.php?p=opendkim Lots of tests fail with opendkim.c:6088: dkimf_config_free: Assertion `conf-conf_refcnt == 0' failed. Cheers, Julien signature.asc Description: Digital signature
Bug#740487: clisp: FTBFS on kfreebsd
Source: clisp Version: 1:2.49-9 Severity: serious Justification: fails to build from source (but built successfully in the past) Control: block 658829 with -1 Hi, your package fails to build on the kfreebsd buildds, see logs at https://buildd.debian.org/status/package.php?p=clisp Seems to die with make[1]: *** [interpreted.mem] Illegal instruction Cheers, Julien signature.asc Description: Digital signature
Bug#740488: gksu: impossible to run root terminal if it has been closed until re-login
Package: gksu Version: 2.0.2-6 Severity: grave Justification: renders package unusable It's impossible to run root terminal if it has been closed until re-login. I use Gnome/Gnome classic mode and running Root terminal from Applications--Accessories And I'm able to run it once. And if I close the window then I'm not able to run it again until re-login to the Gnome session(doesn't matter regular or classic mode). And it doesn't gives me any errors when running. I have got this bug on my virtual machine and on my notebook as well after fresh install. So I don't think that it's wrong settings made by myself. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/2 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 gksu depends on: ii libatk1.0-0 2.10.0-2 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libfontconfig12.11.0-2 ii libfreetype6 2.5.2-1 ii libgconf2-4 3.2.6-1 ii libgdk-pixbuf2.0-02.28.2-1+b1 ii libgksu2-02.0.13~pre1-6 ii libglib2.0-0 2.38.2-5 ii libgnome-keyring0 3.4.1-1 ii libgtk2.0-0 2.24.22-1 ii libpango1.0-0 1.36.0-1+b1 ii libstartup-notification0 0.12-3 ii sudo 1.8.9p5-1 Versions of packages gksu recommends: ii gnome-keyring 3.8.2-2+b1 gksu 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#738645: Processed: severity of 738645 is serious, retitle 738645 to FTBFS: Transition from libdb5.1-dev to libdb5.3-dev
Control: severity -1 serious On Wed, Feb 19, 2014 at 15:08:41 +0100, Matthias Klose wrote: Control: severity -1 wishlist Am 19.02.2014 14:54, schrieb Debian Bug Tracking System: Processing commands for cont...@bugs.debian.org: severity 738645 serious Bug #738645 [python-bsddb3] python-bsddb3: Please update build depends to libdb5.3-dev Severity set to 'serious' from 'important' retitle 738645 FTBFS: Transition from libdb5.1-dev to libdb5.3-dev Bug #738645 [python-bsddb3] python-bsddb3: Please update build depends to libdb5.3-dev Changed Bug title to 'FTBFS: Transition from libdb5.1-dev to libdb5.3-dev' from 'python-bsddb3: Please update build depends to libdb5.3-dev' thanks Stopping processing here. Please contact me if you need assistance. no, there is no reason to do that. s390 still doesn't have db5.3. All release architectures have db5.3, and this is one of the last packages to depend on db5.1, which is not going to ship in jessie, so there's every reason to do that afaict. Cheers, Julien signature.asc Description: Digital signature
Bug#737906: transition: eglibc
On Sun, Feb 23, 2014 at 21:03:41 +, Adam D. Barratt wrote: On Mon, 2014-02-17 at 18:20 +, Adam D. Barratt wrote: On 2014-02-06 21:20, Adam Conrad wrote: Requestion a transition slot to upload eglibc 2.18 to unstable. The number of rdeps with an exact glibc dependency (due to using internal symbols) is quite low, and should all be binNMUable. Assuming that all we're expecting to be involved is the binNMUs, please go ahead (i.e. there aren't a bunch of FTBFS against eglibc 2.18 bugs hiding up your sleeve somewhere :-). The binNMUs are all scheduled and have mostly built now; we're just waiting for mipsel to chew through a few large packages which all seem to have got picked up at the same time. One problem is libnih's FTBFS on i386 - #739913. there's now a couple of RC upgrade bugs against new libc, status update from Aurelien: jcristau aurel32: what's the status of libc 2.18? aurel32 jcristau: i am still working on it, doing builds and upgrade tests aurel32 i hope to have something today Cheers, Julien signature.asc Description: Digital signature
Bug#740489: include correct UA version string
package: libjs-jssip version: 0.4.0.20140212.1-1 The UA version string in the SIP headers is incorrect This is a bug in the way we use make instead of upstream's grunt build system to build the JavaScript. If grunt becomes part of Debian, then we will just use grunt and the problem will go away. If not, then we need to improve the Makefile to fix this and similar issues. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736077: [Pkg-javascript-devel] Bug#736077: dont leak private network information (at least not by default)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/14 15:22, Holger Levsen wrote: package: libjs-jssip tags: security Hi Daniel, thanks for working on usuable + secure RTC in the webbrowser! During your presentation at the Paris mini-debconf I just learned that your libjs-jssip leaks all networks to the sip server (or calling party), which I consider a privacy violation (which has been implemented to improve the user experience by allowing the application to choose the best network connection). Still, if I connect via route $X I expect this software not to leak my other routes, which might contaín sensitive information. In the talk you said it was trivial to comment out these lines, so I'm asking you to do this by default and optionally allow it. I actually did some experiments with this (using a PyRoute script in the SIP proxy to strip some ICE candidates from the SDP message body) I found that sometimes the other end of the connection wasn't happy with the SDP. Maybe there is something embedded in the STUN ICE check messages and the peer knows that the SDP has been modified. I would need to look more closely at the spec to find out. I'm CCing the Jitsi dev list, they develop the ice4j ICE library for Java and may be able to comment on this. It may also be useful for Jitsi, Empathy and other softphones to offer a similar feature and if it is practical, please raise the same bug against those packages. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEw8hAAoJEOm1uwJp1aqDpwAQAKaSO1626Q0FbYxkxL/6iEhv 03JCDeAHbpe7GWIYvJipjiq4l7WMxq1afYD7FInp39HOlvjcqjl3Pu//5NWR4043 R1hR/8M7+248Vk6Ss0eFNZuGnlSjl1Dg/ADrVlZTlmvEGjEfcLA20454dWEZWJII fy3yHNPthHeqza/QxYvCt5CjwLotnOyUZXOpIM9VvxAm/GIRLo48fCGQYCmAZsHy mjSnyX/MPoRYXo3OQTrvHjCVZzj/5DR/rNEsvIHannCwQdKJOQrALNJgHi5Q9g6u J3LnF36I+zcdnIle4MS+gjNQ5oVHzZBJ52OsGGFgzBreK4r09OUkpZStRQKpkZ9s iW9oPUNEjpMEafc37MYpCPN6xrGquIDZM2Y8lo3hrF3ZlZytJYlApaIjcTQNk5IK KKsS7UOPmBsoYFIM/qWUppTyWMEdO6KWRjyQxsFyHlQ/HGuDUQLYkk3PginNj46W o7V20ujhct8Lm1ah7KeYxKAJt3AZ6u8GJrgSYE89+ZUBZ5OYtXFXMflq8WCcoEiK B4hCvgCbTzzbsKDOt1S3xDEczeelP+aNbuhHFE+NfkpOuuvkk5K5WqdF2SvSgcYq GH3uZkJ3xmKHG+lfZEYj0P999j6IUMwbY80VhrjE3u7fl8sZA5RHwunftyhqSn7o NxIXj7mL2MBBr8VHcGel =LRNH -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#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
Am Sat, 01 Mar 2014 01:00:02 +0900 schrieb Taihei Momma t...@mac.com: OK, after some investigation with armhf cross environment and qemu, finally the current mpg123 svn (r3517) should work After Tahei didn't stop at this (big thanks from here!), we got a new snapshot, http://mpg123.org/snapshot/mpg123-20140302115523.tar.bz2 , that will hopefully become mpg123 1.19.0 soon (not 1.18.x because of feature additions regarding this very debian issue). The main points: - float output with all decoders (also arm_nofpu) - ARM decoders (esp. NEON) working with debian toolchain - new --with-cpu=arm_fpu choice with runtime detection to switch between NEON or normal FPU So, the number of builds for optimal treatment of differing platforms reduces to two: 1. --with-cpu=arm_nofpu 2. --with-cpu=arm_fpu I hope we can all be happy about that. I'd also be glad to get some confirmation from debian that it really works now. Release will be imminent, then. Thanks for staying with us with all the chattering about this ... Alrighty then, Thomas signature.asc Description: PGP signature
Bug#718624: still fails with systemd
On Sb, 15 feb 14, 12:45:43, Antoine Beaupré wrote: This works! Here's the modified service file: [Unit] Description=Transmission BitTorrent Daemon After=network.target [Service] User=debian-transmission Type=simple Type=notify would be even better, see https://trac.transmissionbt.com/ticket/4503 for more info. #EnvironmentFile=-/etc/default/transmission-daemon ExecStart=/usr/bin/transmission-daemon -f --log-error [Install] WantedBy=multi-user.target Notice how I *don't* import the environment from the existing defaults file, which is a shame because we loose some settings, but this is unavoidable because --config-dir really breaks everything. Maybe there would be a way to still import $OPTIONS from the defaults yet override the --config-dir somehow to fix those problems? Anyways, it would be nice to have a clean upgrade path here. :) The package /etc/default/transmission file only has three variables, so it's probably doable to just work based on their values. I'll try to write something that looks like shell :p # since both sysv-rc and systemd will try to start the daemon by default # we only need to disable it if the user changed the default value if [ 0 = $ENABLE_DAEMON ]; then update-rc.d disable $DAEMON fi # migrate to new location in the home of the transmission user if [ /var/lib/transmission-daemon/info = $CONFIG_DIR ] [ --config-dir $CONFIG_DIR = $OPTIONS ] $$ [ -z $START_STOP_OPTIONS ]; then mv $CONFIG_DIR $NEW_CONFIG_DIR rm -f /etc/default/transmission else # the admin customised things here, we should not try to guess # further and just let him deal with the migration display big fat warning that further settings in /etc/default/transmission will be ignored fi It would probably also be a good ideat to consider renaming the debian-transmission user to _transmission as per discussions on -devel, especially since _transmission is also quite long. AFAICT the most recent thread starts at http://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1dea...@sun-dag3.synchrotron-soleil.fr Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#740485: linux-image-3.11-2-amd64: trackpad events are not always generated
Control: tag -1 moreinfo On Sun, 2014-03-02 at 11:12 +0100, Vincent Lefevre wrote: Package: src:linux Version: 3.11.10-1 [...] This is quite old; try 3.13 from unstable. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#740490: Change hardware.conf defaults
Package: lirc Version: 0.9.0~pre1-1 Hi, I suggest the following patch for hardware.conf: --- /tmp/hardware.conf 2014-03-02 10:52:28.229878749 + +++ /etc/lirc/hardware.conf 2014-03-02 10:55:30.005150849 + @@ -12,10 +12,12 @@ #Try to load appropriate kernel modules LOAD_MODULES=true +# You can set a driver here if your device is not supported by the lirc kernel modules # Run lircd --driver=help for a list of supported drivers. -DRIVER=UNCONFIGURED +#DRIVER=UNCONFIGURED + # usually /dev/lirc0 is the correct setting for systems using udev -DEVICE= +DEVICE=/dev/lirc0 MODULES= # Default configuration files for your hardware if any This way: * We document the fact that setting the DRIVER is not mandatory. * lircd will work by default for all devices supported by kernel drivers * to my knowledge /dev/lirc0 is the right device name used by kernel drivers. Otherwise lircd default /dev/lirc is used. I also filed an lircd issue upstream to ask to change the default /dev/lirc to /dev/lirc0: https://sourceforge.net/apps/mantisbt/lirc/view.php?id=2 Thanks in advance, Marc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 01/03/2014 15:46, Turbo Fredriksson wrote: Please give us/me a direct link to the Debian GNU/Linux policy point that explain that this is not acceptable. I don't have that. I'm telling you that Debian infrastructure is not ready to handle cross-arch namespace collisions based on my experience hitting the exact same problem before. There's a reason we add a freebsd- prefix to functionally equivalent packages like: freebsd-smbfs - mount command for the SMB/CIFS filesystem freebsd-net-tools - FreeBSD networking tools freebsd-nfs-common - NFS support files common to client and server freebsd-nfs-server - FreeBSD server utilities needed for NFS on GNU/kFreeBSD freebsd-ppp - FreeBSD Point-to-Point Protocol (PPP) userland daemon Your repeated insistence on occupying the zfsutils namespace makes me think you have a self-serving reason for this. How do you plan to react when actual breakage happens? On 02/03/2014 05:56, Turbo Fredriksson wrote: That is what OpenZFS.org is for - eventually (hopefully sooner than later), you/we/I will be able to do just that - one source base for all architectures (Linux, FreeBSD, Illumos etc). But we (they) aren't there yet. As it stands today, there are two upstream sources for/in Debian GNU/Linux - one for the Linux kernel and one for the FreeBSD kernel. These share _a lot_ (I can't give you an exact figure, but if I had to give a between thumb and index finger guess, I'd say 90%) of the same code (they both originated from the last open Solaris release before Oracle closed the source again) and provide the exact same functionality, in the exact same way with binary programs that behave the exact same way (same options and parameters etc). Unless I missed something, ZoL is not OpenZFS. And neither ZoL nor OpenZFS support the kernel of FreeBSD at the time of writing. You make it look like you're adding a portable package, when in fact it is a Linux-specific package. The idea that you're adding a portable package is very consistent with your pretension of occupying the namespace. I think it would serve that agenda to imply that ZoL is OpenZFS and the source you're adding is portable, but I don't think you even believe what you're implying. If you truly believe in the unification path, why don't you try Dimitri's suggestion? I notice that you ignored it on your reply to him: On 02/03/2014 03:52, Dimitri John Ledkov wrote: Also, if there is zfs-dkms module available, why existing zfsutils packages just can't enable compilation on linux-any?! Which should also reduce the scope of linux specific packages down to -dkms/-initramfs, and maybe an arch specific patch-series. The packages are so similar, right? Maybe he has a point. Why don't you send patches for zfsutils to enable compilation on linux-any? I'll be happy to work with you. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727204:
This looks like a dupe of #663504 Wheezy netinstaller does not search inserted media for additional files -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663504:
I recently installed Debian 7.0.4 and noted multiple problems: with
the check-missing-firmware phase
1. check-missing-firmware missing files list is incorrect. Installer
detects that wifi needs Broadcom firmware and says The missing
firmware files are: b43/ucode29_mimo.fw b43-open/ucode29_mimo.fw. The
list is incorrect and incomplete. The list contains only two files -
there are many more that are required. The list contains two files,
suggesting that both are needed - in fact only one copy of the file is
needed (the loader looks in two directories).
- This bug seems to be caused by the installer interpreting the
kernel firmware loading in an overly simple way. The firmware loader
attempts to load files sequentially, and looks for them in two places.
If it does not find a file, it will immediately quit and print the two
locations that it looked for the file. The Debian installer interprets
and reports this pair of locations as an absolute list of missing
files. It is not an absolute list, it is a duplicate pair for a single
missing file.
- Even if the file is present (eg. b43/ucode29_mimo.fw exists),
this function still reports b43-open/ucode29_mimo.fw as missing! It's
not missing, it's just an alternative location for the same file.
2. The installer should copy any firmware files on the USB drive in
one go. Because of the way the installer copies and loads one file at
a time, even if the user has done everything perfectly (all required
firmwares ready on a USB drive) the check missing files prompt will
pop up several times (3 in my case) and the user just has to keep
clicking yes. Any normal user is going to think that this is broken,
only users who are really paying attention and watching the logs will
notice that it is only loading one file every time they click
Continue.
3. check-missing-firmware does not work with a USB drive that
contains a partition table. When a USB drive with a single partition
containing the firmware is inserted, it reports that the firmware was
not found. The firmware is on partition /dev/sdc1. From the log I can
see that the function is attempting to scan drives and partitions
detected on the system, and mount them as FAT file systems. The
problem is that it does not try the USB drive partition 1 at
/dev/sdc1. It does try /dev/{sda sda sdc sdc sda1 sda1 sda sda sdc sdc
sda1 sda1 sda2 sda2 sda3 sda3} in that order. So it is trying to mount
/dev/sdc (the USB drive) but not /dev/sdc1 (the actual partition).
- Workaround is to format the USB drive without a partition table,
e.g. mkfs.vfat -I /dev/sdc (mkfs.vfat actually expects a partition
table, -I override forces it to use the entire device)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740485: linux-image-3.11-2-amd64: trackpad events are not always generated
On 2014-03-02 11:03:38 +, Ben Hutchings wrote: Control: tag -1 moreinfo On Sun, 2014-03-02 at 11:12 +0100, Vincent Lefevre wrote: Package: src:linux Version: 3.11.10-1 [...] This is quite old; try 3.13 from unstable. The trackpad is not correctly recognized by 3.12 and 3.13. That's why I'm using 3.11. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#418590: main-menu: Segfault during automatic install on AMD64
On Sun, Mar 2, 2014 at 3:29 AM, Cyril Brulebois k...@debian.org wrote: Is that still reproducible with current wheezy installation images? If that's the case, we'll see how to help you debug that further. Hi KiBi, Let's just close this bug, it has been almost 7 years since it was opened. If it happens again it'll be reported again. -- Olaf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740425: [Pkg-xfce-devel] Bug#740425: libexo-helpers: Please rename epiphany.desktop to epiphany-browser.desktop
Le Sat, 1 Mar 2014 16:24:03 +0100, Yves-Alexis Perez cor...@debian.org a écrit : On Sat, Mar 01, 2014 at 02:13:27PM +0100, Laurent Bigonville wrote: Package: libexo-helpers Version: 0.10.2-2 Severity: normal Hi, In debian, the .desktop file for epiphany (the web browser) has been renamed to epiphany-browser.desktop due to a clash with the name of an other package. Shouldn't this also be reflected in libexo-helpers? Why, does it conflicts against anything? Does it prevent it to work? There are some other programs (I have geoclue-2.0 in mind) that use the the desktop-id (the name of the desktop file without the .desktop part) to identify the running programs. So if this desktop file is use to start epiphany, the desktop-id might be wrong. Cheers, Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740356: Pokerth cannot connect to internet servers
Hi Ritesh, On Fri, Feb 28, 2014 at 09:38:47PM +0530, Ritesh Raj Sarraf wrote: While it doesn't seriously hinder the functionality of the game, but hey,, who'd play poker if no humans were involved. True :) Since the new 1.1 release (which should be a couple of weeks by now), never have I been able to connect to pokerth.net. The error pop-up I get is Could not connect to server. I've verified to ensure that the DNS is working. There's also a possibility that it is a (temporary) problem with the pokerth servers. But wanted to check here first. While I must admit that I do not play online very often, checking online game functionality is one of the things I do before the upload ;) It worked back then, and so it does now, so there has to be some other problem in your setup. Can you check if it works if you move away your ~/.pokerth? If it does: can you verify you have pokerth.net/serverlist.xml.z as the Automatic Server Configuration URL set in the settings? Does PokerTH tell you something on stderr/out if you start it from a console? Are you using IPv6 (have v6 connectivity *and* have it enabled in the settings)? Apologies for this bug report if nobody else has encountered this problem No need to apologise, we all want stuff to be fixed, right? :) Regards Evgeni -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740485: linux-image-3.11-2-amd64: trackpad events are not always generated
Control: notfound -1 3.11.10-1 Control: found -1 3.12.9-1 Control: found -1 3.13.4-1 On Sun, 2014-03-02 at 12:10 +0100, Vincent Lefevre wrote: On 2014-03-02 11:03:38 +, Ben Hutchings wrote: Control: tag -1 moreinfo On Sun, 2014-03-02 at 11:12 +0100, Vincent Lefevre wrote: Package: src:linux Version: 3.11.10-1 [...] This is quite old; try 3.13 from unstable. The trackpad is not correctly recognized by 3.12 and 3.13. That's why I'm using 3.11. Please send boot logs (/var/log/dmesg) from 3.11 and 3.13. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
Bug#740491: nfs-common: fails to upgrade (action restart failed)
Package: nfs-common Version: 1:1.2.8-6 Severity: serious On upgrading today, I got: Setting up nfs-common (1:1.2.8-6) ... Installing new version of config file /etc/init.d/nfs-common ... insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `nfs-common' overrides LSB defaults (S). Job for nfs-common.service failed. See 'systemctl status nfs-common.service' and 'journalctl -xn' for details. invoke-rc.d: initscript nfs-common, action restart failed. dpkg: error processing package nfs-common (--configure): subprocess installed post-installation script returned error exit status 1 [...] Errors were encountered while processing: nfs-common E: Sub-process /usr/bin/dpkg returned an error code (1) $ sudo systemctl status nfs-common.service nfs-common.service - LSB: NFS support files common to client and server Loaded: loaded (/etc/init.d/nfs-common) Active: failed (Result: exit-code) since Sun 2014-03-02 12:22:37 CET; 5min ago Process: 14279 ExecStop=/etc/init.d/nfs-common stop (code=exited, status=0/SUCCESS) Process: 14288 ExecStart=/etc/init.d/nfs-common start (code=exited, status=1/FAILURE) Mar 02 12:22:37 betterave systemd[1]: Starting LSB: NFS support files common to client and server... Mar 02 12:22:37 betterave rpc.statd[14293]: Version 1.2.8 starting Mar 02 12:22:37 betterave rpc.statd[14293]: Failed to read /var/lib/nfs/state: Success Mar 02 12:22:37 betterave rpc.statd[14293]: Initializing NSM state Mar 02 12:22:37 betterave nfs-common[14288]: Starting NFS common utilities: statd failed! Mar 02 12:22:37 betterave systemd[1]: nfs-common.service: control process exited, code=exited status=1 Mar 02 12:22:37 betterave systemd[1]: Failed to start LSB: NFS support files common to client and server. Mar 02 12:22:37 betterave systemd[1]: Unit nfs-common.service entered failed state. Cheers, Julien -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 42073 status 1000241 tcp 42787 status -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD= NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-51 ii libc6 2.17-97 ii libcap2 1:2.22-1.2 ii libcomerr2 1.42.9-3 ii libdevmapper1.02.1 2:1.02.83-2 ii libevent-2.0-5 2.0.21-stable-1 ii libgssglue1 0.4-2 ii libk5crypto31.12+dfsg-2 ii libkeyutils11.5.6-1 ii libkrb5-3 1.12+dfsg-2 ii libmount1 2.20.1-5.6 ii libnfsidmap20.25-5 ii libtirpc1 0.2.2-5.1 ii libwrap07.6.q-25 ii lsb-base4.1+Debian12 ii rpcbind 0.2.1-3 ii ucf 3.0027+nmu1 Versions of packages nfs-common recommends: ii python 2.7.5-5 Versions of packages nfs-common suggests: pn open-iscsi none pn watchdognone -- no debconf information signature.asc Description: Digital signature
Bug#740492: network-manager-vpnc: check connectivity and loop
Package: network-manager-vpnc Version: 0.9.8.6-1 Severity: wishlist VPN connections could drop at time. Sometimes if the keep alive packet is not served, and also for other reasons. It would be good to have loop option available to ensure vpn connectivity. Currently, under NM, I do it using the dispatcher scripts. rrs@zan:~$ cat /etc/NetworkManager/dispatcher.d/02vpnc #!/bin/sh -e # Script to dispatch NetworkManager events # if [ -z $1 ]; then echo $0: called with no interface 12 exit 1; fi # Fake ifupdown environment export IFACE=$1 export LOGICAL=$1 export METHOD=NetworkManager export VERBOSITY=0 if [ $CONNECTION_UUID = 50655113-6dbb-4472-b865-3dadcfc55fb1 ]; then # Run the right scripts case $2 in up) export MODE=start export PHASE=post-up /home/rrs/bin/vpnc-connect.sh ;; down) export MODE=stop export PHASE=post-down /home/rrs/bin/vpnc-disconnect.sh ;; # pre-up/pre-down not implemented. See # https://bugzilla.gnome.org/show_bug.cgi?id=387832 #pre-up) #export MODE=start #export PHASE=pre-up #run-parts /etc/network/if-pre-up.d #;; #pre-down) #export MODE=stop #export PHASE=pre-down #run-parts /etc/network/if-down.d #;; hostname|dhcp4-change|dhcp6-change) # Do nothing ;; *) echo $0: called with unknown action \`$2' 12 exit 1 ;; esac elif [ $CONNECTION_UUID = 09e21baf-848a-4fcd-90a0-34b6f1890adc ]; then # Run the right scripts case $2 in up) export MODE=start export PHASE=post-up /home/rrs/bin/vpnc-connect-external.sh ;; down) export MODE=stop export PHASE=post-down /home/rrs/bin/vpnc-disconnect-external.sh ;; hostname|dhcp4-change|dhcp6-change) # Do nothing ;; *) echo $0: called with unknown action \`$2' 12 exit 1 ;; esac fi exit $? == And then, a loop inside the calling shell script == rrs@zan:~$ cat ~/bin/vpnc-connect.sh #!/bin/bash SUDO=/usr/bin/sudo VPNC_CONNECT=/usr/sbin/vpnc-connect VPNC_DISCONNECT=/usr/sbin/vpnc-disconnect if ! [ `pidof -x vpnc-loop.sh` ]; then /home/rrs/bin/vpnc-loop.sh fi rrs@zan:~$ cat ~/bin/vpnc-loop.sh #!/bin/sh while true; do # Check if vpnc is running. pidof vpnc-connect sleep 150 continue; # If not running, run it. sudo vpnc-disconnect /dev/null; sleep 1; sudo vpnc-connect /dev/null; sleep 150; done rrs@zan:~$ cat ~/bin/vpnc-disconnect.sh #!/bin/bash SUDO=/usr/bin/sudo VPNC_CONNECT=/usr/sbin/vpnc-connect VPNC_DISCONNECT=/usr/sbin/vpnc-disconnect test `pidof -x vpnc-loop.sh` kill -9 `pidof -x vpnc-loop.sh` $SUDO $VPNC_DISCONNECT == Having something like this natively in NM would be a good feature. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-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 network-manager-vpnc depends on: ii libc6 2.17-97 ii libdbus-1-3 1.8.0-1 ii libdbus-glib-1-2 0.102-1 ii libglib2.0-0 2.38.2-5 ii libnm-glib-vpn1 0.9.8.0-5 ii libnm-glib4 0.9.8.0-5 ii libnm-util2 0.9.8.0-5 ii vpnc 0.5.3r512-2 network-manager-vpnc recommends no packages. network-manager-vpnc 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#740494: openssh-server: Additional arguments for AuthorizedKeysCommand
Package: openssh-server
Version: 1:6.5p1-5
Severity: wishlist
Tags: upstream patch
Dear Maintainer,
I would like sshd to pass some more arguments to the AuthorizedKeysCommand
in order to print the authorized keys in a more intelligent manner.
I was thinking of the Github case, i.e. lots of real users want to
authenticate as the git user, which is currently not feasable because the only
argument to the AuthorizedKeysCommand is the username being authenticated,
which is git for everybody. To allow everyone to authenticate as the git
user, the AuthorizedKeysCommand has to print all the public keys of all the
real users to standard output and sshd in turn has to parse all those keys
and match them against the key that is used for authentication.
This patch passes two additional arguments to the AuthorizedKeysCommand:
- the type of the key used for authentication, e.g. ssh-rsa,
- the MD5 fingerprint of the key used for authentication
This allows the AuthorizedKeysCommand to print only a small subset of the
public keys.
I also submitted this patch to upstream:
https://bugzilla.mindrot.org/show_bug.cgi?id=2081
Cheers
Florian
-- System Information:
Debian Release: 7.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-486
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages openssh-server depends on:
ii adduser 3.113+nmu3
ii dpkg 1.16.12
ii init-system-helpers 1.17
ii libc62.13-38+deb7u1
ii libcomerr2 1.42.5-1.1
ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u1
ii libkrb5-31.10.1+dfsg-5+deb7u1
ii libpam-modules 1.1.3-7.1
ii libpam-runtime 1.1.3-7.1
ii libpam0g 1.1.3-7.1
ii libselinux1 2.1.9-5
ii libssl1.0.0 1.0.1e-2+deb7u4
ii libwrap0 7.6.q-24
ii lsb-base 4.1+Debian8+deb7u1
ii openssh-client 1:6.5p1-5
ii openssh-sftp-server 1:6.5p1-5
ii procps 1:3.3.3-3
ii zlib1g 1:1.2.7.dfsg-13
Versions of packages openssh-server recommends:
ii ncurses-term 5.9-10
ii xauth 1:1.0.7-1
Versions of packages openssh-server suggests:
pn molly-guard none
pn monkeysphere none
pn rssh none
pn ssh-askpass none
pn ufw none
-- no debconf information
diff --git a/auth2-pubkey.c b/auth2-pubkey.c
index 7c56927..9203f53 100644
--- a/auth2-pubkey.c
+++ b/auth2-pubkey.c
@@ -512,7 +512,8 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key)
struct stat st;
int status, devnull, p[2], i;
pid_t pid;
- char *username, errmsg[512];
+ char *username, errmsg[512], *key_fp;
+ const char *key_type_name;
if (options.authorized_keys_command == NULL ||
options.authorized_keys_command[0] != '/')
@@ -552,8 +553,15 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key)
goto out;
}
- debug3(Running AuthorizedKeysCommand: \%s %s\ as \%s\,
- options.authorized_keys_command, user_pw-pw_name, pw-pw_name);
+ key_type_name = key_ssh_name(key);
+ if (key_type_name == NULL)
+ key_type_name = ssh-unknown;
+
+ key_fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX);
+
+ debug3(Running AuthorizedKeysCommand: \%s %s %s %s\ as \%s\,
+ options.authorized_keys_command, user_pw-pw_name,
+ key_type_name, key_fp, pw-pw_name);
/*
* Don't want to call this in the child, where it can fatal() and
@@ -566,6 +574,7 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key)
error(%s: fork: %s, __func__, strerror(errno));
close(p[0]);
close(p[1]);
+ free(key_fp);
return 0;
case 0: /* child */
for (i = 0; i NSIG; i++)
@@ -602,7 +611,8 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key)
}
execl(options.authorized_keys_command,
- options.authorized_keys_command, user_pw-pw_name, NULL);
+ options.authorized_keys_command, user_pw-pw_name,
+ key_type_name, key_fp, NULL);
error(AuthorizedKeysCommand %s exec failed: %s,
options.authorized_keys_command, strerror(errno));
@@ -614,6 +624,7 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key)
temporarily_use_uid(pw);
close(p[1]);
+ free(key_fp);
if ((f = fdopen(p[0], r)) == NULL) {
error(%s: fdopen: %s, __func__, strerror(errno));
close(p[0]);
diff --git a/sshd_config.0 b/sshd_config.0
index 5962b02..a7b9d3b 100644
--- a/sshd_config.0
+++ b/sshd_config.0
@@ -107,14 +107,22 @@ DESCRIPTION
AuthorizedKeysCommand
Specifies a program to be used to look up the user's public keys.
The program must be owned by root and not writable by group or
- others. It will be invoked with a single argument of the
- username being authenticated, and should produce on standard
- output zero or more lines of authorized_keys output (see
-
Bug#738137: libpwiz: FTBFS on mips*: virtual memory exhausted
Greetings, Fellow Developers, On Fri, Feb 28, 2014 at 01:23:16PM +, Dejan Latinovic wrote: Hello, I have attached a patch that solves this issue for me on mips/mipsel. OK, I'll put that in the git repository today and I'll have an upload pretty soon. Thank you very much for your help. Sincerely, Filippo -- Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu Researcher at CNRS and Debian Developer lopi...@debian.org Author of ``massXpert'' at http://www.massxpert.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740495: rti[release.debian.org] transition: imagemagick
Package: release.debian.org Severity: normal I am going to finalize new version of imagemagick that need library transition. I will send more detail soon, here (I am finallizing symbols file and fixing security bug). Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740496: Please change build dependency from slv2-dev to lv2-dev + lv2core
Package: traverso Version: 0.49.2 Hello, Please change build dependency from slv2-dev to lv2-dev + lv2core. slv2-dev is deprecated and is be replaced by lv2-dev. slv2 will be removed from archive in future. best regards mira
Bug#740476: file: 5.17 causes chromium ftbfs
reassign 740476 chromium-browser retitle 740476 chromium-browser: FTBFS since file fixed a bug in file = 5.04, file 5.17 tags 740476 patch thanks Michael Gilbert wrote... The latest update to file leads to a chromium build failure: https://buildd.debian.org/status/fetch.php?pkg=chromium-browserarch=i386ver=32.0.1700.123-2stamp=1392729354 Downgrading to 5.14 solves the problem. That took a while, mostly downloading and unpacking the huge chromium sources. What actually went wrong: The build system calls ../build/linux/python_arch.sh /usr/lib/libpython2.6.so.1.0 and that one calls file(1) which fails (and did so before) for ENOFILE: + file --dereference /usr/lib/libpython2.6.so.1.0 + file_out=/usr/lib/libpython2.6.so.1.0: ERROR: cannot open `/usr/lib/libpython2.6.so.1.0' (No such file or directory) The odd part is this file does not exist in the file system anyhow, since * Debian unstable moved to 2.7 (2.6 is hard coded in src/build/common.gypi), and * additionally libpython2.7.so.1.0 has been moved to /usr/lib/triple/. So this check doesn't make sense, figuring out why it's done at all and whether it should be adjusted to the current file system layout is left as exercise to the reader. *However* python_arch.sh assumes file(1) exits non-zero upon ENOFILE. This was true for file from 5.04 on and before 5.17, but was a bug since it was in violation of | If the file named by the file operand does not exist, cannot be | read, or the type of the file named by the file operand cannot be | determined, this shall not be considered an error that affects the | exit status. [ http://pubs.opengroup.org/onlinepubs/007904975/utilities/file.html ] See the file(1) ticket at http://bugs.gw.com/view.php?id=316 for a longer discussion. How to fix: Upstream added a new option that restores the non-zero exit behaviour of file(1), the patch below applies this to python_arch.sh. I didn't do a complete build for full verification, but can confirm the build got beyond that critical point now. This patch however might be a work-around. In your (chromium-browser maintainer) position I'd do a check whether build/gyp_chromium should rather provide the right libpython2.X.* path. Christoph commit d4926c4f9e8171b4edd931033759d57a7ded5116 Author: Christoph Biedl debian.a...@manchmal.in-ulm.de Date: Sun Mar 2 12:19:36 2014 +0100 Fix FTBFS with file = 5.17. Closes: #740476 diff --git a/debian/control b/debian/control index 285b01e..f9bb162 100644 --- a/debian/control +++ b/debian/control @@ -80,6 +80,7 @@ Build-Depends: libjs-excanvas, libjs-jquery-tablesorter, libjs-jquery-flot | libjs-flot, + file (= 1:5.17), Built-Using: libjs-jquery, libjs-excanvas, diff --git a/debian/patches/exit-nonzero-on-file-error.patch b/debian/patches/exit-nonzero-on-file-error.patch new file mode 100644 index 000..0275e5c --- /dev/null +++ b/debian/patches/exit-nonzero-on-file-error.patch @@ -0,0 +1,11 @@ +--- a/src/build/linux/python_arch.sh b/src/build/linux/python_arch.sh +@@ -10,7 +10,7 @@ + # python_arch.sh /path/to/sysroot/usr/lib/libpython2.4.so.1.0 + # + +-file_out=$(file --dereference $1) ++file_out=$(file -E --dereference $1) + if [ $? -ne 0 ]; then + echo unknown + exit 0 diff --git a/debian/patches/series b/debian/patches/series index 6162e40..bd0d921 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -20,3 +20,4 @@ ps-print.patch window-placement.patch no-promo.patch chromedriver-revision.patch +exit-nonzero-on-file-error.patch signature.asc Description: Digital signature
Bug#740497: Please change build dependency from slv2-dev to lv2-dev + lv2core
Package: gstreamer0.10-plugins-bad Version: 0.10.23 Hello maintainer, Please change build dependency from slv2-dev to lv2-dev + lv2core. slv2-dev is deprecated and is be replaced by lv2-dev. slv2 will be removed from archive in future. best regards mira
Bug#740498: ulatencyd: Ulatencyd have start configuration on two places
Package: ulatencyd Version: 0.5.0-8 Severity: normal Hi One configuration is on /etc/init.d/ulatencyd and second is on /lib/systemd/system/ulatencyd.service Personal prefer to delete old stile init because not know how to start after dbus initialization -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ulatencyd depends on: ii dbus 1.8.0-1 ii dpkg 1.17.6 ii libc6 2.17-97 ii libdbus-1-31.8.0-1 ii libdbus-glib-1-2 0.102-1 ii libglib2.0-0 2.38.2-5 ii liblua5.1-05.1.5-5 ii libpolkit-gobject-1-0 0.105-4 ii libxau61:1.0.8-1 ii libxcb11.10-2 ii lua-posix 29-7 ii lua5.1 [lua] 5.1.5-5 Versions of packages ulatencyd recommends: ii consolekit 0.4.6-3+b1 ulatencyd suggests no packages. -- Configuration Files: /etc/ulatencyd/simple.d/video.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#740340: Forwarded upstream
forwarded 740340 https://bugs.launchpad.net/widelands/+bug/1286576 thanks Thanks for reporting this issue. I've forwarded it to the upstream bugtracker. -- mvh / best regards Hans Joachim http://desserud.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On Mar 2, 2014, at 12:05 PM, Robert Millan wrote: There's a reason we add a freebsd- prefix to functionally equivalent packages like: freebsd-smbfs - mount command for the SMB/CIFS filesystem freebsd-net-tools - FreeBSD networking tools freebsd-nfs-common - NFS support files common to client and server freebsd-nfs-server - FreeBSD server utilities needed for NFS on GNU/kFreeBSD freebsd-ppp - FreeBSD Point-to-Point Protocol (PPP) userland daemon Might I suggest that the reason is that these is _completely_ different implementation, with absolutly no common code? Your repeated insistence on occupying the zfsutils namespace makes me think you have a self-serving reason for this. Of course I have - I have never denied this. But the same can be said for you - you have shown an extreme ill will against us using that name. One could only guess why... My/our reasoning is that it is based on the same code (even if not the same source package - yet), gives the same functionality, with the same... etc, etc. I've said that a few times by now, if you don't want to understand that part, let's wait for the FTP maintainers ruling. How do you plan to react when actual breakage happens? Rename it. It's just that easy. IF someone can actually show me that this is actually illegal and can point me to a policy AND/OR if the FTP maintainers (which have the final say in this - not you, not me, not any one else!) say that this is not acceptable, then we'll rename it, without any bitching or whining or expressing opinions that we can't backup with facts. For now, I have not heard one word about this from them. The only thing I've heard is that there might be a problem with the licensing and that they want to investigate this properly and be absolutly sure - it is their job, the one they where elected and trusted to do. Basically, their ruling is law. Your opinion is just that - your opinion and bear no weight at this moment. Dimitri is the only one that have given something that is slightly more than just a personal opinion: On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote: Hostile binary takeover is not allowed - that is two separate source packages should not build the same binary package names, even if on different architectures. This at least SOUNDS like something that could be a policy. You have not provided ANYTHING that can be considered anything else than a personal opinion and dislike/disdain of the name. I still want/need something that actually IS a policy. Until then, may I suggest we both table further discussion about renaming the package until we get the FTP maintainers ruling on the package. They have been Cc'd on this thread, so they will know that there might be a controversy in the naming. If they rule the license ok but the name wrong, they won't allow it into the archive as-is anyway, so there is no danger in waiting and letting them do their job. Unless I missed something, ZoL is not OpenZFS. No ? Where did you get/draw that conclusion from? And neither ZoL nor OpenZFS support the kernel of FreeBSD at the time of writing. I can't say yes or no on that, I just don't know. I'm involved in ZoL, not OpenZFS. But it would actually surprise me somewhat if it didn't. This because they, from what I understand (which might be wrong) used the Illumos code as starting point. And, again from what I understand, is the code *BSD is using. But talking about what OpenZFS _IS_ and what it's _INTENDED_ to be is irrelevant at the moment. My point have been that _eventually_, there won't BE a FreeBSD/ZFS' or a Linux/ZFS version. There will ONLY be OpenZFS! And that is only partly irrelevant. In the sense that the current FreeBSD 'zfsutils' and the Linux 'zfsutils' is _basically_ the same, but still not _exactly_ the same You make it look like you're adding a portable package No I don't. I haven't even hinted to it.. when in fact it is a Linux-specific package. Yes. Have someone made you believe it to be something else? I think it would serve that agenda to imply that ZoL is OpenZFS and the source you're adding is portable, but I don't think you even believe what you're implying. This is completely your complete misunderstanding and inability to read and understand what's been said. You need to go back and read it again. If you truly believe in the unification path I do. Whole heartedly - it's the only way forward into the future! Keeping X number of implementations, sharing a huge part of the exact same code won't be sustainable in the long run (it have already proved somewhat of a problem - both in ZoL and in Illumos). I notice that you ignored it on your reply to him: On 02/03/2014 03:52, Dimitri John Ledkov wrote: Also, if there is zfs-dkms module available, why existing zfsutils packages just can't enable compilation on linux-any?! Which should also reduce the scope of linux specific packages down to
Bug#740500: debian-installer: amd64 documentation is incorrect/incomplete (isohybrid issues)
Package: debian-installer Version: stable Severity: normal Dear Maintainer, https://www.debian.org/releases/stable/amd64/ch04s03.html.en Documentation is out of date - does not mention that this the amd64 images are isohybrid BIOS/EFI boot format, with both a MBR/GPT partition scheme. Documentation implies there is only one partition but there are now two (EFI system partition and ISO9660 partition). The section on adding an extra partition will likely not be followable due to being incorrect/incomplete - it does not mention what tools to use - *fdisk and gdisk do not work* and it is not clear whether either of them could correctly modify the hybrid MBR/GPT scheme used in the image whilst preserving its bootability on both BIOS and EFI (?) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740499: debian-installer: firmware-7.4.0-amd64-netinst.iso missing broadcom firmware
Package: debian-installer Version: firmware-7.4.0-amd64-netinst.iso Severity: normal Dear Maintainer, https://www.debian.org/releases/stable/amd64/ch06s04.html.en says Alternatively, unofficial CD builds containing non-free firmware can be found at http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/.; And https://wiki.debian.org/Firmware says Alternatively, there are now versions of the netinst CD images that also include all the non-free firmware packages directly Both these extracts infer that all the non-free firmware is in the firmware image, but firmware-7.4.0-amd64-netinst.iso does not contain Broadcom firmware (at least not b43). This firmware should be added to the CD, or the documentation should mention that unofficial builds don't contain *all* firmware. It's a waste of the user's time to download an installer that claims to have non-free firmware and then find the non-free firmware they need is missing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740501: debian-installer: check-missing-firmware mounts FAT partitions case-sensitive
Package: debian-installer Version: 7.0.4 wheezy release Severity: normal Dear Maintainer, Installing from debian-7.4.0-amd64-netinst.iso FAT-fs (sdc): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! check-missing-firmware mounts partitions in a case-sensitive way - this may cause problems for some users and seems unncessary. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
Package: cdimage.debian.org Severity: important Dear Maintainer, The GPT checksum of debian-7.4.0-amd64-netinst.iso (and other wheezy and testing images) is incorrect due to a bug in the Xorriso build tool used on the build system (confirmed by author of build tool). Reported on mailing list but no response received: https://www.mail-archive.com/debian-cd@lists.debian.org/msg21403.html I am not sure what the impact of this is (hypothetically, some EFI systems could refuse to boot the ISO). It does mean that it is not possible to add extra partitions to the image (which the documentation states can be done for firmware files). Thomas Schmitt (author of xorriso) confirmed that: The problem described there affects versions 1.2.6 and 1.2.8. debian-7.3.0-amd64-netinst.iso indeed bears as preparer id XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, LIBISOFS-1.2.6, LIBBURN-1.2.6 It _should_ be fixed in xorriso-1.3.2 as in Debian testing and in the current upstream release 1.3.4. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740502: debian-installer: check-missing-firmware shows incorrect missing list and only copies one firmware file at a time
Package: debian-installer Version: 7.0.4 wheezy release Severity: normal Dear Maintainer, Installing from debian-7.4.0-amd64-netinst.iso 1 check-missing-firmware missing files list is incorrect. Installer detects that wifi needs Broadcom firmware and says The missing firmware files are: b43/ucode29_mimo.fw b43-open/ucode29_mimo.fw. The list is incorrect and incomplete. The list contains only two files - there are more that are required. The list contains two files, suggesting that both are needed - in fact only one copy of the file is needed (the loader looks in two directories). - This bug seems to be caused by the installer interpreting the kernel firmware loading in an overly simple way. The firmware loader attempts to load files sequentially, and looks for them in two places. If it does not find a file, it will immediately quit and print the two locations that it looked for the file. The Debian installer interprets and reports this pair of locations as an absolute list of missing files. It is not an absolute list, it is a duplicate pair for a single missing file. - Even if the file is present (eg. b43/ucode29_mimo.fw exists), this function still reports b43-open/ucode29_mimo.fw as missing! It's not missing, it's just an alternative location for the same file. 2. The installer should copy any firmware files on the USB drive in one go. Because of the way the installer copies and loads one file at a time, even if the user has done everything perfectly (all required firmwares ready on a USB drive) the check missing files prompt will pop up several times (3 in my case) and the user just has to keep clicking yes. Any normal user is going to think that this is broken, only users who are really paying attention and watching the logs will notice that it is only loading one file every time they click Continue. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740503: debian-installer: check-missing-firmware does not work with a USB drive that contains a partition table
Package: debian-installer
Version: 7.0.4 wheezy iso
Severity: important
Dear Maintainer,
Installing from debian-7.4.0-amd64-netinst.iso
check-missing-firmware does not work with a USB drive that
contains a partition table. When a USB drive with a single partition
containing the firmware is inserted, it reports that the firmware was
not found. The firmware is on partition /dev/sdc1. From the log I can
see that the function is attempting to scan drives and partitions
detected on the system, and mount them as FAT file systems. The
problem is that it does not try the USB drive partition 1 at
/dev/sdc1. It does try /dev/{sda sda sdc sdc sda1 sda1 sda sda sdc sdc
sda1 sda1 sda2 sda2 sda3 sda3} in that order. So it is trying to mount
/dev/sdc (the USB drive) but not /dev/sdc1 (the actual partition).
- Workaround is to format the USB drive without a partition table,
e.g. mkfs.vfat -I /dev/sdc (mkfs.vfat actually expects a
partition table, -I override forces it to use the entire device)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739300: dh_sphinxdoc: Please replace MathJax.js with links to the packaged libjs-mathjax
Hi Sebastian, I have performed some queries on codesearch.debian.net and it seems that currently only two packages ship embedded copy of MathJax (mcrl2 and yelp): Your package breathe in NEW seems to be another one, and the only one using Sphinx. Given that you already fixes breathe, I think the impact of this bug is zero. Also, the source of MathJax is quite large (especially if you ship PNG files), so I would usually recommend people to remove that embedded copy from the source tarball. Anyway, I will keep this bug open and accept patches if someone decides to write them. Some packages (i.e. calibre) already do that. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature
Bug#740505: burp: Burp is casting pointer to 64-bit value into a pointer to a 32-bit value
Package: burp Version: 1.3.48-1 Severity: important Dear Maintainer, Burp is casting pointer to 64-bit value into a pointer to a 32-bit value the causing that burp the build of burp is failing on 64-bit big endian platform like s390x see: http://paste.debian.net/84821/ Burp is casting pointer to 64-bit value into a pointer to a 32-bit value For example in in handy.c, line 570 if(!EVP_CipherFinal_ex(enc_ctx, eoutbuf, (int *)eoutlen)) eoutlen is size_t Thanks to Aurelien to help indentify the problem. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages burp depends on: ii libacl1 2.2.52-1 ii libc62.17-97 ii libgcc1 1:4.8.2-14 ii libncurses5 5.9+20140118-1 ii librsync10.9.7-10 ii libssl1.0.0 1.0.1f-1 ii libstdc++6 4.8.2-14 ii libtinfo55.9+20140118-1 ii zlib1g 1:1.2.8.dfsg-1 burp recommends no packages. burp 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#740506: libetpan: needs update for db5.3
Source: libetpan Version: 1.0-5 Severity: serious Control: block 658829 with -1 Hi, db5.1 is being replaced by 5.3, but libetpan doesn't seem to want to build against the latter (configure checks for a list of versions explicitly, not including 5.3, and chooses 5.1 if it finds it before it checks for the unversioned libdb.so). Cheers, Julien signature.asc Description: Digital signature
Bug#606110: installation-report: gtk installer fail to start with PXE boot of Dell Latitude D505
Petter Reinholdtsen p...@hungry.com (2014-03-02): [Cyril Brulebois] If you still have access to this machine, does the wheezy gtk installer start fine? Otherwise, lacking access to such a machine, I'm tempted to close this bug report. I still have access to the machine at work (it is one of my collection of test laptops). I'll retry the wheezy installer, but vaguely remeber the problem exist there too. Anything in particular I should test? Yes, try passing vga=788. Failing that, you're probably going to lack a framebuffer, and X won't be able to start. You would then have a scrolling log on vt1 in which you should be able to see a “(EE) no screens found” line. Mraw, KiBi. signature.asc Description: Digital signature
Bug#740507: TAG: liblog4cxx10 -- A logging library for C++
Package: wnpp Severity: O I have not used, looked at, or even thought about this package in years. There are outstanding bugs and a pending NMU that need to be reviewed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714350: FTBFS when locales-all is installed
reopen 714350 tag 714350 - unreproducible thanks On 03/02/2014 01:47 PM, Cyril Brulebois wrote: You'll have to do better. See attached, successful build log, with: as originally already said, if you install locales-all (which provides locales) instead of locales, localechooser fails to build from source. removing tag and reopening accordingly. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740425: [Pkg-xfce-devel] Bug#740425: libexo-helpers: Please rename epiphany.desktop to epiphany-browser.desktop
On Sun, Mar 02, 2014 at 12:22:54PM +0100, Laurent Bigonville wrote: Le Sat, 1 Mar 2014 16:24:03 +0100, Yves-Alexis Perez cor...@debian.org a écrit : There are some other programs (I have geoclue-2.0 in mind) that use the the desktop-id (the name of the desktop file without the .desktop part) to identify the running programs. So if this desktop file is use to start epiphany, the desktop-id might be wrong. It's only used internally by libexo, afaict. So please check if it *really* breaks geoclue-2.0 or whatever. Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Bug#726490: sponsorship-requests: ethstatus/0.4.4 [ITA]
You wrote: * Upstream is the same as Debian maintainer. Therefore, build a native Debian package IMO, that's a very bad idea. this is a pain for downstream Debian derivative who may want to add specific patches. With a native package, it becomes less convenient to add distro-specific patches. Please don't do this and re-upload a version of your package as non-native. Generally, native packages are very Debian specific, like for example apt, dpkg, etc. Unless you develop this kind of tool, IMO, don't use a native package. Thomas Goirand (zigo) P.S: Some other DD may have a different opinion, like for example I know Joey Hess finds it ok and even wrote about it, but I believe a majority of DD will agree with me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740490: [Pkg-lirc-maint] Bug#740490: Change hardware.conf defaults
Hi On Sunday 02 March 2014, Marc MAURICE wrote: [...] I suggest the following patch for hardware.conf: This has already changed significantly in the packaging Vcs, to the extent that the next uploaded won't have a hardware.conf (in favour of /etc/default/grub[1], pending automated migration support) anymore. --- /tmp/hardware.conf2014-03-02 10:52:28.229878749 + +++ /etc/lirc/hardware.conf 2014-03-02 10:55:30.005150849 + @@ -12,10 +12,12 @@ #Try to load appropriate kernel modules LOAD_MODULES=true +# You can set a driver here if your device is not supported by the lirc kernel modules # Run lircd --driver=help for a list of supported drivers. -DRIVER=UNCONFIGURED +#DRIVER=UNCONFIGURED + According to the current package in the archive, changing this would introduce a bug, as UNCONFIGURED has a special meaning to the initscript and the maintainer scripts. Even if you would rely on it falling back to the default driver, using #DRIVER=UNCONFIGURED however would document a wrong default. # usually /dev/lirc0 is the correct setting for systems using udev -DEVICE= +DEVICE=/dev/lirc0 MODULES= This can be done (and actually has been rectified in the packaging Vcs already), but it's not necessary as /dev/lirc0 is only one of several possible options - in the light of modern RC_CORE based drivers not even necessarily the most common one. # Default configuration files for your hardware if any This way: * We document the fact that setting the DRIVER is not mandatory. DRIVER is mandatory, there are 'default' == 'devinput' vs. several userspace drivers, falling back to 'default' however does make sense (and is already done in the packaging Vcs). Supported drivers: accent alsa_usb asusdh atilibusb atwf83 audio_alsa awlibusb bte bw6130 commandir creative creative_infracd default devinput dfclibusb dsp dvico ea65 ftdi i2cuser irlink livedrive_midi livedrive_seq logitech macmini mp3anywhere mplay mplay2 mouseremote mouseremote_ps2 null pcmak pinsys pixelview samsung sb0540 silitek srm7500libusb tira tira_raw udp uirt2 uirt2_raw usb_uirt_raw usbx * lircd will work by default for all devices supported by kernel drivers It still needs a valid /etc/lirc/lircd.conf and the dæmon won't start without it being present (falling back to /usr/share/lirc/remotes/devinput/lircd.conf.devinput is not impossible, but might be harder to implement with systemd). * to my knowledge /dev/lirc0 is the right device name used by kernel drivers. Otherwise lircd default /dev/lirc is used. This depends, /dev/lirc0 is only default for the lirc protocol, however not for the various IR protocols (e.g. rc-5, nec, rc-6, etc.) which are the default setting for the various RC_CORE based kernel drivers (the lirc protocol needs to be chosen explicitly). I also filed an lircd issue upstream to ask to change the default /dev/lirc to /dev/lirc0: https://sourceforge.net/apps/mantisbt/lirc/view.php?id=2 [...] This has been changed upstream, unreleased/ after 0.9.0, as well commit d0175df5cd2ac4a261332ea21a67179f2c85072c Author: Jarod Wilson ja...@redhat.com Date: Fri Dec 2 14:10:21 2011 -0500 userspace: use /dev/lirc0 as default device The lirc_dev kernel driver results in a first lirc chardev of /dev/lirc0, not /dev/lirc, so lets default to that now. The old way is from pre-udev days or something, I think... While we're at it, update the adjacent comment about the daemon socket locations to reflect current reality too. Signed-off-by: Jarod Wilson ja...@redhat.com At the moment, I haven't decided yet between leaving this bug open (and closing it with the next package upload) or closing it now, as your (mostly valid) suggestions don't apply (at least not as explained here) to the current package in the archive. Regards Stefan Lippers-Hollmann [1] http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.default?view=markup signature.asc Description: This is a digitally signed message part.
Bug#428554: Can't reproduce this problem
Hello, On Mon, Sep 24, 2007 at 04:35:05PM +1000, Ted Percival wrote: Andrés Roldán wrote: Hi. I am unable to reproduce this problem. I have icedove 2.0.0.4.dfsg1-2 installed and I run prelink daily without problems. Today I took another look and it works fine, although I have upgraded some packages since my first message. These are the packages that have been upgraded since: libatk1.0-0 from 1.18.0-2 to 1.20.0-1 libc6 from 2.6.1-3 to 2.6.1-5 libpango1.0-0 from 1.18.1-1 to 1.18.2-1 I downgraded them to the original versions and ran `prelink --all -mR` but icedove continued to work, so I guess this is now unreproducible for me too. I'll leave the packages at these versions and see if it comes back after I've restarted, but I suspect the old error was really because of a mismatch between some installed library and what was already loaded into memory. what about closing this bug? The reported Icedove version out of the official repos for quite some times and notheing else happen to this report quite over 6 years. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740509: ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address
Package: freebsd-net-tools Version: 9.2+ds1-1+b1 Severity: critical Control: found -1 10.0-3 On this system, ifconfig is unable to bring up network when running on a 10.0 kernel (this happens with 10.0 debian kernels and with kfreebsd-downloader too). The problem appears to be somehow related to ipv6: $ sudo ifconfig -a : flags=8802BROADCAST,SIMPLEX,MULTICAST ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address : flags=0 ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address : flags=0 ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address : flags=8008LOOPBACK,MULTICAST ifconfig: ioctl(SIOCGIFINFO_IN6): No such device or address -- System Information: Debian Release: 7.4 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-i386 (i386) Kernel: kFreeBSD 10.0-1-686 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages freebsd-net-tools depends on: ii libbsd00.6.0-1 ii libc0.12.18-3 ii libexpat1 2.1.0-4 ii libfreebsd-glue-0 0.2.16 ii libipx29.2+ds2-4 ii libjail1 9.2+ds2-4 ii libkvm610.0-4 ii libmemstat39.2+ds2-4 ii libnetgraph4 9.2+ds2-4 ii libsbuf6 9.2+ds2-4 ii libutil-freebsd-9 9.2+ds2-4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714350: FTBFS when locales-all is installed
Control: retitle 714350 FTBFS when locales is not installed Daniel Baumann daniel.baum...@progress-technologies.net (2014-03-02): On 03/02/2014 01:47 PM, Cyril Brulebois wrote: You'll have to do better. See attached, successful build log, with: as originally already said, if you install locales-all (which provides locales) instead of locales, localechooser fails to build from source. What you originally said, and what you're stubbornly repeating without any care for what was replied, is missing the point; this isn't due to locales-all's being installed, but due to locales's not being installed, which is a very different thing. KiBi. signature.asc Description: Digital signature
Bug#673644: Message at end of successful install talks about floppies (should be updated)
Christian PERRIER bubu...@debian.org (2014-03-02): Quoting Cyril Brulebois (k...@debian.org): _Description: Installation complete Installation is complete, so it is time to boot into your new system. - Make sure to remove the installation media (CD-ROM, floppies), so that - you boot into the new system rather than restarting the installation. + Make sure to remove the installation media (CD-ROM, DVD-ROM, USB flash + disk), so that you boot into the new system rather than restarting the + installation. Maybe try to be more generic so that we don't have to change this when CD-ROM, DVD or USB flash disk are considered obsolete as well? Something like Make to to remove the installation media so that I kinda liked the parenthesis since people might not be exactly sure what we're talking about. debian-cd@/Steve, any opinion on this? I don't think we're going to drop support for CD, DVD, or USB flash disk any time soon. Not spending our time trying to make stuff fit on CD#1 is OK, but there's still some real needs for CD images last I heard… Mraw, KiBi. signature.asc Description: Digital signature
Bug#740309: [Debichem-devel] Bug#740309: libpwiz FTBFS: configure: error: cannot compile a test that uses Boost thread
Greetings, Aníbal, On Fri, Feb 28, 2014 at 06:01:53AM +, Aníbal Monsalve Salazar wrote: Package: libpwiz Version: 3.0.4624-8 Severity: serious libpwiz 3.0.4624-8 FTBFS on amd64 within a clean and updated sid pbuilder chroot. The complete pbuilder log is at: http://people.debian.org/~anibal/libpwiz/libpwiz_3.0.4624-8_amd64.log.bz2 Log extract is below. checking for boost/thread.hpp... yes checking for the Boost thread library... configure: error: cannot compile a test that uses Boost thread make: *** [build-arch-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 E: Failed autobuilding of package Thanks for the report. Same problem here, I'm investigating this one. Cheers, Filippo -- Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu Researcher at CNRS and Debian Developer lopi...@debian.org Author of ``massXpert'' at http://www.massxpert.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724874: [PKG-IRC-Maintainers] Bug#724874: Bug#724874: inspircd: 2.0.15 now available
Hi all,
Le samedi 01 mars 2014 à 15:14 +0100, Christoph Biedl a écrit :
Christoph Biedl wrote...
Now I'd like to suggest the following procedure: Unless nobody objects
by Thu March 6th, feel free to upload your inspircd packaging.
I've prepared a package a few days ago by didn't finish it, there is the
changelog:
* New upstream release (Closes: #724874), enable m_regex_stdlib new
module
* Drop patches accepted upstream:
+ debian/patches/01_spelling_error.diff
+ debian/patches/03_CVE-2012-1836.diff (cherry-picked)
+ debian/patches/04_FTBFS_kfreebsd.diff
+ debian/patches/05_FTBFS_gcc-4.7.diff
* debian/docs: docs/README has moved to README.md
* debian/examples: examples are now in docs/conf
* Bump debhelper compat to 9
* Remove Bradley Smith as uploaders (Closes: #674890)
* debian/watch: update based on sepwatch
* Add systemd support:
+ Build-Depends on dh-systemd (= 1.5)
+ Add debian/inspircd.service,
debian/inspircd.tmpfiles.d.conf
+ debian/rules: call generic dh with --with systemd
* debian/control: Change Vcs-{Svn,Browser}, point to
anonscm.debian.org and
bump to Standards-Version 3.9.5 (no changes needed)
* debian/patches/02_disable_rpath_for_extra_modules.diff: Refresh
according
upstream modules changes
-- Guillaume Delacour g...@iroqwa.org Sat, 01 Feb 2014 15:36:52 +0100
I've started to rewrite debian/copyright too, i can just finish it.
I propose to integrate David's diff to my version and add it to
uploaders today or within the next week.
___
Pkg-irc-maintainers mailing list
pkg-irc-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-irc-maintainers
--
Guillaume Delacour g...@iroqwa.org
signature.asc
Description: This is a digitally signed message part
Bug#696113: libmagic-dev: No man page for magic_errno
forwarded 696113 http://mx.gw.com/pipermail/file/2014/001387.html tags 696113 confirmed upstream thanks Olly Betts wrote... Oops, attached. + .Nm magic_error , ++.Nm magic_errno , + .Nm magic_descriptor , Oy, that simple. Forwarded to upstream. Christoph signature.asc Description: Digital signature
Bug#740511: libqt5core5a: Some (foreign) packages, that depend on libqt5core5 won't install with libqt5core5a
Package: libqt5core5a Version: 5.2.0+dfsg-7 Severity: normal Dear Maintainer, with the upgrade to libqt5core5a some foreign packages were forced to uninstall because they depend on libqt5core5. As far as I understand libqt5core5a ist backward compatible with libqt5core5, so shoulden't libqt5core5a have a Provides tag stating the backwart compatibility? -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (1001, 'unstable'), (501, 'experimental'), (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libqt5core5a depends on: ii libc6 2.18-3 ii libgcc11:4.8.2-16 ii libglib2.0-0 2.38.2-5 ii libicu52 52.1-3 ii libstdc++6 4.8.2-16 ii multiarch-support 2.18-3 ii zlib1g 1:1.2.8.dfsg-1 libqt5core5a recommends no packages. Versions of packages libqt5core5a suggests: ii libthai0 0.1.20-3 -- 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#740441: suggest jmxetric, provide convenient way to enable it
jmxetric looks interesting but I don't think tomcat7 should suggest a monitoring tool, apache2 doesn't suggest nagios3 for example. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734699: RM: linux-ntfs -- ROM; abandoned upstream, merged with ntfs-3g.
tags 734699 + moreinfo thanks Not ready yet: # Broken Depends: partclone: partclone [amd64 armel armhf i386 mips mipsel powerpc s390x sparc] partman-partitioning: partman-partitioning [amd64 i386 kfreebsd-amd64 kfreebsd-i386] # Broken Build-Depends: partclone: libntfs-dev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709558: Bug#720655: file: stage build support
reassign 709558 src:file severity 720655 wishlist merge 709558 720655 tags 709558 help thanks Eleanor Chen wrote... Attached patch adds stage build support for file, so that python can be disabled when bootstraping. Then the package can be built with something like: Hi, there are two tickets for obviously the same goal, merging. However, the patches are somewhat different. Can you two please check both (#709558, #720655), and give me an idea which is better, and why? Christoph signature.asc Description: Digital signature
Bug#740512: please remove python-elixir and python-sqlalchemy from Depends
Package: dicompyler Version: 0.4.1-1 Severity: normal Hi, I plan to remove python-elixir from Debian (if not in Jessie then in Jessie+1) so I checked reverse dependencies and it looks like dicompyler doesn't use it. It doesn't use python-sqlalchemy as well, so please remove both from Depends. TIA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740513: evince: Keeps connection in CLOSE_WAIT
Package: evince Version: 3.10.0-2 Hi, I currently see those 2 connections: tcp1 0 10.0.200.1:5055910.0.200.1:631 CLOSE_WAIT 4144/evince tcp1 0 10.0.200.1:5061810.0.200.1:631 CLOSE_WAIT 4144/evince That is a connection from evince to cups. The last time I printed was probably weeks ago, but evince is still running. The cups side has long since closed the connection, it's the evince side that keeps the connection open with 1 byte left in the receive queue. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613652: Media device player error displayed
Hey, Could you please still reproduce this issue with newer rhythmbox version like 2.97-2.1 or 3.0.1-1+b1 ? thanks regards althaser
Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM
On Sun, Mar 2, 2014 at 6:02 AM, Thomas Orgis thomas-fo...@orgis.org wrote: Am Sat, 01 Mar 2014 01:00:02 +0900 schrieb Taihei Momma t...@mac.com: OK, after some investigation with armhf cross environment and qemu, finally the current mpg123 svn (r3517) should work After Tahei didn't stop at this (big thanks from here!), we got a new snapshot, http://mpg123.org/snapshot/mpg123-20140302115523.tar.bz2 , that will hopefully become mpg123 1.19.0 soon (not 1.18.x because of feature additions regarding this very debian issue). The main points: - float output with all decoders (also arm_nofpu) - ARM decoders (esp. NEON) working with debian toolchain - new --with-cpu=arm_fpu choice with runtime detection to switch between NEON or normal FPU So, the number of builds for optimal treatment of differing platforms reduces to two: 1. --with-cpu=arm_nofpu 2. --with-cpu=arm_fpu I hope we can all be happy about that. I'd also be glad to get some confirmation from debian that it really works now. Release will be imminent, then. That sounds like if the mpg123 package should use: on armel: --with-cpu=arm_nofpu on armhf: --with-cpu=arm_fpu Does this make sense to everybody? Thanks for staying with us with all the chattering about this ... Thank you for handling this issue (and basically every issue other that popped out in Debian for mpg123) so quickly! -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613652: Media device player error displayed
On 02-03-14 15:07, althaser wrote: Hey, Could you please still reproduce this issue with newer rhythmbox version like 2.97-2.1 or 3.0.1-1+b1 ? I haven't seen it for a long time anymore and I have an up-to-date testing distro. To be honest, I had completely forgotten about this issue. -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740441: suggest jmxetric, provide convenient way to enable it
Emmanuel Bourg ebo...@apache.org wrote: jmxetric looks interesting but I don't think tomcat7 should suggest a monitoring tool, apache2 doesn't suggest nagios3 for example. The difference is that jmxetric does JMX, so it is specific to Java app servers, of which tomcat is obviously the most well known It also suggests that Debian has tested the things together, which reassures users that it will just work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618414: rhythmbox: Rhythmbox won't pause some songs with use backend for crossfading enabled
Hey Marcus, Could you please still reproduce this issue with newer rhythmbox version like 2.97-2.1 or 3.0.1-1+b1 ? thanks regards althaser
Bug#619169: rhythmbox segfaults when selecting multiple podcast feeds
Hey Rares, Could you please still reproduce this issue with newer rhythmbox version like 2.97-2.1 or 3.0.1-1+b1 ? thanks regards althaser
Bug#620461: ipod shows no songs, properties crashes rhythmbox
Hey Craig, Could you please still reproduce this issue with newer rhythmbox version like 2.97-2.1 or 3.0.1-1+b1 ? thanks regards althaser
Bug#740455: [Pkg-xfce-devel] Bug#740455: xfce4-terminal: crash when detaching multiple tabs
Control: tag -1 confirmed On Sat, Mar 01, 2014 at 11:27:01AM -0800, Mike Kupfer wrote: Package: xfce4-terminal Version: 0.6.3-1 Severity: normal Dear Maintainer, I can reliably make xfce4-terminal crash by doing the following: 1. start xfce4-terminal 2. create 3 additional tabs from the menubar (FileOpen Tab) 3. right-clickDetach Tab on the 2nd-from-the-left tab 4. right-clickDetach Tab on the (now) middle tab 5. right-clickDetach on the (now) right-hand tab Indeed, I can reproduce. Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Bug#740250: imagemagick: CVE-2014-1947 CVE-2014-1958 CVE-2014-2030
Corrected waiting a mentors On Sun, Mar 2, 2014 at 8:57 AM, Bastien ROUCARIES roucaries.bastien+imagemag...@gmail.com wrote: Sorry to all we are affected by 1947, commit 43a7754127073ebf0dce2b59cb370c27ae5fbd58 Author: cristy cristy@aa41f4f7-0bf4-0310-aa73-e5a19afd5a74 Date: Sun Feb 16 21:48:05 2014 + Link are incomplete. Will fix asap On Fri, Feb 28, 2014 at 11:20 AM, Bastien ROUCARIES roucaries.bastien+imagemag...@gmail.com wrote: We are not affected by CVE-2014-1947: but by CVE-2014-2030 On Thu, Feb 27, 2014 at 2:45 PM, Moritz Muehlenhoff j...@inutil.org wrote: Package: imagemagick Severity: grave Tags: security Justification: user security hole The CVE assignments are a bit tricky, please see http://www.openwall.com/lists/oss-security/2014/02/12/2 for the thread on oss-security. CVE-2014-1958 http://trac.imagemagick.org/changeset/14801 CVE-2014-1947: http://trac.imagemagick.org/changeset/13736 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#597899: yii-framework in Debian?
Hi Laszlo, Oliver, I wondered what the status of yii-framework in Debian is, as I am (as Julian) interested in having limesurvey in Debian, which uses yii. Regards Evgeni -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739859: ulatencyd: Ulatencyd don't do anithing
This bug is because linux-kernel not have full support for cgroup. On linux debian package missing support also for CONFIG_CFS_BANDWIDTH, CONFIG_RT_GROUP_SCHED please send this bug on linux maintainers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622615: rhythmbox: Doesn't go back to beginning of track selection
Hey Roland, That's the normal behaviour since the last song keeps selected. regards althaser
Bug#740356: Pokerth cannot connect to internet servers
On 03/02/2014 04:44 PM, Evgeni Golov wrote: I've verified to ensure that the DNS is working. There's also a possibility that it is a (temporary) problem with the pokerth servers. But wanted to check here first. While I must admit that I do not play online very often, checking online game functionality is one of the things I do before the upload ;) It worked back then, and so it does now, so there has to be some other problem in your setup. Can you check if it works if you move away your ~/.pokerth? If it does: can you verify you have pokerth.net/serverlist.xml.z as the Automatic Server Configuration URL set in the settings? Does PokerTH tell you something on stderr/out if you start it from a console? Are you using IPv6 (have v6 connectivity *and* have it enabled in the settings)? Moving away the ~/.pokerth folder solved the problem. The culprit was the IPv6 option. Even on the old settings folder, once I reverted the IPv6 settings, things worked back perfect. THank you for your help. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#604081: root password mismatch
Control: found -1 1.48 Control: found -1 1.55 Control: tag -1 confirmed Christian PERRIER bubu...@debian.org (2010-11-20): reassign 604081 user-setup retitle 604081 Does not show password mismatch when first entered root password is empty thanks Quoting Daniel Pocock (dan...@pocock.com.au): Package: installation-reports Installing amd64 as a domU in xen At the first prompt for root password, just hit enter At the second prompt, type a password No password-mismatch error is displayed, installer proceeds to setting up a user account Once rebooted, root login impossible using blank password or the `repeat' password Mount the root fs (e.g. from dom0 or another OS), inspect /etc/shadow: root:!:14932:0:9:7::: When the root password is empty, root account is disabled. This is what the first template says. Still, one can understand that entering the pwd empty, then setting something in the confirmation is user error and the user should have a chance to correct it. And we should anyway to give the false impression that a root password will be set. Reassigning to user-setup as this bug belongs to that package. Still the case in wheezy and above, so recording the versions accordingly. Mraw, KiBi. signature.asc Description: Digital signature
Bug#622615: rhythmbox: Doesn't go back to beginning of track selection
It will play again from the beginning if you double click on the artist or album, at least with 3.0.1-1+b2. when you simple click on play again with a selected song it plays the one selected. perhaps rhythmbox should unselect songs after finished albums, queues or lists. regards althaser
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/03/2014 12:19, Turbo Fredriksson wrote: Basically, their ruling is law. Your opinion is just that - your opinion and bear no weight at this moment. Ah, good. Finally you openly admit that you're requesting ftp-master support for your hostile takeover instead of trying to coordinate with existing maintainers. I won't waste one more minute of my time trying to talk sense into you. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711093: cdrom: Default user is not added to group sudo
Hi, Steve McIntyre st...@einval.com (2013-06-11): Control: reassign -1 user-setup On Tue, Jun 04, 2013 at 06:06:24PM +0200, ashka wrote: Although sudo is installed, the main/default user is not added to the sudo group after install, which leads to errors when trying to run a sudo command. The user has to use su to get root access, which is unexpected since sudo is installed. I'm reassigning to the user-setup package; that's where this happens in the installer. well, the root password prompt contains: | The root user should not have an empty password. If you leave this | empty, the root account will be disabled and the system's initial user | account will be given the power to become root using the sudo | command. I don't think it was intended to give sudo access to the first user if a root password has been specified. Should we reconsider the current behaviour? Mraw, KiBi. signature.asc Description: Digital signature
Bug#740494: openssh-server: Additional arguments for AuthorizedKeysCommand
On Sun, Mar 02, 2014 at 12:38:18PM +0100, Florian Zimmermann wrote: I would like sshd to pass some more arguments to the AuthorizedKeysCommand in order to print the authorized keys in a more intelligent manner. I was thinking of the Github case, i.e. lots of real users want to authenticate as the git user, which is currently not feasable because the only argument to the AuthorizedKeysCommand is the username being authenticated, which is git for everybody. To allow everyone to authenticate as the git user, the AuthorizedKeysCommand has to print all the public keys of all the real users to standard output and sshd in turn has to parse all those keys and match them against the key that is used for authentication. This patch passes two additional arguments to the AuthorizedKeysCommand: - the type of the key used for authentication, e.g. ssh-rsa, - the MD5 fingerprint of the key used for authentication This allows the AuthorizedKeysCommand to print only a small subset of the public keys. I also submitted this patch to upstream: https://bugzilla.mindrot.org/show_bug.cgi?id=2081 Thanks for the patch. Just by way of setting expectations, I wouldn't take this kind of interface change as a Debian patch because there's too much risk that upstream would later introduce it in a slightly different form and then I'd be stuck with a compatibility problem. I'd prefer to wait for upstream. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#450954: Username 'admin' is reserved
Josh Kelley josh...@gmail.com (2014-02-11): Ubuntu no longer uses the admin group (and, as far as I can tell, never used the admin username). http://askubuntu.com/a/122500/5682 https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/893842 (The latter contradicts what you put in parentheses.) Based on this, I suggest removing admin from the list of reserved names. Thanks, but I'll leave that up to Colin. Mraw, KiBi. signature.asc Description: Digital signature
Bug#544971: Assumes HOME is /home/$USER.
Control: tag -1 wontfix Trent W. Buck trentb...@gmail.com (2009-09-04): Package: user-setup Version: 1.28 Severity: minor user-setup-apply is used by live-initramfs to create a guest account at boot time. I needed the account to have HOME outside of /home, because /home is an NFS mount used by non-guest accounts. Since user-setup-apply seems to end up just calling adduser, this is no big deal -- I can change DHOME to /tmp in adduser.conf. But while RTFSing, I noticed that HOME_EXISTED= if [ -d $ROOT/home/$USER ]; then HOME_EXISTED=1 fi Assumes that the new user's home directory will be /home/$USER. To fix this, you'd need to parse and understand adduser.conf, so it may be reasonable to simply WONTFIX this issue. Given the current logic (HOME_EXISTED etc.), I'm not very keen on changing things there, so I'll go with wontfix for now. If nobody pops up yelling and posting patches, it can be closed in a while. Mraw, KiBi. signature.asc Description: Digital signature
Bug#332911: tagging 332911
Christian Perrier bubu...@debian.org (2005-10-28): # Automatically generated email from bts, devscripts version 2.9.8 tags 332911 wontfix Hello, what should we do about this bug report? Mraw, KiBi. signature.asc Description: Digital signature
Bug#725508: hppa patches for eglibc
On 24-Feb-14, at 12:49 PM, John David Anglin wrote: Here is an updated hppa patch set for 2.18. Attached is an updated patch set for 2.18-3. All patches apply cleanly. I've also attached a replacement for the testsuite expected results for hppa. With this, I had a fully successful build even though results from build to build are somewhat variable. Dave -- John David Anglin dave.ang...@bell.net 0) hppa/local-longjmp-chk.diff -- delete 1) hppa/local-elf-make-cflags.diff 2) hppa/local-setjmp-namespace.diff 3) hppa/local-fanotify_mark-5i.diff 4) hppa/local-fcntl-osync.diff 5) hppa/local-atomic.diff local-elf-make-cflags.diff Description: Binary data local-setjmp-namespace.diff Description: Binary data local-fanotify_mark-5i.diff Description: Binary data local-fcntl-osync.diff Description: Binary data local-atomic.diff Description: Binary data expected-results-hppa-linux-gnu-libc Description: Binary data
Bug#740529: RFA: paste -- tools for using a Web Server Gateway Interface stack
Package: wnpp Severity: normal I request an adopter for the paste package. The package description is: Python Paste brings consistency to Python web development and web application installation, providing tools for both developers and system administrators. . Paste for Administrators: * Easily install, run, and configure multiple Paste-enabled web applications at once, and integrate them into your website how you want (SCGI, FCGI, AJP, WSGI) * Manage and install web applications system-wide for easy maintenance . Paste for Web Developers: * Increase your web application's audience * Provide starter templates and custom commands for using your web framework * Keep your development and deployment straightened out, and your automated testing streamlined * Attention payed to the full development cycle -- starting projects, converting old projects, updating and deploying projects -- using a set of complementary packages and tools -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740532: RFA: pastedeploy -- load, configure, and compose WSGI applications and servers
Package: wnpp Severity: normal I request an adopter for the pastedeploy package. The package description is: Paste Deployment is a system for finding and configuring WSGI applications and servers. For WSGI application consumers it provides a single, simple function (loadapp) for loading a WSGI application from a configuration file or a Python Egg. For WSGI application providers it only asks for a single, simple entry point to your application, so that application users don't need to be exposed to the implementation details of your application. . This package contains the Python 2.x module. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740530: rabbitvcs: new upstream 0.16
Source: rabbitvcs Severity: normal Dear Maintainer, Please upgrade to version 0.16 Regards. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740534: RFA: python-tempita -- very small text templating language
Package: wnpp Severity: normal I request an adopter for the python-tempita package. The package description is: Tempita is a small and simple Python text templating language mainly used by Paster (python-pastescript) to roll out new projects. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
