Processing of wdm_1.28-14_i386.changes
wdm_1.28-14_i386.changes uploaded successfully to localhost along with the files: wdm_1.28-14.dsc wdm_1.28-14.debian.tar.gz wdm_1.28-14_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ualjq-0001mc...@franck.debian.org
wdm_1.28-14_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 10 May 2013 11:28:56 +0200 Source: wdm Binary: wdm Architecture: source i386 Version: 1.28-14 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Agustin Martin Domingo agmar...@debian.org Description: wdm- WINGs Display Manager - an xdm replacement with a WindowMaker loo Closes: 707231 Changes: wdm (1.28-14) unstable; urgency=low . * QA upload. * wdm.pam: Ignore pam_selinux.so failures when the module does not exist (e.g. on architectures without SE Linux support like non-linux) instead of requiring it. Thanks Laurent Bigonville for bug report and proposed change (Closes: #707231). Checksums-Sha1: e32195a222b148f546bbf334e5fb06a05138a641 1444 wdm_1.28-14.dsc 4bd065daa4be7535e2e7e6ff849bc2e194e33a3a 70507 wdm_1.28-14.debian.tar.gz e984879b713e0b8d90790f91e155f95602cce9d1 337850 wdm_1.28-14_i386.deb Checksums-Sha256: 500fac85b0cfb8224fc3efccc45a163d144a9f4fd385c20373a3db76bb366f0b 1444 wdm_1.28-14.dsc 42d7945b5fc2b3dbd243ba61883116e7e0d247f9a1de275dd3651266de2b7cbe 70507 wdm_1.28-14.debian.tar.gz 9509de249c3adc2042651775ef075cfb3215f4f5ffb79c140ab2834a2fb308bf 337850 wdm_1.28-14_i386.deb Files: 141c74ed5b87a4079941141e20e0c7dd 1444 x11 optional wdm_1.28-14.dsc 161ff8895bc93087146598c92f60d917 70507 x11 optional wdm_1.28-14.debian.tar.gz a093bb2d47f76ecefef6f05c6de18b4f 337850 x11 optional wdm_1.28-14_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFRjMVOTShHqj72DpwRAg6ZAJ4s2zhlKbDlW9G+bKbU+XYFPVM9agCdHHb3 CXw0RO01B4yGvQC71mRtGCQ= =sdm0 -END PGP SIGNATURE- Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uallx-0002lq...@franck.debian.org
Bug#707231: marked as done (wdm: pam_selinux is not available on !linux)
Your message dated Fri, 10 May 2013 11:18:43 + with message-id e1uallx-0002lx...@franck.debian.org and subject line Bug#707231: fixed in wdm 1.28-14 has caused the Debian Bug report #707231, regarding wdm: pam_selinux is not available on !linux 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.) -- 707231: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707231 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: wdm Version: 1.28-12 Severity: serious Hello, Since version 1.28-12, wdm is calling the pam_selinux pam module (bug #664809). The problem is that pam_selinux is only available on linux architectures. As you made the pam_selinux module required in the pam configuration, this could prevent the user to login on !linux architectures. You should change this to something like: [success=ok ignore=ignore module_unknown=ignore default=bad] Cheers Laurent Bigonville -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- Source: wdm Source-Version: 1.28-14 We believe that the bug you reported is fixed in the latest version of wdm, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 707...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Agustin Martin Domingo agmar...@debian.org (supplier of updated wdm package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 10 May 2013 11:28:56 +0200 Source: wdm Binary: wdm Architecture: source i386 Version: 1.28-14 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Agustin Martin Domingo agmar...@debian.org Description: wdm- WINGs Display Manager - an xdm replacement with a WindowMaker loo Closes: 707231 Changes: wdm (1.28-14) unstable; urgency=low . * QA upload. * wdm.pam: Ignore pam_selinux.so failures when the module does not exist (e.g. on architectures without SE Linux support like non-linux) instead of requiring it. Thanks Laurent Bigonville for bug report and proposed change (Closes: #707231). Checksums-Sha1: e32195a222b148f546bbf334e5fb06a05138a641 1444 wdm_1.28-14.dsc 4bd065daa4be7535e2e7e6ff849bc2e194e33a3a 70507 wdm_1.28-14.debian.tar.gz e984879b713e0b8d90790f91e155f95602cce9d1 337850 wdm_1.28-14_i386.deb Checksums-Sha256: 500fac85b0cfb8224fc3efccc45a163d144a9f4fd385c20373a3db76bb366f0b 1444 wdm_1.28-14.dsc 42d7945b5fc2b3dbd243ba61883116e7e0d247f9a1de275dd3651266de2b7cbe 70507 wdm_1.28-14.debian.tar.gz 9509de249c3adc2042651775ef075cfb3215f4f5ffb79c140ab2834a2fb308bf 337850 wdm_1.28-14_i386.deb Files: 141c74ed5b87a4079941141e20e0c7dd 1444 x11 optional wdm_1.28-14.dsc 161ff8895bc93087146598c92f60d917 70507 x11 optional wdm_1.28-14.debian.tar.gz a093bb2d47f76ecefef6f05c6de18b4f 337850 x11 optional wdm_1.28-14_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFRjMVOTShHqj72DpwRAg6ZAJ4s2zhlKbDlW9G+bKbU+XYFPVM9agCdHHb3 CXw0RO01B4yGvQC71mRtGCQ= =sdm0 -END PGP SIGNATUREEnd Message---
Processing of tuxcmd-modules_0.6.70+ds-5_amd64.changes
tuxcmd-modules_0.6.70+ds-5_amd64.changes uploaded successfully to localhost along with the files: tuxcmd-modules_0.6.70+ds-5.dsc tuxcmd-modules_0.6.70+ds-5.debian.tar.gz tuxcmd-modules_0.6.70+ds-5_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uatml-0004tt...@franck.debian.org
tuxcmd-modules_0.6.70+ds-5_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 10 May 2013 22:00:35 +0200 Source: tuxcmd-modules Binary: tuxcmd-modules Architecture: source amd64 Version: 0.6.70+ds-5 Distribution: unstable Urgency: low Maintainer: Debian QA Group packa...@qa.debian.org Changed-By: Salvatore Bonaccorso car...@debian.org Description: tuxcmd-modules - VFS modules for tuxcmd file manager Changes: tuxcmd-modules (0.6.70+ds-5) unstable; urgency=low . * QA upload. * Set Maintainer to Debian QA Group * Bump Standards-Version to 3.9.4 * Update copyright years for debian/* packaging files Checksums-Sha1: 61fa63b0d0d6d8ceb2c2833155bacd9ff2c028a2 1865 tuxcmd-modules_0.6.70+ds-5.dsc 0ba3120f796b5b35f14136abf53dcb51c36fea51 6547 tuxcmd-modules_0.6.70+ds-5.debian.tar.gz aeaf323e810c12cffb893ade37a89bf944098b7f 177870 tuxcmd-modules_0.6.70+ds-5_amd64.deb Checksums-Sha256: 5c174e99f06b5a96c8c1e026bf5933e155269ebc53acd20ea09350ba58cb2a21 1865 tuxcmd-modules_0.6.70+ds-5.dsc 009ab4629e84e0bb656833b205eb31df4285c15c2ef2bdba5612672d50d02b2b 6547 tuxcmd-modules_0.6.70+ds-5.debian.tar.gz 1fc113277a93aed52851ab5f2d81ba137459819be56a472673088dd6557cb030 177870 tuxcmd-modules_0.6.70+ds-5_amd64.deb Files: 8690513c41bdd61e0f5260d87f01c75f 1865 utils optional tuxcmd-modules_0.6.70+ds-5.dsc 06bd305ecefa1c2313ddc20391c16417 6547 utils optional tuxcmd-modules_0.6.70+ds-5.debian.tar.gz 12dc3b24e3b396b57fd29a813aacf1f9 177870 utils optional tuxcmd-modules_0.6.70+ds-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJRjVRiAAoJEHidbwV/2GP+B1wQAJLKOqNbLS8CSZ0yuJ/Q9ZYU XLE0QnSXiC8T4L68VMwdhUc67S+b/JJceOzO/v0D/02T9ckxh1yQa1Ykqczi7yV3 n092bVQbqr25NxHWIY+L0yiYQKmCgcdKxjqg1AqWsD4gO/rWtlA8TPtdrfZ5C7fC D5ELv7YeRYgYLPyMH2ZJV+9zuFFThLw7A5GafU8oSotizkHTDCR54R53LHeFECon HBXxZG6q5m6tj68TmQQPknMHozZtgFQk4RAdo52UTEpRVO9noNI8FUdVHjeFcYFW EUtIWn1j6gSy0CBUke8poyYtS9RUzZ5AKReejcXDKFza9oHpGmMjFzFGTR15cJLz nNe3N6RiajP74Rf6oeSv7me14Pi8ro/3f4r7yuv168XRv7tkZiU1B5dU2vynUCeH DB8cyf54P/mlymR3oCXEYnToaAF/vfgb9roi+M7U4N5+l3iTLe/RjPfITGFyN8VP 36BOx8VKeyZbCA/sxu5K1IFNIcG9HqEh3Zps0MusBXWaysie3dmBOh+z35aEWjEp cj1/4xHNbH6FA4KXD7QzHuYWtN7R+D918Ik3CYCZCQ897rgFGIUgNHRYixlITIRW ri21xEi12ztmP+EEAmG13AHuoN0tQOo0NOtMJm2K67S7IKhSIZJNKGSPVCF5bFm2 Kb+AYrr/l3CXwcvPOwWn =aDx+ -END PGP SIGNATURE- Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1uauwl-0007wh...@franck.debian.org
Bug#707750: libreadline-gplv2-dev: arch-dependent file in Multi-Arch: same package
Package: libreadline-gplv2-dev Version: 5.2+dfsg-2 User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch (This is similar #658850, but the scope is much narrower, thus severity is different.) libreadline-gplv2-dev is marked as Multi-Arch: same, but the following file is architecture-dependent: /usr/share/doc/libreadline5/examples/Makefile MD5 sums of the file in question: e33b87dd84e70cd693653c2b189d8938 s390 s390x c303c0dc61bd38a0da565bfb235e4795 elsewhere An example diff between i386 and s390 is attached. -- Jakub Wilk diff -ur libreadline-gplv2-dev_5.2+dfsg-2_i386/usr/share/doc/libreadline5/examples/Makefile libreadline-gplv2-dev_5.2+dfsg-2_s390/usr/share/doc/libreadline5/examples/Makefile --- libreadline-gplv2-dev_5.2+dfsg-2_i386/usr/share/doc/libreadline5/examples/Makefile 2013-04-27 18:57:22.0 +0200 +++ libreadline-gplv2-dev_5.2+dfsg-2_s390/usr/share/doc/libreadline5/examples/Makefile 2013-04-27 19:00:54.0 +0200 @@ -32,7 +32,7 @@ DEFS = -DHAVE_CONFIG_H CC = gcc CFLAGS = -g -O -LOCAL_CFLAGS = -DREADLINE_LIBRARY -DRL_LIBRARY_VERSION='$(RL_LIBRARY_VERSION)' +LOCAL_CFLAGS = -fsigned-char -DREADLINE_LIBRARY -DRL_LIBRARY_VERSION='$(RL_LIBRARY_VERSION)' CPPFLAGS = INCLUDES = -I$(srcdir) -I$(top_srcdir) -I..
PTS: RC bugs in dependencies
Hi Neil, Paul, other interested readers, Neil suggested in http://lists.debian.org/debian-devel/2013/05/msg00424.html to add RC bugs in dependencies on the PTS, and Paul contacted me via private e-mail to have a look at this. We've discussed a few aspects via private e-mail, but I think we can better discuss them in public on debian-qa. I'm not repeating all thoughts we shared via private e-mail, but I'm jumping right to an experiment I just did. I started from RC bugs (grave, critical, serious) tagged help. We currently have 18 RC bugs tagged help. I matches these 18 bugs with all reverse dependencies, recursively, both build- and plain reverse dependencies. Recommends and Suggests are not followed. The result is 19475 PTS pages. If I stop the recursion after the bug is advertised on more than 150 PTS pages and skip packages with more than 150 reverse dependencies, then the result is 660 PTS pages, which feels more reasonable to me. The number 150 is chosen with trial and error to reach some reasonable ratio 18/660. This is just a first experiment, and I'm sure the number 150 needs changing when other RC bugs are tagged help. The result is here : http://qa.debian.org/~bartm/depneedshelp/depneedshelp.txt The PTS could be modified to display a message like There are RC bugs in dependencies : #nn, #mm, # For example, on the PTS page of kaya this message would be: There are RC bugs in dependencies : #579647 #545414 #658739 #566351 #368297 #601667 #658896 #628671 Obviously each bug number would have a direct link to the bts page. Comments ? Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510060332.ga3...@master.debian.org
Re: PTS: RC bugs in dependencies
On Fri, May 10, 2013 at 2:03 PM, Bart Martens wrote: I started from RC bugs (grave, critical, serious) tagged help. We currently have 18 RC bugs tagged help. I matches these 18 bugs with all reverse dependencies, recursively, both build- and plain reverse dependencies. Recommends and Suggests are not followed. The result is 19475 PTS pages. If I stop the recursion after the bug is advertised on more than 150 PTS pages and skip packages with more than 150 reverse dependencies, then the result is 660 PTS pages, which feels more reasonable to me. The number 150 is chosen with trial and error to reach some reasonable ratio 18/660. This is just a first experiment, and I'm sure the number 150 needs changing when other RC bugs are tagged help. Thanks for investigating this. I think the approach you have chosen is a good first step and I would like to add it to the PTS. There are RC bugs in dependencies : #579647 #545414 #658739 #566351 #368297 #601667 #658896 #628671 Several of these bugs are merged, I think we should only link to one of the merged bugs. Comments ? I wonder if doing this recursively is a good idea or not. If we decide to do that, your approach to limit the recursion is a good one. I guess you focused on bugs tagged 'help' so that less maintainers are affected? Is the result very different if you change that to all RC bugs? Perhaps we could use recursion for bugs tagged 'help' and no recursion for RC bugs older than one month. A blacklist may be needed to avoid things like eglibc appearing on all packages containing ELF binaries though. It is my feeling that bugs tagged 'help', especially in core packages, are probably ones that are harder to fix and may not be good targets for getting people who aren't intimately familiar with the packages to fix them. I think perhaps that limiting the amount of RC bugs filed against deps to 5 or 10 per PTS page would be good. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6FNR4YuZczzDNYJq1=1cb0wxvpxgysgxnwm9sav+de...@mail.gmail.com
Re: PTS: RC bugs in dependencies
Hi, On Fri, 10 May 2013, Paul Wise wrote: Comments ? I wonder if doing this recursively is a good idea or not. If we decide to do that, your approach to limit the recursion is a good one. I also tend to think that doing it recursively is not a good idea in general. Or maybe only for packages which are not widely used and are at risk of getting removed. I guess you focused on bugs tagged 'help' so that less maintainers are affected? Is the result very different if you change that to all RC bugs? Perhaps we could use recursion for bugs tagged 'help' and no recursion for RC bugs older than one month. A blacklist may be needed to avoid things like eglibc appearing on all packages containing ELF binaries though. Increasing the visibility of bugs tagged help is a good idea and thus using recursion in this specific case is probably ok. I would also suggest not displaying bugs where someone is actively taking care of it (i.e. when a owner is set even though it's not often used). I would also suggest to completely ignore RC bugs in package with lots of reverse dependencies, that is until they are tagged help or are getting really old. It is my feeling that bugs tagged 'help', especially in core packages, are probably ones that are harder to fix and may not be good targets for getting people who aren't intimately familiar with the packages to fix them. I don't think that it's worth trying to filter those at this point. I think perhaps that limiting the amount of RC bugs filed against deps to 5 or 10 per PTS page would be good. While I understand the logic too much and it's going to be useless/ignored, I don't agree that we must put a hard limit. We might have to tweak our rules to avoid too many such cases but then once we have something it should be understandable and relatively complete. Or we must be able to provide a link to get the full list of RC bugs affecting (recursive) dependencies. BTW, I would love if the PTS would make it easier to contact all maintainers of reverse dependencies. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510080357.gb16...@x230-buxy.home.ouaza.com
Re: PTS: RC bugs in dependencies
On Fri, May 10, 2013 at 02:24:56PM +0800, Paul Wise wrote: I started from RC bugs (grave, critical, serious) tagged help. We currently have 18 RC bugs tagged help. I matches these 18 bugs with all reverse dependencies, recursively, both build- and plain reverse dependencies. Thanks for doing this work, Bart! Comments ? I wonder if doing this recursively is a good idea or not. If we decide to do that, your approach to limit the recursion is a good one. AOL on the fact that doing it recursively is _not_ a good idea. My main argument for it is that direct dependencies are those that the maintainers took the time to explicitly add (either manually, or by delegating that choice to some helper tool that fills in substvars). As such, those dependencies are those that are most likely to be meaningful to the package maintainer. And of course there is the bloat risk, that could diminish the usefulness of this check. Other than that, it sounds like a very good idea to me too. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Call for help: archive rebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Lucas, On 05/09/2013 06:32 AM, Lucas Nussbaum wrote: Hi, I'm unlikely to be able to do much archive rebuild work in the coming year, so I would welcome help on that front. Here is the job description: - maintain scripts to organize archive rebuilds, parse logs and file bugs Required skills: basic Ruby knowledge (or willingness to learn) scripts are in http://anonscm.debian.org/gitweb/?p=collab-qa/cloud-scripts.git and http://anonscm.debian.org/viewvc/collab-qa/collab-qa-tools/ - do the archive rebuilds themselves on Amazon Web Services Required skills: basic AWS knowledge (or willingness to learn) - process results and file bugs (there are scripts that allow to automate most of the process). Required skills: good understanding of FTBFS bugs (common causes for failure, etc), and of the BTS - answer to questions from maintainers Overall, one important skill is the ability to dedicate time to this task on a regular basis (on average, approx. 3 hours every 3 weeks). The task covers normal archive rebuilds (rebuilding all packages, including source and arch:all, from source), but also custom rebuilds (new GCC/python/eglibc/... releases, clang), and possibly QA-specific targets (double-builds, non-minimal chroots, etc.) I want to help with this, sounds fun. Right now I'm finishing my NM and I'm so excited to start help really. I'm really interested in joining the QA team. BTW the only skill that I fit, is that I have some spare time for spend in this and I have the willingness to learn :) - -- TiN -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGM4iUACgkQ1ZuGLdlHDIG6mgCfSvsTmixFwNLJ8Waz6t9DzWLh pFkAoKkuzyPgmTab2ojKmlyln+R2C1No =EeTh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518ce22c.6040...@aayy.com.ar
Re: PTS: RC bugs in dependencies
On Fri, May 10, 2013 at 10:51:08AM +0200, Stefano Zacchiroli wrote: On Fri, May 10, 2013 at 02:24:56PM +0800, Paul Wise wrote: I wonder if doing this recursively is a good idea or not. If we decide to do that, your approach to limit the recursion is a good one. AOL on the fact that doing it recursively is _not_ a good idea. My main argument for it is that direct dependencies are those that the maintainers took the time to explicitly add (either manually, or by delegating that choice to some helper tool that fills in substvars). As such, those dependencies are those that are most likely to be meaningful to the package maintainer. This argument makes sense to me. The recursion comes from my reasoning after Neil explained that entire packages trees were removed due to to RC bugs. Your argument makes me realize that a solution can be found at the first level of reverse dependencies by replacing the RC buggy package with an alternative, so then there's no need to advertise the RC bug all the way recursively. And of course there is the bloat risk, that could diminish the usefulness of this check. True, and I had this in mind from the start. I don't want to flood all PTS pages with the same RC bug numbers. That would only cause irritation. Other than that, it sounds like a very good idea to me too. The idea is Neil's, and Paul brought it to my attention. OK, I'll continue my experiment without the recursion, and see where it leads. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510123132.ga13...@master.debian.org
Re: PTS: RC bugs in dependencies
On Fri, May 10, 2013 at 02:24:56PM +0800, Paul Wise wrote: On Fri, May 10, 2013 at 2:03 PM, Bart Martens wrote: There are RC bugs in dependencies : #579647 #545414 #658739 #566351 #368297 #601667 #658896 #628671 Several of these bugs are merged, I think we should only link to one of the merged bugs. Good point. I have now modified the script accordingly. I wonder if doing this recursively is a good idea or not. If we decide to do that, your approach to limit the recursion is a good one. Limiting the recursion is a compromise. Zack convinced me to drop the recursion (at least for now). I guess you focused on bugs tagged 'help' so that less maintainers are affected? To start with a small sample. Also, I think that some RC bugs are easy to fix, so don't need advertising on so many PTS pages. For example, some FTBFS bugs can be quite easy to fix. Now, where to draw the line. Bugs tagged help are bugs for which the package maintainer explicitly asks for help, so there's an objective reason to advertise them on reverse dependencies PTS pages. Is the result very different if you change that to all RC bugs? To my surprise the ratio for all RC bugs is also quite reasonable : - with tag help : 12/312 http://qa.debian.org/~bartm/depneedshelp/depneedshelp_tagged_help.txt - all RC bugs : 1133/12298 http://qa.debian.org/~bartm/depneedshelp/depneedshelp_all_rc.txt I've kept the number 150 at that for now, and I've not yet tried sufficient other numbers to draw conclusions on that. Perhaps we could use recursion for bugs tagged 'help' and no recursion for RC bugs older than one month. I would rather choose the reverse : to advertise older bugs on more PTS pages, since these are bugs that are apparently difficult to fix by the people already looking at them. Why would you advertise older bugs on less PTS pages ? A blacklist may be needed to avoid things like eglibc appearing on all packages containing ELF binaries though. If somehow possible I would prefer to not introduce a blacklist, because it needs maintenance by someone judging which packages to put on the list. An algorithm like I'm using now with that number 150 feels more dynamic to me, as packages can fall in/out the selection over time without human intervention. It is my feeling that bugs tagged 'help', especially in core packages, are probably ones that are harder to fix I agree with that. and may not be good targets for getting people who aren't intimately familiar with the packages to fix them. This is somewhat the same argument as Zack's against using recursion. I guess the package maintainers of one level of reverse dependency should be sufficiently familiar with the RC buggy packages to give fixing the RC bugs a try. I think perhaps that limiting the amount of RC bugs filed against deps to 5 or 10 per PTS page would be good. That's a limitation I hadn't thought of yet. Maybe it's not a problem. I see just libreoffice and meta-gnome3 with slightly more bugs than 10. http://qa.debian.org/~bartm/depneedshelp/depneedshelp_all_rc.txt Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510130357.gb13...@master.debian.org
Re: PTS: RC bugs in dependencies
On Fri, May 10, 2013 at 9:03 PM, Bart Martens wrote: To start with a small sample. Also, I think that some RC bugs are easy to fix, so don't need advertising on so many PTS pages. For example, some FTBFS bugs can be quite easy to fix. Now, where to draw the line. Bugs tagged help are bugs for which the package maintainer explicitly asks for help, so there's an objective reason to advertise them on reverse dependencies PTS pages. Agreed. I would rather choose the reverse : to advertise older bugs on more PTS pages, since these are bugs that are apparently difficult to fix by the people already looking at them. Why would you advertise older bugs on less PTS pages ? My message wasn't clear, I meant: help bugs: advertise, recursive older bugs: advertise newer bugs: don't advertise The newer bugs are ones that the maintainers may still be working on fixing. Since you've dropped the recursion, my suggestion would be to just advertise help bugs and older bugs. That's a limitation I hadn't thought of yet. Maybe it's not a problem. I see just libreoffice and meta-gnome3 with slightly more bugs than 10. http://qa.debian.org/~bartm/depneedshelp/depneedshelp_all_rc.txt Hmm, ok. Perhaps it isn't something to worry about then, at least for now. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6EFGiDXgg-DXZC22Dt_2W3yTK=alyocvymzvf0f2r6...@mail.gmail.com
Re: PTS: RC bugs in dependencies
On Fri, May 10, 2013 at 10:03:57AM +0200, Raphael Hertzog wrote: On Fri, 10 May 2013, Paul Wise wrote: I wonder if doing this recursively is a good idea or not. If we decide to do that, your approach to limit the recursion is a good one. I also tend to think that doing it recursively is not a good idea in general. Or maybe only for packages which are not widely used Not widely used could be measured with popcon. I'll keep this in mind. But I think that RC bugs in more popular packages deserve to be displayed on more PTS pages, not the opposite. and are at risk of getting removed. How to measure that ? Anyhow, I've switched off the recursion for now, based on Zack's argument. I would also suggest not displaying bugs where someone is actively taking care of it (i.e. when a owner is set even though it's not often used). Creative idea, but I'm afraid that setting the owner is not a sufficiently common practice to base this on. I would also suggest to completely ignore RC bugs in package with lots of reverse dependencies, that is until they are tagged help or are getting really old. I'm not sure about this. Somehow I think that RC bugs in packages with many reverse dependencies are more important than other. I think perhaps that limiting the amount of RC bugs filed against deps to 5 or 10 per PTS page would be good. While I understand the logic too much and it's going to be useless/ignored, I don't agree that we must put a hard limit. We might have to tweak our rules to avoid too many such cases but then once we have something it should be understandable and relatively complete. I agree with trying to avoid such hard limit. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510132349.gc13...@master.debian.org
Re: PTS: RC bugs in dependencies
On Fri, 10 May 2013, Bart Martens wrote: I would also suggest not displaying bugs where someone is actively taking care of it (i.e. when a owner is set even though it's not often used). Creative idea, but I'm afraid that setting the owner is not a sufficiently common practice to base this on. Yes, but it would provide a way to not display some bugs that take long to fix (think license issues). So even if uncommon, it can be useful. I would also suggest to completely ignore RC bugs in package with lots of reverse dependencies, that is until they are tagged help or are getting really old. I'm not sure about this. Somehow I think that RC bugs in packages with many reverse dependencies are more important than other. They are but they are also more likely to have an active maintainer. On the other hand, packages with few reverse dependencies are more likely to have an MIA maintainer without anyone noticing. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510133505.gb32...@x230-buxy.home.ouaza.com
