Bug#691858: ITP: ruby-rails-i18n -- locale data and translations to internationalize and/or localize Rails applications
Package: wnpp Severity: wishlist Owner: Praveen Arimbrathodiyil * Package name: ruby-rails-i18n Version : 0.7.0 Upstream Author : Rails I18n Group * URL : http://github.com/svenfuchs/rails-i18n * License : MIT/X Programming Lang: Ruby Description : locale data and translations to internationalize and/or localize Rails applications -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121030125828.20721.3821.reportbug@savannah
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Lucas Nussbaum writes ("[PROPOSAL v2] Orphaning another maintainer's packages"):
> - one week has passed since the ITO bug was submitted, and at least
> 3 DDs supported the orphaning (possibly including the submitter
> of the ITO bug, if it was a DD), while nobody objected.
I think one week is far too short. I think Zack's proposed 15 days is
still far too short. As so many people have sid, none of this is
urgent.
I think four weeks would be much better. A maintainer might
reasonably go abroad for 2-3 weeks - we even have a VAC process for
handling absences. (And we don't want to complicate this third-party
orphan process with references to VACs.)
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20623.53877.252062.170...@chiark.greenend.org.uk
Candidates for removal from testing (2012-10-30)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, We are considering removing the following packages from testing as they have unfixed RC bugs filed against them. The packages can be found in the attached dd-list. The bugs that put them on this list can be found in the removals file (also attached) just above the package name. We have BCC'ed this email to @packages.debian.org for the relevant packages. The packages have been selected based on the following criteria: * The package had at least one RC bug without activity for the past 14 days. * If a bug is assigned to multiple packages, both packages will be affected. * The RC bug affects both unstable and testing. * The affected package does not have any reverse dependencies in testing. If the relevant RC bugs in the affected packages are not dealt with /before/ Wednesday the 7th of Nov.[1], the packages will be removed from testing. Note that "dealt with" may also include downgrading a severity-inflated bug or fixing affected versions in the BTS. Please remember to file unblock bugs for packages fixed via uploads to unstable (and tpu bugs for requests to fix the package via a tpu upload). Should you need a bit more time than given, please do not hesitate to contact us. It is also easier for us if we can avoid having to reintroduce a removed package. We will check the DELAYED queues before activing the removal hints, so NMUs in the DELAYED queues will be given a chance to reach unstable. Thanks, Niels (on behalf of the Release Team) The bugs were found using the tools from: svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages http://release.debian.org/wheezy/freeze_policy.html [1] We intend to do the removal with the 10:00 UTC run of Britney of that day. --8<-- dd-list --8<-- Aurélien GÃRÃME dancer-ircd Al Stone lmbench Chris Lamb python-django-extensions Debian PHP Maintainers xcache (U) Debian XMPP Maintainers jabber-muc Ghe Rivero quantum (U) Jesus Climent distmp3 Jorge Salamero Sanz jabber-muc (U) Jose Luis Tallon couriergraph Julien Danjou quantum (U) Kai Storbeck roundup Loic Dachary (OuoU) quantum (U) Ludovic Brenta polyorb (U) Martin Loschwitz ircd-ircu Mehdi Abaakouk quantum (U) Michal ÄihaÅ xcache Mike Markley dk-milter Peter Krefting lyskom-server PKG OpenStack quantum Thomas Goirand quantum (U) Toni Mueller roundup (U) Xavier Grave polyorb --8<-- end of dd-list --8<-- --8<-- removals.txt --8<-- # #689884 remove couriergraph/0.25-4.1 # #689886 remove dancer-ircd/1.0.36-8 # #689887 remove distmp3/0.1.9.ds1-4.4 # #689888 remove dk-milter/1.0.0.dfsg-1.2 # #689893 remove ircd-ircu/2.10.12.10.dfsg1-1 # #689894 remove jabber-muc/0.8-3 # #689897 remove lmbench/3.0-a9-1 # #689898 remove lyskom-server/2.1.2-12 # #688299 remove polyorb/2.8~20110207-4 # #690425 remove python-django-extensions/0.6+git201107051902-1 # #685251 remove quantum/2012.1-5 # #689257 remove roundup/1.4.20-1 # #690409 remove xcache/2.0.0-2 --8<-- end of removals.txt --8<-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQj9XpAAoJEAVLu599gGRCilQP/0Pzrbiq2Qi5xRdN2Auk7mzr Clqbt9nStd0ZDR6ju2lxVj9emkOIRMUAp5Oq2c/+lC5pg2+AgZD57ijKMJqJLDTM o8Fr8oIVdAcyMgNt7hKo8vXcIz0gBh6qwLWRXdR37pTd4jNqjCGnTtxbS5ZMIcz0 x9J2LjvIPLE+KEsjmAw185W8YVvvkaqVQqfwQ6K0xGdXvv23gfhlimlFHQUs8ElG yljmcRl0e+xBlFxa+zmueBeAPcwPCjUv5haJQWXEZVUjxXezO4FEdwcHZFDeLKYy 1DzpOFcd6wycjqsdizQQtzNGGF726Fdj2nSKc7RjZ2oMr34lYQPKgN233t+QK8f9 aHatHySzcj6etlmsjdHmHreSnzzMxrf08OqWKW8O7AmrWkUdWnQFnUuDXc1A+Dwf ESBG51fbHVj/wCNQ3vq9WyNwZpXqn2VxtHceMhiNdjbjkh/hjr2/k6hUeLADxBqG dwwLA1p3UVk35R19rk5C2qaJIV8INZXfnsg7qZ7rS+JoO0+ZNyRwbxQFuE6Wf1+2 fAvyjmB6qiqHoZ+tSBP44PTzN2uPofZbfe6GTcRVQGJW3JxUSNmjNgefAmXl5367 KJxQKhb6Y3fDbWEl+sum6cV5QMriPxtNY8NnaEBgeGlzWFSlI5s+ozMUrSOTKOV/ E6STJCINXJEOKmcx1ogj =4EtK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121030133215.e95cf3...@thykier.net
Re: Candidates for removal from testing (results)
On 2012-10-28 18:47, Stefano Zacchiroli wrote: > On Fri, Oct 26, 2012 at 12:37:38PM +0200, Niels Thykier wrote: >> ax25-apps, fabric, firmware-crystalhd, icewm-themes, ilisp, inguma, >> lustre, mingw-ocaml, noflushd, openvas-plugins-dfsg, php-crypt-gpg, >> phpgacl, python-django-piston, smbind, sorl-thumbnail, spatialite-gui, >> sugar-chat-activity-0.86, sugar-log-activity-0.86, sugar-moon-activity, >> twidge, venkman >> >> The removed packages accounted for about 4.4% of all RC bugs left in >> testing[0]. > > Thanks a lot, Neil! Is that something that you plan to automate further > (at least the "warning" mails, I understand you probably want to further > inspect the individual removals), and/or run on a fixed cadence? > I have just send another round (only 13-14 packages this time). I hope I can keep it at once per week for the rest of the freeze (or till we run out of RC buggy leaf packages). Though I am not sure whether to keep the rate this high outside freeze. Maybe keep the rate with higher deadline or slow down to (e.g.) bi-weekly mails... Anyway, we can look at that once development of Jessie starts. :) ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508fda1c.3090...@thykier.net
Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Tue, Oct 30, 2012 at 01:13:25PM +, Ian Jackson wrote:
> Lucas Nussbaum writes ("[PROPOSAL v2] Orphaning another maintainer's
> packages"):
> > - one week has passed since the ITO bug was submitted, and at least
> > 3 DDs supported the orphaning (possibly including the submitter
> > of the ITO bug, if it was a DD), while nobody objected.
>
> I think one week is far too short. I think Zack's proposed 15 days is
> still far too short. As so many people have sid, none of this is
> urgent.
>
> I think four weeks would be much better. A maintainer might
> reasonably go abroad for 2-3 weeks - we even have a VAC process for
> handling absences. (And we don't want to complicate this third-party
> orphan process with references to VACs.)
I lived under the impression that we were talking about packages which
were not touched for a *long* time (way longer than four weeks). So we
had some long waiting time X + 15 additional days proposed by Zack. We
are not talking about stealing packages right at the first day of a
maintainers VAC, right?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121030135212.ga10...@an3as.eu
Bug#691866: ITP: ruby-rack-protection -- potection against typical web attacks for all rack apps, including rails
Package: wnpp Severity: wishlist Owner: Praveen Arimbrathodiyil * Package name: ruby-rack-protection Version : 1.2.0 Upstream Author : Konstantin Haase, Akzhan Abdulin, Corey Ward, David Kellum, Fojas, Martin Mauch * URL : http://github.com/rkh/rack-protection * License : MIT/X Programming Lang: Ruby Description : potection against typical web attacks for all rack apps, including rails -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121030141406.15120.70017.reportbug@savannah
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Andreas Tille writes ("Re: [PROPOSAL v2] Orphaning another maintainer's
packages"):
> On Tue, Oct 30, 2012 at 01:13:25PM +, Ian Jackson wrote:
> > I think four weeks would be much better. A maintainer might
> > reasonably go abroad for 2-3 weeks - we even have a VAC process for
> > handling absences. (And we don't want to complicate this third-party
> > orphan process with references to VACs.)
>
> I lived under the impression that we were talking about packages which
> were not touched for a *long* time (way longer than four weeks). So we
> had some long waiting time X + 15 additional days proposed by Zack.
Consider the case where a maintainer objects. In that case you're
counting in the previous "long waiting" time a period which the
orphaner probably thinks shows disinterest in the package, but during
which the maintainer may well feel (for part of the time at least)
that the package simply didn't need any attention. So I don't think
counting time-since-last-touched towards the notification period (even
in the moral sense you're now doing) is reasonable.
Also this argument is a form of "this has been waiting for ages so now
it is urgent" which I don't really agree with (unless there's an
actual deadline of course).
Unless we're having some heavyweight process with multiple pings
etc. (which we IMO shouldn't) the way the maintainer might first
discover that someone feels the package needs to be orphaned is by the
ITO bug. The maintainer needs to have a good chance to object.
> We are not talking about stealing packages right at the first day
> of a maintainers VAC, right?
That's not the intent, of course. But if we invent a new process with
objective criteria, it needs to be robust against malicious
interpretation (or indeed careless action which follows the letter of
the rules).
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20623.58492.876115.508...@chiark.greenend.org.uk
Bug#691868: ITP: ruby-patron -- Ruby HTTP client library based on libcurl
Package: wnpp Severity: wishlist Owner: Praveen Arimbrathodiyil * Package name: ruby-patron Version : 0.4.18 Upstream Author : Phillip Toland * URL : https://github.com/toland/patron * License : MIT/X Programming Lang: Ruby Description : Ruby HTTP client library based on libcurl -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121030144043.17721.68386.reportbug@savannah
Re: [PROPOSAL v2] Orphaning another maintainer's packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I think four weeks would be much better. A maintainer might > reasonably go abroad for 2-3 weeks - we even have a VAC process for > handling absences. (And we don't want to complicate this third-party > orphan process with references to VACs.) Remember that we do not really have a VAC process for the ~50% of maintainers who are not DDs [1]. That group of maintainers have no real way of letting the rest of the project know that they are on VAC [2]. They also have an interest in and a proven ability to maintain packages and so may like to help out with other unmaintained packages ... after all, we they are encouraged time and time again to adopt packages rather than introduce new ones into the archive. But they cannot know if the maintainer is on VAC or not to engage in this process. I'm not suggesting that VAC status should be public information, but blanket statements that we know if maintainers are on VAC (or MIA or whatever) are wrong for 50% of our maintainers as are statements that potential salvagers have this information. cheers Stuart [1] http://lists.debian.org/jr6344$lkp$1...@dough.gmane.org [2] I would encourage them to let their sponsors know this since the sponsors are in the position of helping care for their packages anyway - -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCP7EgACgkQn+i4zXHF0ajEqACgvyXY9SvtOYjjh0RsaUrgO580 n7UAoNPA7ggz/QbjhHBaO4K3ZPdqsiXi =5Qyy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/k6oq8f$22k$1...@ger.gmane.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Le mardi 30 octobre 2012 16:03:35, Stuart Prescott a écrit : > > I think four weeks would be much better. A maintainer might > > reasonably go abroad for 2-3 weeks - we even have a VAC process for > > handling absences. (And we don't want to complicate this third-party > > orphan process with references to VACs.) > > Remember that we do not really have a VAC process for the ~50% of > maintainers who are not DDs [1]. That group of maintainers have no real way > of letting the rest of the project know that they are on VAC [2]. They actually can send an email to debian-private to notify other DD that they are on VAC. They cannot subscribe to this mailing list but they can send mail to it. > > cheers > Stuart Cheers, Thomas signature.asc Description: This is a digitally signed message part.
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Stuart Prescott writes ("Re: [PROPOSAL v2] Orphaning another maintainer's
packages"):
> I'm not suggesting that VAC status should be public information, but blanket
> statements that we know if maintainers are on VAC (or MIA or whatever) are
> wrong for 50% of our maintainers as are statements that potential salvagers
> have this information.
This is a good point. Another reason why the post-ITO waiting period
should be much longer than two weeks.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20623.63037.387949.829...@chiark.greenend.org.uk
Re: Candidates for removal from testing (2012-10-30)
Hello List, does it make sense to establish a list of candidates for reintroduction to testing ? I have in mind packages that were discarded too quickly because an easy to fix a RC appeared a some point while it was unofficially orphaned. Jerome On 30/10/12 14:32, Niels Thykier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, We are considering removing the following packages from testing as they have unfixed RC bugs filed against them. The packages can be found in the attached dd-list. The bugs that put them on this list can be found in the removals file (also attached) just above the package name. We have BCC'ed this email to@packages.debian.org for the relevant packages. The packages have been selected based on the following criteria: * The package had at least one RC bug without activity for the past 14 days. * If a bug is assigned to multiple packages, both packages will be affected. * The RC bug affects both unstable and testing. * The affected package does not have any reverse dependencies in testing. If the relevant RC bugs in the affected packages are not dealt with /before/ Wednesday the 7th of Nov.[1], the packages will be removed from testing. Note that "dealt with" may also include downgrading a severity-inflated bug or fixing affected versions in the BTS. Please remember to file unblock bugs for packages fixed via uploads to unstable (and tpu bugs for requests to fix the package via a tpu upload). Should you need a bit more time than given, please do not hesitate to contact us. It is also easier for us if we can avoid having to reintroduce a removed package. We will check the DELAYED queues before activing the removal hints, so NMUs in the DELAYED queues will be given a chance to reach unstable. Thanks, Niels (on behalf of the Release Team) The bugs were found using the tools from: svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages http://release.debian.org/wheezy/freeze_policy.html [1] We intend to do the removal with the 10:00 UTC run of Britney of that day. --8<-- dd-list --8<-- Aurélien GÉRÔME dancer-ircd Al Stone lmbench Chris Lamb python-django-extensions Debian PHP Maintainers xcache (U) Debian XMPP Maintainers jabber-muc Ghe Rivero quantum (U) Jesus Climent distmp3 Jorge Salamero Sanz jabber-muc (U) Jose Luis Tallon couriergraph Julien Danjou quantum (U) Kai Storbeck roundup Loic Dachary (OuoU) quantum (U) Ludovic Brenta polyorb (U) Martin Loschwitz ircd-ircu Mehdi Abaakouk quantum (U) Michal Čihař xcache Mike Markley dk-milter Peter Krefting lyskom-server PKG OpenStack quantum Thomas Goirand quantum (U) Toni Mueller roundup (U) Xavier Grave polyorb --8<-- end of dd-list --8<-- --8<-- removals.txt --8<-- # #689884 remove couriergraph/0.25-4.1 # #689886 remove dancer-ircd/1.0.36-8 # #689887 remove distmp3/0.1.9.ds1-4.4 # #689888 remove dk-milter/1.0.0.dfsg-1.2 # #689893 remove ircd-ircu/2.10.12.10.dfsg1-1 # #689894 remove jabber-muc/0.8-3 # #689897 remove lmbench/3.0-a9-1 # #689898 remove lyskom-server/2.1.2-12 # #688299 remove polyorb/2.8~20110207-4 # #690425 remove python-django-extensions/0.6+git201107051902-1 # #685251 remove quantum/2012.1-5 # #689257 remove roundup/1.4.20-1 # #690409 remove xcache/2.0.0-2 --8<-- end of removals.txt --8<-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQj9XpAAoJEAVLu599gGRCilQP/0Pzrbiq2Qi5xRdN2Auk7mzr Clqbt9nStd0ZDR6ju2lxVj9emkOIRMUAp5Oq2c/+lC5pg2+AgZD57ijKMJqJLDTM o8Fr8oIVdAcyMgNt7hKo8vXcIz0gBh6qwLWRXdR37pTd4jNqjCGnTtxbS5ZMIcz0 x9J2LjvIPLE+KEsjmAw185W8YVvvkaqVQqfwQ6K0xGdXvv23gfhlimlFHQUs8ElG yljmcRl0e+xBlFxa+zmueBeAPcwPCjUv5haJQWXEZVUjxXezO4FEdwcHZFDeLKYy 1DzpOFcd6wycjqsdizQQtzNGGF726Fdj2nSKc7RjZ2oMr34lYQPKgN233t+QK8f9 aHatHySzcj6etlmsjdHmHreSnzzMxrf08OqWKW8O7AmrWkUdWnQFnUuDXc1A+Dwf ESBG51fbHVj/wCNQ3vq9WyNwZpXqn2VxtHceMhiNdjbjkh/hjr2/k6hUeLADxBqG dwwLA1p3UVk35R19rk5C2qaJIV8INZXfnsg7qZ7rS+JoO0+ZNyRwbxQFuE6Wf1+2 fAvyjmB6qiqHoZ+tSBP44PTzN2uPofZbfe6GTcRVQGJW3JxUSNmjNgefAmXl5367 KJxQKhb6Y3fDbWEl+sum6cV5QMriPxtNY8NnaEBgeGlzWFSlI5s+ozMUrSOTKOV/ E6STJCINXJEOKmcx1ogj =4EtK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/508ff7f4.2070...@rezozer.net
Re: Candidates for removal from testing (2012-10-30)
On Tue, Oct 30, 2012 at 04:53:24PM +0100, Jerome BENOIT wrote: > does it make sense to establish a list of candidates for reintroduction to > testing ? Is this not something best managed on a case-by-case basis? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121030163630.GA20675@debian
Re: Candidates for removal from testing (2012-10-30)
On 30/10/12 17:36, Jon Dowland wrote: On Tue, Oct 30, 2012 at 04:53:24PM +0100, Jerome BENOIT wrote: does it make sense to establish a list of candidates for reintroduction to testing ? Is this not something best managed on a case-by-case basis? my experience as potential sponsoree for such a package answers me no because it is hard to get a sponsor. Jerome -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/509004b9.1060...@rezozer.net
Re: Mandatory -dbg packages
On Mon, Oct 29, 2012 at 05:18:41PM +0200, Andrej N. Gritsenko wrote: > Hello! > > Stefano Rivera has written on Monday, 29 October, at 16:57: > >Hi Tzafrir (2012.10.29_16:29:06_+0200) > >> While clearing your throat, mind telling us how this works in Ubuntu > >> with PPAs? What happens if you installed a package from a PPA and you > >> want to generate a backtrace of a program that happens to use that > >> package? > > >> 1. You'll get debug information for the package. > >> 2. You won't get debug information for the package. > >> 3. You may accidentally get debug information for a diffent version of > >>the package. > > >2. It'll tell you that there aren't any debug symbols available. (IIRC) > > >The -dbgsym packages are only generated in primary archive builds. > > I'm sorry to disappoint you about the Ubuntu PPAs but look into my > PPA - https://launchpad.net/~andrej-rep/+archive/ppa/+packages - to see > all those dbg packages. And users were used them to give me feedback to > bugs with full backtrace. But if you followed the Ubuntu way, you wouldn't have generated a -dbg package for it, right? http://packages.ubuntu.com/source/raring/pcmanfm I see that the Ubuntu package still produces a -dbg package. I figure that this is not what you would expect of an Ubuntu package. Is it possible to change dh_strip's --dbg-package to produce (or not) the dbg package in certain build conditions? The closest thing I see to that is http://bugs.debian.org/510772 . (I figure that there is also the issue of source-only uploads with regards to this) -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121030170359.gy12...@pear.tzafrir.org.il
Re: Mandatory -dbg packages
Hello!
Tzafrir Cohen has written on Tuesday, 30 October, at 17:04:
>On Mon, Oct 29, 2012 at 05:18:41PM +0200, Andrej N. Gritsenko wrote:
>> Stefano Rivera has written on Monday, 29 October, at 16:57:
>> >Hi Tzafrir (2012.10.29_16:29:06_+0200)
>> >> While clearing your throat, mind telling us how this works in Ubuntu
>> >> with PPAs? What happens if you installed a package from a PPA and you
>> >> want to generate a backtrace of a program that happens to use that
>> >> package?
>>
>> >> 1. You'll get debug information for the package.
>> >> 2. You won't get debug information for the package.
>> >> 3. You may accidentally get debug information for a diffent version of
>> >>the package.
>>
>> >2. It'll tell you that there aren't any debug symbols available. (IIRC)
>>
>> >The -dbgsym packages are only generated in primary archive builds.
>>
>> I'm sorry to disappoint you about the Ubuntu PPAs but look into my
>> PPA - https://launchpad.net/~andrej-rep/+archive/ppa/+packages - to see
>> all those dbg packages. And users were used them to give me feedback to
>> bugs with full backtrace.
>But if you followed the Ubuntu way, you wouldn't have generated a -dbg
>package for it, right?
You mean if the debian/rules had only one rule '%:' with 'dh ${@}'?
Sure, I wouldn't. But simple solution isn't always right solution despite
of Occam's razor - in case if simplification kills functionality. And no
automations are done in Ubuntu either, if you meant that.
>http://packages.ubuntu.com/source/raring/pcmanfm
>I see that the Ubuntu package still produces a -dbg package. I figure
>that this is not what you would expect of an Ubuntu package.
Many of packages in Ubuntu now produce -dbg packages. Just example:
xxx@xxx> grep '^Package: .*-dbg$'
/var/lib/apt/lists/ubuntu.org.ua_ubuntu_dists_oneiric_main_binary-i386_Packages
| wc -l
561
xxx@xxx> grep '^Source:'
/var/lib/apt/lists/ubuntu.org.ua_ubuntu_dists_oneiric_main_binary-i386_Packages
| sort | uniq | wc -l
1354
>Is it possible to change dh_strip's --dbg-package to produce (or not)
>the dbg package in certain build conditions?
Of course, I have an option to dh_strip there to have it but it is
common enough to have described name of debug package in debian/rules.
>The closest thing I see to that is http://bugs.debian.org/510772 .
Yes, I'm agree, to automate debug packaging would be nice thing. For
example, AltLinux (RPM-based distro) has it automated.
With best wishes.
Andriy.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121030181949.gb27...@rep.kiev.ua
Re: Candidates for removal from testing (2012-10-30)
On Tue, 30 Oct 2012 17:47:53 +0100 Jerome BENOIT wrote: > On 30/10/12 17:36, Jon Dowland wrote: > > On Tue, Oct 30, 2012 at 04:53:24PM +0100, Jerome BENOIT wrote: > >> does it make sense to establish a list of candidates for reintroduction to > >> testing ? > > > > Is this not something best managed on a case-by-case basis? > > my experience as potential sponsoree for such a package answers me no because > it is hard to get a sponsor. As a former sponsor, the most common problem I saw was that packages prepared for sponsoring during a release freeze took no account of the freeze policy and introduced lame or undesirable changes which were not suitable as RC bug fixes. If there's little chance of getting an unblock, there is no point sponsoring. Sponsoring can be more of a burden for the sponsor than just fixing the bug, especially during a release freeze. I have, on occasion, moved on to investigate a different RC bug in a more interesting package rather than go through the process of sponsoring a stale "fix" merely because it exists. This is as much a reflection of the kind of packages involved - most are leaf packages which are of little interest to most potential sponsors. Just because there is a potential fix (which still needs testing by the sponsor), doesn't always mean that the package is worth keeping in Debian. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpfSzUwtD0pP.pgp Description: PGP signature
Re: Candidates for removal from testing (2012-10-30)
On Tue, Oct 30, 2012 at 12:47 PM, Jerome BENOIT wrote: >> Is this not something best managed on a case-by-case basis? > > my experience as potential sponsoree for such a package answers me no > because > it is hard to get a sponsor. If it fixes *only* rc bugs, then send a bug to sponsorship-requests. I have already committed to reviewing all rc sponsorship-requests, so if it looks good, I will likely sponsor it. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mmghcuyor9lytgboosdw6un8in_anjnutdadqzebhc...@mail.gmail.com
Bug#691890: general: sudoers problem
Package: general Severity: grave Tags: d-i Justification: renders package unusable -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash I can not install any software, because if I type 'sudo su' and type the correct Password I get only: " is not in the sudoers file. This incident will be reported." I am the Admin, but I cannot do anything to personalyse my KDE Debian System. I also cannot edit the sudoers file, witch is empty, because I have not the Privileges to edit/Save the file Please send me help per e-mail Thank you! PS: I am sorry for my bad english, I am german -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121030201024.21274.27678.reportbug@PC-OLIVER
Bug#691890: marked as done (general: sudoers problem)
Your message dated Tue, 30 Oct 2012 20:26:05 + with message-id <1351628765.13356.19.ca...@deadeye.wl.decadent.org.uk> and subject line Re: Bug#691890: general: sudoers problem has caused the Debian Bug report #691890, regarding general: sudoers problem to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 691890: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691890 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: grave Tags: d-i Justification: renders package unusable -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash I can not install any software, because if I type 'sudo su' and type the correct Password I get only: " is not in the sudoers file. This incident will be reported." I am the Admin, but I cannot do anything to personalyse my KDE Debian System. I also cannot edit the sudoers file, witch is empty, because I have not the Privileges to edit/Save the file Please send me help per e-mail Thank you! PS: I am sorry for my bad english, I am german --- End Message --- --- Begin Message --- On Tue, 2012-10-30 at 21:10 +0100, Y wrote: > Package: general > Severity: grave > Tags: d-i > Justification: renders package unusable > > > > -- System Information: > Debian Release: 6.0.6 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > I can not install any software, because if I type 'sudo su' and type the > correct Password I get only: > " is not in the sudoers file. This incident will be reported." > > I am the Admin, but I cannot do anything to personalyse my KDE Debian System. > > I also cannot edit the sudoers file, witch is empty, because I have not the > Privileges to edit/Save the file This is not a bug. Remember not to delete /etc/sudoers again. > Please send me help per e-mail > > Thank you! > > PS: I am sorry for my bad english, I am german Then ask for help on debian-user-ger...@lists.debian.org Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part --- End Message ---
Processed: reassign bug
Processing commands for cont...@bugs.debian.org:
> reassign 691890 sudo
Bug #691890 {Done: Ben Hutchings } [general] general:
sudoers problem
Bug reassigned from package 'general' to 'sudo'.
Ignoring request to alter found versions of bug #691890 to the same values
previously set
Ignoring request to alter fixed versions of bug #691890 to the same values
previously set
> severity 691890 normal
Bug #691890 {Done: Ben Hutchings } [sudo] general:
sudoers problem
Severity set to 'normal' from 'grave'
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
691890: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691890
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/handler.s.c.135163053511466.transcr...@bugs.debian.org
