Bug#1068786: ITS: latencytop
Hello, You, or other DD or DM can take maintainership of it. Zero objections. ciao cate On 2024-04-11 2:41, Boyuan Yang wrote: Source: latencytop Version: 0.5.0-0.1 Severity: important X-Debbugs-CC: c...@debian.org Dear package latencytop maintainer in Debian, After looking into the package you maintain (latencytop, https://tracker.debian.org/pkg/latencytop), I found that this package received no maintainer updates in the past 14 years and is not in good shape. As a result, I am filing an ITS (Intent to Salvage) request against your package according to section 5.12 in Debian's Developers' Reference [1]. My current plan is to refresh packaging and fix all RC bugs. Please let me know whether you are still willing to maintain this package. According to the criteria listed at [2], I will upload a Non- maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days (May 01, 2024) to continue with the package salvaging. If you find it necessary to pause the ITS process, please let me know immediately by replying this bug report. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://wiki.debian.org/PackageSalvaging
Bug#1009826: ITS: screentest
Hello, I'm OK with ITS. ciao cate On 18.04.2022 20:20, Boyuan Yang wrote: Source: screentest Version: 2.0-2.2 Severity: important X-Debbugs-CC: c...@debian.org Dear package screentest maintainer in Debian, After looking into the package you maintain (screentest, https://tracker.debian.org/pkg/screentest), I found that this package received no maintainer updates in the past 11 years and was not in good shape. As a result, I am filing an ITS (Intent to Salvage) request against your package according to section 5.12 in Debian's Developers' Reference [1]. My current plan is to clean up packaging, fix RC bugs and orphan this package to allow possible external contribution. Please let me know whether you are still willing to maintain this package. According to the criteria listed at [2], I will upload a Non- maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days (May. 09, 2022) to continue with the package salvaging. If you find it necessary to pause the ITS process, please let me know immediately by replying this bug report. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://wiki.debian.org/PackageSalvaging
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#970234: consider dropping "No hard links in source packages"
Hello Helmut On 12.10.2020 19:30, Helmut Grohne wrote: You appear to be talking about binary packages. This bug is about source packages. When you unpack a source package, you are creating a directory hiearchy rooted at the point where you start unpacking. There is not possibly any reasonable way to split your source package into multiple file systems. This is very different from binary packages where the underlying hiearchy is shared with other packages and directories frequently already exist. Your are totally right. And it is also on the subject line. So: I have not reasonable explanation. ciao cate
Bug#970234: consider dropping "No hard links in source packages"
On 12.10.2020 16:22, Andrey Rahmatullin wrote: On Mon, Oct 12, 2020 at 04:10:00PM +0200, Giacomo Catenazzi wrote: Now we are more strict on where we can split filesystems What do you mean? If I remember correctly, now we do not support / and /usr to be on a different filesystems, and I think there were few other corner cases which were forbidden. ciao cate
Bug#970234: consider dropping "No hard links in source packages"
On 13.09.2020 12:52, Helmut Grohne wrote: Package: debian-policy Version: 4.5.0.3 Severity: wishlist Jakub stumbled into the "No hard links in source packages" requirement added around 1996 and couldn't make sense of it. Neither could Christoph nor myself. tar does support hard links just fine. lintian does not check this property. sugar-log-activity/38 is an example package violating the property. It is shipped in buster and technically rc-buggy though no bug is filed about it. I believe that the requriement needs a rationale. Failing that, it should be dropped. The rationale was probably similar so symlinks: they may fail across different filesystems, and we supported to have e.g. / /usr /usr/share /usr/local /var (and various /var/*) /home /tmp /boot etc on different file systems. Now we are more strict on where we can split filesystems (and disk are larger, and LVM simplified much of filesystem handling). I think a hardlink on same directory should be fine, or within directories which must be on the same filesystem. ciao cate [for symlinks we have the problem with relative links (containing "../") passing filesystem boundaries]
Bug#969113: spell: Please upload new upstream version 1.1
On 27.08.2020 21:33, Tobias Frost wrote: Package: spell Severity: wishlist Thank you! Note: Debian version is more advanced than upstream. It may need some work to merge both "upstreams" (but GNU one had stricter requirement for copyright assignment, especially for such small wrapper). ciao cate
Bug#945181: ITA: libg15render -- Library for interfacing with the Logitech G15 keyboards
Hello Chris, Alexander already asked me about packages, and I have nothing again getting it adopted. Just I had no time (and hardware) to handle the packages, and the lack of upstream worries my a lot (e.g. security, but also upgrading support libraries). ciao cate On 27.11.19 19:22, Chris Knadle wrote: Greetings. Thanks for your interest in maintaining the libg15render package and for adopting the g15daemon package. Although I don't use g15, I maintain mumble which can optionally use it to support users that have the g15 keyboard. Right now I've had to disable g15 support in mumble because of the package removal that had occurred, but I can re-enable that if it's considered safe to do so. I'm CC:ing the current maintainer directly in order document them being notified of the ITA. This package IMHO is definitely available for salvage. Just for reference, the Debian Developer's Reference section 5.12.2 suggests normally giving the maintainer 21 days to respond before a salvage upload: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package Packaging of libraries is a special category in Debian, and I've never been involved in packaging a library so far, but am interested in how that works, and given what this package is for this library package seems to be of relatively low risk. I'm having another read through the Debian Developer's Reference section 6.7.2 concerning libraries: http://sejnfjrq6szgca7v.onion/doc/manuals/developers-reference/best-pkging-practices.en.html#libraries I see that Andrej Shadura is sponsoring uploads for your work with the g15daemon package; have you checked with him to see if he's comfortable sponsoring uploads for this package? Mainly I'm asking because the packages are related. Thanks -- Chris
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#914888: RM: g15deamoni, libg15 -- ROM; abandoned upstream (and upstream host serves malware)
Package: ftp.debian.org Severity: normal Hello masters! As maintainer, I request to remove g15deamon and libg15 packages. Note: the two packages are interdependent (part of A needs B, and part of B needs A), so the two packages should be removed in parallel. Upstream team is MIA since much time. I also do not have anymore the G15 Logitech keyboard. In any case such USB keyboard works nicely in Debian, also without the packages (it works just like normal keyboard). G23 and other keyboards get support directly from the kernel (and G15 should also now have such support from kernel). The upstream URL now serves malware (as I was told). ciao cate
Bug#886247: program dies with 'Wide character in subroutine entry at /usr/bin/listadmin line 556'
Package: listadmin Version: 2.42-1 Severity: normal If I press 'b' to check the body of the mail, the program dies. This is the first time in a lot of years of moderation, so I assume bad formatting in spam. [2/4] == commun...@lists.debian.ch = From: Subject: Re: notification #4393 for commun...@lists.debian.ch Reason: Post by non-member to a members-only listSpam? 0 Approve/Reject/Discard/Skip/view Body/Full/jump #/Undo/Help/Quit ? b Wide character in subroutine entry at /usr/bin/listadmin line 556. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (1000, 'stable'), (995, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages listadmin depends on: ii libcrypt-ssleay-perl 0.73.04-2 ii libnet-inet6glue-perl 0.603-2 ii libtext-reform-perl1.20-3 ii libwww-perl6.15-1 listadmin recommends no packages. listadmin suggests no packages. -- no debconf information
Bug#846490: missing tar(5) manpage
Package: tar Version: 1.27.1-2+deb8u1 Severity: minor on manpage of tar, I see: SEE ALSO tar(5) But this manpage (and file) don't exist in this or in other packages. It seems that a lot of information (but invocation) is missing in tar(1). ciao cate -- System Information: Debian Release: 8.6 APT prefers stable APT policy: (1000, 'stable'), (995, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages tar depends on: ii libacl1 2.2.52-2 ii libc62.19-18+deb8u3 ii libselinux1 2.3-2 tar recommends no packages. Versions of packages tar suggests: ii bzip21.0.6-7+b3 pn ncompress pn tar-scripts ii xz-utils 5.1.1alpha+20120614-2+b3 -- no debconf information
Bug#839624: Changing default fonts doesn't change bold version (so text is display incorrectly, with missing part of letters)
Package: qterminal Version: 0.6.1~102-g58f4f72-1 Severity: normal I just installed the font "inconsolata" (from package fonts-inconsolata), and set it in the preferences of qterminal. Now when I do a "ls" (with ls color as default), on qterminal I find that some names (directories, in bold blue) are stripped, missing the last part of name (either letters or final part of a letter). This is due to the start of the new column in "ls". lxterminal doesn't have this behaviour (it display normal and bold fonts with "inconsolata" , and it display the text correctly. I tested it in sid and experimental. On both versions, qterminal uses the wrong (default?) font for bold. ciao cate -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (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 Init: systemd (via /run/systemd/system) Versions of packages qterminal depends on: ii libc6 2.24-3 ii libgcc11:6.2.0-5 ii libqt5core5a 5.6.1+dfsg-3+b1 ii libqt5gui5 5.6.1+dfsg-3+b1 ii libqt5widgets5 5.6.1+dfsg-3+b1 ii libqt5x11extras5 5.6.1-2 ii libqtermwidget5-0 0.7.0-3 ii libstdc++6 6.2.0-5 ii libx11-6 2:1.6.3-1 qterminal recommends no packages. qterminal suggests no packages. -- no debconf information
Bug#781098: summit.debconf.org: full name from registration form should be used instead of first name + last name
Fixed in ba50877e8c0742d8ac9c19b8f553f54ec1648ce9 and deployed. Sorry if we ignored the bug for so much time. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780462: summit.debian.org: T-Shirt sizes uses (e.g.) large vs female large
On 14 Mar 2015, at 16:47, Brian Gupta brian.gu...@brandorr.com wrote: On Sat, Mar 14, 2015 at 8:45 AM, Niels Thykier ni...@thykier.net wrote: Package: summit.debconf.org Hi, The T-shirt sizes field in the registration field gives the following options: * Small ... Extra extra large * Female small ... Female extra extra large * No shirt selected I suspect this would be more gender neutral if we had Male small ... Male extra extra large in the first group. ~Niels In US English (not sure about UK), it would be more natural to say Men's and Women's sizes instead of (fe)male sizes. I personally believe that it also makes it clear that we are talking about adult sizes. e.g. - Women's small. I’m not sure. We used this for many DebConf, and IIRC the T-shirt cuts could be normal (stricter form of a T) of female cut. Women choose on of the two cuts. [Really men choose mainly the normal cut (but few very small for their children [my assumption] and women choose female or normal cut (plus also sometime the very small).] But i’m not an expert, so I’ll ask both about perception of “none/female” and how to formulate better. the sizes, without forcing women to choose female cuts. About the sizes: I’ll ask what size our provider could provvide and adapt. [we had very strong limitation of models, in order to have the exact same colours on all t-shirts]. cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705680: Malformed UTF-8 character and ... does not map to utf8 errors
Package: gwhois
Version: 20100728
Severity: normal
If I do the following gwhois, I get a lots errors, but not on the usual IPs.
prefixing LANG=X doesn't seems to correct the problem.
ciao
cate
$ gwhois 201.75.248.6 /dev/null
Malformed UTF-8 character (unexpected non-continuation byte 0x6f, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0xe3, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x6f, immediately
after start byte 0xe3) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x61, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0xe3, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x6f, immediately
after start byte 0xe3) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x72, immediately
after start byte 0xed) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x61, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x72, immediately
after start byte 0xed) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x6f, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0xe3, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x6f, immediately
after start byte 0xe3) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x61, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0xe3, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x6f, immediately
after start byte 0xe3) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x72, immediately
after start byte 0xed) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x61, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x72, immediately
after start byte 0xed) in pattern match (m//) at /usr/bin/gwhois line 542,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x6f, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 547,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0xe3, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 547,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x6f, immediately
after start byte 0xe3) in pattern match (m//) at /usr/bin/gwhois line 547,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x61, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 547,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0xe3, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 547,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x6f, immediately
after start byte 0xe3) in pattern match (m//) at /usr/bin/gwhois line 547,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x72, immediately
after start byte 0xed) in pattern match (m//) at /usr/bin/gwhois line 547,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x61, immediately
after start byte 0xe7) in pattern match (m//) at /usr/bin/gwhois line 547,
PATTERN line 1575.
Malformed UTF-8 character (unexpected non-continuation byte 0x72, immediately
after start byte 0xed) in pattern match (m//) at /usr/bin/gwhois line 547,
PATTERN line 1575.
\x{00e7} does not map to utf8 at /usr/bin/gwhois line 688, PATTERN
Bug#705201: The =163/8 is outdated
Package: gwhois Version: 20100728 Severity: minor Processing a spammer: gwhois 163.5.201.55 I get the answer that some addresses in the Early registration addresses are now distributed also to other RIR. Please update the lookup database. ciao cate -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38.6 (SMP w/8 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 gwhois depends on: ii curl 7.21.0-2.1+squeeze2 Get a file from an HTTP, HTTPS or ii debconf [debconf-2.0 1.5.36.1Debian configuration management sy ii libnet-libidn-perl 0.12.ds-1+b1Perl bindings for GNU Libidn ii libwww-perl 5.836-1 Perl HTTP/WWW client/server librar ii lynx-cur 2.8.8dev.5-1Text-mode WWW Browser with NLS sup ii perl 5.10.1-17squeeze6 Larry Wall's Practical Extraction gwhois recommends no packages. Versions of packages gwhois suggests: ii openbsd-inetd [inet-superse 0.20080125-6 The OpenBSD Internet Superserver -- debconf information: * gwhois/inetd: false gwhois/noinetd: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699382: extlinux fail to boot (error loading ldlinux.c32)
Package: extlinux Version: 2:5.00+dfsg-1 Severity: important Note: this bug is written with a downgraded extlinux. After last package update, when I boot, I get an error about loading ldlinux.c32. I tried several times to reinstall extlinux, but not changes, until I downgraded extlinux. [Note: system with raid, but I don't think it was the problem] -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.8.0-rc5-00193-g2e51b23 (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 extlinux depends on: ii cdebconf [debconf-2.0] 0.181 ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38 Versions of packages extlinux recommends: ii os-prober 1.57 ii syslinux-common 2:4.06+dfsg-3 ii syslinux-themes-debian 12-1.1 extlinux suggests no packages. -- debconf information: * extlinux/install: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687448: Kernel compiled with 4.7.1-8 fails to boot
On 13.09.2012 12:37, Matthias Klose wrote: On 12.09.2012 22:13, Giacomo Catenazzi wrote: Package: gcc-4.7 Version: 4.7.1-8 Severity: normal I cannot boot 3.6-rc5 (and some later) kernels. It blocks the kernel at very beginning (uncompress?) - does this mean, that earlier kernels built with -8 work ok? I don't know. I tested -8 only on new kernels. dpkg -i *_4.7.1-7_* on /var/cache/apt/archives/ solved my problems. Reproducible (but not very debuggable). - architecture, optimization flags? - how is the build reproducible? amd64. Standard vanilla kernels from git. No special flags. Reproducible: I tried a some kernels with old and new compiler (yes: I started to git bisect the kernel). With old compiler I have bootable kernel, with new compiler the kernel block at very beginning. So if you have a hint about what patch should I remove/apply, I could check if it solve the problem. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687448: Kernel compiled with 4.7.1-8 fails to boot
Package: gcc-4.7 Version: 4.7.1-8 Severity: normal I cannot boot 3.6-rc5 (and some later) kernels. It blocks the kernel at very beginning (uncompress?) dpkg -i *_4.7.1-7_* on /var/cache/apt/archives/ solved my problems. Reproducible (but not very debuggable). ciao cate -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.6.0-rc5-00044-g0bd1189 (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 gcc-4.7 depends on: ii binutils 2.22-7.1 ii cpp-4.7 4.7.1-7 ii gcc-4.7-base 4.7.1-7 ii libc6 2.13-35 ii libgcc1 1:4.7.1-8 ii libgmp10 2:5.0.5+dfsg-2 ii libgomp1 4.7.1-7 ii libitm1 4.7.1-7 ii libmpc2 0.9-4 ii libmpfr4 3.1.0-5 ii libquadmath0 4.7.1-7 ii zlib1g1:1.2.7.dfsg-13 Versions of packages gcc-4.7 recommends: ii libc6-dev 2.13-35 Versions of packages gcc-4.7 suggests: ii binutils-gold2.22-7.1 pn gcc-4.7-doc none pn gcc-4.7-locales none pn gcc-4.7-multilib none ii libgcc1-dbg 1:4.7.1-8 pn libgomp1-dbg none pn libitm1-dbg none pn libmudflap0-4.7-dev none pn libmudflap0-dbg none pn libquadmath0-dbg 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#620960: [PKG-IRC-Maintainers] Bug#620960: Packaging of inspircd
On 23.05.2011 00:41, Stig Sandbeck Mathisen wrote: Run: * Starts by default, disable in /etc/default/inspircd don't do that! A lot of people install a lot of programs without knowing what their are doing (and so also without knowing the security impacts). Further, now it nearly recommended to install all packages with priority optional. A IRC daemon is very dangerous: - some ISP blocks own IP where there is a open IRC port (it is a sign of botnet infection). - the standard IRC port are regularly scanned by bad people (and bots). Frequently these IRCd are used to control some hacked computers (via very dynamic DNS), so also if the ircd is secure for the local machine, it could cause problem to other computers (and to low home routers, because of IRC protocol and high connection rates.) - a ircd without admin (o-line) is useless, so user should in any case configure the IRC, to put own password. ciao cate * Default configuration updated from 2.0 examples * logging to to /var/log/inspircd/ * LSB compliant init script Please feel free to pull any changes you like to the inspircd packaging repo. cut-n-pastable test build instructions: $ sudo apt-get install git-buildpackage $ cd /tmp $ gbp-clone git://gitorious.org/ssm-deb/inspircd.git $ cd inspircd $ sudo apt-get build-dep inspircd $ git-buildpackage -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585411: 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 Golden...@debian.org [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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556654: restart in init.d script fails when rddcollect isn't running
Package: rrdcollect Version: 0.2.3-4+b2 Severity: normal Hello, the init.d script rrdcollect fail the restart target if rddcollect isn't running. The stop target in restart is missing the --oknodo flag (note that 'stop' target include it) ciao cate -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31.6 (SMP w/8 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 rrdcollect depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libpcre3 7.6-2.1Perl 5 Compatible Regular Expressi ii librrd4 1.3.1-4Time-series data storage and displ Versions of packages rrdcollect recommends: ii rrdtool 1.3.1-4Time-series data storage and displ rrdcollect 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#542008: mediawiki reccomends ImageMagick over PHP GD library
Package: mediawiki Severity: wishlist From http://www.mediawiki.org/wiki/ImageMagick (and setup page): Image thumbnailing requires either ImageMagick or GD library. ImageMagick is recommended since it produces better quality thumbnails; Thus the package dependencies should have imagemagick before php-gd ciao cate -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (102, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28.6 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540353: bash --posix: . (dot command) doesn't use PATH to search for scripts
Package: bash Version: 3.2-4 Severity: normal /tmp$ echo echo OK ok /tmp$ bash --posix -c . ok OK According POSIX: http://www.opengroup.org/onlinepubs/9699919799/toc.htm the dot command should look the path (and not the local dir). ciao cate -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable'), (102, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28.6 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 bash depends on: ii base-files5lenny3Debian base system miscellaneous f ii debianutils 2.30 Miscellaneous utilities specific t ii libc6 2.7-18 GNU C Library: Shared libraries ii libncurses5 5.7+20081213-1 shared libraries for terminal hand Versions of packages bash recommends: ii bash-completion 20080705 programmable completion for the ba Versions of packages bash suggests: pn bash-doc none (no description available) -- 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#539952: lxterminal doesn't pass Alt-number keys
Package: lxterminal Version: 0.1.6-1 Severity: normal lxterminal doesn't pass to applications the Alt-1 to Alt-9 keys (Alt-0 and Alt-letters works as expected). This is annoying when using irssi. ciao cate -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc4-00405-gb592972 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages lxterminal depends on: ii libatk1.0-0 1.26.0-1 The ATK accessibility toolkit ii libc6 2.9-23 GNU C Library: Shared libraries ii libcairo2 1.8.8-2The Cairo 2D vector graphics libra ii libfontconfig12.6.0-4generic font configuration library ii libfreetype6 2.3.9-5FreeType 2 font engine, shared lib ii libglib2.0-0 2.20.4-1 The GLib library of C routines ii libgtk2.0-0 2.16.5-1 The GTK+ graphical user interface ii libpango1.0-0 1.24.5-1 Layout and rendering of internatio ii libvte9 1:0.20.5-1 Terminal emulator widget for GTK+ ii libx11-6 2:1.2.2-1 X11 client-side library lxterminal recommends no packages. lxterminal 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#538389: ITP: rfkill -- tool for enabling and disabling wireless devices
Darren Salt wrote: Package: wnpp Severity: wishlist Owner: Darren Salt li...@youmustbejoking.demon.co.uk * Package name: rfkill Version : 0.1-4-g9429740 Upstream Authors: Johannes Berg, Marcel Holtmann, Tim Gardner * URL : http://wireless.kernel.org/en/users/Documentation/rfkill * Licence : BSD-style single-clause Programming lang: C Description : tool for enabling and disabling wireless devices rfkill is a simple tool for accessing the Linux rfkill device interface, which is used to enable and disable wireless networking devices, typically WLAN, Bluetooth and mobile broadband. . rfkill uses /dev/rfkill, which is present in Linux kernel 2.6.31 and later. I'm choosing a git snapshot over 0.1 because it contains some functionality which will be of use in eeepc-acpi-scripts. should be integrated in wirelesstools? ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532505: vlc: open dialog doesn't display file with extended characters
Package: vlc Version: 0.9.9a-2 Severity: normal Tags: l10n Open dialog doesn't show all files. I noticed that filename with char c128 are not displayed (not only the character, but file) ciao cate -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-rc8-00034-g81ee1ba (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages vlc depends on: ii libaa1 1.4p5-38 ascii art library ii libc6 2.9-13GNU C Library: Shared libraries ii libdbus-1-31.2.14-2 simple interprocess messaging syst ii libfreetype6 2.3.9-5 FreeType 2 font engine, shared lib ii libfribidi00.10.9-1 Free Implementation of the Unicode ii libgcc11:4.4.0-5 GCC support library ii libgl1-mesa-glx [libgl 7.4.1-1 A free implementation of the OpenG ii libglib2.0-0 2.20.3-1 The GLib library of C routines ii libglu1-mesa [libglu1] 7.4.1-1 The OpenGL utility library (GLU) ii libgtk2.0-02.16.2-1 The GTK+ graphical user interface ii libnotify1 [libnotify1 0.4.5-1 sends desktop notifications to a n ii libqtcore4 4.5.1-2 Qt 4 core module ii libqtgui4 4.5.1-2 Qt 4 GUI module ii libsdl-image1.21.2.6-3 image loading library for Simple D ii libsdl1.2debian1.2.13-4+b1 Simple DirectMedia Layer ii libstdc++6 4.4.0-5 The GNU Standard C++ Library v3 ii libtar 1.2.11-6 C library for manipulating tar arc ii libvlccore00.9.9a-2 base library for VLC and its modul ii libx11-6 2:1.2.1-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxv1 2:1.0.4-1 X11 Video extension library ii libxxf86vm11:1.0.2-1 X11 XFree86 video mode extension l ii ttf-dejavu-core2.29-2Vera font family derivate with add ii vlc-nox0.9.9a-2 multimedia player and streamer (wi ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime vlc recommends no packages. Versions of packages vlc suggests: pn mozilla-plugin-vlcnone (no description available) pn videolan-doc none (no description available) Versions of packages vlc-nox depends on: ii liba52-0.7.4 0.7.4-11library for decoding ATSC A/52 str ii libasound2 1.0.20-2shared library for ALSA applicatio ii libass3 0.9.6-1 library for SSA/ASS subtitles rend ii libavahi-cli 0.6.25-1Avahi client library ii libavahi-com 0.6.25-1Avahi common library ii libavcodec52 5:0.5+svn20090604-0.0 library to encode decode multimedi ii libavformat5 5:0.5+svn20090604-0.0 ffmpeg file format library ii libavutil49 4:0.5+svn20090420-2 ffmpeg utility library ii libc62.9-13 GNU C Library: Shared libraries ii libcaca0 0.99.beta16-1 colour ASCII art library ii libcdio7 0.78.2+dfsg1-3 library to read and control CD-ROM ii libdbus-1-3 1.2.14-2simple interprocess messaging syst ii libdca0 0.0.5-2 decoding library for DTS Coherent ii libdvbpsi4 0.1.5-3.1 library for MPEG TS and DVB PSI ta ii libdvdnav4 4.1.3-3 DVD navigation library ii libdvdread4 4.1.3-5 library for reading DVDs ii libebml0 0.7.7-3.1 access library for the EBML format ii libfaad0 2.6.1-3.1 freeware Advanced Audio Decoder - ii libflac8 1.2.1-1.2 Free Lossless Audio Codec - runtim ii libfontconfi 2.6.0-3 generic font configuration library ii libfreetype6 2.3.9-5 FreeType 2 font engine, shared lib ii libfribidi0 0.10.9-1Free Implementation of the Unicode ii libgcc1 1:4.4.0-5 GCC support library ii libgcrypt11 1.4.4-2 LGPL Crypto library - runtime libr ii libgnutls26 2.6.6-1 the GNU TLS library - runtime libr ii libhal1 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share ii libid3tag0 0.15.1b-10 ID3 tag reading library from the M ii liblircclien 0.8.3-3 infra-red remote control support - ii liblua5.1-0 5.1.4-3 Simple, extensible, embeddable pro ii libmad0
Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Raphael Geissert wrote: On Tuesday 02 June 2009 12:54:00 Bill Allombert wrote: [...] It does not make sense to policy to discourage echo -n. Policy could deprecate it in favor of something else, but I do not see any alternative mentioned in this bug report, and otherwise discouraging echo -n would amount to discourage shell scripts to display lines that does not end by a newline, while Policy 9.4. mandates that init scripts display Starting foo without an ending newline. Furthermore, adding vague recommendation to policy is a waste of resource. So, is there an alternative to echo -n that you would like to recommends, and are you willing to do the job to make sure that all Debian sh-compliant shells in Debian support it ? I think we could forbid echo -n on maintainer and other scripts, but allow it on init.d scripts. Rationale: - portability is more important on other scripts, and it is also not so frequent to use echo -n - init.d are system scripts which special requirement, so they are not portable. And we could ev. workaround with a special alias/path which set a non-portable echo. This is also simple because init.d scripts sould be called only by/via few programs/ Yes, printf. It is not an alternative: - It is ugly - it is not on root partition The ugly part it is IMHO the most important part. Most of people understand echo -n, but I don't know if all people understand fully printf. Mixing echo and printf is ugly. Anyway the standard are helper tools, not tools to make difficult the live of user and maintainer. See for example the recent discussion about ext3, see the old discussion about tar (tar is not in POSIX, people should use 'pax') BTW I think this is incorrect: $ POSIXLY_CORRECT=1 bash -c echo -n line one; echo line two; line oneline two ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528195: hobbit assumes to much abaout apache2
Package: hobbit Version: 4.2.0.dfsg-14lenny2 Severity: normal Setting up hobbit (4.2.0.dfsg-14lenny2) ... .: 44: Can't open /etc/apache2/envvars invoke-rc.d: initscript apache2, action reload failed. dpkg: error processing hobbit (--install): subprocess post-installation script returned error exit status 2 I had installed apache2, but since long time I disinstalled it and I'm using lighhtpd. So I think that hobbit.postinst should have - test -e /etc/init.d/apache2 invoke-rc.d apache2 reload + test -e /etc/init.d/apache2 invoke-rc.d apache2 reload || true [I'm not sure about priorities of shell operators] Note: it seems that there are other problems when /etc/apache2 exists, but invalid ciao cate -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28.6 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 hobbit depends on: ii hobbit-client4.2.0.dfsg-14lenny2 client for the Hobbit network moni ii libc62.7-18 GNU C Library: Shared libraries ii libldap-2.4-22.4.11-1OpenLDAP libraries ii libpcre3 7.6-2.1 Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.27-2+lenny2 PNG library - runtime ii librrd4 1.3.1-4 Time-series data storage and displ ii libssl0.9.8 0.9.8g-15+lenny1SSL shared libraries hobbit recommends no packages. hobbit 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#523093: undetermined copyright/license violation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Millan wrote: On Thu, Apr 09, 2009 at 10:27:19PM -0500, Adam Majer wrote: License and copyright are one and the same. GPL license relies on copyright law, just like almost any other open source license there is, be it BSD, Artistic or LGPL. Without copyright, the license is meaningless. Without license, you have no right to the source code. Thanks for the explanation; but I think what you mean is they're dependant on each other. This doesn't imply they're the same thing though. I think we all agree the Copyright lines, whenever they were present, need to be preserved. The license bits in general too, but what happens when the license terms explicitly give you permission to relicense? I gave this example in another mail (sorry if I sound redundant); my understanding is that in 2 or later terms in a GPLv2+ header the license version can be updated by recipients of the code, and that keeping the old license blob around is not a must; is this correct? Does section 12 of LGPL 2.1 work the same way? If not, where's the difference? No, and anyway, Debian should never do it. 2 or later mean that the recipient could *use* a later license, the derived works could be licensed with (maybe only) a later license, but no, the original code has own (old) license and cannot (should not) be changed. Maybe taking derived code (e.g. including new code), one could write only the license of aggregate work (thus one later license), but I think: 1- the old code is still 2 or later 2- it is better not to mix licenses in one file, so it is better to add new code or with the same license or in an extra file (no problem removing part of old file) 3- Debian should allow the more liberal license as possible, thus maintaining the option to use the old license terms. ciao cate -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknlgYQACgkQ+ZNUJLHfmlfq9ACgltEdKfRp82yN9Xqwmpt86adG 2zkAn3PK/1V3O5UkLrcgH+2MuS9Hu760 =UOei -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
Steve Langasek wrote: On Fri, Feb 27, 2009 at 09:46:15AM +0100, Giacomo A. Catenazzi wrote: Given that m-t-a is mentioned explicitly in policy, and that default-mta will be a virtual package, I think this should be recorded in policy as well - though if a clear consensus emerges on debian-devel, there's no need to go through the policy process before filing bugs. Hmmm. I partially agree, but then we have an unnecessary exception: such virtual packages must have only one provider, or else there will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency is declared as first dependency [1]. From the definition of the virtual package in question, it should have only one provider at a time. And this is an exception, which I want to avoid. So let try to work around with normal package. If we fail, I agree with the virtual package. I would prefer to create a real empty package: default-mta (maybe in a source package debian-defaults), which depends on exim. This unavoidably couples Debian's choice of a default MTA for users who install the new release, to the behavior for users who are upgrading from a previous release, because users who have such a 'default-mta' package installed will find their MTA changed on dist-upgrade. What about an other level of indirection: package debian-mta: Depends: exim | mta-mail-transfer-agent I think this case will solve upgrades, and changing easily the mta (without causing a failed dependency). ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515130: AW: Bug#515130: ITP: unrealircd -- Unreal IRC Server
Rondal wrote: Hi, UnrealIRCd has many licensing and code-quality issues which would block it's inclusion in a Debian release. I admit that the sourcecode is not of the highest quality, but I do not see where it will block inclusion into Debian. About the licensing issues I already said that their license is incompatible with the OpenSSL license but thats it. Please be a little bit more specific. If I missed something important within their license or code, I will gladly reconsider building this package. IIRC unrealircd will pass to inspiricd sources, so I recommend you to evantually pack only the develpement version. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513955: debian-policy: do not require /etc/init.d/*.sh scripts to be sourced
Russ Allbery wrote: Kel Modderman k...@otaku42.de writes: It is the opinion of myself and Petter Reinholdtsen, maintainers of the sysvinit package, that the last sentence of §9.3.1 of policy is no longer relevant and should be removed: Also, if the script name ends in .sh, the script will be sourced in runlevel S rather than being run in a forked subprocess, but will be explicitly run by sh in all other runlevels. The reasons for which it should be removed are: * /etc/init.d/rc has not supported this for an extremely long time, probably never, because the system would be unbootable due to .sh scripts calling 'exit' [0, 1]. Given this, I definitely agree. There's no point in having a statement like this in Policy when our core packages don't implement it and no one has apparently cared. Unless someone steps up to say that we should do the work to reimplement support for this interface (including fixing all the broken *.sh scripts we have now), I think it's obvious we should simply remove it. There's no need to specify things no one uses and clearly can do without. I agree. BTW LSB doesn't have such special case, so such proposal will converge to LSB, which is also positive. ciao cate -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507529: ITP: bauble -- Bauble is a biodiversity collection manager software application
Package: wnpp Severity: wishlist Owner: Giacomo Catenazzi [EMAIL PROTECTED] * Package name: bauble Version : 0.8.5 Upstream Author : Brett [EMAIL PROTECTED] * URL : http://bauble.belizebotanic.org * License : GPL v2 Programming Lang: Python Description : Bauble is a biodiversity collection manager software application Bauble is a software application to help you (yes you) manage a collection of botanical specimens. It is intended to be used by botanic gardens, herbaria, arboreta, etc. to manage their collection information. It is a open, free, cross-platform alternative to BG-Base and similiar software. Features: - Bauble is designed to be simple, elegant and intuitive. - Bauble can use different database backends and is tested against SQLite and PostgreSQL. - Bauble can generate reports through an XSL formatter backend. - Bauble is transaction safe. - Bauble can export data in CSV or Access to Biological Collection Data (ABCD) format. In the future we hope to support other standard formats such as DarwinCore, ITF2, BioCASE, TAPIR, etc. - Bauble supports tagging. You can tag any arbitrary data stored in a Bauble managed database with arbitrary names. - and lots more. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495233: debian-policy: README.source content should be more detailed
Lucas Nussbaum wrote: First, section 4.14 should list things that one does not need to describe in debian/README.source. For example, the use of one of the standard patch systems (quilt, dpatch, simple-patchsys) doesn't need to be documented, since every NMUer should be able to work with them. Another example is build systems: cdbs is used by 20% of our packages, so I don't think that one need to document its use. I think the better way is do it similar to copyright: for common patch/build system we should include only a link to the relative document. Maybe on a common package (build essential or dpkg-dev) or on patch system package (but in this case we should push stronger the maintainer to include the relevant informations). BTW debian/README.source is not only for the MNUer, but also for our users, so I prefer redundant documentation. Also, it would be interesting to extend the use of debian/README.source to other areas, such as: - whether the maintainer encourages commits for other people directly to the package's VCS. - the branch layout in the package's VCS. I agree with that. PS: you should provide a patch! ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494838: RM: knapster2 -- ROM; useless package (MIA upstream, MIA opennap networks)
Package: ftp.debian.org Severity: normal I request removal of this package. I adopted it, hoping on finding new upstream authors, which I did not find. the package was already in a nearly unusable status (it connect only on single network, no automatic network selection, no meta-network handling). Additionally the opennap networks seems closed (people uses other P2P networks). Also the most popular opennap client (xnap) has been removed, so I think there is no interest in napster like P2P. ciao cate -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.13 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494861: installkernel has a wrong assumption in powerpc: 4 or less parameters (powerpc uses 5 args)
Package: debianutils Version: 2.30 Severity: normal The /sbin/installkernel expects 3 or 4 arguments, but on powerpc, kernel uses 5 arguments: From arch/powerpc/boot/install.sh # make install script for ppc64 architecture # # Arguments: # $1 - kernel version # $2 - kernel image file # $3 - kernel map file # $4 - default install path (blank if root directory) # $5 - kernel boot file, the zImage According to the rest of the kernel scripts, the default installation could ignore the 5th arguments. Ignoring the 5th argument seems to work well (but I did not check other archs) ciao cate -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.26 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 debianutils depends on: ii libc6 2.7-13 GNU C Library: Shared libraries debianutils recommends no packages. debianutils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479080: debian-policy: Policy '3.8 Essential packages' does not explain when/why essential is neccessary
Steve Langasek wrote: On Thu, Jun 05, 2008 at 06:25:14PM +0200, Giacomo A. Catenazzi wrote: Manoj Srivastava wrote: Hi, On Fri, 02 May 2008 17:45:30 +0200, Carl Fürstenberg [EMAIL PROTECTED] said: Policy section 3.8, about essential packages, doesn't explain when/why essential is neccessary, only that it should not be essential if it's not necessary. My understanding is that a package is Essential if without it is impossible to install any more packages to the system -- that is, the package is required for proper functioning of dpkg. If my understanding is correct, it should be easy to add in a line about when packages can be made Essential. In addition Essential is also used not full dependencies with obvious packages. (Policy 3.5) This is not part of the rationale for a package's inclusion in Essential, it's an effect of a package's inclusion in Essential. Packages should only be in the Essential set if they have to be there to guarantee the operation of dpkg. I'm not so sure. Or better, I agree the first paragraph (a package will become Essential if it is need by dpkg), but I really think that the second part it is wrong: I don't think we should remove easily the essential status from a package. Packages expect essential package to be installed, without requiring dependencies, so a lot of package will broke on removal of some essential. I think policy should include a incomplete list of essential package, because of the side effect (no dependencies on essential package). ciao cate Note: From Klecker ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=50832 ): [1] Essential means that the package does not need to be depended on (essential does not seem to be guaranteed to work for implicit Pre-Depends), however the thing that bash provides that is essential is /bin/sh. (...) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476769: latencytop: Many features seem to lack any documentation
Sami Liedes wrote: At least some useful features of latencytop seem to be entirely undocumented (even in the website referenced in the manpage...). At least some of them: * The -d switch for cursesless interface (dump once to stdout) * The --unknown switch is only mentioned in the SYNOPSIS * Q key to quit * R to refresh Yes. There is very few documentations, and I'm not so good writing manpages. From sources there are only two options: -d and --unknow (no ui, print unknow symbols), and few UI keys: Z, A, D, Up, Back: previous process X, B, C, Down, Forward: forward one process Q: quit R: refresh data ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463078: g15daemon: LCD keys do not appear to be reported to X
I think it is the expected behaviour: the L keys are used to control the display: change client, and client specific behaviours (clock display mode on default client). So the key is used in g15deamon and thus it is not exported. BTW you don't need Xmodmap file. See the README file, to see how to configure xorg to use g15daemon keys. 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
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: string.h, exit: stdlib.h
+
+ -- 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 stdio.h
++#include stdint.h
+
+ 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 stdio.h
++#include string.h
++#include stdlib.h
+
+ 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#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: string.h, exit: stdlib.h).
+
+ -- 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 stdio.h
++#include stdint.h
+
+-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 stdio.h
++#include stdint.h
+
+-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 stdio.h
+ #include stdint.h
++#include string.h
++#include stdlib.h
+
+ 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#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#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#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#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#453041: Country Liechtenstein not in country list when selecting German as language in installer
Christian Perrier wrote: Quoting Giacomo A. Catenazzi ([EMAIL PROTECTED]): CC: to madduck. IIRC he is rewriting the locales for Switzerland, so probably he could do quickly also for Liechtenstein too. BTW madduck: there is some news about the project? In case madduck is too busy elsewhere, I can quite probably hack down a quick locale for de_LI. After all, this is only a matter of getting information about the country which may be easily found here and there. The language part is of course assumed to be well covered by picking another german-based locale (either de_CH or de_DE...they're probably similar when it comes at language even if some would say that German in Switzerland is different from German in Germany...at least for written language, I guess both are identical). It is not only about languages, but also about numbers and currencies and other conventions. Here a proposal for de_LI. Btw a good documentation about the format is in: http://std.dkuug.dk/jtc1/sc22/wg20/docs/n822-dtr14652.pdf comment_char % escape_char / % % German locale for Liechtenstein % Language: de % Territory: LI % Revision: 1.0 % Date: 2007-11-27 % Users: general % Repertoiremap: mnemonic.ds % Charset: ISO-8859-1 % Distribution and use is free, also % for commercial purposes. LC_IDENTIFICATION title German locale for Liechtenstein source address contact email [EMAIL PROTECTED] tel fax language German territory Liechtenstein revision 1.0 date 2007-11-27 % category de_LI:2000;LC_IDENTIFICATION category de_LI:2000;LC_CTYPE category de_LI:2000;LC_COLLATE category de_LI:2000;LC_TIME category de_LI:2000;LC_NUMERIC category de_LI:2000;LC_MONETARY category de_LI:2000;LC_MESSAGES category de_LI:2000;LC_PAPER category de_LI:2000;LC_NAME category de_LI:2000;LC_ADDRESS category de_LI:2000;LC_TELEPHONE END LC_IDENTIFICATION LC_CTYPE copy de_CH END LC_CTYPE LC_COLLATE copy de_CH END LC_COLLATE LC_MESSAGES copy de_CH END LC_MESSAGES LC_MONETARY copy de_CH END LC_MONETARY LC_NUMERIC copy de_CH END LC_NUMERIC LC_TIME copy de_CH END LC_TIME LC_PAPER copy de_CH END LC_PAPER LC_TELEPHONE tel_int_fmtU002BU0025U0063U0020U0025U0061U0020U0025/ U006C int_prefix U0034U0032U0033 END LC_TELEPHONE LC_MEASUREMENT copy de_CH END LC_MEASUREMENT LC_NAME copy de_CH END LC_NAME LC_ADDRESS postal_fmtU0025U0066U0025U004EU0025U0061U0025U004E/ U0025U0064U0025U004EU0025U0062U0025U004EU0025U0073/ U0020U0025U0068U0020U0025U0065U0020U0025U0072U0025/ U004EU0025U0025U007AU0020U0025U0054U0025/ U004EU0025U0063U0025U004E country_ab2 U004CU0049 country_ab3 U004CU0049U0045 country_num 438 END LC_ADDRESS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442549: libfreetype6-dev: Wrong include in /usr/include/ft2build.h
Steve Langasek wrote: On Sun, Sep 16, 2007 at 04:57:21PM +0200, Giacomo A. Catenazzi wrote: Package: libfreetype6-dev Version: 2.3.5-1+b1 Severity: normal In /usr/include/ft2build.h there is a line: #include freetype/config/ftheader.h but this file file is not in the usual C include path, so change it to: #include freetype2/freetype/config/ftheader.h No, packages that build with libfreetype6-dev are expected to use the include path settings provided by pkg-config --cflags freetype2. No ;-) It is supposed that including a #include header.h will not break C code. If the pkg-config --cflags freetype2 is required, you should move the ft2build.h from /usr/include/ to /usr/include/freetype2/ so that the file will be found only if the right pkg-config is found. ciao cate BTW, personally I find pkg-config only hacks for local installations, but a distribution IMHO should already install and put together things in a better way, but maybe this will be a future step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439872: please include microcode updates for core duo CPUs
Soeren Sonnenburg wrote: Package: microcode.ctl Version: 1.17-3 Severity: wishlist Rudolf Marek posted on June 21 a way to also extract core duo microcode updates, which fixes the infamous Errata AE18 not fixed, update BIOS or microcode of the CPU!. It seemes that Intel forgot to include some microcodes when he packed the ucodes for Linux. Thank to your report, Intel released a more complete version. Could you check that actual version (use update-intel-microcode command to download the last version) correct the original bug? thanks, cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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#439872: please include microcode updates for core duo CPUs
Soeren Sonnenburg wrote: Package: microcode.ctl Version: 1.17-3 Severity: wishlist Rudolf Marek posted on June 21 a way to also extract core duo microcode updates, which fixes the infamous Errata AE18 not fixed, update BIOS or microcode of the CPU!. Could give me more info (links) about these microcodes? ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439872: please include microcode updates for core duo CPUs
Soeren Sonnenburg wrote:
On Tue, 2007-08-28 at 09:12 +0200, Giacomo Catenazzi wrote:
Soeren Sonnenburg wrote:
Package: microcode.ctl
Version: 1.17-3
Severity: wishlist
Rudolf Marek posted on June 21 a way to also extract core duo microcode
updates, which fixes the infamous Errata AE18 not fixed, update BIOS or
microcode of the CPU!.
Could give me more info (links) about these microcodes?
not really... as you can see the microcodes are extracted from ibm
thinkpads bios updates ... errata AE18 is the temperature sensor not
anymore working (important if you have a macbook* core one duo and as
apple did/does not release firmware/bios updates to fix this it is
necessary to get temperature monitoring workin) ...
errate list is here:
http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif
I don't understand why new intel microcodes doesn't include it.
I'll ask Intel, but for one of the next version I'll include
also a small utility to extract information from microcode,
to show CPU and microcode date.
I attach a preliminary version. I used this version to check
what wrong with microcodes (a strange microcode caused reject
of all updates, because of a kernel bug).
ciao
cate
/* */
#include stdlib.h
#include stdio.h
#define BUFFER_SIZE 4096
#define MICROCODE_SIZE (64*1024)
static
int check_microcode(const unsigned int microcode[], size_t len, const char title[]) {
unsigned int header = microcode[0];
unsigned int version = microcode[1];
unsigned int date = microcode[2];
unsigned int cpu = microcode[3];
unsigned int checksum = microcode[4];
unsigned int loader = microcode[5];
unsigned int flags = microcode[6];
unsigned int size = microcode[7];
unsigned int tot_size = microcode[8];
unsigned int cpu1 = cpu 0xff;
unsigned int cpu2 = cpu 8u 0xff;
unsigned int cpu3 = cpu 16u 0xff;
unsigned int cpu4 = cpu 24u 0xff;
unsigned int sum = 0;
size_t i;
if(size == 0)
size = 2000;
if(tot_size == 0)
tot_size = 48 + size;
printf(sec:%14s, header:%1u, loader:%1u, date: %08x, version:%4u, cpu:%8x, flag1:%08x, ,
title,header, loader, date, version, cpu, flags);
if(len*4 != tot_size || size 2000 || tot_size 2048) {
fprintf(stderr, Size error: readed: %u, tot_size: %u, size: %u\n, len, tot_size, size);
return 1;
}
for(i=0; ilen; i++) {
sum += microcode[i];
}
if (sum == 0) {
printf(checksum ok!\n);
} else {
printf(checksum error\n);
}
}
static
int read_microcode(void) {
int line_no = 0;
char line_buffer[BUFFER_SIZE+1];
char title[16+1];
unsigned int microcode[MICROCODE_SIZE+1];
size_t pos = 0;
int scanned;
title[0]=0;
while(fgets(line_buffer, BUFFER_SIZE, stdin) != NULL) {
++line_no;
if (line_buffer[0] == 0) {
if (pos != 0)
check_microcode(microcode, pos, title);
continue;
}
if (line_buffer[0] == '/' line_buffer[1] == '*') {
if (pos !=0)
check_microcode(microcode, pos, title);
pos = 0;
if ( sscanf(line_buffer, /* %16s.inc , title) != 1) {
title[0] = 0;
}
continue;
}
if (line_buffer[0] == '/')
continue;
scanned = sscanf(line_buffer, %x, %x, %x, %x,
microcode + pos,
microcode + pos + 1,
microcode + pos + 2,
microcode + pos + 3);
if(scanned != 4) {
fprintf(stderr, Invalid format at line %i\n, line_no);
return 1;
}
pos += 4;
}
}
int main() {
read_microcode();
return 0;
}
Bug#439792: ITP: g15tools and g15daemon -- support for g15 logitech keyboard (LCD display + extra keys)
Package: wnpp Severity: wishlist Owner: Giacomo Catenazzi [EMAIL PROTECTED] * Package name: g15tools and g15daemon Version : latest Upstream Author : [EMAIL PROTECTED], [EMAIL PROTECTED] * URL : http://g15tools.sourceforge.net/ * License : GPL Programming Lang: C Description : support for g15 logitech keyboard (LCD display + extra keys) G15 is a Logitech keyboard that have a nice LCD display and a lot of extra keys. Our KDE already have support to use g15daemon, but g15daemon is not yet in Debian. So I intent to pack the most important packages in the df projects: g15tools (mainly the library and tools for to format the display) and g15daemon (the daemon, to share display with many applications). BTW the peojects have a lot of sub-project/sources, but primary I intend to pack the main programs, and in a second step I'll check if there is need for other programs (mainly support and interface between current packages and the extra display). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.21.3 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429445: microcode.ctl: [debconf_rewrite] Debconf templates and debian/control review
Christian Perrier wrote: Package: microcode.ctl Version: N/A Severity: normal Tags: patch On Wednesday, July 04, 2007, I will contact you again and will send a final patch summarizing all the updates (changes to debconf templates, updates to debconf translations and new debconf translations). I didn't receive nothing. Spam filter problem? Or I can upload directly the patches on BTS? ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430761: microcode.ctl: fails to install
Jim Paris wrote: I figured out the problem: the microcode module was not loaded. (my kernel has CONFIG_MICROCODE=m). After modprobe microcode and apt-get -f install, everything was OK. I think this is because when the microcode module is not loaded, /dev/cpu/microcode does not exist, and so the postinst calls makedev, which prints a diagnostic message about udev active to stdout. Also, another message would have been printed to stdout if I didn't have an Intel processor. man debconf-devel says about the postinst script: * Always source /usr/share/debconf/confmodule at the top of your postinst, even if you won't be running any db_* commands in it. This is required to make sure the config script gets a change to run (see HACKS for details). * Avoid outputting anything to stdout in your postinst, since that can confuse debconf, and postinst should not be verbose anyway. Output to stderr is ok, if you must. I moved . /usr/share/debconf/confmodule to the very top of the postinst, below set -e, and the problem went away. I presume /usr/share/debconf/confmodule somehow works around the stdout problem -- but it would probably also be good to redirect all output to stderr anyway. I would also recommend that you don't unconditionally unload the microcode module in /etc/init.d/microcode.ctl. If I, for example, included microcode in /etc/modules, I wouldn't expect a startup script to undo that. I already found and corrected the error handling, but I had noticed than /usr/share/debconf/confmodule should be shared at the top. Thanks. For the modules, I should check again. With previous modutils (for 2.2 and 2.4 kernels), we loaded microcode modules with auto and removed only if had this flag. It is possible that new modutils don't handle this flag (or better: all modules are auto). Anyway, why do somebody need microcode modules loaded? I think only microcode.ctl use this module (and in future udev, but in this case only at module loading). 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]
Bug#419214: RFA: screentest -- Utility to test the quality of CRT screens
If you still want to orphan it, I can take it. I've tried to update the libraries, and I success. Otherwise, after I clean and check my patch, I'll sent to you. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428822: microcode.ctl fails to configure on an amd machine
Zoran Dzelajlija wrote: Package: microcode.ctl Version: 1.17-1 Severity: important [14:58] ~ = sudo dpkg --configure -a Setting up microcode.ctl (1.17-1) ... microcode.ctl: Yet we provide only microcodes for Intel processors Your CPU seems not an Intel processor Could you send me the output of: cat /proc/cpuinfo Thanks, cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411060: lxr-cvs: Install instructions don't result in a working apache2 setup
Bill Gatliff wrote: Had a chance to look at this? Sorry. I forgot about this. You should modify the file /etc/apache2/conf.d: you should replace twice /usr/share/lxr into /usr/share/lxr/http I'm traying to upload a new version of package. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411060: lxr-cvs: Install instructions don't result in a working apache2 setup
Giacomo Catenazzi wrote: Bill Gatliff wrote: Had a chance to look at this? Sorry. I forgot about this. You should modify the file /etc/apache2/conf.d: you should replace twice /usr/share/lxr into /usr/share/lxr/http I'm traying to upload a new version of package. Sorry. I was using the wrong version use in /etc/apache2/conf.d/lxr ScriptAlias /lxr /usr/lib/cgi-bin/lxr It seems that newer version of apache2 works only with ScriptAlias. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407801: icedove crash when reading DSA mail (maybe is an enigmail problem)
Alexander Sack - Debian Bugmail wrote: On Sun, Jan 21, 2007 at 02:55:06PM +0100, Giacomo A. Catenazzi wrote: When reading the DSA-1249-1, icedove crashes. It follow the stack trace with icedove-dbg. Note that enigmail is used, but it seems that the crash is just after the enigmail report untrusted good signature. Does this happen with other mails too? No. DSA-1248 and 1250 have no problems (signed with the same key), and I had no problems with a lots more mails. Always reproducible? at 90%. Only once I was able to read the DSA-1249-1 mail. Test before and after was always positive (= crash) What extensions do you have installed in addition to enigmail? only enigmail. Does starting with -safe-mode help? Yes. with safe-mode it doesn't crash. ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407801: icedove crash when reading DSA mail (maybe is an enigmail problem)
Alexander Sack - Debian Bugmail wrote: OK at about 2000 UTC today (Sun 21 Jan) you can get enigmail_0.94.2-1_i386.deb from http://people.debian.org/~asac/unstable it should install in etch too. Please test if it fixes and works well. If you need to respin (amd64), I guess you know how :). With the new version, it works well. Thanks! ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378695: procps: top seg fault if the dir /proc is not listable (readable)
Package: procps Version: 1:3.2.1-2 Severity: minor If the mounting point proc has only x instear of rx for others, top segfault. From a gdb session (on sarge) (gdb) run Starting program: /home/cate/tmp/procps-3.2.1/top Program received signal SIGSEGV, Segmentation fault. 0xb7f47baa in readproc () from /lib/libproc.so.3.2.1 (gdb) bt #0 0xb7f47baa in readproc () from /lib/libproc.so.3.2.1 #1 0x0804b8a6 in procs_refresh (table=0x80580f8, flags=73) at top.c:1070 #2 0x0804ee66 in summary_show () at top.c:2867 #3 0x0804fec6 in frame_make () at top.c:3216 #4 0x080501d5 in main (dont_care_argc=1, argv=0x804a280) at top.c:3275 Bug ha priority minor because is not common to have such permition of /proc, and the lack of this check (also on other procps programs) should not add security troubles. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.17.4 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages procps depends on: ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an ii libncurses5 5.4-4 Shared libraries for terminal hand -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
