Re: Help bts-link be a more effective tool
On Sat, 17 Jan 2009, Sandro Tosi wrote: > In recent bts-link runs, we noticed some errors. The log is available > at [2]: please take the time to give it a look, search for your > packages and check the situation. There are errors in that log that > might be ok, but others can refer to broken links, no more active > BTSes or any other possible situation. E: pkg=acpi-support, bug=388160, msg=Parse error: [https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/18864] No task affecting product acpi-support The URL given is fine… you should really improve bts-link understanding of Launchpad. The bug affects acpi-support inside Ubuntu and is certainly a valid way for us to track a bug. Before you decide to push out errors to maintainers via PTS (as I've seen mentionned), you should really improve the tool so that the only remaining errors are really user errors. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help bts-link be a more effective tool
On Mon, Jan 19, 2009 at 09:17:06AM +0100, Raphael Hertzog wrote:
> Before you decide to push out errors to maintainers via PTS (as I've seen
> mentionned), you should really improve the tool so that the only remaining
> errors are really user errors.
BTW, when that is done, please submit a wishlist bugreport on the PTS
requesting integration, *together* with a description of the parsing
rules of the error output of bts-link OR maybe a switch to a format
which can be parsed out of the box and is extensible, e.g., yaml.
The PTS is being polluted by tons of micro-parsers for the output of
the tools it monitor, a convergence at least on the surface syntaxes
would be nice to ease future maintenance.
(And yes, patches are always welcome :-))
Cheers.
--
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: Help bts-link be a more effective tool
Le lundi 19 janvier 2009 à 09:46 +0100, Stefano Zacchiroli a écrit : > The PTS is being polluted by tons of micro-parsers for the output of > the tools it monitor, a convergence at least on the surface syntaxes > would be nice to ease future maintenance. > Did you mean "The bts-link is polluted", above ? Regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Tracing bugs between distro's bugtrackers - Was: Re: Help bts-link be a more effective tool
Le lundi 19 janvier 2009 à 07:12 +0100, Christian Perrier a écrit : > Quoting Bastien ROUCARIES (roucaries.bast...@gmail.com): > > > > I really useful stuff will be to use user tag in order to crossref > > another distrib bugzilla. For instance some bug are fixed on redhat > > like #506180 but not upstream. > > It will allow to automatize retrieval of information. > > > Apparently, Launchpad has something like this, which is, for instance, > used to reference bugs also reported in Debian. We found this fairly > useful, recently, for Samba. > Any idea if they have some common interchange format for their bugs ? ... there looked like ideas about RDF export in the REST interface of launchpad... but that was not operational last tieme I've checked :( I'd be curious to see how such links between launchpad and debbugs would be represented, then. > > However, such feature should probably be included in the BTS itself > (new tag or something). > And : > FYI, that's the kind of features we're working on in the HELIOS > project > (more details here : > https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web ). > [...] > We're currently trying to evaluate work that has been conducted by > others in the Nepomuk project to find if ontologies and RDF are > interesting to allow the representation of such meta-data about bugs > and > links between bugs in standard format. > Oh, I forgot to mention, that we're more or less planing to work with Mandriva people (who worked for that Nepomuk-related bug store prototype) in Helios... so I hope we'll be able to provide more links between Mandriva bugs and Debian bugs (and upstream bugs). There would be some need for inter-distro work here, maybe... any ideas on where to discuss that much welcome ;) Regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Yet another list statistics for debian-devel
On Sun, Jan 18, 2009, Andreas Tille wrote: > Well, I recieved 3 contra and about 30 pro mails for what I've done. Presumably with my suggestion of mailing -project, and mentionning this in the developers news you might have reached even more people and received more "pro" mails, and you wouldn't have received my "contra" mail. ;-) > 2. The readers of mailing lists who show activity problems are > most probably and will not read -project or -devel so I > would not have reached them = I would have failed my basic > intention to reach problematic list. But they might read debian-news? > 3. I want to trigger discussion about my specific interpretation > of the list activity on the according list. What would you > suggest to approach this without spamming some lists that > perhaps does not need this trigger? As I suggested already, announce your efforts on a widely read channel; -project + -news, or -devel-announce if this is important. > 4. According to spam: As a side effect I've detected about 4500 > Spam mails in our archive. Do you consider sending one single > mail to about 30 list as excusable if I might help out to clean > up the archive from this mails as a punishment I deserve for > this misuse? Eh :) >> I've gotten basically the same template 12 times. > Thanks for your obviosely high activity in Debian for subscribing > 12 lists. Well you make it sound like it's a large number; these are relatively common lists: devel, project, vote some important ones for some aspects of the project: security, release, newmaint, testing, qa, policy, legal[*] and personal choices related to my interests: desktop, python I wouldn't be surprized if some hundreds of DDs are subscribed to >= 15 Debian lists. (I've been subscribed or am subscribed to ~80 alioth lists BTW and expect it to be the same for a bunch of other DDs as well.) Cheers, [*] Yeah I know -- Loïc Minier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Tracing bugs between distro's bugtrackers - Was: Re: Help bts-link be a more effective tool
Hi. Le dimanche 18 janvier 2009 à 19:54 +0100, Bastien ROUCARIES a écrit : > On Sat, Jan 17, 2009 at 8:36 PM, Sandro Tosi wrote: > > Hello, > > > If you feel something is missing, should be fixed or enhanced, let > > us[4] know; of course, patches are welcome ;) (git repo at [5]). > > I really useful stuff will be to use user tag in order to crossref > another distrib bugzilla. For instance some bug are fixed on redhat > like #506180 but not upstream. > It will allow to automatize retrieval of information. > FYI, that's the kind of features we're working on in the HELIOS project (more details here : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web ). We're thinking about helping navigate and manage bugs by allowing the navigation between various distros and upstream bugtrackers... I hope our efforts will benefit Debian through bts-link and other tools, of course. We're still just started and busy with lots of things, and nothing concrete do demonstrate so far. We're currently trying to evaluate work that has been conducted by others in the Nepomuk project to find if ontologies and RDF are interesting to allow the representation of such meta-data about bugs and links between bugs in standard format. Of course the use of debbugs (user)tags is very interesting (compared to what exist in other bugtrackers) to store such elements, but we're thinking about devising something that would scale to the vast majority of bugtrackers used by the free software communities... so we probably need to think about an external store, and hence RDF standard format and such. Hope this makes sense ;) Best regards, P.S.: I'll probably join the FOSDEM, so I hope I'll have the chance to discuss that with some of you bugtracking gurus :-) -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help bts-link be a more effective tool
On Mon, Jan 19, 2009 at 7:12 AM, Christian Perrier wrote: > Quoting Bastien ROUCARIES (roucaries.bast...@gmail.com): >> On Sat, Jan 17, 2009 at 8:36 PM, Sandro Tosi wrote: >> > Hello, >> >> > If you feel something is missing, should be fixed or enhanced, let >> > us[4] know; of course, patches are welcome ;) (git repo at [5]). >> >> I really useful stuff will be to use user tag in order to crossref >> another distrib bugzilla. For instance some bug are fixed on redhat >> like #506180 but not upstream. >> It will allow to automatize retrieval of information. > > > Apparently, Launchpad has something like this, which is, for instance, > used to reference bugs also reported in Debian. We found this fairly > useful, recently, for Samba. Yes it is useful :) > However, such feature should probably be included in the BTS itself > (new tag or something). Yes it will need I suppose cooperation from BTS itself but in a second time. We need only two user tags by foreign distrib: bts-link-foreign-xref-$distrib set to the foregin bugzilla entry bts-link-foreign-status-$distrib magically set by bts-link In a second time BTS interface could provide link near the forwarded link with status in other distrib (with a nice icon describing status) We will need also a means to put in the package describtion link to other distrib bugzilla, and we ease to remove duplicate entry :) Regards Bastien PS: do not trim cc please -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Tracing bugs between distro's bugtrackers - Was: Re: Help bts-link be a more effective tool
On Mon, 2009-01-19 at 10:46 +0100, Olivier Berger wrote: > There would be some need for inter-distro work here, maybe... any ideas > on where to discuss that much welcome ;) distributi...@lists.freedesktop.org would be a good place to start. http://lists.freedesktop.org/mailman/listinfo/distributions Thanks, James -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help bts-link be a more effective tool
On Mon, Jan 19, 2009 at 10:40:13AM +0100, Olivier Berger wrote:
> Did you mean "The bts-link is polluted", above ?
No, I did mean the PTS.
I've no idea whether that is true also for bts-link :)
--
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: Help bts-link be a more effective tool
On Mon, Jan 19, 2009 at 7:46 PM, Stefano Zacchiroli wrote: > BTW, when that is done, please submit a wishlist bugreport on the PTS > requesting integration, *together* with a description of the parsing > rules of the error output of bts-link OR maybe a switch to a format > which can be parsed out of the box and is extensible, e.g., yaml. > > The PTS is being polluted by tons of micro-parsers for the output of > the tools it monitor, a convergence at least on the surface syntaxes > would be nice to ease future maintenance. I submitted a feature request for the PTS that is similar: http://bugs.debian.org/509416 -- 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
Come join me on Mocazo Club
Mocazo Club: Come join me on Mocazo Club! Mocazo Click the link below to Join: http://club.mocazo.com/?xgi=vZHM3i If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser Members already on Mocazo Club Albertson Danim, stephanus, abhi, raghu, Bobby About Mocazo Club Welcome to Mocazo Club! the place for showcasing your talent, making friends & having some fun with your mobile. 2735 members 5225 photos 472 songs 426 videos 210 discussions 138 blog posts To control which emails you receive on the corner, or to opt-out, go to: http://club.mocazo.com/?xgo=pQ0Xf5Vs/P6Vkd2RBDcfHeiqBLOaCBpE8ovp-prwqWrN0b2boPBeFGFYUg0ICqfT5vyQbbH6a4A
Modifying debian/changelog entries
Hey, I have two separate, but related, questions not covered by policy: * If you are the only person mentioned in a changelog and you change your email address, when you do a new upload, is it okay to modify all of the old changelog entries to use the new email address? * Is it okay to occasionally modify old changelog entries for clarity and style, typos and such like, as long as you don't change the semantics? Thanks, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Modifying debian/changelog entries
On Mon, January 19, 2009 13:00, Noah Slater wrote: > I have two separate, but related, questions not covered by policy: > > * If you are the only person mentioned in a changelog and you change your > email address, when you do a new upload, is it okay to modify all of the > old changelog entries to use the new email address? I see no harm but also no gain in this. > * Is it okay to occasionally modify old changelog entries for clarity and > style, typos and such like, as long as you don't change the semantics? I would say that this is perfectly fine. The changelog is documentation of which changes happened between version n and m. If you can improve that documentation, I see no reason to leave it inferior. Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Tracing bugs between distro's bugtrackers - Was: Re: Help bts-link be a more effective tool
On Mon, Jan 19, 2009 at 10:36 AM, Olivier Berger wrote: > Hi. > > Le dimanche 18 janvier 2009 à 19:54 +0100, Bastien ROUCARIES a écrit : >> On Sat, Jan 17, 2009 at 8:36 PM, Sandro Tosi wrote: >> > Hello, >> >> > If you feel something is missing, should be fixed or enhanced, let >> > us[4] know; of course, patches are welcome ;) (git repo at [5]). >> >> I really useful stuff will be to use user tag in order to crossref >> another distrib bugzilla. For instance some bug are fixed on redhat >> like #506180 but not upstream. >> It will allow to automatize retrieval of information. >> > > FYI, that's the kind of features we're working on in the HELIOS project > (more details here : > https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web ). > > We're thinking about helping navigate and manage bugs by allowing the > navigation between various distros and upstream bugtrackers... I hope > our efforts will benefit Debian through bts-link and other tools, of > course. > > We're still just started and busy with lots of things, and nothing > concrete do demonstrate so far. > > We're currently trying to evaluate work that has been conducted by > others in the Nepomuk project to find if ontologies and RDF are > interesting to allow the representation of such meta-data about bugs and > links between bugs in standard format. > > Of course the use of debbugs (user)tags is very interesting (compared to > what exist in other bugtrackers) to store such elements, but we're > thinking about devising something that would scale to the vast majority > of bugtrackers used by the free software communities... so we probably > need to think about an external store, and hence RDF standard format and > such. Yes and it could work with minimal modification of bts-link: We need only two user tags by foreign distrib: bts-link-foreign-xref-$distrib set to the foregin bugzilla entry bts-link-foreign-status-$distrib magically set by bts-link If you go to fosdem, a working example of such a tool will be really useful :) After we could try to standardize this kind of stuff, but we need an example :) Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Tracing bugs between distro's bugtrackers - Was: Re: Help bts-link be a more effective tool
On Mon, Jan 19, 2009 at 10:46 AM, Olivier Berger wrote: > Le lundi 19 janvier 2009 à 07:12 +0100, Christian Perrier a écrit : >> Quoting Bastien ROUCARIES (roucaries.bast...@gmail.com): >> > >> > I really useful stuff will be to use user tag in order to crossref >> > another distrib bugzilla. For instance some bug are fixed on redhat >> > like #506180 but not upstream. >> > It will allow to automatize retrieval of information. >> >> >> Apparently, Launchpad has something like this, which is, for instance, >> used to reference bugs also reported in Debian. We found this fairly >> useful, recently, for Samba. >> > > Any idea if they have some common interchange format for their > bugs ? ... there looked like ideas about RDF export in the REST > interface of launchpad... but that was not operational last tieme I've > checked :( > > I'd be curious to see how such links between launchpad and debbugs would > be represented, then. See previous proposal :) >> >> However, such feature should probably be included in the BTS itself >> (new tag or something). >> > > And : >> FYI, that's the kind of features we're working on in the HELIOS >> project >> (more details here : >> https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web ). >> > > [...] > >> We're currently trying to evaluate work that has been conducted by >> others in the Nepomuk project to find if ontologies and RDF are >> interesting to allow the representation of such meta-data about bugs >> and >> links between bugs in standard format. >> > > Oh, I forgot to mention, that we're more or less planing to work with > Mandriva people (who worked for that Nepomuk-related bug store > prototype) in Helios... so I hope we'll be able to provide more links > between Mandriva bugs and Debian bugs (and upstream bugs). Mandriva use bugzilla and therefore bts-link will retrieve this kind of bug :) > There would be some need for inter-distro work here, maybe... any ideas > on where to discuss that much welcome ;) Yes I agree, but I believe that it will need less than fifty line of code in bts-link :) So it will take more time to discuss than to code :) Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Modifying debian/changelog entries
On Mon, 19 Jan 2009, Noah Slater wrote: > * If you are the only person mentioned in a changelog and you change your > email address, when you do a new upload, is it okay to modify all of the > old > changelog entries to use the new email address? I wouldn't. > * Is it okay to occasionally modify old changelog entries for clarity and > style, typos and such like, as long as you don't change the semantics? The occassional fix for the previous few changelog entries is probably fine. Cheers, weasel -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Modifying debian/changelog entries
On Mon, Jan 19, 2009 at 01:06:53PM +0100, Thijs Kinkhorst wrote: > On Mon, January 19, 2009 13:00, Noah Slater wrote: > > I have two separate, but related, questions not covered by policy: > > > > * If you are the only person mentioned in a changelog and you change your > > email address, when you do a new upload, is it okay to modify all of the > > old changelog entries to use the new email address? > > I see no harm but also no gain in this. Sure. Doing so satisfies my OCD need for consistency though. Heh heh. > > * Is it okay to occasionally modify old changelog entries for clarity and > > style, typos and such like, as long as you don't change the semantics? > > I would say that this is perfectly fine. The changelog is documentation of > which changes happened between version n and m. If you can improve that > documentation, I see no reason to leave it inferior. I agree completely. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Modifying debian/changelog entries
On Mon, Jan 19, 2009 at 5:30 PM, Noah Slater wrote: > * If you are the only person mentioned in a changelog and you change your >email address, when you do a new upload, is it okay to modify all of the > old >changelog entries to use the new email address? It is better that you leave as it is. Changelog should tell exactly who did what (even if its you alone) :P > * Is it okay to occasionally modify old changelog entries for clarity and >style, typos and such like, as long as you don't change the semantics? Its fine when you mention in last changelog. Specially, I fix typos too often! -- Cheers, Kartik Mistry | 0xD1028C8D | IRC: kart_ Homepage: people.debian.org/~kartik Blog.en: ftbfs.wordpress.com Blog.gu: kartikm.wordpress.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512322: ITP: lua-metalua -- Metaprogramming language designed as a superset of Lua
Package: wnpp Severity: wishlist Owner: "John V. Belmonte" * Package name: lua-metalua Version : 0.5 Upstream Author : Fabien Feutot * URL : http://metalua.luaforge.net/ * License : MIT Programming Lang: Lua Description : Metaprogramming language designed as a superset of Lua Metalua is a metaprogramming language and a compiler which provide full compatibility with Lua 5.1 sources and bytecode. It offers a complete macro system similar in power to that offered by Lisp dialects or Template Haskell. Namely, manipulated programs can be seen as source code, abstract syntax trees, or an arbitrary mix thereof-- whichever suits your task better. It has a dynamically extensible parser, which lets you support your macros with a syntax that blends nicely with the rest of the language. A set of language extensions is also provided, all implemented as regular Metalua macros. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Une opportunité à saisir
Bonjour, Sans introduction ni exposé, cliquez sur ce lien , Vous ne le regretterez pas. http://www.1tpe.com/index-pro.php?p=arbisfaxi A votre succès SFAXI ARBI Votre Editeur Internet Si vous ne voulez plus recevoir d’emails de ma part , cliquez sur le lien ci-dessus : arbisfe...@yahoo.fr
Re: Modifying debian/changelog entries
Noah Slater writes: > On Mon, Jan 19, 2009 at 01:06:53PM +0100, Thijs Kinkhorst wrote: > > On Mon, January 19, 2009 13:00, Noah Slater wrote: > > > * If you are the only person mentioned in a changelog and you > > > change your email address, when you do a new upload, is it okay > > > to modify all of the old changelog entries to use the new email > > > address? > > > > I see no harm but also no gain in this. > > Sure. Doing so satisfies my OCD need for consistency though. Heh > heh. Surely consistency would argue *against* changing the historical record? When those releases were made, the email address was as recorded at the time. That it changed later should not alter the existing factual record on earlier entries. No? -- \ “Don't be afraid of missing opportunities. Behind every failure | `\ is an opportunity somebody wishes they had missed.” —Jane | _o__) Wagner, via Lily Tomlin | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Modifying debian/changelog entries
On Mon, Jan 19, 2009 at 01:20:17PM +0100, Peter Palfrader wrote: > > * Is it okay to occasionally modify old changelog entries for clarity and > > style, typos and such like, as long as you don't change the semantics? > > The occassional fix for the previous few changelog entries is probably > fine. In fact, I can think of one case where I'd actually encourage it. We occasionally update packages to solve security issues before a CVE number for the particular vulnerability is known. Retroactively modifying the changelog to include the CVE number, once it's known, helps to resolve any doubt about the specifics of the issue. noah signature.asc Description: Digital signature
Re: Modifying debian/changelog entries
On Tue, Jan 20, 2009 at 09:07:06AM +1100, Ben Finney wrote: > > Sure. Doing so satisfies my OCD need for consistency though. Heh > > heh. > > Surely consistency would argue *against* changing the historical > record? When those releases were made, the email address was as > recorded at the time. That it changed later should not alter the > existing factual record on earlier entries. No? Well, I guess it depends what your personal æsthetic is. I like per-file consistency over (arguably unimportant) historical correctness. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512353: ITP: lib-com-stevesoft-regex-java -- regular expression library for Java
Package: wnpp Severity: wishlist Owner: Vincent Fourmond * Package name: lib-com-stevesoft-regex-java Version : 1.5.3 Upstream Author : Steven R. Brandt * URL : http://www.javaregex.com/home.html * License : LGPL Programming Lang: Java Description : regular expression library for Java This is a regular expression for Java. It is needed for the jalview program. This is one of the dependencies of Jalview which don't have equivalents in debian. Source files can be found there: http://www.javaregex.com/binaries/patsrcfree153.jar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hosting the Debian/kCygwin port?
Hey lists, I'm working on a project porting the Debian tools to Cygwin. Currently, my plan is to: - Provide some required patches to the Cygwin team, for example to allow a file in use to be removed or modified, since this is required for dpkg - Re-compile all packages and patches currently available for Cygwin into a Debian .deb - Provide either a way to bootstrap Debian onto an existing Cygwin installation, or provide installers for a pure Debian/kCygwin installation. Now I'm wondering where to host this project. I've been thinking about three locations: Sourceforge, Debian or Cygwin. I've filed a project takeover request for Sourceforge, but the original project admin seems to work against me a little and it doesn't seem "fit" to release there. Since the largest part of the project would be the packages in their new Debian source and binary forms, I at least need an apt repository. The Debian project already has the structure for that, but the Cygwin packages are different from their Debian counterparts (think patches), and I'm not sure how that happens with other ports. debian-devel, is this a problem? Also, I don't know if the Cygwin team may be willing to host this project. They have their own packages and manager, and may not be willing to host this alternative, even if it works great in a few weeks time. Cygwin list, what do you think? Thanks, Sjors -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Hosting the Debian/kCygwin port?
Sjors Gielen, le Tue 20 Jan 2009 00:49:29 +0100, a écrit : > I'm working on a project porting the Debian tools to Cygwin. Ususally ports are hosted by debian-ports.org. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help bts-link be a more effective tool
On Mon, Jan 19, 2009 at 10:50 AM, Bastien ROUCARIES wrote: >ll need I suppose cooperation from BTS itself but in a second > time. We need only two user tags by foreign distrib: > bts-link-foreign-xref-$distrib set to the foregin bugzilla entry > bts-link-foreign-status-$distrib magically set by bts-link > > In a second time BTS interface could provide link near the forwarded > link with status in other distrib (with a nice icon describing status) > > We will need also a means to put in the package describtion link to > other distrib bugzilla, and we ease to remove duplicate entry :) I downloaded git source but I have some problem. How can I test some stuff on BTS? I does not include a sandbox package (see bug 435...@bugs.debian.org) How can we test improvement? Regards Bastien > PS: do not trim cc please > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512360: RFH: openldap -- OpenLDAP server, libraries, and utilities
Package: wnpp Severity: normal The OpenLDAP packaging for Debian could use additional resources. No one on the current OpenLDAP maintenance team has very much time to work on the package, and we're having difficulty keeping up with both the bug queue and with upstream releases and fixes. Given that this is a fairly critical package supplying both the LDAP libraries for many programs in Debian and the LDAP server used by other Debian projects, this is not a good situation. We particularly need help with: * Triaging Debian bugs, filing them upstream where needed, and helping test and incorporate upstream fixes. Upstream is very active and responsive, but expects careful attention to the existing documentation and separation of OpenLDAP bugs from bugs in Debian's build, configuration, or any local modifications. * Triage of TLS issues. For licensing reasons, Debian builds OpenLDAP with GnuTLS instead of OpenSSL, which is unusual in the broader OpenLDAP community. A lot of the open bugs are about TLS interoperability issues, which need to be analyzed and reported against either GnuTLS or upstream if they're problems with OpenLDAP's interface to GnuTLS. GnuTLS upstream is very responsive and good about helping with this if the bug can be reproduced. * Work on slapd configuration and maintenance. Upstream is converting to cn=config (an LDIF configuration backend) and away from slapd.conf and the Debian packages should do likewise. This will require extensive testing during the squeeze release cycle. * Testing, particularly of the server. Help from someone who runs the Debian slapd packages in production with a fairly large directory, or who can do so at least for testing, would be very welcome. The upstream OpenLDAP team has had many bad experiences with distribution packagers doing a poor job of supporting OpenLDAP packages and the OpenLDAP project doesn't support old versions of OpenLDAP, so it's important to carefully distinguish between Debian problems (including those related to having an old version in stable) and upstream OpenLDAP problems. Having a thick skin and a willingness to work through conflicts is very helpful. OpenLDAP is maintained via an Alioth Subversion repository and mailing list. If you're willing to help, please join the mailing list via: http://lists.alioth.debian.org/mailman/listinfo/pkg-openldap-devel and let us know what you can work on. Bug triage is a great place to start. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
