Bug#781710: nodejs FTBFS in jessie. test-crypto-stream.js fails (again)
Control: tags -1 reproducible On 01/04/15 23:47, peter green wrote: Package: nodejs Severity: serious Version: 0.10.29~dfsg-1.1 nodejs is failing to build with failure of the test test-crypto-stream.js [...] It happens on x64 as well. Tomasz signature.asc Description: Digital signature
Bug#781710: nodejs FTBFS in jessie. test-crypto-stream.js fails (again)
On 06/04/15 16:34, Jérémy Lal wrote:
Hello,
[...]
Hi,
consider this patch. The actual error string is:
TypeError: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
decrypt
In the patch I hook into human readable part, not into the hexadecimal
error code. I don't know how the test passed before! The test expected
error code...
Tomasz
From d153634ea8daddf0f7b1074202357a0f3c8e309a Mon Sep 17 00:00:00 2001
From: Tomasz Buchert tom...@debian.org
Date: Mon, 6 Apr 2015 17:20:46 +0200
Subject: [PATCH] Fix crypto-stream test
---
test/simple/test-crypto-stream.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/simple/test-crypto-stream.js b/test/simple/test-crypto-stream.js
index 402761e..e434aad 100644
--- a/test/simple/test-crypto-stream.js
+++ b/test/simple/test-crypto-stream.js
@@ -70,7 +70,7 @@ var key = new Buffer('48fb56eb10ffeb13fc0ef551bbca3b1b', 'hex'),
cipher.pipe(decipher)
.on('error', common.mustCall(function end(err) {
-assert(/::/.test(err));
+assert(/EVP_DecryptFinal_ex:bad decrypt/.test(err));
}));
cipher.end('Papaya!'); // Should not cause an unhandled exception.
--
2.1.4
signature.asc
Description: Digital signature
Bug#781710: nodejs FTBFS in jessie. test-crypto-stream.js fails (again)
Eh, it was fixed upstream: https://github.com/joyent/node/blob/master/test/simple/test-crypto-stream.js Tomasz signature.asc Description: Digital signature
Bug#781835: ruby-sourcify: raises NoMethodError: undefined method `[]' for nil:NilClass
Package: ruby-sourcify
Version: 0.5.0-2
Severity: important
Hi,
the version in Debian cannot sourcify the following, rather trivial code:
require 'sourcify'
l = lambda {puts Hi!}
puts l.to_source
(see https://github.com/ngty/sourcify/issues/28)
It seems that it is triggered by the quotes in the lambda: if you replace
them with single quotes, it seems to be just fine. As double quotes are often
used, this is a major drawback. Please consider making this bug RC for this
reason.
Tomasz
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ruby-sourcify depends on:
ii ruby 1:2.1.5
ii ruby-file-tail1.1.0-1
ii ruby-parser 3.6.2-1
ii ruby-ruby2ruby2.0.7-1
ii ruby-sexp-processor 4.4.4-1
ii ruby1.9.1 [ruby-interpreter] 1.9.3.484-2
ii ruby2.0 [ruby-interpreter]2.0.0.484+really457-3
ii ruby2.1 [ruby-interpreter]2.1.5-1
Versions of packages ruby-sourcify recommends:
pn ruby-parsetree none
ruby-sourcify suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778646: Multiple issues
Hi, there is 1.12 available (but the patch above solves the problem as well). Tomasz signature.asc Description: Digital signature
Bug#759306: O: mg -- microscopic GNU Emacs-style editor
Hi Harald, without knowing your work on mentors, I did my own, independent work on the package. Are you still interested in (co)maintaining it? I can sponsor your uploads. Tomasz signature.asc Description: Digital signature
Bug#780943: pristine-tar: cannot reproduce a tar.bz2 orig tarball
Package: pristine-tar Version: 1.33 Severity: normal Hi, while working on maradns packaging, we observed (by having our package upload rejected) that pristine-tar generates a tar.bz2 file that is slightly different that what was originally uploaded to pristine-tar. Here is a relevant rejection text: maradns_2.0.09-4.dsc: Invalid size hash for maradns_2.0.09.orig.tar.bz2: According to the control file the size hash should be 1139409, but maradns_2.0.09.orig.tar.bz2 has 1089174. To reproduce please do: (1) wget http://ftp.de.debian.org/debian/pool/main/m/maradns/maradns_2.0.09.orig.tar.bz2 (2) git clone git://anonscm.debian.org/collab-maint/maradns.git cd maradns pristine-tar checkout maradns_2.0.09.orig.tar.bz2 You'll notice that the first file has 1089174 bytes, whereas the second 1139409 bytes. For all we know, the tarballs created before were ok (3 uploads were made before). If you uncompress these 2 files with bunzip2, you will see that both tars are identical, though. There is a functionality proposed in https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=608406 that would catch this in theory. This problem has been workarounded by taking the orig tarball from the archive and building against it. Cheers, Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pristine-tar depends on: ii libbz2-1.0 1.0.6-7+b2 ii libc6 2.19-15 ii perl5.20.2-2 ii tar 1.27.1-2+b1 ii xdelta 1.1.3-9.1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages pristine-tar recommends: ii bzip2 1.0.6-7+b2 ii pbzip21.1.9-1 ii xz-utils 5.1.1alpha+20120614-2+b3 pristine-tar suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780943: pristine-tar: cannot reproduce a tar.bz2 orig tarball
Hi, the problem with the tarball has been fixed by reuploading it to the pristine-tar branch: http://anonscm.debian.org/cgit/collab-maint/maradns.git/log/?h=pristine-tar I live this bug open nevertheless - I think there is an issue somewhere. Tomasz signature.asc Description: Digital signature
Bug#780599: verbiste: FTBFS on various architectures due to outdated symbols file
Hi, Guillem in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780489 noticed that some symbols indeed changed from unsigned long to unsigned int. It is because size_t resolves to unsigned int instead of unsigned long as before. So it is rather a toolchain change that makes size_t defined in a different way. The funny thing is that on i386 for example, unsigned long unsinged int is the same thing, but it still mangles differently :). I think that the right solution is to get rid of size_t from public libverbiste API (replace it with unsigned long) and shield ourselves from changes like that. I'll work on that. Now, I also built 0.1.14-2 on testing i386 and it built fine (with debuild -us -uc), but when I tried *exactly the same package* from git on testing i386 (but with git-buildpackage), it fails with symbols problem. It seems that in both cases size_t resolves to a different type! It's rather strange. Cheers, Tomasz signature.asc Description: Digital signature
Bug#780489: dpkg-dev: dpkg-gensymbols does not demangle C++ symbols on some archs
Control: close -1 Hi Guillem, you are right, the problem is due to size_t used by libverbiste. Size_t may resolve to unsigned int or long and probably is not a good candidate for a public API. Closing this bug. Cheers, Tomasz signature.asc Description: Digital signature
Bug#778646: Multiple issues
Hi all,
Moritz - did you take a look at my patch? I'd really like to have a
second opinion on that since it is fairly large for an NMU.
I attach NMU patch. Shall I upload it to DELAYED/5 or something like
that?
Cheers,
Tomasz
diff -Nru potrace-1.11/debian/changelog potrace-1.11/debian/changelog
--- potrace-1.11/debian/changelog 2015-03-17 08:16:28.0 +0100
+++ potrace-1.11/debian/changelog 2015-03-17 08:19:09.0 +0100
@@ -1,3 +1,10 @@
+potrace (1.11-2.1) testing; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix multiple integer overflows (Closes: #778646)
+
+ -- Tomasz Buchert tom...@debian.org Tue, 17 Mar 2015 08:11:24 +0100
+
potrace (1.11-2) unstable; urgency=low
* Uses dh-autoreconf instead of autotools-dev (Closes: #732923)
diff -Nru potrace-1.11/debian/patches/0002-Fix-multiple-integer-overflows.patch potrace-1.11/debian/patches/0002-Fix-multiple-integer-overflows.patch
--- potrace-1.11/debian/patches/0002-Fix-multiple-integer-overflows.patch 1970-01-01 01:00:00.0 +0100
+++ potrace-1.11/debian/patches/0002-Fix-multiple-integer-overflows.patch 2015-03-17 08:19:09.0 +0100
@@ -0,0 +1,172 @@
+From: Tomasz Buchert tom...@debian.org
+Date: Sun, 1 Mar 2015 20:27:29 +0100
+Subject: Fix multiple integer overflows.
+
+Dimensions of a BMP file are signed, 4-byte integers. Therefore the size
+of the image may be bigger than range of (int). This is fixed in
+bitmap.h, by casting all offsets to unsigned long long int (and fixing
+another possible overflow in bm_new).
+
+In bitmap_io.c we make sure that width and height of the image are
+non-negative and in (int) range, because other functions require it.
+
+Moreover, we make sure that allocations do not overflow the range of
+size_t by having a wrapper (safe_malloc) that tests whether the
+allocation size fits in size_t.
+---
+ src/bitmap.h| 35 +++
+ src/bitmap_io.c | 30 +++---
+ 2 files changed, 54 insertions(+), 11 deletions(-)
+
+diff --git a/src/bitmap.h b/src/bitmap.h
+index 1ce13d6..7110926 100644
+--- a/src/bitmap.h
b/src/bitmap.h
+@@ -7,6 +7,7 @@
+
+ #include string.h
+ #include stdlib.h
++#include errno.h
+
+ /* The bitmap type is defined in potracelib.h */
+ #include potracelib.h
+@@ -27,7 +28,10 @@
+ /* macros for accessing pixel at index (x,y). U* macros omit the
+bounds check. */
+
+-#define bm_scanline(bm, y) ((bm)-map + (y)*(bm)-dy)
++typedef unsigned long long int ulli;
++
++#define bm_allocsize(bm) ((ulli)(bm)-dy * (ulli)(bm)-h)
++#define bm_scanline(bm, y) ((bm)-map + ((ulli)(y))*(ulli)(bm)-dy)
+ #define bm_index(bm, x, y) (bm_scanline(bm, y)[(x)/BM_WORDBITS])
+ #define bm_mask(x) (BM_HIBIT ((x) (BM_WORDBITS-1)))
+ #define bm_range(x, a) ((int)(x) = 0 (int)(x) (a))
+@@ -43,6 +47,16 @@
+ #define BM_INV(bm, x, y) (bm_safe(bm, x, y) ? BM_UINV(bm, x, y) : 0)
+ #define BM_PUT(bm, x, y, b) (bm_safe(bm, x, y) ? BM_UPUT(bm, x, y, b) : 0)
+
++/* allocates memory safely */
++static inline void* safe_malloc(ulli size) {
++ size_t maxsize = (size_t)-1;
++ if (size maxsize) {
++errno = ENOMEM;
++return NULL;
++ }
++ return malloc((size_t)size);
++}
++
+ /* free the given bitmap. Leaves errno untouched. */
+ static inline void bm_free(potrace_bitmap_t *bm) {
+ if (bm) {
+@@ -54,16 +68,21 @@ static inline void bm_free(potrace_bitmap_t *bm) {
+ /* return new un-initialized bitmap. NULL with errno on error */
+ static inline potrace_bitmap_t *bm_new(int w, int h) {
+ potrace_bitmap_t *bm;
+- int dy = (w + BM_WORDBITS - 1) / BM_WORDBITS;
++ int dy;
++
++ if (w % BM_WORDBITS == 0)
++dy = w / BM_WORDBITS;
++ else
++dy = (w / BM_WORDBITS) + 1;
+
+- bm = (potrace_bitmap_t *) malloc(sizeof(potrace_bitmap_t));
++ bm = (potrace_bitmap_t *)safe_malloc(sizeof(potrace_bitmap_t));
+ if (!bm) {
+ return NULL;
+ }
+ bm-w = w;
+ bm-h = h;
+ bm-dy = dy;
+- bm-map = (potrace_word *) malloc(dy * h * BM_WORDSIZE);
++ bm-map = (potrace_word *)safe_malloc(bm_allocsize(bm) * BM_WORDSIZE);
+ if (!bm-map) {
+ free(bm);
+ return NULL;
+@@ -73,7 +92,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
+
+ /* clear the given bitmap. Set all bits to c. */
+ static inline void bm_clear(potrace_bitmap_t *bm, int c) {
+- memset(bm-map, c ? -1 : 0, bm-dy * bm-h * BM_WORDSIZE);
++ memset(bm-map, c ? -1 : 0, bm_allocsize(bm) * BM_WORDSIZE);
+ }
+
+ /* duplicate the given bitmap. Return NULL on error with errno set. */
+@@ -82,14 +101,14 @@ static inline potrace_bitmap_t *bm_dup(const potrace_bitmap_t *bm) {
+ if (!bm1) {
+ return NULL;
+ }
+- memcpy(bm1-map, bm-map, bm-dy * bm-h * BM_WORDSIZE);
++ memcpy(bm1-map, bm-map, bm_allocsize(bm) * BM_WORDSIZE);
+ return bm1;
+ }
+
+ /* invert the given bitmap. */
+ static inline void bm_invert(potrace_bitmap_t *bm) {
+- int i;
+- for (i = 0; i bm-dy * bm-h; i++) {
++ ulli i;
++ for (i = 0; i bm_allocsize(bm); i++) {
+ bm-map[i] ^= BM_ALLBITS
Bug#780599: verbiste: FTBFS on various architectures due to outdated symbols file
On 16/03/15 15:49, John Paul Adrian Glaubitz wrote: Source: verbiste Version: 0.1.41-3 Severity: serious Justification: FTBFS on release architecture leaves package out-of-date Hello! Your package currently fails to build on various (release) architectures since the symbols file is outdated and needs to be updated using the diff output generated during the failed builds. Hi John, I don't think it is the case. It seems to me (although I may be wrong) that dpkg-gensymbols does not demangle C++ symbols properly. I reported a bug yesterday: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780489 Please see the available build logs [1] and use this information to update the symbols file for all architectures. Please do also remember to have a look at the builds logs for the port architectures [2] as well to fix these as well. I'd appreciate if you'd take a look at the bug report I mentioned above. Thanks, Adrian Cheers, Tomasz [1] https://buildd.debian.org/status/package.php?p=verbistesuite=sid [2] http://buildd.debian-ports.org/status/package.php?p=verbistesuite=sid signature.asc Description: Digital signature
Bug#780599: verbiste: FTBFS on various architectures due to outdated symbols file
Control: block -1 by 780489 On 16/03/15 16:24, John Paul Adrian Glaubitz wrote: Hi Tomasz! On 03/16/2015 04:14 PM, Tomasz Buchert wrote: I don't think it is the case. It seems to me (although I may be wrong) that dpkg-gensymbols does not demangle C++ symbols properly. I reported a bug yesterday: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780489 Indeed, you could be right. I just checked the build log for verbiste_0.1.41-2 on sh4, for example, and the buildd was, indeed, using dpkg_1.17.23 that time while it was using 1.17.24 for the last build. That's a great observation, however I get the problem with 1.17.24 on i386. dpkg-gensymbols does not demangle a few symbols and I don't know why (I'd have to dig dpkg-gensymbols, but I have no time right now). Please see the available build logs [1] and use this information to update the symbols file for all architectures. Please do also remember to have a look at the builds logs for the port architectures [2] as well to fix these as well. I'd appreciate if you'd take a look at the bug report I mentioned above. I could just do a manual build with a downgraded version of dpkg on one of the buildds. I wasn't really expecting this to be a bug in dpkg as we usually see this kind of FTBFS due to outdated symbols files. Feel free to reassign and merge the bug report to dpkg. I also don't think it will change anything, but it is still rather mysterious why these symbols do not demangle on some archs. I'll leave your report open, but I'll mark it blocked by my previous report, since we should understand this anyway. Thanks for the heads up! You're welcome! Adrian Tomasz signature.asc Description: Digital signature
Bug#780489: dpkg-dev: dpkg-gensymbols does not demangle C++ symbols on some archs
Package: dpkg-dev Version: 1.17.24 Severity: normal Hi, I noticed some FTBFSes with verbiste package that I uploaded recently: https://buildd.debian.org/status/package.php?p=verbistesuite=sid It happens only on some architectures, though. It seems that dpkg-gensymbols generates a symbols file that has some C++ symbols mangled. I attach the file generated on i386. You can also see that it worked before: https://buildd.debian.org/status/package.php?p=verbistesuite=jessie Cheers, Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg-dev depends on: ii base-files8 ii binutils 2.25-5 ii bzip2 1.0.6-7+b2 ii libdpkg-perl 1.17.24 ii make 4.0-8.1 ii patch 2.7.5-1 ii xz-utils 5.1.1alpha+20120614-2+b3 Versions of packages dpkg-dev recommends: ii build-essential 11.7 ii clang-3.4 [c-compiler] 1:3.4.2-13 ii fakeroot 1.20.2-1 ii gcc [c-compiler] 4:4.9.2-2 ii gcc-4.8 [c-compiler] 4.8.4-1 ii gcc-4.9 [c-compiler] 4.9.2-10 ii gnupg1.4.18-7 ii gnupg2 2.0.26-6 ii gpgv 1.4.18-7 ii libalgorithm-merge-perl 0.08-2 Versions of packages dpkg-dev suggests: ii debian-keyring 2014.12.10 -- no debconf information --- debian/libverbiste-0.1-0.symbols (libverbiste-0.1-0_0.1.41-3_i386) +++ dpkg-gensymbolsI546OM 2015-03-14 20:30:26.179866685 + @@ -3,41 +3,57 @@ (c++)InflectionDesc::~InflectionDesc()@Base 0.1 (c++)ModeTensePersonNumber::dump(Verbiste_ModeTensePersonNumber) const@Base 0.1 (c++)ModeTensePersonNumber::set(char const*, char const*, int, bool, bool)@Base 0.1 - (c++)guard variable for verbiste::Triestd::vectorverbiste::FrenchVerbDictionary::TrieValue, std::allocatorverbiste::FrenchVerbDictionary::TrieValue ::getDesc(verbiste::Triestd::vectorverbiste::FrenchVerbDictionary::TrieValue, std::allocatorverbiste::FrenchVerbDictionary::TrieValue ::Row*, std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const, unsigned long, bool, bool)::trieTrace@Base 0.1 + _ZGVZN8verbiste4TrieISt6vectorINS_20FrenchVerbDictionary9TrieValueESaIS3_EEE7getDescEPNS6_3RowERKSbIwSt11char_traitsIwESaIwEEjbbE9trieTrace@Base 0.1.41-3 + _ZN8verbiste20FrenchVerbDictionary26formUTF8UnaccentedVariantsERKSbIwSt11char_traitsIwESaIwEEjRSt6vectorISsSaISsEE@Base 0.1.41-3 + _ZN8verbiste20FrenchVerbDictionary26formUTF8UnaccentedVariantsERKSsjRSt6vectorISsSaISsEE@Base 0.1.41-3 + _ZN8verbiste4TrieISt6vectorINS_20FrenchVerbDictionary9TrieValueESaIS3_EEE7getDescEPNS6_3RowERKSbIwSt11char_traitsIwESaIwEEjbb@Base 0.1.41-3 + _ZNK8verbiste20FrenchVerbDictionary8VerbTrie25onFoundPrefixWithUserDataERKSbIwSt11char_traitsIwESaIwEEjPKSt6vectorINS0_9TrieValueESaIS9_EE@Base 0.1.41-3 + _ZNK8verbiste4TrieISt6vectorINS_20FrenchVerbDictionary9TrieValueESaIS3_EEE25onFoundPrefixWithUserDataERKSbIwSt11char_traitsIwESaIwEEjPKS5_@Base 0.1.41-3 + _ZNSt20__uninitialized_copyILb0EE13__uninit_copyIP14InflectionSpecS3_EET0_T_S5_S4_@Base 0.1.41-3 + _ZNSt4pairIKSsSt6vectorI21ModeTensePersonNumberSaIS2_EEED1Ev@Base 0.1.41-3 + _ZNSt4pairIKSsSt6vectorI21ModeTensePersonNumberSaIS2_EEED2Ev@Base 0.1.41-3 + _ZNSt8_Rb_treeI4ModeSt4pairIKS0_St3mapI5TenseSt6vectorIS5_I14InflectionSpecSaIS6_EESaIS8_EESt4lessIS4_ESaIS1_IKS4_SA_St10_Select1stISH_ESB_IS0_ESaISH_EE17_M_insert_unique_ESt23_Rb_tree_const_iteratorISH_ERKSH_@Base 0.1.41-3 + _ZNSt8_Rb_treeI5TenseSt4pairIKS0_St6vectorIS3_I14InflectionSpecSaIS4_EESaIS6_EEESt10_Select1stIS9_ESt4lessIS0_ESaIS9_EE17_M_insert_unique_ESt23_Rb_tree_const_iteratorIS9_ERKS9_@Base 0.1.41-3 + _ZNSt8_Rb_treeISsSt4pairIKSsSt3mapI4ModeS2_I5TenseSt6vectorIS5_I14InflectionSpecSaIS6_EESaIS8_EESt4lessIS4_ESaIS0_IKS4_SA_EEESB_IS3_ESaIS0_IKS3_SG_St10_Select1stISM_ESB_ISsESaISM_EE17_M_insert_unique_ESt23_Rb_tree_const_iteratorISM_ERKSM_@Base 0.1.41-3 + _ZNSt8_Rb_treeISsSt4pairIKSsSt3mapISsSt6vectorI21ModeTensePersonNumberSaIS4_EESt4lessISsESaIS0_IS1_S6_St10_Select1stISC_ES8_SaISC_EE17_M_insert_unique_ESt23_Rb_tree_const_iteratorISC_ERKSC_@Base 0.1.41-3 + _ZNSt8_Rb_treeISsSt4pairIKSsSt3setISsSt4lessISsESaISsEEESt10_Select1stIS7_ES4_SaIS7_EE17_M_insert_unique_ESt23_Rb_tree_const_iteratorIS7_ERKS7_@Base 0.1.41-3 + _ZNSt8_Rb_treeISsSt4pairIKSsSt6vectorI21ModeTensePersonNumberSaIS3_EEESt10_Select1stIS6_ESt4lessISsESaIS6_EE17_M_insert_unique_ESt23_Rb_tree_const_iteratorIS6_ERKS6_@Base 0.1.41-3 + _ZZN8verbiste4TrieISt6vectorINS_20FrenchVerbDictionary9TrieValueESaIS3_EEE7getDescEPNS6_3RowERKSbIwSt11char_traitsIwESaIwEEjbbE9trieTrace@Base 0.1.41-3 +#MISSING: 0.1.41-3# (c++)guard variable for verbiste::Triestd::vectorverbiste::FrenchVerbDictionary::TrieValue,
Bug#714564: Verbiste-mode bugs
Control: unmerge -1 On 14/03/15 09:19, intrigeri wrote: Hi, [I don't get what this has to do with a bug report titled verbiste-conjuate entrypoint autoload. Please file separate bug reports for unrelated problems, thanks!] They were simply solved by the same patch. Ok, unmerging. I'm therefore uploading what Kevin proposed. As I'm not a user of verbiste-el, I'll not complain about buffer behavior in another bug. Tomasz signature.asc Description: Digital signature
Bug#714564: verbiste bugs
Hi Kevin, sorry for being late in the bug discussion (almost 2 years). :) The good thing is that I now use emacs so I (kind of) understand elisp. I would like to close these two bugs ASAP. First, I agree that verbiste-(de)conjugate functions should autoload. And so I applied your patches and it works, generally speaking. However, I have a usability issue, which actually existed before: when I'm in verbiste buffer (i.e., verbiste-mode) and I press c (or d) and I give a word, then *another* buffer opens with conjugation/deconjugation. I would actually expect the buffer contents to be replaced with a result of conjugation/deconjugation. If you run M-x verbiste-conjugate, I can live with a new buffer opened every time. What do you think? Would you happen to know how to implement this? Cheers, Tomasz signature.asc Description: Digital signature
Bug#742627: mutt-patched: full text search (l + ~b text) is extremely slow
Control: reassign -1 mutt This problem exists in plain mutt as well, reassigning. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779948: hwinfo is in /usr/sbin
On 06/03/15 22:28, shirish शिरीष wrote: Package: hwinfo Version: 21.12-1 Severity: normal Dear Maintainer, hwinfo needs sudo/superuser/root privileges. Hi Shirish, it does not, it just gives you more information if run with them. $ sudo which hwinfo [sudo] password for shirish: /usr/sbin/hwinfo /usr/sbin is for Non-essential standard system binaries and This directory contains any non-essential binaries used exclusively by the system administrator [1]. Although, you may argue that hwinfo can be run without root privileges, its full functionality is only available when you are root. Why does it need sudo or superuser/root privileges. AFAI understand the tool/package does similar work/utility as lspci or any other tool which shows what parts of a system are there to the user. My guess is that some hardware information is restricted to root. The ideal part would be it would be able to probe all the hardware, generate a report and write it in the user's home directory. By default hwinfo prints what it probed to the standard output. You can redirect it to whatever location you like. Looking forward to know. I'd like to know what your precise problem. Is it that you like to see hwinfo in /usr/bin/hwinfo? If yes, then I'd argue that it shouldn't be there, because (1) it will signal that hwinfo does *not* need root privileges to run without trimmed functionality and this is not the case, and (2) hwinfo has always been in /usr/sbin and so it could break uses that depend on that. Cheers, Tomasz [1] http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#USRSBINNONESSENTIALSTANDARDSYSTEMBI signature.asc Description: Digital signature
Bug#779924: stellarium: Needs GLSL1.30 or later
Some relevant information: * https://bugs.freedesktop.org/show_bug.cgi?id=59187 * http://www.phoronix.com/scan.php?page=news_itempx=MTMxMDQ It seems that some GLSL 1.30 functionality exists for Ironlake GPUs, but something is still missing so only GLSL 1.2 is advertised. Fortunately, there is enough so that you can use stellarium just fine. I think it should be reassigned to one of mesa packages. Tomasz signature.asc Description: Digital signature
Bug#513402: Ping
fasm has now landed in NEW. Stay tuned. Tomasz signature.asc Description: Digital signature
Bug#779924: stellarium: Needs GLSL1.30 or later
Hi Martin, could you be more specific what the problem is? It seems that you have an older bersion of GLSL and *could* experience some problems, but you don't. That should be a reason to rejoice rather then to submit a bug, right? :D Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779046: Crash when clicking Lookup locations on network checkbox in Locations window
Hi, the change has been accepted in stellarium [1] and will be probably released in 0.13.3 release. [1] http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/7433 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778646: Multiple issues
Hi again (!),
I figured out that this will not work on architectures where
sizeof(long int) != 8 and/or sizeof(size_t) != 8, i386 for example.
The *next* patch makes sure that numbers passed to malloc() are not
overflowing size_t, and also uses *unsigned long long int* everywhere
which is guaranteed to be at least 64bit. Tested on both amd64 and
i386.
Tomasz
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Sun, 1 Mar 2015 20:27:29 +0100
Subject: Fix multiple integer overflows.
Dimensions of a BMP file are signed, 4-byte integers. Therefore the size
of the image may be bigger than range of (int). This is fixed in
bitmap.h, by casting all offsets to unsigned long long int (and fixing
another possible overflow in bm_new).
In bitmap_io.c we make sure that width and height of the image are
non-negative and in (int) range, because other functions require it.
Moreover, we make sure that allocations do not overflow the range of
size_t by having a wrapper (safe_malloc) that tests whether the
allocation size fits in size_t.
---
src/bitmap.h| 35 +++
src/bitmap_io.c | 30 +++---
2 files changed, 54 insertions(+), 11 deletions(-)
diff --git a/src/bitmap.h b/src/bitmap.h
index 1ce13d6..7110926 100644
--- a/src/bitmap.h
+++ b/src/bitmap.h
@@ -7,6 +7,7 @@
#include string.h
#include stdlib.h
+#include errno.h
/* The bitmap type is defined in potracelib.h */
#include potracelib.h
@@ -27,7 +28,10 @@
/* macros for accessing pixel at index (x,y). U* macros omit the
bounds check. */
-#define bm_scanline(bm, y) ((bm)-map + (y)*(bm)-dy)
+typedef unsigned long long int ulli;
+
+#define bm_allocsize(bm) ((ulli)(bm)-dy * (ulli)(bm)-h)
+#define bm_scanline(bm, y) ((bm)-map + ((ulli)(y))*(ulli)(bm)-dy)
#define bm_index(bm, x, y) (bm_scanline(bm, y)[(x)/BM_WORDBITS])
#define bm_mask(x) (BM_HIBIT ((x) (BM_WORDBITS-1)))
#define bm_range(x, a) ((int)(x) = 0 (int)(x) (a))
@@ -43,6 +47,16 @@
#define BM_INV(bm, x, y) (bm_safe(bm, x, y) ? BM_UINV(bm, x, y) : 0)
#define BM_PUT(bm, x, y, b) (bm_safe(bm, x, y) ? BM_UPUT(bm, x, y, b) : 0)
+/* allocates memory safely */
+static inline void* safe_malloc(ulli size) {
+ size_t maxsize = (size_t)-1;
+ if (size maxsize) {
+errno = ENOMEM;
+return NULL;
+ }
+ return malloc((size_t)size);
+}
+
/* free the given bitmap. Leaves errno untouched. */
static inline void bm_free(potrace_bitmap_t *bm) {
if (bm) {
@@ -54,16 +68,21 @@ static inline void bm_free(potrace_bitmap_t *bm) {
/* return new un-initialized bitmap. NULL with errno on error */
static inline potrace_bitmap_t *bm_new(int w, int h) {
potrace_bitmap_t *bm;
- int dy = (w + BM_WORDBITS - 1) / BM_WORDBITS;
+ int dy;
+
+ if (w % BM_WORDBITS == 0)
+dy = w / BM_WORDBITS;
+ else
+dy = (w / BM_WORDBITS) + 1;
- bm = (potrace_bitmap_t *) malloc(sizeof(potrace_bitmap_t));
+ bm = (potrace_bitmap_t *)safe_malloc(sizeof(potrace_bitmap_t));
if (!bm) {
return NULL;
}
bm-w = w;
bm-h = h;
bm-dy = dy;
- bm-map = (potrace_word *) malloc(dy * h * BM_WORDSIZE);
+ bm-map = (potrace_word *)safe_malloc(bm_allocsize(bm) * BM_WORDSIZE);
if (!bm-map) {
free(bm);
return NULL;
@@ -73,7 +92,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
/* clear the given bitmap. Set all bits to c. */
static inline void bm_clear(potrace_bitmap_t *bm, int c) {
- memset(bm-map, c ? -1 : 0, bm-dy * bm-h * BM_WORDSIZE);
+ memset(bm-map, c ? -1 : 0, bm_allocsize(bm) * BM_WORDSIZE);
}
/* duplicate the given bitmap. Return NULL on error with errno set. */
@@ -82,14 +101,14 @@ static inline potrace_bitmap_t *bm_dup(const potrace_bitmap_t *bm) {
if (!bm1) {
return NULL;
}
- memcpy(bm1-map, bm-map, bm-dy * bm-h * BM_WORDSIZE);
+ memcpy(bm1-map, bm-map, bm_allocsize(bm) * BM_WORDSIZE);
return bm1;
}
/* invert the given bitmap. */
static inline void bm_invert(potrace_bitmap_t *bm) {
- int i;
- for (i = 0; i bm-dy * bm-h; i++) {
+ ulli i;
+ for (i = 0; i bm_allocsize(bm); i++) {
bm-map[i] ^= BM_ALLBITS;
}
}
diff --git a/src/bitmap_io.c b/src/bitmap_io.c
index 6cfecb1..ea2d188 100644
--- a/src/bitmap_io.c
+++ b/src/bitmap_io.c
@@ -381,6 +381,16 @@ static int bmp_readint(FILE *f, int n, unsigned int *p) {
return 0;
}
+/* converts unsigned to signed using 32 bits */
+static int unsigned_to_signed32(unsigned int x) {
+ unsigned int sign = 0x8000U;
+ unsigned int mask = 0xU;
+ if (sign x)
+return -(int)(x ^ mask) - 1;
+ else
+return (int)x;
+}
+
/* reset padding boundary */
static void bmp_pad_reset(void) {
bmp_count = 0;
@@ -478,12 +488,25 @@ static int bm_readbody_bmp(FILE *f, double threshold, potrace_bitmap_t **bmp) {
TRY(bmp_readint(f, 4, bmpinfo.BlueMask));
TRY(bmp_readint(f, 4, bmpinfo.AlphaMask));
}
-if ((signed int)bmpinfo.h 0) {
- bmpinfo.h = -bmpinfo.h;
+int maxdim = 0x7ffe; /* 2^31 - 2 */
+int
Bug#778646: Multiple issues
Hi again,
here is slightly better patch.
Cheers,
Tomasz
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Sun, 1 Mar 2015 20:27:29 +0100
Subject: Fix multiple integer overflows.
Dimensions of a BMP file are signed, 4-byte integers. Therefore
the size of the image may be bigger than range of (int). This is fixed
in bitmap.h, by casting all offsets to long int (and fixing
another possible overflow in bm_new).
In bitmap_io.c we make sure that width and height of the image
are non-negative and in (int) range, because other functions require it.
---
src/bitmap.h| 20 +---
src/bitmap_io.c | 27 +--
2 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/src/bitmap.h b/src/bitmap.h
index 1ce13d6..878aa9a 100644
--- a/src/bitmap.h
+++ b/src/bitmap.h
@@ -27,7 +27,8 @@
/* macros for accessing pixel at index (x,y). U* macros omit the
bounds check. */
-#define bm_scanline(bm, y) ((bm)-map + (y)*(bm)-dy)
+#define bm_allocsize(bm) ((long int)(bm)-dy * (long int)(bm)-h)
+#define bm_scanline(bm, y) ((bm)-map + ((long int)(y))*(long int)(bm)-dy)
#define bm_index(bm, x, y) (bm_scanline(bm, y)[(x)/BM_WORDBITS])
#define bm_mask(x) (BM_HIBIT ((x) (BM_WORDBITS-1)))
#define bm_range(x, a) ((int)(x) = 0 (int)(x) (a))
@@ -54,7 +55,12 @@ static inline void bm_free(potrace_bitmap_t *bm) {
/* return new un-initialized bitmap. NULL with errno on error */
static inline potrace_bitmap_t *bm_new(int w, int h) {
potrace_bitmap_t *bm;
- int dy = (w + BM_WORDBITS - 1) / BM_WORDBITS;
+ int dy;
+
+ if (w % BM_WORDBITS == 0)
+dy = w / BM_WORDBITS;
+ else
+dy = (w / BM_WORDBITS) + 1;
bm = (potrace_bitmap_t *) malloc(sizeof(potrace_bitmap_t));
if (!bm) {
@@ -63,7 +69,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
bm-w = w;
bm-h = h;
bm-dy = dy;
- bm-map = (potrace_word *) malloc(dy * h * BM_WORDSIZE);
+ bm-map = (potrace_word *) malloc(bm_allocsize(bm) * BM_WORDSIZE);
if (!bm-map) {
free(bm);
return NULL;
@@ -73,7 +79,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
/* clear the given bitmap. Set all bits to c. */
static inline void bm_clear(potrace_bitmap_t *bm, int c) {
- memset(bm-map, c ? -1 : 0, bm-dy * bm-h * BM_WORDSIZE);
+ memset(bm-map, c ? -1 : 0, bm_allocsize(bm) * BM_WORDSIZE);
}
/* duplicate the given bitmap. Return NULL on error with errno set. */
@@ -82,14 +88,14 @@ static inline potrace_bitmap_t *bm_dup(const potrace_bitmap_t *bm) {
if (!bm1) {
return NULL;
}
- memcpy(bm1-map, bm-map, bm-dy * bm-h * BM_WORDSIZE);
+ memcpy(bm1-map, bm-map, bm_allocsize(bm) * BM_WORDSIZE);
return bm1;
}
/* invert the given bitmap. */
static inline void bm_invert(potrace_bitmap_t *bm) {
- int i;
- for (i = 0; i bm-dy * bm-h; i++) {
+ long int i;
+ for (i = 0; i bm_allocsize(bm); i++) {
bm-map[i] ^= BM_ALLBITS;
}
}
diff --git a/src/bitmap_io.c b/src/bitmap_io.c
index 6cfecb1..3635ec3 100644
--- a/src/bitmap_io.c
+++ b/src/bitmap_io.c
@@ -381,6 +381,16 @@ static int bmp_readint(FILE *f, int n, unsigned int *p) {
return 0;
}
+/* converts unsigned to signed using 32 bits */
+static int unsigned_to_signed32(unsigned int x) {
+ unsigned int sign = 0x8000U;
+ unsigned int mask = 0xU;
+ if (sign x)
+return -(int)(x ^ mask) - 1;
+ else
+return (int)x;
+}
+
/* reset padding boundary */
static void bmp_pad_reset(void) {
bmp_count = 0;
@@ -478,12 +488,25 @@ static int bm_readbody_bmp(FILE *f, double threshold, potrace_bitmap_t **bmp) {
TRY(bmp_readint(f, 4, bmpinfo.BlueMask));
TRY(bmp_readint(f, 4, bmpinfo.AlphaMask));
}
-if ((signed int)bmpinfo.h 0) {
- bmpinfo.h = -bmpinfo.h;
+int maxdim = 0x7ffe; /* 2^31 - 2 */
+int sign_h = unsigned_to_signed32(bmpinfo.h);
+int sign_w = unsigned_to_signed32(bmpinfo.w);
+if (sign_w 0 || sign_w maxdim) {
+ bm_read_error = incorrect bmp width;
+ goto format_error;
+}
+if (sign_h -maxdim || sign_h maxdim) {
+ bm_read_error = incorrect bmp height;
+ goto format_error;
+}
+if (sign_h 0) {
+ bmpinfo.h = (unsigned int)(-sign_h);
bmpinfo.topdown = 1;
} else {
bmpinfo.topdown = 0;
}
+/* now we know that bmpinfo.{w,h} are non-negative ints
+ that fit in int type (cf. bm_new)) */
} else if (bmpinfo.InfoSize == 12) {
/* old OS/2 format */
bmpinfo.ctbits = 24; /* sample size in color table */
Bug#778646: Multiple issues
On 17/02/15 22:02, Moritz Muehlenhoff wrote:
Package: potrace
Version: 1.11-2
Severity: grave
Tags: security
Hi,
please see https://bugzilla.redhat.com/show_bug.cgi?id=955808
Could you report this upstream?
A CVE ID has been requested, but not yet assigned:
http://www.openwall.com/lists/oss-security/2015/02/06/12
Cheers,
Moritz
Hi Moritz,
here is my analysis of the problem in a form of a patch.
tl;dr; - (a) casting from unsigned int to int is tricky
(b) product of two ints may overflow
It fixes all the cases attached in the RedHat's bugzilla, but
a review of the code by another person is advised.
Cheers,
Tomasz
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Sun, 1 Mar 2015 20:27:29 +0100
Subject: Fix multiple integer overflows.
Dimensions of a BMP file are signed, 4-byte integers. Therefore
the size of the image may be bigger than range of (int). This is fixed
in bitmap.h, by casting all offsets to long int (and fixing
another possible overflow in bm_new).
In bitmap_io.c we make sure that width and height of the image
are non-negative and in (int) range, because other functions require it.
---
src/bitmap.h| 20 +---
src/bitmap_io.c | 29 +++--
2 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/src/bitmap.h b/src/bitmap.h
index 1ce13d6..878aa9a 100644
--- a/src/bitmap.h
+++ b/src/bitmap.h
@@ -27,7 +27,8 @@
/* macros for accessing pixel at index (x,y). U* macros omit the
bounds check. */
-#define bm_scanline(bm, y) ((bm)-map + (y)*(bm)-dy)
+#define bm_allocsize(bm) ((long int)(bm)-dy * (long int)(bm)-h)
+#define bm_scanline(bm, y) ((bm)-map + ((long int)(y))*(long int)(bm)-dy)
#define bm_index(bm, x, y) (bm_scanline(bm, y)[(x)/BM_WORDBITS])
#define bm_mask(x) (BM_HIBIT ((x) (BM_WORDBITS-1)))
#define bm_range(x, a) ((int)(x) = 0 (int)(x) (a))
@@ -54,7 +55,12 @@ static inline void bm_free(potrace_bitmap_t *bm) {
/* return new un-initialized bitmap. NULL with errno on error */
static inline potrace_bitmap_t *bm_new(int w, int h) {
potrace_bitmap_t *bm;
- int dy = (w + BM_WORDBITS - 1) / BM_WORDBITS;
+ int dy;
+
+ if (w % BM_WORDBITS == 0)
+dy = w / BM_WORDBITS;
+ else
+dy = (w / BM_WORDBITS) + 1;
bm = (potrace_bitmap_t *) malloc(sizeof(potrace_bitmap_t));
if (!bm) {
@@ -63,7 +69,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
bm-w = w;
bm-h = h;
bm-dy = dy;
- bm-map = (potrace_word *) malloc(dy * h * BM_WORDSIZE);
+ bm-map = (potrace_word *) malloc(bm_allocsize(bm) * BM_WORDSIZE);
if (!bm-map) {
free(bm);
return NULL;
@@ -73,7 +79,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
/* clear the given bitmap. Set all bits to c. */
static inline void bm_clear(potrace_bitmap_t *bm, int c) {
- memset(bm-map, c ? -1 : 0, bm-dy * bm-h * BM_WORDSIZE);
+ memset(bm-map, c ? -1 : 0, bm_allocsize(bm) * BM_WORDSIZE);
}
/* duplicate the given bitmap. Return NULL on error with errno set. */
@@ -82,14 +88,14 @@ static inline potrace_bitmap_t *bm_dup(const potrace_bitmap_t *bm) {
if (!bm1) {
return NULL;
}
- memcpy(bm1-map, bm-map, bm-dy * bm-h * BM_WORDSIZE);
+ memcpy(bm1-map, bm-map, bm_allocsize(bm) * BM_WORDSIZE);
return bm1;
}
/* invert the given bitmap. */
static inline void bm_invert(potrace_bitmap_t *bm) {
- int i;
- for (i = 0; i bm-dy * bm-h; i++) {
+ long int i;
+ for (i = 0; i bm_allocsize(bm); i++) {
bm-map[i] ^= BM_ALLBITS;
}
}
diff --git a/src/bitmap_io.c b/src/bitmap_io.c
index 6cfecb1..635540c 100644
--- a/src/bitmap_io.c
+++ b/src/bitmap_io.c
@@ -381,6 +381,18 @@ static int bmp_readint(FILE *f, int n, unsigned int *p) {
return 0;
}
+/* converts unsigned to signed */
+static int unsigned_to_signed(int bits, unsigned int x) {
+ unsigned int mask = ((unsigned int)1) (bits - 1);
+ int minint = ((int)-1) (bits - 1);
+ if (mask == x)
+return minint;
+ else if (mask x)
+return -((int)(~x) + 1);
+ else
+return (int)x;
+}
+
/* reset padding boundary */
static void bmp_pad_reset(void) {
bmp_count = 0;
@@ -478,12 +490,25 @@ static int bm_readbody_bmp(FILE *f, double threshold, potrace_bitmap_t **bmp) {
TRY(bmp_readint(f, 4, bmpinfo.BlueMask));
TRY(bmp_readint(f, 4, bmpinfo.AlphaMask));
}
-if ((signed int)bmpinfo.h 0) {
- bmpinfo.h = -bmpinfo.h;
+int maxdim = 0x7ffe; /* 2^31 - 2 */
+int sign_h = unsigned_to_signed(32, bmpinfo.h);
+int sign_w = unsigned_to_signed(32, bmpinfo.w);
+if (sign_w 0 || sign_w maxdim) {
+ bm_read_error = incorrect bmp width;
+ goto format_error;
+}
+if (sign_h -maxdim || sign_h maxdim) {
+ bm_read_error = incorrect bmp height;
+ goto format_error;
+}
+if (sign_h 0) {
+ bmpinfo.h = (unsigned int)(-sign_h);
bmpinfo.topdown = 1;
} else {
bmpinfo.topdown = 0;
}
+/* now we know that bmpinfo.{w,h} are non-negative ints
Bug#779268: www.debian.org: package list does not specify architectures for most packages
Package: www.debian.org Severity: normal Hi, the package list that can be downloaded from here: https://packages.debian.org/stable/allpackages?format=txt.gz is supposed to contain packages and their version in stable distribution. When there are multiple versions of the same package, but with different archs., each arch. is listed next to the version. However, if there is only *one* version, no archs. are listed, *even* if a subset of them is in stable. For example, 0ad is such a package - it is listed as 0ad (0~r11863-2) Real-time strategy game of ancient warfare but it is only built on 5 archs.: https://packages.qa.debian.org/0/0ad.html As a result, there is no way of knowing about the archs the particular package support without fetching data from elsewhere. I'd expect this file to list *each* supported arch. for *each* package on the list. Cheers, Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779168: stellarium: please package stellarium 0.13.2
Hi Shirish, 0.13.2 is already in the git repository for some time. It *could* be uploaded to unstable (and accepted), there is nothing technically blocking it, but it could make things more difficult if RC bugs would show up in jessie. This is the only reason why it hasn't been released in unstable. For the experimental release - why not! The only problem I have is the fact that my key in the Debian keyring is currently expired, so I cannot upload it myself. I'll ask a DD while waiting for it to be refreshed, though. Stay tuned. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779046: Crash when clicking Lookup locations on network checkbox in Locations window
On 23/02/15 11:31, Adam Majer wrote: Package: stellarium Version: 0.13.1-1 Severity: normal To reproduce this bug, it seems it is enough to click on the network lookup checkbox in Location window a few times. StelLocationMgr: Malformatted answer in IP-based location lookup: StelLocationMgr: Will not change location. StelLocationMgr: Malformatted answer in IP-based location lookup: StelLocationMgr: Will not change location. StelLocationMgr: Malformatted answer in IP-based location lookup: StelLocationMgr: Will not change location. Failure getting IP-based location: Unknown error Segmentation fault (core dumped) [...] Hi Adam, I can't reproduce it, I'm not getting your messages. I tried with Internet connection on and off. In both cases it went fine (i.e., it didn't crash)). I think you have experienced aserver problem which is not handled properly in the code. I'll take a look at it later. Thanks, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779046: Crash when clicking Lookup locations on network checkbox in Locations window
Control: tag -1 confirmed Ok, I didn't understand your first instructions. It is reproducible by me as well. I'll take a look at it later today. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779046: Crash when clicking Lookup locations on network checkbox in Locations window
On 24/02/15 16:54, Tomasz Buchert wrote:
Control: tag -1 confirmed
Ok, I didn't understand your first instructions.
It is reproducible by me as well. I'll take a look at it
later today.
I found the problem - Location dialog launches Network Request
asynchronously on every click of the checkbox. However each request
uses the same global variable which creates a race condition. Our
problem happens, because QNetworkReply that was already deleted is
used by another async. request.
I attach a patch that fixes this for me and I'm contacting stellarium
devs to tell them about it.
Thanks Adam,
Tomasz
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Tue, 24 Feb 2015 22:33:20 +0100
Subject: test
---
src/core/StelLocationMgr.cpp | 4 ++--
src/core/StelLocationMgr.hpp | 4
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/core/StelLocationMgr.cpp b/src/core/StelLocationMgr.cpp
index f922a95..dd37c57 100644
--- a/src/core/StelLocationMgr.cpp
+++ b/src/core/StelLocationMgr.cpp
@@ -35,7 +35,6 @@
#include QSettings
StelLocationMgr::StelLocationMgr()
- : networkReply(NULL)
{
QSettings* conf = StelApp::getInstance().getSettings();
@@ -345,7 +344,7 @@ bool StelLocationMgr::deleteUserLocation(const QString id)
void StelLocationMgr::locationFromIP()
{
QNetworkRequest req( QUrl( QString(http://freegeoip.net/csv/;) ) );
- networkReply=StelApp::getInstance().getNetworkAccessManager()-get(req);
+ QNetworkReply* networkReply=StelApp::getInstance().getNetworkAccessManager()-get(req);
connect(networkReply, SIGNAL(finished()), this, SLOT(changeLocationFromNetworkLookup()));
}
@@ -354,6 +353,7 @@ void StelLocationMgr::changeLocationFromNetworkLookup()
{
StelLocation location;
StelCore *core=StelApp::getInstance().getCore();
+ QNetworkReply* networkReply = static_castQNetworkReply*(sender());
if (networkReply-error() == QNetworkReply::NoError) {
//success
// Tested with and without working network connection.
diff --git a/src/core/StelLocationMgr.hpp b/src/core/StelLocationMgr.hpp
index 36d9eee..31ff428 100644
--- a/src/core/StelLocationMgr.hpp
+++ b/src/core/StelLocationMgr.hpp
@@ -108,10 +108,6 @@ private:
QMapQString, StelLocation pickedLocations;
StelLocation lastResortLocation;
-
- //! For IP-based location lookup
- QNetworkReply *networkReply;
-
};
#endif // _STELLOCATIONMGR_HPP_
Bug#778992: RFP: guess-language -- Guess the natural language of a text
On 15/08/13 19:03, Luciano Bello wrote: Package: wnpp Severity: wishlist * Package name: guess-language Version : 0.5a4 Upstream Author : Name hiddenspi...@gmail.com * URL : https://bitbucket.org/spirit/guess_language * License : LGPL Programming Lang: Python Description : Guess the natural language of a text long description needed Hi, I revived the idea of packaging guess-language. Here is the ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778992 Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778992: ITP: python-guess-language -- library to detect the natural language of a text
Package: wnpp Severity: wishlist Owner: Tomasz Buchert tomasz.buch...@inria.fr * Package name: python-guess-language Version : 0.5.1 Upstream Author : spirit hiddenspi...@gmail.com * URL : https://bitbucket.org/spirit/guess_language/ * License : LPGL-3+ Programming Lang: Python Description : library to detect the natural language of a text guess_language is a Python library to guess the natural language that a given text is written it. To achieve this, it uses models precomputed for each language and, optionally, spellchecking of words. . This package installs the library for Python 3. There is a RFP on this package for some time: https://bugs.debian.org/719820. I'll also need this in my future project. I will maintain it myself. The package theoretically supports Python 2 through lib3to2, but it is not in Debian: https://bugs.debian.org/597283, so I don't provide the Python 2 version. I, personally, have no need for Python 2 version, but if lib3to2 is available I'll be happy to add it. The current state of packaging is here: http://anonscm.debian.org/cgit/collab-maint/python-guess-language.git Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778933: ITP: python-pyelftools -- pure-python library for parsing ELF and DWARF
Package: wnpp Severity: wishlist Owner: Tomasz Buchert tomasz.buch...@inria.fr * Package name: python-pyelftools Version : 0.23-1 Upstream Author : 2015 Eli Bendersky eli...@gmail.com * URL : https://github.com/eliben/pyelftools * License : Public Domain Programming Lang: Python Description : pure-python2 library for parsing ELF and DWARF pyelftools is a pure-Python library for parsing and analyzing ELF files and DWARF debugging information. It can be used to query information about compiled binaries and libraries from your Python code. This package is required for a newer versions of pax-utils [1]. However, it is interesting on its own - it provides Python 2 3 compatible library to parse ELF files and reimplementation of readelf from binutils. I can maintain it myself (I already maintain pax-utils). I've already did the preliminary packaging [2]. The source package builds 3 binary packages: Python2 library, Python3 library and pyreadelf which depends on Python3 library. Cheers, Tomasz [1] https://tracker.debian.org/pkg/pax-utils [2] http://anonscm.debian.org/cgit/collab-maint/python-pyelftools.git/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778674: apt-p2p: fails to start (throws exception)
Package: apt-p2p Version: 0.1.7 Severity: grave Justification: renders package unusable Hi, I wanted to test apt-p2p and noticed that it won't even start: [ ~ ] $ sudo apt-p2p [sudo] password for toma: 2015-02-18 11:47:31+0100 [-] Log opened. 2015-02-18 11:47:31+0100 [-] Loading config files: '/etc/apt-p2p/apt-p2p.conf', '/root/.apt-p2p/apt-p2p.conf', '' 2015-02-18 11:47:31+0100 [-] Successfully loaded config files: '/etc/apt-p2p/apt-p2p.conf' 2015-02-18 11:47:31+0100 [-] Starting application with uid/gid 141/65534 2015-02-18 11:47:31+0100 [-] Starting main application server 2015-02-18 11:47:31+0100 [-] Traceback (most recent call last): 2015-02-18 11:47:31+0100 [-] File /usr/sbin/apt-p2p, line 73, in module 2015-02-18 11:47:31+0100 [-] from apt_p2p.apt_p2p import AptP2P 2015-02-18 11:47:31+0100 [-] File /usr/lib/python2.7/dist-packages/apt_p2p/apt_p2p.py, line 19, in module 2015-02-18 11:47:31+0100 [-] from MirrorManager import MirrorManager 2015-02-18 11:47:31+0100 [-] File /usr/lib/python2.7/dist-packages/apt_p2p/MirrorManager.py, line 16, in module 2015-02-18 11:47:31+0100 [-] from AptPackages import AptPackages 2015-02-18 11:47:31+0100 [-] File /usr/lib/python2.7/dist-packages/apt_p2p/AptPackages.py, line 40, in module 2015-02-18 11:47:31+0100 [-] from apt.progress.old import OpProgress 2015-02-18 11:47:31+0100 [-] ImportError: No module named old Just letting you know and putting it under RC. Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt-p2p depends on: ii adduser 3.113+nmu3 ii python 2.7.8-3 ii python-apt 0.9.3.11 ii python-debian0.1.25 ii python-pysqlite2 2.6.3-3 ii python-twisted-web2 8.1.0-3 pn python:any none apt-p2p recommends no packages. apt-p2p suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778375: apt-transport-https: segfaults
On 15/02/15 23:55, Tomasz Buchert wrote:
[...]
(@Julian: sorry for not CCing you before)
Hi again,
I couldn't fall asleep, so there you go:
The tricky HTTPS server returns this line: HTTP/1.1 302. Note that
there is no explanation for the status code 302 (it should be
Found). Anyway, this is fine, the code seems to be prepared for
that case: elements is set to 3 in server.cc:128.
However, Owner is NULL (I don't know why, I don't know the code, but
it is) so Owner-Debug fails in server.cc:132.
The attached patch checks whether Owner is NULL before dereferencing
it. This fixes this problem for me, but somebody who knows what Owner
is should make sure that it makes sense. Feel free to adjust the
patch to your needs, it's in public domain.
Cheers,
Tomasz
From 3afccaefccc9045d5d1236f09d4cc90cc721c8ef Mon Sep 17 00:00:00 2001
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Mon, 16 Feb 2015 00:57:29 +0100
Subject: [PATCH] simple fix
---
methods/server.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/methods/server.cc b/methods/server.cc
index cb0341d..e321e02 100644
--- a/methods/server.cc
+++ b/methods/server.cc
@@ -129,7 +129,7 @@ bool ServerState::HeaderLine(string Line)
if (elements == 3)
{
Code[0] = '\0';
- if (Owner-Debug == true)
+ if (Owner != NULL Owner-Debug == true)
clog HTTP server doesn't give Reason-Phrase for Result std::endl;
}
else if (elements != 4)
--
2.1.4
Bug#777421: dnstop: fails to capture packets in realtime
Control: severity -1 grave
On 08/02/15 03:19, Tomasz Buchert wrote:
[...]
Hi,
I've analyzed my problem and found what follows.
ANALYSIS
=
First, only the QUERY packets are missing in dnstop, the RESPONSE
packets show (mostly) fine with dns -Q -R interface. I say mostly
because they can be still lost if there is too much traffic coming to
the card.
Second, the use of pcap_fileno is incorrect, it seems that
pcap_get_selectable_fd should be used instead. I'm not sure it
changes anything in practice, though.
Third, pcap_select in the code is called with 1s of timeout: for
reasons that are unclear to me, this makes the pcap library drop the
packets randomly (verified with pcap_stats) and these drops are the
reason for this bug. Strangely, making the timeout smaller (say 50ms)
makes the problem go away. Removing the use of pcap_select
altogether works as well, however this causes dnstop to eat 100% of
ther CPU due to pcap_setnonblock.
SOLUTIONS
===
(1) Changing the pcap_select timeout to something like 50ms works
for me, but this is hardly a real solution.
(2) Removing pcap_setnonblock and pcap_select from the code solves
the problem as well. In this case we should probably also increase
to_ms in pcap_open_live to something bigger than 1ms (I've set
it to 50ms - a tolerable time for an interface to freeze).
(3) Increasing the buffer size for the capture could work as well, but
I haven't tried it.
===
My preferred solution is (2) and I attach a proof-of-concept
patch. The reason for having (1) in the upstream is a support for
MacOSX which we don't really care about in Debian. However, we have
non-Linux ports (FreeBSD officialy and hurd) and I have no idea
whether (2) will work for them. For example, while researching this,
I found that there is no promise that pcap_dispatch will respect the
timeout given in pcap_open_live (it may actually block).
Personally I think this bug is RC (the package does not work
out of the box) and I'm bumping the severity.
Cheers,
Tomasz
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Sun, 15 Feb 2015 20:20:54 +0100
Subject: proof-of-concept patch
---
dnstop.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dnstop.c b/dnstop.c
index 57e12cc..e4b8f6d 100644
--- a/dnstop.c
+++ b/dnstop.c
@@ -1901,7 +1901,7 @@ main(int argc, char *argv[])
if (readfile_state) {
pcap = pcap_open_offline(device, errbuf);
} else {
- pcap = pcap_open_live(device, PCAP_SNAPLEN, promisc_flag, 1, errbuf);
+ pcap = pcap_open_live(device, PCAP_SNAPLEN, promisc_flag, 50, errbuf);
}
if (NULL == pcap) {
fprintf(stderr, pcap_open_*: %s\n, errbuf);
@@ -1934,7 +1934,7 @@ main(int argc, char *argv[])
* workaround and dnstop does not require non-blocking, we'll won't
* check the return status.
*/
-pcap_setnonblock(pcap, 1, errbuf);
+/* pcap_setnonblock(pcap, 1, errbuf); */
switch (pcap_datalink(pcap)) {
case DLT_EN10MB:
handle_datalink = handle_ether;
@@ -1993,8 +1993,8 @@ main(int argc, char *argv[])
* packets to process. Thus, we always ignore its return value
* and just call pcap_dispatch() anyway.
*/
- if (0 == readfile_state) /* interactive */
- pcap_select(pcap, 1, 0);
+ /* if (0 == readfile_state)
+ pcap_select(pcap, 1, 0); */
x = pcap_dispatch(pcap, 50, handle_pcap, NULL);
}
if (0 == x 1 == readfile_state) {
Bug#778375: apt-transport-https: segfaults
On 14/02/15 10:44, Kurt Roeckx wrote: Package: apt-transport-https Version: 1.0.9.6 Severity: serious Hi, When I try to download something over https apt just segfaults: https[7809]: segfault at 69 ip 7f523b8cbb03 sp 7fff432589e0 error 4 in https[7f523b8c+12000] Kurt Hi Kurt, I cannot reproduce it: $ LC_ALL=C sudo apt-get install cowsay Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: cowsay 0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded. Need to get 20.0 kB of archives. After this operation, 92.2 kB of additional disk space will be used. Get:1 https://ftp-stud.hs-esslingen.de/debian/ testing/main cowsay all 3.03+dfsg1-10 [20.0 kB] Fetched 20.0 kB in 0s (65.9 kB/s) [... other standard things ...] Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778375: apt-transport-https: segfaults
On 15/02/15 23:16, Tomasz Buchert wrote:
[...]
Okay, I get a segfault too now:
[ 153.995036] https[2667]: segfault at 69 ip 7f41539d7b03 sp
7fffa171dbb0 error 4 in https[7f41539cc000+12000]
Tomasz
Hi again,
I've recompiled apt-transport-https with debugging symbols and
derandomized positions of code sections (via echo 0 | sudo tee
/proc/sys/kernel/randomize_va_space). I got this:
[ 510.536222] https[2990]: segfault at 69 ip fb03 sp
7fffdbf0 error 4 in https[4000+12000]
and then, via gdb:
(gdb) list *0xfb03
0xfb03 is in ServerState::HeaderLine(std::string)
(/tmp/apt-1.0.9.6/methods/server.cc:120).
115// Parse off any trailing spaces between the : and the next word.
116string::size_type Pos2 = Pos;
117while (Pos2 Line.length() isspace(Line[Pos2]) != 0)
118 Pos2++;
119
120string Tag = string(Line,0,Pos);
121string Val = string(Line,Pos2);
122
123if (stringcasecmp(Tag.c_str(),Tag.c_str()+4,HTTP) == 0)
124{
So there is an issue with parsing of HTTP headers or something like
that around server.cc:120. Unfortunately, I don't have much time to
dig more at the moment. Hope this helps.
Tomasz
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778375: apt-transport-https: segfaults
On 15/02/15 22:22, Kurt Roeckx wrote: [...] Can you try adding this to your sources.list? deb https://dl.bintray.com/sbt/debian / And then apt-get install -d sbt Kurt Okay, I get a segfault too now: [ 153.995036] https[2667]: segfault at 69 ip 7f41539d7b03 sp 7fffa171dbb0 error 4 in https[7f41539cc000+12000] Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776717: hwinfo build is not reproducible
This has been fixed in the git and will be a part of the new upload. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776713: tiptop: package is not reproducible
This now fixed in the git repository and will be released with the new upload. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776715: pax-utils are not reproducible
This is fixed in the git repository and will be released with the new upload. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776716: miredo is not reproducible
This is fixed in the fir repo and will be a part of the next release. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778336: pastebinit: fails in the default configuration
Package: pastebinit Version: 1.4-3 Severity: important Dear Maintainer, * What led up to the situation? I wanted to paste my piece of code. * What exactly did you do (or not do) that was effective (or ineffective)? I've run: echo foo\nq\nb\nc | pastebinit * What was the outcome of this action? The output is: Bad API request, invalid api_dev_key * What outcome did you expect instead? I'd expect a link like: http://pastebin.com/FKViEqGi It seems to me that http://pastebin.com, the default paste service, became closed to anonymous pasting. The package is not usable by default and needs some tinkering to make it work. This is a workaround: $ echo foo\nq\nb\nc | pastebinit -b http://paste.debian.net but remember also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760341 Cheers, Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pastebinit depends on: ii python3 3.4.2-2 Versions of packages pastebinit recommends: ii lsb-release 4.1+Debian13+nmu1 pastebinit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778336: Bumping severity
Severity: grave Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778336: Bumping severity
Control: severity -1 grave I never remember how it works. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777421: dnstop: fails to capture packets in realtime
Package: dnstop Version: 20120611-2 Severity: important Dear Maintainer, * What led up to the situation? I wanted to see my server's DNS queries. * What exactly did you do (or not do) that was effective (or ineffective)? I've run dnstop with: sudo dnstop my-interface on the machine running the DNS server. Then I issued some (successful) DNS queries to this machine. * What was the outcome of this action? The DNS queries were not shown in the interface. * What outcome did you expect instead? I would like to see DNS queries listed in the interface as they hit the server. The problem seems to persist with the newer version (dnstop-20140915.tar.gz) which I compiled from the source. The problem *does not* happen if I run dnstop from a tcpdump capture (saved with -w filename). Cheers, Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dnstop depends on: ii libc62.19-13 ii libncurses5 5.9+20140913-1+b1 ii libpcap0.8 1.6.2-2 ii libtinfo55.9+20140913-1+b1 dnstop recommends no packages. dnstop suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776717: hwinfo build is not reproducible
Source: hwinfo Severity: wishlist The package should build reproducibly, see: https://reproducible.debian.net/rb-pkg/hwinfo.html Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776716: miredo is not reproducible
Source: miredo Severity: wishlist The package should be reproducible: https://reproducible.debian.net/rb-pkg/miredo.html Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776713: tiptop: package is not reproducible
Package: tiptop Version: 2.2-2 Severity: wishlist The package is not reproducible: https://reproducible.debian.net/rb-pkg/tiptop.html Cheers, Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tiptop depends on: ii libc62.19-13 ii libncurses5 5.9+20140913-1+b1 ii libtinfo55.9+20140913-1+b1 ii libxml2 2.9.1+dfsg1-4 tiptop recommends no packages. tiptop suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776715: pax-utils are not reproducible
Package: pax-utils Version: 0.8.1-1 Severity: wishlist The package build is not reproducible, see: https://reproducible.debian.net/rb-pkg/pax-utils.html Tomasz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pax-utils depends on: ii libc62.19-13 ii libcap2 1:2.24-6 pax-utils recommends no packages. Versions of packages pax-utils suggests: pn paxctl none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744192: abandoned
On 01/05/14 15:27, Fernando Toledo wrote: it seems to have been abandoned i will try to build it on unstable with pbuilder. and contact to another DD to get into the debian archive again more info: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739131 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713655 -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar Hi guys, I've repackaged a new release (which should be considered beta-like according to the developers) here: http://anonscm.debian.org/cgit/collab-maint/synapse.git You can build it from the git for now, but I'll work to bring it back to Debian. It won't be in testing, though. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738483: python-gnupg: list_keys fails with debian-keyring due to UTF-8 corruption
On 25/02/14 14:32, Gerald Turner wrote: Control: found -1 0.3.6-1 [...] Hi Gerald, I've hit the same problem. Here is a dirty fix for you: import gnupg from pprint import pprint keyring = gnupg.GPG(keyring = /usr/share/keyrings/debian-keyring.gpg) keyring.decode_errors = 'replace' # - to replace decode errors with \ufffd keys = keyring.list_keys() # this shows a list of keys with crazy UIDs pprint([ k for k in keys if any(u'\ufffd' in uid for uid in x['uids']) ]) I think that we could ask José to remove this unfortunate UID from the keyring... Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775194: RFS: mininet/2.2.0 ITP - process-based network emulator
On 17/01/15 22:02, Vincent Bernat wrote: ❦ 12 janvier 2015 16:59 +0100, Vincent Bernat ber...@debian.org : I have not tested the result, but the package looks good otherwise. I've just reuploaded the package to mentors. It should be visible in few minutes. I'll try the package later. I am fine with the package as is. What do you think about what I said about debian/copyright and the MIT/Expat license? -- Debian package sponsoring guidelines: http://vincent.bernat.im/en/debian-package-sponsoring.html Hi Vincent, my only concern is that the text of the license is not literally the MIT/Expat license so I would prefer to call it differently. See (https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification): These short names have the specified meanings across all uses of this file format, and must not be used to refer to any other licenses. Parsers may thus rely on these short names referring to the same licenses wherever they occur, without needing to parse or compare the full license text. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775194: RFS: mininet/2.2.0 ITP - process-based network emulator
On 17/01/15 22:33, Vincent Bernat wrote: ❦ 17 janvier 2015 22:17 +0100, Tomasz Buchert tomasz.buch...@inria.fr : I am fine with the package as is. What do you think about what I said about debian/copyright and the MIT/Expat license? my only concern is that the text of the license is not literally the MIT/Expat license so I would prefer to call it differently. See (https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification): These short names have the specified meanings across all uses of this file format, and must not be used to refer to any other licenses. Parsers may thus rely on these short names referring to the same licenses wherever they occur, without needing to parse or compare the full license text. OK, I don't mind. We'll see what FTP masters will say about that. The package is ready to upload, should I? -- Debian package sponsoring guidelines: http://vincent.bernat.im/en/debian-package-sponsoring.html I believe so :). Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775194: RFS: mininet/2.2.0 ITP - process-based network emulator
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package mininet: * Package name: mininet Version : 2.2.0 Upstream Author : Bob Lantz et al. * URL : http://mininet.org/ * License : BSD-like (mininet-license) Section : net It builds those binary packages: mininet - process-based network emulator To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mininet Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mininet/mininet_2.2.0-1.dsc More information about hello can be obtained from http://www.mininet.org. Notes: * the package was difficult to prepare for reasons related to open vswitch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757761; the bug was workarounded and the new version does not require Openswitch controller in the system (it will degrade to pure software switch, see: https://github.com/mininet/mininet/pull/432) Regards, T. Buchert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775194: RFS: mininet/2.2.0 ITP - process-based network emulator
On 12/01/15 15:03, Vincent Bernat wrote: ❦ 12 janvier 2015 14:30 +0100, Tomasz Buchert tomasz.buch...@inria.fr : It builds those binary packages: mininet - process-based network emulator To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mininet Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mininet/mininet_2.2.0-1.dsc More information about hello can be obtained from http://www.mininet.org. In Ubuntu, the package is maintained by James Page. I pinged him a week ago about packaging it in Debian but got no answer. Your package seems an original work. Did you try to reach James about that? Did you look at how the problems you got have been solved in this version? Hi Vincent, I don't quite remember if I have met James electronically yet. I know, however, that Ubuntu packaging of openvswitch provided openvswitch-controller which solved the problem for them. This is described in the bug #757761. About the package: - in d/control, you recommend openvswitch-controller but no such package exists in Debian. Thanks, my bad. - in d/copyright, you license debian/* under GPL-2+ but since the original software is licensed as MIT, it would be better to use the same license. This allows upstream to integrate your changes more easily. That makes sense. However, the license is *not* MIT literally speaking (https://mailman.stanford.edu/pipermail/mininet-discuss/2014-August/004879.html). I renamed the license to mit-mininet-license and used the same license for debian/* as you proposed. - in d/copyright, the license is MIT with a preface, just use MIT as the keyword (but keep the whole license). See above. - in d/repack, why is this script here if not used? Well spotted. I removed it (note, however, that there is a comment at the beginning saying that it may be used one day). - in d/rules, you use python_distutils as a build system, this will call python setup.py clean in dh_auto_clean, not make clean. This explains why you have to use make clean. As for CPPFLAGS, this is because the Makefile don't include it. I think both of your fixes are fine. Ok, I removed todos. - d/TODO should be removed if those problems are solved. Done. I have not tested the result, but the package looks good otherwise. I've just reuploaded the package to mentors. It should be visible in few minutes. Thanks a lot, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775192: ITP: mininet -- process-based network emulator
Package: wnpp Severity: wishlist Owner: Tomasz Buchert tomasz.buch...@inria.fr * Package name: mininet Version : 2.2.0 Upstream Author : Bob Lantz et al. * URL : http://mininet.org/ * License : BSD-like (mininet-license) Programming Lang: Python Description : process-based network emulator Mininet is a network emulator which uses lightweight virtualization to create virtual networks for rapid prototyping of Software-Defined Network (SDN) designs using OpenFlow. The package will be maintained by me and D. Dwornikowski (more details in the incoming RFS). Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741451: Bugfix
On 23/12/14 16:00, Jay Berkenbilt wrote: Thanks, Tomasz, for preparing the NMU and Balint for uploading! I've tweaked the DEP-3 stuff in the patch a little and changed its name, and am preparing a regular, non-NMU upload which I will upload momentarily. I've given Tomasz credit for the fix. Sorry for not being more on top of it. Your good efforts made my job trivial. Thanks! I have also submitted an unblock request to the release team. -- Jay Berkenbilt q...@debian.org Great! :D Merry Christmas! Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741451: Bugfix
On 22/12/14 18:08, Tomasz Buchert wrote:
On 19/12/14 22:05, Balint Reczey wrote:
Hi Jay,
[...]
Cheers,
Balint
Hi guys,
I didn't notice that upstream made a fix based on what I found. I'll
try to prepare an NMU right now.
Tomasz
Here is a NMU. Feel free to adapt it if you
feel like it.
Tomasz
diff -Nru tiff-4.0.3/debian/changelog tiff-4.0.3/debian/changelog
--- tiff-4.0.3/debian/changelog 2014-06-29 23:32:44.0 +0200
+++ tiff-4.0.3/debian/changelog 2014-12-22 18:51:23.0 +0100
@@ -1,3 +1,10 @@
+tiff (4.0.3-10.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Don't crash on JPEG = non-JPEG conversion (Closes: #741451)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Tue, 28 Oct 2014 18:11:18 +0100
+
tiff (4.0.3-10) unstable; urgency=medium
* Remove libtiff4-dev, completing the tiff transition. Packages that
diff -Nru tiff-4.0.3/debian/patches/bug-741451.patch tiff-4.0.3/debian/patches/bug-741451.patch
--- tiff-4.0.3/debian/patches/bug-741451.patch 1970-01-01 01:00:00.0 +0100
+++ tiff-4.0.3/debian/patches/bug-741451.patch 2014-12-22 19:09:35.0 +0100
@@ -0,0 +1,36 @@
+Description: fix for Debian bug #741451
+ tiffcp crashes when converting JPEG-encoded TIFF to a different
+ encoding (like none or lzw). For example this will probably fail:
+ .
+tiffcp -c none jpeg_encoded_file.tif output.tif
+ .
+ The reason is that when the input file contains JPEG data,
+ the tiffcp code forces conversion to RGB space. However,
+ the output normally inherits YCbCr subsampling parameters
+ from the input, which leads to a smaller working buffer
+ than necessary. The buffer is subsequently overrun inside
+ cpStripToTile() (called from writeBufferToContigTiles).
+ Note that the resulting TIFF file would be scrambled even
+ if tiffcp wouldn't crash, since the output file would contain
+ RGB data intepreted as subsampled YCbCr values.
+ .
+ This patch fixes the problem by forcing RGB space on the output
+ TIF if the input is JPEG-encoded and output is *not* JPEG-encoded.
+ Fixed upstream: http://bugzilla.maptools.org/show_bug.cgi?id=2480
+Author: Tomasz Buchert tomasz.buch...@inria.fr
+
+--- a/tools/tiffcp.c
b/tools/tiffcp.c
+@@ -629,6 +629,12 @@
+ TIFFSetField(out, TIFFTAG_PHOTOMETRIC,
+ samplesperpixel == 1 ?
+ PHOTOMETRIC_LOGL : PHOTOMETRIC_LOGLUV);
++ else if (input_compression == COMPRESSION_JPEG
++ samplesperpixel == 3) {
++ /* RGB conversion was forced above
++ hence the output will be of the same type */
++ TIFFSetField(out, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB);
++ }
+ else
+ CopyTag(TIFFTAG_PHOTOMETRIC, 1, TIFF_SHORT);
+ if (fillorder != 0)
diff -Nru tiff-4.0.3/debian/patches/series tiff-4.0.3/debian/patches/series
--- tiff-4.0.3/debian/patches/series 2014-06-29 23:32:44.0 +0200
+++ tiff-4.0.3/debian/patches/series 2014-12-22 18:51:23.0 +0100
@@ -6,3 +6,4 @@
CVE-2013-4232.patch
CVE-2013-4244.patch
CVE-2013-4243.patch
+bug-741451.patch
Bug#741451: Bugfix
On 19/12/14 22:05, Balint Reczey wrote: Hi Jay, [...] Cheers, Balint Hi guys, I didn't notice that upstream made a fix based on what I found. I'll try to prepare an NMU right now. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718596: [Pkg-bluetooth-maintainers] Bug#718596: (no subject)
On 03/12/14 08:47, Habib Seifzadeh wrote: Dear Nobuhiro, Thanks a lot, Bluez-obexd solved the problem. Both send and receive works perfectly, Cheers, Habib On 12/03/2014 04:19 AM, Nobuhiro Iwamatsu wrote: Hi, obexd is already obsolete. Also different because API can not be used in GNOME, KDE and other. Please use the bluez-obexd instead. Best regards, Nobuhiro Hi guys, I confirm that today, after upgrade of my packages, I can transfer files from/to my phone using gnome-bluetooth. It means, I guess, that you can close (or maybe donwgrade) this bug. Thanks Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771317: unblock: ruby-pygments.rb/0.5.4~ds1-1.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package ruby-pygments.rb
During BSP in Munich we created an NMU patch that fixed
the bug https://bugs.debian.org/768615 . The debdiff is
attached.
unblock ruby-pygments.rb/0.5.4~ds1-1.1
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
diff -Nru ruby-pygments.rb-0.5.4~ds1/debian/changelog ruby-pygments.rb-0.5.4~ds1/debian/changelog
--- ruby-pygments.rb-0.5.4~ds1/debian/changelog 2014-04-04 04:06:32.0 +0200
+++ ruby-pygments.rb-0.5.4~ds1/debian/changelog 2014-11-22 17:17:34.0 +0100
@@ -1,3 +1,10 @@
+ruby-pygments.rb (0.5.4~ds1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update the testsuite (Closes: #768615)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Sat, 22 Nov 2014 15:18:14 +0100
+
ruby-pygments.rb (0.5.4~ds1-1) unstable; urgency=low
* Initial release (Closes: #703188)
diff -Nru ruby-pygments.rb-0.5.4~ds1/debian/patches/0007-Update-test-result.patch ruby-pygments.rb-0.5.4~ds1/debian/patches/0007-Update-test-result.patch
--- ruby-pygments.rb-0.5.4~ds1/debian/patches/0007-Update-test-result.patch 2014-04-04 03:54:49.0 +0200
+++ ruby-pygments.rb-0.5.4~ds1/debian/patches/0007-Update-test-result.patch 2014-11-22 17:17:34.0 +0100
@@ -1,18 +1,28 @@
Description: Update test result
Subject: Update test result
- Using old test result.
+ The upstream testsuite is using an embedded pygments version, which
+ at the moment of writing this is 2.0pre. The version in Debian is
+ slightly different (2.0rc1) and there are some minor mismatches. Most
+ importantly, the Debian version is unable to find a good lexer for
+ ambigous code a. It is fixed by forcing it to use Ruby lexer.
Already reported upstream https://github.com/tmm1/pygments.rb/issues/118
Author: Per Andersson avtob...@gmail.com
---
--- a/test/test_pygments.rb
+++ b/test/test_pygments.rb
-@@ -32,7 +32,7 @@
- def test_highlight_works_with_larger_files
- code = P.highlight(REDIS_CODE)
- assert_match 'used_memory_peak_human', code
--assert_equal 455203, code.bytesize.to_i
-+assert_equal 454107, code.bytesize.to_i
+@@ -88,7 +88,7 @@
end
- def test_returns_nil_on_timeout
+ def test_highlight_works_with_single_character_input
+-code = P.highlight(a)
++code = P.highlight(a, :lexer = 'ruby')
+ assert_match 'a/span', code
+ end
+
+@@ -283,5 +283,3 @@
+ assert list['Html'][:aliases].include?('html')
+ end
+ end
+-
+-
Bug#771320: unblock: latex-mk/2.1-1.3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package latex-mk
This is an NMU patch removes dependency on tgif
which, with high confidence, is not going to be released with jessie.
Tgif is not an essential dependency and latex-mk is goind to work
just fine. If the user tries to use tgif functionality, she/he
will be shown a message showing that tgif support is not available.
The patch is attached.
unblock latex-mk/2.1-1.3
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
diff -Nru latex-mk-2.1/debian/changelog latex-mk-2.1/debian/changelog
--- latex-mk-2.1/debian/changelog 2014-04-25 16:45:24.0 +0200
+++ latex-mk-2.1/debian/changelog 2014-11-22 20:19:57.0 +0100
@@ -1,3 +1,10 @@
+latex-mk (2.1-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Disable support and dependency on tgif (Closes: #768690)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Sat, 22 Nov 2014 18:14:45 +0100
+
latex-mk (2.1-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru latex-mk-2.1/debian/control latex-mk-2.1/debian/control
--- latex-mk-2.1/debian/control 2014-04-25 16:44:02.0 +0200
+++ latex-mk-2.1/debian/control 2014-11-22 20:19:57.0 +0100
@@ -6,7 +6,7 @@
Build-Depends-Indep: texlive-base, texlive-latex-base, texlive-latex-extra,
texlive-latex-recommended, texlive-fonts-recommended, texinfo, xsltproc,
docbook-xsl, graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig, csh, autoconf
+ ghostscript, transfig, csh, autoconf
Standards-Version: 3.9.2
Homepage: http://latex-mk.sourceforge.net/
@@ -15,7 +15,7 @@
Depends: ${misc:Depends}
Recommends: make, texlive-latex-recommended, texlive-base
Suggests: graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig
+ ghostscript, transfig
Description: tool for managing LaTeX projects
LaTeX-Mk is a collection of Makefile fragments and shell scripts for
managing small to large sized LaTeX projects. The typical LaTeX-Mk
diff -Nru latex-mk-2.1/debian/patches/disable-tgif.patch latex-mk-2.1/debian/patches/disable-tgif.patch
--- latex-mk-2.1/debian/patches/disable-tgif.patch 1970-01-01 01:00:00.0 +0100
+++ latex-mk-2.1/debian/patches/disable-tgif.patch 2014-11-22 20:19:57.0 +0100
@@ -0,0 +1,28 @@
+Description: Disables build dependency on tgif
+ tgif was removed from testing for various reasons.
+ First, its dependencies are not in testing (see https://bugs.debian.org/699301)
+ and then its own status is ambiguous (see https://bugs.debian.org/668249).
+ This patch disables tgif-related functionality by showing error
+ message if the user wants to use it.
+ .
+ latex-mk (2.1-1.3) unstable; urgency=medium
+ .
+ * Non-maintainer upload.
+ * Disable support and dependency on tgif (Closes: #768690)
+Author: Tomasz Buchert tomasz.buch...@inria.fr
+Bug-Debian: https://bugs.debian.org/768690
+
+--- a/latex.mk.in.in
b/latex.mk.in.in
+@@ -432,9 +432,11 @@
+ # pull in tgif.[g]mk if needed
+
+ BMK:.if defined(_USE_TGIF_MK)
++BMK:.error Support for tgif files is not available, see https://bugs.debian.org/768690
+ BMK:.include ${LATEX_MK_DIR}/tgif.mk
+ BMK:.endif
+ GMK:ifdef _USE_TGIF_MK
++GMK:$(error Support for tgif files is not available, see https://bugs.debian.org/768690)
+ GMK:include ${LATEX_MK_DIR}/tgif.gmk
+ GMK:endif
+
diff -Nru latex-mk-2.1/debian/patches/series latex-mk-2.1/debian/patches/series
--- latex-mk-2.1/debian/patches/series 2011-06-22 04:36:52.0 +0200
+++ latex-mk-2.1/debian/patches/series 2014-11-22 20:19:57.0 +0100
@@ -2,3 +2,4 @@
use-fancyhdr.patch
new-nomencl.patch
use-gunzip-instead-of-gzcat.patch
+disable-tgif.patch
Bug#768615: #768615: ruby-pygments.rb: FTBFS in jessie: ERROR: Test ruby2.1 failed
On 24/11/14 14:21, Christian Hofstaedtler wrote: Tobias, Tomasz, Thank you for working on this. Feel free to reschedule the NMU to an earlier date (e.g. immediate). Best, -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- Hi Christian, I think I made a mistake in this NMU, the changelog uploads it to unstable, but I think it should be testing instead (on the other hand you may unblock transition unstable = testing if I'm correct). Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768690: latex-mk: FTBFS in jessie: build-dependency not installable: tgif
On 22/11/14 20:28, Tobias Frost wrote:
Control: tags -1 pending
Uploaded to DELAYED/5
Thanks Thomasz!
--
tobi
I think that my NMU is wrong since it uploads into unstable, but
it should be testing instead. Sorry for trouble, I attach a
modified NMU.
Tomasz
diff -Nru latex-mk-2.1/debian/changelog latex-mk-2.1/debian/changelog
--- latex-mk-2.1/debian/changelog 2014-04-25 16:45:24.0 +0200
+++ latex-mk-2.1/debian/changelog 2014-11-22 18:15:40.0 +0100
@@ -1,3 +1,10 @@
+latex-mk (2.1-1.3) testing; urgency=medium
+
+ * Non-maintainer upload.
+ * Disable support and dependency on tgif (Closes: #768690)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Sat, 22 Nov 2014 18:14:45 +0100
+
latex-mk (2.1-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru latex-mk-2.1/debian/control latex-mk-2.1/debian/control
--- latex-mk-2.1/debian/control 2014-04-25 16:44:02.0 +0200
+++ latex-mk-2.1/debian/control 2014-11-22 18:14:34.0 +0100
@@ -6,7 +6,7 @@
Build-Depends-Indep: texlive-base, texlive-latex-base, texlive-latex-extra,
texlive-latex-recommended, texlive-fonts-recommended, texinfo, xsltproc,
docbook-xsl, graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig, csh, autoconf
+ ghostscript, transfig, csh, autoconf
Standards-Version: 3.9.2
Homepage: http://latex-mk.sourceforge.net/
@@ -15,7 +15,7 @@
Depends: ${misc:Depends}
Recommends: make, texlive-latex-recommended, texlive-base
Suggests: graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig
+ ghostscript, transfig
Description: tool for managing LaTeX projects
LaTeX-Mk is a collection of Makefile fragments and shell scripts for
managing small to large sized LaTeX projects. The typical LaTeX-Mk
diff -Nru latex-mk-2.1/debian/patches/disable-tgif.patch latex-mk-2.1/debian/patches/disable-tgif.patch
--- latex-mk-2.1/debian/patches/disable-tgif.patch 1970-01-01 01:00:00.0 +0100
+++ latex-mk-2.1/debian/patches/disable-tgif.patch 2014-11-22 18:57:09.0 +0100
@@ -0,0 +1,28 @@
+Description: Disables build dependency on tgif
+ tgif was removed from testing for various reasons.
+ First, its dependencies are not in testing (see https://bugs.debian.org/699301)
+ and then its own status is ambiguous (see https://bugs.debian.org/668249).
+ This patch disables tgif-related functionality by showing error
+ message if the user wants to use it.
+ .
+ latex-mk (2.1-1.3) unstable; urgency=medium
+ .
+ * Non-maintainer upload.
+ * Disable support and dependency on tgif (Closes: #768690)
+Author: Tomasz Buchert tomasz.buch...@inria.fr
+Bug-Debian: https://bugs.debian.org/768690
+
+--- a/latex.mk.in.in
b/latex.mk.in.in
+@@ -432,9 +432,11 @@
+ # pull in tgif.[g]mk if needed
+
+ BMK:.if defined(_USE_TGIF_MK)
++BMK:.error Support for tgif files is not available, see https://bugs.debian.org/768690
+ BMK:.include ${LATEX_MK_DIR}/tgif.mk
+ BMK:.endif
+ GMK:ifdef _USE_TGIF_MK
++GMK:$(error Support for tgif files is not available, see https://bugs.debian.org/768690)
+ GMK:include ${LATEX_MK_DIR}/tgif.gmk
+ GMK:endif
+
diff -Nru latex-mk-2.1/debian/patches/series latex-mk-2.1/debian/patches/series
--- latex-mk-2.1/debian/patches/series 2011-06-22 04:36:52.0 +0200
+++ latex-mk-2.1/debian/patches/series 2014-11-22 18:17:49.0 +0100
@@ -2,3 +2,4 @@
use-fancyhdr.patch
new-nomencl.patch
use-gunzip-instead-of-gzcat.patch
+disable-tgif.patch
Bug#768695: Bug #768695: statsmodels: FTBFS in jessie: ImportError: cannot import name DateRange
Good idea, feel free to change the patch. I won't be able to do it before the evening. Tomasz On 25/11/14 20:51, Yaroslav Halchenko wrote: On Wed, 26 Nov 2014, Tomasz Buchert wrote: + import pandas as _ +-return True ++return hasattr(_, DateRange) imho this is way too aggressive and would cause skipping all pandas related tests (DateRange dependent or not) + except ImportError: + return False + +Index: statsmodels-0.4.2/statsmodels/tsa/base/tests/test_datetools.py +=== +--- statsmodels-0.4.2.orig/statsmodels/tsa/base/tests/test_datetools.py statsmodels-0.4.2/statsmodels/tsa/base/tests/test_datetools.py +@@ -3,6 +3,7 @@ import numpy.testing as npt + from statsmodels.tsa.base.datetools import (_date_from_idx, + _idx_from_dates, date_parser, date_range_str, dates_from_str, + dates_from_range, _infer_freq, _freq_to_pandas) ++import nose + + def test_date_from_idx(): + d1 = datetime(2008, 12, 31) +@@ -15,6 +16,7 @@ def test_date_from_idx(): + npt.assert_equal(_date_from_idx(d1, idx, 'M'), datetime(2010, 3, 31)) + + def test_idx_from_date(): ++raise nose.SkipTest(Skipped because of missing DateRange) if you are introducing these changes, why not to make def skip_if_no_daterange(): try: import pandas as _ if not hasaattr(_, DateRange): raise nose.SkipTest(Skipped because...) except ImportError: raise nose.SkipTest(Skipped because no pandas...) and just call that one? -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718596: Grave severity
severity 718596 grave thanks I think we all agree that it deserves to be an RC bug. I am completely unable to use bluetooth to send/recv files to/from my phone. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768673: NMU patch
Hi,
I attach my NMU debdiff that fixes this issue.
Feel free to change the changelog and upload it
in a standard way.
Cheers,
Tomasz
diff -Nru ruby-httpclient-2.3.3/debian/changelog ruby-httpclient-2.3.3/debian/changelog
--- ruby-httpclient-2.3.3/debian/changelog 2014-06-27 03:03:36.0 +0200
+++ ruby-httpclient-2.3.3/debian/changelog 2014-11-26 12:00:23.0 +0100
@@ -1,3 +1,10 @@
+ruby-httpclient (2.3.3-3.1) testing; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix default SSL configuration (Closes: #768673)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Wed, 26 Nov 2014 18:59:26 +0100
+
ruby-httpclient (2.3.3-3) unstable; urgency=medium
* fix-port-allocation-in-tests.patch: fix port allocation for servers
diff -Nru ruby-httpclient-2.3.3/debian/patches/0003-fix-ssl-config.patch ruby-httpclient-2.3.3/debian/patches/0003-fix-ssl-config.patch
--- ruby-httpclient-2.3.3/debian/patches/0003-fix-ssl-config.patch 1970-01-01 01:00:00.0 +0100
+++ ruby-httpclient-2.3.3/debian/patches/0003-fix-ssl-config.patch 2014-11-26 11:57:16.0 +0100
@@ -0,0 +1,64 @@
+Description: Change default SSL configuration
+ The POODLE attack (https://en.wikipedia.org/wiki/POODLE) deprecated the use
+ of SSLv3 protocol. We change the default configuration to autodetection
+ and try to explicitly disable SSLv2 and SSLv3, preferring TLS protocol suites
+ instead.
+ This patch is a minimal adaptation of a commit in the project's upstream:
+ https://github.com/nahi/httpclient/commit/90d5c791c941c72521784dc4ea8eed60987800da
+
+--- a/lib/httpclient/ssl_config.rb
b/lib/httpclient/ssl_config.rb
+@@ -34,7 +34,13 @@
+ class SSLConfig
+ include OpenSSL if SSLEnabled
+
+-# String name of OpenSSL's SSL version method name: SSLv2, SSLv23 or SSLv3
++# Which TLS protocol version (also called method) will be used. Defaults
++# to :auto which means that OpenSSL decides (In my tests this resulted
++# with always the highest available protocol being used).
++# String name of OpenSSL's SSL version method name: TLSv1_2, TLSv1_1, TLSv1,
++# SSLv2, SSLv23, SSLv3 or :auto (and nil) to allow version negotiation (default).
++# See {OpenSSL::SSL::SSLContext::METHODS} for a list of available versions
++# in your specific Ruby environment.
+ attr_reader :ssl_version
+ # OpenSSL::X509::Certificate:: certificate for SSL client authenticateion.
+ # nil by default. (no client authenticateion)
+@@ -83,8 +89,13 @@
+ @verify_callback = nil
+ @dest = nil
+ @timeout = nil
+- @ssl_version = SSLv3
+- @options = defined?(SSL::OP_ALL) ? SSL::OP_ALL | SSL::OP_NO_SSLv2 : nil
++ @ssl_version = :auto
++ # Follow ruby-ossl's definition
++ @options = OpenSSL::SSL::OP_ALL
++ @options = ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS if defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS)
++ @options |= OpenSSL::SSL::OP_NO_COMPRESSION if defined?(OpenSSL::SSL::OP_NO_COMPRESSION)
++ @options |= OpenSSL::SSL::OP_NO_SSLv2 if defined?(OpenSSL::SSL::OP_NO_SSLv2)
++ @options |= OpenSSL::SSL::OP_NO_SSLv3 if defined?(OpenSSL::SSL::OP_NO_SSLv3)
+ # OpenSSL 0.9.8 default: ALL:!ADH:!LOW:!EXP:!MD5:+SSLv2:@STRENGTH
+ @ciphers = ALL:!aNULL:!eNULL:!SSLv2 # OpenSSL 1.0.0 default
+ @cacerts_loaded = false
+@@ -283,7 +294,7 @@
+ ctx.timeout = @timeout
+ ctx.options = @options
+ ctx.ciphers = @ciphers
+- ctx.ssl_version = @ssl_version
++ ctx.ssl_version = @ssl_version unless @ssl_version == :auto
+ end
+
+ # post connection check proc for ruby 1.8.5.
+--- a/test/test_ssl.rb
b/test/test_ssl.rb
+@@ -33,7 +33,10 @@
+ assert_equal(OpenSSL::SSL::VERIFY_PEER | OpenSSL::SSL::VERIFY_FAIL_IF_NO_PEER_CERT, cfg.verify_mode)
+ assert_nil(cfg.verify_callback)
+ assert_nil(cfg.timeout)
+-assert_equal(OpenSSL::SSL::OP_ALL | OpenSSL::SSL::OP_NO_SSLv2, cfg.options)
++expected_options = OpenSSL::SSL::OP_ALL | OpenSSL::SSL::OP_NO_SSLv2 | OpenSSL::SSL::OP_NO_SSLv3
++expected_options = ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS if defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS)
++expected_options |= OpenSSL::SSL::OP_NO_COMPRESSION if defined?(OpenSSL::SSL::OP_NO_COMPRESSION)
++assert_equal(expected_options, cfg.options)
+ assert_equal(ALL:!aNULL:!eNULL:!SSLv2, cfg.ciphers)
+ assert_instance_of(OpenSSL::X509::Store, cfg.cert_store)
+ end
diff -Nru ruby-httpclient-2.3.3/debian/patches/series ruby-httpclient-2.3.3/debian/patches/series
--- ruby-httpclient-2.3.3/debian/patches/series 2014-06-27 00:41:13.0 +0200
+++ ruby-httpclient-2.3.3/debian/patches/series 2014-11-26 11:49:41.0 +0100
@@ -1,2 +1,3 @@
0001-Remove-Hash-element-order-dependency.patch
fix-port-allocation-in-tests.patch
+0003-fix-ssl-config.patch
Bug#768695: Bug #768695: statsmodels: FTBFS in jessie: ImportError: cannot import name DateRange
Hi, this patch is even more concise. It builds properly on amd64 and i386 (at least). Cheers, Tomasz diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog --- statsmodels-0.4.2/debian/changelog 2012-06-29 23:26:49.0 +0200 +++ statsmodels-0.4.2/debian/changelog 2014-11-26 22:38:12.0 +0100 @@ -1,3 +1,10 @@ +statsmodels (0.4.2-1.1) testing; urgency=medium + + * Non-maintainer upload. + * Fixes various problems with build process (Closes: #768695) + + -- Tomasz Buchert tomasz.buch...@inria.fr Wed, 26 Nov 2014 22:38:48 +0100 + statsmodels (0.4.2-1) unstable; urgency=low * Fresh upstream release addressing FTBFS across big-endian architectures. diff -Nru statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch --- statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch 1970-01-01 01:00:00.0 +0100 +++ statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch 2014-11-26 22:38:12.0 +0100 @@ -0,0 +1,14 @@ +Description: Fix building of docs + See https://github.com/matplotlib/matplotlib/issues/2967 for more info. + +--- a/docs/source/conf.py b/docs/source/conf.py +@@ -33,7 +33,7 @@ + 'matplotlib.sphinxext.plot_directive', + 'matplotlib.sphinxext.only_directives', + 'ipython_console_highlighting', +- 'ipython_directive', ++ 'IPython.sphinxext.ipython_directive', + 'numpy_ext.numpydoc'] + + # plot_directive is broken on old matplotlib diff -Nru statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch --- statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch 1970-01-01 01:00:00.0 +0100 +++ statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch 2014-11-26 22:59:46.0 +0100 @@ -0,0 +1,165 @@ +Description: Fix various testsuite problems + The testsuite depends on version-specific functionality + of various dependencies like numpy or scipy. This patch fixes + problems caused by versions in jessie release of these dependencies. + . + statsmodels/tools/tools.py: + = unexisting attribute in numpy object + statsmodels/sandbox/distributions/tests/testtransf.py: + statsmodels/tsa/filters/tests/test_filters.py: + = scipy interface incompatibilities + statsmodels/tsa/base/tests/test_datetools.py: + = DateRange class is not present in jessie pandas + statsmodels/sandbox/distributions/extras.py: + = a mistake fixed in newer releases of statsmodels + statsmodels/sandbox/tests/test_gam.py: + = incompatible scipy interface for rvs method + statsmodels/discrete/tests/test_discrete.py: + = failures due to differences between architectures, see + https://github.com/statsmodels/statsmodels/commit/ca701e7a + +--- a/statsmodels/tools/tools.py b/statsmodels/tools/tools.py +@@ -231,7 +231,7 @@ + + def _series_add_constant(data, prepend): + const = np.ones_like(data) +-const.name = 'const' ++# const.name = 'const' + if not prepend: + results = DataFrame([data, const]).T + results.columns = [data.name, 'const'] +--- a/statsmodels/sandbox/distributions/tests/testtransf.py b/statsmodels/sandbox/distributions/tests/testtransf.py +@@ -88,8 +88,8 @@ + (absnormalg, stats.halfnorm), + (absnormalg, stats.foldnorm(1e-5)), #try frozen + #(negsquarenormalg, 1-stats.chi2), # won't work as distribution +-(squaretg(10), stats.f(1, 10))] #try both frozen +- ++#(squaretg(10), stats.f(1, 10))] #try both frozen ++] + + l,s = 0.0, 1.0 + self.ppfq = [0.1,0.5,0.9] +--- a/statsmodels/tsa/vector_ar/tests/test_svar.py b/statsmodels/tsa/vector_ar/tests/test_svar.py +@@ -8,6 +8,7 @@ + from results import results_svar + import numpy as np + import numpy.testing as npt ++import nose + + DECIMAL_6 = 6 + DECIMAL_5 = 5 +@@ -29,4 +30,5 @@ + def test_A(self): + assert_almost_equal(self.res1.A, self.res2.A, DECIMAL_4) + def test_B(self): ++raise nose.SkipTest(This test is fixed in newer versions) + assert_almost_equal(self.res1.B, self.res2.B, DECIMAL_4) +--- a/statsmodels/tsa/vector_ar/tests/test_var.py b/statsmodels/tsa/vector_ar/tests/test_var.py +@@ -494,6 +494,7 @@ + resultspath = basepath + '/tsa/vector_ar/tests/results/' + + def get_lutkepohl_data(name='e2'): ++raise nose.SkipTest(Skipped because of missing DateRange) + lut_data = basepath + '/tsa/vector_ar/data/' + path = lut_data + '%s.dat' % name + +--- a/statsmodels/tsa/base/tests/test_datetools.py b/statsmodels/tsa/base/tests/test_datetools.py +@@ -3,6 +3,7 @@ + from statsmodels.tsa.base.datetools import (_date_from_idx, + _idx_from_dates, date_parser, date_range_str, dates_from_str, + dates_from_range, _infer_freq, _freq_to_pandas) ++import nose + + def
Bug#768695: Bug #768695: statsmodels: FTBFS in jessie: ImportError: cannot import name DateRange
On 25/11/14 10:57, Michael Banck wrote: On Sun, Nov 23, 2014 at 07:13:07PM +0100, Michael Banck wrote: Hi have uploaded the attached debdiff targetted at testing-proposed-updates to DELAYED/3-day. See also the pre-approval/unblock bug for relesae.debian.org, #770730. Unfortunately, it FTBFS on i386 still, there are a couple of test suite failures: https://buildd.debian.org/status/fetch.php?pkg=statsmodelsarch=i386ver=0.4.2-1.1stamp=1416885423 Michael Oh no. This is a bit weird, though - these failures are only due to some precision problems. One would think that operations on i386 and amd64 would follow IEEE 754 and give the same result. The testsuite is really, really fragile! I'll take a look later today. Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768695: Bug #768695: statsmodels: FTBFS in jessie: ImportError: cannot import name DateRange
On 25/11/14 16:23, Yaroslav Halchenko wrote: On Tue, 25 Nov 2014, Tomasz Buchert wrote: Hi have uploaded the attached debdiff targetted at testing-proposed-updates to DELAYED/3-day. See also the pre-approval/unblock bug for relesae.debian.org, #770730. Unfortunately, it FTBFS on i386 still, there are a couple of test suite failures: https://buildd.debian.org/status/fetch.php?pkg=statsmodelsarch=i386ver=0.4.2-1.1stamp=1416885423 Michael Oh no. This is a bit weird, though - these failures are only due to some precision problems. One would think that operations on i386 and amd64 would follow IEEE 754 and give the same result. The testsuite is really, really fragile! I'll take a look later today. Thanks in advance for your help In sid we have a better version I believe, but it fell through the freeze (for those failing tests never migrated to jessie in time) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik Hi, here is a new NMU with one more patch inside. See its description for more info. As a plus I've simplified and merged 2 older patches. Tomasz diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog --- statsmodels-0.4.2/debian/changelog 2012-06-29 17:26:49.0 -0400 +++ statsmodels-0.4.2/debian/changelog 2014-11-25 20:00:04.0 -0500 @@ -1,3 +1,10 @@ +statsmodels (0.4.2-1.1) testing; urgency=medium + + * Non-maintainer upload. + * Fixes various problems with build process (Closes: #768695) + + -- Tomasz Buchert tomasz.buch...@inria.fr Wed, 26 Nov 2014 01:38:48 +0100 + statsmodels (0.4.2-1) unstable; urgency=low * Fresh upstream release addressing FTBFS across big-endian architectures. diff -Nru statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch --- statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch 1969-12-31 19:00:00.0 -0500 +++ statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch 2014-11-25 19:59:40.0 -0500 @@ -0,0 +1,14 @@ +Description: Fix building of docs + See https://github.com/matplotlib/matplotlib/issues/2967 for more info. + +--- a/docs/source/conf.py b/docs/source/conf.py +@@ -33,7 +33,7 @@ + 'matplotlib.sphinxext.plot_directive', + 'matplotlib.sphinxext.only_directives', + 'ipython_console_highlighting', +- 'ipython_directive', ++ 'IPython.sphinxext.ipython_directive', + 'numpy_ext.numpydoc'] + + # plot_directive is broken on old matplotlib diff -Nru statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch --- statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch 1969-12-31 19:00:00.0 -0500 +++ statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch 2014-11-25 20:15:10.0 -0500 @@ -0,0 +1,169 @@ +Description: Fix various testsuite problems + The testsuite depends on version-specific functionality + of various dependencies like numpy, scipy. This patches fixes + problems caused by versions in jessie release of these dependencies. + . + statsmodels/tools/tools.py: + = unexisting attribute in numpy object + statsmodels/sandbox/distributions/tests/testtransf.py: + statsmodels/tsa/filters/tests/test_filters.py: + = scipy interface incompatibilities + statsmodels/tsa/base/tests/test_datetools.py: + = DateRange class is not present in jessie pandas + statsmodels/sandbox/distributions/extras.py: + = a mistake fixed in newer releases of statsmodels + statsmodels-0.4.2.orig/statsmodels/sandbox/tests/test_gam.py + = incompatible scipy interface for rvs method + +Index: statsmodels-0.4.2/statsmodels/tools/tools.py +=== +--- statsmodels-0.4.2.orig/statsmodels/tools/tools.py statsmodels-0.4.2/statsmodels/tools/tools.py +@@ -231,7 +231,7 @@ def categorical(data, col=None, dictname + + def _series_add_constant(data, prepend): + const = np.ones_like(data) +-const.name = 'const' ++# const.name = 'const' + if not prepend: + results = DataFrame([data, const]).T + results.columns = [data.name, 'const'] +Index: statsmodels-0.4.2/statsmodels/sandbox/distributions/tests/testtransf.py +=== +--- statsmodels-0.4.2.orig/statsmodels/sandbox/distributions/tests/testtransf.py statsmodels-0.4.2/statsmodels/sandbox/distributions/tests/testtransf.py +@@ -88,8 +88,8 @@ class Test_Transf2(object): + (absnormalg, stats.halfnorm), + (absnormalg
Bug#770730: thanks for the NMU
On 24/11/14 08:40, Yaroslav Halchenko wrote: Hi Guys, Thanks for the NMU. Note that that instead of a heavy patch you could have disabled the tests (if we decide to fix by burring bugs away) by extending --exclude=sandbox option in debian/rules without any patch to upstream. Feel welcome to reupload without delay though - a patch is better than no patch ;) -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik Hi Yaroslav, I did not disable the tests on purpose - surely you must see a difference between disabling *all* tests and the tests that fail for reasons that have been understood. I've spent some considerable amount of time to figure why these tests fail and whether it is indeed a *bug*. I still think that there are cases well the interface of scipy will bite you, but I did my best. Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE
On 23/11/14 03:03, Adam Borowski wrote: On Sun, Nov 23, 2014 at 02:07:42AM +0100, Christian Kastner wrote: On 2014-11-23 01:16, Adam Borowski wrote: On Sat, Nov 22, 2014 at 09:09:55PM +0100, Tomasz Buchert wrote: On 10/11/14 10:56, Christian Kastner wrote: I cannot confirm this bug in both cases I've tried: * amd64 (Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64 GNU/Linux) * amrhf (Linux 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 2014 armv7l GNU/Linux) My tests: armhf 3.8.13.28: FTBFS Was this either a Debian or a vanilla kernel? I ask because 3.8 kernels are often vendor-provided variants of certain ARM devices. I have heard myths of ARM devices that can run upstream kernels, but I have yet to see one :p. This one is git://github.com/hardkernel/linux, a pretty well behaved one as vendor kernels go. Guys, I went crazy and tested this assertion. I've upgraded the vendor arm kernel to the testing kernel and guess what - it didn't boot... (I'll have to fix it when I'm back home) That said, one of the Debian developers built it for me on armhf 3.16.3 (slightly newer than the testing kernel) and it went fine. If you still think that it may not work in jessie, you could ask for rebuild (https://release.debian.org/wanna-build.txt). If not, you could downgrade the severity to unblock keyutils for the jessie release (I'm not sure if tagging with +sid will stop it being RC). Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE
On 23/11/14 12:55, Christian Kastner wrote: (Tomasz, apparently I forgot to CC you on this mail yesterday, sorry) On 2014-11-23 02:55, Christian Kastner wrote: On 2014-11-23 01:16, Adam Borowski wrote: amd64 vanilla 3.16.7: builds ok amd64 vanilla 3.17.3: FTBFS I can confirm that is issue exists with 3.17. The syscall is returning ENOKEY where until 3.16 it was returning EPERM. I am now quite certain that the issue is being caused by this kernel commit in 3.17: Commit: a4e3b8d79a5c6d40f4a9703abf7fe3abcc6c3b8d KEYS: special dot prefixed keyring name bug fix The thing is, I'm not sure whether this needs to be fixed in keyutils, or in the kernel. I now contacted upstream about this. Depending on the answer, I'll either fix keyutils, or reassign to src:linux. Either way, I tagged this sid as it can only appear with a kernel that will not be part of Jessie. So that should solve the RC problem, no? Thank you for all your work, guys! Christian My pleasure! I think that this bug is not RC anymore - it is not listed here: https://udd.debian.org/bugs/bugs/bugs/bugs/?release=jessie_and_sidpatch=ignmerged=igndone=ignfnewerval=7rc=1sortby=idsorto=ascctags=1ctags=1cdeferred=1#results Good luck with 3.17 :D - if you need help, let me know. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770085: Grave severity
On 23/11/14 15:04, Benjamin Drung wrote: Am Samstag, den 22.11.2014, 12:12 +0100 schrieb Tomasz Buchert: On 22/11/14 11:32, Tomasz Buchert wrote: On 20/11/14 11:54, Tomasz Buchert wrote: [...] Here is a NMU debdiff for this bug. The Debian patches for Python3 support broke Python2 package. It's a story about naming the entry function for a module module which is slightly different in both version of Python. Note that there is a newer upstream version of pyhunspell. If you look for more minimal patch, I can make for you, since gbp pq renamed the original patches. Tomasz Sorry for too overloaded debdiff. Here is a concise one. Thanks for your patch. I have included it and added a smoke test that would have caught this bug. I also updated the watch file to point to the new upstream. Once jessie is released, the new upstream release should be packaged. -- Benjamin Drung Debian Ubuntu Developer Thanks Benjamin, you can package it even now, it will simply stay in unstable. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768695: NMU patch
Hi, I attach a NMU patch which solves the bug at least on AMD64. Please build in jessie environment. Cheers, Tomasz diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog --- statsmodels-0.4.2/debian/changelog 2012-06-29 23:26:49.0 +0200 +++ statsmodels-0.4.2/debian/changelog 2014-11-23 17:55:26.0 +0100 @@ -1,3 +1,10 @@ +statsmodels (0.4.2-1.1) testing; urgency=medium + + * Non-maintainer upload. + * Fixes various problems with build process + + -- Tomasz Buchert tomasz.buch...@inria.fr Sun, 23 Nov 2014 17:46:48 +0100 + statsmodels (0.4.2-1) unstable; urgency=low * Fresh upstream release addressing FTBFS across big-endian architectures. diff -Nru statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch --- statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 1970-01-01 01:00:00.0 +0100 +++ statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 2014-11-23 17:57:08.0 +0100 @@ -0,0 +1,128 @@ +Description: remove tests that use uncompatible scipy interface + The tests use an rvs method which has an incompatible + interface. We remove these failing tests altogother. + +--- statsmodels-0.4.2.orig/statsmodels/sandbox/tests/test_gam.py statsmodels-0.4.2/statsmodels/sandbox/tests/test_gam.py +@@ -187,121 +187,3 @@ class TestAdditiveModel(BaseAM, CheckAM) + const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) + #print const, slopes + res1.params = np.array([const] + slopes) +- +- +-class BaseGAM(BaseAM, CheckGAM): +- +-def init(self): +-nobs = self.nobs +-y_true, x, exog = self.y_true, self.x, self.exog +-if not hasattr(self, 'scale'): +-scale = 1 +-else: +-scale = self.scale +- +-f = self.family +- +-self.mu_true = mu_true = f.link.inverse(y_true) +- +-np.random.seed(8765993) +-#y_obs = np.asarray([stats.poisson.rvs(p) for p in mu], float) +-y_obs = self.rvs(mu_true, scale=scale, size=nobs) #this should work +-m = GAM(y_obs, x, family=f) #TODO: y_obs is twice __init__ and fit +-m.fit(y_obs, maxiter=100) +-res_gam = m.results +-self.res_gam = res_gam #attached for debugging +-self.mod_gam = m #attached for debugging +- +-res_glm = GLM(y_obs, exog, family=f).fit() +- +-#Note: there still are some naming inconsistencies +-self.res1 = res1 = Dummy() #for gam model +-#res2 = Dummy() #for benchmark +-self.res2 = res2 = res_glm #reuse existing glm results, will add additional +- +-#eta in GLM terminology +-res2.y_pred = res_glm.model.predict(res_glm.params, exog, linear=True) +-res1.y_pred = res_gam.predict(x) +-res1.y_predshort = res_gam.predict(x[:10]) #, linear=True) +- +-#mu +-res2.mu_pred = res_glm.model.predict(res_glm.params, exog, linear=False) +-res1.mu_pred = res_gam.mu +- +-#parameters +-slopes = [i for ss in m.smoothers for i in ss.params[1:]] +-const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) +-res1.params = np.array([const] + slopes) +- +- +-class TestGAMPoisson(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Poisson() +-self.rvs = stats.poisson.rvs +- +-self.init() +- +-class TestGAMBinomial(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Binomial() +-self.rvs = stats.bernoulli.rvs +- +-self.init() +- +-class _estGAMGaussianLogLink(BaseGAM): +-#test failure, but maybe precision issue, not far off +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true)) +-#0.80409736263199649 +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true))/tt.mu_true.mean() +-#0.023258245077813208 +-# np.mean((tt.res2.mu_pred - tt.mu_true)**2)/tt.mu_true.mean() +-#0.022989403735692578 +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Gaussian(links.log) +-self.rvs = stats.norm.rvs +-self.scale = 5 +- +-self.init() +- +- +-class TestGAMGamma(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Gamma(links.log) +-self.rvs = stats.gamma.rvs +- +-self.init() +- +-class _estGAMNegativeBinomial(BaseGAM): +-#rvs generation doesn't work, nbinom needs 2 parameters +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.NegativeBinomial() +-self.rvs = stats.nbinom.rvs +- +-self.init() +- +-if __name__ == '__main__': +-t1 = TestAdditiveModel() +-t1
Bug#768695: Updated NMU patch
Here is a patch with 2 modifications: 1) d/changelog: added (Closes: ...) 2) altogother = altogether Cheers, Tomasz diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog --- statsmodels-0.4.2/debian/changelog 2012-06-29 23:26:49.0 +0200 +++ statsmodels-0.4.2/debian/changelog 2014-11-23 17:55:26.0 +0100 @@ -1,3 +1,10 @@ +statsmodels (0.4.2-1.1) testing; urgency=medium + + * Non-maintainer upload. + * Fixes various problems with build process (Closes: #768695) + + -- Tomasz Buchert tomasz.buch...@inria.fr Sun, 23 Nov 2014 17:46:48 +0100 + statsmodels (0.4.2-1) unstable; urgency=low * Fresh upstream release addressing FTBFS across big-endian architectures. diff -Nru statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch --- statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 1970-01-01 01:00:00.0 +0100 +++ statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch 2014-11-23 17:57:08.0 +0100 @@ -0,0 +1,128 @@ +Description: remove tests that use uncompatible scipy interface + The tests use an rvs method which has an incompatible + interface. We remove these failing tests altogether. + +--- statsmodels-0.4.2.orig/statsmodels/sandbox/tests/test_gam.py statsmodels-0.4.2/statsmodels/sandbox/tests/test_gam.py +@@ -187,121 +187,3 @@ class TestAdditiveModel(BaseAM, CheckAM) + const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) + #print const, slopes + res1.params = np.array([const] + slopes) +- +- +-class BaseGAM(BaseAM, CheckGAM): +- +-def init(self): +-nobs = self.nobs +-y_true, x, exog = self.y_true, self.x, self.exog +-if not hasattr(self, 'scale'): +-scale = 1 +-else: +-scale = self.scale +- +-f = self.family +- +-self.mu_true = mu_true = f.link.inverse(y_true) +- +-np.random.seed(8765993) +-#y_obs = np.asarray([stats.poisson.rvs(p) for p in mu], float) +-y_obs = self.rvs(mu_true, scale=scale, size=nobs) #this should work +-m = GAM(y_obs, x, family=f) #TODO: y_obs is twice __init__ and fit +-m.fit(y_obs, maxiter=100) +-res_gam = m.results +-self.res_gam = res_gam #attached for debugging +-self.mod_gam = m #attached for debugging +- +-res_glm = GLM(y_obs, exog, family=f).fit() +- +-#Note: there still are some naming inconsistencies +-self.res1 = res1 = Dummy() #for gam model +-#res2 = Dummy() #for benchmark +-self.res2 = res2 = res_glm #reuse existing glm results, will add additional +- +-#eta in GLM terminology +-res2.y_pred = res_glm.model.predict(res_glm.params, exog, linear=True) +-res1.y_pred = res_gam.predict(x) +-res1.y_predshort = res_gam.predict(x[:10]) #, linear=True) +- +-#mu +-res2.mu_pred = res_glm.model.predict(res_glm.params, exog, linear=False) +-res1.mu_pred = res_gam.mu +- +-#parameters +-slopes = [i for ss in m.smoothers for i in ss.params[1:]] +-const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers]) +-res1.params = np.array([const] + slopes) +- +- +-class TestGAMPoisson(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Poisson() +-self.rvs = stats.poisson.rvs +- +-self.init() +- +-class TestGAMBinomial(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Binomial() +-self.rvs = stats.bernoulli.rvs +- +-self.init() +- +-class _estGAMGaussianLogLink(BaseGAM): +-#test failure, but maybe precision issue, not far off +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true)) +-#0.80409736263199649 +-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true))/tt.mu_true.mean() +-#0.023258245077813208 +-# np.mean((tt.res2.mu_pred - tt.mu_true)**2)/tt.mu_true.mean() +-#0.022989403735692578 +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Gaussian(links.log) +-self.rvs = stats.norm.rvs +-self.scale = 5 +- +-self.init() +- +- +-class TestGAMGamma(BaseGAM): +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.Gamma(links.log) +-self.rvs = stats.gamma.rvs +- +-self.init() +- +-class _estGAMNegativeBinomial(BaseGAM): +-#rvs generation doesn't work, nbinom needs 2 parameters +- +-def __init__(self): +-super(self.__class__, self).__init__() #initialize DGP +- +-self.family = family.NegativeBinomial() +-self.rvs = stats.nbinom.rvs +- +-self.init() +- +-if __name__ == '__main__': +-t1
Bug#770085: Grave severity
On 20/11/14 11:54, Tomasz Buchert wrote: severity 770085 grave thanks I'm bumping the severity to grave since the package is not at all usable. This makes this bug RC. Tomasz Here is a NMU debdiff for this bug. The Debian patches for Python3 support broke Python2 package. It's a story about naming the entry function for a module module which is slightly different in both version of Python. Note that there is a newer upstream version of pyhunspell. If you look for more minimal patch, I can make for you, since gbp pq renamed the original patches. Tomasz diff -Nru pyhunspell-0.1/debian/changelog pyhunspell-0.1/debian/changelog --- pyhunspell-0.1/debian/changelog 2013-06-29 20:27:33.0 +0200 +++ pyhunspell-0.1/debian/changelog 2014-11-22 11:24:20.0 +0100 @@ -1,3 +1,11 @@ +pyhunspell (0.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix Python3 patch that broke Python 2 module + * Bumped standards version to 3.9.6 + + -- Tomasz Buchert tomasz.buch...@inria.fr Sat, 22 Nov 2014 11:11:31 +0100 + pyhunspell (0.1-1) unstable; urgency=low * Initial release. (Closes: #714459) diff -Nru pyhunspell-0.1/debian/control pyhunspell-0.1/debian/control --- pyhunspell-0.1/debian/control 2013-06-29 20:27:35.0 +0200 +++ pyhunspell-0.1/debian/control 2014-11-22 11:08:00.0 +0100 @@ -5,10 +5,11 @@ Build-Depends: debhelper (= 9), libhunspell-dev, python-all-dev, - python3-all-dev + python3-all-dev, + dh-python X-Python-Version: = 2.6 X-Python3-Version: = 3.0 -Standards-Version: 3.9.4 +Standards-Version: 3.9.6 Homepage: https://code.google.com/p/pyhunspell/ Vcs-Git: git://anonscm.debian.org/collab-maint/pyhunspell.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/pyhunspell.git diff -Nru pyhunspell-0.1/debian/patches/0001-license.patch pyhunspell-0.1/debian/patches/0001-license.patch --- pyhunspell-0.1/debian/patches/0001-license.patch 1970-01-01 01:00:00.0 +0100 +++ pyhunspell-0.1/debian/patches/0001-license.patch 2014-11-22 11:02:51.0 +0100 @@ -0,0 +1,888 @@ +From: Benjamin Drung bdr...@debian.org +Date: Sat, 22 Nov 2014 10:55:24 +0100 +Subject: license + +--- + COPYING| 674 + + COPYING.LESSER | 165 ++ + hunspell.c | 7 +- + 3 files changed, 842 insertions(+), 4 deletions(-) + create mode 100644 COPYING + create mode 100644 COPYING.LESSER + +diff --git a/COPYING b/COPYING +new file mode 100644 +index 000..94a9ed0 +--- /dev/null b/COPYING +@@ -0,0 +1,674 @@ ++GNU GENERAL PUBLIC LICENSE ++ Version 3, 29 June 2007 ++ ++ Copyright (C) 2007 Free Software Foundation, Inc. http://fsf.org/ ++ Everyone is permitted to copy and distribute verbatim copies ++ of this license document, but changing it is not allowed. ++ ++Preamble ++ ++ The GNU General Public License is a free, copyleft license for ++software and other kinds of works. ++ ++ The licenses for most software and other practical works are designed ++to take away your freedom to share and change the works. By contrast, ++the GNU General Public License is intended to guarantee your freedom to ++share and change all versions of a program--to make sure it remains free ++software for all its users. We, the Free Software Foundation, use the ++GNU General Public License for most of our software; it applies also to ++any other work released this way by its authors. You can apply it to ++your programs, too. ++ ++ When we speak of free software, we are referring to freedom, not ++price. Our General Public Licenses are designed to make sure that you ++have the freedom to distribute copies of free software (and charge for ++them if you wish), that you receive source code or can get it if you ++want it, that you can change the software or use pieces of it in new ++free programs, and that you know you can do these things. ++ ++ To protect your rights, we need to prevent others from denying you ++these rights or asking you to surrender the rights. Therefore, you have ++certain responsibilities if you distribute copies of the software, or if ++you modify it: responsibilities to respect the freedom of others. ++ ++ For example, if you distribute copies of such a program, whether ++gratis or for a fee, you must pass on to the recipients the same ++freedoms that you received. You must make sure that they, too, receive ++or can get the source code. And you must show them these terms so they ++know their rights. ++ ++ Developers that use the GNU GPL protect your rights with two steps: ++(1) assert copyright on the software, and (2) offer you this License ++giving you legal permission to copy, distribute and/or modify it. ++ ++ For the developers' and authors' protection, the GPL clearly explains ++that there is no warranty for this free software
Bug#770085: Grave severity
On 22/11/14 11:32, Tomasz Buchert wrote:
On 20/11/14 11:54, Tomasz Buchert wrote:
[...]
Here is a NMU debdiff for this bug.
The Debian patches for Python3 support broke Python2 package.
It's a story about naming the entry function for a module
module which is slightly different in both version of Python.
Note that there is a newer upstream version of pyhunspell.
If you look for more minimal patch, I can make for you,
since gbp pq renamed the original patches.
Tomasz
Sorry for too overloaded debdiff. Here is a concise one.
Tomasz
diff -Nru pyhunspell-0.1/debian/changelog pyhunspell-0.1/debian/changelog
--- pyhunspell-0.1/debian/changelog 2013-06-29 20:27:33.0 +0200
+++ pyhunspell-0.1/debian/changelog 2014-11-22 12:08:04.0 +0100
@@ -1,3 +1,10 @@
+pyhunspell (0.1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix Python3 patch that broke Python 2 module (Closes: #770085)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Sat, 22 Nov 2014 11:11:31 +0100
+
pyhunspell (0.1-1) unstable; urgency=low
* Initial release. (Closes: #714459)
diff -Nru pyhunspell-0.1/debian/patches/python3.patch pyhunspell-0.1/debian/patches/python3.patch
--- pyhunspell-0.1/debian/patches/python3.patch 2013-06-29 20:47:03.0 +0200
+++ pyhunspell-0.1/debian/patches/python3.patch 2014-11-22 12:08:04.0 +0100
@@ -34,7 +34,7 @@
HunSpell, /* tp_name */
sizeof(HunSpell), /* tp_basicsize */
0, /* tp_itemsize */
-@@ -259,28 +262,42 @@
+@@ -259,28 +262,51 @@
0, /* tp_new */
};
@@ -54,8 +54,17 @@
-void
-inithunspell(void)
-+PyObject*
-+PyInit_hunspell(void)
++#if PY_MAJOR_VERSION = 3
++#define PYRETURN(x) return (x)
++#else
++#define PYRETURN(x) return
++#endif
++
++#if PY_MAJOR_VERSION = 3
++PyMODINIT_FUNC PyInit_hunspell(void)
++#else
++PyMODINIT_FUNC inithunspell(void)
++#endif
{
PyObject *mod;
@@ -68,17 +77,17 @@
+#endif
if (mod == NULL) {
- return;
-+ return NULL;
++ PYRETURN(NULL);
}
// Fill in some slots in the type, and make it ready
HunSpellType.tp_new = PyType_GenericNew;
if (PyType_Ready(HunSpellType) 0) {
- return;
-+ return NULL;
++ PYRETURN(NULL);
}
// Add the type to the module.
Py_INCREF(HunSpellType);
PyModule_AddObject(mod, HunSpell, (PyObject *)HunSpellType);
-+ return mod;
++ PYRETURN(mod);
}
Bug#768615: Patch
Hi,
this is a NMU debdiff that fixes this bug. The problem is generally
caused by strong dependency on pygments - some testsuite tests may
fail when pygments formatting changes. I guess that they should be
more robust and pygment-version-independent, but well...
Tomasz
diff -Nru ruby-pygments.rb-0.5.4~ds1/debian/changelog ruby-pygments.rb-0.5.4~ds1/debian/changelog
--- ruby-pygments.rb-0.5.4~ds1/debian/changelog 2014-04-04 04:06:32.0 +0200
+++ ruby-pygments.rb-0.5.4~ds1/debian/changelog 2014-11-22 15:18:56.0 +0100
@@ -1,3 +1,10 @@
+ruby-pygments.rb (0.5.4~ds1-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Update the testsuite (Closes: #768615)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Sat, 22 Nov 2014 15:18:14 +0100
+
ruby-pygments.rb (0.5.4~ds1-1) unstable; urgency=low
* Initial release (Closes: #703188)
diff -Nru ruby-pygments.rb-0.5.4~ds1/debian/patches/0007-Update-test-result.patch ruby-pygments.rb-0.5.4~ds1/debian/patches/0007-Update-test-result.patch
--- ruby-pygments.rb-0.5.4~ds1/debian/patches/0007-Update-test-result.patch 2014-04-04 03:54:49.0 +0200
+++ ruby-pygments.rb-0.5.4~ds1/debian/patches/0007-Update-test-result.patch 2014-11-22 15:17:56.0 +0100
@@ -1,18 +1,28 @@
Description: Update test result
Subject: Update test result
- Using old test result.
+ The upstream testsuite is using an embedded pygments version, which
+ at the moment of writing this is 2.0pre. The version in Debian is
+ slightly different (2.0rc1) and there are some minor mismatches. Most
+ importantly, the Debian version is unable to find a good lexer for
+ ambigous code a. It is fixed by forcing it to use Ruby lexer.
Already reported upstream https://github.com/tmm1/pygments.rb/issues/118
Author: Per Andersson avtob...@gmail.com
---
--- a/test/test_pygments.rb
+++ b/test/test_pygments.rb
-@@ -32,7 +32,7 @@
- def test_highlight_works_with_larger_files
- code = P.highlight(REDIS_CODE)
- assert_match 'used_memory_peak_human', code
--assert_equal 455203, code.bytesize.to_i
-+assert_equal 454107, code.bytesize.to_i
+@@ -88,7 +88,7 @@
end
- def test_returns_nil_on_timeout
+ def test_highlight_works_with_single_character_input
+-code = P.highlight(a)
++code = P.highlight(a, :lexer = 'ruby')
+ assert_match 'a/span', code
+ end
+
+@@ -283,5 +283,3 @@
+ assert list['Html'][:aliases].include?('html')
+ end
+ end
+-
+-
Bug#668249: tgif is not DFSG-Free
Hi Carlo, I'm trying to fix https://bugs.debian.org/768690 and I stumbled upon this bug. It seems to me that Mejiko is actually right - even debian/copyright mentions that code is under QPL. What is this DFSG compatible license that you are talking about? Cheers, Tomasz On 10/04/12 02:52, Carlo Segre wrote: I beg to differ. There are two different versions of tgif. One is licensed QPL and the other have a DFSG compatible license. The Debian package has been built from the non-QPL licensed code and non-DFSG bits have been removed with the cooperation of the upstream author. It has been so for more than a decade and therefore will stay in main. Carlo On Tue, 10 Apr 2012, mejiko wrote: Package: tgif Severity: normal Hello. Tgif license is Q Public License version 1.0 . This license is not DFSG-Free. (e.g libcwd) Suggests: 1. Tgif move to non-free. 2. remove Tgif. Thanks. References: http://packages.debian.org/changelogs/pool/main/t/tgif/tgif_4.1.45-3/tgif.copyright http://wiki.debian.org/DFSGLicenses#Q_Public_License_.28QPL.29.2C_Version_1.0 http://lists.debian.org/debian-legal/2004/06/msg00131.html -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tgif depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii gettext 0.18.1.1-3 GNU Internationalization utilities ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libsm62:1.1.1-1 X11 Session Management library ii libx11-6 2:1.3.3-4 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxt61:1.0.7-1 X11 toolkit intrinsics library tgif recommends no packages. tgif suggests no packages. -- Carlo U. Segre -- Duchossois Leadership Professor of Physics Associate Dean for Graduate Admissions, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 se...@iit.edu http://phys.iit.edu/~segre se...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768690: NMU patch
Hi,
this is a lazy solution to this bug: we remove tgif dependency
altogether by not disabling tgif in latex-mk. tgif does not seem to be
available anyway so it is a compromise that has to be made. The user
will see an error message if tgif functionality will be used.
You may notice that some unit tests fail during the build - it is
ok-ish since they were failing before anyway.
Tomasz
diff -Nru latex-mk-2.1/debian/changelog latex-mk-2.1/debian/changelog
--- latex-mk-2.1/debian/changelog 2014-04-25 16:45:24.0 +0200
+++ latex-mk-2.1/debian/changelog 2014-11-22 18:15:40.0 +0100
@@ -1,3 +1,10 @@
+latex-mk (2.1-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Disable support and dependency on tgif (Closes: #768690)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Sat, 22 Nov 2014 18:14:45 +0100
+
latex-mk (2.1-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru latex-mk-2.1/debian/control latex-mk-2.1/debian/control
--- latex-mk-2.1/debian/control 2014-04-25 16:44:02.0 +0200
+++ latex-mk-2.1/debian/control 2014-11-22 18:14:34.0 +0100
@@ -6,7 +6,7 @@
Build-Depends-Indep: texlive-base, texlive-latex-base, texlive-latex-extra,
texlive-latex-recommended, texlive-fonts-recommended, texinfo, xsltproc,
docbook-xsl, graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig, csh, autoconf
+ ghostscript, transfig, csh, autoconf
Standards-Version: 3.9.2
Homepage: http://latex-mk.sourceforge.net/
@@ -15,7 +15,7 @@
Depends: ${misc:Depends}
Recommends: make, texlive-latex-recommended, texlive-base
Suggests: graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig
+ ghostscript, transfig
Description: tool for managing LaTeX projects
LaTeX-Mk is a collection of Makefile fragments and shell scripts for
managing small to large sized LaTeX projects. The typical LaTeX-Mk
diff -Nru latex-mk-2.1/debian/patches/disable-tgif.patch latex-mk-2.1/debian/patches/disable-tgif.patch
--- latex-mk-2.1/debian/patches/disable-tgif.patch 1970-01-01 01:00:00.0 +0100
+++ latex-mk-2.1/debian/patches/disable-tgif.patch 2014-11-22 18:57:09.0 +0100
@@ -0,0 +1,28 @@
+Description: Disables build dependency on tgif
+ tgif was removed from testing for various reasons.
+ First, its dependencies are not in testing (see https://bugs.debian.org/699301)
+ and then its own status is ambiguous (see https://bugs.debian.org/668249).
+ This patch disables tgif-related functionality by showing error
+ message if the user wants to use it.
+ .
+ latex-mk (2.1-1.3) unstable; urgency=medium
+ .
+ * Non-maintainer upload.
+ * Disable support and dependency on tgif (Closes: #768690)
+Author: Tomasz Buchert tomasz.buch...@inria.fr
+Bug-Debian: https://bugs.debian.org/768690
+
+--- a/latex.mk.in.in
b/latex.mk.in.in
+@@ -432,9 +432,11 @@
+ # pull in tgif.[g]mk if needed
+
+ BMK:.if defined(_USE_TGIF_MK)
++BMK:.error Support for tgif files is not available, see https://bugs.debian.org/768690
+ BMK:.include ${LATEX_MK_DIR}/tgif.mk
+ BMK:.endif
+ GMK:ifdef _USE_TGIF_MK
++GMK:$(error Support for tgif files is not available, see https://bugs.debian.org/768690)
+ GMK:include ${LATEX_MK_DIR}/tgif.gmk
+ GMK:endif
+
diff -Nru latex-mk-2.1/debian/patches/series latex-mk-2.1/debian/patches/series
--- latex-mk-2.1/debian/patches/series 2011-06-22 04:36:52.0 +0200
+++ latex-mk-2.1/debian/patches/series 2014-11-22 18:17:49.0 +0100
@@ -2,3 +2,4 @@
use-fancyhdr.patch
new-nomencl.patch
use-gunzip-instead-of-gzcat.patch
+disable-tgif.patch
Bug#768690: NMU patch
Of course I meant:
by DISABLING tgif in ... (spurious not)
Tomasz
On 22/11/14 19:06, Tomasz Buchert wrote:
Hi,
this is a lazy solution to this bug: we remove tgif dependency
altogether by not disabling tgif in latex-mk. tgif does not seem to be
available anyway so it is a compromise that has to be made. The user
will see an error message if tgif functionality will be used.
You may notice that some unit tests fail during the build - it is
ok-ish since they were failing before anyway.
Tomasz
diff -Nru latex-mk-2.1/debian/changelog latex-mk-2.1/debian/changelog
--- latex-mk-2.1/debian/changelog 2014-04-25 16:45:24.0 +0200
+++ latex-mk-2.1/debian/changelog 2014-11-22 18:15:40.0 +0100
@@ -1,3 +1,10 @@
+latex-mk (2.1-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Disable support and dependency on tgif (Closes: #768690)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Sat, 22 Nov 2014 18:14:45 +0100
+
latex-mk (2.1-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru latex-mk-2.1/debian/control latex-mk-2.1/debian/control
--- latex-mk-2.1/debian/control 2014-04-25 16:44:02.0 +0200
+++ latex-mk-2.1/debian/control 2014-11-22 18:14:34.0 +0100
@@ -6,7 +6,7 @@
Build-Depends-Indep: texlive-base, texlive-latex-base, texlive-latex-extra,
texlive-latex-recommended, texlive-fonts-recommended, texinfo, xsltproc,
docbook-xsl, graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf,
cups-bsd,
- ghostscript, tgif, transfig, csh, autoconf
+ ghostscript, transfig, csh, autoconf
Standards-Version: 3.9.2
Homepage: http://latex-mk.sourceforge.net/
@@ -15,7 +15,7 @@
Depends: ${misc:Depends}
Recommends: make, texlive-latex-recommended, texlive-base
Suggests: graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig
+ ghostscript, transfig
Description: tool for managing LaTeX projects
LaTeX-Mk is a collection of Makefile fragments and shell scripts for
managing small to large sized LaTeX projects. The typical LaTeX-Mk
diff -Nru latex-mk-2.1/debian/patches/disable-tgif.patch
latex-mk-2.1/debian/patches/disable-tgif.patch
--- latex-mk-2.1/debian/patches/disable-tgif.patch1970-01-01
01:00:00.0 +0100
+++ latex-mk-2.1/debian/patches/disable-tgif.patch2014-11-22
18:57:09.0 +0100
@@ -0,0 +1,28 @@
+Description: Disables build dependency on tgif
+ tgif was removed from testing for various reasons.
+ First, its dependencies are not in testing (see
https://bugs.debian.org/699301)
+ and then its own status is ambiguous (see https://bugs.debian.org/668249).
+ This patch disables tgif-related functionality by showing error
+ message if the user wants to use it.
+ .
+ latex-mk (2.1-1.3) unstable; urgency=medium
+ .
+ * Non-maintainer upload.
+ * Disable support and dependency on tgif (Closes: #768690)
+Author: Tomasz Buchert tomasz.buch...@inria.fr
+Bug-Debian: https://bugs.debian.org/768690
+
+--- a/latex.mk.in.in
b/latex.mk.in.in
+@@ -432,9 +432,11 @@
+ # pull in tgif.[g]mk if needed
+
+ BMK:.if defined(_USE_TGIF_MK)
++BMK:.error Support for tgif files is not available, see
https://bugs.debian.org/768690
+ BMK:.include ${LATEX_MK_DIR}/tgif.mk
+ BMK:.endif
+ GMK:ifdef _USE_TGIF_MK
++GMK:$(error Support for tgif files is not available, see
https://bugs.debian.org/768690)
+ GMK:include ${LATEX_MK_DIR}/tgif.gmk
+ GMK:endif
+
diff -Nru latex-mk-2.1/debian/patches/series
latex-mk-2.1/debian/patches/series
--- latex-mk-2.1/debian/patches/series2011-06-22 04:36:52.0
+0200
+++ latex-mk-2.1/debian/patches/series2014-11-22 18:17:49.0
+0100
@@ -2,3 +2,4 @@
use-fancyhdr.patch
new-nomencl.patch
use-gunzip-instead-of-gzcat.patch
+disable-tgif.patch
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE
On 10/11/14 10:56, Christian Kastner wrote: Darn, I CCed submit. Sorry about that. I blame my webmail. Hi, I cannot confirm this bug in both cases I've tried: * amd64 (Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) x86_64 GNU/Linux) * amrhf (Linux 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 2014 armv7l GNU/Linux) (I'm sorry, but I cannot verify this on testing kernel on armhf) So for me the bug does not exist. Christian, I propose to downgrade it to normal, or even closing it if Adam doesn't provide more info. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668249: tgif is not DFSG-Free
Hi again Carlo, If the license is the one here: http://bourbon.usc.edu/tgif/copyright.html then the situation is even worse than with QPL: [...] and its documentation for *not-for-profit* purpose (emphasis is mine). This is non-free: https://people.debian.org/~bap/dfsg-faq.html#no_commercial So either: 1) the license is QPL and in this case the situation is a bit ambiguous (but maybe it is ok, IANAL), 2) or the license is royalty-free and then tgif is obviously non-free Tomasz On 22/11/14 15:10, Carlo Segre wrote: Hi Tomasz: I am referring to the page below. http://bourbon.usc.edu/tgif/download.html he calls it free-of-charge butit is a license which was qualified as acceptable when tgif was first put in the archive, before I adopted it. If it is now not acceptable, perhaps it would be a good idea to discuss it with the author who, in my experience, has been very willing to accomodate my requests. Carlo On Sat, 22 Nov 2014, Tomasz Buchert wrote: Hi Carlo, I'm trying to fix https://bugs.debian.org/768690 and I stumbled upon this bug. It seems to me that Mejiko is actually right - even debian/copyright mentions that code is under QPL. What is this DFSG compatible license that you are talking about? Cheers, Tomasz On 10/04/12 02:52, Carlo Segre wrote: I beg to differ. There are two different versions of tgif. One is licensed QPL and the other have a DFSG compatible license. The Debian package has been built from the non-QPL licensed code and non-DFSG bits have been removed with the cooperation of the upstream author. It has been so for more than a decade and therefore will stay in main. Carlo On Tue, 10 Apr 2012, mejiko wrote: Package: tgif Severity: normal Hello. Tgif license is Q Public License version 1.0 . This license is not DFSG-Free. (e.g libcwd) Suggests: 1. Tgif move to non-free. 2. remove Tgif. Thanks. References: http://packages.debian.org/changelogs/pool/main/t/tgif/tgif_4.1.45-3/tgif.copyright http://wiki.debian.org/DFSGLicenses#Q_Public_License_.28QPL.29.2C_Version_1.0 http://lists.debian.org/debian-legal/2004/06/msg00131.html -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tgif depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii gettext 0.18.1.1-3 GNU Internationalization utilities ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libice6 2:1.0.6-2 X11 Inter-Client Exchange library ii libsm62:1.1.1-1 X11 Session Management library ii libx11-6 2:1.3.3-4 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxt61:1.0.7-1 X11 toolkit intrinsics library tgif recommends no packages. tgif suggests no packages. -- Carlo U. Segre -- Duchossois Leadership Professor of Physics Associate Dean for Graduate Admissions, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 se...@iit.edu http://phys.iit.edu/~segre se...@debian.org -- Carlo U. Segre -- Duchossois Leadership Professor of Physics Director, Center for Synchrotron Radiation Research and Instrumentation Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 se...@iit.edu http://phys.iit.edu/~segre se...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770085: Grave severity
severity 770085 grave thanks I'm bumping the severity to grave since the package is not at all usable. This makes this bug RC. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770085: python-hunspell cannot be imported
Package: python-hunspell Version: 0.1-1+b2 Severity: important Dear Maintainer, * What led up to the situation? I wanted to use hunspell dictionaries from Python. * What exactly did you do (or not do) that was effective (or ineffective)? I did: $ sudo apt-get install python-hunspell $ ipython --no-banner In [1]: import hunspell --- ImportError Traceback (most recent call last) ipython-input-1-473e5a634a9a in module() 1 import hunspell ImportError: dynamic module does not define init function (inithunspell) * What was the outcome of this action? As you can see, the package cannot be imported. * What outcome did you expect instead? I would expect the module to load successfully. Note that python3-hunspell loads successfully (I'm not saying it works, though, I haven't had time to test). Also note that it seems that there is a bunch of newer upstream versions available: https://pypi.python.org/pypi/hunspell/0.3.2 Cheers, Tomasz -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-hunspell depends on: ii libc6 2.19-13 ii libhunspell-1.3-0 1.3.3-3 ii python 2.7.8-2 python-hunspell recommends no packages. python-hunspell suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513402: Ping
retitle -1 ITP: : fasm -- assembly language compiler for x86 and x86-64 processors owner -1 ! thanks Actually, I don't know how bootstrapping should be done, but what I did looks pretty natural. :) Tomasz On 08/11/14 14:48, Jure Sah wrote: Hello, If there's anything I could do to help let me know. The last time I tried I had no idea how to get the bootstrapping done. LP, Jure Dne 07. 11. 2014 ob 20:17 je Tomasz Buchert zapisal(a): Hi guys, just letting you know that I revived the process of packaging fasm. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768487 Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513402: Ping
retitle 513402 ITP: fasm -- assembly language compiler for x86 and x86-64 processors owner 513402 ! thanks I suck so badly at using control@b.d.o ! :| Tomasz On 08/11/14 16:12, Tomasz Buchert wrote: retitle -1 ITP: : fasm -- assembly language compiler for x86 and x86-64 processors owner -1 ! thanks Actually, I don't know how bootstrapping should be done, but what I did looks pretty natural. :) Tomasz On 08/11/14 14:48, Jure Sah wrote: Hello, If there's anything I could do to help let me know. The last time I tried I had no idea how to get the bootstrapping done. LP, Jure Dne 07. 11. 2014 ob 20:17 je Tomasz Buchert zapisal(a): Hi guys, just letting you know that I revived the process of packaging fasm. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768487 Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768487: RFS: fasm/1.71.22 -- fast assembler for the x86 and x86-64 architectures
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package fasm: * Package name: fasm Version : 1.71.22-1 Upstream Author : Tomasz Grysztar * URL : http://flatassembler.net * License : FASM license (Simplified BSD with a weak copyleft clause) Section : devel It builds those binary packages: fasm - fast assembler for the x86 and x86-64 architectures To access further information about this package, please visit the following URL: http://mentors.debian.net/package/fasm Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/f/fasm/fasm_1.71.22-1.dsc NOTES: 1) the first upload fixes https://bugs.debian.org/513402 2) the gbp packaging is hosted here: http://anonscm.debian.org/cgit/collab-maint/fasm.git 3) fasm is x86 and x64 assembler, however it builds as a i386 ELF static binary (even on x64) 4) fasm is a self-assembling assembler, therefore it has to be bootstrapped; the -1 upload packages the binary provided upstream (the master branch); the -2 depends on fasm and uses it to build itself (the after branch); after the second step fasm should be properly bootstrapped Regards, T. Buchert -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513402: Ping
Hi guys, just letting you know that I revived the process of packaging fasm. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768487 Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741451: Bugfix
On 07/11/14 16:55, Jay Berkenbilt wrote: Jay Berkenbilt q...@debian.org wrote: Mathieu Malaterre ma...@debian.org wrote: On Tue, Oct 28, 2014 at 7:13 PM, Tomasz Buchert tomasz.buch...@inria.fr wrote: Hi, I've worked on that bug today's evening and I found a fairly simple fix. Thanks Tomasz ! Jay, are you going to submit the debdiff as-is ? Are you forwarding the issue upstream ? I do not have the time to prepare an NMU ATM, sorry. Thanks, Tomasz, for the bug fix. Sorry to have been silent for a while. While the bug fix looks straightforward, it's the kind of thing I would probably want upstream to weigh in on. Also, when you sent your original message, we were too close the Jessie freeze for me to get the package into testing in time, and tiff has lots of reverse dependencies, so I have a strong desire not to make anymore uploads that are not intended for Jessie. Otherwise it's too disruptive. What I have done is to create an upstream bug report with this. If it's excepted, then I will mark this patch to include in my first post-Jessie upload. There's a chance upstream will issue a new version before then anyway, and we will want this fix to go in. Here's the upstream bug report: http://bugzilla.maptools.org/show_bug.cgi?id=2480 Okay, sorry, I just noticed this is an RC bug. I guess I was asleep at the wheel. Given this, as soon as I get a response from upstream, I will upload and request a freeze exception. -- Jay Berkenbilt q...@debian.org Thanks for taking it to the next step. I'm not sure that the bug deserves to be RC, but well, technically it is :). If you need any help, please let me know. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766994: Confirmed
Hi, I confirm that this bug affects me as well. One workaround is to remove systemtap-common (a thing I could do since I haven't used systemtap recently). Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741451: Bugfix
Hi,
I've worked on that bug today's evening and I found
a fairly simple fix. I'm quite confident that it fixes
the problem and does not break anything else (in any
case I understand the source of the problem). The upstream
may be interested in the fix.
The downside is that the result of JPEG to [none,lzw,lzma,...]
conversion will be encoded in RGB space, not subsampled YCrCb,
which may slightly increase output size. If you have questions,
do not hesitate.
I prepared a debdiff patch which I attach. It is written
as NMU, but you are free to modify it and incorporate
as a standard maintainer upload.
Cheers,
Tomasz
diff -Nru tiff-4.0.3/debian/changelog tiff-4.0.3/debian/changelog
--- tiff-4.0.3/debian/changelog 2014-06-29 23:32:44.0 +0200
+++ tiff-4.0.3/debian/changelog 2014-10-28 18:32:27.0 +0100
@@ -1,3 +1,10 @@
+tiff (4.0.3-10.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Don't crash on JPEG = non-JPEG conversion (Closes: #741451)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr Tue, 28 Oct 2014 18:11:18 +0100
+
tiff (4.0.3-10) unstable; urgency=medium
* Remove libtiff4-dev, completing the tiff transition. Packages that
diff -Nru tiff-4.0.3/debian/patches/bug-741451.patch tiff-4.0.3/debian/patches/bug-741451.patch
--- tiff-4.0.3/debian/patches/bug-741451.patch 1970-01-01 01:00:00.0 +0100
+++ tiff-4.0.3/debian/patches/bug-741451.patch 2014-10-28 19:02:53.0 +0100
@@ -0,0 +1,34 @@
+Description: fix for Debian bug #741451
+ tiffcp crashes when converting JPEG-encoded TIFF to a different
+ encoding (like none or lzw). For example this will probably fail:
+ .
+tiffcp -c none jpeg_encoded_file.tif output.tif
+ .
+ The reason is that when the input file contains JPEG data,
+ the tiffcp code forces conversion to RGB space. However,
+ the output normally inherits YCbCr subsampling parameters
+ from the input, which leads to a smaller working buffer
+ than necessary. The buffer is subsequently overrun inside
+ cpStripToTile() (called from writeBufferToContigTiles).
+ Note that the resulting TIFF file would be scrambled even
+ if tiffcp wouldn't crash, since the output file would contain
+ RGB data intepreted as subsampled YCbCr values.
+ .
+ This patch fixes the problem by forcing RGB space on the output
+ TIF if the input is JPEG-encoded and output is *not* JPEG-encoded.
+Author: Tomasz Buchert tomasz.buch...@inria.fr
+
+--- tiff-4.0.3.orig/tools/tiffcp.c
tiff-4.0.3/tools/tiffcp.c
+@@ -629,6 +629,11 @@ tiffcp(TIFF* in, TIFF* out)
+ TIFFSetField(out, TIFFTAG_PHOTOMETRIC,
+ samplesperpixel == 1 ?
+ PHOTOMETRIC_LOGL : PHOTOMETRIC_LOGLUV);
++ else if (input_compression == COMPRESSION_JPEG) {
++ /* RGB conversion was forced above
++ hence the output will be of the same type */
++ TIFFSetField(out, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB);
++ }
+ else
+ CopyTag(TIFFTAG_PHOTOMETRIC, 1, TIFF_SHORT);
+ if (fillorder != 0)
diff -Nru tiff-4.0.3/debian/patches/series tiff-4.0.3/debian/patches/series
--- tiff-4.0.3/debian/patches/series 2014-06-29 23:32:44.0 +0200
+++ tiff-4.0.3/debian/patches/series 2014-10-28 18:37:10.0 +0100
@@ -6,3 +6,4 @@
CVE-2013-4232.patch
CVE-2013-4244.patch
CVE-2013-4243.patch
+bug-741451.patch
Bug#688049: Interesting link
Hi Shirish (and other possibly interested), I've just wanted to let you know about this: http://www.nasa.gov/connect/sounds/index.html#.VE4vNJv62V5 as it may satisfy your need for space sound :) Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766717: bug
Hi Davide, you are aware that it is probably the same bug that you posted before in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757150, aren't you? Did you try the thing with libopengl-qt4 and friends? I still claim that there is a problem with your card, your shader compiler or your installation of OpenGL. Your card really seems to be the one causing problems - you can google error C6013 and you'll find a plethora of problems EVERYWHERE (I won't even bother to paste them here). However, I think that stellarium should stop more gracefully when shaders fail to compile. There was a discussion about having stellarium-legacy package with version 0.12.4, but it was rejected as we don't really want to support two packages at the same time [1]. I heard from stellarium developers that they want to release an updated version from 0.12.x series which I'll be more that happy to bring to *wheezy*, but not to *jessie*. You are free to use stellarium 0.12.4 right now from backports. If you need help to do that, drop me an e-mail. And you can always run without hardware acceleration: $ LIBGL_ALWAYS_SOFTWARE=1 stellarium but it will eat your laptop battery like Cookie Monster its cookies. I'm dropping the severity down as 0.13.x does not seem to support your GPU or software stack around it (as much evidence show). [1] https://lists.debian.org/debian-astro/2014/08/msg00010.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
On 25/09/14 17:27, Thibaut Paumard wrote: Le 25/09/2014 09:15, Tomasz Buchert a écrit : Hi Thibaut, I corrected these problems: http://mentors.debian.net/package/gravit (changes: http://anonscm.debian.org/cgit/debian-astro/packages/gravit.git/) I also added cc-by-sa-3.0.txt to gravit-data since in theory every license text should be distributed with Debian, but I couldn't find it in /usr/share/common-licenses. Tomasz Hi Tomasz, Not really important, but the purpose of sponsoring is to teach you the True Way of Debian: you should dump the WTF and the CC-BY-SA licenses directly in copyright instead of putting them somewhere else. The sentence On Debian systems, such license can be found... is only for the licenses in common-licenses. Policy says: Every package must be accompanied by a verbatim copy of its copyright information and distribution license in the file /usr/share/doc/package/copyright (see Copyright information, Section 12.5 for further details). The common licenses are an exception, where we put only a pointer to another file. So technically it's an RC bug to put the license in any other place, although I doubt that you would get a REJECT for that (the FTP master would file a bug, though, or otherwise remind you to fix this). Kind regards, Thibaut. Hi Thibaud, you can find the new version at http://mentors.debian.net/package/gravit. It has now a huge d/copyright file. :) Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
On 24/09/14 17:29, Thibaut Paumard wrote: Le 24/09/2014 17:05, Thibaut Paumard a écrit : I'm building the package now, will let you know if there are other problems While you're at it, there's a new version of Policy, you should update Standards-Version: https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt Package looks good otherwise, I'll upload as soon as you have fixed the remaining issues: +dfsg in upstream version, nit-picking about copyright, Standards-Version should be 3.9.6 (I think lintian doesn't even know about it yet) Regards, Thibaut. Hi Thibaut, I corrected these problems: http://mentors.debian.net/package/gravit (changes: http://anonscm.debian.org/cgit/debian-astro/packages/gravit.git/) I also added cc-by-sa-3.0.txt to gravit-data since in theory every license text should be distributed with Debian, but I couldn't find it in /usr/share/common-licenses. Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742330: RFS: gravit/0.5.1-1 ITP -- visually stunning gravity simulator
Hi Thibaut, I' taking liberty to ping you about this RFS. Cheers, Tomasz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
