Re: flashcache - call for resolution / seeking for a mentor
On Wed, Sep 21, 2011 at 01:21:00PM +1000, onlyjob wrote: Could someone please kindly have a look at the package I've made (and provide comments)? You didn't fix Vcs-* per Arno comments in the ITP bug. What is This has to be exported to make some magic below work. (before 'export DH_OPTIONS')? You dont need --with quilt and quilt Build-Dep with 3.0 (quilt) and lintian tells you that. If At the moment this version works only on x86_64 a.k.a. amd64 why Architecture: linux-any? Some files under utils/ are 2-BSD and it is useful to document that in debian/copyright. It may be better to convert debian/copyright to http://dep.debian.net/deps/dep5/ format at least in this case. Also, I think Based on DM-Cache: Copyright (C) International Business Machines Corp., 2006 should be reflected in debian/copyright too. The patch lacks author information (did you see http://dep.debian.net/deps/dep3/ ? it suggests adding other useful information to patch headers). The package I need someone to look at is flashcache uploaded to mentors.debian.net The usual practice is to provide at least an URL of .dsc. It's http://mentors.debian.net/debian/pool/main/f/flashcache/flashcache_1.0~20110920132357-1.dsc -- WBR, wRAR signature.asc Description: Digital signature
Re: flashcache - call for resolution / seeking for a mentor
(Note: I didn't have a look at either package; I merely read the preceding discussion in the bug log) From what I've read so far, my impression is that this is not a technical issue, but more a social / team-work... misunderstanding, perhaps. So read my comments below, with these things in mind. onlyjob only...@member.fsf.org writes: So perhaps like many people before me I picked a software which I need as a matter of urgency and packaged it for Debian only to find unhappy maintainer who was doing similar work but (arguably) didn't yet made as much progress. This is called duplication of effort, and while the ITP might not have been kept up to date, progress was being made. How much, I will not judge, as I'm not qualified to do so. Nevertheless, when one wants to package something, the first thing to do, in order to make it smooth and useful, is to see if there's anyone working on it already, and if so, how far they've got. This way, you don't have to start from scratch, and you're not stepping on anyone's toes, either. If all goes well, and most often it does, one can speed up the packaging process by joining the effort, instead of starting a competing one. My bad, I should have find him and coordinate the effort but as a newcomer I'm lacking some understanding of how things suppose to be done and hence I missed the chance to reduce our efforts. That happens at times, indeed. But not to worry! It's never too late to join forces, and get the best of both efforts (preferably without the bugs of either :P). At this point my package is ready for review and as I'm been told, I'm neither suppose to close someone else's ITP nor submit a duplicate one. That is mostly correct. If there's someone already working on a package, it's generally not recommended to hijack and invalidate his efforts. The best practice is to strive for merging both works. Arno offered you the opportunity to do so, and I believe that's the best path to follow, regardless of what the technical state of each of your packages are. He started the work, he filed the ITP, it's pretty much his package at this time. And as you wouldn't want to upload a package managed by someone else, because it happens to have a bug or shortcoming that bothers you, the same treatment should be applied to ITPs aswell. No doubts in the end there should be only one package left. Indeed. It is indeed possible that something can be merged between those two packages. (As a matter of fact, maintainer who first logged an ITP already integrated some pieces of my work into his unfinished package) That's the way forward: merge the good parts from both efforts. By the maintainer of the unfinished package (Arno Töll) I have been told that my only option is to merge with him but not the other way. Does it really matter? In the end, the result should be the same either way: a package with the best parts of both. The question, I believe, is more about why Arno should be doing the merge, and not you. And the reason for that is simple: he started first. That you might have gotten further on your own, doesn't change the fact, that Arno was and still is working on packaging flashcache, and as such, one's not supposed to hijack his package. However there are a few reasons why I don't like the idea of merging with unfinished package at the moment: * Because I'm using the software I packaged, I will have to maintain a working package until a suitable alternative will be available in Debian. That's unfortunate, but if you start working with Arno, helping him in the merging effort instead of complaining and arguing against it, it will go much faster. And in the future, when you wish to contribute, you look for previous, ongoing efforts first, and try to join in, instead of going on your own, then it will be even easier and faster. * Because it might be feasible to merge the other way and having my package a primary one. (In this case there might be less work to do) Since Arno is the owner of the ITP, and by common practice, the maintainer, it's his decision. * Because I'm using fossil http://fossil-scm.org/ (git may be an overkill just for several files) and merging to git will require a substantial effort for me. The other way around would require similar efforts. Arno is willing to merge from you, and already merged a few things from your packaging that his missed, as far as I remember the bug log. For this reason, I support his decision to merge your packaging into his, and not the other way around: because he proved this works, and can bring the packaging effort forward. * Because it seems wrong to made a decision about who should merge with who merely by the ITP announcement date and not by the technical examination. By that reasoning, it's not acceptable to start a competing packaging effort, when one is already in progress, because at the time you started, you had nothing, and Arno had visible
Re: flashcache - call for resolution / seeking for a mentor
On 2011-09-21, onlyjob only...@member.fsf.org wrote: * Is it true that whoever happen to create an ITP first gets the monopoly for packaging? * If ITP always have priority, aren't we sending a wrong message for ambitious maintainers who might be tempted to create ITP early in order to secure the rights for packaging, disregarding of how close they are to providing a usable package? There are ways to take over a ITP, also without consent from the owner of the ITP. But it requires unresponsiveness from the owner and early communication from the one who wants to take it over. In this case, Arno always replied within 1 or 2 days. And you didn't try to communicate before you were actually done. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj7jahk.p7v.nos...@sshway.ssh.pusling.com
mentors.debian.net time in sync?
Hi, When trying to upload packages to mentors.debian.net it fails due to time issue's. It seems like mentors is running behind in time. Or is it just me? Regards, Jeroen Nijhof signature.asc Description: OpenPGP digital signature
Re: mentors.debian.net time in sync?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jeroen, On 21.09.2011 11:22, Jeroen Nijhof wrote: Hi Arno, E: libpam-tacplus: tar-errors-from-data ./lib/security/pam_tacplus.so: time stamp 2011-09-21 08:46:23 is 6411.189313009 s in the future Don't worry, that's Lintian, not a reject. Your package is perfectly reachable to everyone else. Regarding the Lintian error itself, you eventually didn't configure your local time accordingly. Our server runs with a time zone configured to be UTC and tar is supposed to cope with time zones. Yet we had your problem occasionally, but we never found the particular reason, so we expected the packages to /really/ have configured their clocks that way. If you have any other evidence, please let me know. (replied public, as I guess you just hit the wrong button in your MUA) - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOea91AAoJEMcrUe6dgPNtPuMQAMQi5P2GU3N9NR/XI1drHrwu 3iJiwIVSM/ZIIGGIhGYezxB23j6+V+XWkxsRjAmY1Ob4FSvxLmiDy2el5BSRUIbv Mexcz5F1MRtsjs67IO8Q136E6XfOx1TAk7XkTMBd4ym5NsQac53jRVvW85GSDtta eGPhgJLDBy960rPHFsCIpqwO4XmCC0EKRkLEU7tjaSVflIVzCxOhsE2/DV/i6Cjj VOMWKsZVMjmTJ3ClfkcPhWgMYWVoZyz/ycSrDtCAw2EhSee7d1O64V+DfT03zsgW Z3UKF8cQz25ftrsMjyhZxvuZbC+/FqS64p9yAQOWbnIDhyFEWWJbFFq2RmTTU97q HJI1vlKdjpyJ3YQtNdm5+aSczszbtmwChJxB3QQIetpY9AaJfDUHulXhZiwsv9p4 a08ND0y8wv3REJuhY3svSvA326qgKNsqnznWR+3/Ykibd1Mw335O7h1MoJUNGaEN Gt+8UZtnjv0o547SpG9wJgSUYzaTgTtChDUvlv32RaM72Ab58/5NGmJvqJh4qMCg R5N/DlZNCPje4U0DCWxYjXITgY6phYeq3ELa3MCSuvwTEwuG9I0pKTOXxmaSyDXC q3aY8MKTrji+gk4XsDtpQHY2e9iUlZXbNdckjQbpggiGaGgzBsziz9RjdFbzZSkS mD0vFZxBNeOz7XVIZ/72 =b7jt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e79af76.60...@toell.net
Re: mentors.debian.net time in sync?
On Wed, 2011-09-21 at 11:15 +0200, Jeroen Nijhof wrote: Hi, When trying to upload packages to mentors.debian.net it fails due to time issue's. It seems like mentors is running behind in time. Or is it just me? Same message for me: http://mentors.debian.net/package/gnupg-pkcs11-scd Cheers, Fabrizio. signature.asc Description: This is a digitally signed message part
Re: mentors.debian.net time in sync?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21.09.2011 11:39, Fabrizio Regalli wrote: Same message for me: http://mentors.debian.net/package/gnupg-pkcs11-scd I correct myself: Our clock is /supposed/ to run with UTC as local time. Now it really is (again). If both of you care enough, you can re-upload your packages to get a fresh Lintian run. Thanks for reporting. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOebY7AAoJEMcrUe6dgPNteuUP/0zNIwq/pxFzvXDR/GrWg9+7 Yk/BH9Ijwi8THp5YO9ShQ/lxmlmuqt2eNB5r0i4FqMH2d6t8eRYY6GB1L2cpIfJd gODzyNAnrHEOyrozRI6Gnzx84GWfgHdLpehbwTcM6gg4o1n7QahDd/5oONCrWR6c Mzu6DL1V6otpqTP/iiE+Ib4XMgvl2/6TKX1zZBp+s2xnc9Yu5uwha4QDfj1k5+GW KNlU+v5UpW7+joDscmdxej7rm0egREHaIHX3bc/T/ugHZie+bLBgVkHN1DpF4SDu O0rU7yd+up1Q6Oo8N30Gqp8Er5gENnD4WmcSb4GdD6Sv9X5c+S4nOPsoos0NXgYx TFyDp41pISRVz5SIQ4DE1UYsI3Wx2yTAZ1oa+4ZfpOFV1xjQSHgexU9aWJ6LXWxw Ar74UhPAW13ikBPTth0WzJ7iXrtOs8Ha07luan5ueXPpER19bJHibsUbLAK7SNyh BiOjVDNK+HJ66JRD0Tv2mhe1hQYKxjiOyVlXcKKe2CSyw4b05Q2FPHOWb5EaviwJ 42hpnvv2ZRh04nGcf8ZYYz+0ZPgrjjrHit7DGM5fxmAUsJHZMRFxSzVb85xftEA6 qIRPCDSt5mYPHEqqMmVVN+CYJhFzrNaoYVb3vQJm77Fh2haBQ5LPQQwzi+rpLdux 6P3WzwKdb7s9KB11P4QR =oOUU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e79b63b.3000...@toell.net
Re: mentors.debian.net time in sync?
Hi Arno, On Wed, 2011-09-21 at 12:02 +0200, Arno Töll wrote: On 21.09.2011 11:39, Fabrizio Regalli wrote: Same message for me: http://mentors.debian.net/package/gnupg-pkcs11-scd I correct myself: Our clock is /supposed/ to run with UTC as local time. Now it really is (again). If both of you care enough, you can re-upload your packages to get a fresh Lintian run. Thanks for reporting. Thanks for your answer. I uploaded again gnupg-pkcs11-scd package two seconds ago. PS I can't delete my previous uploaded package: it gives me an internal error 500, in details: Internal error 500 An unexpected error occured in this application. The administrator will get a detailed report about the error situation. We appreciate if you give us more information how this error situation happened. If you have questions feel free to contact us at a href=mailto:supp...@mentors.debian.net;supp...@mentors.debian.net/a. Cheers, Fabrizio. signature.asc Description: This is a digitally signed message part
Re: mentors.debian.net time in sync?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21.09.2011 12:10, Fabrizio Regalli wrote: PS I can't delete my previous uploaded package: it gives me an internal error 500, in details: That's a known (and fixed) bug, supposed to be deployed soon. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOebhGAAoJEMcrUe6dgPNt86wP/2dFIywZAiANXV9Go8ZMXomW uJrb5dy+VG8FwwJvtaJQ2qiRP3my1JCFY2OOSJ+tbbgP4/kNAbhutjvYFQyZxr3A synygsvHpI7odYCtqvLauyPfQUrphYfhuKRLFq7WOw0gEHRGYcIgEEx/NwUNTx/w aZpkbvuvI2FbESAVBfX+qG8h5aDJLiYCKYXe3P2exjQGJiWnXMGSLAX59wToHTWQ I/yMBpchA4rRzFlWEPf/kD6gdLgvyuyX/13fSvDVZVwyXhAlpVfi1jO/eXxXyaYI qHPyxJpo7Mbm2D34+jMyqrgGiZSve1WBri3eYUCKNFnFqCtWFRP7DkGQdf5GZ9lz yT5cLP5Wcz9UJkqwWc9ThgqjFq6zjsznQYt+8hfGobUMJvXyEBPKUgPo+C8afPJf 3v/TYmPGluRYeAUJpX1HsO6zJav9rMueyz1RXpmzdeK72N8EYDuaj5hexxI3PajP kEM6mqTY2X1sNCZUG8ycHBtS9HiKV3bpwCZAgoRg+x5FA3leUujQvu2zqTCqUSZc AwSEkwQOGBv0gbUGxMUR7GIohDXfOExC6z5DVZhiPrhKDoOfwguh+uo5N/banO2F 4yGBIhh+MQzNGxPmbiKuBsPaL9h7GsLHO1PZbe0JrT8OjPZ6aEp5vwg4wUU2CAyk Ae4A8bdvmbgi9s1Glo5z =oLvL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e79b846.6010...@toell.net
Re: flashcache - call for resolution / seeking for a mentor
Hi Andrey, Thank you very much for your feedback. On 21 September 2011 16:31, Andrey Rahmatullin w...@wrar.name wrote: On Wed, Sep 21, 2011 at 01:21:00PM +1000, onlyjob wrote: Could someone please kindly have a look at the package I've made (and provide comments)? You didn't fix Vcs-* per Arno comments in the ITP bug. I can't quite do it yet because I have no public repository. Given that our only option is merge, it looks like there will be no second repository. What is This has to be exported to make some magic below work. (before 'export DH_OPTIONS')? Hmm, apparently a remnants after dh_make You dont need --with quilt and quilt Build-Dep with 3.0 (quilt) and lintian tells you that. Thanks. If At the moment this version works only on x86_64 a.k.a. amd64 why Architecture: linux-any? That is an interesting question. We believe that upstream may eventually fix that. I remember reading discussion on this some time ago, regarding different package with similar problem. It was suggested that limiting package for the only architecture as workaround for upstream bugs is not recommended because package may be ported to a different architecture etc. I had impression that if package meant to be useful on linux-any it should be a target architecture despite know problems with some particular architectures. Please correct me on this - what's the best practice? Some files under utils/ are 2-BSD and it is useful to document that in debian/copyright. It may be better to convert debian/copyright to http://dep.debian.net/deps/dep5/ format at least in this case. Also, I think Based on DM-Cache: Copyright (C) International Business Machines Corp., 2006 should be reflected in debian/copyright too. The patch lacks author information (did you see http://dep.debian.net/deps/dep3/ ? it suggests adding other useful information to patch headers). No I did not - thank you very much for the hint. The package I need someone to look at is flashcache uploaded to mentors.debian.net The usual practice is to provide at least an URL of .dsc. It's http://mentors.debian.net/debian/pool/main/f/flashcache/flashcache_1.0~20110920132357-1.dsc My bad, sorry. I shouldn't assume that people have deb-src http://mentors.debian.net/debian unstable main in /etc/apt/sources.list Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbdoduwijwz75jgfej29l7uwflx--tuqj_tu7uwpirns-v...@mail.gmail.com
Re: mentors.debian.net time in sync?
On Wed, 2011-09-21 at 12:11 +0200, Arno Töll wrote: On 21.09.2011 12:10, Fabrizio Regalli wrote: PS I can't delete my previous uploaded package: it gives me an internal error 500, in details: That's a known (and fixed) bug, supposed to be deployed soon. Right, thanks. No more lintian messages related to time stamp appears on latest upload :-) Cheers, Fabrizio signature.asc Description: This is a digitally signed message part
Re: flashcache - call for resolution / seeking for a mentor
Dear Gergely, What a brilliant explanation! All the questions answered - much appreciated. Thank you, thank you. All the best, Dmitry. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBdODXSu14AUNY=ur9agiemxzgx_3mdlfkolv_eq4vxdz5...@mail.gmail.com
Re: flashcache - call for resolution / seeking for a mentor
Dear Sune, Thank for explaining this. Cheers, Dmitry. On 21 September 2011 19:11, Sune Vuorela nos...@vuorela.dk wrote: On 2011-09-21, onlyjob only...@member.fsf.org wrote: * Is it true that whoever happen to create an ITP first gets the monopoly for packaging? * If ITP always have priority, aren't we sending a wrong message for ambitious maintainers who might be tempted to create ITP early in order to secure the rights for packaging, disregarding of how close they are to providing a usable package? There are ways to take over a ITP, also without consent from the owner of the ITP. But it requires unresponsiveness from the owner and early communication from the one who wants to take it over. In this case, Arno always replied within 1 or 2 days. And you didn't try to communicate before you were actually done. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj7jahk.p7v.nos...@sshway.ssh.pusling.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbdodvma5syko06zv1cght7uoz60s71gr9lfej__eusmi5...@mail.gmail.com
Re: flashcache - call for resolution / seeking for a mentor
On Wed, Sep 21, 2011 at 08:13:33PM +1000, onlyjob wrote: You didn't fix Vcs-* per Arno comments in the ITP bug. I can't quite do it yet because I have no public repository. Then remove the tags. They are optional. Given that our only option is merge, it looks like there will be no second repository. What is This has to be exported to make some magic below work. (before 'export DH_OPTIONS')? Hmm, apparently a remnants after dh_make No, looks like a blind copy-paste. If At the moment this version works only on x86_64 a.k.a. amd64 why Architecture: linux-any? That is an interesting question. We believe that upstream may eventually fix that. I remember reading discussion on this some time ago, regarding different package with similar problem. It was suggested that limiting package for the only architecture as workaround for upstream bugs is not recommended because package may be ported to a different architecture etc. I had impression that if package meant to be useful on linux-any it should be a target architecture despite know problems with some particular architectures. Please correct me on this - what's the best practice? Why it doesn't work on other architectures? Does it build there? Is the not working of a doesn't launch kind or works but sometimes crashes kind? Can it corrupt user data because of this? The patch lacks author information (did you see http://dep.debian.net/deps/dep3/ ? it suggests adding other useful information to patch headers). No I did not - thank you very much for the hint. I've asked this because you have Description tag in the patch header. Usually manually created patches don't have any metadata at all. -- WBR, wRAR signature.asc Description: Digital signature
Re: flashcache - call for resolution / seeking for a mentor
Hi Andrey, What is This has to be exported to make some magic below work. (before 'export DH_OPTIONS')? Hmm, apparently a remnants after dh_make No, looks like a blind copy-paste. Fair enough, that could be the case of momentarily blindness of mine. :) If At the moment this version works only on x86_64 a.k.a. amd64 why Architecture: linux-any? That is an interesting question. We believe that upstream may eventually fix that. I remember reading discussion on this some time ago, regarding different package with similar problem. It was suggested that limiting package for the only architecture as workaround for upstream bugs is not recommended because package may be ported to a different architecture etc. I had impression that if package meant to be useful on linux-any it should be a target architecture despite know problems with some particular architectures. Please correct me on this - what's the best practice? Why it doesn't work on other architectures? Does it build there? Is the not working of a doesn't launch kind or works but sometimes crashes kind? Can it corrupt user data because of this? When I tried on i686 it compiles but then kernel can't load the module - see https://github.com/facebook/flashcache/issues/5 (third comment) The patch lacks author information (did you see http://dep.debian.net/deps/dep3/ ? it suggests adding other useful information to patch headers). No I did not - thank you very much for the hint. I've asked this because you have Description tag in the patch header. Usually manually created patches don't have any metadata at all. This patch is really unnecessary since the patched Makefile is not used at all. I should have it removed completely. I did patching with quilt without enough attention to annotation. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBdODVSC0fD2UCnuiu-EvGs7h1GZ6+720NkkYt=gt6dnis...@mail.gmail.com
Re: Tracking RFSs as bugs
Hi, I do not sponsor very much, but I am a bit unhappy about having comment possibilities on both mentors.d.n and the mailing list with information not forwarded. This results in duplicate work (for example I reviewed a package that already had a review on mentors.d.n pointing out the same issues). Which system we end up using, I do not really care about, but I would prefer if it was accessible by mail (for both reading and writing comments). For a BTS-based workflow as proposed I had these ideas (based on [1], but without using usertags to keep things a bit simpler): - A new pseudo-package mentors.debian.org (or whatever) is created; the maintainer is set to debian-mentors@l.d.o so all bug mail is sent to there. - New requests should use RFS: package/version; maybe with [NEW] appended for packages not yet in the archive. It might be helpful to have mentors.d.n be able to file them (on manual request). - Comments are sent to the BTS. Tags are used as follows: - moreinfo: Open questions or changes are required before an upload. - confirmed: Somebody did review the package and thinks it is okay. (Not needed when the package is directly uploaded.) - pending (closing the bug): Somebody will (did) upload the package (no further changes required). - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. It may also automatically close inactive bugs. - Packages tagged both moreinfo and confirmed get the confirmed tag removed automatically. It would still be possible to provide a web interface for comments on mentors.d.n: it would just create a mail to the BTS and also set the appropriate tags. Regards, Ansgar [1] http://wiki.debian.org/PackageReview -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s2svcsm447s@bistromathics.mathi.uni-heidelberg.de
Re: mentors.debian.net time in sync?
Thanks it's working now. Regards, Jeroen On 09/21/2011 12:02 PM, Arno Töll wrote: On 21.09.2011 11:39, Fabrizio Regalli wrote: Same message for me: http://mentors.debian.net/package/gnupg-pkcs11-scd I correct myself: Our clock is /supposed/ to run with UTC as local time. Now it really is (again). If both of you care enough, you can re-upload your packages to get a fresh Lintian run. Thanks for reporting. signature.asc Description: OpenPGP digital signature
Re: Tracking RFSs as bugs
I wanted to comment on this thread, but for some reason, it always fell off my radar. No more! Ansgar Burchardt ans...@debian.org writes: I do not sponsor very much, While I don't sponsor at all at the moment, because I'm not a DD right now, if and when I become one, I do wish to sponsor from time to time. And until then, I wish to occassionally contribute with package reviews. Hopefully my input, despite these shortcomings, will be useful. but I am a bit unhappy about having comment possibilities on both mentors.d.n and the mailing list with information not forwarded. Whatever happens, the end result should be that comments would be visible on all commonly used places: on this list, and on mentors.d.n (possibly including the BTS, my personal preference). This results in duplicate work (for example I reviewed a package that already had a review on mentors.d.n pointing out the same issues). Even worse is the case where issues are pointed out in one place, and the package gets uploaded nevertheless, because another sponsor did not spot the same mistake, and didn't check $ThisOtherPlaceSomePeopleUseToComment. Which system we end up using, I do not really care about, but I would prefer if it was accessible by mail (for both reading and writing comments). Same opinions here. Mail allows me to tag, mark and otherwise sort the stuff I want to review, or find interesting. Doing the same on the web is far more painful (and for that reason, I don't even attempt to do it). For a BTS-based workflow as proposed I had these ideas (based on [1], but without using usertags to keep things a bit simpler): - A new pseudo-package mentors.debian.org (or whatever) is created; the maintainer is set to debian-mentors@l.d.o so all bug mail is sent to there. - New requests should use RFS: package/version; maybe with [NEW] appended for packages not yet in the archive. It might be helpful to have mentors.d.n be able to file them (on manual request). - Comments are sent to the BTS. Tags are used as follows: - moreinfo: Open questions or changes are required before an upload. - confirmed: Somebody did review the package and thinks it is okay. (Not needed when the package is directly uploaded.) - pending (closing the bug): Somebody will (did) upload the package (no further changes required). I like this. - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. It may also automatically close inactive bugs. Apart from closing inactive bugs automatically, I believe this is a good idea. Some non-trivial packages might take some time to review, especially if it turns out there are some issues that need to be solved upstream before an upload can happen (ie, packaging is spot-on, and perfect, but upstream needs to clarify a license, for example). I think it's worth having that RFS bug still open, and pinging it once in a while only adds noise. Closing it, and opening a new one (or reopening the same) would only be noise, in my opinion. Instead, I'd propose using the pending tag for this case. Packages that get uploaded can be closed with mailing -done@ (and if the sponsoring process involves fixing a few issues, the bug can even be closed with the changelog). With using 'pending', it would be possible to filter out uninteresting requests, and everyone's staisfied. It would still be possible to provide a web interface for comments on mentors.d.n: it would just create a mail to the BTS and also set the appropriate tags. Instead of mentors.d.n automatically doing the mail (which would be a dumbed-down web interface to the BTS), it would in my opinion, be better if it had the appropriate mailto: links instead, and provide a read-only interface to the comments only. But all in all, once I'm a DD again, I'd love to have sponsoring support in the BTS. I know and love that thing, and use it daily anyway, it would be a huge improvement over the current status quo, even if mentors.d.n would not have explicit support for it at first: * The BTS provides a familiar interface for DDs, one that can be easily archived, tagged and otherwise sorted. * It provides a web interface, ability to download full RFS 'sessions' as mbox. * One can subscribe to specific RFS bugs, and collaborate with other reviewers easily, as it all ends up in the same place. * This latter feature also makes it easier to notice replies. When one has a huge volume of mail to go through daily (hi lkml, bugs-dist, devel, mentors, devel-changes and a whole lot of other lists.. ;), it helps if I could subscribe to RFS requests I reviewed, so I immediately see if I get a response, without having to write specific filters for this case, or look into my mentors folder. ...and I don't see a downside of using the BTS, apart from making some minor noise on -devel-changes and -bugs-dist perhaps. But the amount of RFS traffic is
Re: Tracking RFSs as bugs
Hi, Gergely Nagy alger...@balabit.hu writes: Ansgar Burchardt ans...@debian.org writes: - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. It may also automatically close inactive bugs. Apart from closing inactive bugs automatically, I believe this is a good idea. Some non-trivial packages might take some time to review, especially if it turns out there are some issues that need to be solved upstream before an upload can happen (ie, packaging is spot-on, and perfect, but upstream needs to clarify a license, for example). That will make the pseudo-package accummulate lots of open bug reports that never see any attention. So I think inactive requests need to be dealt with one way or another, closing them automatically after a longer term of no activity does seem as easy way to do so (ie. after 4-8 weeks of no new comments). For reviews that take a longer time, the sponsor could set himself as the owner of the bug -- bugs with an owner would then not be closed. This maybe can also be extended to bugs tagged confirmed. An other idea I had when discussing this on IRC would be using the summary field of the bug report to link to the current source package and (optionally) also the page on mentors.d.n for the package. For this to be easily set automatically, we might however need to add a new command to debbugs (as the current summary command has to refer to an already existing message). Instead of mentors.d.n automatically doing the mail (which would be a dumbed-down web interface to the BTS), it would in my opinion, be better if it had the appropriate mailto: links instead, and provide a read-only interface to the comments only. Sure, I don't mind either way. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/s2sd3eu10oq@bistromathics.mathi.uni-heidelberg.de
Re: Tracking RFSs as bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, aside from my comments below I fully agree to both of your mails. On 21.09.2011 14:33, Gergely Nagy wrote: but I am a bit unhappy about having comment possibilities on both mentors.d.n and the mailing list with information not forwarded. Whatever happens, the end result should be that comments would be visible on all commonly used places: on this list, and on mentors.d.n (possibly including the BTS, my personal preference). that's pretty much the reason why I am picky to get people to comment in this thread. I am aware of this problem and I am exploring possibilities to solve it. On whatever solution we may agree (or not), Debexpo will need to follow. That said, I don't want to find a solution in Debexpo the mailing list has to follow, but the other way around. I am not sure what the original intention of the author regarding the comment function was - I didn't implement it. Its clear its not really usable as is. On the other hand I know from several people they like the web comment function, opposing us old, grumpy MUA die-hards and consider it a worthwhile addition. Hence my idea was and is to merge the web review part of Expo with our current or future review solution. So, people using either solution would be aware of comments from the other world. - Comments are sent to the BTS. Tags are used as follows: - moreinfo: Open questions or changes are required before an upload. - confirmed: Somebody did review the package and thinks it is okay. (Not needed when the package is directly uploaded.) - pending (closing the bug): Somebody will (did) upload the package (no further changes required). I like this. We would probably need in addition: - - wontfix: Somebody claims the package is not distributable by Debian and/or does not belong to Debian. The last point is hard to judge, but developers should be brave enough to use it by making clear its a vote on the package, not a personal level. If a developer disagrees he can still retag and taking over ownership of the bug. This is to not have many bugs more or less forever in the BTS being tagged moreinfo. A wontfix bug would be closed automatically after a while, say 8 weeks or so. - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. It may also automatically close inactive bugs. Apart from closing inactive bugs automatically, I believe this is a good idea. [..] I think it's worth having that RFS bug still open, and pinging it once in a while only adds noise. Closing it, and opening a new one (or reopening the same) would only be noise, in my opinion. As Ansgar says (in his next reply) we should avoid carrying old cruft forever with us. The inactivity period may be very long, though. I wouldn't close it based on the date it was filed, but based on the last activity. That would be conform to your idea I think. sponsoring process involves fixing a few issues, the bug can even be closed with the changelog). Quoting myself from IRC for a wider audience: That's semantically wrong, as its not the maintainer, but the sponsor to fix the bug. It should be closed by mentors.d.n or/and and by an explicit -done from the sponsor. Instead of mentors.d.n automatically doing the mail (which would be a dumbed-down web interface to the BTS), it would in my opinion, be better if it had the appropriate mailto: links instead, and provide a read-only interface to the comments only. While I personally wouldn't mind, I know people who disagree here. I tried to honor their opinion a bit above. Being subscribed to both -bugs-dist and -devel-changes among other high volume lists, I wouldn't mind the extra noise to be honest. Probably wouldn't even notice the difference in volume. Frankly, I don't see anything wrong even if we would draw attraction to sponsor requests by that way as a side effect. Mentoring needs more attraction among developers. I truly doubt the amount of sponsor requests is /that/ notable, though. Its about two fresh requests per day (citation needed). - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOee4hAAoJEMcrUe6dgPNtTKYQALTqQz1ttKTBuDWO6Ktg/E6l 6lSeZauZnyYj5jqC3j5eF27j72wwSd6/817zYcmulJqzjTBUEe+Lexqd46n3vX1H xM0CE1yIkE5cCJtuSun0+7uHsHrnA9Z0GmI+3D6nsxx1j8BUlpdh1HiHpsg3SJ8S lpJOeNDjcdYq2QROHEbNTs7vvgPSsMCtWXmFoPBsjeVsiTlXqXKiaAO4hzQizBD8 XrQbz3NHnCTspqLFqXBoP2DPHbi9P20Pv0aohOIqGPOtk3uwJ2pWUqJF/S/yU0zP KVVS0pkdDH82vkavj+gl89//HyrbA++bpquek8hULzn46UR7BpTLO+He5eSoJlFF tJkIgBLZR6JHsQmISVCIvcQ+FvJB+k5cRZsITwtLy8sDeDaSa0qrbhj8Rg3Np/I3 ymVCHaWMgiG0GNuSfrCFUqlQbbFjBGkE2PiDHJ2ZB1W8JVfFAvmgnBxpBaHTer6k M64tkbapHepZYLHIcCi2r54wb/t+gK7QGtHanU2lxInJobhuqhTBpDzEzy1eglXN
Re: Tracking RFSs as bugs
Ansgar Burchardt ans...@debian.org writes: Gergely Nagy alger...@balabit.hu writes: Ansgar Burchardt ans...@debian.org writes: - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. It may also automatically close inactive bugs. Apart from closing inactive bugs automatically, I believe this is a good idea. Some non-trivial packages might take some time to review, especially if it turns out there are some issues that need to be solved upstream before an upload can happen (ie, packaging is spot-on, and perfect, but upstream needs to clarify a license, for example). That will make the pseudo-package accummulate lots of open bug reports that never see any attention. So I think inactive requests need to be dealt with one way or another, closing them automatically after a longer term of no activity does seem as easy way to do so (ie. after 4-8 weeks of no new comments). In my opinion, RFS bugs that see no attention, but get uploaded can be closed automatically: if the version in unstable is = than on mentors, and the bug did not see any activity in a while (~4-8 weeks, as you said), then it can be safely closed. If it was never uploaded, then I would still opt for manual handling. Perhaps a monthly report could be made, where inactive bugs can be listed, and volunteers could glance over the list, and deal with said bug reports. (And I hereby volunteer to do that, and help setting up such a monthly report, in the very desired case of RFS's moving to the BTS) The reason behind this, is that RFS with no feedback is something that should not happen, as it's a big discouragement for the requestor, for one. Keeping them open, with a monthly report would make it easier to see what needs urgent attention. For reviews that take a longer time, the sponsor could set himself as the owner of the bug -- bugs with an owner would then not be closed. This maybe can also be extended to bugs tagged confirmed. ACK, sounds good! -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqiu56qj@balabit.hu
Package separation/naming conventions
Dear list, I am currently packaging the wcslib package (Bug #641624) as my first Debian package, and I am wondering about the naming conventions. The package contains two libraries, some tools and an common API documentation for both libraries. I would now make the following binary packages: - libwcs4 and libwcs4-dev - libpgsbox4 and libpgsbox4-dev containing the shared libs resp. the static libs+headers of the two libraries - wcslib-tools containing the included binaries - wcslib-doc containing the documentation of the two libraries. First question is now, Is it wise to call a package containing documentation for libwcs4 wcslib-doc? Usually, the doc has the same base name as the according library, hasn't it? Or is the link here made with the suggests/enhances dependency? And what would then suggest what? libwcs4-dev suggests wcslib-doc, or vice versa? Second question: libpgsbox4 depends on a package that is in non-free (pgplot5), and one of the (three) programs that are in wcslib-tools depend on libpgsbox4. Should I divide wcslib-tools into two packages like the following? - libwcs4-tools (two small executable) - libpgsbox4-tools (one small executable) The three programs are useful by its own. Best regards Ole -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ytzhb46q7n4@news.ole.ath.cx
Re: RFS: glipper
Hi, 2011/9/20 Gergely Nagy alger...@madhouse-project.org: A few nitpickings from the sideline, if you don't mind (IANADD applies, and so on and so forth): * It would perhaps be a good idea to add a few more headers to debian/patches/01_license-headers.patch, like fill in the Author field, or add Origin: Upstream CVS or somesuch, to make it even clearer where it comes from. The license header was removed in upstream source, so I decided to remove it. * debian/copyright has this text: This package was debianized by Neil Williams li...@codehelp.co.uk on Thu, 14 Sep 2006 11:40:26 +0100. The current Debian maintainer is Davide truffa dav...@catoblepa.org This is obviously not the case, as the package is currently orphaned, and the changelog closes the appropriate bug too, so the current maintainer should be updated (by mentioning all former maintainers too, preferably). My bad, already fixed and added new upstream author and copyright for that author. [SNIP] * debian/rules Very minor nitpicking, but... it's not a sample debian/rules anymore ;) You're totally right! Thanks for your comments, I re-uploaded the package with all the changes mentioned above, if someone can upload the package I'll be very glad. Thanks on advance -- José Ernesto Dávila Pantoja Licenciado en Computación - Ubuntu Member Ubuntu User #395356 GNU/Linux User #18273 Blog: http://josernestodavila.blogspot.com/ Fingerprint: 42F6 CCA0 22B2 B64C 131D AA9C 5943 CDFE 99BC D948 - -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGcdKnA2T6+WN_e6vRu25x-wMB2o_Gq0k7_vfPND9=zyveq...@mail.gmail.com
Re: Tracking RFSs as bugs
* Ansgar Burchardt ans...@debian.org, 2011-09-21, 11:47: I do not sponsor very much, but I am a bit unhappy about having comment possibilities on both mentors.d.n and the mailing list with information not forwarded. Same here. - A new pseudo-package mentors.debian.org (or whatever) is created; the maintainer is set to debian-mentors@l.d.o so all bug mail is sent to there. - New requests should use RFS: package/version; maybe with [NEW] appended for packages not yet in the archive. It might be helpful to have mentors.d.n be able to file them (on manual request). Agreed. - Comments are sent to the BTS. Tags are used as follows: - moreinfo: Open questions or changes are required before an upload. - confirmed: Somebody did review the package and thinks it is okay. (Not needed when the package is directly uploaded.) Let me bikeshed a little here. ;) I'd use confirmed merely to indicate that either: a) the package is already in the archive or b) it's a new package and a DD believes it would be a good addition to the archive. Note that the latter option is not necessarily a declaration of willingness to sponsor the package - I'd use owner for that purpose. - pending (closing the bug): Somebody will (did) upload the package (no further changes required). I'm not sure if pending would be ever useful (except maybe for uploads to DELAYED). - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. I think I'd prefer this to be done manually. Sending an Uploaded, thanks! mail to nnn-d...@bugs.debian.org shouldn't be a big effort for sponsors... It may also automatically close inactive bugs. Yes, this is quite important, or else we'll drown in bugs. Of course, we would have to define what is inactive. One of my packages was sponsored 8 months after I sent the RFS... - Packages tagged both moreinfo and confirmed get the confirmed tag removed automatically. With my proposal on how to use confirmed this won't be needed. In fact, it'd very typical for an RFS to be tagged both confirmed (= the package is welcome) and moreinfo (= needs more work). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110921173002.ga2...@jwilk.net
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/21/2011 12:49 PM, Daniel Kauffman wrote: ... for serving Adobe socket policy files. What's that? How do you make them? The package is ready for sponsorship and can be downloaded from: http://socketpolicyserver.com 1/ The package is a native package, which isn't required for an Apache module IMO. Please read about it in the Debian policy manual. 2/ The package has apache2-threaded-dev as Build-Depends, any reason why it wouldn't work with apache2-prefork-dev also? Also, having a binary package with apache2 | apache2-mpm seems strange to me. 3/ It'd be nice to use the DEP5 format for debian/copyright. Please see http://dep.debian.net/deps/dep5/. It's still a candidate, so it's not a requirement though. 4/ Your Standards-Version: isn't up-to-date. Did you build the package in SID and ran lintian there? Also: I: libapache2-mod-socket-policy-server: extended-description-is-probably-too-short You don't need the last dot at the end, but you do need a longer extended description. Lintian complains with less than 2 lines, but I think at least 10 lines sounds reasonable. By reading what you wrote, I still don't understand what your package is doing. :) 5/ Your debian/README explains how to use apt-get, that we can edit the config file of the module, and how to restart apache. I don't think you should do that, it's not helpful, but there might be other things you want to document (like what to put in the socket policy file for example?). 6/ Your package configures a VirtualHost in a /etc/apache2/conf.d file, don't you think it would be nicer in /etc/apache2/sites-available? If not, please explain here why. I hope the above helps, Thanks for your will to contribute to Debian, Thomas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e7a3068.5070...@debian.org
Re: Tracking RFSs as bugs
Hi, Jakub Wilk jw...@debian.org writes: - Comments are sent to the BTS. Tags are used as follows: - moreinfo: Open questions or changes are required before an upload. - confirmed: Somebody did review the package and thinks it is okay. (Not needed when the package is directly uploaded.) Let me bikeshed a little here. ;) I'd use confirmed merely to indicate that either: a) the package is already in the archive or b) it's a new package and a DD believes it would be a good addition to the archive. Note that the latter option is not necessarily a declaration of willingness to sponsor the package - I'd use owner for that purpose. I discussed this with Jakub on IRC and we came to the conclusion that (experienced) reviewers or DDs who believe the package is not totally insane. It does not need to have gone through a thorough review, though it certainly would not hurt either. - pending (closing the bug): Somebody will (did) upload the package (no further changes required). I'm not sure if pending would be ever useful (except maybe for uploads to DELAYED). Hmm, I thought about using it in case the sponsor did review the package, but will only upload later (for whatever reasons). But I guess he could just close the bug right away as well. I do not think uploads to DELAYED should be handled differently as the sponsor will just forget to close the bug later. - mentors.d.n automatically closes RFS bugs for uploaded packages or packages that were removed from there. I think I'd prefer this to be done manually. Sending an Uploaded, thanks! mail to nnn-d...@bugs.debian.org shouldn't be a big effort for sponsors... Agreed, but having mentors.d.n cleaning up (semi-)automatically in case the mail went to nnn@bugs.d.o instead of nnn-done@bugs.d.o should not hurt. - Packages tagged both moreinfo and confirmed get the confirmed tag removed automatically. With my proposal on how to use confirmed this won't be needed. In fact, it'd very typical for an RFS to be tagged both confirmed (= the package is welcome) and moreinfo (= needs more work). Agreed. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uv9zlro@deep-thought.43-1.org
Re: Package separation/naming conventions
* Ole Streicher debian-de...@liska.ath.cx, 2011-09-21, 16:42: I am currently packaging the wcslib package (Bug #641624) as my first Debian package, and I am wondering about the naming conventions. The package contains two libraries, some tools and an common API documentation for both libraries. I would now make the following binary packages: - libwcs4 and libwcs4-dev - libpgsbox4 and libpgsbox4-dev containing the shared libs resp. the static libs+headers of the two libraries First of all, don't version your -dev package(s), unless you want to keep multiple versions of it in the archive at the same people. (You probably don't.) Also, unless there's good reason to separate -dev package, I'd create just a single one. First question is now, Is it wise to call a package containing documentation for libwcs4 wcslib-doc? Sounds good to me. Or is the link here made with the suggests/enhances dependency? And what would then suggest what? libwcs4-dev suggests wcslib-doc, or vice versa? You can use both. Or none. Users will find out which package they need anyway, so don't worry about it. :) Second question: libpgsbox4 depends on a package that is in non-free (pgplot5), and one of the (three) programs that are in wcslib-tools depend on libpgsbox4. Should I divide wcslib-tools into two packages like the following? - libwcs4-tools (two small executable) - libpgsbox4-tools (one small executable) That make sense (except there's probably no need to version *-tools packages). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110921204812.ga9...@jwilk.net
Re: Tracking RFSs as bugs
Ansgar Burchardt ans...@debian.org writes: - pending (closing the bug): Somebody will (did) upload the package (no further changes required). I'm not sure if pending would be ever useful (except maybe for uploads to DELAYED). Hmm, I thought about using it in case the sponsor did review the package, but will only upload later (for whatever reasons). But I guess he could just close the bug right away as well. I do not think uploads to DELAYED should be handled differently as the sponsor will just forget to close the bug later. Wouldn't the fixed tag work for cases where the package is reviewed, and will be uploaded VerySoon(tm)? -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwjpr3qh@luthien.mhp
Re: Tracking RFSs as bugs
Gergely Nagy alger...@madhouse-project.org writes: Wouldn't the fixed tag work for cases where the package is reviewed, and will be uploaded VerySoon(tm)? Please disregard that, I had a brainfart. Apologies for the noise. -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877h51r36s@luthien.mhp
Re: Package separation/naming conventions
* Jakub Wilk jw...@debian.org, 2011-09-21, 22:48: unless you want to keep multiple versions of it in the archive at the same people. Err, of course I meant s/people/time/. Thanks to Arno for spotting this. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110921215832.ga5...@jwilk.net
mentors.debian.net moved to new hardware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everyone, our (not so) old host running http://mentors.debian.net was replaced right before by shiny new hardware. For you, as user you shouldn't hopefully notice the switch. The new hardware is much more powerful and has plenty of disk space. Hence all problems with exhausted disk space and time-outing servers should not occur anymore. If you find any problem with the new setup, please let us know. Please note, in particular the DNS update is pending and not complete yet. However we set-up a proxy routing your uploads to the new server. HTTP uploads work as before, as do FTP uploads, except that FTP uploads are processed in a more timely manner now. Also we improved security of the anonymous FTP[sic!]. For you, this means you can't overwrite anonymous uploads anymore until they have been processed by mentors and have been moved out from the incoming directory. Hardware and bandwidth is generously donated by Wavecon GmbH www.wavecon.de. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOem5xAAoJEMcrUe6dgPNtZ1AP/i5ArxmhRvVOLqid/6ThHz6Q tskMF/n3yhpW3BCASv4oD+THZ4dlfRZTi9hE+hbnwMWndaj+jsT+oJKQvG+p2max szx/0+ab31gyjErVZ3VMaRSqQOIx6bOaKqC4Xjn55M8jJUQMg7Tixkdc+JpH/pPQ A5ogF0Yn9xLFFR6w73AWWPiKc7aKeHvTMvFqHJ/u8gz1m9KZPNzx0s3JVxRpJ2hm NTZcBeA+IMsXkYPjVnV2koVoQF5agiERmTlbXC1p1MEfFYzrC0mGJfCNy/7NU1h9 jyVCCvl31b0MrYH5SHFyFIsrSMaQFGU/j+0A7wZTu6fN98N/pRR37Ol4rOXpDr02 B3Nb4dVGBgRH5jzEkNeAfJFW9V8d+bfihWlgORCM9xmMc9G1tx9cb5xBz5miGFR9 g+8puM8WrEbbMJFs6Iog8XLw8Y+MgiFZr9p6Wh87sXjUOk/ozRFGPbJPe4GcIwCP 2qfWyWdAFjtdv8CDTbJGVn8AyO68lBJY8J9aY+8Jbs/+Yf57GqyIIin54Bdcxfxj zkCAUv53sdZtrSH45h20tXcJpEwufYPD2equhXOsNLptJrJc8Tpjv4I6qAcsEDcc SLe4QxsJ0uT+O6ph02+MbDhcDkegMfjsKYdPC+nGS+TKj1RYPAfHSop1mAL+/seb X7fVuvUhfB3XuOk6B+oR =+dXy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e7a6e71.3010...@toell.net
RFS: pysolfc (replacement for removed package: pysol)
Hello mentors, I am looking for a sponsor for my package pysolfc. * Package name: pysolfc Version : 2.0-1 * URL : http://pysolfc.sourceforge.net/ * License : GPL * Programming Lang: Python * Description : A Python solitaire game collection It builds the binary package: pysolfc To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pysolfc Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pysolfc/pysolfc_2.0-1.dsc The package appears to be lintian and pbuilder clean. A previous version has already been included in Ubuntu. The upload would fix this bug: 519752 My motivation for maintaining this package is: Its (unmaintained) predecessor pysol dropped out of debian a while ago; pysolfc is considered one of the best versatile solitaire collections. It is already part of Ubuntu, but I'd rather maintain it via Debian. Other relevant location(s): - Git: git://git.debian.org/git/pkg-games/pysolfc.git - Git-Browser: http://git.debian.org/?p=pkg-games/pysolfc.git I would be glad if someone sponsored this package for me. I've also prepared a transitional package pysol, found at: - URL: http://mentors.debian.net/package/pysol - dget -x http://mentors.debian.net/debian/pool/main/p/pysol/pysol_10.dsc There are also supplementary cardsets packages in the following locations which I'd glady see reviewed: pysolfc-cardsets: - URL: http://mentors.debian.net/package/pysolfc-cardsets - dget -x http://mentors.debian.net/debian/pool/main/p/pysolfc-cardsets/pysolfc-cardsets_2.0+dfsg-1.dsc - Git: git://git.debian.org/git/pkg-games/pysolfc-cardsets.git - Git-Browser: http://git.debian.org/?p=pkg-games/pysolfc-cardsets.git pysol-cardsets (transitional): - URL: http://mentors.debian.net/package/pysol-cardsets - dget -x http://mentors.debian.net/debian/pool/main/p/pysol-cardsets/pysol-cardsets_10.dsc Kind regards, Bernhard PS: Please CC me when replying to this message! signature.asc Description: This is a digitally signed message part
