Re: RFS: bugs-everywhere
On Wed, 23 Apr 2008 23:41:30 +1000, Ben Finney [EMAIL PROTECTED] wrote: Howdy mentors, I have a package that is seeking a sponsor. Package name: bugs-everywhere Version:0.0.193-2~rc1 Upstream Author:Aaron Bentley [EMAIL PROTECTED] Chris Ball [EMAIL PROTECTED] URL:http://bugseverywhere.org/ License:GPL-2+ Section:devel Hi Ben! Did you get the mail from Alexander? I agree with him: the diff.gz is difficult to read. Don't patch headers for FSF address, don't ship this .be directory (I suppose you should adapt clean target of your debian/rules). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: xiterm+thai (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.09-1 of my package xiterm+thai. It builds these binary packages: xiterm+thai - X terminal program with Thai languague support The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xiterm+thai - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xiterm+thai/xiterm+thai_1.09-1.dsc I would be glad if someone uploaded this package for me. Kind regards Neutron Soutmun signature.asc Description: นี่คือ ส่วนข้ อความท ี่มีลา ยเซ็นด ิจิทัล กำกับ
RFS: meshlab
Dear mentors, I am looking for a sponsor for my package meshlab. * Package name: meshlab Version : 1.1.1-1 Upstream Author : Paolo Cignoni and others * URL : http://meshlab.sourceforge.net/ * License : GPL2+ Section : misc It builds these binary packages: meshlab- System for processing and editing triangular meshes The package has been in development for almost a year now. The only thing still missing is a sponsor. See the rather long ITP bug thread at bug #426581. The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/meshlab - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/meshlab/meshlab_1.1.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Teemu Ikonen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: meshlab
On Thu, 24 Apr 2008 12:43:03 +0200, Teemu Ikonen [EMAIL PROTECTED] wrote: Dear mentors, I am looking for a sponsor for my package meshlab. * Package name: meshlab Version : 1.1.1-1 Upstream Author : Paolo Cignoni and others * URL : http://meshlab.sourceforge.net/ * License : GPL2+ Section : misc Some random remarks : - debian/copyright is incomplete. Those files, at least, are missing: meshlab/src/fgt/edit_texture/edittexture.cpp meshlab/src/meshlabplugins/meshedit/meshedit.h sf/vcg/complex/trimesh/create/emc_lookup_table.h sf/wrap/gl/gl_geometry.h - it also misses files in code/, even if you don't use them - what is the status of the phone home system? - you should write some minimal manpage for meshlab - you could add an Homepage field in debian/control - you seems to modify a lot of .pro files, right? You should use a patch management system to do that, this will make your diff.gz easier to read. I cannot test further, I don't know how to get a file that could be opened by meshlab. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xiterm+thai (updated package)
On Thu, Apr 24, 2008 at 5:48 PM, Neutron Soutmun [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 1.09-1 of my package xiterm+thai. Uploaded. For future reference, please mention changes like the security issue in the RFS. Please remember to prepare a security update for etch and forward to the stable security team, more details are in the developers-reference. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xiterm+thai (updated package)
On Thu, Apr 24, 2008 at 5:48 PM, Neutron Soutmun [EMAIL PROTECTED] wrote: I am looking for a sponsor for the new version 1.09-1 of my package xiterm+thai. Uploaded. For future reference, please mention changes like the security issue in the RFS. Please remember to prepare a security update for etch and forward to the stable security team, more details are in the developers-reference. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bugs-everywhere
Vincent Bernat [EMAIL PROTECTED] writes: On Wed, 23 Apr 2008 23:41:30 +1000, Ben Finney [EMAIL PROTECTED] wrote: Howdy mentors, I have a package that is seeking a sponsor. Package name: bugs-everywhere Version:0.0.193-2~rc1 Upstream Author:Aaron Bentley [EMAIL PROTECTED] Chris Ball [EMAIL PROTECTED] URL:http://bugseverywhere.org/ License:GPL-2+ Section:devel Hi Ben! Did you get the mail from Alexander? Alexander who? When was it sent? I agree with him: the diff.gz is difficult to read. Don't patch headers for FSF address, That's a patch which has been sent upstream, and the upstream devel agrees it will be applied. I'm patching it in the Debian package as a direct result of other feedback that said it *should* be corrected in the Debian package. don't ship this .be directory (I suppose you should adapt clean target of your debian/rules). Oops, yes, you're right, that directory shouldn't be part of the package. Thanks for the feedback! -- \ “There is no reason anyone would want a computer in their | `\ home.” —Ken Olson, president, chairman and founder of | _o__)Digital Equipment Corp., 1977 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bugs-everywhere
On Thu, 24 Apr 2008 23:38:17 +1000, Ben Finney [EMAIL PROTECTED] wrote: Did you get the mail from Alexander? Alexander who? When was it sent? This message : http://lists.debian.org/debian-mentors/2008/04/msg00330.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bugs-everywhere
On 24/04/2008, Ben Finney wrote: Did you get the mail from Alexander? Alexander who? When was it sent? Schmehl. http://lists.debian.org/debian-mentors/2008/04/msg00330.html Mraw, KiBi. pgpCHeoD6L7Mb.pgp Description: PGP signature
Re: RFS: liblunar and lunar-applet
Hello, On Tue, Apr 22, 2008 at 7:47 PM, Bas Wijnen [EMAIL PROTECTED] wrote: Hello again, I should have been much faster with this, but better late than never I guess... On Thu, Apr 03, 2008 at 10:43:09PM +0800, LI Daobing wrote: On Wed, Apr 2, 2008 at 11:40 PM, Bas Wijnen [EMAIL PROTECTED] wrote: - The library version is complex. This is probably upstream's choice, in which case it's fine. Libraries normally have a [base]-[version] and [base]-dev package. That means the base name of this library is liblunar-1. Gtk+ uses a similar naming, but personally I don't think it's needed to do this until version 2 is needed *and* it is such a big change that porting old applications is not reasonable, *and* there are enough old applications to keep providing the old version as a -dev package next to the new version. Most libraries don't ever get in that state, so they don't need such a complex version. lintian will complain if the name is not liblunar-1-0, this name is come from objdump -p /usr/lib/liblunar-1.so.0.0.0 | grep SONAME Yes, this comment was more directed at upstream. As long as upstream uses this versioning, you should follow it. What I'm saying is that it's probably too complex for what upstream needs. forwarded - Packages containing functionality for use in a script language should be named libpackage-language, in this case liblunar-python instead of python-lunar. no, debian python policy 2.2 said the package name should be python-foo, and python-lunar really provide a lunar module. Ah, ok. I'm not too familiar with the Python policy, thanks. :-) OK an updated version is uploaded to mentors.debian.net. remove DM-Upload-Allowed and update copyright information, please check it. It looks good, but some problems have been caused by my delay: - There are several warnings now that it's being compiled with gcc-4.3. This is upstream stuff, you probably don't need to fix it, but upstream may want to know. OK - python-lunar.install looks in /usr/lib/python2.4/, but the files are now installed in /usr/lib/python2.5/. fixed. a new version 1.0.0-1 uploaded to mentors.debian.net, you can download it by dget http://mentors.debian.net/debian/pool/main/l/liblunar/liblunar_1.0.0-1.dsc thanks. -- Best Regards, LI Daobing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
A question about adopting a package
Hello mentors, Reading the list of orphaned packages I have noticed that package nec has been orphaned [1]. Because I use NEC2 in antenna related research I think that I can adopt this package. At the moment I am not a maintainer of any package in Debian nor a DD, however I have been packaging software for my own needs for quite some time. One my package is awaiting a sponsor on mentors.debian.net [2]. As I have never worked with the BTS control bot, I am asking for directions. Shall this mail sent from my own address to [EMAIL PROTECTED] suffice for setting an ITA? === 8 package wnpp retitle 465910 ITA: nec -- NEC2 Antenna Modelling System owner 465910 ! quit === 8 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465910 [2] http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=fuse-convmvfs -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about adopting a package
On Thu, Apr 24, 2008 at 11:25:11PM +0400, Stanislav Maslovski wrote: As I have never worked with the BTS control bot, I am asking for directions. Shall this mail sent from my own address to [EMAIL PROTECTED] suffice for setting an ITA? === 8 package wnpp retitle 465910 ITA: nec -- NEC2 Antenna Modelling System owner 465910 ! quit === 8 Yes, it would. You don't actually need the 'quit', but it hurts noone. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: A question about adopting a package
On Thu, Apr 24, 2008 at 02:36:37PM -0500, Luis Rodrigo Gallardo Cruz wrote: On Thu, Apr 24, 2008 at 11:25:11PM +0400, Stanislav Maslovski wrote: Shall this mail sent from my own address to [EMAIL PROTECTED] suffice for setting an ITA? === 8 package wnpp retitle 465910 ITA: nec -- NEC2 Antenna Modelling System owner 465910 ! quit === 8 Yes, it would. You don't actually need the 'quit', but it hurts noone. Thanks, done. -- Stanislav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Uploaded] liblunar and lunar-applet
On Thu, Apr 24, 2008 at 10:43:05PM +0800, LI Daobing (李道兵) wrote: a new version 1.0.0-1 uploaded to mentors.debian.net Looks good, I uploaded it. Please let me know when it passes NEW, so the new lunar-applet can be uploaded as well. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: A question about adopting a package
Luis Rodrigo Gallardo Cruz wrote: You don't actually need the 'quit', but it hurts noone. There actuatually seems to be a trend to use 'kthxbye' nowadays, which is not documented, but seems to work, and a lot cooler and lolcatter From http://www.debian.org/Bugs/server-control quit stop thank thanks thankyou thank you On a line by itself, in any case, possibly followed by whitespace, tells the control server to stop processing the message; the remainder of the message can include explanations, signatures or anything else, none of it will be detected by the control server. So 'quit' would be perfectly fine, and actually very useful, ie: I mail control and cc: a bug [EMAIL PROTECTED] tags XX moreinfo sevrity XX serious [more commands] quit Blah, I need you to provide all this extra info, blah... [more info on the bug] So that control doesn't try to parse evrery line of your mail and get confused, signatures included :) -- ·''`. Come, let me sing into your ear, those dancing days are gone : :' : I carry the sun in a golden cup, the moon in a silver bag `. `' `- Proudly running Debian GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about adopting a package
On Thu, 24 Apr 2008, Amaya wrote: Luis Rodrigo Gallardo Cruz wrote: You don't actually need the 'quit', but it hurts noone. There actuatually seems to be a trend to use 'kthxbye' nowadays, which is not documented, but seems to work, and a lot cooler and lolcatter It is documnted on server-control... see if you can find it. Don Armstrong -- This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging without Makefile
Dominik George wrote: [...] Sounds easy - but how do I get it to copy my one single file? What Dmitry suggested does not quite work ... The debian/rules file *is* a Makefile --- so at the very worst you can just change the bit that invokes upstream's Makefile to a cp. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ I have always wished for my computer to be as easy to use as my │ telephone; my wish has come true because I can no longer figure out │ how to use my telephone. --- Bjarne Stroustrup signature.asc Description: OpenPGP digital signature
foo.diff.gz difficult to read (was: RFS: bugs-everywhere)
Vincent Bernat [EMAIL PROTECTED] writes: Did you get the mail from Alexander? [from Alexander Schmehl, on a different thread. URL:http://lists.debian.org/debian-mentors/2008/04/msg00330.html] I agree with him: the diff.gz is difficult to read. How is it difficult to read? I've opened it in Emacs and 'zless' and in either of them it reads like any other diff. Like any other unified diff, the changes are clearly marked by file, hunk location, and context lines. What readability problems are you seeing? What improvements would you want to see in the diff? As for a patch management system, I find packages that use them *more* difficult to understand as an outsider than those that use the standard foo.diff.gz. I've read much discussion for and against, and I'm currently convinced that such systems are detrimental, on balance, for those wanting to work with the package. So, no thanks, I'll decline on that suggestion and continue to ship a standard foo.diff.gz. Feedback still appreciated, and I'll be incorporating other suggestions soon. -- \“There are only two ways to live your life. One is as though | `\ nothing is a miracle. The other is as if everything is.” | _o__) —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about adopting a package
Amaya [EMAIL PROTECTED] writes: Luis Rodrigo Gallardo Cruz wrote: You don't actually need the 'quit', but it hurts noone. There actuatually seems to be a trend to use 'kthxbye' nowadays, which is not documented, but seems to work, and a lot cooler and lolcatter I find these last two to be mutually exclusive. -- \Laurie got offended that I used the word 'puke.' But to me, | `\ that's what her dinner tasted like. -- Jack Handey | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Keep directory in working tree, but exclude from foo.diff.gz
Howdy mentors, I have a working tree for a package that's under version control; the working tree is specific to the Debian packaging for the software. That working tree contains a (version-controlled) directory that must remain in the working tree, and remain under version control, but should *not* become part of the Debian foo.diff.gz against the upstream source. The directory contains developer-only data that is not part of the Debian package, but *is* part of the data that should be under VCS in that working tree. So, in this case, it's not appropriate to have the directory removed by the 'debian/rules clean' action; the files need to remain in the working tree. What would be the best way to keep such a directory in place, but exclude the directory from the Debian source and binary packages? -- \ If you can do no good, at least do no harm. -- _Slapstick_, | `\ Kurt Vonnegut | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Ben Finney wrote: What would be the best way to keep such a directory in place, but exclude the directory from the Debian source and binary packages? dpkg-source -iregexp? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITA: tkgate (updated package)
Dear mentors, I am looking for a sponsor for the new version 2.0~a11.dfsg.1-1 of my package tkgate. It builds these binary packages: tkgate - Tcl/Tk based digital circuit editor and simulator tkgate-data - Tcl/Tk based digital circuit editor and simulator tkgate-doc - Tcl/Tk based digital circuit editor and simulator The package appears to be lintian clean. The upload would fix these bugs: 464329 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tkgate - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tkgate/tkgate_2.0~a11.dfsg.1-1.dsc I would be glad if someone uploaded this package for me. -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer SySDSoft, Inc. GPG KeyID: 0x9DCA0B27 (@ subkeys.pgp.net) GPG Fingerprint: 087D 3767 8CAC 65B1 8F6C 156E D325 C3C8 9DCA 0B27 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Felipe Sateler [EMAIL PROTECTED] writes:
Ben Finney wrote:
What would be the best way to keep such a directory in place, but
exclude the directory from the Debian source and binary packages?
dpkg-source -iregexp?
Thanks. That looks like the right functionality, indeed.
However:
=
$ man dpkg-source
[...]
-i[regexp]
You may specify a perl regular expression to match files
you want filtered out of the list of files for the diff.
[...] There can only be one active regexp, of multiple
-i options only the last one will take effect.
[...]
$ dpkg-source --help
[...]
-i[regexp] filter out files to ignore diffs of
(defaults to:
'(?:^|/).*~$|(?:^|/)\.#.*$|(?:^|/)\..*\.swp$|(?:^|/),,.*(?:$|/.*$)|(?:^|/)(?:DEADJOE|\.cvsignore|\.arch-inventory|\.bzrignore|\.gitignore)$|(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn|\.hg|_darcs|\.git|\.shelf|_MTN|\.bzr(?:\.backup|tags)?)(?:$|/.*$)').
[...]
=
Yikes. So, in order to filter out an additional pattern, I can't just
say ignore this pattern as well as the defaults. I have to construct
a *single* regexp that contains the default pattern *plus* mine, and
forever diverge from any future changes to the default regexp.
Am I reading it wrong, or is this dpkg-source option really that
awful?
--
\ First they came for the verbs, and I said nothing, for verbing |
`\weirds language. Then, they arrival for the nouns and I speech |
_o__)nothing, for I no verbs. -- Peter Ellis |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Ben Finney wrote:
Felipe Sateler [EMAIL PROTECTED] writes:
Ben Finney wrote:
What would be the best way to keep such a directory in place, but
exclude the directory from the Debian source and binary packages?
dpkg-source -iregexp?
Thanks. That looks like the right functionality, indeed.
However:
=
$ man dpkg-source
[...]
-i[regexp]
You may specify a perl regular expression to match files
you want filtered out of the list of files for the diff.
[...] There can only be one active regexp, of multiple
-i options only the last one will take effect.
[...]
$ dpkg-source --help
[...]
-i[regexp] filter out files to ignore diffs of
(defaults to:
'(?:^|/).*~$|(?:^|/)\.#.*$|(?:^|/)\..*\.swp$
(?:^|/),,.*(?:$|/.*$)|(?:^|/)(?:DEADJOE|\.cvsignore|\.arch-inventory
\.bzrignore|\.gitignore)$|(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn
\.hg|_darcs|\.git|\.shelf|_MTN|\.bzr(?:\.backup|tags)?)(?:$|/.*$)').
[...]
=
Yikes. So, in order to filter out an additional pattern, I can't just
say ignore this pattern as well as the defaults. I have to construct
a *single* regexp that contains the default pattern *plus* mine, and
forever diverge from any future changes to the default regexp.
Am I reading it wrong, or is this dpkg-source option really that
awful?
Apparently it is. Note though that most of that regex is to match stuff you
won't use (eg, every VCS in common use, you probably use only one).
BTW, why are there files useful to you but not other developers?
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
