Re: FYI: QA uploads primer
On Mon, Jun 15, 2009 at 00:49, Serafeim Zanikolasser...@hellug.gr wrote: Hi, Those interested in packaging, but not certain about making a long-term commitment might be interested in a practical primer for QA uploads: http://wiki.debian.org/QAUploadsPrimer (A QA upload is a one-off maintenance act of an orphaned package (as opposed to an upload that declares one's adoption of the package)) 1. QA uploads are nothing different from a normal upload except for the Maintainer field; does it worth a full wiki page? A paragraph in some other QA page would be enough 2. read or skim through the table of contents of the Debian new maintainer's guide (so that you know where to lookup things you might need) ??? policy and devref are just a waste of time? this is a wrong suggestion (without mentioning the other 2 docs). 3. an orphaned package has its Maintainer set to Debian QA Group packa...@qa.debian.org what for those that are orphaned but never received a QA upload? qa.debian.org/orphaned.html to have such list 4. it's NOT okay to edit any upstream file; for that, you'll have to use a patch management system (such as quilt [2]) too strong requirement IMO. if an orphaned package already does direct upstream code changes, might be ok to keep doing them in the qa upload. 5. the first entry in debian changelog should be QA upload dch does the right thing without specify anythinh (just update maintainer field first to QA if it's not yet) 6. if the package is team-maintained (see the Maintainer field in debian/control, you might have to commit your changes to the team's repository; but this shouldn't be the case because we said that you'd work on an orphaned package ) so why mention it?? this is wrong. It's orphaned, no need to commit anythin to the ex-team. 7. repeat steps 3-4 there are no numbers in your doc. 8. check that your newly-built .deb installs, uninstalls, and re-installs without problems (you did choose a non-critical package, so this should be okay even if your package is horribly broken) what?? 9. if you have modified the package's dependencies, use pbuilder to confirm that the package builds successfully USE PBUILDER IN ANY CASE BEFORE UPLOAD TO MENTORS!!! In definitive, this is a complete waste of time: if you know how to package, this page is useless, if you don't, this page drive to the wrong direction. Please either: 1. fix it 2. merge with an already existing QA page (a small paragraph in hte main wiki QA page would be enough) 3. remove it. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: mupen64plus
[Sven Eckelmann, 2009-06-14] On Sun, 14 Jun 2009 05:13:31 -0700 Piotr Ożarowski wrote: * can you do with lzma something similar to you did with bz2 and zlib? No, not at the moment. The lzma-dev doesn't provide a shared object. I changed it now to link against the static libraries from lzma-dev instead of the LzmaDecode-stuff in ./main/7zip/. The ./main/lzma/ stuff cannot be changed because it is taken from libxz (as it was called liblzma). This isn't packaged in debian yet. See #518803 and #532501 for more informations. ok, you forgot to disable 111-system-unlzma.patch, though Why should I do that? You asked me to change it in a way that it uses shared objects from debian. This cannot be done because there is no shared object in lzma*. This means that I changed it to do a static link against libunlzma as much as possible as I wrote before. Can you please write something more specific about your intention? I don't see a good reason to disable that patch right now. Maybe there is a little bit confusion about lzma/lzma-dev/liblzma/libxz/7z. when 111-system-unlzma.patch is enabled, I'm getting segmentation fault every time I try to start the emulator with .7z roms. -- http://people.debian.org/~piotr/sponsor -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: mupen64plus tinc-interface
On Mon, 15 Jun 2009 00:33:01 -0700 Piotr Ożarowski wrote: a good reason to disable that patch right now. Maybe there is a little bit confusion about lzma/lzma-dev/liblzma/libxz/7z. when 111-system-unlzma.patch is enabled, I'm getting segmentation fault every time I try to start the emulator with .7z roms. Thanks, have removed it for now and reuploaded it. Maybe I can get upstream to change to libxz in an upcoming release. Maybe xz-utils are released and packaged until then Best regards, Sven signature.asc Description: This is a digitally signed message part.
Re: RFS: qutecsound (2nd try)
Hello, On Sun, Jun 14, 2009 at 14:29, Felipe Satelerfsate...@gmail.com wrote: El domingo 14 de junio, LI Daobing escribió: Hello, On Sun, Jun 14, 2009 at 11:37, Felipe Satelerfsate...@gmail.com wrote: El sábado 13 de junio, LI Daobing escribió: Hello, On Sat, Jun 13, 2009 at 16:15, LI Daobinglidaob...@debian.org wrote: Hello, On Sat, Jun 13, 2009 at 11:58, Felipe Satelerfsate...@gmail.com wrote: This package has been updated, it now sets the default html for the csound ^path manual currently in NEW. I am looking for a sponsor for my package qutecsound. * Package name : qutecsound Version : 0.4.1-1 Upstream Author : Andrés Cabrera mantaray...@gmail.com * URL : http://sourceforge.net/projects/qutecsound * License : LGPL-2.1 Section : sound It builds these binary packages: qutecsound - frontend for the csound sound processor The package appears to be lintian clean. The upload would fix these bugs: 511631 QuteCsound is a simple cross platform editor and front-end for Csound with syntax highlighting, interactive help and automatic launching of Csound. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qutecsound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qutecsound/qutecsound_0. 4-1 .dsc I would be glad if someone uploaded this package for me. Ping? This application is very important for csound users, because it provides a great frontend for it. I'll take a look. failed to build from source. build log in attachment. This failure is caused by using gcc 4.4 instead of 4.3. Upstream knew about it already, so I took the patch from their svn. Please see an updated package in mentors. comments: 1. E: qutecsound: menu-icon-too-big /usr/share/pixmaps/qtcs.xpm: 128x128 32x32 Duh, I forgot to change the .install file when I created the smaller icon. 2. debian/copyright: following paragraph is incorrect: On Debian systems, the complete text of the GNU General Public License version 3 can be found in `/usr/share/common-licenses/LGPL-2.1'. Fixed as well. New package uploaded to mentors. uploaded. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: kabikaboo
Hi Debian, I am looking to add my little program into Debian. It is a simple, but unique, text editor. I created it to help people write novels. I am a little overwhelmed by this big Debian ecosystem but eager to learn. Here are the package details: 1. Name: kabikaboo 2. License: GNU GPL v3 3. Short Description: Kabikaboo - Recursive Writing Assistant 3. Long Description: Kabikaboo is a simple tree branching text organizer. It is meant to be used to help aid in the writing of novels or other large documents. A recursive viewing feature allows one to see any section of the tree. You can see an overview of all the children or grandchildren of any given node in the tree, for reference. Each text node can have any arrangement of children, and the nodes can be moved around freely. A tabbed notebook allows users to keep track of the most recently opened nodes, easing movement within a large tree. 4. Where: Homepage = https://launchpad.net/kabikaboo Packages = https://launchpad.net/kabikaboo/+download There is also a branch containing packaging files. The code is small, only a few py files. I also just uploaded i386 and amd64 packages using dupload. 5. Language: Python 6. Dependencies: python, python-gtk2, python-gtksourceview2 7. Author: David Kerr 8. Version: 1.1 Why it should be in Debian: there are ~ a hundred text editors, but none of them are like this, at least not that I know of. I personally couldn't write my novel without it - that's why I made it! :) cheers Dave PS. I hope everything is in order here, but if not, please let me know what to fix. I'm totally new at this... -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: kabikaboo
Hi, Why it should be in Debian: there are ~ a hundred text editors, but none of them are like this, at least not that I know of. I personally couldn't write my novel without it - that's why I made it! :) cheers Dave PS. I hope everything is in order here, but if not, please let me know what to fix. I'm totally new at this... Interesting thoughtful presentation, which doesn't mean I'm ready to sponsor, but to look at it and give some comments you can start with: You should always run lintian over your package. It is very good at explaining what made it unhappy and generally gives good pointers how to fix these. If you are in doubt how to properly fix these warnings and errors, you can always ask again here. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: mupen64plus
uploaded -- http://people.debian.org/~piotr/sponsor signature.asc Description: Digital signature
Re: RFS: kabikaboo (lintian)
Hi George, thanks for the help. I fixed these: W: kabikaboo: readme-debian-contains-debmake-template W: kabikaboo: copyright-lists-upstream-authors-with-dh_make-boilerplate W: kabikaboo: copyright-contains-dh_make-todo-boilerplate E: kabikaboo: description-starts-with-package-name W: kabikaboo: extended-description-line-too-long W: kabikaboo: unknown-section office Replaced office with text. I am going to have to figure this manpage one out, but I think I can do it on my own: W: kabikaboo: binary-without-manpage usr/bin/kabikaboo However I am unsure how to fix these two: W: kabikaboo: new-package-should-close-itp-bug W: kabikaboo: wrong-bug-number-in-closes l3:# Could you give me some guidance on new-package-should-close-itp-bug and wrong-bug-number-in-closes l3:#? I read the documentation but I'm unclear if I can submit a bug against my package if the package isn't submitted yet... seems like a catch 22 to me! thanks, Dave Kerr George Danchev wrote: Hi, Interesting thoughtful presentation, which doesn't mean I'm ready to sponsor, but to look at it and give some comments you can start with: You should always run lintian over your package. It is very good at explaining what made it unhappy and generally gives good pointers how to fix these. If you are in doubt how to properly fix these warnings and errors, you can always ask again here. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: kabikaboo (lintian)
On Mon, Jun 15, 2009 at 12:45 PM, Dave Kerraid...@shaw.ca wrote: However I am unsure how to fix these two: W: kabikaboo: new-package-should-close-itp-bug W: kabikaboo: wrong-bug-number-in-closes l3:# Could you give me some guidance on new-package-should-close-itp-bug and wrong-bug-number-in-closes l3:#? I read the documentation but I'm unclear if I can submit a bug against my package if the package isn't submitted yet... seems like a catch 22 to me! You file the ITP against the pseudopackage wnpp, not your own package. If you reportbug wnpp it will guide you through the steps pretty well, this is also documented at http://www.debian.org/devel/wnpp/ Regards, Daniel -- Daniel Moerner dmoer...@gmail.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: kabikaboo (lintian)
Hi Dave On Mon, Jun 15, 2009 at 01:45:08PM -0600, Dave Kerr wrote: Could you give me some guidance on new-package-should-close-itp-bug and wrong-bug-number-in-closes l3:#? I read the documentation but I'm unclear if I can submit a bug against my package if the package isn't submitted yet... seems like a catch 22 to me! It says, you diden't (Close #bugnumber_for_itp) use in your debian/changelog. Did you filled allrady a ITP (= Intend To Package= for your package kabikaboo? See [1]. [1] http://www.debian.org/doc/developers-reference/pkgs.html#newpackage You should fill such an ITP for the package, and then close the Bug appropriately in debian/changelog. Does this helps you? Kind regards Salvatore signature.asc Description: Digital signature
RFS: partlibrary (QA Upload)
Dear mentors, I am looking for a sponsor for the new version 2.1.2.8-1-1 of the package partlibrary. It is orphaned and I don't intend to adopt it. Because of the relatively high popcon I've prepared a QA upload with the current upstream version. It builds these binary packages: partlibrary - Electrical and processing parts and symbols for QCad 2 The package appears to be lintian clean. The upload would fix these bugs: 434778 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/partlibrary - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/partlibrary/partlibrary_2.1.2.8-1-1.dsc I would be glad if someone uploaded this package for me (or rather for QA :)). Cheers, Hauke signature.asc Description: Digital signature
Re: RFS: partlibrary (QA Upload)
Hi, On Mon, Jun 15, 2009 at 1:00 PM, Jan Hauke Rahmi...@jhr-online.de wrote: The package appears to be lintian clean. You could still add a watch file, and it would also be trivial to fix at least one of the pedantic warnings here by adding the Homepage field in debian/control. By the way, here's a working watch file: version=3 http://www.ribbonsoft.com/qcad_downloads.html \ ftp://anonymous:anonym...@ribbonsoft.com/archives/partlibrary/partlibrary-(.*)\.tar\.gz I think you need to be more verbose in debian/changelog, you seemed to completely rework the structure of the source package as well as the build system (it used to use separate dh_* calls and pack the upstream zip inside the .orig.tar.gz, now you unpack the upstream source directly and use dh 7). I think this is the correct choice but it needs to be documented. IANADD so I can't sponsor your package, but it looks like a perfect candidate for a QA upload. Regards, Daniel -- Daniel Moerner dmoer...@gmail.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: libslf4j-java (updated package)
Dear mentors and java maintainers, I am looking for a sponsor for the new version 1.5.8-1 of package libslf4j-java. It builds these binary packages: libslf4j-java - Simple Logging Facade for Java The package is lintian clean. The package can be found on mentors.debian.net: - http://mentors.debian.net/debian/pool/main/l/libslf4j-java/libslf4j- java_1.5.8-1.dsc or on pkg-java team SVN Repository: - svn+ssh://svn.debian.org/svn/pkg-java/trunk/libslf4j-java I would be glad if someone uploaded this package for me. Regards, -- Damien Raude-Morvan / www.drazzib.com signature.asc Description: This is a digitally signed message part.
Re: RFS: iulib (2nd attempt)
2009/6/13 Boyd Stephen Smith Jr. b...@iguanasuicide.net: The (unversioned, build-time use only) symlink libiulib.so - libiulib.so.0.0.0 needs to be in libiulib-dev package. The (major- versioned) symlink libiulib.so.0 - libiulib.so.0.0.0 needs to be in the libuilib0 package. Thanks for this. I have now uploaded the package to mentors. It has a shared library and is lintian-clean. I would appreciate someone taking a look. Note that this is 0.3. v0.4 has been available for a couple of days, but at the moment ./configure doesn't run as upstream hasn't included a Makefile.in. Therefore I am suggesting uploading 0.3. Regards Jeff -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: partlibrary (QA Upload) [updated]
Hi Daniel, On Mon, Jun 15, 2009 at 01:21:36PM -0700, Daniel Moerner wrote: You could still add a watch file, and it would also be trivial to fix at least one of the pedantic warnings here by adding the Homepage field in debian/control. You're absolutely right. I was working on a different package at the same time and confused what I had done. Shouldn't have happened... :-/ I think you need to be more verbose in debian/changelog, you seemed to completely rework the structure of the source package as well as the build system (it used to use separate dh_* calls and pack the upstream zip inside the .orig.tar.gz, now you unpack the upstream source directly and use dh 7). I think this is the correct choice but it needs to be documented. Right, same reason. I've uploaded the updated package with the same version to mentors.d.n to not confuse other QA workers with entries in changelog that were never uploaded. Thanks for the review, Daniel. Hauke signature.asc Description: Digital signature
Re: RFS: libslf4j-java (updated package)
Hi Damien, On Mon, Jun 15, 2009 at 10:45 PM, Damien Raude-Morvandraz...@drazzib.com wrote: I am looking for a sponsor for the new version 1.5.8-1 of package libslf4j-java. unfortunately java-gcj-compat-dev is still broken: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532065. Someone needs to fix this bug. Cheers, Torsten -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libslf4j-java (updated package)
Le lundi 15 juin 2009 22:54:33, Torsten Werner a écrit : Hi Damien, Hi Torsten, On Mon, Jun 15, 2009 at 10:45 PM, Damien Raude-Morvandraz...@drazzib.com wrote: I am looking for a sponsor for the new version 1.5.8-1 of package libslf4j-java. unfortunately java-gcj-compat-dev is still broken: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532065. Someone needs to fix this bug. Someone needs to fix this bug should be understood as Someone may NMU this real-soon-now if Uploaders don't take action, isn't it ? IMO, we should add a Depends on gcj-4.3 but maybe doko (Matthias) have different views on this. In any case, he should comment this issue before someone NMU this. Concerning my RFS, should we stop uploading new packages revisions until some fix java-gcj-compat-dev ? Cheers, -- Damien Raude-Morvan / www.drazzib.com PS: no need to CC me, I'm suscribed to -java -mentors signature.asc Description: This is a digitally signed message part.
Re: FYI: QA uploads primer
Thanks for the feedback Sandro. I've written the primer for technical-minded debian users that (a) want to contribute to debian, but are uncertain about their long-term time-commitment; and (b) given their uncertain commitment, won't read the whole policy, devref, and newmaint guide just for the sake of trying out the water. Of course anyone seriously interested in packaging should eventually read all 3 docs, but it helps if there's a shorter cheatsheet (with appropriate pointers) to get started. On Mon, Jun 15, 2009 at 08:33:57AM +0200, Sandro Tosi wrote [edited]: 1. QA uploads are nothing different from a normal upload except for the Maintainer field; does it worth a full wiki page? A paragraph in some other QA page would be enough Technically yes, but they are different in terms of expected time-commitment from the person preparing the upload. For that reason alone, it's worth having a guide for potential not-yet-committed contributors. 2. read or skim through the table of contents of the Debian new maintainer's guide (so that you know where to lookup things you might need) ??? policy and devref are just a waste of time? this is a wrong suggestion (without mentioning the other 2 docs). The debian developer's guide is mentioned two bullets below the one you cite. I've added after that: * eventually you must also become familiar with the debian policy (but for now you might get away with using lintian, described below) Bear in mind that the point of the primer is to get people started asap, instead of discourage them by saying ``we don't want to even hear from you until you finish these 3 long docs'' And frankly, I think that lintian does a very good job at catching most policy violations, so until one gets serious enough about packaging to actually read the whole policy, we should at least make sure that they use lintian. 3. an orphaned package has its Maintainer set to Debian QA Group packa...@qa.debian.org what for those that are orphaned but never received a QA upload? qa.debian.org/orphaned.html to have such list adapted phrasing and added the above url at the next bullet 4. it's NOT okay to edit any upstream file; for that, you'll have to use a patch management system (such as quilt [2]) too strong requirement IMO. if an orphaned package already does direct upstream code changes, might be ok to keep doing them in the qa upload. I've made the statement milder (added typically), feel free to edit more yourself 5. the first entry in debian changelog should be QA upload dch does the right thing without specify anythinh (just update maintainer field first to QA if it's not yet) fixed 6. if the package is team-maintained (see the Maintainer field in debian/control, you might have to commit your changes to the team's repository; but this shouldn't be the case because we said that you'd work on an orphaned package ) so why mention it?? this is wrong. It's orphaned, no need to commit anythin to the ex-team. removed 7. repeat steps 3-4 there are no numbers in your doc. fixed 8. check that your newly-built .deb installs, uninstalls, and re-installs without problems (you did choose a non-critical package, so this should be okay even if your package is horribly broken) what?? never mind, removed the stuff in parens 9. if you have modified the package's dependencies, use pbuilder to confirm that the package builds successfully USE PBUILDER IN ANY CASE BEFORE UPLOAD TO MENTORS!!! fixed btw I've added a link to the QA wiki from DebianDevelopment (it seemed completely isolated from the rest of the wiki) Cheers, Serafeim -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: libspring-2.5-java
Dear mentors and java maintainers, I am looking for a sponsor for my package libspring-2.5-java. * Package name: libspring-2.5-java Version : 2.5.6.SEC01-1 Upstream Author : SpringSource Inc. * URL : http://www.springsource.org/ * License : Apache 2.0 Section : java It builds these binary packages: libspring-aop-2.5-java - modular Java/J2EE application framework - AOP libspring-beans-2.5-java - modular Java/J2EE application framework - Beans libspring-context-2.5-java - modular Java/J2EE application framework - Context libspring-context-support-2.5-java - modular Java/J2EE application framework - Context Support libspring-core-2.5-java - modular Java/J2EE application framework - Core libspring-jdbc-2.5-java - modular Java/J2EE application framework - JDBC tools libspring-jms-2.5-java - modular Java/J2EE application framework - JMS tools libspring-orm-2.5-java - modular Java/J2EE application framework - ORM tools libspring-test-2.5-java - modular Java/J2EE application framework - Test helpers libspring-tx-2.5-java - modular Java/J2EE application framework - transaction libspring-web-2.5-java - modular Java/J2EE application framework - Web libspring-webmvc-2.5-java - modular Java/J2EE application framework - MVC The package is lintian clean. The package can be found on mentors.debian.net: - http://mentors.debian.net/debian/pool/main/l/libspring-2.5- java/libspring-2.5-java_2.5.6.SEC01-1.dsc I would be glad if someone uploaded this package for me. Torsten, as you already checked previous version of this package could you please ahve a look ? Regards, -- Damien Raude-Morvan / www.drazzib.com signature.asc Description: This is a digitally signed message part.
Re: RFS: libslf4j-java (updated package)
Le lundi 15 juin 2009 23:23:34, Vincent Fourmond a écrit : Hello Damien ! Damien Raude-Morvan wrote: Concerning my RFS, should we stop uploading new packages revisions until some fix java-gcj-compat-dev ? If it FTBS in a chroot, sure enough: uploaders can't build... Pwned! I've re-checked and dependencies problem seems to have vanished. It seems to be linked with upload of gcc-defaults (1.87) [1]: gcj-jre-headless/gcj-jdk: Depend on gij-4.3/gcj-4.3. Closes: #532292. Now we have this (complex) dep. chain : default-jdk-builddep - default-jdk - java-gcj-compat-dev - gcj - gcj-jdk - gcj-4.3 You should check my package in chroot now ;) [1] http://packages.qa.debian.org/g/gcc-defaults/news/20090611T224713Z.html Cheers, -- Damien Raude-Morvan / www.drazzib.com signature.asc Description: This is a digitally signed message part.
Re: FYI: QA uploads primer
On Mon, Jun 15, 2009 at 23:00, Serafeim Zanikolasser...@hellug.gr wrote: Thanks for the feedback Sandro. I've written the primer for technical-minded debian users that (a) want to contribute to debian, but are uncertain about their long-term time-commitment; and (b) given their uncertain commitment, won't read the whole policy, devref, and newmaint guide just for the sake of trying out the water. No, that's again wrong: you can't do a quality work without ready those documents (with this order: policy, devref, NM Guide). This is a false statement you're making and I'm stopping here reading your email. If you want pursuit this road, you'll drive apart potential future contributors because the moment they'll send the RFS and they'll get scolded very heavy due to their lack of basic knowledge, they do really wasted their and our time. Googbye, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FYI: QA uploads primer
On Tue, Jun 16, 2009 at 12:01:30AM +0200, Sandro Tosi wrote: On Mon, Jun 15, 2009 at 23:00, Serafeim Zanikolasser...@hellug.gr wrote: Thanks for the feedback Sandro. I've written the primer for technical-minded debian users that (a) want to contribute to debian, but are uncertain about their long-term time-commitment; and (b) given their uncertain commitment, won't read the whole policy, devref, and newmaint guide just for the sake of trying out the water. No, that's again wrong: you can't do a quality work without ready those documents (with this order: policy, devref, NM Guide). This is a false statement you're making and I'm stopping here reading your email. There's a tradeoff: encouraging potential new contributors (in the hope that they'll eventually read all the docs) at the cost of initially lower-quality RFS requests, or making it clear from the start that packaging is hard and time-consuming and they shouldn't even bother until they've read all 3 docs in full [1] If you want pursuit this road, you'll drive apart potential future contributors because the moment they'll send the RFS and they'll get scolded very heavy due to their lack of basic knowledge, they do really wasted their and our time. The primer repeatedly mentions lintian, which catches most policy violations, and (if you would have read the previous email, you'd know that it) by now also mentions policy as a must in the preparation section ... I honestly don't mind dropping the page, but I haven't been convinced that the issues you raise can't be addressed by adding more references and warning flags in the doc. -S [1] the successor of mentors.d.n, which can easily automatically reject packages with lintian errors, would eliminate this problem -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FYI: QA uploads primer
On Tue, Jun 16, 2009 at 12:53:32AM +0200, Serafeim Zanikolas wrote: On Tue, Jun 16, 2009 at 12:01:30AM +0200, Sandro Tosi wrote: On Mon, Jun 15, 2009 at 23:00, Serafeim Zanikolasser...@hellug.gr wrote: Thanks for the feedback Sandro. I've written the primer for technical-minded debian users that (a) want to contribute to debian, but are uncertain about their long-term time-commitment; and (b) given their uncertain commitment, won't read the whole policy, devref, and newmaint guide just for the sake of trying out the water. No, that's again wrong: you can't do a quality work without ready those documents (with this order: policy, devref, NM Guide). This is a false statement you're making and I'm stopping here reading your email. There's a tradeoff: encouraging potential new contributors (in the hope that they'll eventually read all the docs) at the cost of initially lower-quality RFS requests, or making it clear from the start that packaging is hard and time-consuming and they shouldn't even bother until they've read all 3 docs in full [1] Or you can point people who don't want to learn how to package things properly to QA activities that their limited time and attention span can cope with. Things like just making sure that the bugs on a package are in good order, with well-tested patches and clear comments to that effect, which reduces the time commitment for someone who *does* have the necessary skills to produce a working package. Announcing their work on debian-qa often finds someone to aggregate, test, and make the upload. Anything that encourages people to submit even shoddier RFSes than some of those that already come through here should be derided loudly and publically. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qutecsound (2nd try)
El lunes 15 de junio, LI Daobing escribió: Hello, On Sun, Jun 14, 2009 at 14:29, Felipe Satelerfsate...@gmail.com wrote: El domingo 14 de junio, LI Daobing escribió: Hello, On Sun, Jun 14, 2009 at 11:37, Felipe Satelerfsate...@gmail.com wrote: El sábado 13 de junio, LI Daobing escribió: Hello, On Sat, Jun 13, 2009 at 16:15, LI Daobinglidaob...@debian.org wrote: Hello, On Sat, Jun 13, 2009 at 11:58, Felipe Satelerfsate...@gmail.com wrote: This package has been updated, it now sets the default html for the csound ^path manual currently in NEW. I am looking for a sponsor for my package qutecsound. * Package name: qutecsound Version : 0.4.1-1 Upstream Author : Andrés Cabrera mantaray...@gmail.com * URL : http://sourceforge.net/projects/qutecsound * License : LGPL-2.1 Section : sound It builds these binary packages: qutecsound - frontend for the csound sound processor The package appears to be lintian clean. The upload would fix these bugs: 511631 QuteCsound is a simple cross platform editor and front-end for Csound with syntax highlighting, interactive help and automatic launching of Csound. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qutecsound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qutecsound/qutecsound _0. 4-1 .dsc I would be glad if someone uploaded this package for me. Ping? This application is very important for csound users, because it provides a great frontend for it. I'll take a look. failed to build from source. build log in attachment. This failure is caused by using gcc 4.4 instead of 4.3. Upstream knew about it already, so I took the patch from their svn. Please see an updated package in mentors. comments: 1. E: qutecsound: menu-icon-too-big /usr/share/pixmaps/qtcs.xpm: 128x128 32x32 Duh, I forgot to change the .install file when I created the smaller icon. 2. debian/copyright: following paragraph is incorrect: On Debian systems, the complete text of the GNU General Public License version 3 can be found in `/usr/share/common-licenses/LGPL-2.1'. Fixed as well. New package uploaded to mentors. uploaded. Thanks! Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
