Bug#699382: Broken syslinux in sid
On 02/04/2013 08:40 AM, Giacomo A. Catenazzi wrote: On 02/03/2013 10:53 PM, Daniel Baumann wrote: On 02/03/2013 10:44 PM, Cyril Brulebois wrote: Now please explain how exactly syslinux-themes-debian is involved here. it's a bug in your config, you need more files present on the media, as the link to the corresponding commit in live-build shows. Could you be more specific, and put an information in README.Debian? On the 5.0 version, I had libutil_com.c32 and not the libutil.c32. Could be that the error? (Note: I copied it also /boot/extlinux). Anyway running extlinux -i /boot/extlinux, I would expect that the program will copy the right files in boot (so possibly my original bug is a slight different [or deeper] to the installer bug) Version 5.01 works again for me, so for me the initial bug is closed. Because of the further concerns opened by -release and -boot, I left it open, to continue the discussion. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699382: Broken syslinux in sid
On 02/03/2013 10:53 PM, Daniel Baumann wrote: On 02/03/2013 10:44 PM, Cyril Brulebois wrote: Now please explain how exactly syslinux-themes-debian is involved here. it's a bug in your config, you need more files present on the media, as the link to the corresponding commit in live-build shows. Could you be more specific, and put an information in README.Debian? On the 5.0 version, I had libutil_com.c32 and not the libutil.c32. Could be that the error? (Note: I copied it also /boot/extlinux). Anyway running extlinux -i /boot/extlinux, I would expect that the program will copy the right files in boot (so possibly my original bug is a slight different [or deeper] to the installer bug) ciao cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584671: [lxr-cvs] new stable version fix security hole
On 26.07.2010 15:08, Alexander Reichle-Schmehl wrote: Hi! * Giacomo A. Catenazzic...@cateee.net [100607 09:29]: Please update lxr-cvs to the new stable version. The new version 0.9.8 of lxrng fix several cross-site scripting vulnerabilities (CVE-2009-4497) reported in bug #575745 The new version was published 2010-01-15 on http://sourceforge.net/projects/lxr/ Yes, I'll push the security fix. Note that the new upstream version is not a releasable version: it was an alpha version with the security fix added, but still it is not really working. Any news on this? There are four security related RC bugs open against lxr and lxr-cvs. And as popcon seems to report only one actively used installation, I wonder if removing these packages wouldn't be an option. Seb (I know only the nickname on IRC) told me few days ago, that it was ready to release a fix for the 4 CVEs for lxr-cvs. I was planing than to test and port the fixes to lxr. Probably should not be put anymore on stable releases, but it is IMHO a base for further developements (debian sources, etc.), and considering that CVE are issued, I think the lxr is still used and checked (so possibly it is not in a so bad shape). Note: probably one of the two package should be removed, but I'm still undecided which one ciao cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584671: [lxr-cvs] new stable version fix security hole
On 05.06.2010 15:00, Xavier Brochard wrote: Package: lxr-cvs Version: 0.9.5+cvs20071020-1 Severity: serious Tags: security X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org --- Please enter the report below this line. --- Please update lxr-cvs to the new stable version. The new version 0.9.8 of lxrng fix several cross-site scripting vulnerabilities (CVE-2009-4497) reported in bug #575745 The new version was published 2010-01-15 on http://sourceforge.net/projects/lxr/ Yes, I'll push the security fix. Note that the new upstream version is not a releasable version: it was an alpha version with the security fix added, but still it is not really working. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549834: Bug#549816 and #549...@bugs.debian.org (g15daemon-audacious and g15macro): FTBFS: libtool: link: `/usr/lib/libg15.la' is not a valid libtool archive
Yes, thanks you for remind me to publish the new g15daemon. On removing the *.la files I used a shortcut, but than I forgot to upload the new version of g15daemon without .la file (and references to no more existent libg15 la file. I'll upload the new version of g15daemon in next few days, and I'll check/upload the other g15 packages, to finally remove all .la dependencies from my packages. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547186: g15daemon: Random crashes
Could you check in /var/log/syslog, if at the time of the crash there is some additional information? The daemon is terminated with SIGKILL, and this signal should not be caused by the daemon itself (SEGSEGV, SIGILL, SIGBUS, etc. are delivered for internal errors). So I think an external program/setting will send such signals, on passing some limits or with invalid permissions. So I expect ulimits, acct, selinux, etc to send the signal. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547186: g15daemon: Random crashes
Could you send also the output of grep g15daemon /var/log/syslog thanks cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546877: depends on extra package (makedev)
Xavier Bestel wrote: Package: microcode.ctl Version: 1.17-12 Severity: serious Justification: Policy 2.5 your package depends on makedev which is an extra packages. That's a violation of Debian Policy 2.5: Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. Moreover, this makes makedev un-uninstallable and so blocks the sysv-rc conversion to dependency based boot. I don't think this is a bug, and I don't think your analysis is correct: microcode.ctl depends on udev | makedev, thus it depends on makedev ONLY if udev (a package with higher priority) is not installed, and this happen only if user choose not to follow the priorities. Also the second part: if a system have udev installed, the package makedev could be removed. (on the countrary, please fill the bug on dpkg or apt). I'll ask other maintainer if my interpretation is right, before closing or resolving the bug. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539744: chroot to lenny /target in debootstrap segfaults
Frans Pop wrote:
This oneliner change would fix the issue as well:
+++ b/packages/base-installer/debian/bootstrap-base.postinst
@@ -88,7 +88,7 @@ install_base_system () {
# so make a backup to be restored later
copied_fstab=true
cp /target/etc/fstab /target/etc/fstab.orig
thus this should be a mv
- echo # UNCONFIGURED FSTAB FOR BASE SYSTEM /target/etc/fstab
+ echo # UNCONFIGURED FSTAB FOR BASE SYSTEM /target/etc/fstab
fi
if [ $PROTOCOL = http ]; then
And it even makes more sense than the current code...
ciao
cate
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521918: pbuilder --build --binary-arch invokes 'build' target
Filippo Rusconi wrote: On Mon, May 11, 2009 at 02:11:18PM +0200, Julien Cristau wrote: On Mon, May 11, 2009 at 13:46:30 +0200, Lionel Elie Mamane wrote: No, policy is very clear on that: if you call the build target, you _must_ satisfy Build-Depends-Indep and Build-Conflicts-Indep: And policy is clearly not followed by any actual practice on this point. So that's as much a bug in policy as anything else (#374029). Cheers, Julien Well, but then, why have new packagers trained by studying the Policy? Because they should find errors in policy and report such bugs ;-) Really many bug of debian-policy are found by new maintainers, but unfortunately most of new maintainers are too shy to report bugs to debian-policy, just because they are *new* maintainers. Thus debian-policy still have many bugs. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#449497: foo2zjs dispute
Note: I'm not a CTTE member. Steffen Joeris wrote: Maintainer: -- The problem is as follows. The submitter sees the inclusion of the getweb script as a violation of the DFSG. The script is provided by upstream to download non-free firmware from his upstream webpage. The package includes documentation in README.Debian and a GUI interface (hannah-foo2zjs) around the getweb script for the user's convenience. Some printers need this non-free firmware to run, others don't. More information can be found in the bugreport. Could we please ask you to settle this dispute? Submitter: -- The submitter sees the getweb script's dependencies on external data/files as potentially dangerous. Once the package enters stable, upstream changes (moving/modifying files, etc.) can break functionality -- leading to a package that can no longer be considered stable. External dependencies also potentially leave users vulnerable to security risks (the upstream site could be spoofed or hijacked and malicious files hosted instead of the legitimate firmware files). Also, the submitter views external dependencies as a possible violation of the spirit of the debian policy, which currently is not explicitly clear on the issue. Section 2.2.1 says ... the packages in main must not require a package outside of main for compilation or execution (thus, the package must not declare a 'Depends', 'Recommends', or 'Build-Depends' relationship on a non-main package). This makes the policy clear about packages, but it does not address dependencies on other external non-packaged non-free files. It is the submitter's belief that Debian's policy should be reworded for clarity on situations such as this. It is not a DFSG violation, because the file are not distributed by Debian, but I think it violated the policy. I think Debian should not assume a machine on the net, so I would interpret main in the stricter way. I don't find an overkill to make a separate package for the download script. As you will see, maintaining such script will be complexer and in case of layout change, it don't requires a updates from most of the package user. The changing of remote layout is an important problem: the package could become unusable thus potentially a RC bug, which should not happens on other bugs in main. The contrib section includes (historically) also the reduced quality package, so the uninstability of a contrib package could be temporary accepted. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438385: NMU awardeco #438385: fails on 64-bit platforms
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 Please add (Closes: #438385) here. Also, please end all changelog lines with a full stop and start sentences with capital letters for consistency. oops. Ok. the first was a cut-copy error trying cdbs-edit-patch (nice tools!). Never realized about cosmetic consistency, I'll fix also that. --- 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.h2006-08-05 11:38:03.0 +0200 awardeco-0.2.new/src/awardeco.h2008-01-16 08:12:10.0 +0100 +@@ -10,10 +10,11 @@ + #define AWARDECO_H 1 + + #include stdio.h ++#include stdint.h + + typedef unsigned char byte; Maybe make this uint8_t then, too, for consistency? Yes, it's more cosmetical, but still. yes. This change doesn't harm: in C, char is a byte and in POSIX, char is 8 bit. So I take a smaller NMU. But reading the code it seems ok to do this conversion. I've some other minor stylistic C correction, i.e. 0x; is wrong, it should have a u postfix. (and ul if we care about real C, but anyway POSIX int is 32-bit or more.), but for this I think I (or you) should contact upstream author. 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
Jelmer Vernooij wrote: Am Montag, den 14.01.2008, 08:43 +0100 schrieb Giacomo Catenazzi: and the diff PS: This bug will close also a rc-bug in an other package. Please don't upload this. I'm not sure what upstream package you're looking at but tdb_setalarm_sigptr() still exists in upstream gits tdb.h. ok. I'll check how to remove from the delayed queue. Or you can include signal.h and upload a new package (so that my package will never be installed). [see POSIX: http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html ] I was locking in: http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/tags/TDB_1_1_0/include/tdb.h?rev=22638view=auto which seemed me the right source, extrapoled and interpreted from debian/copyright. But I lack of deep knowledge of the project, so I had taken a wrong branch (you were the last commiter). Sorry for my error! ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451657: g15daemon-audacious: FTBFS: Could not find audacious/beepctrl.h
Daniel Schepler wrote: Package: g15daemon-audacious Version: 2.5.2.0.20070914-1 Severity: serious With the new version of audacious, I get this in my pbuilder build log: Thank you for the report. The new version of audacious has a new plugin API. Now I nearly finished the conversion, so you should expect in next few days a version that compile with newer audacious. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442995: g15daemon: FTBFS: /bin/sed: can't read /usr/lib/libfreetype.la: No such file or directory
Lucas Nussbaum wrote: Hi, During a rebuild of all packages in sid, your package failed to build on i386. ar cru .libs/libg15daemon_client.a g15daemon_net.o ranlib .libs/libg15daemon_client.a creating libg15daemon_client.la /bin/sed: can't read /usr/lib/libfreetype.la: No such file or directory libtool: link: `/usr/lib/libfreetype.la' is not a valid libtool archive make[3]: *** [libg15daemon_client.la] Error 1 make[3]: Leaving directory `/build/user/g15daemon-1.9.0-wip.20070910/libg15daemon_client' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/user/g15daemon-1.9.0-wip.20070910' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/user/g15daemon-1.9.0-wip.20070910' make: *** [debian/stamp-makefile-build] Error 2 Thanks you. The problem was partly know, and I wait for a upstream fix (libfreetype will be used by unconditionally). I've corrected the libg15render package, but I didn't noticed that g15daemon depended directly on libfreetype, nor that the build behavior change according configuration of libg15render. I'll upload tonight a new version, which is compiled with the recent (and libfreetype enabled) libg15render. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439871: binary missing from package
Cyril Brulebois wrote: tag 439871 patch thanks Soeren Sonnenburg [EMAIL PROTECTED] (28/08/2007): /usr/sbin/microcode_ctl is missing from the package rendering it useless $ dpkg -L microcode.ctl /. /usr /usr/sbin Since the switch to cdbs is suboptimal (missing include), it is “normal” not to have this file anymore. Please find attached a patch to fix this. The debdiff output still states: | Files in first .deb but not in second | - | -rw-r--r-- root/root /usr/share/man/man8/microcode_ctl.8.gz But it sounds less RC to me and I won't spend more time on this. Now I've already uploaded and corrected, also the man page. But in next version I'll add include /usr/share/cdbs/1/class/makefile.mk and maybe some other cdbs improvements. What really I don't understand is how I had uploaded the packages which such bug, after a lot of checks and building. Maybe I looked to much debhelper changes and my git documentation Thanks for the quick report and patches :-) ciao cate
Bug#403397: conflict file with lxr-cvs: /usr/bin/genxref without Conflicts
Yes. It is a know bug. It will be resolved with a Conflict in next release. Unfortunately in last days the some changes (with the correction of this bug) was rejected from NEW queue: I was restructurating the packages, but I didn't correct the copyright file. In next days I will upload again, to proposed stable and unstable. thanks cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326467: lxr-cvs tried to install /usr/bin/genxref, conflicts with lxr
Ok, you are right! It should be possible to run the two application in parallel (i.e. one for kernel and the other for other projects), but I think it is very rare (or maybe only theoretical). So now I will change the dependences, so that they conflicts. Maybe in future I will change the binary name. Thanks for the report cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384106: kopete: crashes whole system
If it happens, kde hangs completely, leaving the user unable to switch to a different terminal or even to restart X. The mouse is not reacting anymore and the system does not respond on any keystrokes. Sometimes it is possible to ssh into the box from another box and kill kopete which instantly resurrects the system. But if you wait too long, the box does not even answer to ping requests and you have to restart the hard way. This means surely that there is kernel bug! New kopete versions help to trigger it, but the worse bug is surelly in the kernel. Try to update the kernel (debian versions) and see it you see the bug. In this case open a new bug (but now for the kernel) and help to debug. (The kernel people will give you some hint how to find more informations). ciao cate PS: to the maintainer: it is up to you if you should move the bug or to let open in kopete. It is possible that a bug in kopete triggers the kernel bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355517: lxr-csv: Unstable Interface. Not yet ready for testing
Package: lxr-csv Version: 0.9.4-1 Severity: critical Justification: causes serious data loss [I'm the maintainer of the package] The interface is not stable. Now normal user (which use mysql), will lost data on upgrades. I will revert the release - xrelease change (and quote the new mysql5 reserved key release, so to have a smooth upgrade, and probably still some few little changes on directory structures. In next few week I should have (an upload) a stable version, but now better not to go in testing. ciao cate -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-rc5-g501f74f2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353106: lxr-cvs: FTBFS: can't parse dependency
Daniel Schepler wrote: Package: lxr-cvs Version: 0.9.2-5 Severity: serious From my pbuilder build log: ... dh_shlibdeps dh_gencontrol dpkg-gencontrol: warning: no utmp entry available and LOGNAME not defined; using uid of process (0) dpkg-architecture: warning: no utmp entry available and LOGNAME not defined; using uid of process (0) dpkg-parsechangelog: warning: no utmp entry available and LOGNAME not defined; using uid of process (0) debian: warning: no utmp entry available and LOGNAME not defined; using uid of process (0) dpkg-architecture: warning: no utmp entry available and LOGNAME not defined; using uid of process (0) dpkg-gencontrol: warning: can't parse dependency (mysql-server libdbd-mysql-perl) | (postgresql libdbd-pgsql) dpkg-gencontrol: error: error occoured while parsing Recommends dh_gencontrol: command returned error code 2304 make: *** [binary-arch] Error 1 That dependency line is completely broken. Could you send me your dependency line? The dependency line is partially built at build-time by debhelper package. Could you give me the version of your debhelper. Maybe the newer debhelper is not compatible with (maybe broken) old dependencies variables. Anyway I think I will upload the new updated version in next weeks, modified according the newer debian policies. Thank for the report! ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353106: lxr-cvs: FTBFS: can't parse dependency
Steve Langasek wrote: On Thu, Feb 16, 2006 at 10:34:47AM +0100, Giacomo A. Catenazzi wrote: Daniel Schepler wrote: dpkg-gencontrol: error: error occoured while parsing Recommends dh_gencontrol: command returned error code 2304 make: *** [binary-arch] Error 1 That dependency line is completely broken. Could you send me your dependency line? He should have said recommends line rather than dependency line. He's right: the line is completely broken, and it's a line present verbatim in your source package. Ok. The '' should be replaced by ','. IIRC there was a problem with (A, B) | (C, D), but the '' is surely a very wrong solution. So I think i will upload tonight the correct Recommends version, and only later the new version (which require extensive testing). thanks cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318019: libxine1: uninstallable due to g++ 4.0 transition
libxine1 is still uninstallable, it still depend on a pre g++ library: libmodplug0 (libmodplug0c2) see: http://packages.debian.org/unstable/libs/libxine1 ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318019: libxine1: uninstallable due to g++ 4.0 transition
Note that the last patch in ubuntu doesn't include all the previous patch. The nes_apu.c patch is found only on yhe first chunk of ubuntu bug report. If you apply also this part of patch, you solve the problem Applying the first chunk solve the problem. But not tested the result package ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
