Processed: your mail
Processing commands for cont...@bugs.debian.org:
# bugs with submitter t...@buchert.pl
submitter 734365 tom...@debian.org
Bug #734365 [freeplayer] freeplayer: unknown option or missing mandatory
argument (while calling vlc)
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 779268 tom...@debian.org
Bug #779268 [www.debian.org] www.debian.org: package list does not specify
architectures for most packages
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 775192 tom...@debian.org
Bug #775192 [wnpp] ITP: mininet -- process-based network emulator
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 778933 tom...@debian.org
Bug #778933 [wnpp] ITP: python-pyelftools -- pure-python library for parsing
ELF and DWARF
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 743478 tom...@debian.org
Bug #743478 [debian-installer] debian-installer: cannot create partitions on
RAID5 device
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 776715 tom...@debian.org
Bug #776715 [src:pax-utils] pax-utils are not reproducible
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 777421 tom...@debian.org
Bug #777421 [dnstop] dnstop: fails to capture packets in realtime
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 759164 tom...@debian.org
Bug #759164 [git-buildpackage] git-buildpackage: search for lightweight
upstream tags in git-dch
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 761200 tom...@debian.org
Bug #761200 [debbugs] debbugs: add bug number to first mail in a bug (probably
via proper header)
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 776717 tom...@debian.org
Bug #776717 {Done: Sebastien Badia s...@sebian.fr} [src:hwinfo] hwinfo build
is not reproducible
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 776716 tom...@debian.org
Bug #776716 [src:miredo] miredo is not reproducible
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 776713 tom...@debian.org
Bug #776713 [src:tiptop] tiptop: package is not reproducible
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 768487 tom...@debian.org
Bug #768487 [sponsorship-requests] RFS: fasm/1.71.22-1 [ITP] -- fast assembler
for the x86 and x86-64 architectures
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 778336 tom...@debian.org
Bug #778336 {Done: Rolf Leggewie f...@rolf.leggewie.biz} [pastebinit]
pastebinit: fails in the default configuration
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 778992 tom...@debian.org
Bug #778992 [wnpp] ITP: python-guess-language -- library to detect the natural
language of a text
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 742627 tom...@debian.org
Bug #742627 [mutt-patched] mutt-patched: full text search (l + ~b text) is
extremely slow
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 778674 tom...@debian.org
Bug #778674 {Done: Michael Gilbert mgilb...@debian.org} [apt-p2p] apt-p2p:
fails to start (throws exception)
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 749029 tom...@debian.org
Bug #749029 [screenkey] screenkey: cannot enter Preferences, screenkey hangs
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
submitter 743956 tom...@debian.org
Bug #743956 [wnpp] ITP: stellarium-stars -- additional stellarium star
catalogues
Changed Bug submitter to 'tom...@debian.org' from 't...@buchert.pl (toma)'
# bugs with owner t...@buchert.pl
thanks
Stopping processing here.
Please contact me if you need assistance.
--
734365: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734365
742627: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742627
743478: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743478
743956: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743956
749029: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749029
759164: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759164
761200: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761200
768487: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768487
775192: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775192
776713: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776713
776715: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776715
776716: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776716
776717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776717
777421: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777421
778336: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778336
778674:
Processed: Re: Bug#780054: USB modem cannot be used, affects network-manager and wvdial
Processing control commands: severity -1 important Bug #780054 [modemmanager] USB modem cannot be used, affects network-manager and wvdial Severity set to 'important' from 'critical' tags -1 moreinfo Bug #780054 [modemmanager] USB modem cannot be used, affects network-manager and wvdial Added tag(s) moreinfo. -- 780054: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780054 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780054: USB modem cannot be used, affects network-manager and wvdial
control: severity -1 important control: tags -1 moreinfo Am 08.03.2015 um 20:53 schrieb Imam Kurniawan: Mar 9 01:56:19 skynetter ModemManager[783]: info Modem for device at '/sys/devices/pci:00/:00:13.2/usb2/2-5' successfully created Mar 9 01:56:19 skynetter ModemManager[783]: Error while checking ^SYSCFGEX format: Unknown error Mar 9 01:56:19 skynetter ModemManager[783]: warn couldn't load Supported IP families: 'SIM failure' Mar 9 01:56:19 skynetter ModemManager[783]: warn Modem couldn't be initialized: Couldn't check unlock status: SIM failure Looks like ModemManager doesn't properly detect the SIM When you run ModemManager, is wvdial active? Having both run a the same time is probably not a good idea. Can you also attach the output of (run as root) mmcli -L mmcli -m number (use the one from mmcli -L) -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Processed: notfixed 780059 in 2015-01-16-1, fixed 780059 in youtube-dl/2015.01.16-1
Processing commands for cont...@bugs.debian.org: notfixed 780059 2015-01-16-1 Bug #780059 [youtube-dl] youtube-dl: Forces SSLv3, incompatible with Python 2.7.9 There is no source info for the package 'youtube-dl' at version '2015-01-16-1' with architecture '' Unable to make a source version for version '2015-01-16-1' No longer marked as fixed in versions 2015-01-16-1. fixed 780059 youtube-dl/2015.01.16-1 Bug #780059 [youtube-dl] youtube-dl: Forces SSLv3, incompatible with Python 2.7.9 Marked as fixed in versions youtube-dl/2015.01.16-1. thanks Stopping processing here. Please contact me if you need assistance. -- 780059: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780059 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779048: marked as done (libjpeg-turbo: Migration of jpeg-progs from Wheezy to Jessie)
Your message dated Sun, 08 Mar 2015 18:33:40 + with message-id e1yug1e-0004hd...@franck.debian.org and subject line Bug#779048: fixed in libjpeg-turbo 1:1.3.1-11+deb7u1 has caused the Debian Bug report #779048, regarding libjpeg-turbo: Migration of jpeg-progs from Wheezy to Jessie to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 779048: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779048 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Source: libjpeg-turbo Version: 1:1.3.1-11 Severity: serious User: release.debian.org Usertags: jessie-is-blocker Hi, It seems that there is no migration from libjpeg-progs to libjpeg-turbo-progs. Given that we have decided to not ship libjpeg9 in Jessie (and by extension, libjpeg-progs), this now leaves Wheezy users with libjpeg-progs installed and no updates to it. This is unfortunate to say the least. We ought to have caught this earlier - apologies for not doing so. Please provide a migration path from libjpeg-progs to libjpeg-turbo-progs when upgrading to Jessie. It is my understanding that libjpeg-progs remains in unstable and you may not be at liberty to break co-installability between libjpeg62-turbo and libjpeg9 in unstable. If this is indeed the case and prevents you from making a proper upgrade path via unstable, please consider doing it via testing-proposed-updates. Thanks, ~Niels ---End Message--- ---BeginMessage--- Source: libjpeg-turbo Source-Version: 1:1.3.1-11+deb7u1 We believe that the bug you reported is fixed in the latest version of libjpeg-turbo, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 779...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ondřej Surý ond...@debian.org (supplier of updated libjpeg-turbo package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 08 Mar 2015 17:04:13 +0100 Source: libjpeg-turbo Binary: libjpeg-dev libjpeg62-turbo-dev libjpeg62-turbo libjpeg62-turbo-dbg libturbojpeg1 libturbojpeg1-dbg libturbojpeg1-dev libjpeg-turbo-progs libjpeg-turbo-progs-dbg Architecture: source all amd64 Version: 1:1.3.1-11+deb7u1 Distribution: testing-proposed-updates Urgency: medium Maintainer: Ondřej Surý ond...@debian.org Changed-By: Ondřej Surý ond...@debian.org Description: libjpeg-dev - Development files for the JPEG library [dummy package] libjpeg-turbo-progs - Programs for manipulating JPEG files libjpeg-turbo-progs-dbg - Programs for manipulating JPEG files (debugging symbols) libjpeg62-turbo - libjpeg-turbo JPEG runtime library libjpeg62-turbo-dbg - Debugging symbols for the libjpeg-turbo JPEG library libjpeg62-turbo-dev - Development files for the libjpeg-turbo JPEG library libturbojpeg1 - TurboJPEG runtime library - SIMD optimized libturbojpeg1-dbg - TurboJPEG runtime library - SIMD optimized (debugging symbols) libturbojpeg1-dev - Development files for the TurboJPEG library Closes: 779048 Changes: libjpeg-turbo (1:1.3.1-11+deb7u1) testing-proposed-updates; urgency=medium . * Provide upgrade path to libjpeg-turbo-progs by adding versioned Breaks with libjpeg-progs (Closes: #779048) Checksums-Sha1: d23857a0658dbee5cce710a544efec9e1f522e52 2678 libjpeg-turbo_1.3.1-11+deb7u1.dsc 7b4d1d81e31d876fb77c0fe6848b05fe4e541257 78764 libjpeg-turbo_1.3.1-11+deb7u1.debian.tar.xz 1adefbd7bb9fe14bc54f0b78087537257062fde9 49328 libjpeg-dev_1.3.1-11+deb7u1_all.deb 57ab77e83634acefa7746a52a25db6ee68eab067 455526 libjpeg62-turbo-dev_1.3.1-11+deb7u1_amd64.deb 4f0bde054c31db61c48856fd040068dd63348b62 116306 libjpeg62-turbo_1.3.1-11+deb7u1_amd64.deb 5835c10b7f90d76cee57711db908aa08a35e7338 318270 libjpeg62-turbo-dbg_1.3.1-11+deb7u1_amd64.deb 60af13211759eb3028960b856b1c058dea0934e4 126560 libturbojpeg1_1.3.1-11+deb7u1_amd64.deb cb0ce539e426b2376d0219dade9b9f96298c84ab 354810 libturbojpeg1-dbg_1.3.1-11+deb7u1_amd64.deb 18a965a76c693fecb349dca4ad822b5efab0d77e 496316 libturbojpeg1-dev_1.3.1-11+deb7u1_amd64.deb 66a98a4920c8d45097fe3478cb19a61050c6bae5 82758 libjpeg-turbo-progs_1.3.1-11+deb7u1_amd64.deb a42d8bc8750e9136364d7029bc3eda2b2466a46d 187058
Bug#776911: gnome-shell: fails to start on i386 when [Mesa was] built with llvm-3.5
Hi, Simon McVittie wrote (26 Feb 2015 08:54:10 GMT) : Context for Mesa maintainers: #775235 is that gnome-shell crashes in an i386 VM with its default choice of emulated CPU, with LLVM ERROR: Do not know how to split the result of this operator!. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775235#10 for full backtrace. Tails is affected by that bug (https://labs.riseup.net/code/issues/8778); in case it may help asserting the severity, comment #16 there (and some further ones, particularly #19 and #22) have additional data about what exact vcpu model and features are affected. I've rebuilt the mesa package with the patch from https://freedesktop.org/patch/34445/, and it fixes things for me, at least with `-cpu qemu32'. I've asked the other Tails developer (Cc'd), who is also experiencing this bug, to try and reproduce my results. = I believe at least one of these bugs should be reassigned to the mesa package. I'll let the maintainers decide about that and about the potential RC-ness. If it helps, I can also do a more complete series of comparative tests with various vcpus. Would use of llvm-3.4 for jessie be acceptable to the Mesa maintainers? According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775235#15 that fixes at least one of these merged bugs, perhaps all three. I suspect that the release team will find that rebuilding mesa with a different compiler is more invasive and risky, at this stage of the release cycle, than applying a relatively simple patch. (The good news is that we might get a release team member's opinion for free while asking to the mesa maintainers :) Alternatively, would it be useful information for the Mesa maintainers if people tried Mesa 10.4.2 on affected systems? I can do that if it helps, although I suspect it's too way late to let that one migrate to testing. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759530: Patch to fix segfault in ldconfig
control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=18093
On 2015-02-25 13:49, Lennart Sorensen wrote:
I looked at ways the aux-cache could cause a segfault, and given the
file is mmap'd and has data offsets in it that are used as pointers
without being checked it is not hard to see how a corrupt file could
cause a segfault. The following patch makes the segfaults I was able
to think of and create go away.
Thanks for your work, it's nice we have been able to understand the real
issue.
I also have included an example corrupted aux-cache file
(aux-cache-corrupt-soname-offset) which has a bad offset that causes
a segfault.
Unfortunately they doesn't seem to work here. That said I have been able
to reproduce the problem by truncating/changing the aux cache manually.
There is another problem which I haven't solved but which is not a
segfault. If you somehow truncate the aux-cache file by a bit and run
the previous ldconfig without my patch, then you end up with a corrupted
aux-cache where some entries do not have soname's even though they should,
and that causes you to get messages like:
/sbin/ldconfig.real: /lib/i386-linux-gnu/ is not a symbolic link
/sbin/ldconfig.real: /usr/lib/i386-linux-gnu/ is not a symbolic link
/sbin/ldconfig.real: /lib64/ is not a symbolic link
/sbin/ldconfig.real: /usr/lib64/ is not a symbolic link
/sbin/ldconfig.real: /libx32/ is not a symbolic link
/sbin/ldconfig.real: /usr/libx32/ is not a symbolic link
/sbin/ldconfig.real: /usr/lib/ is not a symbolic link
/sbin/ldconfig.real: /usr/lib/i386-linux-gnu/i586/ is not a symbolic link
/sbin/ldconfig.real: /usr/lib/i386-linux-gnu/i686/cmov/ is not a symbolic link
Using ldconfig -i (and hence ignoring the corrupted aux-cache) makes
that problem go away. To solve it would of course mean you have to
not trust the cache which rather defeats the point of having the cache,
so I don't know if that is worth trying to solve. It does not cause a
segfault however.
Using ldconfig -p to show the cache at that point has entries that are
clearly wrong such as:
...
day (libc6, OS ABI: Linux 2.6.32) = /lib/i386-linux-gnu/day
__kernel_sigreturn (libc6,x32, OS ABI: Linux 3.4.0) =
/libx32/__kernel_sigreturn
X_2.6 (libc6) = /usr/lib/i386-linux-gnu/X_2.6
LF (libc6) = /usr/lib/i386-linux-gnu/LF
(libc6) = /usr/lib/
(libc6, OS ABI: Linux 2.6.32) = /lib/i386-linux-gnu/
(libc6, OS ABI: Linux 2.6.32) = /usr/lib/i386-linux-gnu/
(libc6) = /lib/i386-linux-gnu/
(libc6) = /usr/lib/i386-linux-gnu/
(libc6) = /usr/lib/i386-linux-gnu/
(libc6) = /usr/lib/i386-linux-gnu/
(libc6) = /usr/lib/i386-linux-gnu/
(libc6, OS ABI: Linux 2.6.32) = /lib/i386-linux-gnu/
(libc6, OS ABI: Linux 2.6.32) = /usr/lib/i386-linux-gnu/
(libc6,x32, OS ABI: Linux 3.4.0) = /libx32/
(libc6,x32, OS ABI: Linux 3.4.0) = /usr/libx32/
(libc6,x86-64, OS ABI: Linux 2.6.32) = /lib64/
(libc6,x86-64, OS ABI: Linux 2.6.32) = /usr/lib64/
(libc6, hwcap: 0x00088000) =
/usr/lib/i386-linux-gnu/i686/cmov/
(libc6, hwcap: 0x0004) = /usr/lib/i386-linux-gnu/i586/
(libc6) = /lib/i386-linux-gnu/
(libc6) = /usr/lib/i386-linux-gnu/
(libc6) = /usr/lib/
� (libc6) = /lib/i386-linux-gnu/�
The file aux-cache-missing-sonames shows this corrupted state.
I hope the patch at least helps solve the worst part of the problem.
I think the idea behind the patch is correct, but it is not fully
correct (or at least it only fixes corner cases).
diff -ur --exclude debian --exclude build-tree glibc-2.19.ori/elf/cache.c
glibc-2.19/elf/cache.c
--- glibc-2.19.ori/elf/cache.c2015-02-25 16:24:59.0 +
+++ glibc-2.19/elf/cache.c2015-02-25 17:42:18.0 +
@@ -699,7 +699,8 @@
if (aux_cache == MAP_FAILED
|| aux_cache_size sizeof (struct aux_cache_file)
|| memcmp (aux_cache-magic, AUX_CACHEMAGIC, sizeof AUX_CACHEMAGIC - 1)
- || aux_cache-nlibs = aux_cache_size)
+ || sizeof(struct aux_cache_file) + (aux_cache-nlibs - 1) *
sizeof(struct aux_cache_file_entry) = aux_cache_size
Why using (aux_cache-nlibs - 1) and not directly aux_cache-nlibs here?
+ || aux_cache-nlibs * sizeof(struct aux_cache_file_entry) +
aux_cache-libs[aux_cache-nlibs - 1].soname = aux_cache_size)
The best to catch all cases here is to compute the theoretical size of
the file using the headers and comparing it to the real one.
{
close (fd);
init_aux_cache ();
@@ -712,12 +713,14 @@
const char *aux_cache_data
= (const char *) aux_cache-libs[aux_cache-nlibs];
for (unsigned int i = 0; i aux_cache-nlibs; ++i)
-insert_to_aux_cache (aux_cache-libs[i].id,
- aux_cache-libs[i].flags,
- aux_cache-libs[i].osversion,
Processed: Re: Bug#759530: Patch to fix segfault in ldconfig
Processing control commands: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=18093 Bug #759530 [libc-bin] libc-bin: ldconfig breaks a system Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=18093'. -- 759530: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759530 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762700: systemd: journald fails to forward some messages to syslog
Hello. Sorry if what I ask is very silly, but I feel I need to ask anyway... If sysvinit started syslog and waited for it and then started everything else, why can't we do the same with systemd? I mean, don't create the socket and then start syslog, but just start syslog and make everything that logs wait for it like in sysvinit. Is this just a performance optimization or is there another reason? BTW, my system says systemd-journal[153]: Forwarding to syslog missed 293 messages.. Another thing I don't understand is why after startup, in normal operation, things like NetworkManager or some other daemons can lose messages to syslog? Does that happen with sysvinit too or is it a systemd specific thing? RHEL7 has the same issue? Maybe they have solved it or do something differently, but it could be useful to look... Thanks and sorry for being dumb! Have a great day! -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: iba...@codigolibre.net - http://go.to/ibaldo -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779048: libjpeg-turbo: Migration of jpeg-progs from Wheezy to Jessie
On Sun, Mar 8, 2015, at 17:47, Niels Thykier wrote:
On 2015-03-08 16:47, Ondřej Surý wrote:
Hi Niels,
what if I just do:
Package: libjpeg62-turbo
[...]
Conflicts: libjpeg-progs ( 2:0), libjpeg-progs ( 1:0)
(or more precise Conflicts: libjpeg-progs ( ${binary:Version},
libjpeg-progs ( ${binary:Version})
That should push libjpeg-progs from other sources out
Cheers,
Ondrej
[...]
Seems reasonable at first glance. Can you upload that to tpu
Done.
(with a no-change upload to sid to ensure the tpu version is = than sid)?
Done. (Since we are stuck to t-p-u now, I could probably bring 1.4.0
from experimental to unstable now, but let's leave it after the dust
settles...)
That way we force Wheezy (and testing) to force migrate into turbo
without breaking co-installability with libjpeg's progs (and therefore
avoid any political fall-out with other interested parties).
We should definitely solve this after jessie is out.
It will leave unstable users with the current progs. However, I
consider that less of a problem, given they can pull updates to that
implementation via unstable (unlike pure Jessie users).
True.
O.
--
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779801: marked as done (pngcrush: CVE-2015-2158)
Your message dated Sun, 8 Mar 2015 18:46:58 +0100 with message-id 20150308174658.GA4466@eldamar.local and subject line Re: Bug#779801: CVE-2015-2158 has caused the Debian Bug report #779801, regarding pngcrush: CVE-2015-2158 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 779801: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779801 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: pngcrush Severity: grave Tags: security Hi, this has been assigned CVE-2015-2158: http://www.openwall.com/lists/oss-security/2015/02/28/6 Cheers, Moritz ---End Message--- ---BeginMessage--- Hi Moritz, On Wed, Mar 04, 2015 at 10:42:54PM +0100, Moritz Muehlenhoff wrote: Package: pngcrush Severity: grave Tags: security Hi, this has been assigned CVE-2015-2158: http://www.openwall.com/lists/oss-security/2015/02/28/6 It looks this should have been introduced in 1.7.83[1] and then fixed in 1.7.84[2], see as well the analysis of Red Hat in [3]. [1] http://sourceforge.net/p/pmt/code/ci/e1a36a9639e2db16494d90459c7c2b78677a20bf/ [2] http://sourceforge.net/p/pmt/code/ci/a1ce646d00a400fd9ec321ab5cb522f40b7bdfe6/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=1198171#c2 Regards, Salvatore---End Message---
Processed: your mail
Processing commands for cont...@bugs.debian.org:
# bugs with submitter tomasz.buch...@inria.fr
submitter 734365 !
Bug #734365 [freeplayer] freeplayer: unknown option or missing mandatory
argument (while calling vlc)
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 778933 !
Bug #778933 [wnpp] ITP: python-pyelftools -- pure-python library for parsing
ELF and DWARF
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 775192 !
Bug #775192 [wnpp] ITP: mininet -- process-based network emulator
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 779268 !
Bug #779268 [www.debian.org] www.debian.org: package list does not specify
architectures for most packages
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 743478 !
Bug #743478 [debian-installer] debian-installer: cannot create partitions on
RAID5 device
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 776715 !
Bug #776715 [src:pax-utils] pax-utils are not reproducible
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 777421 !
Bug #777421 [dnstop] dnstop: fails to capture packets in realtime
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 759164 !
Bug #759164 [git-buildpackage] git-buildpackage: search for lightweight
upstream tags in git-dch
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 776717 !
Bug #776717 {Done: Sebastien Badia s...@sebian.fr} [src:hwinfo] hwinfo build
is not reproducible
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 761200 !
Bug #761200 [debbugs] debbugs: add bug number to first mail in a bug (probably
via proper header)
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 776716 !
Bug #776716 [src:miredo] miredo is not reproducible
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 776713 !
Bug #776713 [src:tiptop] tiptop: package is not reproducible
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 768487 !
Bug #768487 [sponsorship-requests] RFS: fasm/1.71.22-1 [ITP] -- fast assembler
for the x86 and x86-64 architectures
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 778336 !
Bug #778336 {Done: Rolf Leggewie f...@rolf.leggewie.biz} [pastebinit]
pastebinit: fails in the default configuration
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 742627 !
Bug #742627 [mutt-patched] mutt-patched: full text search (l + ~b text) is
extremely slow
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 778992 !
Bug #778992 [wnpp] ITP: python-guess-language -- library to detect the natural
language of a text
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 778674 !
Bug #778674 {Done: Michael Gilbert mgilb...@debian.org} [apt-p2p] apt-p2p:
fails to start (throws exception)
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 749029 !
Bug #749029 [screenkey] screenkey: cannot enter Preferences, screenkey hangs
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
submitter 743956 !
Bug #743956 [wnpp] ITP: stellarium-stars -- additional stellarium star
catalogues
Changed Bug submitter to 't...@buchert.pl (toma)' from 'Tomasz Buchert
tomasz.buch...@inria.fr'
# bugs with owner tomasz.buch...@inria.fr
thanks
Stopping processing here.
Please contact me if you need assistance.
--
734365: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734365
742627: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742627
743478: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743478
743956: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743956
749029: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749029
759164: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759164
761200: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761200
768487: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768487
775192: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775192
776713: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776713
776715: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776715
776716: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776716
776717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776717
777421:
Bug#780054: USB modem cannot be used, affects network-manager and wvdial
Package: modemmanager Version: 1.4.4-1 Severity: critical Tags: upstream Dear, Sir. I am using Debian Testing for all daily works at my personal computer, and always make all packages are up to date (apt-get upgrade and apt-get dist- upgrade). Someday after made all packages are up to date, I realized that modemmanager is not working anymore. I cannot use my USB modem, Huawei K4505. The problem affects network-manager and wvdial as described below (1-5): 1) At NetworkManager Applet with right click mouse, I have Enable Mobile Broadband. But when I want to activate the connection with left click mouse, it shows Mobile Broadband not enabled (with grey text color/cannot be clicked). 2) Sometime I use wvdial to activate the connection for my USB modem. It always works, but I think because the problem from modemmanager, now I cannot use it. 3) The problem occurs with modemmanager in unstable (1.4.0-1), and reproduced in experimental (1.4.4-1). I have upgraded modemmanager to experimental version to see the problem still exists or not, and evidently the problem still occurs. 4) Here is the log from /var/log/syslog Mar 9 01:55:59 skynetter kernel: [ 87.591122] usb 2-5: new high-speed USB device number 2 using ehci-pci Mar 9 01:55:59 skynetter kernel: [ 87.726205] usb 2-5: New USB device found, idVendor=12d1, idProduct=1521 Mar 9 01:55:59 skynetter kernel: [ 87.726217] usb 2-5: New USB device strings: Mfr=3, Product=2, SerialNumber=0 Mar 9 01:55:59 skynetter kernel: [ 87.726224] usb 2-5: Product: Vodafone Mobile Broadband (Huawei) Mar 9 01:55:59 skynetter kernel: [ 87.726229] usb 2-5: Manufacturer: Vodafone Group (Huawei) Mar 9 01:55:59 skynetter mtp-probe: checking bus 2, device 2: /sys/devices/pci:00/:00:13.2/usb2/2-5 Mar 9 01:55:59 skynetter mtp-probe: bus: 2, device: 2 was not an MTP device Mar 9 01:55:59 skynetter kernel: [ 87.807284] usb-storage 2-5:1.0: USB Mass Storage device detected Mar 9 01:55:59 skynetter kernel: [ 87.807380] scsi6 : usb-storage 2-5:1.0 Mar 9 01:55:59 skynetter kernel: [ 87.807486] usb-storage 2-5:1.1: USB Mass Storage device detected Mar 9 01:55:59 skynetter kernel: [ 87.807533] scsi7 : usb-storage 2-5:1.1 Mar 9 01:55:59 skynetter kernel: [ 87.807617] usbcore: registered new interface driver usb-storage Mar 9 01:56:00 skynetter usb_modeswitch: switch device 12d1:1521 on 002/002 Mar 9 01:56:00 skynetter kernel: [ 88.470655] usb 2-5: USB disconnect, device number 2 Mar 9 01:56:05 skynetter kernel: [ 93.294623] usb 2-5: new high-speed USB device number 3 using ehci-pci Mar 9 01:56:05 skynetter kernel: [ 93.429875] usb 2-5: New USB device found, idVendor=12d1, idProduct=1464 Mar 9 01:56:05 skynetter kernel: [ 93.429887] usb 2-5: New USB device strings: Mfr=4, Product=3, SerialNumber=0 Mar 9 01:56:05 skynetter kernel: [ 93.429894] usb 2-5: Product: Vodafone Mobile Broadband (Huawei) Mar 9 01:56:05 skynetter kernel: [ 93.429900] usb 2-5: Manufacturer: Vodafone Group (Huawei) Mar 9 01:56:05 skynetter kernel: [ 93.435480] usb-storage 2-5:1.5: USB Mass Storage device detected Mar 9 01:56:05 skynetter kernel: [ 93.435695] scsi8 : usb-storage 2-5:1.5 Mar 9 01:56:05 skynetter kernel: [ 93.436134] usb-storage 2-5:1.6: USB Mass Storage device detected Mar 9 01:56:05 skynetter kernel: [ 93.436256] scsi9 : usb-storage 2-5:1.6 Mar 9 01:56:05 skynetter mtp-probe: checking bus 2, device 3: /sys/devices/pci:00/:00:13.2/usb2/2-5 Mar 9 01:56:05 skynetter mtp-probe: bus: 2, device: 3 was not an MTP device Mar 9 01:56:05 skynetter kernel: [ 93.536790] cdc_ether 2-5:1.1 wwan0: register 'cdc_ether' at usb-:00:13.2-5, Mobile Broadband Network Device, 02:50:f3:00:00:00 Mar 9 01:56:05 skynetter kernel: [ 93.536822] usbcore: registered new interface driver cdc_ether Mar 9 01:56:05 skynetter NetworkManager[785]: info devices added (path: /sys/devices/pci:00/:00:13.2/usb2/2-5/2-5:1.1/net/wwan0, iface: wwan0) Mar 9 01:56:05 skynetter NetworkManager[785]: info device added (path: /sys/devices/pci:00/:00:13.2/usb2/2-5/2-5:1.1/net/wwan0, iface: wwan0): no ifupdown configuration found. Mar 9 01:56:05 skynetter logger: usb_modeswitch: switched to 12d1:1464 on 002/003 Mar 9 01:56:05 skynetter kernel: [ 93.556486] usbcore: registered new interface driver usbserial Mar 9 01:56:05 skynetter kernel: [ 93.556509] usbcore: registered new interface driver usbserial_generic Mar 9 01:56:05 skynetter kernel: [ 93.556527] usbserial: USB Serial support registered for generic Mar 9 01:56:05 skynetter kernel: [ 93.581054] usbcore: registered new interface driver option Mar 9 01:56:05 skynetter kernel: [ 93.581227] usbserial: USB Serial support registered for GSM modem (1-port) Mar 9 01:56:05 skynetter kernel: [ 93.581318] option 2-5:1.0: GSM modem (1-port) converter detected Mar 9 01:56:05 skynetter kernel: [ 93.581456] usb 2-5: GSM modem (1-port) converter now attached to ttyUSB0 Mar 9 01:56:05
Bug#780059: youtube-dl: Forces SSLv3, incompatible with Python 2.7.9
Package: youtube-dl Version: 2014.08.05-1 Severity: grave Tags: patch Justification: renders package unusable Control: fixed -1 2015-01-16-1 Upstream is doing some crazy stuff with SSL. Fortunately, they admit this in their git history, and have improved things since the 2014.08.05 release. The protocol is forced to SSLv3, rather than negotiating the latest protocol supported by both sides. There is a fallback path to negotiation, but it doesn't work when PROTOCOL_SSLv3 isn't available in the Python ssl module (as is the case, since 2.7.8-12). The attached patch should fix the issue. SR Description: Support Python 2.7.9, which removed PROTOCOL_SSLv3 In fact, don't try to force an SSL version at all. Debian OpenSSL doesn't support insecure versions. Upstream use Python's default SSL handshake since https://github.com/rg3/youtube-dl/commit/0db261ba567cb5370455d67c4398e11e5e2119f8 And switches to TLSv1 in legacy paths in https://github.com/rg3/youtube-dl/commit/d79323136fabc2cd72afc7c124e17797e32df514 Author: Stefano Rivera stefa...@debian.org Forwarded: not-needed Last-Update: 2015-03-08 --- a/youtube_dl/utils.py +++ b/youtube_dl/utils.py @@ -588,17 +588,14 @@ if getattr(self, '_tunnel_host', False): self.sock = sock self._tunnel() -try: -self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file, ssl_version=ssl.PROTOCOL_SSLv3) -except ssl.SSLError: -self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file, ssl_version=ssl.PROTOCOL_SSLv23) +self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file, ssl_version=ssl.PROTOCOL_SSLv23) class HTTPSHandlerV3(compat_urllib_request.HTTPSHandler): def https_open(self, req): return self.do_open(HTTPSConnectionV3, req) return HTTPSHandlerV3(**kwargs) else: -context = ssl.SSLContext(ssl.PROTOCOL_SSLv3) +context = ssl.SSLContext(ssl.PROTOCOL_SSLv23) context.verify_mode = (ssl.CERT_NONE if opts_no_check_certificate else ssl.CERT_REQUIRED)
Processed: youtube-dl: Forces SSLv3, incompatible with Python 2.7.9
Processing control commands: fixed -1 2015-01-16-1 Bug #780059 [youtube-dl] youtube-dl: Forces SSLv3, incompatible with Python 2.7.9 There is no source info for the package 'youtube-dl' at version '2015-01-16-1' with architecture '' Unable to make a source version for version '2015-01-16-1' Marked as fixed in versions 2015-01-16-1. -- 780059: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780059 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: tagging 767019
Processing commands for cont...@bugs.debian.org: user release.debian@packages.debian.org Setting user to release.debian@packages.debian.org (was iv...@debian.org). usertags 767019 jessie-can-defer There were no usertags set. Usertags are now: jessie-can-defer. tags 767019 + jessie-ignore Bug #767019 [xscreensaver] xscreensaver: postinst overwrites /etc/X11/app-defaults/XScreenSaver without asking Added tag(s) jessie-ignore. thanks Stopping processing here. Please contact me if you need assistance. -- 767019: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767019 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779993: DFSG violation, Not including changelog of 2.4.1-1
Control: reassign -1 src:task 2.4.1-1 Control: severity -1 normal Control: retitle -1 src:task missing changelog entry for 2.4.1-1 Hallo Martin, Thanks for the report. However, a missing changelog entry is not a DFSG violation. It is also not RC. As said by Sebastien the 2.4.1 was uploaded in error -- I selected the wrong package to upload -- and this version actually contained a DFSG violation (a file which cannot be rebuilt). While we usually strive to have complete changelogs, and the missing changelog entry should not have happened in the first place, this is *not* release critical per defintion. -- tobi signature.asc Description: This is a digitally signed message part
Processed: Re: DFSG violation, Not including changelog of 2.4.1-1
Processing control commands: reassign -1 src:task 2.4.1-1 Bug #779993 [taskwarrior] DFSG violation, Not including changelog of 2.4.1-1 Bug reassigned from package 'taskwarrior' to 'src:task'. No longer marked as found in versions task/2.4.1+dfsg-2. Ignoring request to alter fixed versions of bug #779993 to the same values previously set Bug #779993 [src:task] DFSG violation, Not including changelog of 2.4.1-1 Marked as found in versions task/2.4.1-1. severity -1 normal Bug #779993 [src:task] DFSG violation, Not including changelog of 2.4.1-1 Severity set to 'normal' from 'serious' retitle -1 src:task missing changelog entry for 2.4.1-1 Bug #779993 [src:task] DFSG violation, Not including changelog of 2.4.1-1 Changed Bug title to 'src:task missing changelog entry for 2.4.1-1' from 'DFSG violation, Not including changelog of 2.4.1-1' -- 779993: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779993 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: tagging 767659
Processing commands for cont...@bugs.debian.org: # only affects upgrades from older versions of jessie, not from wheezy user release.debian@packages.debian.org Setting user to release.debian@packages.debian.org (was iv...@debian.org). usertags 767659 jessie-can-defer There were no usertags set. Usertags are now: jessie-can-defer. tags 767659 + jessie-ignore Bug #767659 [libpoppler-glib8] evince 3.14.1-1 gets undefined symbol with libpoppler46:i386 earlier than 0.26.5-2 Bug #768475 [libpoppler-glib8] evince: segfault on trying to open a pdf Bug #768985 [libpoppler-glib8] libpoppler-glib.so.8: undefined symbol Segmentation fault Added tag(s) jessie-ignore. Added tag(s) jessie-ignore. Added tag(s) jessie-ignore. thanks Stopping processing here. Please contact me if you need assistance. -- 767659: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767659 768475: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768475 768985: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768985 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780059: youtube-dl: Forces SSLv3, incompatible with Python 2.7.9
Hi Debian (2015.03.08_14:32:19_-0700)
The protocol is forced to SSLv3, rather than negotiating the latest protocol
supported by both sides. There is a fallback path to negotiation, but it
doesn't work when PROTOCOL_SSLv3 isn't available in the Python ssl module (as
is the case, since 2.7.8-12).
I forgot to provide a stack trace:
[youtube] Setting language
Traceback (most recent call last):
File /usr/bin/youtube-dl, line 9, in module
load_entry_point('youtube-dl==2014.08.05', 'console_scripts',
'youtube-dl')()
File /usr/lib/python2.7/dist-packages/youtube_dl/__init__.py, line 890, in
main
_real_main(argv)
File /usr/lib/python2.7/dist-packages/youtube_dl/__init__.py, line 880, in
_real_main
retcode = ydl.download(all_urls)
File /usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py, line 1052,
in download
self.extract_info(url)
File /usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py, line 516, in
extract_info
ie_result = ie.extract(url)
File /usr/lib/python2.7/dist-packages/youtube_dl/extractor/common.py, line
169, in extract
self.initialize()
File /usr/lib/python2.7/dist-packages/youtube_dl/extractor/common.py, line
164, in initialize
self._real_initialize()
File /usr/lib/python2.7/dist-packages/youtube_dl/extractor/youtube.py, line
123, in _real_initialize
if not self._set_language():
File /usr/lib/python2.7/dist-packages/youtube_dl/extractor/youtube.py, line
50, in _set_language
fatal=False))
File /usr/lib/python2.7/dist-packages/youtube_dl/extractor/common.py, line
283, in _download_webpage
res = self._download_webpage_handle(url_or_request, video_id, note,
errnote, fatal)
File /usr/lib/python2.7/dist-packages/youtube_dl/extractor/common.py, line
223, in _download_webpage_handle
urlh = self._request_webpage(url_or_request, video_id, note, errnote, fatal)
File /usr/lib/python2.7/dist-packages/youtube_dl/extractor/common.py, line
203, in _request_webpage
return self._downloader.urlopen(url_or_request)
File /usr/lib/python2.7/dist-packages/youtube_dl/YoutubeDL.py, line 1231,
in urlopen
return self._opener.open(req, timeout=self._socket_timeout)
File /usr/lib/python2.7/urllib2.py, line 431, in open
response = self._open(req, data)
File /usr/lib/python2.7/urllib2.py, line 449, in _open
'_open', req)
File /usr/lib/python2.7/urllib2.py, line 409, in _call_chain
result = func(*args)
File /usr/lib/python2.7/dist-packages/youtube_dl/utils.py, line 598, in
https_open
return self.do_open(HTTPSConnectionV3, req)
File /usr/lib/python2.7/urllib2.py, line 1194, in do_open
h.request(req.get_method(), req.get_selector(), req.data, headers)
File /usr/lib/python2.7/httplib.py, line 1001, in request
self._send_request(method, url, body, headers)
File /usr/lib/python2.7/httplib.py, line 1035, in _send_request
self.endheaders(body)
File /usr/lib/python2.7/httplib.py, line 997, in endheaders
self._send_output(message_body)
File /usr/lib/python2.7/httplib.py, line 850, in _send_output
self.send(msg)
File /usr/lib/python2.7/httplib.py, line 812, in send
self.connect()
File /usr/lib/python2.7/dist-packages/youtube_dl/utils.py, line 592, in
connect
self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file,
ssl_version=ssl.PROTOCOL_SSLv3)
AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: bug 779989 is forwarded to https://bugzilla.gnome.org/show_bug.cgi?id=745868
Processing commands for cont...@bugs.debian.org:
forwarded 779989 https://bugzilla.gnome.org/show_bug.cgi?id=745868
Bug #779989 {Done: Simon McVittie s...@debian.org} [gdm3] invoke-rc.d:
initscript gdm3, action reload failed.
Set Bug forwarded-to-address to
'https://bugzilla.gnome.org/show_bug.cgi?id=745868'.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
779989: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779989
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780007: marked as done (db5.3 build-depends on debhelper = 9.20141221~ but jessie only has 9.20141022)
Your message dated Sun, 08 Mar 2015 11:29:01 +0100 with message-id 54fc246d.4090...@thykier.net and subject line Re: [debhelper-devel] Bug#780007: db5.3 build-depends on debhelper = 9.20141221~ but jessie only has 9.20141022 has caused the Debian Bug report #780007, regarding db5.3 build-depends on debhelper = 9.20141221~ but jessie only has 9.20141022 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 780007: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780007 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: db5.3 Version: 5.3.28-9 Severity: serious Tags: jessie x-debbugs-cc: debhel...@packages.debian.org The version of db5.3 that just migrated to testing build-depends on debhelper = 9.20141221~ but jessie only has 9.20141022 . This means that db5.3 cannot be built in jessie. I notice that the recent debhelper uploads were made by Niels Thykier who is also a release manager. I don't know if that means there is an intention to unblock debhelper or not. ---End Message--- ---BeginMessage--- On 2015-03-08 03:27, peter green wrote: Package: db5.3 Version: 5.3.28-9 Severity: serious Tags: jessie x-debbugs-cc: debhel...@packages.debian.org The version of db5.3 that just migrated to testing build-depends on debhelper = 9.20141221~ but jessie only has 9.20141022 . This means that db5.3 cannot be built in jessie. I notice that the recent debhelper uploads were made by Niels Thykier who is also a release manager. I don't know if that means there is an intention to unblock debhelper or not. [...] The new version of debhelper got unblocked (see #780016). Thanks, ~Niels---End Message---
Bug#757413: Processed: jessie
Control: tag -1 - sid jessie
Cyril Brulebois k...@debian.org (2015-02-28):
Debian Bug Tracking System ow...@bugs.debian.org (2015-02-28):
tags 757413 + sid jessie
Bug #757413 {Done: Steve McIntyre st...@einval.com} [partman-target]
debian-installer: Please do not add mount point on /media/usb0 because
create conflict with mount point create by kdm desktop session
Added tag(s) sid and jessie.
Again?
No argumentation, so removing tags again.
Meh,
KiBi.
signature.asc
Description: Digital signature
Processed: Re: Bug#757413: Processed: jessie
Processing control commands:
tag -1 - sid jessie
Bug #757413 {Done: Steve McIntyre st...@einval.com} [partman-target]
debian-installer: Please do not add mount point on /media/usb0 because create
conflict with mount point create by kdm desktop session
Removed tag(s) sid and jessie.
--
757413: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757413
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757413: Processed: jessie
Hi Cyril, On Sonntag, 8. März 2015, Cyril Brulebois wrote: Again? No argumentation, so removing tags again. the bug shows up on http://udd.debian.org/bugs.cgi?release=wheezyrc=1sortby=idsorto=descctags=1 - and as thus gets on the radar of people caring about fixing RC bugs in stable and AFAICS this bug is not RC for wheezy. So I would like it to not show up on that URL... So, shall we tag it wheezy-ignore instead? (so cc:ing -release@ for input.) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#776910: apt: upgrade from wheezy to jessie breaks in the middle
On Tue, Feb 24, 2015 at 09:53:11AM +0100, Rafał Pietrak wrote: W dniu 23.02.2015 22:27, Niels Thykier pisze: On 2015-02-03 16:34, Rafal Pietrak wrote: [] 2. I do _vaguely_ remember last line above the shell prompt (after upgrade stopped) saying: too many errors (after quite long running upgrade). I suspect that line is from dpkg. There are example of: dpkg: too many errors, stopping Maybe you were looking for dpkg ... --abort-after=99? At least that is what a quick googling suggests. Possibly. No, you are not looking for this, like ever. apt and dpkg are tidily coupled so people usually have their problems figuring out which message comes from which program, but that is okay as there is just on general rule: If apt exits non-zero (= it fails) then something really bad happened, which shouldn't have happened and which needs to be fixed for the release. No strange workarounds for users. End of story. apt and dpkg have various points at which they consider something to be really bad and you can configure some of them to a certain degree, but that isn't advisable. It will usually fail anyway in the best case and open an all consuming crack in the space-time continuum in the worst case. The reason is simply that they aren't failing just for fun and try really hard to avoid any kind of problem to begin with. They also have various points which they consider bad and complain about it, but carry on anyway in the hope it will work out anyway. It usually does, but if it doesn't, these messages give hints where it all started to go downhill. 5. I'm filing this bugreport, because this time there was no reboot-in-the middle, so I'd expect, the apt-max-errors (if it really exists - I cannot find it now) is truely too low for an average system I'd imagine, that upgrade from one major release to another should set it temporarly to infinity ;7, but may be not. Rather, there should be no errors during an upgrade - ever. That is one of the goals for upgrades. Somehow, setting such a (fictive?) option to infinite seems to be working around a problem that should not exist in the first place. Yes and no. *actual errors* yes; but I don't think I've seen them during the upgrade. 1. During the upgrade I have seen some errors/complains about unresolved dependencies, or conflicts ... but continiueing anyway as requested the apt-get said. 2. at one point it said too many errors and stopped. 3. then a simple apt-get -f install; apt-get dist-upgrade completed the task (sort of) cleanly. MHC (e.g. Conclusion) is, that there were kind of errors, which were *expected* during the *dist-upgrade* from release to release, but apt-get counted them anywayand checked against a treshold which it shouldn't in that particular situation of major release change. The 1. you mention are complains of dpkg about how apt is talking to it. They are 'normal' and 'okay' and are unlimited. (As a user) Ignore them. 2. is very very likely dpkg running into a trigger loop and unrelated to the 1.. (Well, they could be related potentially, but they aren't counting for the 'too many errors', but just influence the formation of loops). The errors leading to 2. look a lot like 1. through, but they are different in such a way that they aren't recoverable if they can't be resolved, so dpkg is trying hard to find a solution, but at some point it has to give up or it would just run forever in circles (it did, in certain buggy versions). 3. works (sometimes) because apt rethinks the upgrade, might come to a different solution (still with the same packages involved, but in a different order) and in this one dpkg doesn't end in a loop. That works ONLY in this case as apt and dpkg have a deep communication problem here. Just rerunning apt usually doesn't work (otherwise we could just do that by default, right?). The think is that I figured out a while back that the way apt is talking to dpkg, dpkg can create a loop for itself without apt knowing before it is actually too late. That is made worse by the fact that apt doesn't know that dpkg cares about these loops anyhow (it didn't until very recently) and apt doesn't know such loops can exist – in fact it pretends that the things (= triggers) which create these loops do not even exist as they are in theory an implementation detail of dpkg. The other RC bugs apt currently has deal with this looping, so if you really want to you can look into them if you want more details, but I would avoid it if I could. Also requires a fair bit of deep knowledge even most DDs do not concern themselves with… so don't say I haven't warned you. ;) The important part is that loop detection was dropped from jessie by request of Nils (thanks a million), so that what you saw will not be seen with released jessie and hence in a wheezy to jessie upgrade. I believe the BTS will accept it (you may want to gzip it though), but lists.d.o
Processed: notfound 780007 in 5.3.28-9
Processing commands for cont...@bugs.debian.org:
notfound 780007 5.3.28-9
Bug #780007 {Done: Niels Thykier ni...@thykier.net} [db5.3] db5.3
build-depends on debhelper = 9.20141221~ but jessie only has 9.20141022
There is no source info for the package 'db5.3' at version '5.3.28-9' with
architecture ''
Unable to make a source version for version '5.3.28-9'
No longer marked as found in versions 5.3.28-9.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
780007: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780007
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779662: package fails to build without network connection
On Tue, Mar 03, 2015 at 08:26:38PM +0100, Matthias Klose wrote: Package: src:fedmsg-meta-fedora-infrastructure Version: 0.2.18-1 Severity: serious Tags: sid jessie The package fails to build in an unstable environment on amd64 without having network access. the build log shows errors like these, which go away if you have network connection. I wanted to work on this but couldn't find an easy way to build a package without network access. -- WBR, wRAR signature.asc Description: Digital signature
Bug#779662: package fails to build without network connection
Control: tags -1 + unreproducible * Matthias Klose d...@debian.org [2015-03-03 20:26:38 +0100]: Package: src:fedmsg-meta-fedora-infrastructure Version: 0.2.18-1 Severity: serious Tags: sid jessie The package fails to build in an unstable environment on amd64 without having network access. the build log shows errors like these, which go away if you have network connection. Hi, I couldn't reproduce this on my laptop disconnected from the internet. Please be more specific as to what you mean by no network access. I'm pretty sure those tests need access to localhost, and I'm not sure no localhost is a supported configuration for our build environment. Thanks, -- Nicolas Dandrimont BOFH excuse #433: error: one bad user found in front of screen signature.asc Description: Digital signature
Processed: Re: Bug#779662: package fails to build without network connection
Processing control commands: tags -1 + unreproducible Bug #779662 [src:fedmsg-meta-fedora-infrastructure] package fails to build without network connection Added tag(s) unreproducible. -- 779662: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779662 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774700: [pkg-cryptsetup-devel] Bug#774700: Cryptsetup tools are not included by update-initramfs command
Hi, Am 16.02.2015 um 19:36 schrieb Musy Bite: Hello Jonas! We run into this bug, too. There is mkinitramfs_debug.log you requested at message #25. Installation was performed from debian testing amd64 netinst ISO image built on unknown date, and apt-get dist-upgraded to jessie. cryptsetup version is 2:1.6.6-5. please send the content of /etc/crypttab and /etc/fstab in order to better understand what's going on here. It seems to me like as if a UUID is treaten as dm device name instead of being treated as UUID. Cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#778655: doxygen: Doxygen should not enable markdown by default
Processing control commands: severity -1 important Bug #778655 [doxygen] doxygen: Doxygen should not enable markdown by default Severity set to 'important' from 'serious' -- 778655: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778655 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779662: marked as done (package fails to build without network connection)
Your message dated Sun, 8 Mar 2015 13:47:58 +0100 with message-id 20150308124758.ge19...@werner.olasd.eu and subject line Re: Bug#779662: package fails to build without network connection has caused the Debian Bug report #779662, regarding package fails to build without network connection to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 779662: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779662 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: src:fedmsg-meta-fedora-infrastructure Version: 0.2.18-1 Severity: serious Tags: sid jessie The package fails to build in an unstable environment on amd64 without having network access. the build log shows errors like these, which go away if you have network connection. == FAIL: test_secondary_icon (fedmsg_meta_fedora_infrastructure.tests.TestGithubDelete) Does fedmsg.meta produce the expected secondary icon? -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/fedmsg/tests/test_meta.py, line 44, in inner return func(self) File /usr/lib/python2.7/dist-packages/fedmsg/tests/test_meta.py, line 100, in test_secondary_icon eq_(actual_icon, self.expected_secondary_icon) AssertionError: None != 'https://seccdn.libravatar.org/avatar/9c9f7784935381befc302fe3c814f9136e7a33953d0318761669b8643f4df55c?s=64d=retro' == FAIL: test_icon (fedmsg_meta_fedora_infrastructure.tests.TestGithubFork) Does fedmsg.meta produce the expected icon? -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/fedmsg/tests/test_meta.py, line 44, in inner return func(self) File /usr/lib/python2.7/dist-packages/fedmsg/tests/test_meta.py, line 94, in test_icon eq_(actual_icon, self.expected_icon) AssertionError: 'https://apps.fedoraproject.org/img/icons/git-logo.png' != 'https://apps.fedoraproject.org/img/icons/github.png' == FAIL: test_link (fedmsg_meta_fedora_infrastructure.tests.TestGithubFork) Does fedmsg.meta produce the expected link? -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/fedmsg/tests/test_meta.py, line 44, in inner return func(self) File /usr/lib/python2.7/dist-packages/fedmsg/tests/test_meta.py, line 88, in test_link eq_(actual_link, self.expected_link) AssertionError: None != 'https://github.com/kushal124/github2fedmsg' ---End Message--- ---BeginMessage--- Version: 0.2.18-1 * Nicolas Dandrimont ol...@debian.org [2015-03-08 12:42:20 +0100]: Control: tags -1 + unreproducible * Matthias Klose d...@debian.org [2015-03-03 20:26:38 +0100]: Package: src:fedmsg-meta-fedora-infrastructure Version: 0.2.18-1 Severity: serious Tags: sid jessie The package fails to build in an unstable environment on amd64 without having network access. the build log shows errors like these, which go away if you have network connection. Hi, I couldn't reproduce this on my laptop disconnected from the internet. Please be more specific as to what you mean by no network access. I'm pretty sure those tests need access to localhost, and I'm not sure no localhost is a supported configuration for our build environment. It has been pointed out to me that pbuilder restricts access to the network during build by default. I retried the build with pbuilder, and it succeeded. Since version 0.215+nmu3, pbuilder establishes a new loopback interface after creating a new network namespace to isolate the chroot. I'll therefore close this bug as invalid. Thanks, -- Nicolas Dandrimont All language designers are arrogant. Goes with the territory... (By Larry Wall) signature.asc Description: Digital signature ---End Message---
Bug#757413: Processed: jessie
Holger Levsen hol...@layer-acht.org (2015-03-08): On Sonntag, 8. März 2015, Cyril Brulebois wrote: I'm not sure what your “AFAICS” covers. literally: as far as I can see... Based on what? I've already explained this code has been here for 10 years. People have already complained about this against wheezy. the impact is less severe on wheezy, again AFAIK. Based on what? Can we please try not to sweep it under the rug, and instead try to reproduce + fix it?! Making it not ring unneeded alarms is not sweeping it under the rug. That said, I'll leave the bug alone now. Who said they are unneeded? That's what I asked in my first reply. You didn't mention anything. And now you're tagging that bug report again, without any further explanations. Letting that bug report in a proper state means we have a chance that someone who cares actually investigates the wheezy situation instead of wild guessing. That means possibly landing a fix in wheezy. That's been my plan from the start, I'd appreciate not having to fight to keep the bug report in a suitable state… KiBi. signature.asc Description: Digital signature
Bug#779825: nginx-full: Unable to install nginx-full, does not get configured at end.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm not a maintainer but just tried to reproduce this issue on two different fresh headless systems and failed to do so. nginx-full has been installed successfully on multiple tries on debian unstable and debian testing. As test setup I used: a) An up-to-date, debootstraped system on an OpenVZ machine with kernel 2.6.32-042stab104.1. b) A up-to-date system inside VirtualBox which has been installed from an RC1-netinst media. For those both amd64 systems I've set the locale to en_IN to match yours. Have you made an aptitude update and aptitude safe-upgrade with non-CD sources before trying to install nginx? Also, are there any broken packages on your system? You can try detecting and fixing those by issuing: aptitude -f install. Have you already started another web server which has been bound to TCP port 80? You should stop any of those services beforehand. Bound ports can be seen by issuing sudo netstat -ntlp which also gives you the name of the service. Are there any related entries in /var/log/nginx/error.log? If the start script for nginx fails, there's probably some information in the error.log. Checking /var/log/syslog and /var/log/messages could give helpful messages as well. Regards Norbert Fischer -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJU/FCfAAoJEEqTSFSl09fQl8EQALdHsQVL2e+HcJiRCbOqqwsm daML52qO1kBD0tAod1lJnNqXuXAvf3uO+A+Opbx+mbv3LywsQMXubii3KD8K6ssc rkI8X0hHbJ168tacNKyw6ykCs4JjldjMGcTZEmmihbSXOaFF5+yzyW/GaGIpqIPl MdleuDi5t1pkzSYujSvGj5rFSdKfvEaEgnW7y1QBd77RCaF4fP948MVvVxTSROhu TFX4PBPoNI9I9zgpbYDkKJWUjVcaujGTncvyVj6a+5T/rC686JVLD49Hq7rnRyHM eCzz8VIB7SN8u34kMdh75V5qwv0KJc4mz1PoYlU/sOThooh+zGZl9U5T4by8fgoP 9kyG+EXie6QcKx17s1/N7Xhn/fIPp74HTJKjH7kZyivW8GqHshja6H/+DF5BiqGg K9cp81EJQ9MH5lPWIeRMrGoG1HUJ1h23894yyyBORo0WXqeV2pHYE4aWwE52Ai5O qWDsLidFKs0/Y3d2HENvHXBsw/6F70AN77CJdfmEFfHpdJq3sw0emfcB9HmkSEj4 WXtAXEtB+i7c+hl3RV0Mt0AX1G9+xT8FiWRgO2Fugmwv9YHaNyP/ve3k0PPnMIFx 0nfG02sqkZIqPP5rpiWGcXHfR4HksH3FQKzVm686U9sZomizKEHN4Akg7nVFFiG4 VLQZUzHL57jUKTjEC+hi =J5AA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779825: nginx-full: Unable to install nginx-full, does not get configured at end.
On Sun, Mar 8, 2015 at 7:07 PM, Norbert Fischer no...@nerdpol.org wrote:
Have you already started another web server which has been bound to
TCP port 80? You should stop any of those services beforehand. Bound
ports can be seen by issuing sudo netstat -ntlp which also gives you
the name of the service.
Look like this is the case with bug.
Shirish, can you check and revert back, please?
--
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757413: Processed: jessie
Holger Levsen hol...@layer-acht.org (2015-03-08): On Sonntag, 8. März 2015, Cyril Brulebois wrote: Again? No argumentation, so removing tags again. the bug shows up on http://udd.debian.org/bugs.cgi?release=wheezyrc=1sortby=idsorto=descctags=1 - and as thus gets on the radar of people caring about fixing RC bugs in stable and AFAICS this bug is not RC for wheezy. I'm not sure what your “AFAICS” covers. I've already explained this code has been here for 10 years. People have already complained about this against wheezy. Looking at bug reports whose title contains fstab lets you find some occurrences. Can we please try not to sweep it under the rug, and instead try to reproduce + fix it?! KiBi. signature.asc Description: Digital signature
Processed: tagging 779989
Processing commands for cont...@bugs.debian.org: tags 779989 + pending Bug #779989 [gdm3] invoke-rc.d: initscript gdm3, action reload failed. Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 779989: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779989 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779592: [apt] /var/lib/apt/lists/partial/ gets filled by Diff_index file
Control: fixed -1 1.1~exp4 Control: severity -1 normal Hi, On Mon, Mar 02, 2015 at 08:34:33PM +0100, Valerio Passini wrote: This bug it's tremendous: if in my source list there is this Debian mirror line: deb http://ftp.it.debian.org/debian/ experimental main contrib non-free; the directory /var/lib/apt/lists/partial/ is quickly filled by a Diff_index file growing at a 30MB/s rate until the partition is full. Quite obviously the next Well, I can't reproduce it here. Was the file really just called Diff_index? I presume it was: ftp.it.debian.org_debian_dists_experimental_main_binary-amd64_Packages.IndexDiff which is the filename for this file: http://ftp.it.debian.org/debian/dists/experimental/main/binary-amd64/Packages.diff/Index boot is going to fail for the lack of disk space. I can't understand if this bug it's in the mirror or in apt, but it's quite annoying and should really be fixed ASAP. Best regards There isn't much we can do about it at the moment. apt/stretch (not jessie!) will know (most) filesizes in advance and check that it isn't getting feed too much, but that is just preventing bad sympthoms to appear (= full disk), it isn't a solution for the (unknown) initial problem. Could be a misbehaving proxy (do you have one?), a misbehaving server, your ISP (via a misbehaving proxy) or any classic man-in-the-middle really. Hard to know without details. Can you even reproduce it? I am not fully closing this bug as fixed in future version just yet because I would like to understand what is going on here in case we can do anything about it (further) to prevent this from happening, but I am downgrading drastically as this isn't a new issue (= always possible in all versions of apt), apt isn't made unusuable by it, we are not loosing any data (well, with a fulldisk we potentially are, but that is the bug of other tools not handling this case) and its not opening a security hole. So neither of the reasons for 'grave' apply here and hence not release critical. Best regards David Kalnischkies signature.asc Description: Digital signature
Processed: Re: Bug#779592: [apt] /var/lib/apt/lists/partial/ gets filled by Diff_index file
Processing control commands: fixed -1 1.1~exp4 Bug #779592 [apt] [apt] /var/lib/apt/lists/partial/ gets filled by Diff_index file Marked as fixed in versions apt/1.1~exp4. severity -1 normal Bug #779592 [apt] [apt] /var/lib/apt/lists/partial/ gets filled by Diff_index file Severity set to 'normal' from 'grave' -- 779592: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757413: Processed: jessie
Hi, On Sonntag, 8. März 2015, Cyril Brulebois wrote: I'm not sure what your “AFAICS” covers. literally: as far as I can see... I've already explained this code has been here for 10 years. People have already complained about this against wheezy. the impact is less severe on wheezy, again AFAIK. Can we please try not to sweep it under the rug, and instead try to reproduce + fix it?! Making it not ring unneeded alarms is not sweeping it under the rug. That said, I'll leave the bug alone now. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#769797: marked as done (gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2)
Your message dated Sun, 08 Mar 2015 13:18:17 +0100 with message-id 54fc3e09.9070...@debian.org and subject line Re: Bug#769797: marked as done (gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2) has caused the Debian Bug report #769797, regarding gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 769797: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769797 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Source: gnat-4.9 Version: 4.9.1-4 Severity: serious The Build-Depends for gnat-4.9 cannot be satisfied in current unstable because they include gcc-4.9-source ( 4.9.2). -- Daniel Schepler ---End Message--- ---BeginMessage--- Version: 4.9.2-1 On 03/05/2015 11:19 PM, Ivo De Decker wrote: Since the last britney run, gcc-4.9 4.9.2-10 is in testing, so now gnat-4.9 needs an update as well. 4.9.2-1 is in unstable, needs an unblock.---End Message---
Bug#778655: doxygen: Doxygen should not enable markdown by default
Control: severity -1 important no feedback, based on Helmuts analysis, this doesn't look release critical. On 02/18/2015 08:58 PM, Helmut Grohne wrote: Control: tags -1 + moreinfo Hi Ron, Duplicating a bit of our discussion here for keeping track of it. On Wed, Feb 18, 2015 at 09:58:25AM +1030, Ron wrote: So doxygen 1.8 added support for interpreting markdown, and it does this in all normal comment blocks before applying the normal doxygen formatting. Unfortunately, they also chose to enable this by default, so any package that is building docs against this version, which didn't update the doxyconf configuration using this version, to see that this option exists and to turn it off if it breaks the generated documentation, is going to run a fairly high chance of generating fairly horribly broken docs. A quick canary for the extent of this problem is to search for: 'warning: unexpected command endcode' Which went by uncommented on (or I assume inspected) in logs such as was posted to https://bugs.debian.org/680896 and many other places. This is just one fairly common way this fails horribly, resulting in all the comments *above* a @code section being treated as code, and the code section itself being dumped literally to the output - but there are quite a few other ways this will generate awful unreadable documentation when markdown syntax is inadvertently applied to an existing codebase. Thanks for reporting this. I was not aware! Unless we want to ship with a lot of fairly useless -doc packages, it seems like this should probably be disabled by default, until people have become more aware of the problem and have taken steps to avoid it in their own source. I found a lot of build logs that show people having this problem, but no discussion of the cause, the impact, or the fix. I suspect a lot of people who build -doc packages rarely or never actually read them themselves ... Flipping the default of MARKDOWN_SUPPORT in Debian won't happen for the following reasons: * Deviating from upstream is bad. Of course, this means that convincing upstream to change the default necessitates revisiting this decision. * Changing this in the doxygen package won't fix any documentation: I don't expect many packages to be uploaded after a doxygen upload and binNMUs cannot be used as most documentation resides in arch:all packages. Thus it should be easier to just fix build-rdeps of doxygen. Fixing the ones that are already broken is probably going to be something of a major operation in its own right, but the mood in #d-d seemed to be that we should start by limiting the damage here and then tackle that part separately. And this is where the moreinfo tag comes into place: The information of which packages actually are broken is missing entirely. Before this bug becomes actionable in any way, the purported damage needs to be understood. Please remove the moreinfo tag when adding an affected jessie package and explaining how it is affected. Let me add a few hints on which packages to look for. The following packages set MARKDOWN_SUPPORT=NO: hdf5 hwloc libsbml mpich openms ppl simbody witty The following packages set MARKDOWN_SUPPORT=YES: ace apophenia apt aubio bladerf boost1.54 boost1.55 casablanca clipper cmocka colobot cpl csound cupt eigen3 elektra exiv2 feel++ fflas-ffpack freecontact gazebo gdcm geographiclib givaro glfw3 gnuradio gr-fcdproplus grass gtkspellmm imagemagick libam7xxx libburn libcaca libclaw libdatrie libdebian-installer libevdev libhmsbeagle liblo libltc libopendbx libreoffice libsdl2-gfx libsidplayfp libssh libstxxl libthai linbox litl lvtk lxc mysql-workbench ns3 ogre-1.9 openmprtl orthanc pcl psocksxx python-odf qof rapidjson rivet schroot sdformat serd simgrid sord speech-tools sratom ui-gxmlcpp ui-utilcpp v4l-utils visp vlfeat websocketpp The vast majority of build-rdeps of doxygen or doxygen-latex appear to not set MARKDOWN_SUPPORT at all. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779468: apt-spy: creates an invalid sources list
On 1 March 2015 at 18:27, Vagrant Cascadian vagr...@debian.org wrote: On 2015-02-28, Manolo Díaz wrote: Also, it fails to update the mirror list due the the lack of http://http.us.debian.org/debian/README.mirrors.txt I think this is the main source of the problem. It seems that the mirrors no longer include README.mirrors.txt, and apt-spy needs to be patched to parse https://www.debian.org/mirror/list, which is in html format. Not sure how invasive that will be. FWIW, the data source used to build this list is in the VCS (but I wouldn’t bet on any stability from an URL on alioth): https://anonscm.debian.org/viewvc/webwml/webwml/english/mirror/Mirrors.masterlist?view=co Regards David signature.asc Description: Digital signature
Bug#759530: Patch to fix segfault in ldconfig
On Sun, Mar 08, 2015 at 09:48:50PM +0100, Aurelien Jarno wrote:
Thanks for your work, it's nice we have been able to understand the real
issue.
Well I thing the best summary of the problem is that the aux-cache
handling code is awful and doesn't check anything before using the
incoming data as a source for pointers. Corrupt aux-cache files was
not even remotely considered. Safest option right now would be to disable
the use of the aux-cache if you want to avoid segfaults in ldconfig.
Unfortunately they doesn't seem to work here. That said I have been able
to reproduce the problem by truncating/changing the aux cache manually.
Well it segfaulted on my amd64 system when I tried that file. Of course
it may need to have the same set of libraries installed as I have.
I think the idea behind the patch is correct, but it is not fully
correct (or at least it only fixes corner cases).
I don't doubt I missed some of the problem cases. Seems the best answer
would be to redesign it with a checksum and a size indicator or something
else that would catch corruption in general.
diff -ur --exclude debian --exclude build-tree glibc-2.19.ori/elf/cache.c
glibc-2.19/elf/cache.c
--- glibc-2.19.ori/elf/cache.c 2015-02-25 16:24:59.0 +
+++ glibc-2.19/elf/cache.c 2015-02-25 17:42:18.0 +
@@ -699,7 +699,8 @@
if (aux_cache == MAP_FAILED
|| aux_cache_size sizeof (struct aux_cache_file)
|| memcmp (aux_cache-magic, AUX_CACHEMAGIC, sizeof AUX_CACHEMAGIC -
1)
- || aux_cache-nlibs = aux_cache_size)
+ || sizeof(struct aux_cache_file) + (aux_cache-nlibs - 1) *
sizeof(struct aux_cache_file_entry) = aux_cache_size
Why using (aux_cache-nlibs - 1) and not directly aux_cache-nlibs here?
Hmm, I seem to have misread the way the structure is defined, and thought
it always had one aux_cache_file_entry in the aux_cache_file struct,
but no it has 0 of them.
+ || aux_cache-nlibs * sizeof(struct aux_cache_file_entry) +
aux_cache-libs[aux_cache-nlibs - 1].soname = aux_cache_size)
The best to catch all cases here is to compute the theoretical size of
the file using the headers and comparing it to the real one.
Well the filenames seem to be just stored at the end of the other data
with pointers to it (which is where most of the chances for segfaults
occur). The format doesn't seem to actually have anything to cover the
size of that pile of strings. There is really no way to know what the
filesize should be given the end is just a heap of c strings. Did I
miss something? You seem to be using anpother header thing that mentions
the string lengths. Maybe I missed that existing. That would be useful.
{
close (fd);
init_aux_cache ();
@@ -712,12 +713,14 @@
const char *aux_cache_data
= (const char *) aux_cache-libs[aux_cache-nlibs];
for (unsigned int i = 0; i aux_cache-nlibs; ++i)
-insert_to_aux_cache (aux_cache-libs[i].id,
-aux_cache-libs[i].flags,
-aux_cache-libs[i].osversion,
-aux_cache-libs[i].soname == 0
-? NULL : aux_cache_data + aux_cache-libs[i].soname,
-0);
+/* Only use entries with sane offsets */
+if (aux_cache-libs[i].soname aux_cache_size)
The check is incorrect here, the address in aux_cache-libs[i].soname is
relative to aux_cache_data, so it probably catches very few cases.
Well it catches any where the offset is corrupt by a larger value
(doesn't have to be that large either). But yes I did get that check
slightly wrong. I think I changed it a few times while working out what
the code was trying to do with the data structure.
+ insert_to_aux_cache (aux_cache-libs[i].id,
+ aux_cache-libs[i].flags,
+ aux_cache-libs[i].osversion,
+ aux_cache-libs[i].soname == 0
+ ? NULL : aux_cache_data + aux_cache-libs[i].soname,
+ 0);
munmap (aux_cache, aux_cache_size);
close (fd);
Please find a new patch below. I have submitted it upstream as bz 18093.
I am planning to wait for upstream answer or comment for other people a
few days. I'll then prepare an upload fixing this bug.
diff --git a/ChangeLog b/ChangeLog
index 4a5cd16..5086267 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2015-03-08 Aurelien Jarno aurel...@aurel32.net
+
+ [BZ #18093]
+ * elf/cache.c (load_aux_cache): Regenerate the cache if it has the
+ wrong size. Ignore entries pointing outside of the mmaped memory.
+
2015-03-08 Paul Pluzhnikov ppluzhni...@google.com
[BZ #16734]
diff --git a/elf/cache.c b/elf/cache.c
index 1732268..9131e08 100644
--- a/elf/cache.c
+++ b/elf/cache.c
@@ -698,7 +698,9 @@ load_aux_cache (const char *aux_cache_name)
if (aux_cache == MAP_FAILED
|| aux_cache_size
Processed: Fixing versions for #779662
Processing commands for cont...@bugs.debian.org:
notfound 779662 fedmsg-meta-fedora-infrastructure/0.2.18-1
Bug #779662 {Done: Nicolas Dandrimont ol...@debian.org}
[src:fedmsg-meta-fedora-infrastructure] package fails to build without network
connection
No longer marked as found in versions
fedmsg-meta-fedora-infrastructure/0.2.18-1.
fixed 779662 fedmsg-meta-fedora-infrastructure/0.2.18-1
Bug #779662 {Done: Nicolas Dandrimont ol...@debian.org}
[src:fedmsg-meta-fedora-infrastructure] package fails to build without network
connection
Marked as fixed in versions fedmsg-meta-fedora-infrastructure/0.2.18-1.
thanks
Stopping processing here.
Please contact me if you need assistance.
--
779662: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779662
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779865: marked as done (ulogd2: removal of old initscript does not work)
Your message dated Sun, 08 Mar 2015 15:49:44 + with message-id e1yudsa-oz...@franck.debian.org and subject line Bug#779865: fixed in ulogd2 2.0.4-2 has caused the Debian Bug report #779865, regarding ulogd2: removal of old initscript does not work to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 779865: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779865 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: ulogd2 Version: 2.0.4-1 Severity: serious Tags: patch User: debian...@lists.debian.org Usertags: piuparts Hi, the removal of /etc/init.d/ulogd does not work as intended since dpkg-maintscript-helper rm_conffile does not work upon initial installation (upon upgrading from ulogd to ulogd2 the ulogd2 package will be installed for the first time) unless tricked into believing this is an upgrade instead of an initial install. = patch 0001 While we are at it, perform some more removal of obsolete conffiles in the transitional ulogd package = patch 0002 While the second patch duplicates the actions of the first, the first one is important for cases where the ulogd package was already removed (but not purged) but it's problematic initscript is still sitting around. The second just ensures an even smoother experience if the transitional ulogd package is installed. Severity serious since * your maintscript comment said as it can cause problems/confusion * I already had to dig into several failing upgrade paths involving obsolete initscripts and changes in the things they provide ... with nontrivial recovery paths. (I didn't manage to run into failures with ulogd/ulogd2, yet, maybe I didn't try hard enough. :-) Andreas From 8688648c4cedc7f2cc4478279b071de42e518522 Mon Sep 17 00:00:00 2001 From: Andreas Beckmann a...@debian.org Date: Thu, 5 Mar 2015 18:32:43 +0100 Subject: [PATCH 1/2] fix removal of old ulogd initscript upon initial installation of ulogd2 --- debian/changelog | 6 ++ debian/ulogd2.maintscript | 4 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 716e6f5..c5cd521 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +ulogd2 (2.0.4-2) UNRELEASED; urgency=medium + + * Fix removal of old ulogd initscript upon initial installation of ulogd2. + + -- Andreas Beckmann a...@debian.org Wed, 04 Mar 2015 21:54:40 +0100 + ulogd2 (2.0.4-1) unstable; urgency=medium * New upstream release: diff --git a/debian/ulogd2.maintscript b/debian/ulogd2.maintscript index 02c899b..efcdeba 100644 --- a/debian/ulogd2.maintscript +++ b/debian/ulogd2.maintscript @@ -1,4 +1,6 @@ # Remove the old ulogd 1.x init script, as it can cause problems/confusion -rm_conffile /etc/init.d/ulogd 2.0.2-4~ ulogd +# Provide a fall-back old-version (0) as a hack to ensure this is performed +# by dpkg-maintscript-helper on the initial install of ulogd2, too. +rm_conffile /etc/init.d/ulogd 2.0.4-2~ ulogd -- $@ 0 -- 2.1.4 From c5ce5e12d260d6539e75785d6ab9e34fb1baa89b Mon Sep 17 00:00:00 2001 From: Andreas Beckmann a...@debian.org Date: Thu, 5 Mar 2015 19:01:45 +0100 Subject: [PATCH 2/2] remove obsolete /etc/logrotate.d/ulogd, too --- debian/changelog | 1 + debian/ulogd.maintscript | 2 ++ 2 files changed, 3 insertions(+) create mode 100644 debian/ulogd.maintscript diff --git a/debian/changelog b/debian/changelog index c5cd521..c8defe1 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,7 @@ ulogd2 (2.0.4-2) UNRELEASED; urgency=medium * Fix removal of old ulogd initscript upon initial installation of ulogd2. + * Remove more obsolete conffiles. -- Andreas Beckmann a...@debian.org Wed, 04 Mar 2015 21:54:40 +0100 diff --git a/debian/ulogd.maintscript b/debian/ulogd.maintscript new file mode 100644 index 000..cc65a1b --- /dev/null +++ b/debian/ulogd.maintscript @@ -0,0 +1,2 @@ +rm_conffile /etc/init.d/ulogd 2.0.4-2~ +rm_conffile /etc/logrotate.d/ulogd 2.0.4-2~ -- 2.1.4 ---End Message--- ---BeginMessage--- Source: ulogd2 Source-Version: 2.0.4-2 We believe that the bug you reported is fixed in the latest version of ulogd2, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 779...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Chris Boot deb...@bootc.net (supplier of updated ulogd2
Bug#779048: libjpeg-turbo: Migration of jpeg-progs from Wheezy to Jessie
Hi Niels,
what if I just do:
Package: libjpeg62-turbo
[...]
Conflicts: libjpeg-progs ( 2:0), libjpeg-progs ( 1:0)
(or more precise Conflicts: libjpeg-progs ( ${binary:Version},
libjpeg-progs ( ${binary:Version})
That should push libjpeg-progs from other sources out
Cheers,
Ondrej
On Sun, Mar 8, 2015, at 16:42, Niels Thykier wrote:
On 2015-03-07 14:24, Ondřej Surý wrote:
Hi Niels,
Hi,
:)
was src:libjpeg9 ever part of jessie? E.g. should I bump epoch on the
upload?
I believe Simon covered this one.
Also do you think I should fill bug on libjpeg9 asking maintainer to
rename libjpeg-progs to (f.e.) libjpeg9-progs to have a plan for
jessie+1?
Honestly, I think it is best if only changed libjpeg-turbo at this
point. At least, I suspect that is the least controversial solution and
also the fastest one to implement.
Mind you, I assume here that this is in fact possible without actually
having looked at the technical details.
I do certainly not mind if it takes an upload testing-proposed-update,
if we can solve it that way.
Sorry it took so long, I almost forgot about this.
Cheers,
Ondrej
Don't worry and thanks for picking it up again, :)
~Niels
--
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775913: marked as done (vala-0.26: CVE-2014-8154: Heap-buffer overflow in vala-gstreamer bindings at Gst.MapInfo())
Your message dated Sun, 08 Mar 2015 16:21:03 + with message-id e1yudwt-0005bu...@franck.debian.org and subject line Bug#775913: fixed in vala-0.26 0.26.1-1.1 has caused the Debian Bug report #775913, regarding vala-0.26: CVE-2014-8154: Heap-buffer overflow in vala-gstreamer bindings at Gst.MapInfo() to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 775913: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775913 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Source: vala-0.26 Version: 0.26.1-1 Severity: grave Tags: security upstream patch fixed-upstream Control: fixed -1 0.26.2-1 Hi, the following vulnerability was published for vala-0.26. CVE-2014-8154[0]: Heap-buffer overflow in vala-gstreamer bindings at Gst.MapInfo() If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2014-8154 [1] https://git.gnome.org/browse/vala/commit/?id=3092537db65887e24a3d3e87a27caf9c5295e4f7 [2] https://bugzilla.gnome.org/show_bug.cgi?id=678663 [3] https://bugzilla.novell.com/show_bug.cgi?id=913071 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1181404 Regards, Salvatore ---End Message--- ---BeginMessage--- Source: vala-0.26 Source-Version: 0.26.1-1.1 We believe that the bug you reported is fixed in the latest version of vala-0.26, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 775...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. gregor herrmann gre...@debian.org (supplier of updated vala-0.26 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 06 Mar 2015 16:58:06 +0100 Source: vala-0.26 Binary: valac valac-0.26 valac-0.26-vapi vala-0.26-doc libvala-0.26-0 libvala-0.26-dev valac-0.26-dbg libvala-0.26-0-dbg Architecture: source all amd64 Version: 0.26.1-1.1 Distribution: unstable Urgency: medium Maintainer: Maintainers of Vala packages pkg-vala-maintain...@lists.alioth.debian.org Changed-By: gregor herrmann gre...@debian.org Description: libvala-0.26-0 - C# like language for the GObject system - library libvala-0.26-0-dbg - C# like language for the GObject system - library symbols libvala-0.26-dev - C# like language for the GObject system - development headers vala-0.26-doc - C# like language for the GObject system - documentation valac - C# like language for the GObject system valac-0.26 - C# like language for the GObject system valac-0.26-dbg - C# like language for the GObject system - debug symbols valac-0.26-vapi - C# like language for the GObject system - vapi files Closes: 775913 Changes: vala-0.26 (0.26.1-1.1) unstable; urgency=medium . * Non-maintainer upload. * Fix CVE-2014-8154: Heap-buffer overflow in vala-gstreamer bindings at Gst.MapInfo(): add patch mapinfo.date-array-length.patch, taken from upstream git: https://git.gnome.org/browse/vala/commit/?id=22126ebad3b2133db39bcf301c29c8b78b440f1a (Closes: #775913) Checksums-Sha1: 5c2107b70f8a3974e39d75bc5e32b9465669f649 2825 vala-0.26_0.26.1-1.1.dsc 8ae9e0649dc27eab3d64e80addc7e8f57afbe09d 24056 vala-0.26_0.26.1-1.1.debian.tar.xz afda298215c3cdd19f11d746f8cf67bcd4011f4d 146332 valac_0.26.1-1.1_all.deb 2f863efb72b2759fa1bd1a93936fc6d84ed8c9b6 813914 valac-0.26-vapi_0.26.1-1.1_all.deb 5e29ea2683d64f6bacaec9aaadf3bc177588bdc4 153472 vala-0.26-doc_0.26.1-1.1_all.deb Checksums-Sha256: c731322e9ce269444b49e961742e9d8f8e00fac7a6892bce1d33fcd8890012b1 2825 vala-0.26_0.26.1-1.1.dsc ece03d323b4613b2aff0e6e0c3957f036e1c31aa66961ece32aff054897b72f5 24056 vala-0.26_0.26.1-1.1.debian.tar.xz 5dcbd338d101776e9082ca6c0adf30b5f0e3e7207d4b0102aaa80a97b6d2436e 146332 valac_0.26.1-1.1_all.deb 9d1b98e3c16e0e7e0bbc520fbc105f51c59de3776b80b71aa55f2b0183960d92 813914 valac-0.26-vapi_0.26.1-1.1_all.deb af14f1dc04e56f6ac007e11517ac5adee801fbdcba088dd565b77c487676ea5e 153472 vala-0.26-doc_0.26.1-1.1_all.deb Files: 9acdc177e6e7e8c2638bfebda3aa6d15 2825 devel optional vala-0.26_0.26.1-1.1.dsc ff528ec6223f24122db03f0ec574a451 24056 devel optional
Bug#779048: libjpeg-turbo: Migration of jpeg-progs from Wheezy to Jessie
On Sat, 07 Mar 2015 at 14:24:32 +0100, Ondřej Surý wrote: was src:libjpeg9 ever part of jessie? E.g. should I bump epoch on the upload? https://tracker.debian.org/pkg/libjpeg9 [2014-10-17] libjpeg9 1:9a-2 MIGRATED to testing (Britney) and that version's Changes say: libjpeg9 (1:9a-2) unstable; urgency=low . * Build libjpeg-progs * debian/control: - Bump standard version to 3.9.5. * Bump epoch to recover from libjpeg-turbo hijacking of libjpeg-progs. So yes, libjpeg-progs/1:9a-2 existed in jessie in the past. S -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779985: marked as done (libwww-youtube-download-perl: youtube-videos fail to download)
Your message dated Sun, 08 Mar 2015 15:34:44 + with message-id e1yude4-0006pz...@franck.debian.org and subject line Bug#779985: fixed in libwww-youtube-download-perl 0.56-2 has caused the Debian Bug report #779985, regarding libwww-youtube-download-perl: youtube-videos fail to download to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 779985: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779985 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: libwww-youtube-download-perl Version: 0.56-1 Severity: important Dear Maintainer, say I want to download, that video of motherfucking LADY GAGA: andrew@s5:~$ youtube-download https://www.youtube.com/watch?v=ohs0a-QnFF4 garbage after JSON object, at character offset 33125 (before ;ytplayer.load = fun...) at /usr/share/perl5/WWW/YouTube/Download.pm line 226. andrew@s5:~$ It does not work, it is most probably due to Youtube's transition from Flash videos to HTML5. In my opinion, if it is not easy to fix the problem, it is safer to leave the package out of Jessie, when it is going to be released. It does not make sense to keep it in, when it is not workable anymore, because of changes to that webservice, which will not be rolled back again. - -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.7-ckt4ckead (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libwww-youtube-download-perl depends on: ii libhtml-parser-perl 3.71-1+b3 ii libjson-perl 2.61-1 ii liburi-perl 1.64-1 ii libwww-perl 6.08-1 ii libxml-treepp-perl 0.39-1 ii perl 5.20.2-2 libwww-youtube-download-perl recommends no packages. libwww-youtube-download-perl suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlT7FxgACgkQ5+rBHyUt5wuznQCeN7wc7T2j7/En9YmcRNFB0ycR +OEAoJlQEDyxd8c1wA0AWeESOIz/Am58 =HU0B -END PGP SIGNATURE- ---End Message--- ---BeginMessage--- Source: libwww-youtube-download-perl Source-Version: 0.56-2 We believe that the bug you reported is fixed in the latest version of libwww-youtube-download-perl, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 779...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. gregor herrmann gre...@debian.org (supplier of updated libwww-youtube-download-perl package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 08 Mar 2015 15:35:00 +0100 Source: libwww-youtube-download-perl Binary: libwww-youtube-download-perl Architecture: source all Version: 0.56-2 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: gregor herrmann gre...@debian.org Description: libwww-youtube-download-perl - module for downloading video from YouTube Closes: 779985 Changes: libwww-youtube-download-perl (0.56-2) unstable; urgency=medium . * Add 2 small patches from Github to adjust to YouTube changes. . Patches are taken from PR#31 in issue #27 at https://github.com/xaicron/p5-www-youtube-download/issues/27 . (Closes: #779985) Checksums-Sha1: 3e4bc8d59e7a6447bf9a229a06ce0211bb1d37ea 2537 libwww-youtube-download-perl_0.56-2.dsc f6c4bffdc7fec37e498fa45d3bfddbaf912dd9ae 4032 libwww-youtube-download-perl_0.56-2.debian.tar.xz 3668acc3c7a0efa6d62e98b1bb856adfd803d44b 23546 libwww-youtube-download-perl_0.56-2_all.deb Checksums-Sha256: 561bc3821f16a69a7d577c0e0b1a481c07e09165aad9b8e74416bae564508ced 2537 libwww-youtube-download-perl_0.56-2.dsc f6138752af400498f5919db8193ccc0b63a035c0588707de5ee33d664a510445 4032 libwww-youtube-download-perl_0.56-2.debian.tar.xz e5b58281493d025583c9fe07e5e5c53904231c69f4c2ee6f8765421da27836c6 23546 libwww-youtube-download-perl_0.56-2_all.deb Files: 833fec7472753d733559170adb403eba 2537 perl optional
Bug#779989: marked as done (invoke-rc.d: initscript gdm3, action reload failed.)
Your message dated Sun, 08 Mar 2015 15:34:20 + with message-id e1yuddg-0006j0...@franck.debian.org and subject line Bug#779989: fixed in gdm3 3.14.1-5 has caused the Debian Bug report #779989, regarding invoke-rc.d: initscript gdm3, action reload failed. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 779989: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779989 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: gdm3 Version: 3.14.1-4 Severity: normal When upgrading to the most recent version: Setting up gdm3 (3.14.1-4) ... Job for gdm.service failed. See 'systemctl status gdm.service' and 'journalctl -xn' for details. invoke-rc.d: initscript gdm3, action reload failed. From the journal: Mar 07 10:17:42 thin systemd[1]: Failed to load environment files: No such file or directory Mar 07 10:17:42 thin systemd[1]: gdm.service failed to run 'reload' task: No such file or directory Mar 07 10:17:42 thin systemd[1]: Reload failed for GNOME Display Manager. -- Subject: Unit gdm.service has finished reloading its configuration -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit gdm.service has finished reloading its configuration -- -- The result is failed. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.19.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gdm3 depends on: ii accountsservice 0.6.37-3+b1 ii adduser 3.113+nmu3 ii dconf-cli 0.22.0-1 ii dconf-gsettings-backend 0.22.0-1 ii debconf [debconf-2.0] 1.5.55 ii gir1.2-gdm3 3.14.1-4 ii gnome-session [x-session-manager] 3.14.0-2 ii gnome-session-bin 3.14.0-2 ii gnome-settings-daemon 3.14.2-2 ii gnome-shell 3.14.2-3+b1 ii gnome-terminal [x-terminal-emulator] 3.14.1-1 ii gsettings-desktop-schemas 3.14.1-1 ii libaccountsservice0 0.6.37-3+b1 ii libaudit1 1:2.4-1+b1 ii libc6 2.19-15 ii libcanberra-gtk3-00.30-2.1 ii libcanberra0 0.30-2.1 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libgdm1 3.14.1-4 ii libglib2.0-0 2.42.1-1 ii libglib2.0-bin2.42.1-1 ii libgtk-3-03.14.5-1 ii libpam-modules1.1.8-3.1 ii libpam-runtime1.1.8-3.1 ii libpam-systemd215-12 ii libpam0g 1.1.8-3.1 ii librsvg2-common 2.40.5-1 ii libselinux1 2.3-2 ii libsystemd0 215-12 ii libwrap0 7.6.q-25 ii libx11-6 2:1.6.2-3 ii libxau6 1:1.0.8-1 ii libxdmcp6 1:1.1.1-1+b1 ii libxrandr22:1.4.2-1+b1 ii lsb-base 4.1+Debian13+nmu1 ii metacity [x-window-manager] 1:3.14.3-1 ii mutter [x-window-manager] 3.14.2-1 ii policykit-1 0.105-8 ii ucf 3.0030 ii x11-common1:7.7+7 ii x11-xserver-utils 7.7+3+b1 Versions of packages gdm3 recommends: ii at-spi2-core 2.14.0-1 ii desktop-base 8.0.2 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii x11-xkb-utils 7.7+1 ii xserver-xephyr 2:1.16.4-1 ii xserver-xorg 1:7.7+7 ii zenity 3.14.0-1 Versions of packages gdm3 suggests: ii gnome-orca3.14.0-4 ii libpam-gnome-keyring 3.14.0-1+b1 -- Configuration Files: /etc/gdm3/daemon.conf changed: [daemon] AutomaticLoginEnable=True AutomaticLogin=josh [security] [xdmcp] [greeter] [chooser] [debug] -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3 ---End Message--- ---BeginMessage--- Source: gdm3 Source-Version: 3.14.1-5 We believe that the bug you reported is
Bug#779048: libjpeg-turbo: Migration of jpeg-progs from Wheezy to Jessie
On 2015-03-07 14:24, Ondřej Surý wrote: Hi Niels, Hi, :) was src:libjpeg9 ever part of jessie? E.g. should I bump epoch on the upload? I believe Simon covered this one. Also do you think I should fill bug on libjpeg9 asking maintainer to rename libjpeg-progs to (f.e.) libjpeg9-progs to have a plan for jessie+1? Honestly, I think it is best if only changed libjpeg-turbo at this point. At least, I suspect that is the least controversial solution and also the fastest one to implement. Mind you, I assume here that this is in fact possible without actually having looked at the technical details. I do certainly not mind if it takes an upload testing-proposed-update, if we can solve it that way. Sorry it took so long, I almost forgot about this. Cheers, Ondrej Don't worry and thanks for picking it up again, :) ~Niels -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776746: gnome-session: GNOME crashes during a remote desktop access
retitle 776746 gnome-session: Oh no! Something has gone wrong when Composite extension is absent from X server On Sun, 01 Feb 2015 at 14:58:10 +0800, GGaotx wrote: Suppose you installed GNOME as default DE and also with xrdp installed, when trying to use another computer to visit it by remote access(RDP or VNC),then GNOME crashes: Oh, no! Something has gone wrong. Nothing is actually crashing, although the user-visible symptom is the same. Steps to reproduce: * install jessie with only the GNOME desktop (I used a virtual machine) * apt-get install xrdp * connect an RDP client to the machine (I used Vinagre) * accept the default Module, sesman-Xvnc; enter a valid username and password, e.g. the one created by the installer You get the Oh no! screen as described. ~/.xsession-errors indicates why: Xsession: X session started for at Sun 8 Mar 16:27:54 GMT 2015 X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 109 (X_ChangeHosts) Value in failed request: 0x5 Serial number of failed request: 6 Current serial number in output stream: 8 localuser:smcv being added to access control list openConnection: connect: No such file or directory cannot connect to brltty at :0 gnome-session-is-accelerated: No composite extension. gnome-session-check-accelerated: Helper exited with code 256 gnome-session-is-accelerated: No composite extension. gnome-session-check-accelerated: Helper exited with code 256 ** (process:2235): WARNING **: software acceleration check failed: Child process exited with code 1 GNOME Shell is a compositing window manager. It requires the Composite extension, and cannot operate on a display that does not have it, regardless of whether it is provided by software rendering or 3D hardware or what. If Xvnc does not have that extension then GNOME Shell cannot work. There are several bugs here. IMO none of them is really RC: * gnome-session should put different text on the oh no! message if the problem is really your X server is not sufficiently capable to run GNOME * xrdp should allow session-selection, so remote users can select a non-compositing environment like LXDE or XFCE even if GNOME is the default * xrdp, or whatever Xserver it uses behind the scenes (Xvnc?), should support the Composite extension When trying to use MATE as default DE, it works as it should. mate's window manager is marco, which I think is a fork of GNOME 2's Metacity. Metacity is *optionally* a compositing window manager, but can also run as a traditional non-compositing window manager, so the absence of the Composite extension is non-fatal Cinnamon also crashes, but soft rendering works. cinnamon's (default?) window manager is muffin, which I believe is a fork of mutter, a compositing window manager which does not support non-composited operation (GNOME Shell uses Mutter libraries for its window-manager and compositing-manager functionality). S -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779048: libjpeg-turbo: Migration of jpeg-progs from Wheezy to Jessie
On 2015-03-08 16:47, Ondřej Surý wrote:
Hi Niels,
what if I just do:
Package: libjpeg62-turbo
[...]
Conflicts: libjpeg-progs ( 2:0), libjpeg-progs ( 1:0)
(or more precise Conflicts: libjpeg-progs ( ${binary:Version},
libjpeg-progs ( ${binary:Version})
That should push libjpeg-progs from other sources out
Cheers,
Ondrej
[...]
Seems reasonable at first glance. Can you upload that to tpu (with a
no-change upload to sid to ensure the tpu version is = than sid)?
That way we force Wheezy (and testing) to force migrate into turbo
without breaking co-installability with libjpeg's progs (and therefore
avoid any political fall-out with other interested parties).
It will leave unstable users with the current progs. However, I
consider that less of a problem, given they can pull updates to that
implementation via unstable (unlike pure Jessie users).
Thanks,
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
