Bug#999282: spell: diff for NMU version 1.0-24.1

2021-12-15 Thread Giacomo Catenazzi

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

2019-03-17 Thread Giacomo Catenazzi

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

2011-05-11 Thread Giacomo Catenazzi
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

2010-08-04 Thread Giacomo Catenazzi

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

2010-07-31 Thread Giacomo Catenazzi

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

2008-01-16 Thread Giacomo Catenazzi
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

2008-01-16 Thread Giacomo Catenazzi
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.

2008-01-14 Thread Giacomo Catenazzi
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

2008-01-14 Thread Giacomo Catenazzi
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

2008-01-13 Thread Giacomo Catenazzi
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

2008-01-13 Thread Giacomo Catenazzi
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"

2007-09-12 Thread Giacomo Catenazzi
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

2007-06-22 Thread Giacomo Catenazzi
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

2007-06-21 Thread Giacomo Catenazzi
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]