Re: Removal of fc-cache calls in postinsts
Quoting Josselin Mouette (j...@debian.org): > The next paragraph said: > I’ve requested a new lintian check, and here is the list of > affected packages. /me slaps self. Sorry, Joss, for overreading your mail. I actually went back on it quickly after you forwarded it to pkg-fonts-devel. signature.asc Description: Digital signature
Re: RFC: DEP-3: Patch Tagging Guidelines
On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote: > The dh_make template for debian/copyright induces many developers to put their > packaging work under the GPL, and I have already seen packages whose license > is > otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and > the patch is non-trivial, then in theory if we want to respect what is > written, > we are stuck with a GPL'ed patch. Therefore, we have an optional License field > to make things crystal clear if necessary. Sounds like dh_make needs a bug report about the default packagaging license, could you file one? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Raphael Hertzog wrote: > Hello, > > please find below a first draft of DEP-3 that I called Patch Tagging > Guidelines. The idea is to standardize a set of meta-information to embed > in patches that we apply. Please review, share your comments and ideas of > enhancements. If the idea is to standarize metainformation, I would suggest standarizing filenaming scheme too. What I do in some packages is to name the patches as follows: 0xxx-name.patch -> Grabbed from upstream VCS 1xxx-name.patch -> Interesting for submission upstream 2xxx-name.patch -> Debian-specific The Status field is then no longer needed, since patches in 1xxx should be moved into 0xxx when accepted upstream, or into 2xxx if rejected for non- cosmetic reasons (ie, the purpose of the patch is not accepted, not just the current form). This has the added benefit that patches submitted upstream have a greater chance of applying cleanly against the current HEAD of development. The Origin field becomes optional too. > > * `Status` (optional) > > This field is a textual explanation of its status concerning its > inclusion in the upstream project. The first line should consist of a > single keyword among "-specific" (the patch must not be > forwarded as it is specific to a vendor, ex: branding patches), > "must-be-forwarded" (nobody has taken the time to forward the patch > yet), "forwarded" (the patch has been forwarded, the Bug or Patch > fields should contain the corresponding URLs) or "rejected" (the patch > has been submitted but it has been rejected upstream). Supplementary > lines can be used to explain in more details the status of the patch. > It should be used for example to explain why the patch has been > rejected, or why this change is only meaningful for the vendor. This field misses a value for patches picked from upstream VCS. > Interpretation > -- > > In the analysis of the meta-information, a certain number of related > facts can be deduced from the absence, presence, or combinations of fields > and their values. > > * Has the patch been forwarded upstream? > > If there is a `Status` field, its value answers the question. > If there's an `Origin` field and it contains "upstream" or "backport", > the patch comes from upstream and it doesn't need to be forwarded. > The same is true if there's a `Commit` field. > In other cases, if there is a `Bug` field, then the patch has most > likely been referenced in the bug and upstream should know about it. > Any package maintainer should ensure that the existence of the patch > has been documented in the upstream bug log when he adds the > patches' meta-information. I think answering a simple question (and one of the most likely to be asked about a patch) should be done by a simple rule. The Status field should be sufficient for this. Introduce a picked-from-upstream value for the Status field and then we are done. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
Le Mon, Jun 15, i2009 at 06:12:49PM +0200, Raphael Hertzog a écrit : >Title: Patch Tagging Guidelines >DEP: 3 >State: DRAFT >Date: 2009-06-12 >Drivers: Raphael Hertzog >URL: http://dep.debian.net/deps/dep3 >Abstract: > Meta-information embedded in patches applied to Debian > packages > * `Description` (required) > * `Origin` (required) > * `Bug-` or `Bug` (optional) > * `Patch` (optional) > * `Commit` (optional) > * `Status` (optional) > * `Signed-off-by` (optional) Bonjour Raphaël, in the Debian Med packaging team, we use a similar approach for many of our packages: * Author (optional) * Description (optional) * Forwarded (optional) * License (optional) In ‘Description’ we put everything that would be in Patch, Commit and Bug. ‘Forwarded’ sometimes uses a short/long semantic à la debian/control, where the first line contains either ‘no’, an URL or an email address, and the following lines an optional long comment explaining for instance why the patch has not been forwarded. The dh_make template for debian/copyright induces many developers to put their packaging work under the GPL, and I have already seen packages whose license is otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and the patch is non-trivial, then in theory if we want to respect what is written, we are stuck with a GPL'ed patch. Therefore, we have an optional License field to make things crystal clear if necessary. I guess that other teams and individual developers use other variants. Thanks for your effort to unifiy the format. Personally, I do not mind changing our local format for the DEP3 format as long as we have one release cycle to do it. Some of our packages have a very slow turnover. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: good way to change a name of a package
On Mon, 15 Jun 2009, Atsuhito Kohda wrote: > Hi all, > > I've maintained ttf-mathematica4.1 but it was obsolete > now (for MathML and for Mathematica also) but someone has > requested me to keep maintenance of a package for Mathematica > fonts. > > I've not so good motivation for it but I build a new package > for Mathematica fonts named mathematica-fonts which installs > the latest type1, ttf Mathematica fonts which could be useful > for a Mathematica user from remote terminal. > > In this situation, is it enough for me to upload a new > mathematica-fonts package (as only version up) or is there > anything I should do before uploading? > > I think an obsolete ttf-mathematica4.1 is very annoying for Debian > and it should be replaced with mathematica-fonts or removed > completely as soon as possible. > Hi there, If I understood correctly, you could add a new package entry declaring ttf-mathematica as dummy package with a dependency on mathematica-fonts, and mathematica-fonts with replaces, provides and conflicts to ttf-mathematica. (Note that these fields should be compared to the latest version of ttf-math). Here's an example of how to do that: http://wiki.debian.org/Renaming_a_Package Regards -- JID: lavaram...@jabber.org | http://lusers.com.ar/ 2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 10:15:16PM +0100, Mark Brown wrote: > On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote: > > > I currently don't see a relevant benefit in this above just using the > > changelog entry, which you need to write anyway. Additional information > > Putting the information in the changelog makes it much harder to find Yes, putting the information _only_ in the changelog make it much harder to find, but that is not what I did nor what I proposed. As you can see, my patch header is a copy of the changelog entry, so you don't even need to open the changelog file to get all relevant information. I proposed a free text format which should include specified information, whether this is a git like header, a copy of the changelog entry or anything else does not matter as long as it is readable and understandable. If an integration of the information in the patch headers into UDD would be planned which could be used to query patches not applied upstream or similar, I would at least see a benefit in using a standard header format. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 2009-06-15, Raphael Hertzog wrote: > Hello, > > please find below a first draft of DEP-3 that I called Patch Tagging > Guidelines. The idea is to standardize a set of meta-information to embed Wouldn't a better first goal be to have just a freeform text field ? With the current amount of comments in the patches of random packages I touch, just a oneliner would be a significatn improvement. AS long as not a major part of debian people comment their patches, the format really doesn't matter. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 11:10:14PM +0200, Carsten Hey wrote: > I currently don't see a relevant benefit in this above just using the > changelog entry, which you need to write anyway. Additional information Putting the information in the changelog makes it much harder to find when looking at a package source than if it's right there in the patch file - you need to look the patch up in the changelog and if the patch is revised or otherwise changes state over time you need to figure out what the current state is somehow. It's a similar idea to saying that code should be adequately commented - the revision control history should say what's going on too but it shouldn't be essential to reading the code. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: > please find below a first draft of DEP-3 that I called Patch Tagging > Guidelines. The idea is to standardize a set of meta-information to embed > in patches that we apply. Please review, share your comments and ideas of > enhancements. I currently don't see a relevant benefit in this above just using the changelog entry, which you need to write anyway. Additional information like the author of the patch or a note like "this is Debian specific, don't merge" can also be included in a changelog file if this is relevant, as I did in the following example: debian/changelog: pal (0.4.3-2) unstable; urgency=low * debian/watch: use QA redirector. * Added a new Debian specific patch which changes the path to example.css in pal.1. Debian installs this file into a different location than upstream's makefile target install-doc. (Closes: #497874) -- Carsten Hey Sat, 06 Sep 2008 07:13:08 +0200 debian/patches/50_debian_fix_example_path_in_manpage.patch: pal (0.4.3-2) * Added a new Debian specific patch which changes the path to example.css in pal.1. Debian installs this file into a different location than upstream's makefile target install-doc. (Closes: #497874) --- pal.orig/pal.1.template ... If you get the relevant information from git or any other source this is in my opinion also ok, as long as the header format is easy to parse for humans. Standardizing the format would be a must if this information should be parsed by computers, do you have any plans in this direction? I think there should be a consent _which_ information should be included in patch headers, but unless they must be parsed by machines a standard which defines _how_ these information should be presented just adds unnecessary work for the maintainers. For a definition which information should be in a header your proposal could act as a very good basis, but there should IMHO some defaults which fit in most cases, e.g. when no author is mentioned the current Debian maintainer is the author and the patch is assumed to be Debian originated unless noted otherwise. > - in format "3.0 (quilt)" dpkg-source would create initial headers > respecting this format automatically based on the changelog when it > creates a new patch Not everyone lets dpkg create new patches. Different maintainers, different workflows ... Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, 2009-06-15 at 21:37 +0200, Joerg Jaspert wrote: > On 11782 March 1977, Raphael Hertzog wrote: > > > This is a proposal to formalize a set of meta-information > > to be embedded in patches applied to Debian packages. Most > > patch systems allow for a free-from description preceeding > > the content of the patch and the plan is to make use of that > > space to embed some structured content. > > It does sound a *little* overengineered for no good reason. (IMO). > > How about starting to do that for your own packages and see how it works > out. If it turns out to be great people will join and it will spread and > at some point be something we could even enforce. Would also give this a > little practice test to see if what you want from people is worth the > work/trouble dealing with it. We have been using something very similar to this in parts of Ubuntu for a while now (the wiki page on it is referenced in the DEP). I for one find it to be very useful and wish that it was more widespread. Yes, there can be a few fields for each patch, but you generally have the relevant links to hand when you are adding a patch anyway. There is growing use of the tags within Ubuntu, so there are obviously others that agree that it is useful. Whether Debian Developers wish to use it is obviously up to them, but I would think that this is one case where standardisation is very useful, even if it is the cart leading the horse to some extent. I need to re-read the DEP; I may have some suggestions about the content, but I agree whole-heartedly with the intent. I will also talk to people from other distributions about adopting the same fields. Thanks, James -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On 11782 March 1977, Raphael Hertzog wrote: > This is a proposal to formalize a set of meta-information > to be embedded in patches applied to Debian packages. Most > patch systems allow for a free-from description preceeding > the content of the patch and the plan is to make use of that > space to embed some structured content. It does sound a *little* overengineered for no good reason. (IMO). How about starting to do that for your own packages and see how it works out. If it turns out to be great people will join and it will spread and at some point be something we could even enforce. Would also give this a little practice test to see if what you want from people is worth the work/trouble dealing with it. -- bye, Joerg > What would you do if you wanted to retire from the project? This is far easier than to get in! ;) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Removal of fc-cache calls in postinsts
Le lundi 15 juin 2009 à 17:59 +0200, Christian Perrier a écrit : > Quoting Josselin Mouette (j...@debian.org): > > Hi, > > > > since version 2.6.0-4, fontconfig includes a trigger that will re-run > > fc-cache whenever needed. > > > > Therefore, all font packages that currently do this in the postinst are > > strongly advised to remove these calls. The performance gains during > > upgrades should be huge. > > > Maybe such test could be added to lintian? The next paragraph said: I’ve requested a new lintian check, and here is the list of affected packages. That’s #532984. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Let’ s turn DEP5 into something useful
On Sat, 13 Jun 2009, Mike Hommey wrote: > On Sat, Jun 13, 2009 at 10:06:31AM +0100, Neil Williams wrote: > > Requiring any details of precisely which files are affected makes the > > whole thing impossible because that requires some form of mass-update > > (or at least mass check of individual files) at every upstream release. > > Let's just drop the whole idea for Files: - if some packages find it > > useful, then the Files: field can be optional but it cannot be sensible > > to mandate it for large upstream teams. > > Plus, the per-file copyright information doesn't reflect anything > for binary packages, since they refer to source files. And per > source file licensing information is available in the source > tarball, where the copyright file has no use. The main reason to include per-file copyright information in the copyright file is to make sure that you've actually examined the copyright of all of the files and to allow for automatically generated[1] machine-readable copyright files to be updated sanely. The per-file copyright information should not be mandated, but the standard should allow for it to be present for the above reasons. Don Armstrong 1: We probably won't ever reach 100% automation, but the more it's possible to generate and update the copyright file automatically, the easier it is for maintainers to generate and maintain them. Ideally the machine-readable files will be so easy to generate that people will transition simply because it wastes less time. -- I'd sign up in a hot second for any cellular company whose motto was: "We're less horrible than a root canal with a cold chisel." -- Cory Doctorow http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533229: O: ctorrent -- BitTorrent Client written in C++
Package: wnpp Severity: normal X-Debbugs-CC: debian-devel@lists.debian.org As the maintainer of ctorrent is not available since over a year referring to the ctorrent uploader I am hereby orphaning this package. Description: BitTorrent Client written in C++ This application is written in the C++ language and doesn't require any graphical component, such as an X server. Original ctorrent's upstream has stopped its development and now it's kept updated with new releases/bug fixes by a new developer. It's built as a console program and it can be even used remotely in a machine that provides outside ssh access. Other main features are: . * Support for large files (>2GB) and large torrents (>255 files). * Strategic selection of pieces to request for download. * Continuous queueing of download requests, tuned based on latency and throughput for each peer. * Improved download performance, including parallel requests in initial and endgame modes. * Improved bandwidth regulation. * Improved compatibility with other peers. * Performance optimization and bug fixes. * An interface for monitoring and managing multiple clients. * Dynamic cache allocation and management, including prefetch. . Homepage: http://ctorrent.sourceforge.net/ . See also: http://www.rahul.net/dholmes/ctorrent/ Maintaining a package requires time and skills. Please only adopt this package if you are *sure* you will have enough time and attention to work on it. If you want to be the new maintainer, please see http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions how to adopt a package properly. Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgp9SfK8l9vBU.pgp Description: PGP signature
Re: Bug#526489: Time to orphan eclipse? (Bug#526489: eclipse: should this package be orphaned?)
Ana Guerrero schrieb: > On Wed, May 20, 2009 at 01:40:49AM +0200, Ana Guerrero wrote: >> I filed the quoted report almost 3 weeks ago. Resending to people listed as >> eclipse uploaders in case they did not get it. >> > > Third and last warning, I will orphan eclipse next saturday (20th June), so if > somebody from the Java team is interested, please step up now. please wait until afer debconf with orphaning the package. there might be some interest. > Usually, I > would have orphaned the package already, but I was hoping from somebody from > the > team take over it. Sadly, I did not get a word from any of the uploaders (a > "i am not > longer interested" email would have been nice) or from somebody else from the > team. > > For the record, even if the last version we have in Debian is 3.2.2, there was > some work done (from one year ago) in the SVN for the version 3.4: > http://svn.debian.org/wsvn/pkg-java/trunk/eclipse/debian/?op=log&rev=0&sc=0&isdir=1 care to help with this? the problem with eclipse is that everybody seems to start his/her own packaging and gets stuck with it. Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: intent to hijack turbogears 2 (and some of its friends)
Stefano Zacchiroli wrote: > Given that the maintainer (Cc-ed) has not replied to any of the above > bug reports---the latter is 7-month old---I'm hereby notifying my > intention to hijack both turbogears 2 and turbojson. as stated in the wnpp bug when i took over, my only interest in turbogears is that a) it doesn't get away (and that quickly >= 1.0.7 got available), and b) openerp-web-client uses it. now that openerp-web-client will get ported away from turbogears 1.x to cherrypy-only, it's not on my priority list anymore. therefore, please take over the packages. Regards, Daniel -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Removal of fc-cache calls in postinsts
Quoting Josselin Mouette (j...@debian.org): > Hi, > > since version 2.6.0-4, fontconfig includes a trigger that will re-run > fc-cache whenever needed. > > Therefore, all font packages that currently do this in the postinst are > strongly advised to remove these calls. The performance gains during > upgrades should be huge. Maybe such test could be added to lintian? signature.asc Description: Digital signature
Re: intent to hijack turbogears 2 (and some of its friends)
On Mon, Jun 15, 2009 at 19:13, Stefano Zacchiroli wrote: ... > Given that the maintainer (Cc-ed) has not replied to any of the above > bug reports---the latter is 7-month old---I'm hereby notifying my > intention to hijack both turbogears 2 and turbojson. > > Comments, about either approval or disapproval of this intended > action, are more than welcome. Yay, go for it!! Thanks a lot for the work you did/do/will do :) . Cheers, -- 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-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
intent to hijack turbogears 2 (and some of its friends)
[ I'm not subscribed to -python, please Cc me if you reply only there ]
Hi all,
as some of you might know from planet already [1,2,3,4], I've been
working on the packaging of turbogears 2 [5] recently.
Fact is, turbogears 2 was already packaged in Debian, but was
unusable. The main reasons were #530879 and, transitively,
#507909. Both cases show that both turbogears and turbojson were
uploaded to unstable, but nevertheless were lacking several of their
dependencies in the Debian archive. My work thus far have been on
packaging such dependencies, relying on the experimental archive.
Now, to get turbogears 2 actually working [6], I'm at the point that I
need to actually upload at least turbojson, but soon thereafter also
turbogears 2.
Given that the maintainer (Cc-ed) has not replied to any of the above
bug reports---the latter is 7-month old---I'm hereby notifying my
intention to hijack both turbogears 2 and turbojson.
Comments, about either approval or disapproval of this intended
action, are more than welcome.
Cheers
PS the work I've done thus far has been under the umbrella of the
Debian Python Module Team, with me as the only Uploader. If you are
interested in helping out, I'm more than open to have other
Uploaders, just let me know.
[1]
http://upsilon.cc/~zack/blog/posts/2009/05/kick-starting_turbogears_2_packaging/
[2] http://upsilon.cc/~zack/blog/posts/2009/06/turbogears_2_packaging_-_take_2/
[3] http://upsilon.cc/~zack/blog/posts/2009/06/turbogears_2_packaging_-_take_3/
[4] http://upsilon.cc/~zack/blog/posts/2009/06/turbogears_2_packaging_-_take_4/
[5] http://www.turbogears.org/
[6] ... and actually also to get turbogears *1* working again, since
the turbojson bug have broken also version 1, which was working in
Lenny
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: RFC: DEP-3: Patch Tagging Guidelines
Le lundi 15 juin 2009 à 18:12 +0200, Raphael Hertzog a écrit : > * `Patch` (optional) > > URL pointing to the patch. It can be in a VCS web interface, > a BTS attachment, etc. If the patch is available in the upstream VCS > or BTS, those URLs take precedence. Maintaining this information up-to-date can be troublesome. > * `Status` (optional) > > This field is a textual explanation of its status concerning its > inclusion in the upstream project. The first line should consist of a > single keyword among "-specific" (the patch must not be > forwarded as it is specific to a vendor, ex: branding patches), > "must-be-forwarded" (nobody has taken the time to forward the patch > yet), "forwarded" (the patch has been forwarded, the Bug or Patch > fields should contain the corresponding URLs) or "rejected" (the patch > has been submitted but it has been rejected upstream). Supplementary > lines can be used to explain in more details the status of the patch. > It should be used for example to explain why the patch has been > rejected, or why this change is only meaningful for the vendor. Same here. At the moment a package is uploaded, it can be must-be-forwarded, then later it becomes forwarded and later on it can change again. Which means a lot of additional commits, and that the version in sid can be easily outdated. It’s not that we can’t live with these issues, but we need to be aware of that. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFC: DEP-3: Patch Tagging Guidelines
On 15/06/09 at 18:12 +0200, Raphael Hertzog wrote: > Hello, > > please find below a first draft of DEP-3 that I called Patch Tagging > Guidelines. The idea is to standardize a set of meta-information to embed > in patches that we apply. Please review, share your comments and ideas of > enhancements. Thanks a lot for starting the discussion on this. I think that standardizing on this would really help Debian and the free software community as a whole. > * `Bug-` or `Bug` (optional) > > It contains one or more URLs (space separated) pointing to the related > bugs > (possibly fixed by the patch). The `Bug` field is reserved > for the bug URL(s) in the upstream bug tracker. What about using Debian: (like Ubuntu's Patch Tagging Guidelines) to indicate which Debian bug is fixed by this patch? > * `Status` (optional) Why optional? > * `Signed-off-by` (optional) I don't think that this field is necessary. If people want to credit other people in their patches, they can do so in the Description:. I Think that there's one field missing: DebianSpecific. This field would indicate why the patch is Debian-specific, and should not be forwarded upstream. Thanks again, -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
On Mon, Jun 15, 2009 at 06:12:49PM +0200, Raphael Hertzog wrote: > * `Signed-off-by` (optional) > > This field can be used to document the fact that the patch has been > reviewed by one or more persons. It should list their names and > emails in the standard format (similar to the example given for > the `Origin` field), separated by commas if needed. For the avoidance of confusion I would suggest that this be changed to Reviewed-by - the normal Linux/git Signed-off-by has a specific meaning that needn't include actually doing a code review. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#526489: Time to orphan eclipse? (Bug#526489: eclipse: should this package be orphaned?)
Thanks for dropping an answer... On Mon, Jun 15, 2009 at 06:18:06PM +0200, Matthias Klose wrote: > Ana Guerrero schrieb: > > On Wed, May 20, 2009 at 01:40:49AM +0200, Ana Guerrero wrote: > >> I filed the quoted report almost 3 weeks ago. Resending to people listed as > >> eclipse uploaders in case they did not get it. > >> > > > > Third and last warning, I will orphan eclipse next saturday (20th June), so > > if > > somebody from the Java team is interested, please step up now. > > please wait until afer debconf with orphaning the package. there might be some > interest. > uhm, I fail to see what debconf is going to change with respect this situation :? > > Usually, I > > would have orphaned the package already, but I was hoping from somebody > > from the > > team take over it. Sadly, I did not get a word from any of the uploaders (a > > "i am not > > longer interested" email would have been nice) or from somebody else from > > the > > team. > > > > For the record, even if the last version we have in Debian is 3.2.2, there > > was > > some work done (from one year ago) in the SVN for the version 3.4: > > http://svn.debian.org/wsvn/pkg-java/trunk/eclipse/debian/?op=log&rev=0&sc=0&isdir=1 > > care to help with this? the problem with eclipse is that everybody seems to > start his/her own packaging and gets stuck with it. > Just doing some QA here, I am not a eclipse user :) Ana -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFC: DEP-3: Patch Tagging Guidelines
Hello, please find below a first draft of DEP-3 that I called Patch Tagging Guidelines. The idea is to standardize a set of meta-information to embed in patches that we apply. Please review, share your comments and ideas of enhancements. If (and once) we have consensus that it is good idea to standardize those information, we can take supplementary steps to ensure they are not forgotten and correctly filled: - lintian can advise using this format in quilt-patch-missing-description or dpatch-missing-description, it can also check for correctness when packages are trying to use of this format - in format "3.0 (quilt)" dpkg-source would create initial headers respecting this format automatically based on the changelog when it creates a new patch - fix some tools to correctly preserve those information (apparently cdbs-edit-patch is not wise enough to do this by default) - the developers-reference could be updated to recommend usage of this format The latest version of the DEP is on the web: http://dep.debian.net/deps/dep3/ Text version follows: Title: Patch Tagging Guidelines DEP: 3 State: DRAFT Date: 2009-06-12 Drivers: Raphael Hertzog URL: http://dep.debian.net/deps/dep3 Abstract: Meta-information embedded in patches applied to Debian packages Introduction This is a proposal to formalize a set of meta-information to be embedded in patches applied to Debian packages. Most patch systems allow for a free-from description preceeding the content of the patch and the plan is to make use of that space to embed some structured content. Motivation -- In order to ensure high-quality in the distribution, it's important to facilitate the review of patches that are applied to Debian packages. To achieve this task we must be able to browse the patches and discover some information about them (their origin/author, if they have been forwarded upstream, if they are meant to be debian specific or not, etc.). Thus the first step is to include those information in the patches when they are available so that tools like the [Patch Tracking System](http://patch-tracking.debian.net) can display them. Structure - The meta-information would be stored in a set of RFC-2822 compliant fields. Those fields should start on the first non-empty line (after having stripped whitespace characters at the start and end of lines). For patch-systems like dpatch that require the patch to be a standalone script, the shebang line is ignored and it is possible to put those fields in comments. The line should then follow the format "`# `". For multi-line fields, the subsequent lines should start with "`#` " (dash followed by two spaces) so that they start with a space once "`#` " (dash followed by a space) has been stripped from the beginning. The set of fields ends on the first empty line. Free-form comments can follow and be used for any other information that does not fit in the structured content. Standard fields --- In the following section, `` can be "Debian" or the name of any other distribution that tracks the same problem/patch. * `Description` (required) This obligatory field contains at least a short description on the first line. Supplementary lines can be used to provide a longer explanation of the patch. * `Origin` (required) This field should document the origin of the patch. It can have the following standard values: "upstream" (in the case of a patch cherry-picked from the upstream VCS), "backport" (in the case of an upstream patch that had to be modified to apply on the current version). Any other value is supposed to be free-form text describing the origin of the patch. It should typically be the name and email of the patch author (ex: "`John Bear `") or the project/company that she worked for when she authored the patch. * `Bug-` or `Bug` (optional) It contains one or more URLs (space separated) pointing to the related bugs (possibly fixed by the patch). The `Bug` field is reserved for the bug URL(s) in the upstream bug tracker. * `Patch` (optional) URL pointing to the patch. It can be in a VCS web interface, a BTS attachment, etc. If the patch is available in the upstream VCS or BTS, those URLs take precedence. * `Commit` (optional) One or more commit identifiers. This should only be used when the `Patch` field can't be used because the upstream project has no VCS web interface or similar restrictions. * `Status` (optional) This field is a textual explanation of its status concerning its inclusion in the upstream project. The first line should consist of a single keyword among "-specific" (the patch must not be forwarded as it is specific to a vendor, ex: branding patches), "must-be-forwarded" (nobody has taken the time to forward the patch yet), "forwarded" (the patch has been forwarded,
Bug#533175: ITP: hoogle -- A Haskell API search engine
Package: wnpp Severity: wishlist Owner: Erik de Castro Lopo * Package name: hoogle Version : 4.0.0.5 Upstream Author : Neil Mitchell * URL : http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hoogle * License : GPL Programming Lang: Haskell Description : A Haskell API search engine A Haskell API search engine, which allows searching of standard Haskell libraries by either function name, or by approximate type signature. . The hoogle execuatble relies on database files with the '.hoo' file extension which are generated from Haskell source code using Haddock. -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533173: ITP: madwimax -- user-space driver for mWiMAX equipment based on Samsung CMC-730
Package: wnpp Severity: wishlist Owner: Alexander Gordeev * Package name: madwimax Version : 0.1.0 Upstream Author : Alexander Gordeev * URL : http://code.google.com/p/madwimax/ * License : GPL Programming Lang: C Description : user-space driver for mWiMAX equipment based on Samsung CMC-730 madwimax is an experimental reverse-engineered Linux driver for mobile WiMAX (802.16e) devices based on Samsung CMC-730 chip. These devices are currently supported: * Samsung SWC-U200 * Samsung SWC-E100 * Samsung SWM-S10R (it is built in Samsung NC-10 netbook) . This package contains the user-space standalone implementation of the driver. It requires Universal TUN/TAP support in your kernel. -- System Information: Debian Release: 5.0.1 Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
good way to change a name of a package
Hi all, I've maintained ttf-mathematica4.1 but it was obsolete now (for MathML and for Mathematica also) but someone has requested me to keep maintenance of a package for Mathematica fonts. I've not so good motivation for it but I build a new package for Mathematica fonts named mathematica-fonts which installs the latest type1, ttf Mathematica fonts which could be useful for a Mathematica user from remote terminal. In this situation, is it enough for me to upload a new mathematica-fonts package (as only version up) or is there anything I should do before uploading? I think an obsolete ttf-mathematica4.1 is very annoying for Debian and it should be replaced with mathematica-fonts or removed completely as soon as possible. Regards,2009-6-15(Mon) -- Debian Developer - much more I18N of Debian Atsuhito Kohda Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
