Bug#328808: very old package, should this be removed?
Package: zone-file-check Version: 1.01-3 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. It's very old, seems to have no upstream development anymore, has not many users and there are some alternatives. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Mar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328809: very old package, should this be removed?
Package: escm Version: 1.1-4 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package has some bugs, is quite out of date wrt Debian's policies, has almost no users and seems to be upstream-dead. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328810: very old package, should this be removed?
Package: xodo Version: 1.2-9.2 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. It hasn't had a maintainer upload in a looong time, is quite out of date wrt Debian's policies, has not many users and at least one (kodo) alternative. Upstream development is also stalled. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328811: very old package, should this be removed?
Package: powstatd Version: 1.5.1-1 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package has almost no users, is quite out of date wrt Debian's policies and there are some alternatives available. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328812: very old package, should this be removed?
Package: doc-linux-ko Version: 1:20010417-1 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package is quite old and isn't useful nowadays, as many things have changed in the last 4 years. Because of that, the package has almost no users. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328814: very old package, should this be removed?
Package: debian-history-ko Version: 0.1 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. This package is very old and has almost no users. As long as it isn't kept up to date, it's useless. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328813: very old package, should this be removed?
Package: vmnet Version: 0.4-1 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package hasn't been updated in the last 4 years, has some bugs, very few users. You've already filed a bug to find a new maintainer for it, but as noone has stepped up, it's probably the best to remove the package from the archive. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328815: very old package, should this be removed?
Package: gmgaclock Version: 0.4.8-2 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package has very few users and is quite out of date wrt Debian's policy. There are also some open bug reports. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328817: very old package, should this be removed?
Package: bloksi Version: 0.0.2001.07.13-1 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package has very few users and is only a Perl rewrite of the Glotski game. It also depends on the obsolete libgnome-perl. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328816: very old package, should this be removed?
Package: vgagamespack Version: 1.4-5 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package wasn't updated in the last years and there are many alternatives available. The number of users is also very small. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328818: very old package, should this be removed?
Package: pcrd Version: 0.10-2 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package has more or less no users, no upstream development and is quite out of date wrt Debian's policies. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328819: very old package, should this be removed?
Package: math3d Version: 0.3.0-4 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. There are almost no users, some important bugs and no upstream development (at least I couldn't find it). This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Mar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328821: very old package, should this be removed?
Package: emwin Version: 0.93-6 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. It's old and has almost no users. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328820: very old package, should this be removed?
Package: tik Version: 0.90-1 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. It doesn't have many users, is quite out of date wrt Debian's policies and there alternatives available. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#227777: Removal of the flin package
retitle 22 RM: flin -- RoQA; old, unused, orphaned for a long time reassign 22 ftp.debian.org thanks Hi, The package is old, unused, upstream dead and has no Debian maintainer. Clear case. Marc -- Fachbegriffe der Informatik - Einfach erklärt 282: Perl Der geglückte Versuch, einen braindump direkt ausführbar zu machen. (gefunden von Alexander Schreiber)
Bug#328837: very old package, should this be removed?
Package: titrax Version: 1.98.1-6 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package has not many users and there are some alternatives (worklog, wmwork) available. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328838: very old package, should this be removed?
Package: camlp4-doc Version: 3.02-1 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. There are only very few users and I have to admit that I don't understand which package contains camlp4... This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328839: very old package, should this be removed?
Package: regex Version: 0.12-15 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. There are very few users and the package FTBFSed at the moment. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328840: very old package, should this be removed?
Package: pc532down Version: 1.1-9 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. It has, according to popcon, no users at all. Do we really need it in etch? This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328847: very old package, should this be removed?
Package: saxon-catalog Version: 2203-4 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. It has not many users, was NMUed twice and has 2 RC bugs at the moment. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328851: very old packages, should these be removed?
Package: sitescooper,sitescooper-sites Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your packages showed up on the list. I propose to remove them. There are some open bug reports, but not many users, upstream development seems to be dead and there are alternatives like plucker (plus the fact that mobile devices nowadays have full-blown browsers and/or special WPA content) This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328853: very old package, should this be removed?
Package: tag-types Version: 0.0.9-4 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. There are very few users, upstream development is pretty dead and the package is quite out of date wrt Debian's policies. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328854: very old package, should this be removed?
Package: nwutil Version: 1.4-3 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. There are almost no users, but some open bugs. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328856: very old package, should this be removed?
Package: samba-doc-ja Version: 2.0.6+ja1.0-3 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. There are very few users and the package is not in sync with the samba version distributed by Debian. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328857: very old package, should this be removed?
Package: libfloat Version: 990616-3 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. popcon doesn't even provide data for this package, it's very old and has probably lost all it's uses. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328859: very old package, should this be removed?
Package: safe-hole-perl Version: 0.08-3.1 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. There are very few users and though a new upstream release is available for some time, nobody has requested it yet. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328860: very old package, should this be removed?
Package: libhs Version: 0.1.3 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. There are no users. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328862: very old package, should this be removed?
Package: gidic Version: 0.2-3 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. It has not many users, there are some alternatives as dictionaries available and the program itself is based on Gtk1.2, which should get removed for etch. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Mar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328863: very old package, should this be removed?
Package: ultrapoint Version: 0.4-9 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. The package has some open bugs, 4 (!) not acknowledged NMUs and almost no users. It's probably time to remove it, as there are plenty of alternatives available. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328866: very old package, should this be removed?
Package: opennap Version: 0.44-2 Severity: serious Hi, During the Debian QA meeting hold during Sept. 09th till 11th, we decided that looking at packages that haven't been uploaded for a very long time could cover up some QA problems. I've done this now and your package showed up on the list. I propose to remove it. It has almost no users and some open bugs. This usually means that your package matched some of the following criteria: [1] Your packages has not had a maintainer upload for more than three years. [2] has one or more RC bugs with no answer from the maintainer (**) [3] the state of your packages in general seems to indicate that you might be MIA [4] (if we propose a removal) it shows in popcon as having less than 100 users with the package installed. [5] the package was not released with sarge and at least ([1] and ( [2] or [3] or [4] or [5] )) was true. (**) The maintainer not answering to RC bugs refers to bugs filed more than one month before the time the check was performed. After 7 days without answer from you (the maintainer) we will reassign this bug to either WNPP (in case we propose to orphan it) or ftp.debian.org (in case we propose to remove it). The package will need an upload or an explanation for this action not to proceed. Please do *not* upload a package just to get off this list - it won't help the package at all. Maintainers should be responsive and feel responsible for their packages without needing other people to force them to do work. Sometimes, finding a new maintainer or even removing the package completly from the archive is better for Debian's users. Thanks! Mar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328673: Very old means it’s stable
Michael Piefel <[EMAIL PROTECTED]> writes: > Thank you for your concern, but honestly: Where is the severe violation > of Debian policy in this package that justifies the severity youâ've > given? Old, *unsupported* packages are, by definition, too buggy to be supported. The latter requirement is somewhere in the text about the main section. As we have a lot of very old, unused and unneeded packages, the QA team started an effort to find these. We filed over 100 bugs like the one you received in the last week and over 20 of them were directly answered by a "Oh, right, I wanted to remove the package anyway" from the maintainer. We can't decide if a package is still supported, so we try to get information from the maintainers, who should know more about their packages. To emphasize the importance of this question, the bug reports are filed as release critical bugs. If you think that the package is needed and you're willing to support it, you are free to close the bug. Marc -- BOFH #284: Electrons on a bender pgpe5DYOLrfQc.pgp Description: PGP signature
Bug#328674: very old package, should this be removed?
Jim Mintha <[EMAIL PROTECTED]> writes: > On Fri, Sep 16, 2005 at 07:05:13PM +0200, Marc 'HE' Brockschmidt wrote: >> I've done this now and your package showed up on the list. I propose >> to remove it. >> There are not many users, upstream development seems to be stalled >> and the package is FTBFS at the moment. > I agree that the package doesn't get used very much, and I was > considering removing it myself. On the other hand I do hear from > users (in fact I got an email the same day from a user that was very > happy the package was in debian) > > I think, given that it is a fairly small package, that it would be > useful to have it in debian. I will (unless there is an objection) do > an upload to updates the standards, etc. OK, thanks for the info. Just fix the FTBFS bug in the next upload and close this bug. Marc -- BOFH #355: Boredom in the Kernel. pgpgHIZqg3w0a.pgp Description: PGP signature
Bug#329966: RFH: lib{glib, gtk2, gnome2}*-perl -- Perl interfaces to the Gtk and Gnome libraries
Package: wnpp Severity: normal Hi, I'd like to continue maintaining the Gtk2-Perl packages (including the Gnome bindings) in a team, possibly in an alioth project. I haven't been able to invest much time into them in the last few months, so new upstream releases needed a few weeks and the last two FTBFS bugs (for libgtk2-perl and libgstreamer-perl) haven't received any attention from me, which is a good sign that I need help for the packages. I also haven't had the time to create new projects based on these nice libraries, so I'm increasingly out of date with regard to changes in the APIs. Though I don't have that much free time, I would definitely have the time to sponsor a non-DD who wants to help to maintain the packages. I'll spare you the usual description blob, as long as you're using something newer than woody, apt-cache show for libgnome2-gconf-perl, libgnome2-vfs-perl, libgtk2-perl, libgtk2-traymanager-perl, libglib-perl, libgnome2-perl, libgnome2-wnck-perl, libgtk2-spell-perl, libgnome2-canvas-perl, libgnome2-print-perl, libgtk2-gladexml-perl and libgtk2-trayicon-perl should give you all information you need. Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329977: RFA: libcurses-ui-perl -- A curses based OO user interface framework
Package: wnpp Severity: normal Heya, In my crusade to lose packages, I request an adopter for the libcurses-ui-perl package. It's upstream development was quite stalled in the last few months, but there *could* be some activity again. It's rdepends are sysv-rc-conf and lire (in the archive) plus some private projects (whose authors have contacted me in private about some issues). The package description is far too long: A UI framework based on the curses library. Curses::UI contains several widgets which can be used to build a user interface: . - Buttonbox - Calendar - Checkbox - Container (container base element) - Label - Listbox - Menubar - PasswordEntry - Popupmenu (a.k.a. pulldown- or dropdown menu) - Progressbar - Radiobuttonbox - Texteditor (has features like word wrapping and undo) - Textentry - Textviewer - Widget (widget base element) - Window . There are also a couple of dialog windows available: . - Basic dialog window - Error dialog window - Filebrowser - Status window - Progress window - Calendar dialog window . Curses::UI can easily be configured to use a specific language. If you want a language that is not yet supported, please let me know. If you want to translate the needed strings, I'll add the language to the distribution. Currently the following languages are supported: . - English - Dutch - German - Russian - Italian - Polish -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328545: very old package with RC bugs, should this be orphaned?
"James R. Van Zandt" <[EMAIL PROTECTED]> writes: >> Your package did show up on this list and we propose to orphan >> it. There are not very many users, the last upload was two years ago >> and it's rc-buggy. > Hmm. Actually my records show I uploaded version 0.3.0-9 last August, > which was supposed to have fixed #259615: > > vanzandt:/usr/local/src/pspp$ ls -lt *upload > -rw-r--r-- 1 jrv jrv 429 Sep 24 17:56 pspp_0.4.0-1_i386.upload > -rw-r--r-- 1 jrv jrv 357 Aug 5 2004 pspp_0.3.0-9_i386.upload > -rw-rw-r-- 1 jrv jrv 357 Aug 25 2003 pspp_0.3.0-8_i386.upload > -rw-rw-r-- 1 jrv jrv 297 Mar 23 2002 pspp_0.3.0-7_i386.upload > > I don't know how that failed to make it into the archive. You should have received a reject mail about that. > I don't see an RC bug anywhere. #259615 is an RC bug which is still open in the BTS. You tried to close it with your last upload, but this changelog entry won't work: * New upstream release (fixes: Bug#259615,Bug#328545) The regex used to find out which bugs an uploads closes doesn't match here. [1] Please close the two bugs manually (by mailing [EMAIL PROTECTED]) and use "closes: #111, #222" in the future. Marc Footnotes: [1] It's /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig -- Fachbegriffe der Informatik - Einfach erklärt 166: Wiedervereinigung Verschmelzung zweier Staaten ohne Rücksicht auf die Geschichte (Ralf Muschall) pgpAT8ERSKZc1.pgp Description: PGP signature
Bug#329977: RFA: libcurses-ui-perl -- A curses based OO user interface framework
Russ Allbery <[EMAIL PROTECTED]> writes: > Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> writes: >> In my crusade to lose packages, I request an adopter for the >> libcurses-ui-perl package. > I use this one for a personal project and am willing to take it if no one > else has volunteered. OK, you can have it. Mail me if you need a sponsor. About your NM process: I have received your mails and will reply to them as soon as possible, but at the moment, my priorities are concentrated on getting rid of other work. Marc -- Fachbegriffe der Informatik - Einfach erklärt 185: LaTeX Eine spülmaschinenfeste Seitenbeschreibungssprache. (Cornell Binder) pgpOPjQkLKkTE.pgp Description: PGP signature
Bug#323220: darcs patch: Added option to use something else than debuild to build
Florian Ragwitz <[EMAIL PROTECTED]> writes:
> Tue Sep 13 06:54:47 CEST 2005 Florian Ragwitz <[EMAIL PROTECTED]>
> * Added option to use something else than debuild to build
>
>
> New patches:
>
> [Added option to use something else than debuild to build
> Florian Ragwitz <[EMAIL PROTECTED]>**20050913045447] {
It looks like I'm too stupid for this:
[EMAIL PROTECTED]:~/Projects/Debian/Packages/libnet-perl/libnet-perl$
darcs-buildpackage --dbp_builder=pdebuild
[...]
dpkg-source: building libnet-perl using existing libnet-perl_1.19.orig.tar.gz
dpkg-source: building libnet-perl in libnet-perl_1.19-3.diff.gz
dpkg-source: cannot represent change to
_darcs/patches/20050815131712-3d260-38d4fe0677b34519f8a58f1598d795dfdd52e046.gz:
binary file contents changed
dpkg-source: cannot represent change to
_darcs/patches/20050815131712-3d260-b073070f6b25c80eebe9e392b3d4ae0d4c167c26.gz:
binary file contents changed
dpkg-source: cannot represent change to
_darcs/patches/20050815131709-3d260-a4cb3d2ea375e035d6ddee36fca96dff7e83f98b.gz:
binary file contents changed
dpkg-source: cannot represent change to
_darcs/patches/20050815131709-3d260-8d44dbb3645914de64dbb95ae6e2fc963cc50ad1.gz:
binary file contents changed
dpkg-source: cannot represent change to
_darcs/patches/20050815131706-3d260-7cd487ec18619ca8f6525db955a92458e71fa13c.gz:
binary file contents changed
dpkg-source: cannot represent change to
_darcs/patches/20050815131706-3d260-ca67a022767c446941c210467f85c7a3a886e7ed.gz:
binary file contents changed
dpkg-source: cannot represent change to
_darcs/patches/20050815131704-3d260-7e6291f864fcbef12177cf705c887f9bfe6fcee8.gz:
binary file contents changed
dpkg-source: cannot represent change to
_darcs/patches/20050815131703-3d260-dfeaa9c88817a218a991c097d96e2042cf64425c.gz:
binary file contents changed
dpkg-source: warning: file
_darcs/inventories/20050815131712-3d260-38d4fe0677b34519f8a58f1598d795dfdd52e046.gz
has no final newline (either original or modified version)
dpkg-source: warning: file _darcs/inventory has no final newline (either
original or modified version)
dpkg-source: building libnet-perl in libnet-perl_1.19-3.dsc
dpkg-source: unrepresentable changes to source
Command pdebuild ["-i_darcs","-I_darcs"] failed; exit code 1
darcs-buildpackage: user error (Command pdebuild ["-i_darcs","-I_darcs"]
failed; exit code 1)
Marc
--
BOFH #26:
first Saturday after first full moon in Winter
pgplAbOZ1Q6Fd.pgp
Description: PGP signature
Bug#326590: www.debian.org: Simple spelling mistake on debian.org/devel/join/nm-step4
Nigel Jones <[EMAIL PROTECTED]> writes: > Simple mistake, http://www.debian.org/devel/join/nm-step4 > > Part B "Skills" sub section A "Package Management" reads: > If the applicant intends to maintain packages for Debian, some > demonstration of those skills will be required. The first choice is to > have the applicant take over on of the "orphaned" packages, but any > other useful package would qualify as well. > > It should read: > > If the applicant intends to maintain packages for Debian, some > demonstration of those skills will be required. The first choice is to > have the applicant take over *one* of the "orphaned" packages, but any > other useful package would qualify as well. > > Simple mistake, anyone can make it... This will be fixed with the rewrite of the New Maintainer documentation that I currently prepare. If you're interested, look at the wml files in people.debian.org/~he/. Marc -- BOFH #244: Your cat tried to eat the mouse. pgpF7h6dNH6Eb.pgp Description: PGP signature
Bug#326633: Section 6.3 should reference 3.10.1
Package: debian-policy Version: 3.6.2.1 Severity: normal [this is an edited resent of my previous mail, no new information was harm^Wused in the production] Lars Wirzenius <[EMAIL PROTECTED]> writes: > * Some packages still don't use debconf for prompting, and > instead do silly stuff that assumed it is OK to read and > write /dev/tty. Actually, the policy explicitly allows this: | The maintainer scripts are guaranteed to run with a controlling terminal | and can interact with the user. If they need to prompt for passwords, do | full-screen interaction or something similar you should do these things | to and from /dev/tty, [...] [Debian Policy 3.6.2.1, section 6.3] This should probably changed a bit to reference 3.10.1, which says that all means to prompt the user besides debconf are deprecated. Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322773: Links against libstc++.so.6 and old qt
Package: djview Severity: serious Hi, I just looked through the whole mess with djvulibre and noticed that it was only built on two official archs (i386, uploaded by the maintainer, and sparc). m68k fails due to a toolchain bug, hppa due to the broken fakeroot on the buildds and the other fail because they can't link in Xinerama - I have no idea why this was successful on the sparc buildd. Anyway, the sparc binaries are broken, as announced in the build log: /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/lib/libqt-mt.so, may conflict with libstdc++.so.6 This means that the current version of djview is broken on sparc (and probably on i386, iff the maintainer used an up-to-date system to build). You'll need to wait at least another day until QT has finished it's own transition to the new C++ ABI. http://lists.debian.org/debian-devel-announce/2005/07/msg1.html contains what you need to know for now, please *read* debian-devel-announce in the future. This bug shouldn't have happened. Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322773: Links against libstc++.so.6 and old qt
severity 322773 important thanks Steve Langasek <[EMAIL PROTECTED]> writes: > On Fri, Aug 12, 2005 at 09:49:50PM +0200, Marc 'HE' Brockschmidt wrote: >> Anyway, the sparc binaries are broken, as announced in the build log: >> /usr/bin/ld: warning: libstdc++.so.5, needed by /usr/lib/libqt-mt.so, may >> conflict with libstdc++.so.6 >> This means that the current version of djview is broken on sparc (and >> probably on i386, iff the maintainer used an up-to-date system to >> build). > In spite of this rather specific ld warning, *if* ld succeeds in linking an > application against two versions of libstdc++, this is much less likely to > cause breakage than linking in two versions of almost any other > library, because libstdc++ uses fully versioned symbols. Errr, yes. Thanks for the hint, somehow my C++-breakage radar is a bit too sensitive at the moment. Downgrading to important. Marc -- Fachbegriffe der Informatik - Einfach erklärt 237: Login Test bei Admin und Programmierer, ob sie schreiben kann. (Manfred Worm Schäfer) pgplZgey6mBtl.pgp Description: PGP signature
Bug#322859: FTBFS: Cannot find apr.h
tags 322859 fixed-upstream thanks Matt Kraai <[EMAIL PROTECTED]> writes: > Package: libembperl-perl > Version: 2.0rc3-1 > Severity: serious > > libembperl-perl fails to build because it cannot find apr.h: [...] This problem is caused by a radical API change in libapach2-mod-perl2 1.999_22. Upstream has already reacted, so packaging the new 2.0rc5 version should fix this FTBFS. Marc -- BOFH #276: U.S. Postal Service pgpxHHuKSSqZ2.pgp Description: PGP signature
Bug#323220: Add (configuration) option to use something else than debuild to build
Package: darcs-buildpackage Version: 0.5.1 Severity: wishlist Hi, It would be nice if you could provide an command line option (or something specified in the config file, or both) to allow to use pdebuild, for example. I'm used to build all packages in a pbuilder (because I don't want to keep all weird build-dependencies of my packages on my workstation), so using dbp directly for that would be very nice. TIA, Marc [If you'd use something like perl, i'd be able to provide a patch :-)] -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (542, 'unstable'), (101, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.1ibook+he1 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323620: examples broken, should REALLY be fixed
Package: dbconfig-common Version: 1.8.3 Severity: important Hi, First: It's a nice thing that you provided a common infrastructure for db-based applications. It eases the life of translators, sponsors, mentors and users. Common interfaces are good. But, please, PLEASE provide working examples. This has a really bad bug: | #!/bin/sh | | set -e | #set -x | | . /usr/share/debconf/confmodule | . /usr/share/dbconfig-common/dpkg/preinst.mysql | dbc_go db-test-mysql-perl $@ | | #DEBHELPER# [/usr/share/doc/dbconfig-common/examples/db-example-2.1/debian/db-test-mysql-perl.preinst] Using "set -e": Good. Using #DEBHELPER#: Good. Forgetting to pre-depends on dbconfig-common: Priceless. Please fix this. TIA, Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314519: Permission problems in the i386 chroot?
Hi, #314519 notified me of the fact that libgtk2-perl, which I only uploaded for powerpc, was unstripped on i386. As this problem doesn't exist on other archs (and the same happened with the next release, 1.083-1), I think that the problem is on the buildd system. The build log shows this: dh_strip -a strip: unable to copy file 'debian/libgtk2-perl/usr/lib/perl5/auto/Gtk2/Gtk2.so' reason: Permission denied I asked Martin Zobel-Helas to do a test-build of the package on i386. He couldn't reproduce the problem on his system (build log attached). It would be nice if you could check if the problem is really on the buildd side. Marc -- Fachbegriffe der Informatik - Einfach erklärt 282: Perl Der geglückte Versuch, einen braindump direkt ausführbar zu machen. (gefunden von Alexander Schreiber) libgtk2-perl_1.083-1_i386.log.bz2 Description: Binary data pgp6BQrh37MY2.pgp Description: PGP signature
Bug#320363: Tagging/Merging
tag 320363 + upstream thanks Compatibility with Apache2 is sommething that upstream should fix, so I'm tagging the bug. Anyway, you might want to consider to fix this bug by conflicting with Apache2, if there's really no easy way to solve the problems with the new mod_perl. Marc -- Fachbegriffe der Informatik - Einfach erklärt 234: Integrationstest Einladung sich zum Gedankenaustausch über Systemarchitektur zu treffen. (Manfred Worm Schäfer) pgpOBBkG7gfiE.pgp Description: PGP signature
Bug#310417: libnet-perl: Net/Cmd.pm(354) uninitialized value -> Net/NNTP.pm(673) Argument "" isn't numeric.
tags 310417 upstream forwarded 310417 [EMAIL PROTECTED] thanks, Debian BTS Hi, This report was reported against libnet-perl 1.19 in the Debian BTS: Mike Mestnik <[EMAIL PROTECTED]> writes: > I was running ubh, it was d-loading msgs when... > > Use of uninitialized value in substr at /usr/share/perl5/Net/Cmd.pm line 354. > Argument "" isn't numeric in numeric eq (==) at /usr/share/perl5/Net/NNTP.pm > line 673. The Net::NNTP call is a simple quit cmd. It tries to get the respone with Net::Cmd::respone(), which somehow has no return value. This could happen if the server sends back unparseable crap. I'm not sure how to fix this without breaking existing scripts, so I would be thankful if you could look into this. Marc -- BOFH #267: The UPS is on strike. pgpLyxbaTVDl3.pgp Description: PGP signature
Bug#321744: RFA: libgimp-perl -- Perl support and plugins for The GIMP
Package: wnpp Severity: normal Hi, I have to admit that I'm not using libgimp-perl for my own work, so my interest in maintaining it has a bit ceased. Anyway, the packaging is more or less in a good state, but I didn't have time to fix some upstream bugs (or at least cleanly forward them to upstream). Please also note that the last upstream release was when Gimp 2.0 came out. So, here's the description: Description: Perl support and plugins for The GIMP The Gimp module includes the Perl modules necessary to write Perl-based plugins for The GIMP. It includes several plugins with various useful features. I will orphan in 3 months or so if nobody cares enough to take the package. No package in the archive depends on it (only a suggests from gimp), but there are some users, so I'm reluctant to ask for removal. Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401416: pending upload of digikam-0.8.2
"Mark Purcell" <[EMAIL PROTECTED]> writes: > Given the discussion has died down. > > I am proposing to release digikam[imageplugins] 0.8.2 to unstable in the > next couple of days to overcome the lack of an libexiv2 transition. From what I can see, this is fine. bugs.d.o doesn't report anything unusual, but I would love to know if #393505 and #396249 are fixed in 2:0.8.2-2. Marc -- Fachbegriffe der Informatik - Einfach erklärt 137: Cisco Microsoft im Routermarkt (Simone Demmel) pgpQumAxn4h3z.pgp Description: PGP signature
Bug#402179: [Bug-tar] Race condition in GNU tar test-suite
Bdale Garbee <[EMAIL PROTECTED]> writes: > On Tue, 2006-12-19 at 15:46 +, Alex Owen wrote: >> This patch should fix the problem. I guess the opotions are to aply >> this patch to 1.16 or package 1.16.1. I guess applying the patch is >> the better option if we wnat to fix this for etch. > It's not clear to me that we need to disturb etch to fix this. It's > "just" a race in a regression test, and I *think* 1.16 is built for all > the architectures that matter for etch release, isn't it? If not, I'm > certainly willing to apply the patch and upload this. > > Packaging 1.16.1 for unstable clearly makes sense, and I'll try to do > that tonight or tomorrow. I've looked at the diff between tar 1.16 and 1.16.1, I'm not really happy to approve this to etch. I would prefer to get a fixed version of tar (with the patch from tar 1.16.1 or the one from the bug report) into etch through tpu. If you don't have the time to do that, there is probably some eager NMUer willing to do it :-) Marc -- Fachbegriffe der Informatik - Einfach erklärt 18: Vorbereitet für den Multimediaeinsatz Es sind noch zwei Slots auf dem Motherboard frei. (Peter Berlich) pgpAQsB6uI7k9.pgp Description: PGP signature
Bug#404143: Fans unreliable under load, permanent memory leak
severity 404143 serious thanks maximilian attems <[EMAIL PROTECTED]> writes: > severity 404143 important > tags 404143 upstream > stop [...] > big nack, > acpi has a huge potential destabilisation. > at this time of the game adding acpi patches is pron to regression > at unexpected corners. > > etch will get in a point release a newer kernel, > those laptops will have to get one on backports soon after release. Sorry, I don't accept this. We are talking about an *overheating* problem, which means *broken* hardware. There needs to be at least a fix documented in the release-notes. Marc -- BOFH #357: I'd love to help you -- it's just that the Boss won't let me near the computer. pgpuNNfE74wKM.pgp Description: PGP signature
Bug#404143: Fans unreliable under load, permanent memory leak
[EMAIL PROTECTED] writes: > I'm more than willing to help test a kernel package, but I'll be on > [VAC] from 2006-12-23 to 2007-01-03 inclusive. So, please do not > release Etch just now :) I have ordered an nx6325, which should arrive directly after Christmas. I would also be happy to test a fixed kernel. Due to this being an overheating problem, I would prefer if you could provide kernel images, so that I don't have to compile it. Marc -- BOFH #34: (l)user error pgppTCQdnLOR0.pgp Description: PGP signature
Bug#404143: Fans unreliable under load, permanent memory leak
Bastian Blank <[EMAIL PROTECTED]> writes: > On Fri, Dec 22, 2006 at 10:30:57AM +0100, Marc 'HE' Brockschmidt wrote: >> Sorry, I don't accept this. We are talking about an *overheating* >> problem, which means *broken* hardware. There needs to be at least a fix >> documented in the release-notes. > Garbage-in, garbage-out. The BIOS of that machines is broken. Do you > really expect that an interpreter (in this case the ACPI interpreter) > accepts any garbage? Other OSes don't destroy the hardware. There is a patch for Linux not to - I don't see why Debian should release with a kernel that destroys hardware, without even giving users a warning. Not everyone who buys a notebook is aware of ACPI problems, and we shouldn't expect all users to do so. Fix it or document it, I don't care. But the current state is not releasable. Marc -- BOFH #241: _Rosin_ core solder? But... pgpWLOe1V4FBy.pgp Description: PGP signature
Bug#404143: Fans unreliable under load, permanent memory leak
severity 404143 critical thanks maximilian attems <[EMAIL PROTECTED]> writes: > On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: >> Fix it or document it, I don't care. But the current state is not >> releasable. > we are not talking about "a" patch. > what you need is an backport of the 2.6.19 acpi release to 2.6.18. Read again what I wrote. I will not allow Debian to release with a Kernel that may damage hardware without even a notice in the release notes. If you are not able to fix it, note that you have provided a broken kernel. Marc -- Fachbegriffe der Informatik - Einfach erklärt 205: BSD Berkeley Spongiform Derivative (Felix Deutsch) pgpNazNAryceU.pgp Description: PGP signature
Bug#404195: RM: libnet-perl -- RoM; included in perl-modules
Package: ftp.debian.org Heya, libnet-perl is nowadays completly included in the perl package. I have merged the last few remaining patches recently, so there is no reason to keep the package. It was already removed from testing, which works out just fine, as perl-modules has a Provides: libnet-perl. Marc -- Fachbegriffe der Informatik - Einfach erklärt 159: Hochleistungswebspace Das sind public-html-Verzeichnisse, die jeden Morgen zwanzig Liegestütze machen, und mit Testosteron vollgepumpt sind. (Markus Schaber)
Bug#404143: Fans unreliable under load, permanent memory leak
Sven Luther <[EMAIL PROTECTED]> writes: > On Fri, Dec 22, 2006 at 12:53:09PM +0100, Marc 'HE' Brockschmidt wrote: >> maximilian attems <[EMAIL PROTECTED]> writes: >>> On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: >>>> Fix it or document it, I don't care. But the current state is not >>>> releasable. >>> we are not talking about "a" patch. >>> what you need is an backport of the 2.6.19 acpi release to 2.6.18. >> Read again what I wrote. I will not allow Debian to release with a >> Kernel that may damage hardware without even a notice in the release >> notes. If you are not able to fix it, note that you have provided a >> broken kernel. > Cool, let's delay etch a couple of weeks and move to a (now released) 2.6.19 > kernel, to solve this issue. Let's try again: Fix it *OR* explain in the release notes that the kernel in etch is broken for some hardware. Marc -- Fachbegriffe der Informatik - Einfach erklärt 79: Usenet Ich habe zuviel Freizeit. (Florian Kuehnert) pgpwpNLk8yIZi.pgp Description: PGP signature
Bug#404888: glib destabilization and ways forward
Josselin Mouette <[EMAIL PROTECTED]> writes:
> Le vendredi 29 décembre 2006 à 10:48 -0800, Thomas Bushnell BSG a écrit :
>> 1) Decide that glib should not migrate into testing (it is a freeze,
>> after all); if there are particular fixes of RC issues in more recent
>> versions, then those fixes should be added, but otherwise the wholesale
>> importation of many changes should not be permitted.
> That leaves us with the silent data loss that can happen when using
> broken key names (like, well, gnucash does). Whether this is or not a RC
> issue, I'll let the release team decide.
It is no regression over the prior situation and was never reported in
the BTS, even though GKeyFile was "broken" (ie too liberal when taking
input from application) in this way for some time.
>> 3) Decide that glib can migrate into testing with the destabilizing
>> change intact, migrate an upstream gnucash fix into testing at the same
>> time.
> This is the sanest solution because this is the one that gets us with
> the lesser number of bugs.
We don't know which other applications may rely on gkeyfile without
input checking. I don't want to find out at this point of the release
cycle, so this is not an option.
>> 2) Decide that glib can migrate into testing, with the particular change
>> of checking key values reverted to its pre-2.12.5 behavior, since this
>> is a destabilizing change in the Debian context.
> Same answer. At least we can get the other bug fixes.
I would prefer to leave the new input validation routines in place, but
replace all current "return FAIL" in the new g_key_file_is_group_name
and g_key_file_is_key_name function with g_warning("'%s' is not a valid
GKeyFile key/group name", bla) and only do a return FAIL if the old
condition (string is empty) was met. Of course, reverting to the old
version would also be an option.
Marc
--
BOFH #121:
halon system went off and killed the operators.
pgpylq1GVkRP4.pgp
Description: PGP signature
Bug#407779: Memory leak in Evince (or a library)
Luis Matos <[EMAIL PROTECTED]> writes: > which version of evince is going to be shipped with etch??? i think this > is RC for Evince. This is in no way RC for evince. It wasn't reported for any other .pdf, so I guess this only hits very few users. It is a crash, yes, but it does not make evince unuseable. We will ship a version of evince 0.4 with etch, as newer versions are part of Gnome 2.16, which is also not part of etch. You may write to debian-release@lists.debian.org if you still believe that this is an RC issue, but I don't think so. Marc -- BOFH #79: Look, buddy: Windows 3.1 IS A General Protection Fault. pgpSDSToMBYi3.pgp Description: PGP signature
Bug#407779: Memory leak in Evince (or a library)
Luis Matos <[EMAIL PROTECTED]> writes: > Dom, 2007-01-21 às 21:24 +0100, Marc 'HE' Brockschmidt escreveu: >> Luis Matos <[EMAIL PROTECTED]> writes: >> > which version of evince is going to be shipped with etch??? i think this >> > is RC for Evince. >> This is in no way RC for evince. It wasn't >> reported for any other .pdf, so I guess this only hits very few >> users. It is a crash, yes, but it does not make evince unuseable. We >> will ship a version of evince 0.4 with etch, as newer versions are >> part of Gnome 2.16, which is also not part of etch. > well ... evince is quite unstable in my system and it seems that this is > not only one pdf. For example i often experience some breakage on exit > (ok, missed the bug report) and have to kill evince's pid. Well, "quite unstable" is not something I can fix. If you are more specific, there are maybe single issues that could be fixed. > Maybe this bug has an acceptable patch to it. This causes bad usability. No, there is no patch. I haven't even verified yet that it is fixed in the newer upstream versions, but even if it is, there is no specific changelog entry for this. Also, this is probably a bug in libpoppler, which does the .pdf rendering, and not in evince. Marc -- BOFH #108: The air conditioning water supply pipe ruptured over the machine room pgpxHgcRy9IVk.pgp Description: PGP signature
Bug#403134: apache2: does not work with CGI, PHP, Perl, mySQL, etc.
severity 403134 important tag 403134 unreproducible thanks Bernd Warken <[EMAIL PROTECTED]> writes: > I tested apache2 and the 3 apache1 versions on both KNOPPIX-5.02-CD and > my working machine with Debian testing. None worked with CGI, PHP, > Perl, mySQL, phpmyadmin, and many other things. This was not reported by other people and I, for once, have a working installation (without hand-holding, simply apt-getting it). Until you are able to give us some way to reproduce these problems, I assume it's a local problem on your side. Please file bugs in the future with some more basic information (used versions, used configuration files, at least). Marc -- BOFH #99: SIMM crosstalk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392951: Reason for these bugs
Heya, All these three packages (toolchain-source, llvm, mingw32) contain copies of the gcc sources in recent versions, so they include GFDLed material, just like gcc. Similiar patches should probably be applied. Marc -- BOFH #37: heavy gravity fluctuation, move computer to floor rapidly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397470: Versioned depends on soon obsolete libnet-perl package
Package: libnet-ph-perl Severity: important Tags: patch Heya, I'm the maintainer of libnet-perl and would like to kill it off, if possible before etch is released. To do that, I need to get the last two versioned deps on it to go away, libnet-ph-perl is one of them. Please replace libnet-perl (>= 1:1.09) by libnet-perl (>= 1:1.09) | perl-modules (>= 5.8.0). perl 5.8.0 contained libnet-perl 1.12, so everything should work out there. Please note that I would really like to do it and may do an NMU to upload this small change. I would also watch over the testing transition and everything, so you wouldn't have to do anything. As far as I can see, I'm still a member of the Perl Group, so I could just do a MU, but if anybody feels to be responsible for this package, (s)he can just integrate. I'm also willing to sponsor this for non-DDs :) Thanks, Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397503: Versioned depends on soon obsolete libnet-perl package
Package: amavisd-new Severity: important Tags: patch Heya, I'm the maintainer of libnet-perl and would like to kill it off, if possible before etch is released. To do that, I need to get the last two versioned deps on it to go away, amavisd-new is one of them. Please replace libnet-perl (>= 1:1.16) by libnet-perl (>= 1.16) | perl-modules (>= 5.8.1). perl 5.8.1 contained libnet-perl 1.17, so everything should work out there. Please note that I would really like to do it and may do an NMU to upload this small change. I would also watch over the testing transition and everything, so you wouldn't have to do anything. Just tell me how you would like to proceed :) Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398331: Integrate libnet-perl in perl-modules
Package: perl-modules
Tags: patch
Heya,
Here is the patch we talked about in IRC. This includes all patches
applied on libnet-perl that were not yet in perl-modules, a control file
conflict with the last libnet-perl version and a new
/etc/perl/libnet.cfg config file which uses /etc/libnet.cfg if it
exists and is used for configuration in the other cases.
Marc
--
Fachbegriffe der Informatik - Einfach erklärt
251: Hochglanz-Verkaufsprospekt
Das Produkt befindet sich gerade in der allerersten
Konzeptionsphase. (Patrick Piecha)
diff -u perl-5.8.8/lib/Net/Config.pm perl-5.8.8/lib/Net/Config.pm
--- perl-5.8.8/lib/Net/Config.pm
+++ perl-5.8.8/lib/Net/Config.pm
@@ -57,7 +57,7 @@
}
TRY_INTERNET_CONFIG
-my $file = '/etc/perl/Net/libnet.cfg';
+my $file = '/etc/perl/libnet.cfg';
my $ref;
if ( -f $file ) {
$ref = eval { local $SIG{__DIE__}; do $file };
@@ -130,8 +130,8 @@
C holds configuration data for the modules in the libnet
distribuion. During installation you will be asked for these values.
-The configuration data is held globally in a file in the perl installation
-tree, but a user may override any of these values by providing their own. This
+The configuration data is held globally in /etc/perl/libnet.cfg,
+but a user may override any of these values by providing their own. This
can be done by having a C<.libnetrc> file in their home directory. This file
should return a reference to a HASH containing the keys described below.
For example
@@ -156,7 +156,7 @@
Attempts to determine if a given host is outside your firewall. Possible
return values are.
- -1 Cannot lookup hostname
+ \-1 Cannot lookup hostname
0 Host is inside firewall (or there is no ftp_firewall entry)
1 Host is outside the firewall
diff -u perl-5.8.8/patches-applied perl-5.8.8/patches-applied
--- perl-5.8.8/patches-applied
+++ perl-5.8.8/patches-applied
@@ -10,6 +10,10 @@
debian/patches/09_fix_installperl
debian/patches/10_fix_installsitescript
debian/patches/11_fix_processPL
+debian/patches/12_fix_net_cmd
+debian/patches/13_fix_net_pop3
+debian/patches/14_fix_net_groff_minus-hyphen
+debian/patches/15_fix_net_smtp_docs
debian/patches/50_debian_use_gdbm
debian/patches/51_debian_ld_run_path
debian/patches/52_debian_extutils_hacks
diff -u perl-5.8.8/debian/patches/60_debian_libnet_config_path perl-5.8.8/debian/patches/60_debian_libnet_config_path
--- perl-5.8.8/debian/patches/60_debian_libnet_config_path
+++ perl-5.8.8/debian/patches/60_debian_libnet_config_path
@@ -1,4 +1,4 @@
-Set location of libnet.cfg to /etc/perl/Net as /usr may not be writable.
+Set location of libnet.cfg to /etc/perl/libnet.cfg as /usr may not be writable.
diff -Naur --exclude=debian perl-5.8.8.orig/lib/Net/Config.pm perl-5.8.8/lib/Net/Config.pm
--- perl-5.8.8.orig/lib/Net/Config.pm 2002-03-01 01:04:31.0 +1100
@@ -11,6 +11,17 @@
-+my $file = '/etc/perl/Net/libnet.cfg';
++my $file = '/etc/perl/libnet.cfg';
my $ref;
-$file =~ s/Config.pm/libnet.cfg/;
if ( -f $file ) {
$ref = eval { local $SIG{__DIE__}; do $file };
if (ref($ref) eq 'HASH') {
+@@ -131,8 +130,8 @@
+ C holds configuration data for the modules in the libnet
+ distribuion. During installation you will be asked for these values.
+
+-The configuration data is held globally in a file in the perl installation
+-tree, but a user may override any of these values by providing their own. This
++The configuration data is held globally in /etc/perl/libnet.cfg,
++but a user may override any of these values by providing their own. This
+ can be done by having a C<.libnetrc> file in their home directory. This file
+ should return a reference to a HASH containing the keys described below.
+ For example
diff -u perl-5.8.8/debian/changelog perl-5.8.8/debian/changelog
--- perl-5.8.8/debian/changelog
+++ perl-5.8.8/debian/changelog
@@ -1,3 +1,15 @@
+perl (5.8.8-6.2) unstable; urgency=low
+
+ * Completly replace libnet-perl:
+ + Integrate some patches for the Net:: modules
+ + debian/control: Update to replace the last libnet-perl version.
+ + Update configuration mechanism so that /etc/perl/libnet.cfg
+ sources in /etc/libnet.cfg if it exists, otherwise the
+ configuration is stored there. This saves us trouble from
+ converting debconf-managed /etc/libnet.cfg to a dpkg conffile
+
+ -- Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> Tue, 7 Nov 2006 17:30:54 +0100
+
perl (5.8.8-6.1) unstable; urgency=high
* Non-maintainer upload to fix Failure To Build From Source in hppa, mips
diff -u perl-5.8.8/debian/control perl-5.8.8/debian/control
--- perl-5.8.8/debian/control
+++ perl-5.8.8/debian/control
@@ -50,7 +50,7 @@
Priority: standard
Architecture: all
Depends: perl (>= ${Upstream-Version}-1)
-Conflicts: libpod-parser-perl (<< 1.32-1), libansicolor-perl (<< 1.10-1), libfile-temp-perl (<< 0.16-1), libnet-perl (<< 1:1.17-1)
Bug#401192: bin-NMU for dsniff
Heya, Please bin-NMU dsniff: dsniff_2.4b1+debian-15, rebuild for libnids1.21 (#401192), 1, alpha, amd64, arm, hppa, i386, ia64, m68k, mipsel, mips, powerpc, s390, sparc This should fix the bug. Marc -- BOFH #291: Due to the CDA, we no longer have a root account. pgpNheT32d9aE.pgp Description: PGP signature
Bug#402566: localization-config: not ready for Etch
Frans Pop <[EMAIL PROTECTED]> writes: > Package: localization-config > Severity: serious [...] > Release Managers: please hint l-c for removal from Etch. Done. BTW, X-Debbugs-CC would have been nice to save the time of searching for the bug number. Marc -- BOFH #73: Daemons did it pgpoQkpbRQBhW.pgp Description: PGP signature
Bug#331246: Please mark #331246 as etch-ignore
Lior Kaplan <[EMAIL PROTECTED]> writes: > The library was renamed again from Sarge to Etch, the the > provides/conflicts are fine in the control file. So that version fixes the bug, right? And what do you do when a new version fixes a bug? Marc -- BOFH #57: Groundskeepers stole the root password pgpyIzrh3gzSI.pgp Description: PGP signature
Bug#159461: closed by Martin Michlmayr <[EMAIL PROTECTED]> (Old bugs)
Josip Rodin <[EMAIL PROTECTED]> writes: > The pdl dependency was added to libgimp-perl in 2004 and the changelog > referred to bug #255923, where the bug submitter noticed libgtk2-perl to be > missing. Marc 'HE' Brockschmidt did this upload; Marc, why did you add pdl > as well as libgtk2-perl? Well, pdl adds to the functionality of libgimp-perl, and at that point of time a large number of the scripts provided with the package needed pdl to actually work. Don't know how the current state is, though. Please also note that my memory is surprisingly bad for my age, so everything I say may be wrong. Marc -- Fachbegriffe der Informatik - Einfach erklärt 217: geräteunabhängig Sieht nirgends gut aus. Ist nicht Herstellers Schuld. (Dietz Proepper) pgpAFjtHqNAw0.pgp Description: PGP signature
Bug#317461: 317461: Bug still exists?
Heya, This bug was never closed, is it still valid? I couldn't reproduce it, but this may be a local thing... Marc -- Fachbegriffe der Informatik - Einfach erklärt 82: Demokratie Statt eines Hofnarren für den König gibt es ein paar hundert für das Volk. (Stefan Hager)
Bug#404555: May I upload dfsbuild to testing-proposed-updates?
John Goerzen <[EMAIL PROTECTED]> writes: > I have prepared an update to dfsbuild that fixes 2 RC bugs: #404563 and > #404555. If your final patches look like the two patches in the BTS for these bugs, that should be fine. Please mail us again after you've uploaded the package. Marc -- Fachbegriffe der Informatik - Einfach erklärt 197: Human Resources Menschenmaterial (Konstantin Welke) pgp69ryUws44N.pgp Description: PGP signature
Bug#405908: This is a bug in libpoppler
reassign 405908 libpoppler1/0.4.5-5 forwarded 405908 https://bugs.freedesktop.org/show_bug.cgi?id=9627 tags 405908 + upstream thanks Heya, The bug you've reported is actually a problem in the rendering library evince uses, libpoppler. I have reassigned the bug accordingly and informed the upstream developers of poppler about this problem. Marc -- BOFH #135: You put the disk in upside down. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396467: evince: dvi reload crash not yet fixed
forwarded 396467 http://bugzilla.gnome.org/show_bug.cgi?id=380440 thanks Heya, This bug was reported to still exist 0.6.1 in Ubuntu, and the user reported also a full backtrace to the upstream bugzilla, so we can hope the bug gets fixed in one of the next versions. Marc -- BOFH #260: We're upgrading /dev/null -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366550: Tiff support in evince?
Heya,
I have tried unstable's evince to view a TIFF document and had no
problems - can you still reproduce the problem with evince in unstable?
Could you provide the problematic tiff file if the problem still exists
for you?
Marc
--
Fachbegriffe der Informatik - Einfach erklärt
22: Interaktives Fernsehen
Fernsteuerung mit Taste 'Bezahlen' statt 'Aus'. ('Standpay'-Taste)
(nach Peter Berlich)
Bug#405597: please don't release open-cobol version 0.32-3 with etch
Bart Martens <[EMAIL PROTECTED]> writes: > I have set the severity of bug 405597 to "grave". I suggest that you > remove open-cobol from testing and don't include open-cobol in the etch > release unless I get it fixed in time. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405597 > > Thanks to Dennis Boone <[EMAIL PROTECTED]> for reporting this problem. Removal hint added. Marc -- BOFH #233: TCP/IP UDP alarm threshold is set too low. pgpRic4vQrQoE.pgp Description: PGP signature
Bug#393665: Please consider bumping cdbs' urgency, and let it migrate to testing
Frank Küster <[EMAIL PROTECTED]> writes: > However, the upload was done with low urgency and still needs 7 days to > get into testing. I suggest to bump the urgency to high or medium - and > probably cdbs also needs to be unblocked. Added urgent/unblock hints. Marc -- BOFH #38: secretary plugged hairdryer into UPS pgpGouXHd9Z5e.pgp Description: PGP signature
Bug#294964: does not work at all
tags 294964 + confirmed upstream
forwarded 294964 Torsten Schoenfeld <[EMAIL PROTECTED]>
thank you, wonderful Debian BTS!
Hi Torsten,
I've received this bug report and could reproduce it easily. I tried to
debug this, but failed. As you naturally have no problem to understand
the code, you can probably fix this in a few minutes.
Anyway, here is the report. Please keep the reporter and the Debian BTS
in the CC when you answer.
Alex Gould <[EMAIL PROTECTED]> writes:
> When you use the program the first time, and enter a to-do item, it
> disappears. It doesn't save properly to ~/.odot as indicated in the man
> page. It produces the following output:
>
> Use of uninitialized value in string ne at /usr/bin/odot line 1963.
> *** unhandled exception in callback:
> *** Gtk-ERROR **: file gtktreestore.c: line 581
> (gtk_tree_store_get_path): assertion failed: (G_NODE
> (iter->user_data)->parent != NULL) at /usr/bin/odot line 1975.
> *** ignoring at /usr/bin/odot line 1358.
> Use of uninitialized value in concatenation (.) or string at
> /usr/bin/odot line 2758.
> Use of uninitialized value in concatenation (.) or string at
> /usr/bin/odot line 2758.
> Use of uninitialized value in string ne at /usr/bin/odot line 1963.
>
> (process:22589): Gtk-ERROR (recursed) **: file gtktreestore.c: line 581
> (gtk_tree_store_get_path): assertion failed: (G_NODE
> (iter->user_data)->parent != NULL)
> aborting...
> Aborted
>
> thanks, Alex
The only "new" thing is that i've found out that this even happens with
an existing ~/.odot file if the tasklist is empty.
Marc
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse #
pgp5wqH2D5aFU.pgp
Description: PGP signature
Bug#296029: perlpanel: loops looking for icons
tags 296029 + unreproducible moreinfo
severity 296029 important
thanks
Michal Politowski <[EMAIL PROTECTED]> writes:
> Perlpanel just installed, with default configuration, when run loops
> using the whole CPU.
> I don't really know Perl but from a quick session with the perl debugger
> it looks like
> my $info = $self->{icon_theme}->lookup_icon(lc($icon), 48, 'force-svg');
> in PerlPanel::lookup_icon always fails to return anything useful
> and the program descends into infinite recursion looking for
> a 'perlpanel-applet-missing' icon.
I could not reproduce this in a clean chroot. As other new users haven't
experienced this problem, i'm downgrading the severity to important (for
now).
I see where this could end up in a loop, but perlpanel should find
perlpanel-applet-missing in all cases (as this in the package
itself).
I'm not sure where to start to debug this. Could you send me the output
of "find /usr/share/icons/" and your ~/.gtkrc-2.0 (if you have one)?
Marc
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse #
pgpV0yVa9ZcvX.pgp
Description: PGP signature
Bug#296029: perlpanel: loops looking for icons
Michal Politowski <[EMAIL PROTECTED]> writes:
> On Sat, 19 Feb 2005 23:44:05 +0100, Marc 'HE' Brockschmidt wrote:
>> I see where this could end up in a loop, but perlpanel should find
>> perlpanel-applet-missing in all cases (as this in the package
>> itself).
> Of course on the first iteration it tried to find perlpanel-applet-actionmenu
> which is in the package as well.
Well, there will be some sort of check to prevent loops in the next
release, but that's not the real problem here.
>> I'm not sure where to start to debug this. Could you send me the output
>> of "find /usr/share/icons/" and your ~/.gtkrc-2.0 (if you have one)?
> Certainly. Though the newly created account didn't have any .gtkrc-2.0
Hmmm, well couldn't see what i hoped for. So could you please run this
script and send me the output:
#!/usr/bin/perl -W
use strict;
use Gtk2 '-init';
my $theme = Gtk2::IconTheme->new();
$theme->set_custom_theme("gnome");
print join "\n", $theme->get_search_path, "";
exit;
Marc, themes suck.
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse # <mailto:[EMAIL PROTECTED]>
pgp9KvLK066IB.pgp
Description: PGP signature
Bug#296029: perlpanel: loops looking for icons
Michal Politowski <[EMAIL PROTECTED]> writes:
> On Sat, 19 Feb 2005 23:44:05 +0100, Marc 'HE' Brockschmidt wrote:
>> I'm not sure where to start to debug this. Could you send me the output
>> of "find /usr/share/icons/" and your ~/.gtkrc-2.0 (if you have one)?
> Certainly. Though the newly created account didn't have any .gtkrc-2.0
OK, something i just noticed: Could you run "gtk-update-icon-cache
/usr/share/icons/hicolor/" and try again?
Marc
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse # <mailto:[EMAIL PROTECTED]>
pgpMngKSRV9HQ.pgp
Description: PGP signature
Bug#291109: On RFA: dh-make-perl
Chris Sacca <[EMAIL PROTECTED]> writes:
> As a Perl programmer and a prospective NM, I would be interested in
> picking up dh-make-perl. I have some Perl coding time on my hands and
> this seems like a good thing to pick up.
>
> As I am not a DD, I would understand if you were not very into my
> adoption the package,
Uh? Please remember, i'm a frontdesk member. I *like* new maintainers :)
> but at the very least I would like your blessing on making an attempt
> to clean up some of the bugs.
No problem from my side, but another new maintainer already asked me if
he could work on the package, so you have to ask him if he wants to work
in a team. I'm CCing this mail to him. Wolfgang, what do you think?
Marc
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse #
pgpO5hCOR9BF3.pgp
Description: PGP signature
Bug#296029: perlpanel: loops looking for icons
reassign 296029 libgtk2.0-bin
severity 296029 serious
tags 296029 = confirmed upstream
thank you, wonderful Debian BTS!
Hi,
Michal Politowski <[EMAIL PROTECTED]> writes:
> On Sun, 20 Feb 2005 02:46:11 +0100, Marc 'HE' Brockschmidt wrote:
> [...]
>> OK, something i just noticed: Could you run "gtk-update-icon-cache
>> /usr/share/icons/hicolor/" and try again?
> You hit it. After this perlpanel starts up all right.
> It means it just has to update caches for all the themes it ships in
> postinst, doesn't it?
OK, I've looked at the C code, it's a bug in the icon cache code. I'm
reassigning the bug to libgtk2.0-bin now...
Let's see what happens here:
* Since Gtk 2.6.0, the IconCache exists
* New theme packages call gtk-update-icon-cache in their postinst
* A new package is installed and drops icons in /usr/share/icons/$foo
* It can't find its icons
The reason for that is the flawed logic of the IconCache code... To
prevent the use of old caches that don't reflect what's actually on the
disk, the code checks some timestamps:
cache_filename = g_build_filename (path, "icon-theme.cache", NULL);
[...]
if (g_stat (path, &path_st) < 0)
goto done;
/* Open the file and map it into memory */
fd = g_open (cache_filename, O_RDONLY|_O_BINARY, 0);
[...]
if (fstat (fd, &st) < 0 || st.st_size < 4)
goto done;
/* Verify cache is uptodate */
if (st.st_mtime < path_st.st_mtime)
{
GTK_NOTE (ICONTHEME,
g_print ("cache outdated\n"));
goto done;
}
path is something like "/usr/share/icons/hicolor/". This means that the
code checks if the mtime of $PATH/icon-theme.cache is newer than
$PATH. The mtime for a directory changes whenever something in this
directory is changed. The problem is that mtime stays the same if
something in a *subdir* is changed, which is the case here (as all icons
go to $PATH/$SIZE/$SECTION/).
Look at this little snippet to verify it:
mkdir -p foo/bar; sleep 5; touch foo/bar/baz;
perl -e 'for (qw(foo foo/bar foo/bar/baz)) { printf "\%-12s \%d\n", $_,
(stat($_))[9]}'
The fix would be to check that the icon-theme.cache file's mstamp is
higher than the mstamps of all subdirs of $PATH. My C skills are a bit
rusty, so i can't provide a patch now, but it should be pretty easy to
do.
And someone should probably forward this upstream, I don't have a
bugzilla account.
Marc
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse # <mailto:[EMAIL PROTECTED]>
pgpI7GZyOlZPq.pgp
Description: PGP signature
Bug#409978: minbar_0.1-4(experimental/hppa/swawa): notify_notification_attach_to_status_icon
Package: minbar Version: 0.1-4 Severity: serious Tags: experimental Automatic build of minbar_0.1-4 on swawa.farm.ftbfs.de by sbuild/hppa 98 Build started at 20070206-2140 ** [...] Checking correctness of source dependencies... Toolchain package versions: libc6-dev_2.3.6.ds1-10 linux-kernel-headers_2.6.18-6 gcc-4.1_4.1.1-21 g++-4.1_4.1.1-21 binutils_2.17-3 libstdc++6-4.1-dev_4.1.1-21 libstdc++6_4.1.1-21 [...] cc -g -Wall -O2 -o minbar minbar-main.o -pthread -Wl,--export-dynamic -litl /usr/lib/libgconf-2.so /usr/lib/libORBit-2.so /usr/lib/libglade-2.0.so /usr/lib/libgstreamer-0.10.so /usr/lib/libgthread-2.0.so /usr/lib/libxml2.so /usr/lib/libnotify.so /usr/lib/libgtk-x11-2.0.so -ldbus-glib-1 /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXfixes /usr/lib/libpango-1.0.so /usr/lib/libcairo.so -lX11 /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so -ldl -ldbus-1 /usr/lib/libglib-2.0.so minbar-main.o: In function `create_notification': /build/buildd/minbar-0.1/src/main.c:884: undefined reference to `notify_notification_attach_to_status_icon' collect2: ld returned 1 exit status make[2]: *** [minbar] Error 1 make[2]: Leaving directory `/build/buildd/minbar-0.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/buildd/minbar-0.1' make: *** [debian/stamp-makefile-build] Error 2 Marc -- Fachbegriffe der Informatik - Einfach erklärt 753: Nur der Inhalt zählt! Ich war zu blöd, meinen HTML-Editor richtig zu bedienen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410118: mesa_6.5.2-2(experimental/amd64/xenophanes): Installs to /usr/lib64, tries to copy from /usr/lib
Package: mesa Version: 6.5.2-2 Severity: serious Tags: experimental Heya, Here's a bug report for the mesa problem we spoke about in #debian-devel: Automatic build of mesa_6.5.2-2 on xenophanes by sbuild/amd64 98-farm Build started at 20070207-1601 [...] mklib: Making Linux shared library: libGL.so.1.5.060502 mklib: Installing libGL.so.1.5.060502 libGL.so.1 libGL.so in ../../lib64 [...] dh_install --sourcedir=debian/tmp --list-missing -s dh_install: libgl1-mesa-swx11 missing files (usr/lib/libGL.so.*), aborting make: *** [binary-arch] Error 1 Marc -- BOFH #223: The lines are all busy (busied out, that is -- why let them in to begin with?). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410119: seam_1.3-1(experimental/amd64/xenophanes): casts from pointer to int loose precision
Package: seam Version: 1.3-1 Severity: serious Tags: experimental Heya, Automatic build of seam_1.3-1 on xenophanes by sbuild/amd64 98-farm Build started at 20070207-1838 ** [...] g++ -DPACKAGE_NAME=\"SEAM\" -DPACKAGE_TARNAME=\"seam\" -DPACKAGE_VERSION=\"1.3\" "-DPACKAGE_STRING=\"SEAM 1.3\"" -DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" -DPACKAGE=\"seam\" -DVERSION=\"1.3\" -DUSE_POSIX_SELECT=1 -DUSE_WINSOCK=0 -DHAVE_ZLIB=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIGHTNING=0 -DHAVE_U_INT=1 -DHAVE_DLLS=0 -DHAVE_VIRTUALALLOC=0 -DHAVE_LOADLIBRARY=0 -DHAVE_SIGNAL=1 -DHAVE_SIG_ATOMIC_T=1 -DHAVE_CONSOLECTRL=0 -DHAVE_DLFCN_H=1 -DHAVE_LIBLTDL=1 -DDEBUGGER=0 -DPROFILE=0 -I. -I. -I.. -I.. -I -I/include -g -Wall -O2 -pipe -fPIC -fPIC -ggdb -O3 -fomit-frame-pointer -fforce-addr -finline-limit=2500 -fno-implement-inlines -fno-keep-static-consts -fno-implicit-templates -fno-implicit-inline-templates -fno-rtti -Wundef -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wredundant-decls -Winline -Woverloaded-virtual -Wsign-promo -c BaseMap.cc -fPIC -DPIC -o .libs/BaseMap.o ../store/HeaderOp.hh: In static member function 'static u_int HeaderOp::EncodeHeader(BlockLabel, u_int, u_int, u_int)': ../store/HeaderOp.hh:32: warning: left shift count >= width of type ../store/HeaderOp.hh:33: warning: left shift count >= width of type ../store/HeaderOp.hh:37: warning: left shift count >= width of type ../store/HeaderOp.hh:37: warning: left shift count >= width of type ../store/HeaderOp.hh: In static member function 'static void HeaderOp::EncodeLabel(Transient*, BlockLabel)': ../store/HeaderOp.hh:49: warning: left shift count >= width of type ../store/HeaderOp.hh: In static member function 'static void HeaderOp::EncodeMutableFlag(Block*, u_int)': ../store/HeaderOp.hh:63: warning: left shift count >= width of type ../store/HeaderOp.hh: In static member function 'static void HeaderOp::SetChildishFlag(Block*)': ../store/HeaderOp.hh:84: warning: left shift count >= width of type ../store/HeaderOp.hh: In static member function 'static void HeaderOp::ClearChildishFlag(Block*)': ../store/HeaderOp.hh:88: warning: left shift count >= width of type ../store/PointerOp.hh: In static member function 'static word_s* PointerOp::EncodeTag(Block*, u_int)': ../store/PointerOp.hh:23: error: cast from 'Block*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static u_int PointerOp::DecodeTag(word_s*)': ../store/PointerOp.hh:26: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static Block* PointerOp::RemoveTag(word_s*)': ../store/PointerOp.hh:29: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static word_s* PointerOp::EncodeBlock(Block*)': ../store/PointerOp.hh:34: error: cast from 'Block*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static Block* PointerOp::DecodeBlock(word_s*)': ../store/PointerOp.hh:41: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static Chunk* PointerOp::DecodeChunk(word_s*)': ../store/PointerOp.hh:51: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static word_s* PointerOp::EncodeTransient(Transient*)': ../store/PointerOp.hh:59: error: cast from 'Transient*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static Transient* PointerOp::DecodeTransient(word_s*)': ../store/PointerOp.hh:66: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static bool PointerOp::IsInt(word_s*)': ../store/PointerOp.hh:73: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static bool PointerOp::IsTransient(word_s*)': ../store/PointerOp.hh:76: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static s_int PointerOp::DirectDecodeInt(word_s*)': ../store/PointerOp.hh:86: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh:86: warning: left shift count >= width of type ../store/PointerOp.hh:87: warning: left shift count >= width of type ../store/PointerOp.hh:87: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh:88: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh: In static member function 'static s_int PointerOp::DecodeInt(word_s*)': ../store/PointerOp.hh:91: error: cast from 'word_s*' to 'u_int' loses precision ../store/PointerOp.hh:94: warning: left shift count >= width of type ../store/PointerOp.hh: In static member function 'static word
Bug#410117: libgksu_2.0.4-1(experimental/hppa/swawa): Package 'xcb-xlib', required by 'X11', not found
Package: libgksu Version: 2.0.4-1 Severity: serious Tags: experimental Automatic build of libgksu_2.0.4-1 on swawa.farm.ftbfs.de by sbuild/hppa 98 [...] Build-Depends: cdbs, debhelper (>= 4.1.0), libgtk2.0-dev (>= 2.4.0), libglade2-dev, libgconf2-dev, libstartup-notification0-dev, libgnome-keyring-dev, gettext, autotools-dev, gtk-doc-tools, gnome-pkg-tools (>= 0.10), libgtop2-dev [...] checking pkg-config is at least version 0.9.0... yes checking for LIBGKSU... configure: error: Package requirements (gtk+-2.0 >= 2.4.0, gconf-2.0, libstartup-notification-1.0, gnome-keyring-1, libgtop-2.0) were not met: Package xcb-xlib was not found in the pkg-config search path. Perhaps you should add the directory containing `xcb-xlib.pc' to the PKG_CONFIG_PATH environment variable Package 'xcb-xlib', required by 'X11', not found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables LIBGKSU_CFLAGS and LIBGKSU_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [config.status] Error 1 [...] This looks like a missing dep on libxcb-xlib0-dev somewhere. Marc -- BOFH #9: doppler effect -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410246: tau_2.16-1(experimental/amd64/xenophanes): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
Package: tau Version: 2.16-1 Severity: serious Tags: experimental Heya, tau failed to build, here's the relevant part from the build log: Automatic build of tau_2.16-1 on xenophanes by sbuild/amd64 98-farm Build started at 20070208-2038 ** [...] g++ -g -O2 -shared -o libTAUsh-linuxtimers-pthread.so Profiler.o TulipTimers.o UserEvent.o FunctionInfo.o RtsLayer.o RtsThread.o TauCAPI.o TauFAPI.o TauMapping.o TauHooks.o TauHandler.o TauMemory.o PthreadLayer.o TauLinuxTimers.o -lpthread /usr/bin/ld: TauLinuxTimers.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC TauLinuxTimers.o: could not read symbols: Bad value collect2: ld returned 1 exit status Marc -- BOFH #274: It was OK before you touched it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410378: tau_2.16-2(experimental/alpha/ds10): FTBFS: TauLinuxTimers.c:16: error: impossible constraint in 'asm'
Package: tau Version: 2.16-2 Severity: serious Tags: experimental Automatic build of tau_2.16-2 on ds10 by sbuild/alpha 98-farm Build started at 20070210-0022 [...] gcc -c -fPIC-g -O2 TauLinuxTimers.c TauLinuxTimers.c: In function 'getLinuxHighResolutionTscCounter': TauLinuxTimers.c:16: error: impossible constraint in 'asm' make[2]: *** [TauLinuxTimers.o] Error 1 make[2]: Leaving directory `/build/buildd/tau-2.16/src/Profile' make[1]: *** [install] Error 2 make[1]: Leaving directory `/build/buildd/tau-2.16' make: *** [stamps/build-arch] Error 2 [Full log on http://experimental.ftbfs.de/fetch.php?&pkg=tau&ver=2.16-2&arch=alpha&stamp=1171092341&file=log&as=raw] Marc -- Fachbegriffe der Informatik - Einfach erklärt 190: Cisco Protokolhure. (unbekannt) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410412: john_1.7-2(experimental/alpha/ds10): Doesn't build binary
Package: john Version: 1.7-2 Severity: serious Tags: experimental Heya, Building john failed here because the build system simply forgot to actually build something: Automatic build of john_1.7-2 on ds10 by sbuild/alpha 98-farm Build started at 20070210-0644 ** [...] dpkg-source: extracting john in john-1.7 dpkg-buildpackage: source package is john dpkg-buildpackage: source version is 1.7-2 dpkg-buildpackage: host architecture alpha dpkg-buildpackage: source version without epoch 1.7-2 /usr/bin/fakeroot debian/rules clean test -x debian/rules test "`id -u`" = 0 /usr/bin/make -f debian/rules reverse-config make[1]: Entering directory `/build/buildd/john-1.7' make[1]: Nothing to be done for `reverse-config'. make[1]: Leaving directory `/build/buildd/john-1.7' if [ "reverse-patches" = "reverse-patches" ]; then rm -f debian/stamp-patched; fi patches: debian/patches/faq.diff debian/patches/system-wide.diff Patch debian/patches/system-wide.diff is not applied. Patch debian/patches/faq.diff is not applied. if [ "reverse-patches" != "reverse-patches" ]; then touch debian/stamp-patched; fi if [ "reverse-patches" != "reverse-patches" ] ; then \ /usr/bin/make -f debian/rules update-config ; \ fi for dir in debian/patches ; do \ rm -f $dir/*.log ; \ done dh_clean rm -f run/john-* run/john cd /build/buildd/john-1.7/src && /usr/bin/make clean make[1]: Entering directory `/build/buildd/john-1.7/src' rm -f ../run/john ../run/unshadow ../run/unafs ../run/unique ../run/john.bin ../run/john.com ../run/unshadow.com ../run/unafs.com ../run/unique.com ../run/john.exe ../run/unshadow.exe ../run/unafs.exe ../run/unique.exe rm -f ../run/john.exe *.o *.bak core rm -f detect bench generic.h arch.h sparc.h tmp.s rm -f DES_bs_s.c DES_bs_n.c DES_bs_a.c cp /dev/null Makefile.dep make[1]: Leaving directory `/build/buildd/john-1.7/src' rm -f build-john-stamp debian/rules build test -x debian/rules mkdir -p "." /usr/bin/make -f debian/rules reverse-config make[1]: Entering directory `/build/buildd/john-1.7' make[1]: Nothing to be done for `reverse-config'. make[1]: Leaving directory `/build/buildd/john-1.7' if [ "debian/stamp-patched" = "reverse-patches" ]; then rm -f debian/stamp-patched; fi patches: debian/patches/faq.diff debian/patches/system-wide.diff Trying patch debian/patches/faq.diff at level 1 ... success. Trying patch debian/patches/system-wide.diff at level 1 ... success. if [ "debian/stamp-patched" != "reverse-patches" ]; then touch debian/stamp-patched; fi if [ "debian/stamp-patched" != "reverse-patches" ] ; then \ /usr/bin/make -f debian/rules update-config ; \ fi make[1]: Entering directory `/build/buildd/john-1.7' make[1]: Nothing to be done for `update-config'. make[1]: Leaving directory `/build/buildd/john-1.7' touch build-john-stamp /usr/bin/fakeroot debian/rules binary-arch test -x debian/rules test "`id -u`" = 0 dh_clean -k dh_installdirs -A mkdir -p "." dh_installdirs -pjohn dh_installdocs -pjohn ./README dh_installexamples -pjohn dh_installman -pjohn dh_installinfo -pjohn dh_installmenu -pjohn dh_installcron -pjohn dh_installinit -pjohn dh_installdebconf -pjohn dh_installemacsen -pjohn dh_installcatalogs -pjohn dh_installpam -pjohn dh_installlogrotate -pjohn dh_installlogcheck -pjohn dh_installmime -pjohn dh_installchangelogs -pjohn dh_installudev -pjohn dh_install -pjohn dh_link -pjohn install -d /build/buildd/john-1.7/debian/john//var/run install -d -m 0700 /build/buildd/john-1.7/debian/john//var/run/john install -m 755 debian/extra/cronjob /build/buildd/john-1.7/debian/john//usr/share/john install -m 644 debian/extra/cron.d-john /build/buildd/john-1.7/debian/john//etc/cron.d/john install doc/CHANGES /build/buildd/john-1.7/debian/john//usr/share/doc/john/changelog install -m 644 run/john.conf /build/buildd/john-1.7/debian/john//etc/john/john.conf ( cd /build/buildd/john-1.7/debian/john//usr/share/john && ln -s /etc/john/john.conf john.conf ) install -s run/john /build/buildd/john-1.7/debian/john//usr/sbin/john install: cannot stat `run/john': No such file or directory make: *** [binary-install/john] Error 1 Marc -- BOFH #340: Well fix that in the next (upgrade, update, patch release, service pack). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395858: libfile-homedir-perl: FTBFS: tests failed
close 395858 libfile-homedir-perl/0.56-1.1 thanks Jonas Genannt <[EMAIL PROTECTED]> writes: > the fix from Version 0.56-1 does not work in the current version (0.64). Yes. This doesn't change the fact that this bug is fixed in version 0.56-1.1. Please don't mess around with the versioning of bugs (ie, don't use reopen when "found" is what you want), it makes tracking bugs harder than it needs to be. In this case, reopening was completly unneeded, as a buggy version of 0.64 never entered the archive. Marc -- BOFH #32: techtonic stress -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410507: pike7.7_7.7.24-1(experimental/amd64/xenophanes): Depends on non-existing package libmysqlclient10-dev
Package: pike7.7 Version: 7.7.24-1 Severity: serious Tags: experimental Heya, Trying to build the version of pike7.7 shows this: Automatic build of pike7.7_7.7.24-1 on xenophanes by sbuild/amd64 98-farm Build started at 20070207-1830 ** Checking available source versions... Fetching source files... Reading Package Lists... Building Dependency Tree... Need to get 19.7MB of source archives. Get:1 http://sinclair.farm.ftbfs.de experimental/main pike7.7 7.7.24-1 (dsc) [1547B] Get:2 http://sinclair.farm.ftbfs.de experimental/main pike7.7 7.7.24-1 (tar) [19.6MB] Get:3 http://sinclair.farm.ftbfs.de experimental/main pike7.7 7.7.24-1 (diff) [25.6kB] Fetched 19.7MB in 0s (26.6MB/s) Download complete and in download only mode ** Using build dependencies supplied by package: Build-Depends: debhelper (>> 4.0.0), libgdbm-dev, libgmp3-dev, libz-dev, libjpeg-dev, libttf-dev, libmysqlclient10-dev, libreadline-dev, perl, bison, debhelper, freeglut3-dev (>= 2.2.0-6.1) [alpha hppa] | libglut3-dev, freeglut3-dev [!alpha !hppa] | libglut3-dev, xlibmesa-glu-dev | libglu-dev, xlibmesa-gl-dev | libgl-dev, libxpm-dev, gnome-devel, libgtkxmhtml-dev, libfreetype6-dev, autoconf, libiodbc2-dev, libsane-dev, postgresql-dev, librsvg2-dev, libsdl-mixer1.2-dev, libsdl1.2-dev, libperl-dev, sharutils, libpng3-dev, gtkglarea5-dev, libtiff4-dev, bc, libpcre3-dev, libbz2-dev, libnettle-dev, libsqlite3-dev, libfuse-dev, libglade0-dev, fftw3-dev, pkg-config Please either remove the libmysqlclient10-dev build-dep (and use 15 instead) or remove it from the archive. Thanks, Marc -- Fachbegriffe der Informatik - Einfach erklärt 23: Codefreeze Linux Kernel Patch v1.3, patch-1.3.94 (00/55) (Kristian Köhntopp) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410554: stlport5.1_5.1.0-1(experimental/alpha/ds10): error: size of array '__static_assert' is negative
Package: stlport5.1 Version: 5.1.0-1 Severity: serious Tags: experimental Heya, stlport5.1 failed to build on alpha: Automatic build of stlport5.1_5.1.0-1 on ds10 by sbuild/alpha 98-farm Build started at 20070211-1039 ** [...] /usr/bin/make -C build/lib -f gcc.mak depend release-shared make[1]: Entering directory `/build/buildd/stlport5.1-5.1.0/build/lib' c++ -pthread -fexceptions -fident -fPIC -O2 -g -fuse-cxa-atexit -D_REENTRANT -D_STLP_REAL_LOCALE_IMPLEMENTED -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I../../stlport -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp ../../stlport/stl/_cwchar.h:114: error: size of array '__static_assert' is negative make[1]: *** [obj/gcc/so/dll_main.o] Error 1 make[1]: Leaving directory `/build/buildd/stlport5.1-5.1.0/build/lib' make: *** [debian/stamp-makefile-build] Error 2 Marc -- BOFH #25: Decreasing electron flux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410637: xbase-clients_1:7.2.ds1-1(experimental/amd64/xenophanes): libpng12 pkg-config file needed
Package: xbase-clients Version: 1:7.2.ds1-1 Severity: serious Tags: experimental Heya, xbase-clients failed to build: Automatic build of xbase-clients_1:7.2.ds1-1 on xenophanes by sbuild/amd64 98-farm Build started at 20070212- ** [...] xclock [...] checking pkg-config is at least version 0.9.0... yes checking for XCURSORGEN... configure: error: Package requirements (x11 xcursor libpng12) were not met: No package 'libpng12' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables XCURSORGEN_CFLAGS and XCURSORGEN_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [build-stamp] Error 1 Marc -- Fachbegriffe der Informatik - Einfach erklärt 155: Religion Der Wille, etwas Unverstandenes zu glauben. (Klaus Hipp)
Bug#410686: numerix_0.22a-1(experimental/alpha/ds10): FTBFS
Package: numerix Version: 0.22a-1 Severity: serious Tags: experimental Automatic build of numerix_0.22a-1 on ds10 by sbuild/alpha 98-farm Build started at 20070212-0429 ** [...] Configure summary - machine word size 64 bits processor alpha use alloca yes use longlongno shared librariesno languages selected C Ocaml modules selectedClong Slong Gmp Big(ocaml) bin directory /usr/bin lib directory /usr/lib include directory /usr/include [...] ocamlmklib -I kernel/ocaml/o -o numerix -oc numerix-ocaml kernel/ocaml/o/numerix.cmo kernel/ocaml/o/numerix.cmx kernel/ocaml/o/chrono.o kernel/ocaml/o/hash.o kernel/ocaml/o/numerix-c.o kernel/ocaml/o/numerix-s.o kernel/ocaml/o/numerix-g.o kernel/n/o/numerix-c.o kernel/n/o/numerix-s.o kernel/n/o/numerix-t.o -lgmp /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_addloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_subloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_addsubloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_mulloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_mulloop2 /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_muladdloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_mulsubloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_muladdloop2 /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_mulsubloop2 /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_incloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_decloop /usr/bin/ld: kernel/n/o/numerix-t.o: pc-relative relocation against dynamic symbol sn_cpuploop /
Bug#410688: qemu_0.9.0-1(experimental/alpha/ds10): FTBFS: too many arguments to function `gen_op_jmp_label'/`gen_op_jnz_T0_label'
Package: qemu Version: 0.9.0-1 Severity: serious Tags: experimental Automatic build of qemu_0.9.0-1 on ds10 by sbuild/alpha 98-farm Build started at 20070212-0417 ** [...] CFLAGS="-Wall -g -fno-strict-aliasing -O2" ./configure \ --prefix=/usr \ --enable-alsa \ --cc=gcc-3.4 Install prefix/usr BIOS directory/usr/share/qemu binary directory /usr/bin Manual directory /usr/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /build/buildd/qemu-0.9.0 C compilergcc-3.4 Host C compiler gcc make make install install host CPU alpha host big endian no target list i386-linux-user arm-linux-user armeb-linux-user sparc-linux-user ppc-linux-user mips-linux-user mipsel-linux-user m68k-linux-user i386-softmmu ppc-softmmu sparc-softmmu x86_64-softmmu mips-softmmu mipsel-softmmu arm-softmmu gprof enabled no profiler no static build no SDL support yes SDL static link yes curses supportyes mingw32 support no Adlib support no CoreAudio support no ALSA support yes DSound supportno FMOD support no kqemu support no Documentation yes NPTL support yes [...] gcc-3.4 -Wall -g -fno-strict-aliasing -O2 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/build/buildd/qemu-0.9.0/target-i386 -I/build/buildd/qemu-0.9.0 -I/build/buildd/qemu-0.9.0/linux-user -I/build/buildd/qemu-0.9.0/linux-user/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/build/buildd/qemu-0.9.0/fpu -DHAS_AUDIO -I/build/buildd/qemu-0.9.0/slirp -msmall-data -c -o translate.o /build/buildd/qemu-0.9.0/target-i386/translate.c /build/buildd/qemu-0.9.0/target-i386/translate.c:877: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:878: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:883: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:884: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:896: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:897: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:898: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:902: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:903: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:904: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1177: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1178: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1179: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1180: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1182: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1183: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1187: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1188: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1189: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1190: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1192: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1193: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1197: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1198: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1199: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1200: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1202: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1203: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/translate.c:1220: warning: initialization from incompatible pointer type /build/buildd/qemu-0.9.0/target-i386/transla
Bug#413338: Enable regular expressions in the mail whitelist
Package: dak
Version: 1.0-8.4
Severity: wishlist
Tags: Patch
Hi,
I've implemented a backwards-compatible way to include regular
expressions in the mail whitelist for dak. To use a regular expression
instead of regular string, use a "RE:" prefix in the whitelist file.
Marc
--
BOFH #357:
I'd love to help you -- it's just that the Boss won't let me near
the computer.
diff -Nru dak-1.0/utils.py dak-1.0.new/utils.py
--- dak-1.0/utils.py 2006-01-28 14:24:20.0 +0100
+++ dak-1.0.new/utils.py 2007-03-04 12:41:26.0 +0100
@@ -380,11 +380,16 @@
message_in.close();
whitelist_in = open_file(Cnf["Dinstall::MailWhiteList"])
-whitelist = whitelist_in.readlines()
-whitelist_in.close()
+RE_mark = re.compile(r'^RE:')
+try:
+for line in whitelist_in:
+if RE_mark.match(line):
+whitelist.append(re.compile(RE_mark.sub("", line.strip(), 1)))
+else:
+whitelist.append(re.compile(re.escape(line.strip(
+finally:
+whitelist_in.close()
-# Remove newlines
-whitelist = map(string.strip, whitelist)
# Fields to check. Here the order is important because Bcc
# will be the last changed field
@@ -396,7 +401,12 @@
match = [];
for item in value.split(","):
(rfc822_maint, rfc2047_maint, name, email) = fix_maintainer(item.strip())
-if email not in whitelist:
+mail_whitelisted = 0
+for wr in whitelist:
+if wr.match(email):
+mail_whitelisted = 1
+break
+if not mail_whitelisted:
print "Skipping %s since it's not in %s" % (item, Cnf["Dinstall::MailWhiteList"])
continue
match.append(item)
Bug#413338: Enable regular expressions in the mail whitelist
Frederic Lehobey <[EMAIL PROTECTED]> writes: > On Sun, Mar 04, 2007 at 12:45:54PM +0100, Marc 'HE' Brockschmidt wrote: >> I've implemented a backwards-compatible way to include regular >> expressions in the mail whitelist for dak. To use a regular expression >> instead of regular string, use a "RE:" prefix in the whitelist file. > Beware your patch might be hit by #349919 too: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349919 It doesn't change the code for the actual header splitting, so naturally the bug also applies for my patch. A correct fix for #349919 would be to use parseaddr(address) from email.utils, but that still won't work for the broken maintainer name you quoted in your initial bug report (as all tools expect the content of the Maintainer and Uploaders field to conform to RFC822 address lists). Marc -- Fachbegriffe der Informatik - Einfach erklärt 231: Debugger Psychologe, der einem erklärt, warum man beim Anbaggern abgeblitzt ist. (Manfred Worm Schäfer) pgpHPq5uEX3iv.pgp Description: PGP signature
Bug#413338: Enable regular expressions in the mail whitelist
tags 349919 + patch
thanks
Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> writes:
> A correct fix for #349919 would be to use parseaddr(address) from
> email.utils, but that still won't work for the broken maintainer name
> you quoted in your initial bug report (as all tools expect the content
> of the Maintainer and Uploaders field to conform to RFC822 address
> lists).
I've thought about this again and hacked up a workaround for this
issue. It's not really nice, but it will not lead to a backtrace...
Attached patch is done on top of my RE patch for the whitelists from
#413338.
Marc
--
Fachbegriffe der Informatik - Einfach erklärt
263: MCSE
Meine Computerkenntisse Sind Erbärmlich (Sebastian Posner)
diff -Nwru dak-1.0/utils.py dak-1.0.new/utils.py
--- dak-1.0/utils.py 2007-03-08 09:28:57.0 +0100
+++ dak-1.0.new/utils.py 2007-03-08 09:32:23.0 +0100
@@ -24,7 +24,7 @@
import commands, encodings.ascii, encodings.utf_8, encodings.latin_1, \
email.Header, os, pwd, re, select, socket, shutil, string, sys, \
- tempfile, traceback;
+ tempfile, traceback, email.Utils;
import apt_pkg;
import db_access;
import email as modemail
@@ -399,8 +399,10 @@
value = message_raw.get(field, None)
if value != None:
match = [];
-for item in value.split(","):
-(rfc822_maint, rfc2047_maint, name, email) = fix_maintainer(item.strip())
+for item in email.Utils.getaddresses([value]):
+(name, email) = item
+if not email == None or mail.find("@") == -1 :
+continue
mail_whitelisted = 0
for wr in whitelist:
if wr.match(email):
pgpKZlnLfXFcV.pgp
Description: PGP signature
Bug#410595: evince: Copy selection changes text to white-on-white
merge 410595 365575 thanks Karl Schmidt <[EMAIL PROTECTED]> writes: > Package: evince > Version: 0.4.0-5 > Severity: important [...] > this is the current version in etch - To recreate: > > Open a pdf then left-click and drage to select text - changes to all white. This is a known problem in the evince/poppler combination in Etch, but has been fixed in the new versions which are already available in experimental. Marc -- BOFH #418: Sysadmins busy fighting SPAM. pgpNktP9hCz7Q.pgp Description: PGP signature
Bug#413953: evince respects pdf passwords, leading to user confusion when compared to xpdf
reassign 413953 libpoppler0c2 thanks Joey Hess <[EMAIL PROTECTED]> writes: > Since Debian's xpdf is uncripped to not ask for stupid pdf passwords, > users can get really confused when evince asks for passwords for the > same documents, as you can see in the forwarded message below. > > evince in Debian should have the same level of uncrippledness and > freedom as xpdf. This problem needs to be fixed in poppler, not in evince. evince just gets POPPLER_ERROR_ENCRYPTED back from poppler and tries to get a password for the document then. Marc -- BOFH #352: The cables are not the same length. pgp06zG2aAUkB.pgp Description: PGP signature
Bug#413964: xulrunner: Broken xulrunner-plugin.pc causes gcj-4.1 to FTBFS
Mike Hommey <[EMAIL PROTECTED]> writes: > On Thu, Mar 08, 2007 at 01:07:53PM -0800, Steve Langasek <[EMAIL PROTECTED]> > wrote: >> On Thu, Mar 08, 2007 at 01:37:49PM +0100, Mike Hommey wrote: >>> If the gcj plugin is making use of xpcom, it should require xulrunner-xpcom >>> too. >>> See https://bugzilla.mozilla.org/show_bug.cgi?id=366113#c8 >> Still, this is an 11th-hour regression introduced by the new xulrunner, >> AFAICS. Even if the "bug" belongs to gcj-4.1, this change in xulrunner's >> behavior is grounds for not letting the new xulrunner into etch. Security >> updates need to not break related packages. > So what ? Better "fixing" xulrunner than gcj-4.1 ? This gets ridiculous. At this time, we don't know which other third-party application rely on this specific xulrunner configuration, and I really don't want to risk to break anything else. It's easier to revert this change for xulrunner now instead of testing every possible r-dep. Marc -- BOFH #86: Runt packets pgpv8DxCqA9Tr.pgp Description: PGP signature
