Bug#999282: spell: diff for NMU version 1.0-24.1
Thank you for the patch. No need to have a longer queue. ciao cate On 14.12.2021 19:13, gregor herrmann wrote: Control: tags 999282 + patch Control: tags 999282 + pending Dear maintainer, I've prepared an NMU for spell (versioned as 1.0-24.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards.
Bug#899007: bauble: Depends on unmaintained python-gdata
Hello Andreas, I gave the package to Mario Frasca, which then orphaned the package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903644 gdata is not the only problem, there are other dependencies (which seems to be more complex to solve). Additionally as far I know there is no interest of upstream to continue such package, which I think it is also reasonable: a web application is a lot better. For my point of view, you can put into Debian Science, but possibly we should let it go. ciao cate On 17.03.19 18:29, Andreas Tille wrote: Hi Giacomo, the bug log states that the files using gdata have been removed upstream[1]. I'd volunteer to commit this package to Salsa in Debian Science, apply the needed patch and upload as a team upload if you don't mind. If I will not hear from you soon I assume you are fine with the move into Debian Science team. Kind regards Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899007#15
Bug#626457: libc6 doesn't include lib64 symlink on amd64
Package: libc6 Version: 2.13-3 Severity: critical Tags: sid The 2.13-3 version of libc6 doesn't include the lib64 symlink (in root and in /usr), thus making the system unusable (and blocking dpkg in the middle of operations). Restoring the symlink solve the problem. ciao cate -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-rc7 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-3 Embedded GNU C Library: Binaries ii libgcc1 1:4.6.0-7 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: ii cdebconf [debconf-2.0]0.155 Debian Configuration Management Sy ii debconf [debconf-2.0] 1.5.39 Debian configuration management sy ii glibc-doc 2.13-3 Embedded GNU C Library: Documentat ii locales 2.13-3 Embedded GNU C Library: National L -- debconf information: * glibc/upgrade: true glibc/disable-screensaver: glibc/restart-failed: * glibc/restart-services: cups cron atd -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588138: Bug#591059: Bug#585411: RM: lxr -- RoQA; security bugs, oooold upstream version, not properly maintained
On 08/04/2010 01:49 PM, Alexander Reichle-Schmehl wrote: Hi! * Nico Golde [100731 17:59]: PS: I would use some debconf time to improve the situation so that users will not have security problem after we remove the packages. Again, see the NMU I prepared for lxr-cvs, it should be fine. For lxr I think there is hardly much todo apart from upgrading to the current upstream version which you haven't done for quite a long. Thus the removal request. If that changes now fine, then I see no reason to remove it. So, any comments, Giacomo? I must say, that I tend to agree with Nico here, and therefore tend to remove the package soonish unless you show some activity or at least give comment. It is a difficult question: - I really think that lxr has less problem than lxr-cvs - both upstreams are not very active in publishing the tarball (and debian is doing most of security support) - lxr-cvs has released many unusable versions (buggy in core functionality, see e.g. the lasts versions) - I don't find real alternative in debian (let see where sources.d.n will go) - but OTOH I don't think is is so useful to have it in Debian: they are web application that need many customization, so IMHO for them it is better to work in a VCS branch than a package - I think there are very few true installation of debian packages (and IMHO the security problems are found testing the online mozilla lxr). So let's remove the two packages. cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588138: Bug#585411: RM: lxr -- RoQA; security bugs, oooold upstream version, not properly maintained
On 07/31/2010 04:38 PM, Nico Golde wrote: Package: ftp.debian.org Severity: normal Hi, I hereby request the removal of lxr from the archive, it should not be included in squeeze as well. The version that our package is currently based on is 0.3 (from 2003), which is light years behind upstream, has security bugs and not properly maintained. See e.g. #588138 and #585411. Probably #575745 affects lxr as well, hard to tell though, the code heavily differs since it's so old. There has been no move from the maintainer towards packaging current upstream versions and given the small number of popcon installations this doesn't have an impact on many users. No. please wait. I agree that there are problems but: - I would not include it squeeze anyway - let go before the security fixes in lxr, than we could see if we could remove it. BTW most of security bugs are only in lxr-cvs, which is an "enhancement" of lxr with other upstreams. One of the enhancement was to allow cross-referencing many languages, thus doing indirect regex and other more complex tasks, inducing such errors. LXR instead has hardcoded C decoding, and it seems with many less errors. For now I would remove lxr and lxr-cvs from squeeze, and I'll ask upstream what are their plan, and probably I propose to remove also lxr-cvs. ciao cate PS: I would use some debconf time to improve the situation so that users will not have security problem after we remove the packages. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#438385: NMU awardeco #438385: fails on 64-bit platforms
Hello, Now I upload (still to DELAYED) the new version, diff attached. I have fixed the problems you pointed in last mail, and I noticed I forgot one part of the uintXX_t patch. BTW: lintian give two warning (on your and on this NMU) - policy version - empty /usr/bin I see you install the binary on /bin and not on /usr/bin. Is really what you want? Do you know why pool http://ftp.debian.org/debian/pool/main/a/awardeco/ contains only i386 and amd64 ? But the package should be already build and installed on all archs: http://people.debian.org/~igloo/status.php?packages=awardeco ciao cate diff -u awardeco-0.2/debian/changelog awardeco-0.2/debian/changelog --- awardeco-0.2/debian/changelog +++ awardeco-0.2/debian/changelog @@ -1,3 +1,12 @@ +awardeco (0.2-2.1) unstable; urgency=low + + * Non-Maintainer Upload at BSP in Zurich: fix rc bug. + * Use the C99 bit length integer, to be safe on various +architectures (Closes: #438385). + * Fix also headers inclusion (memcpy: , exit: ). + + -- Giacomo Catenazzi <[EMAIL PROTECTED]> Thu, 17 Jan 2008 08:17:08 +0100 + awardeco (0.2-2) unstable; urgency=low * Fix FTBFS on GNU/kFreeBSD (Closes: #414235). only in patch2: unchanged: --- awardeco-0.2.orig/debian/patches/30_fixeduint.patch +++ awardeco-0.2/debian/patches/30_fixeduint.patch @@ -0,0 +1,36 @@ +diff -Nur awardeco-0.2/src/awardeco.h awardeco-0.2.new/src/awardeco.h +--- awardeco-0.2/src/awardeco.h 2006-08-05 11:38:03.0 +0200 awardeco-0.2.new/src/awardeco.h 2008-01-17 08:25:23.0 +0100 +@@ -10,10 +10,11 @@ + #define AWARDECO_H 1 + + #include ++#include + +-typedef unsigned char byte; +-typedef unsigned short word; +-typedef unsigned long dword; ++typedef uint8_t byte; ++typedef uint16_t word; ++typedef uint32_t dword; + + #define Xtract 0x10 + #define List 0x11 +diff -Nur awardeco-0.2/src/awardfnc.c awardeco-0.2.new/src/awardfnc.c +--- awardeco-0.2/src/awardfnc.c 2006-08-05 11:38:03.0 +0200 awardeco-0.2.new/src/awardfnc.c 2008-01-17 08:26:24.0 +0100 +@@ -10,10 +10,11 @@ + #define AWARDFUNC_H 1 + + #include ++#include + +-typedef unsigned char byte; +-typedef unsigned short word; +-typedef unsigned long dword; ++typedef uint8_t byte; ++typedef uint16_t word; ++typedef uint32_t dword; + + #define Xtract 0x10 + #define List 0x11 only in patch2: unchanged: --- awardeco-0.2.orig/debian/patches/40_fixheader.patch +++ awardeco-0.2/debian/patches/40_fixheader.patch @@ -0,0 +1,12 @@ +diff -Nur awardeco-0.2/src/awardfnc.c awardeco-0.2.new/src/awardfnc.c +--- awardeco-0.2/src/awardfnc.c 2008-01-17 08:26:37.0 +0100 awardeco-0.2.new/src/awardfnc.c 2008-01-17 08:27:05.0 +0100 +@@ -11,6 +11,8 @@ + + #include + #include ++#include ++#include + + typedef uint8_t byte; + typedef uint16_t word; only in patch2: unchanged: --- awardeco-0.2.orig/debian/patches/40_fixwarnings.patch +++ awardeco-0.2/debian/patches/40_fixwarnings.patch @@ -0,0 +1,21 @@ +diff -Nur awardeco-0.2/src/awardfnc.c awardeco-0.2.new/src/awardfnc.c +--- awardeco-0.2/src/awardfnc.c 2008-01-16 08:28:09.0 +0100 awardeco-0.2.new/src/awardfnc.c 2008-01-16 08:30:41.0 +0100 +@@ -153,7 +153,7 @@ + + byte *GetFullDate(byte *mon, byte *day, byte *year) + { +- byte *Months[]={"", ++ static byte const*const Months[]={"", + "January", + "February", + "March", +@@ -166,7 +166,7 @@ + "October", + "November", + "December"}; +- byte Buf[20]; ++ static byte Buf[20]; // Warning: we return this buffer, so place it in heap not on stack! + sprintf(Buf,"%2.2s",year); + + if((atoi(Buf)>=0) && (atoi(Buf)<70)) sprintf(Buf,"%.2s %s %s%.2s",day,Months[atoi(mon)],"20",year);
Bug#438385: NMU awardeco #438385: fails on 64-bit platforms
Hello, I'm ready for a NMU, attached I put the diff. Now I'll upload the package in delayed. the patch contain: - fix on 64-bit architecture: use C99 "fixed"-bit integer - fix of undeclared function: a potential bug, which can give problem on some architectures. Considering the package pourpose, maybe Architecture: "any" is to wide. - fix a return of local stack variables PS: only the first is a rc bug (#438385), but the second adn the third are potential rc or important bugs. ciao cate diff -u awardeco-0.2/debian/changelog awardeco-0.2/debian/changelog --- awardeco-0.2/debian/changelog +++ awardeco-0.2/debian/changelog @@ -1,3 +1,11 @@ +awardeco (0.2-2.1) unstable; urgency=low + + * Non-Maintainer Upload at BSP in Zurich: fix rc bug + * Use the C99 bit length integer, to be safe on various archs + * fix also headers inclusion (memcpy: , exit: + + -- Giacomo Catenazzi <[EMAIL PROTECTED]> Sat, 12 Jan 2008 20:07:12 +0100 + awardeco (0.2-2) unstable; urgency=low * Fix FTBFS on GNU/kFreeBSD (Closes: #414235). only in patch2: unchanged: --- awardeco-0.2.orig/debian/patches/30_fixeduint.patch +++ awardeco-0.2/debian/patches/30_fixeduint.patch @@ -0,0 +1,17 @@ +diff -Nur awardeco-0.2/src/awardeco.h awardeco-0.2.new/src/awardeco.h +--- awardeco-0.2/src/awardeco.h 2006-08-05 11:38:03.0 +0200 awardeco-0.2.new/src/awardeco.h 2008-01-16 08:12:10.0 +0100 +@@ -10,10 +10,11 @@ + #define AWARDECO_H 1 + + #include ++#include + + typedef unsigned char byte; +-typedef unsigned short word; +-typedef unsigned long dword; ++typedef uint16_t word; ++typedef uint32_t dword; + + #define Xtract 0x10 + #define List 0x11 only in patch2: unchanged: --- awardeco-0.2.orig/debian/patches/40_fixheader.patch +++ awardeco-0.2/debian/patches/40_fixheader.patch @@ -0,0 +1,12 @@ +diff -Nur awardeco-0.2/src/awardfnc.c awardeco-0.2.new/src/awardfnc.c +--- awardeco-0.2/src/awardfnc.c 2006-08-05 11:38:03.0 +0200 awardeco-0.2.new/src/awardfnc.c 2008-01-16 08:25:31.0 +0100 +@@ -10,6 +10,8 @@ + #define AWARDFUNC_H 1 + + #include ++#include ++#include + + typedef unsigned char byte; + typedef unsigned short word; only in patch2: unchanged: --- awardeco-0.2.orig/debian/patches/40_fixwarnings.patch +++ awardeco-0.2/debian/patches/40_fixwarnings.patch @@ -0,0 +1,21 @@ +diff -Nur awardeco-0.2/src/awardfnc.c awardeco-0.2.new/src/awardfnc.c +--- awardeco-0.2/src/awardfnc.c 2008-01-16 08:28:09.0 +0100 awardeco-0.2.new/src/awardfnc.c 2008-01-16 08:30:41.0 +0100 +@@ -153,7 +153,7 @@ + + byte *GetFullDate(byte *mon, byte *day, byte *year) + { +- byte *Months[]={"", ++ static byte const*const Months[]={"", + "January", + "February", + "March", +@@ -166,7 +166,7 @@ + "October", + "November", + "December"}; +- byte Buf[20]; ++ static byte Buf[20]; // Warning: we return this buffer, so place it in heap not on stack! + sprintf(Buf,"%2.2s",year); + + if((atoi(Buf)>=0) && (atoi(Buf)<70)) sprintf(Buf,"%.2s %s %s%.2s",day,Months[atoi(mon)],"20",year);
Bug#447007: wavsplit: Doesn't support files larger than 2 GB.
The followind patch should correct the behaviour. Not tested (later I'll create a big wav test-file). --- wavsplit.c 2008-01-15 08:22:04.0 +0100 +++ ../orig/wavsplit-1.1.0/wavsplit.c 2004-04-12 11:35:52.0 +0200 @@ -248,8 +248,7 @@ unsigned int fps, int splits, timepos * split) { char *buf, *bp_out; - long to_write, to_read, n_read; - off_t pos; + long to_write, to_read, n_read, pos; int fnr = 0; unsigned long in_blk_size; struct stat stat_buf; Cyril: do you still want to maintain whis package? in sf there are new versions. I think that the code should be re-organized. "pos" is used only on two places, so IMHO we could remove it and work with relative positions. Also the calculation of split is not very good for bigger files (doubles is not byte precise for big numbers). Doing integer calculation is IMHO better. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460302: NMU #460302 in tdb: usr/include/tdb.h uses sig_atomic_t without including signal.h
Hello In the Debian BSP in Zurich I fixed one rc-bug in tdb package: I remove the funcion, because it is also removed upstream in the released version. I've not corrected the second rc-bug. I think that the release correct the bug, but: 1- not so sure 2- it change GPL-2 to GPL-3 so to much for a "normal" NMU. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460302: NMU #460302 in tdb: usr/include/tdb.h uses sig_atomic_t without including signal.h
and the diff PS: This bug will close also a rc-bug in an other package. diff -u tdb-1.1.1~svn26294/debian/changelog tdb-1.1.1~svn26294/debian/changelog --- tdb-1.1.1~svn26294/debian/changelog +++ tdb-1.1.1~svn26294/debian/changelog @@ -1,3 +1,10 @@ +tdb (1.1.1~svn26294-1.1) unstable; urgency=low + + * Non-Maintainer Upload at BSP in Zurich: fix rc-bug + * remove tdb_setalarm_sigptr() as in the released version (Closes: #460302) + + -- Giacomo Catenazzi <[EMAIL PROTECTED]> Sun, 13 Jan 2008 13:50:34 +0100 + tdb (1.1.1~svn26294-1) unstable; urgency=low * New upstream snapshot. only in patch2: unchanged: --- tdb-1.1.1~svn26294.orig/include/tdb.h +++ tdb-1.1.1~svn26294/include/tdb.h @@ -147,8 +147,6 @@ int tdb_chainlock_mark(struct tdb_context *tdb, TDB_DATA key); int tdb_chainlock_unmark(struct tdb_context *tdb, TDB_DATA key); -void tdb_setalarm_sigptr(struct tdb_context *tdb, volatile sig_atomic_t *sigptr); - /* Debug functions. Not used in production. */ void tdb_dump_all(struct tdb_context *tdb); int tdb_printfreelist(struct tdb_context *tdb);
Bug#453200: NMU #453200: genext2fs: FTBFS: ./test-gen.lib: line 29: 31347 Segmentation fault
Hello, In the Debian BSP in Zurich, I prepared a NMU to correct a rc-bug. You will find the diff in attachment: The program use "%as" to scan lines. The problem is that not so new C99 use "%a" for floating point, and no more as GNU extension "auto malloc". ciao cate PS: I'll push the package in delayed queue diff -u genext2fs-1.4.1/debian/changelog genext2fs-1.4.1/debian/changelog --- genext2fs-1.4.1/debian/changelog +++ genext2fs-1.4.1/debian/changelog @@ -1,3 +1,11 @@ +genext2fs (1.4.1-2.1) unstable; urgency=low + + * Non-Maintainer Upload, at BSP in Zurich + * in sscanf the "a" could mean "malloc" or the new C99 floating, + so don't use it, not to have surprises. + + -- Giacomo Catenazzi <[EMAIL PROTECTED]> Sat, 12 Jan 2008 23:03:59 +0100 + genext2fs (1.4.1-2) unstable; urgency=low * configure.in: Change AC_CONFIG_HEADER to AM_CONFIG_HEADER. only in patch2: unchanged: --- genext2fs-1.4.1.orig/genext2fs.c +++ genext2fs-1.4.1/genext2fs.c @@ -286,7 +286,9 @@ // older solaris. Note that this is still not very portable, in that // the return value cannot be trusted. -#if SCANF_CAN_MALLOC +#if 0 // SCANF_CAN_MALLOC +// C99 define "a" for floating point, so you can have runtime surprise +// according the library versions # define SCANF_PREFIX "a" # define SCANF_STRING(s) (&s) #else
Bug#441919: g15daemon: FTBFS: configure: error: "libg15 (or its devel package) not found. please install it"
Kurt Roeckx writes: Hi, Your package is failing to build with the following error: checking for initLibG15 in -lg15... no configure: error: "libg15 (or its devel package) not found. please install it" make: *** [config.status] Error 1 This is a know problem. Now I'm on short vacation, but I don't understand why the new version doesn't get in incomming. This weekend I'll correct all thinngs (now I've a really working pbuilder environemnt. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430036: dpkg: error processing microcode.ctl ... post-installation script returns 128
retitle 430036 microcode.ctl: fail to handle missing microcode support severity 430036 minor thanks Soeren Sonnenburg wrote: > argh. I noticed that I did not have /dev/cpu/microcode (support for it > was missing in the kernel). Now I've enabled support for it in the > kernel (overwriting the old one) and reinstalled the package without > seeing any error: Ok. but I don't like the error message. I'll improve in the next version. Thanks, cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430036: dpkg: error processing microcode.ctl ... post-installation script returns 128
Soeren Sonnenburg wrote: > Package: microcode.ctl > Version: 1.17-1 > Severity: grave > > Setting up microcode.ctl (1.17-1) ... > udev active, devices will be created in /dev/.static/dev/ > dpkg: error processing microcode.ctl (--configure): > subprocess post-installation script returned error exit status 128 > Errors were encountered while processing: > microcode.ctl > E: Sub-process /usr/bin/dpkg returned an error code (1) Could you run bash -x /var/lib/dpkg/info/microcode.ctl.postinst and give me the output. thanks, cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]