Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit : > > run a CI before uploading, even a very basic one is just fine, better > than nothing. Thanks for the remider ! I will have a closer look at Salsa CI instead of trying to understand how to run autopkgtests locally. Would there be a way to get Salsa upload and tag the package if the CI tests pass and the changelog signals a release? Or does somebody has a script which can screen a Salsa group for ready uploads, and run clone && buildpackage && dput automatically ? Cheers, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Le Sat, Jul 27, 2024 at 03:38:40PM -0700, Otto Kekäläinen a écrit : > > I have drafted a new DEP at > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > Enable true open collaboration on all Debian packages". Hi Otto, thank you for your initiative, one problem I have with NMUs in team-maintained package is that they often bypass Salsa… Would it make sense to add to the DEP a request that NMUs are started from and pushed to the default branch? Have a nice week-end, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Removing more packages from unstable
Le Tue, Aug 20, 2024 at 07:28:52AM +0200, Helmut Grohne a écrit : > > please allow me to open a can of worms. Package removal from unstable. Hi all, I think that package removal from Unstable, total or partial (for instance, 32-bit architectures) should be an automated self-sevice system for leaf packages. And it should be permitted to batch-request transitive leaf package removals where B becomes leaf after A is removed. As of today, removing a package involves mailing the BTS and therefore not knowing if the message arrived until the acklonledgement is received, and not knowing when the acknowledgement will be sent. Then the waiting time for the action is undetermined. Then the acknowledgement message for removal can arrive together with a couple hundred emails like mass-bug-fillings (like GCC updates) and autoremoval warnings, with the risk of of deleting the important information together with the batch. So as of today, it is much less work to keep a package rotting than removing it. Maybe interface for the self-service system could be a simple text file in a Salsa repository writeable to all DDs. This would provide obvious accountability, and allow filters and monitoring to be implemented if needed. Have a nice day, Charles
Re: Bits from DPL
Following what I wrote on removals and the discussion on DEP 18, I think that the following would be very neat: - Packages are on Salsa, - moving the source repository to a special group called 'removed' removes the package from Unstable. - reverting the move of the source repository reverts the removal. - people with insufficient privileges ask for removal with a Salsa issue. - people abusing the system get signalled to the community team who can propose the people to be reomoved from Salsa by the Salsa admins or from Debian by the DSA. Unfortunately, architecture-specific removals can not be done under this pattern, but maybe it could be automated that anything depending on architecture-is-64-bit gets removed from i386, armel and armhf for instance? Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Re: DEP5 and spdx shortname of license
Hello everybody, > On Sun, 08 Sep 2024 at 09:49:39 +0200, Niels Thykier wrote: > > Is it really that valuable for us to have a delta here compared to what > > upstream projects would use? If I remember well, one of the reason for the divergence was that we really wanted a system describing license exceptions, so that we do not need to quote near-identical versions of the GPL two or three times in the same copyright files. Fortunately, SPDX has adopted such a system in the meantime. With the current version of the machine-readable debian/copyright file, we can already use SPDX identifiers as long as they do not clash with the Debian ones, and I am not aware of such a case. But I see the value of deprecating the Debian ones and align on SPDX. For this to happen I think that we need 1) proof of consensus and 2) host the update somewhere. Using the debian-policy pakcage like for version 1.0 would acheive both. Using the DEP process might help (or not) for 1). Le Sun, Sep 08, 2024 at 12:07:16PM +0100, Simon McVittie a écrit : > > That, and MIT (SPDX) vs Expat (DEP-5) for one particularly popular member > of the MIT/X11 license family, as used in Expat and many other projects. About saying MIT instead of Expat, I fully [1] agree [2]. 1: https://lists.debian.org/debian-project/2010/08/msg00109.html 2: https://lists.debian.org/debian-project/2011/12/msg00034.html Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Trivial bug on apt-file (Was : Re: Development standards for unstable)
On Thu, Jan 12, 2006 at 02:21:03PM +0100, Olaf van der Spek wrote : > > ... > > If a maintainer would not manage to respond to an RC bug for three months > > the package is obviousely not maintained and should be taken over by > > somebody else, IMHO. > > I wish something like that applied to all bugs. > There are packages that have seen little updates for months/years with > lots of wishlist bugs. Dear debian developpers, As suggested on the transient packages.debian.org homepage, I tried to use apt-file while the site is offline. However, apt-file has a bug in the definition of its dependancies, which makes it uninstable unless one manually installs curl before. Of course, this is trivial, but fixing this bug (251 days old) is also trivial. Then why complain ? I feel that it gives a bad image of debian, when it suggests to use a broken tool while another one is being repaired. So if you want a basic user to innocently raise the severity of the bug, so that a developper could NMU a fixed package, just drop me a mail. Best regards, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)
On Fri, Jan 13, 2006 at 04:47:33AM +1000, Anthony Towns wrote : > On Thu, Jan 12, 2006 at 06:48:38PM +0100, Luk Claes wrote: > > > But if you read this bug (#307833), you'd see that the maintainer doesn't > > > consider it a bug, and has documented why in the README file. > > It is a bug as the package is not usable without curl or wget installed. > > Though, I give him a chance to respond to my intention to NMU... > > An NMU is not the place to "fix" things that the maintainer has > specifically said aren't bugs. Dear Anthony, As stated by the Debian Policy Manual : "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." and "The Recommends field should list packages that would be found together with this one in all but unusual installations." Also, the debian BTS developer infos states : "serious is a severe violation of Debian policy (roughly, it violates a "must" or "required" directive), or, in the package maintainer's opinion, makes the package unsuitable for release." Apt-file will not be installed on an out-of the box debian by the command "apt-get install apt-file", because its depends field misses a dependancy on curl. However, declaring proper dependancies for the package is a "should", not a "must", so if a debian developper is free to creating uninstallable packages if he fancies this. In conclusion, you are right, apt-file sould not be fixed unless the maintainer accepts it. As complaining to the tech-ctte should not be done becaues I did not even try to contact the maintainer directly, I will either: - Forget about it, or - File a wishlist bug against packages.debian.org, or whatever appropriate, to suggest to stop suggesting the use of a broken package, or at least to mention the bug. In my opinion, it is a shame that the first workaround for the temporary unavailability of packages.debian.org is a broken package for which the fix is trivial and available since more than 200 days. This will comfort the people who think that debian made by arrogant experts, only for other experts who are comfortable at the command line, when they will read the bug report and the answers of the maintainer. Sébastien, please fix your bug ! Can you imagine Debian if all the packages, like yours, would need a manual inspection of the error messages to figure out on what it really depends ??? Best regards, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352506: ITP: treeviewx -- TreeView X displays and prints phylogenetic trees
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> * Package name: treeviewx Version : 0.5.1 Upstream Author : [EMAIL PROTECTED] * URL : http://darwin.zoology.gla.ac.uk/~rpage/treeviewx/ * License : GPL Description : TreeView X displays and prints phylogenetic trees TreeView X is an open source program to display phylogenetic trees on Linux, Unix, Mac OS X, and Windows platforms. It can read and display NEXUS and Newick format tree files (such as those output by PAUP*, ClustalX, TREE-PUZZLE, and other programs). It has a subset of the functionality of the version of TreeView available for the Mac Classic and Windows (it is roughly equivalent to version 0.95 of TreeView). . The program was written by Rod Page [EMAIL PROTECTED] using the wxWidgets C++ library. URL: http://darwin.zoology.gla.ac.uk/~rpage/treeviewx/ Note that TreeView X is neither TreeView [1] nor Java TreeView [2]. [1] http://rana.lbl.gov/EisenSoftware.htm [2] http://bugs.debian.org/243771 Note also that the binary name as chosen by the upstream author is 'tv'. Please complain if it could be annoying for a software you package, or intend to package. Best, -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Balancing the noise between -devel and -private?
Dear developpers, I have no idea of what is the traffic on debian-private, nor on the content of the messages there. But, for the sake of the signal/noise ratio on debian-devel, do you think that you could move most of the ad-hominem stuff on such a list? Also, in most social groups in most cultures, from the company to the rock band or the football club, critisism against insiders are not done in front of outsiders. The public trials are usually the hallmark of terror systems. Have a nice day, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
Le Sun, Jul 30, 2006 at 08:26:02AM +0200, Michael Vogt a écrit : > > 1. send a Mail to [EMAIL PROTECTED] with the subject 'GET 3 cs' > (use cs da de eo es fi fr hu it ja nl pl pt_BR pt_PT ru sk sv_SE > uk as langcode) Dear Michael, how can we get description for specific packages? There are some pages of the debian web site, such as in the debian-med area [1], which contain package descriptions that have therefore have already been translated in some languages. [1] http://www.debian.org/devel/debian-med/microbio Have a nice day, -- Charles Plessy, Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New desktop features provided by new version of update-notifier
Le Sun, Aug 13, 2006 at 09:03:52PM -0500, John Goerzen a écrit : > > Say you were a > seasoned Solaris admin, and you installed Debian to play around with. > You get a prompt saying that you have to reboot because zlib or > something has been upgraded. Are you going to think this is a serious > operating system, suitable for server-class work? Maybe a way to solve the problem would be to make clear in the package name, documentation and popup messages that it is not a native Debian tool? For instance, it could be called "Ubuntu update notifier for Debian". In the end, it seems to me that the problem is more that the tool has a name made only with dictionary words, which suggest that it is *the* tool to use. In the future, there may be more update notifiers, each with its own policy about when to reboot, when to relog, and so on, and "update-notifier" would have an advantage over the others, which is unfortunate because of the bad practices it promotes as you pointed out. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382994: ITP: rebase -- The restriction enzyme database, from New England Biolabs
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: rebase Version : NA Upstream Author : Dr. Richard J. Roberts and Dana Macelis (http://rebase.neb.com/rebase/rebase.staff.html) URL : http://rebase.neb.com License : Permission obtained by email (see below) Description : The restriction enzyme database, from New England Biolabs The Restriction Enzyme data BASE is a collection of information about restriction enzymes and related proteins. It contains published and unpublished references, recognition and cleavage sites, isoschizomers, commercial availability, methylation sensitivity, crystal and sequence data. DNA methyltransferases, homing endonucleases, nicking enzymes, specificity subunits and control proteins are also included. Most recently, putative DNA methyltransferases and restriction enzymes, as predicted from analysis of genomic sequences, are also listed. REBASE is continuously updated and the web pages not dynamically generated are refreshed on a nightly basis. The data in REBASE consists in 39 files which are used by external software such as PerlPrimer (distributed in Debian), EMBOSS (unofficial Debian package), or Staden (unfficial Debian package). Packaging REBASE will make it available to these progams and allow to update the data without to update the debian package of these programs themeselves. The packaging of REBASE is a first step towards a high-quality packaging of EMBOSS, which is very important in the field of molecular biology and bioinformatics. I explained the upstream authors the difference between main and non-free, and asked if they think that we can redistribute their data in a dfsg-free manner, and here is their answer: "REBASE is free to its users and they may use the data however they'd like, but when this use involves repackaging the data and redistribututing it, the common courtesy we always provide one another is to credit the source of this data. Users expect bibliographical content showing the sources of your material. This could be contained in a README file, or a menu item, whatever. So if you include a note such as - References: REBASE, the Restriction Enzyme Database Dr. R.J. Roberts and D. Macelis rebase.neb.com somewhere in your distribution, that's fine." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#382994: ITP: rebase -- The restriction enzyme database, from New England Biolabs
Le Mon, Aug 14, 2006 at 09:44:59PM +, David Nusinow a écrit : > > First off, I'm excited about this package. But does this actually allow for > modification and redistribution? By "use the data however they'd like", > does that include modification, or is it just reading the data? Good question. I asked two times if the data is modifiable, but did not get a clear answer. On the other hand, "use the data however [you] like" does not forbid modification. My plan is to re-ask before uploading, when sending a "I am delighted to tell you that your data is entering Debian" mail. I will explain again that being distributed in Debian means claiming that anybody can redistribute modified versions of the data. I am a bit reluctant to insist and ask the same question three times in less than a week. I already told the upstream people that non-modifiable mean non(-dfsg)-free, and that non-free is a bit cumbersome to distribute (for instance in live CDs). This did not trigger any reaction. Maybe I can unbrand the mails I sent them and publish them if you want post-proofread them... Althouth I intended to be clear, I am not a native speaker... Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems with security updates (was: Surpassing Microsoft quality)
> Now, I have awaken because of bug 372719. Wine crashes, OpenOffice.org > 2.0 crashes upon saving a document. The bug was introduced in > "security update" of libfreetype. Identification of problem was quick > in OpenOffice.org community, and also in Debian. Just apply the next > security update that will fix the bug. > > Not that easy. It's 2 months now and bug still there. Dear Mgr Tuharsky, The Debian bug tracking system contains pseudo-packages to report such problems to the relevant persons. For your case, the pseudo-package is "security.debian.org". http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=security.debian.org By sending your message directly to a wider audience, you give the impression that its purpose is to ashame the responsible persons, not to inform them, especially as you added remarks about abandonning Debian because of you are not satisfied of the quality of their work. In the meantime before the breakage is resolved, please note the workaround published in the bug you cited. Best regards, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Removing moderation on Alioth lists
Le Thu, Aug 17, 2006 at 10:52:52AM +1000, Brian May a écrit : > Subject: Your message to Pkg-mediawiki-devel awaits moderator approval > > > The reason it is being held: > > Post by non-member to a members-only list > Dear all, In the case of the mail list of the packaging project of debian-med, we decided to remove moderation after reading this thread. It took us some time to figure out how to do it in mailman. For the other persons unfamiliar with mailman, here is what to do: * In Privacy options... / Sender filters, set "generic_nonmember_action" to "accept". * In Privacy options... / Recipient filters, set "require_explicit_destination" to "no". Hope that helps, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status of BSD-like licences with advertisement clauses.
Dear all, I have been told by two different developers that licences using the 4-clauses BSD licence as a template are free or non-free (one opinion per develop per). There is a software that I definitely want to see in Debian and it is covered by such a licence. Can somebody remind me whether I would have to get it sponsored in main or non-free? This mail in not about starting a discussion on whether the licence should be treated as main or non-free, but to tell me where to upload if I do not want to see the package rejected. If you really would like to discuss the subject, the original thread in debian-mentors is: http://lists.debian.org/debian-mentors/2006/08/msg00233.html In-Reply-To=<[EMAIL PROTECTED]> Also, if you are puzzled on what this discussion is about, the following link may be of interest: http://www.gnu.org/philosophy/bsd.html Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Le Sat, Aug 26, 2006 at 10:00:08PM +0200, Michelle Konzack a écrit : > Am 2006-08-25 11:46:20, schrieb Mgr. Peter Tuharsky: > > 1b, If things don't work, it's sometimes hard to get them working > > either. Example: Bug 372719. The OOo 2.0 keeps crashing for 2 months > > thank to KNOWN bug in security upgrade. Now tell somebody, that Debian > > But OOo 2.0 is not in Stable! Dear Michelle, to be fair with Mgr Tuharsky, I think that it is important to remind that the bug he is talking about in not affecting OpenOffice only, that it was introduced by a security update, and that for various reasons the fix takes months to be released, leaving users with a broken Sarge. I conclude from this that there is a problem of transparency / communication : - The people complaining had the impression that nobody was caring fixing the problem, because there was no apparent activity, and the problem was claimed to be solved. - Many answers to Mgr Tuharsky got were counter-criticisms focusing on OpenOffice, and overlooking the fact that the security update broke many more programs. - The fix was lost in the limbo for some time between two teams, leaving the users reading the bug report in a situation in which they can not decide who to contact to unblock the situation. - The problem is getting solved in silence. Maybe the debian website would deserve a section in which Debian communicates on those issues. After all, I think that they are similar in concept (but not in gravity) to recalls seen in the industry: a broken material was released, so special communication could help to contact the users, explain the problem, and help them to fix it. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Resuming the packaging of EMBOSS
user debian-med@lists.debian.org reopen 156276 usertag 156276 + wnpp med-bio med-bio-dev thanks bts Dear all, I and others have tried to contact Matt Hope in the past, to ask him if he is interested in resuming his packaging of EMBOSS (www.emboss.org), but we could not get an answer. I am therefore posting a last call on -devel, in the case that Matt reads this list with a different adress. Starting with his unfficial packages, we will finish the work to make them acceptable in the main archive, through an Alioth collaboration. http://debian.bioinformatics.unsw.edu.au/dists/sid/main/source/science/ http://alioth.debian.org/projects/pkg-emboss/ Matt is member of this Alioth project and is most welcome to take the reclaim maintainership if he is not MIA. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bashing rude users does not fix bugs they report.
Le Fri, Sep 01, 2006 at 11:36:15AM +0100, Jon Dowland a écrit : > At 1156986534 past the epoch, Michelle Konzack wrote: > > > to be fair with Mgr Tuharsky, I think that it is > > > important to remind that the bug he is talking about in > > > not affecting OpenOffice only, that it was introduced by > > > a security update, and that for various reasons the fix > > > takes months to be released, leaving users with a broken > > > Sarge. > > ^ > > Do you mean Testing? > > A security update in sarge for a different package breaks > OOo2 in some circumstances on Sarge. That is, if someone > installs OOo2, which means fetching it from elsewhere > (backports perhaps?) an unrelated security update will stop > it working. > > Personally I think the DS team have enough work making sure > security updates are a smooth process for packages *in the > OS*: being expected to test random-external-package-x on top > of that is asking too much. Hi all, here is a summary of what happened: - A security update of Sarge broke programs, some being shipped in Sarge, some being installed by the users from other sources. - The problem was quickly reported, and a fix was made. - Unfortunately, it was not released during aproximately two months. - A user complained on -devel. - It was realised by the appropriate persons that the fix was forgetten for two months. - The fixed was released in the last Sarge update. People who tried to report through the bts that the bug was not fixed were replied that it was, as they sent bugs to the package, not on the security.debian.org pseudopackage. Did the user who complained on -devel stay silent, it is possible that the fix would still wait to be released. I think that it is unfair to criticize him for having reported the problem as it appears that this is what solved the problem for real at the user level. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bashing rude users does not fix bugs they report.
Le Sun, Sep 03, 2006 at 04:06:39AM -0500, Steve Langasek a écrit : > On Sat, Sep 02, 2006 at 10:31:21PM +0900, Charles Plessy wrote: > > here is a summary of what happened: > > > - A security update of Sarge broke programs, some being shipped in > > Sarge, some being installed by the users from other sources. > > > - The problem was quickly reported, and a fix was made. > > > - Unfortunately, it was not released during aproximately two months. > > > - A user complained on -devel. > > > - It was realised by the appropriate persons that the fix was forgetten > > for two months. > > Incorrect. a) the bug was never forgotten; b) the longest delay in my > discussion with the security team was around 3 weeks, which regardless of > whether this should be acceptable is != 2 months. Dear Steve, Let's take the point of view of the user, who sees only the part of your discussion with the security team which is visible on the BTS: - There is a security fix on a package the 10th of June. - It is reported the 11th of June that it breaks OOo2; reports that it breaks applications supported by Debian stable follow. - The maintainer of the package releases a fix for the regression on the 14th of June on his people.d.o page. => From the point of view of the user, the bug was technically fixed within 4 days. The rest of the delay is, say "infrastructural". - After being confirmed that the fix was effective, the package maintainer contacts the security team the 15h of June. - Nothing happens for 10 days. The package maintainer re-contacts the security team the 25th of June. The package is uploaded to security.d.o on the 26th. - The 7th of July, it is reported that the package is lost. - The 1st of August, a user reports that Sarge is still suffering of this bug. - Nothing happens for more that two weeks. Other users ask for the bug to be fixed, but there was no answer from Debian developers. - The 17th of August, the user who complained on the 1st August complains again, but on -devel, and threatening to leave Debian for Ubuntu. - The 19th of August, a new version of the fixed package is uploaded to the security team. - The 1th of September, the bug is officially fixed, because the new package is part of the 3rd revision of Sarge. => With a few drops of cynicism, the morale of the story is that noting will happen if you do not cry out loud on -devel that you will switch to Ubuntu. We all know that it is wrong, and you confirmed that the correlation in the dates happened just by chance. But the point of my messages was that when a user complains on -devel about broken software which is not supported by Debian, although it seems to make sense to tell him that Debian can not solve all of his computer problems, it is safer to check before that there nothing wrong happening which could have induced this user to calm his nerves on -devel. You are right that there has never been a lapse of more than three weeks. But there have been multiple lapses which total a bit more that six weeks, and the delay for pushing the fixed package in Sarge is approximately two months and two weeks. I can understand that users who had their system broken by a security update become angry after two months in which Debian is not *apparently* in a hurry to repair what was broken. Please do not take this as a blunt criticism to the security.d.o team or the package maintainer. I am just saying that if people do see only the problems and the delays, and not the hard work behind, they will have the impression that Debian does not care. I already suggested to dedicate a few square centimeters of the homepage to "crisis communication". I do not think that it necessary requires a person in charge, especially as it is a sensitive subject: if there is crisis communication to do, it means that something wrong happened *in the hands of somebody*. But package maintainers could benefit from having a space in which they can communicate with their users when something is prevented to be fixed in the classical way. (that space could also take the shape of a header on top of bug reports, for instance, there are many possible variations on the theme...) Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request to mailing list Pkg-qof-maintainers rejected
Le Mon, Sep 11, 2006 at 09:09:26AM -0500, Manoj Srivastava a écrit : > > Why are you even in a position that such mistakes are > possible? Why is the recipient of the [EMAIL PROTECTED] > moderated at all? > Hi all, It happens because it is the default behaviour when you : - Request the creation of a mailing list on Alioth, - Change the maintainer field to the new list. Un-moderating is not enough, if you want to get some automated mails from the building system, there us other antispam filter to inhibit. I posted a short summary of what to do last month: http://lists.debian.org/debian-devel/2006/08/msg00873.html It is really unfortunate that the regulation of moderation is hidden under a "privacy" menu in Mailman. Maybe the most straightforward mean to slove this in the future would be to make the new lists unmoderated by default? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intend to intend to hijack SeaView.
Dear all, I did not find a match for "mia" or "hijack" in the tables of content of the policy or of the developper's reference. If Brian R Furry ([EMAIL PROTECTED]) were MIA, I would like to hijak his "seaview" package, for which the upstream author has made improvements that allow to move the package from contrib to main. The maintainer did not answer to the bugs I posted half a year ago, one of them being potentially release critical (wrong licence in debian/copyright). He also did not upload anything at all for one year. Seaview it an editor for multiple alignments of biological sequences, and I have been working recently on bringing more sequence aligners to Debian. Having an editor for the output of these programs in "main" rather than "contrib" would help to assemble a coherent framework for biological sequence analysis in Etch, but it necessitates to upgrade to the latest upstream version. In my understanding, this is too much for a NMU. Therefore, unless I am told not to do so, and of course unless I am wrong to thing that Brian Furry is MIA, I would like to put the package under the responsability of the "Debian-Med packaging team" (see http://alioth.debian.org/projects/debian-med/ and http://alioth.debian.org/projects/debian-med/), and to submit an upgrade to my sponsor before the 8th of October. (By the way, is freeze time minus 10 days the deadline for uploads ?). Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Bug#387557: pcre3: Please ship pcre_internal.h
> Personally I feel that the "internal" in the name really should have > been a big enough clue, and I don't want to include a file that's not > meant to be used just because some idiots have written software that > needs it. > I'm not even sure it will work; what is it that emboss wants it for? Dear all, dear Mark, I investigated the problem a bit further: I am trying to replace the includes to "local" libpcre headers by includes in the form, and to ship the pcre_internal.h in the debian directory. This leads to three problems: - I also need the configure.h file generated when libpcre3-dev was built. I solved this one by shipping this one as well in the debian directory. - The file ucp.h is needed by pcre3_internal.h. For the moment, I also added it to the debian directory. But its header says "libucp - Unicode Property Table handler". So maybe it is a library which is not internal and could be shipped by the pcre3 debian package? - After these modifications, the building fails with make: *** No rule to make target `pcre.lo', needed by `libajax.la'. Stop. This one is fatal to me as I have to admit that, not being a C programmer, I my understanding of those library things is very limited. But there may be other solutions: - Modify the makefiles of EMBOSS so that it gets built statically against the libpcre it ships (or does it already?). - Ressucitate the debian package for pcre 4.3 if it can cohabit with the current version, and build emboss against version 4.3. Depending on the answer, it may be more appropriate to continue the discussion on -mentors. The thread is here: http://lists.debian.org/debian-mentors/2006/09/msg00286.html [EMAIL PROTECTED] Lastly, I would like to quote the EMBOSS website: "EMBOSS breaks the historical trend towards commercial software packages". As a molecular biologist, I am really grateful to the EMBOSS developpers for their past and present efforts for free software, especially in those years where there is an increasing pressure on scientists to commercialise their works using buisness models based on intellecutal property (patents, non-free software,...). Not being a Debian developper I can not speak for the Debian project, but if the people behind EMBOSS read this thread, I want them to know that I strongly disagree with the Debian developper saying that they are idiots. I have a deep respect for their work, which makes bioinformatics accessible to anybody having a personnal computer running a *nix operating system. Have a nice day, -- Charles Plessy Debian-Med packaging team Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help with menu (Was: Bug#389932: wish: gnumed --debug should open terminal window)
Le Fri, Sep 29, 2006 at 07:37:24AM +0200, Andreas Tille a écrit : >3. File bugs against all packages that provide > x-terminal-emulator but do not show the -hold feature > (would this be reasonable) > > Would be option 3 also interesting for other packages? IMHO if > we have the x-terminal-emulator feature we need to fix the call > to a common set of options between all these terminal emulators. Hi all, actually, it would be interesting if the common core of options of the x-terminal emulators would be documented somewhere, such as in a manpage for instance. In one of my future packages, the upstream sources are modified so that x-terminal-emulator is called instead of xterm, but I do not know if this would break for non-mainstream alternatives... Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Another option to reconfigure to avoid rejection on Alioth mailing lists.
Dear all, In addition to "generic_nonmember_action" and "require_explicit_destination" (in "Privacy options... / Sender filters" and "Privacy options... / Recipient filters" respectively), I realised today that there is another filter wich is on by default and can subject mails to moderation on the mailing list hosted on Alioth, which are increasingly being used a "Maintainer:" of packages. At the bottom of the "General Options", there is "max_message_size", which defaults to 40 kb. In my case, it sent a bug report with attached files to the moderation queue, which is not good. Setting the value to zero disables the filter. Hope this helps, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: delay of the full etch freeze
Le Thu, Oct 12, 2006 at 10:22:43PM +0200, Petter Reinholdtsen a écrit : > [Charles Plessy] > > The rationale is that the 8th is "old freeze deadline minus 10 > > days", so it was not completely unreasonnable to take this day as > > the deadline for having new packages in Etch. > > I find this completely unreasonable. If someone waited that late in > the release process before uploading a package they knew would have to > go through NEW, they can not expect the package to make it into Etch. > New packages should have had at least a few weeks in unstable to allow > problems to be detected before heading for testing. Dear Petter, Your point of view is in my opinion very pessimistic. What if there were some late uploads because people were enthousiastic improving Etch and worked hard until the deadline ? I agree that there needs some testing, but freeze or not, packages without bugs stay in unstable no more than 10 days anyway. There will be one month between the freeze and the release, so this is few weeks of testing anyway. I have the point of view of somebody making packages for simple programs on which other packages usually do not depend. Of course, I do not pretend that one should upload to NEW a major release of a pivotal software suite eleven days before the prospective freeze. Anyway, it was good to have some sort of deadline. I thank the release team for having decided one. In my case, I prioritised my recreational computer activities, putting more Debian stuff in September and less in October. Overall, it helped me to acheive one goal (good coverage of biological sequence alignment tools in Etch). Depending on who will be the fastest between release and the ftp teams, two more packages will make it or not. If they do not, I will send apologies to the upstream author who trusted me when I said that we should be ready a few days before the 8th and explain him that I did not understand how the freeze process works. For the second package, as it has a RC bug hidden under a normal priority, I will ask for an exemption on the debian-release list. Thanks to all the other persons who answered to me. Have a nice weekend, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Le Sat, Oct 14, 2006 at 11:51:49AM +0100, Wookey a écrit : > > Perhaps debtags could be used as an appropriate classification > mechanism. Hi all, As a maintainer of scientific packages, I agree with this idea. I always feel sorry to see my packages sitting in the queue of slow arches while I am very confident that nobody will use them on such computers. The interest with debtags is that it allows to change the policy for a package without needing an upload or the intervention of the maintainer. This way, the decision of not building could be taken by the maintainer, and it could be reverted quickly by somebody else if a user requested the package on an excluded arch. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
Dear all, Clustal W and Clustal X are the most popular software for multiple alignment of biological sequences. Their source package was NMUed during the lesstif transition, but not built on enough architectures, and was therefore removed from testing. http://packages.qa.debian.org/c/clustalw.html Can some DD help clustalw to get back into Etch as we still have the opportunity ? I just entered the NM queue and therefore can not do this kind of work by myself. Thank you so much in advance! Have a nice day, -- Charles Plessy Debian-Med packaging team Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Please compile clustalw on architectures ia64, mips, mipsel, s390 and m68k
Le Tue, Oct 17, 2006 at 02:30:59PM +0200, Frank Küster a écrit : > Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > > What about convincing the upstream developers to change the license to > > one of the free software licenses? It would solve the problem for > > good. > > Judging from the mail recorded in its copyright file, this isn't likely > to happen. http://packages.debian.org/changelogs/pool/non-free/c/clustalw/clustalw_1.83-1.1/clustalw.copyright Dear all, Eight years have passed since the authors of Clustal gave a special permission to Debian. There could be hope that the non-exclusive licences they sold to companies have expired, removing the reason for which they are reluctant to give Clustal away for free. Indeed, as there are now some "competitors" in the public domain, I see more and more commercial products using them instead of Clustal, so it is predictable that the authors will not get revenues from this program for ever, if they still do. When the Debian-Med project will have some authority in the field of molecular biology and bioinformatics, I think that it will be a good idea to contact the academic authors of non-free software, and ask them if they would like to reconsider their choice. But for this, we need success, and for success we need to listen to our users, and our users still massively use Clustal compared to the free competitors. http://people.debian.org/~igloo/popcon-graphs/index.php?packages=kalign+dialign+probcons+clustalx+clustalw+muscle+t-coffee+poa+amap-align+sigma-align&show_installed=on&want_legend=on&beenhere=1 I do not know how to interpret the popcon data: either some users are swiching from the clustal programs to alternatives, or we are losing some users since clustalw was removed from testing. Already 10 % less... Ouch, it bleeds... In conclusion: by building this non-free package and allowing clustalw to migrate in testing, you will help to increase our user base and promote all the free software we promote together with clustalw: http://wiki.debian.org/SequenceAlignment PS: depending on the answer, debian-science can be a better list than debian-devel. PPS: I would bet that half of the architectures on which clustalw is missing are architectures on which nobody uses Clustal W or Clustal X, but this is another story... Have a nice day, -- Charles Plessy Debian-Med Packaging Team Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394705: ITP: emma -- extendable MySQL managing assistant
Le Sun, Oct 22, 2006 at 06:59:38PM +0200, Piotr Ozarowski a écrit : > Package: wnpp > Severity: wishlist > Owner: Piotr Ozarowski <[EMAIL PROTECTED]> > > * Package name: emma Dear Piotr, I am preparing a package for a software suite called EMBOSS, and one of its binaries is called emma. Is the Emma you are packaging also containing a "emma" binary ? http://emboss.sourceforge.net/apps/cvs/emma.html Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394705: ITP: emma -- extendable MySQL managing assistant
Le Tue, Oct 24, 2006 at 02:40:16AM +0200, Piotr Ozarowski a écrit : > Charles Plessy wrote: > > I am preparing a package for a software suite called EMBOSS, and one > > of > > its binaries is called emma. Is the Emma you are packaging also > > containing a "emma" binary ? > > Yes, my package has only one file in /usr/bin - "emma". > > I wanted to search for sponsor today, but I will delay it so we can > work on > consensus here... > Are other binaries depending on "emma" name in your package? Not "depending". However, EMBOSS is a set of command line tools in the unix spirit. Its users would be quite disturbed if emma had to be renamed. Also, I guess that it would break scripts. So let us list the possibilities : a) One of the packages gives up emma to the other. I explained my reasons why I would prefer not giving up the name, but I understand that if you estimate that you also have good ones, we will have to find another solution. b) EMBOSS and Emma packages rename the binary to emma-align and emma-assistant respectively (for instance). This is what policy 10.1 requires when there is no consensus. c) The packages rename the binaries, and we find a way to ship a script as /usr/bin/emma which tells the user to read /usr/share/doc/emboss|emma/README.Debian. Or to read a emma.1 manpage wich explains how to deal with this issue (such as having a symlink to /usr/bin/emma-relevant in $HOME/bin). Using dpkg-divert could be a way to ship this script in both packages. As the policy does not recommend anything like c), I am wondering if it is a good idea. I welcome any comment on this. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394705: ITP: emma -- extendable MySQL managing assistant
Le Tue, Oct 24, 2006 at 02:40:16AM +0200, Piotr Ozarowski a écrit : > Charles Plessy wrote: > > I am preparing a package for a software suite called EMBOSS, and one of > > its binaries is called emma. Is the Emma you are packaging also > > containing a "emma" binary ? > > Yes, my package has only one file in /usr/bin - "emma". > > I wanted to search for sponsor today, but I will delay it so we can work on > consensus here... > Are other binaries depending on "emma" name in your package? Not "depending". However, EMBOSS is a set of command line tools in the unix spirit. Its users would be quite disturbed if emma had to be renamed. Also, I guess that it would break scripts. So let us list the possibilities : a) One of the packages gives up emma to the other. I explained my reasons why I would prefer not giving up the name, but I understand that if you estimate that you also have good ones, we will have to find another solution. b) EMBOSS and Emma packages rename the binary to emma-align and emma-assistant respectively (for instance). This is what policy 10.1 requires when there is no consensus. c) The packages rename the binaries, and we find a way to ship a script as /usr/bin/emma which tells the user to read /usr/share/doc/emboss|emma/README.Debian. Or to read a emma.1 manpage wich explains how to deal with this issue (such as having a symlink to /usr/bin/emma-relevant in $HOME/bin). Using dpkg-divert could be a way to ship this script in both packages. As the policy does not recommend anything like c), I am wondering if it is a good idea. I welcome any comment on this. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan
Bug#395840: ITP: phylowin -- Graphical interface for molecular phylogenetic inference
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: phylowin Version : 25.09.2006 Upstream Author : Nicolas GALTIER <[EMAIL PROTECTED]> and Manolo GOUY URL : http://pbil.univ-lyon1.fr/software/phylowin.html License : Not found on the website Description : Graphical interface for molecular phylogenetic inference Phylo_win is a graphical colour interface for molecular phylogenetic inference. It performs neighbor-joining, parsimony and maximum likelihood methods and bootstrap with any of them. Many distances can be used including Jukes & Cantor, Kimura, Tajima & Nei, HKY, Galtier & Gouy (1995), LogDet for nucleotidic sequences, Poisson correction for protein sequences, Ka and Ks for codon sequences. Species and sites to include in the analysis are selected by mouse. Reconstructed trees can be drawn, edited, printed, stored and evaluated according to numerous criteria. . Homepage: http://pbil.univ-lyon1.fr/software/phylowin.html One of the authors asked me if I could package Phylo_win for Debian. After inspecting the sources, I figured out that this program uses sources files from the Phylip program, which frobids its use for profit. Therfore, Phylo_win will unfortunately have to be distributed in "non-free", oustide of Debian. I will nevertheless contact the author(s) of the derived source files and ask if they are willing to give an exemption for Phylo_win. Phylo_win will depend on Vibrant (ncbi-tools6) and lesstif. -- Charles Plessy Wako, Saitama, Japan Debian-Med packaging team -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16farm Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397873: ITP: sixpack -- A full-featured package for XAS analysis
Le Thu, Nov 09, 2006 at 05:10:40PM -0600, Carlo Segre a écrit : > Package: wnpp > Severity: wishlist > Owner: Carlo Segre <[EMAIL PROTECTED]> > > > * Package name: sixpack Hi, I am preparing a package for "EMBOSS", the European Molecular Biology Open Source Software suite, which is focused on the manipulation of biological sequences in command line. EMBOSS contains a binary file named sixpack. Is it the case for SIXPack? Also, Google indicates at least one other "sixpack" project. Maybe you could consider renaming your package sixpack-xas, or something like this... Have a nice day, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397873: ITP: sixpack -- A full-featured package for XAS analysis
Le Fri, Nov 10, 2006 at 09:47:56AM -0600, Carlo Segre a écrit : > > Hi Charles: > > The program is itself called sixpack. There was an ITP some time ago > (2002-2003) for another program called sixpack but the wnpp bug was RFP > and it was closed due to 2 years of inactivity. What would you propose > for your sixpack binary? Hi Carlo, I had a similar discussion on -devel last month, and we agreed that the one binary would use uppercase letters. http://lists.debian.org/debian-devel/2006/10/msg00978.html If there is no technical concern, I would suggest that your binary would be named SixPACK, to match what is used on upstream's website. I would be rather reluctant to rename the sixpack binary of EMBOSS, as it is a software suite which is very command-line oriented, in the Unix way : many small programs fitting one task. EMBOSS users will definitely not expect sixpack to be renamed. In addition, their scripts would be broken. How is the case of sixpack for XAS? Is it used in command line, or will it be called from a menu ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bash /dev/tcp and /dev/udp
Le Thu, Nov 23, 2006 at 02:09:33PM +0100, Jan C. Nordholz a écrit : > Hi Klaus, > > > >from the bash manpage: > > /dev/tcp/host/port > > /dev/udp/host/port > > This has been discussed several times [1][2], and the outcome was every time > that this should not be a feature of the shell, but of more specialized > tools like nc. Use those or recompile your bash. > > > Regards, > > Jan > > [1] http://lists.debian.org/debian-user/2003/04/msg01591.html > [2] http://lists.debian.org/debian-user/2006/07/msg00121.html Dear all, I found the following additional discussions in my crystal ball: http://lists.debian.org/debian-user/2008/09/msg00087.html http://lists.debian.org/debian-user/2010/02/msg00295.html Maybe one source of the problem is that the bug report contains only messages advocating the inclusion of the feature, and that the maintainer tagged it "wontfix" without explaining his reasons? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Where to put non-locale global environment settitngs ?
Dear all, There has been a question which has stayed unanswered for a while on debian-user-french; as I do not have the answer, I would like to submit it here... Users are now told to use /etc/defaults/locale instead of /etc/environment for setting system-wide default language. But what about the non-locale environment variables that users also put in /etc/environment, such as http_proxy for instance? Are they also unwelcome because /etc/environment "is a PAM configuration file"? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why not scan for unmaintained packages and orphan them?
Le Tue, Dec 05, 2006 at 01:35:25PM +, Sune Vuorela a écrit : > On 2006-12-05, Lionel Elie Mamane <[EMAIL PROTECTED]> wrote: > > I don't see "seen" as a supported tag in the BTS documentation, and > > 'confirmed' maybe? > > - but having 20 importaint bugs in one package and 1 wishlist in >another package -- in my world the 20 importaint bugs gets higher >priority - even if it takes a half year to get to the wishlist >without much commenting. Hi all, how about a new function for the bts program of the devscripts package: $ bts thankyou 123456 This could send a template message to [EMAIL PROTECTED], which would say something like "The maintainer is too busy to send a real answer, but he saw your report and thanks you for sending it." (one can imaging many other variants, such as bts dontcare, bts onstrike, bts waitayear, ) Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
Le Fri, Dec 29, 2006 at 02:18:26PM +0100, Kurt Roeckx a écrit : > > I think you're confusing the buildd admin with the porters. I expect > porters to read the [EMAIL PROTECTED] list, I don't expect > the same from the buildd admin. Dear all, Maybe the "[EMAIL PROTECTED]" lists should be read by "those who care" instead of just those who port ? When such a list does not react anymore, does it really make sense to ask a DD to take the responsability of a buildd and spend his time for an arch in which he has no particular interest ? I think that it would be a much better situation if a buildd admin would be somebody who particularly cares for the corrseponding port. This would warrant some reactivity, and if a core group of DDs interested in a port can not provide a buildd admin, it may mean that the support for the existence of the port is not sufficient. (said after having wasted hours with the s390 port some weeks ago - I did not guess that the buildd admin was not reading the list on which I posted my mails). Have a nice day, and happy new year to those who celebrate it this evening. -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#406495: ITP: odt2txt -- simple converter from OpenDocument Text to plain text
Le Thu, Jan 11, 2007 at 02:18:52PM -0200, Nelson A. de Oliveira a écrit : > Package: wnpp > Severity: wishlist > Owner: "Nelson A. de Oliveira" <[EMAIL PROTECTED]> > > * Package name: odt2txt > Version : 0.2 > Upstream Author : Dennis Stosberg <[EMAIL PROTECTED]> > * URL : http://stosberg.net/odt2txt/ > * License : GNU GPL-2 > Programming Lang: C > Description : simple converter from OpenDocument Text to plain text > > odt2txt extracts the text out of OpenDocument Texts, as produced by > OpenOffice.org, KOffice, StarOffice and others. It is small and > fast, can output the document in many encodings and adopts to your > locale. Hi Nelson, How does it compare to the converter from the o3read package? Can there be some automagic mutt handling such as for antiword? Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: o3read -- standalone converter for OpenOffice.org documents
Copy sent to the mail-list as I have problems with direct mail (error message below my signature). On Thu, Mar 16, 2006 at 05:14:08PM +0100, Bartosz Fenski aka fEnIo wrote : > * o3totxt - creates plain text Hello, It would be great if, similarly to antiword, this program would be easy to be used with mutt or others to display inline the contents of attached OOo documents in emails. Have a nice day, -- Charles Plessy Wako, Saitama, Japan This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to one or more of its > recipients. This is a permanent error. The following address(es) failed: > > [EMAIL PROTECTED] > SMTP error from remote mailer after RCPT TO:<[EMAIL PROTECTED]>: > host mx6.go2.pl [193.17.41.46]: 550 <[EMAIL PROTECTED]>: > Recipient address rejected: Bad SPF records, see http://spf.pobox.com/ > > -- This is a copy of the message, including all the headers. -- > > Return-path: > Received: from d231185.ppp.asahi-net.or.jp ([210.253.231.185] > helo=localhost.localdomain) > by master.debian.org with esmtp (Exim 4.50) > id 1FK1sc-0001wG-9X > for [EMAIL PROTECTED]; Thu, 16 Mar 2006 17:27:42 -0600 > Received: by localhost.localdomain (Postfix, from userid 1000) > id F296A62E; Fri, 17 Mar 2006 08:27:33 +0900 (JST) > Date: Fri, 17 Mar 2006 08:27:33 +0900 > From: Charles Plessy > To: Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> > Subject: Re: Bug#357299: ITP: o3read -- standalone converter for > OpenOffice.org documents > Message-ID: <[EMAIL PROTECTED]> > Reply-To: Charles Plessy > References: <[EMAIL PROTECTED]> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > In-Reply-To: <[EMAIL PROTECTED]> > User-Agent: Mutt/1.5.9i > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How (not) to write copyright files - take two
On Sun, Mar 26, 2006 at 08:29:48PM +0200, Joerg Jaspert wrote : > > In many packages there is more than one author, more than one > copyright-holder and more than one license. Do not miss to list them > all, even if that other license is just for one file. Yes, any single > file is important. Dear Joerg, I am packaging a program for debian, and wrote a manpage and two patches for making it compile with libwxwindows. I am not very interested in being the author list: I would be a bit ashamed that my name would appear more frequently that the author's for a work which is not mine. Also, I feel a bit lazy and do not want the burden of changing the copyright file whenever one of my modifications is accepted or obsoleted. Is it OK if I release the patches and the manpages in the public domain, and I do not mention the manpage and the patches in the copyright file? Best Regards, -- Charles Plessy Wako, Saitama, Japon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361682: ITP: dialign -- Segment-based multiple sequence alignment
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: dialign Version : 2.1.1 Upstream Author : Burkhard Morgenstern, Said Abdeddaim <[EMAIL PROTECTED]> URL : http://dialign.gobics.de/ License : LGPL Description : Segment-based multiple sequence alignment DIALIGN2 is a command line tool to perform multiple alignment of protein or DNA sequences. It constructs alignments from gapfree pairs of similar segments of the sequences. This scoring scheme for alignments is the basic difference between DIALIGN and other global or local alignment methods. Note that DIALIGN does not employ any kind of gap penalty. It has been published by Morgenstern B. in Bioinformatics. 1999 Mar;15(3):211-8. . Homepage: http://dialign.gobics.de/ I will patch the program so that it will use /usr/share/dialign by default to access the substitution matrices instead of requiring the user to set an environment variable. Setting it anyway will override the default value. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16farm Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is there a policy for the .desktop files?
Hi all. Applications can be listed in the non-debian menu of desktop managers such as Gnome and Kde by dropping a applicationname.desktop file in /usr/share/applications/. There is a lot activity in Ubuntu to provide applicationname.desktop files to packages which lack them, so I decided to write one for a package I am currently preparing (treeviewx, ITP#352506). However, I could not find something equivalent to the menu policy. Can any program register itself in the Application menu of Gnome and KDE, or does it has to be done in coordination wiht the teams responsible for these desktops ? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bounty for packaging OME
On Sun, Apr 23, 2006 at 09:46:16AM -0700, kris kvilekval wrote : > We are looking for someone with packaging experience to help package OME > (http://www.openmicroscopy.org/) for debian on a paid basis. > BTW if this is not the correct forum, please let me know. Dear Kris, As far as I know, debian-devel is the list to use to if one intends to contact the debian developpers as a whole. However, not all are subscribed to, and there are some more specialised lists in which people could be interersted in your message such as debian-med and debian-science. I forwarded your message to those lists. http://lists.debian.org/debian-med/ http://lists.debian.org/debian-science/ I hope you will find your bounty hunter, Best regards, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[OT] plonk reports are off-topic.
On Mon, Apr 24, 2006 at 07:45:21PM -0500, Manoj Srivastava wrote : > > *plonk*. Dear all, dear Manoj, Since the use of killfiles reflects the personnal opinion of the person who is using it about the person which will be ignored, I think that informing the thousands of subscribers of the -devel list that one will ignore one more person is not necessary and off-topic. Reducing the number of mails and moving the personnal arguments to private discussions or private mailing lists can make -devel much more friendly. So, to the next person adding an entry in his/her killfile, please refrain from informing the subscribers of -devel about it. Have a nice day, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365344: ITP: kalign -- Global and progressive multiple sequence alignment
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: kalign Version : 1.04 Upstream Author : Timo Lassmann <[EMAIL PROTECTED]> URL : http://msa.cgb.ki.se/downloads/kalign-1.04.tgz License : GPL Description : Global and progressive multiple sequence alignment Kalign is a command line tool to perform multiple alignment of biological sequences. It employs the Wu-Manber string-matching algorithm, to improve both the accuracy and speed of the alignment. It uses global, progressive alignment approach, enriched by employing an approximate string-matching algorithm to calculate sequence distances and by incorporating local matches into the otherwise global alignment. In comparisons made by its authors, Kalign was about 10 times faster than ClustalW and, depending on the alignment size, up to 50 times faster than popular iterative methods. It has been published in Lassmann and Sonnhammer, BMC Bioinformatics 2005, 6:298. . Homepage: http://msa.cgb.ki.se -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16farm Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365499: ITP: probcons -- PROBabilistic CONSistency-based multiple sequence alignment
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: probcons Version : 1.10 Upstream Author : Chuong B. Do <[EMAIL PROTECTED]> URL : http://probcons.stanford.edu/download.html License : Public Domain Description : PROBabilistic CONSistency-based multiple sequence alignment PROBCONS is a tool for generating multiple alignments of protein sequences. Using a combination of probabilistic modeling and consistency-based alignment techniques, PROBCONS has achieved the highest accuracies of all alignment methods to date. On the BAliBASE benchmark alignment database, alignments produced by PROBCONS show statistically significant improvement over current programs, containing an average of 7% more correctly aligned columns than those of T-Coffee, 11% more correctly aligned columns than those of CLUSTAL W, and 14% more correctly aligned columns than those of DIALIGN. Probcons is published in Do, C.B., Mahabhashyam, M.S.P., Brudno, M., and Batzoglou, S. 2005. Genome Research 15: 330-340. . Homepage: http://probcons.stanford.edu/ -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16farm Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366321: ITP: amap-align -- Protein multiple alignment by sequence annealing
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: amap-align Version : 2.0 Upstream Author : Ariel Schwartz <[EMAIL PROTECTED]> URL : http://bio.math.berkeley.edu/amap/download/amap.2.0.tar.gz License : Public domain Description : Protein multiple alignment by sequence annealing AMAP is a command line tool to perform multiple alignment of peptidic sequences. It utilizes posterior decoding, and a sequence-annealing alignment, instead of the traditional progressive alignment method. It is the only alignment program that allows to control the sensitivity / specificity tradeoff. It is based on the ProbCons source code, but uses alignment metric accuracy and eliminates the consistency transformation. . Homepage: http://bio.math.berkeley.edu/amap/ Amap has of course nothing to do with the amap already packaged for Debian ( http://packages.debian.org/unstable/net/amap ). (By the way, I am looking for sponsors for kalign, dialign and treeviewx, which I have uploaded on Mentors. http://lists.debian.org/debian-mentors/2006/05/msg00014.html ) -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PDF files and dh_compress
On Wed, May 10, 2006 at 07:21:58AM +0200, Florian Weimer wrote : > * Frank Küster: > > > Most PDF files in Debian are already compressed; at least those > > which are generated on a Debian system, and somehow TeX is involved > > are. > > And those which haven't been rebuilt could well be non-free anyway > (because we lack the source code). 8-> Dear all, dear Florian, I am preparing a package (1) in which I have added the the PDF manual (2) which in the public domain. It has been created from a MSWord document. The upstream author is considering rewriting it in LaTeX, but of course, ther is no guarantee that it will be done shortly. (1) http://bugs.debian.org/365499 (2) available on the same page as the sources, http://probcons.stanford.edu/download.html Does it mean that I have to remove the pdf documentation, and indicate to the users how to download it by themselves in the manpage and/or README.Debian? Interestingly, one could consider that a PDF file is not a program. As in addition this one is in the public domain, it has no licence nor copyright. Does it mean that the DFSG do not apply and that I can distribute it in the debian package ? Have a nice day, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PDF files and dh_compress
Dear all, dear Frank, If it was the intention of the general resolution you are reffering to that any document which has been created by automatic processing of another document could not be distributed without its "source", it is rather unfortunate that it refers to the DFSG, which explicitely use the term "program" in their paragraph 2. However, I do not want to argue, and your comment about the possibility that the PDF file might contain non-free fonts also makes sense. I will not include the PDF in my package. As for the public domain, I thought I was on solid ground because work made by public servants in the USA is automatically public domain. However, I realised that the Standford university where the software has been released is private (correct me if I am wrong), thus the program can not be in public domain. I will document this in the copyright file, and ask the upstream author if he agrees to rephrase his statement. (However, my limited experience showed me that when authors chose permissive licences or statement, they are not generally interested in managing their copyrights as rigourously as Debian expects it...) Have a nice day, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#368931: ITP: libjung-java -- Java Universal Network/Graph Framework
Le Thu, May 25, 2006 at 07:29:43PM -0400, Charles Fry a écrit : > Package: wnpp > Severity: wishlist > Owner: Charles Fry <[EMAIL PROTECTED]> > > > * Package name: libjung-java > Version : 1.7.4 > Upstream Author : Joshua O'Madadhain <[EMAIL PROTECTED]> > * URL : http://www.example.org/ Homepage: http://jung.sourceforge.net/ -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
One can not guess if somebody is willing to accept private mails or not...
Le Wed, Jun 07, 2006 at 11:32:36PM +0100, Matthew Garrett a écrit : > Bill Allombert <[EMAIL PROTECTED]> wrote: > > > Given the above link point to your post, you can only blame yourself for > > its content. > > It's not strictly necessary to bitch about Anthony's actions at every > opportunity. If you disagree with his course of actions, perhaps > dropping him a private mail discussing your concerns would work better? (IANDD) Hi Matthew and Bill Just dont: Anthony Towns seems to find such private mails much more disturbing than public criticisms. In the early 2006, I complained privately about the sarcastic tone of one of the answers he made to me on -devel, and I guess that I hurted him more strongly than if I had done this publicly, because I received insults on his blog in return. (However, I think that the signal-noise ratio on -devel could be strongly raised if at least part of the discussions would be conduced in private with the people who have no objection against it.) Have a nice day, (and please answer privately, of course) -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373606: ITP: sms2 -- Biological sequence manipulation suite
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: sms2 Version : 2.303 Upstream Author : Paul Stothard <[EMAIL PROTECTED]> URL : http://www.bioinformatics.org/SMS/index.html License : GPL Description : Biological sequence manipulation suite The Sequence Manipulation Suite is a collection of web-based programs for analyzing and formatting DNA and protein sequences. The output of each program is a set of HTML commands, which is rendered by your web browser as a standard web page. You can print and save the results, and you can edit them using an HTML editor or a text editor. Sequences submitted to the Sequence Manipulation Suite do not leave your computer and are instead manipulated by your web browser. The SMS has been published in Stothard P (2000) The Sequence Manipulation Suite: JavaScript programs for analyzing and formatting protein and DNA sequences. Biotechniques 28:1102-1104. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16farm Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Broken applications: Could we be honest?
Le Sat, Jul 08, 2006 at 10:09:56AM -0600, Art Edwards a écrit : > It would be very nice if you, and other distro's, were > to put appropriate caveats on the websites, saying that 64-bit is really not > ready for the prime-time desktop. That way, we could make better purchasing > decisions. Dear Art, others already answered why such a caveat would be a very pessimistic overstatement. I just would like to add that there is a mailing list for the scientific communauty using and developping Debian, which can provide insightful comments on the state of scientific computing in Debian when you are preparing a purchase order. http://lists.debian.org/debian-science/ "Discussion of issues relating to the use of Debian for science research, including useful packages, particular problems faced by scientists using Debian, how to make Debian more useful to scientists, etc." Have a nice day, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378288: ITP: poa -- Partial Order Alignment for multiple sequence alignment
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: poa Version : 2.0 Upstream Author : Christopher Lee <[EMAIL PROTECTED]> URL : http://www.bioinformatics.ucla.edu/poa License : GPL Description : Partial Order Alignment for multiple sequence alignment POA is Partial Order Alignment, a fast program for multiple sequence alignment (MSA) in bioinformatics. Its advantages are speed, scalability, sensitivity, and the superior ability to handle branching / indels in the alignment. Partial order alignment is an approach to MSA, which can be combined with existing methods such as progressive alignment. POA optimally aligns a pair of MSAs and which therefore can be applied directly to progressive alignment methods such as CLUSTAL. For large alignments, Progressive POA is 10–30 times faster than CLUSTALW. POA is published in Bioinformatics. 2004 Jul 10;20(10):1546-56. . Homepage: http://www.bioinformatics.ucla.edu/poa -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16farm Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378289: ITP: sigma-align -- Simple greedy multiple alignment of non-coding DNA sequences
Package: wnpp
Severity: wishlist
Owner: Charles Plessy <[EMAIL PROTECTED]>
Package name: sigma-align
Version : 1.0
Upstream Author : Rahul Siddharthan <[EMAIL PROTECTED]>
URL : http://www.imsc.res.in/~rsidd/sigma/
License : GPL
Description : Simple greedy multiple alignment of non-coding DNA sequences
Sigma ("Simple greedy multiple alignment") is an alignment program with
a new algorithm and scoring scheme designed specifically for non-coding
DNA sequence. It uses a strategy of seeking the best possible gapless
local alignments, at each step making the best possible alignment
consistent with existing alignments, and scores the significance of the
alignment based on the lengths of the aligned fragments and a
background model which may be supplied or estimated from an auxiliary
file of intergenic DNA. With real data, while "correctness" can't be
directly quantified for the alignment, running the PhyloGibbs motif
finder on pre-aligned sequence suggests that Sigma's alignments are
superior. It has been published in BMC Bioinformatics. 2006 Mar
16;7:143.
.
Homepage: http://www.imsc.res.in/~rsidd/sigma/
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16farm
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378290: ITP: proalign -- Probabilistic multiple alignment program
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: proalign Version : 0.5alpha1 Upstream Author : Ari Löytynoja & Michel C. Milinkovitch URL : http://evol-linux1.ulb.ac.be/ueg/ProAlign/ License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Probabilistic multiple alignment program ProAlign performs probabilistic sequence alignments using hidden Markov models (HMM). It includes a graphical interface (GUI) allowing to (i) perform alignments of nucleotide or amino-acid sequences, (ii) view the quality of solutions, (iii) filter the unreliable alignment regions and (iv) export alignments to other softwares. . ProAlign uses a progressive method, such that multiple alignment is created stepwise by performing pairwise alignments in the nodes of a guide tree. Sequences are described with vectors of character probabilities, and each pairwise alignment reconstructs the ancestral (parent) sequence by computing the probabilities of different characters according to an evolutionary model. It has been published in Bioinformatics. 2003 Aug 12;19(12):1505-13. . Homepage: http://evol-linux1.ulb.ac.be/ueg/ProAlign/ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16farm Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
On Mon, Jan 10, 2005 at 07:14:29PM +0100, Wouter Verhelst wrote : > Why don't you guys go to psychology class before telling people not to > be 'rude'? > It's impossible not to be rude on written media. What's a harmless joke > to one is an insult to another, and an attack to one's personality to a > third one. You can't expect everyone to be happy with everything you > might possibly write. Then what about keeping jokes for our private messages to our friends ? Your suggestion to go back to classes is, to my standards, definetly rude. As it does not add anything to your message, I do not understand why you want to take the risk to offend people, if there is no payback for it. > 'RTFM' means "Go read the documentation, that's what it's for". It also contains the "F word", which is related to the act of having sex. I wouldn't expect everybody to understand that using such a vocabulary has no mean to be instulting, as it is a hallmark of sentences which contain words about sex, feces or body parts to be more frequently insulting than average... As you say, any translation is sort of risky (even between related languages, where identical words have changed their meaning). My point of view is to minimise the risks when talking on international mail-lists, and in any case, to avoid anything which sounds like a personnal attack, including more general sentences which include the person you are answering to, as the first one of your mail... > I personally find it far more rude to go on a mailing list, ask for > the obvious, and expect a bunch of volunteers to come up with an > answer that's been answered in great detail in the documentation, > than to be sent back with an 'RTFM' as answer to that question. Silence is also an answer. And sometimes, volunteers do come up. > In any case, I strongly disagree with the stance that the rudeness of a > particular developer would reflect on Debian as a whole. Sure, people > who think they've been handled unfairly aren't going to talk positively > about Debian; but that happens to any organization, commercial or > voluntarily-based. That doesn't mean one rude developer will label > Debian as a rude organization... Most commercial organisations do their best to contrtol how their employees reflect their image, event to a point which is questionnable, when they want to take a tight control of physical appearance, or when they request people on phone hotlines to change their fisrt name because being called Mustapha is less correct that being called Pierre. The reason is they beleive that every invidual reflects the image of the organisation, especially at the first encounter. -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461506: ITP: altree -- program to perform phylogeny based analyses
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: altree Version : 1.0.1 Upstream Author : Claire Bardel <[EMAIL PROTECTED]> URL : http://claire.bardel.free.fr/software.html License : GPL Programming Lang: Perl Description : program to perform phylogeny based analyses This software was designed to perform phylogeny based analysis: first, it allows the detection of an association between a candidate gene and a disease, and second, it enables to make hypothesis about the susceptibility loci. The package is already ready: it was prepared by Vincent Danjean, who offered it to the Debian-Med packaging team. http://www-id.imag.fr/Laboratoire/Membres/Danjean_Vincent/deb.html#altree Have a nice day, -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461504: ITP: tacg -- command line program for finding patterns in nucleic acids
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: tacg Version : 4.1.0 Upstream Author : Harry Mangalam, tacg Informatics URL : http://sourceforge.net/projects/tacg License : GPL and others Programming Lang: C (tacg), Perl (CGI) Description : command line program for finding patterns in nucleic acids tacg is a character-based, command line tool for unix-like operating systems for pattern-matching in nucleic acids and performing some of the basic protein manipulations. It was originally designed for restriction enzyme analysis of DNA, but has been extended to other types of matching. It now handles degenerate sequence input in a variety of matching approaches, as well as patterns with errors, regular expressions and TRANSFAC-formatted matrices. . It was designed to be a grep for DNA and like the original grep, its capabilities have grown so that now the author has to keep calling up the help page to figure out which flags (now ~50) mean what. tacg is NOT a GUI application in any sense. However, it's existance as a strictly command-line tool lends itself well to Webification and wrapping by various GUI tools and it is now distributed with a web interface form and a Perl CGI handler. Additionally, it can easily be integrated into editors that support shell commands such as nedit. . The use of tacg may be cited as: Mangalam, HJ. (2002) tacg, a grep for DNA. BMC Bioinformatics. 3:8 http://www.biomedcentral.com/1471-2105/3/8 I had to apply an ugly patch in order to compile it with gcc4. Because I am not a C programmer, I barely understand what I did, so I would appreciate comments on the patch: http://svn.debian.org/wsvn/debian-med/trunk/packages/tacg/trunk/debian/patches/to-build-with-gcc4.patch?op=file&rev=0&sc=0 This is a low-quality patch, but it works. The modificaiton of tacg.h was made according to what I found on the mailing lists, and seems to make sense. The modification of SeqFuncs.c is completely heuristic; I used the same numbers as in tacg.h. The modification of SetFlags.c is a quick workaround that does not solve the real problem. Also, you can consult the full copyright file in the same repository: http://svn.debian.org/wsvn/debian-med/trunk/packages/tacg/trunk/debian/copyright?op=file&rev=0&sc=0 I use tacg to search for oligonucleotides in sequence reads: I need to allow mismatches, and want to detect if I (unfortunatley) cloned concatemer artefacts. If you know a better tool, let me know ! Have a nice day, -- Charles Plessy Debian-Med packaging team Wakō, Saitama, Japan
Bug#461510: ITP: treevolve -- simulation of evolution of DNA sequences
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: treevolve Version : 1.3.2 Upstream Author : Andrew Rambaut & Nick Grassly URL : http://evolve.zoo.ox.ac.uk/software.html?id=Treevolve License : Not found... will enquire. Programming Lang: C Description : simulation of evolution of DNA sequences treevolve will simulate the evolution of DNA sequences under a coalescent model, which allows exponential population growth, population subdivision according to an island model, migration and recombination. In addition different periods of population dynamics can be enforced at different times. For example, a period of exponential growth can be followed by a period of stasis where the population is subdivided into demes. Multiple sets of such simulated sequence data can then be compared to sequence data sampled from a population of interest using suitable statistics, and various evolutionary hypotheses concerning the evolution of this population tested. . Citation: Population dynamics of HIV-1 inferred from gene sequences Grassly NC, Harvey PH & Holmes EC (1999) Genetics 151, 427-438. The package is already ready: it was prepared by Vincent Danjean, who offered it to the Debian-Med packaging team. http://www-id.imag.fr/Laboratoire/Membres/Danjean_Vincent/deb.html#treevolve Have a nice day, -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461508: ITP: treeplot -- Phylogenetic tree file converter
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> Package name: treeplot Version : 0.7 Upstream Author : Olivier Langella URL : http://www.pge.cnrs-gif.fr/bioinfo/treeplot/ (invalid) License : GPL Programming Lang: C++ Description : Phylogenetic tree file converter Treeplot is a conversion tool, from "Phylip" phylogenetic tree file to Postscript (.ps), Adobe Illustrator (.ai), Scalable Vector Graphic (.svg), Computer Graphic Metafile(.cgm), Hewlet Packard Graphic Language (.hpgl), xfig file (.fig), gif image file(.gif), PBM Portable aNy Map file (.pnm) The package is already ready: it was prepared by Vincent Danjean, who offered it to the Debian-Med packaging team. http://www-id.imag.fr/Laboratoire/Membres/Danjean_Vincent/deb.html#treeplot Have a nice day, -- Charles Plessy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is a free document whose sources have been lost free?
Dear all, To make the dialign-t package, I removed the documentation from the upstream tarball, that I use for a dialign-t-doc package, in the non-free section as the their LaTeX sources are not provided. Now, I was informed that the reason is that the sources have been lost. In that case, don't the .html, .pdf and .ps files become the "preferred form for modification"? I really would be happy to merge dialign-t and dialign-t-doc again; we do not need to punish our users for an error made upstream. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely (Was: State of the project - input needed)
Le Fri, Jan 25, 2008 at 12:51:40PM -0500, Joey Hess a écrit : > > Unless what you get when you run apt-get source is *not* the source that > is in the end used to build the package, which is instead squirrled away > in some arbitrary patch format somewhere under debian/. In this case, > unlike in the vcs case, you have to figure out an arbitrary other tool > to get the source. Dear all, dear Joey, [This is a long mail, I hope that there is not too much verbillage in it. I encourage other participants to this interesting thread to take the opportunity of this week-end to take their time and write condensed answers instead of discussion-style answers.] I think that one of the driving forces for the adoption of patch systems is that they give an opportunity to organise the information and make it easier to review. Now it may be the wrong answer to the question, but in the absense of a document explaining how to implement an alternative method, I guess that things are not going to change rapidly. By storing multiple patches in debian/patches, we indicate to upstream, users and devloppers which change has which effect. This is not possible in the .diff.gz, except by verbosely paraphrasing the patches themselves, writing in english that at line X, the change Y does Z. (Comments in the code usually do not include reference to coordinated changes in other locations in the source, whereas the juxtaposition of the changes in a patch does.) Importantly, the debian/patches way provides this information offline, as it is is part of the source package. Also, having them as files in a directory allows to users and developpers to easily inactivate them if needed. I am so ignorant of git that I probably have missed if what you propose allows to do this and better. Can you or somebody else give some explanation at a beginner level? I also did not understand if the proposed solution can work if upstream is not using a VCS at all, as we do not want to duplicate hundreds of megaoctets of upstream sources. Neither how it works in the case of repackaging. Let me summarise the features I am talking about: - Changes are grouped accorging to their goal. - Easy way to swich the changes on/off. - All the information is in the Debian source package. - No upstream sources in the packaging team VCS. As Andreas said in this thread and in ohters (about the Debian Menu system for instance), we are eager to use the best solution if they are established, documented and durable standards. Of course, we are aware of the shortcommings of our approach, and this thread made us understand them better: - Just because there are patches in debian/patches does not say how to use them. - Patching a patched file is not convenient. - After doing apt-get source, the unpatched sources are displayed, and there is no instruction on how to review the patched sources. Anyway, the situation is not that bad: it seems that only three systems take the lion's share of patch management: dpatch, quilt, and cdbs. All use the same directory, the two first manage their patches using the only file in the directory that is not a patch, 00list or series, and the last one just applies everything. Quilt and cdbs accept patches that originate from the diff command. So for most uses, there is no need to deeply understand the patch system to add or remove a patch, with the major problem being apparently to generate patches for the dpatch system (this is why I do not use it anymore). Nevertheless, it is a bit scary to hear that one of the systems, quilt, is not actively maintained. Does this mean that at any time the tool could be removed and that we would have to migrate all our packages to another system? Group maintainance of such core tools would definitely help. Debian has grown big, and information diffuses surprisingly slowly (who knew about debcheckout before reading this thread ?). I am sure that we (the Debian-Med packaging team) are not the only team that would like to have some assurance that the packaging tools they use will have a lifetime of a few releases. How about identifying the major components and organising a certification system similar to the architecture certification? I would be very happy to decide to use only certified tools. Have a nice week-end, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sources of dak ?
Dear Developpers, I wanted to check if dak was case-sensitive when parsing the DM-Upload-Allowed field, but I did not find this string in the sources that I got from `apt-get source dak'. I then checked debian/copyright, that pointed me to http://cvs.debian.org/?cvsroot=dak, in which I did not find anything either. Are there more recent sources available to non-DDs? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is the DM-Upload-Allowed case-sensitive ?
Le Sun, Jan 27, 2008 at 09:08:44AM +0100, Martin Zobel-Helas a écrit : > On Sun Jan 27, 2008 at 16:53:59 +0900, Charles Plessy wrote: > > I wanted to check if dak was case-sensitive when parsing the > > DM-Upload-Allowed field, but I did not find this string in the sources > > that I got from `apt-get source dak'. I then checked debian/copyright, > > that pointed me to http://cvs.debian.org/?cvsroot=dak, in which I did > > not find anything either. Are there more recent sources available to > > non-DDs? > > http://ftp-master.debian.org/bzr/ Thanks a lot! I am affraid that I did not manage to find the answer by myself. Does anybody know if the DM-Upload-Allowed is case-sensitive, i.e if 'Yes' is not a correct value to enable DM uploads ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is a free document whose sources have been lost free?
> Charles Plessy <[EMAIL PROTECTED]> writes: > > To make the dialign-t package, I removed the documentation from the > > upstream tarball, that I use for a dialign-t-doc package, in the > > non-free section as the their LaTeX sources are not provided. > > > > Now, I was informed that the reason is that the sources have been lost. > > > > In that case, don't the .html, .pdf and .ps files become the "preferred > > form for modification"? Le Fri, Jan 25, 2008 at 08:08:48PM -0800, Russ Allbery a écrit : > My opinion is yes, as explained in the copyright file for openafs-doc, and > ftp-master apparently agreed sufficiently to let the package into the > archive. (Although they weren't released under the GPL -- the specific > license may make a difference, and I haven't checked what license > dialign-t is under.) Le Fri, Jan 25, 2008 at 10:35:16PM -0800, Don Armstrong a écrit : > Unless the pdf is exceptionally complicated, it's not all that > difficult to resurect LaTeX that does a similar job; it'd probably be > ideal to do this and distribute the pdf files built from that, unless > the underlying codebase never changes and you won't ever need to fix a > bug in the documentation. Thanks for your answers (and thank for the private answer I got as well). I will prepare an update of dialign-t using unmodified sources and ask for the removal of dialign-t-doc from non-free. Actually, the documentation has been almost completely rewritten in DocBook format for making the manpage of dialign-t for Debian, but I am reluctant to replace the original html and pdf files: it is just like adding my name into a work I have not done. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely (Was: State of the project - input needed)
Le Sun, Jan 27, 2008 at 01:37:25PM +0100, Pierre Habouzit a écrit : > On Sun, Jan 27, 2008 at 11:23:45AM +, Loïc Minier wrote: > > On Sat, Jan 26, 2008, Pierre Habouzit wrote: > > > And in taht sense, wig&pen that allow you to put multiple diffs rather > > > than a single .diff.gz with your orig tarball is quite enough. > > > debian/control is already here for the rest, and we just need some more > > > Vcs-* like headers, or some new resource to list the proper Debian > > > packages upstreams (maybe in mole ?) since Vcs-* headers in a given > > > package cannot be updated if the maintainer changes, and that the Vcs he > > > uses changes location. > > > > Is the above a proposal to include each individual patch / feature as a > > separate .diff in the source package? IOW foo.dsc would point to > > foo.tgz, foo.debian.diff for the Debian packaging, and patch-1.diff, > > patch-2.diff etc.? This doesn't sound very practical for large > > patchsets. :-( > > Not really, it would point to the orig.tar.gz's, a debian.tar.gz that > would hold the content of debian/, and a patches.tar.gz that would hold > a quilt series in it. Or anything similar, that's just an example. Hi all, In tried to summarise the current discussion in a wiki. The first draft is here: http://wiki.debian.org/debian/patches There are gaps in the table: I do not know about dbs and wig&pen for instance, so people are welcome to modify the page. Pierre, if your patches.tar.gz proposal is different from wig&pen, feel free to add it of course. I also like quilt a lot, but I am wondering if quilt is needed for the apply/deapply steps at build time. Maybe if somebody could provide a way that quilt use the strategy of simple-patchsys (apply everyghing that has a .diff or .patch suffix) instead of the series file, or the reverse, it would be a first step towards standardisation. (If simple-patchsys accepts patch with headers made by quilt). Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Le Mon, Jan 28, 2008 at 11:33:39PM +1100, Ben Finney a écrit : > > It seems to me that you can only agree with the position that "you can > check out the source to the package using 'apt-get source'. This > allows examination and midification of the source to any package" if > "the source to the package" is agreed upon. Hi all, In that case, I think that the man page of apt-get should be authoritative on what is expected from running 'apt-get source': "source causes apt-get to fetch source packages." The definition of the debian source package in Policy C.3 does not mention that the upsteam sources must bear all the modifications that the debian/rules makefile applies to them before starting compilation and/or installation. So for the moment there is no tool for people to examinate the patched sources without having to know about the patch systems. Maybe a bit of Policy on a 'patch' rule for 'debian/rules' and an option --patch for 'apt-get source', or 'dpkg-source', would solve this aspect of the problem. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: electronics-menu REJECTED (discussion)
Le Wed, Jan 30, 2008 at 05:24:50AM +1100, Andrew Vaughan a écrit : > > > As a user technical seems awkward and unintuitive to me. I would rather it > was called Science and Engineering. [Since the question is not… technical, let's transfer this part of the discussion on [EMAIL PROTECTED] Hi all, there has been a debate on debian-devel on how we could name a FreeDesktop menu that would contain applications related to science, techniques, engeneering, maths, and electronics. Please see the following page for reference: http://wiki.debian.org/ExtraMenus It would be great to reach a consensus on the name, if the idea that proposing a single entry instead of two or three is accepted. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Le Thu, Jan 31, 2008 at 10:54:03AM +0200, Lars Wirzenius a écrit : > Perhaps it would be better to make the creation of the source package > create a .diff.gz that already has the patches applied? This may be > more complicated to change, and probably requires changes to how the > patch systems are used. Hello Lars, Basically it would mean to have the clean rule call calling 'patch' instead of 'unpatch', isn't it? I think that it would defeat the reason why people use patch sytems: to break out the .diff.gz into logical parts. If packages start to have half of the diff.gz originating from patches, and half from direct modificaitons to the source, it will turn into a horrible mess, especially that the unpatch rules can not be guaranteed to work in this case. As Teemu Likonen wrote in his latest email, to be able to repack patched sources after modification, it would be required to interact with the patch systems to generate a new patch. But this is adding a lot of complexity. I am wondering if just mandating 'debian/rules patch' to work if debian/patches exist shouldn't be just sufficient. Correct me if I am wrong, but aren't most of the people using patch systems working in teams? In that case, NMUers can simply make a diff between modified and untouched sources, and send it via a bug report: one of the purposes of team work is to ensure high responsivity. In the case of packages maintained by MIA developpers, getting rid of the patch system could be a viable option, since it means that nobody cares for the package anyway. But I am still missing something: how can we get the benefits of using a patching strategy, that is to break up changes into logical components, with the VCS strategy? I would't mind swiching, however I do not know for others, but for me it would require some help and explanations. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Hi again,
Two long answers:
- In the fist I propose that the 'patch' rule could only be provided by
snippets such as those of dpatch, quilt, and CDBS, so that there is no
security risk running this command.
- In the second I question the VCS model, mostly because I still do not
fully understand how to keep the advantages of the patch systems in
this alternative workflow.
> > On to, 2008-01-31 at 20:03 +0900, Charles Plessy wrote:
> > > I am wondering if just mandating 'debian/rules patch' to work if
> > > debian/patches exist shouldn't be just sufficient.
> On Thu, Jan 31, 2008 at 01:09:44PM +0200, Lars Wirzenius wrote:
> > The only big problem I have with that is that is required some unknown
> > subset of build-dependencies to be installed, and to run code _from_
> > _the_ _package_, just to unpack a source package. This makes me
> > uncomfortable: you have to install and run complicated tools and
> > untrusted code, with all the potential for bugs and security trouble
> > that involves, just to see the source code.
Le Thu, Jan 31, 2008 at 11:54:18AM +, Colin Watson a écrit :
> I have a similar discomfort. We regard bugs in tar that allow malicious
> tarballs to do bad things as security vulnerabilities, and rightly so.
>
> That said, we could have this behaviour controlled by an option, so that
> if you knew you were fetching a trusted signed package from the Debian
> archive then you could supply the option, and otherwise (say you were
> examining a package provided by a sponsored developer whom you didn't
> know very well) then you could omit the option and get safe behaviour.
Le Thu, Jan 31, 2008 at 11:51:05PM +1100, Ben Finney a écrit :
> It's no security risk to unpack a tarball, apply a patch to it via GNU
> 'patch', and examine the result. (I don't even have to trust debhelper
> for that, since it's not part of unpacking the source.)
>
> I'm *not* happy to need to run some target with arbitrary commands in
> the 'debian/rules' file, just to allow me to examine the source. A big
> part of the reason for unpacking the source could be to find out
> what's in there *before* executing any part of it.
I do not know if it would be reasonnable to extend the scope of the
discussion to third-party packages. For the packages distributed by
Debian, there are quite many safety guards that should make people think
that it is not unsafe to run 'debian/rules patch' (for the moment it has
not been proposed to go through another mechanism).
- The package has been signed by a DD.
- In some cases, it has been built on trusted machines, and the build
logs are publically available.
- What 'debian/rules patch' is doing can be inferred by remotely
examinating the diff.gz file.
- In many cases, the 'patch' and 'unpatch' rules are factorised code
that can be read from /usr/share/{cdbs|quilt|dpatch}.
Each of these points have their flaws, and in the end, I agree tha the
process is not very convenient. But I am still surprised that the risk
of running 'debian/rules patch' from official Debian pacakages is felt
to be so high.
I have proposed in an earlier mail to "qualify" tools a bit in the same
way as Debian qualifies release architectures. If the Policy would put
constraints on the 'patch' and 'unpatch' rules, it could be for instance
that they must be inherited from the /usr/share/foo/bar.make snippets of
"qualified" patch systems. Would it help to solve the security problem?
> Charles Plessy <[EMAIL PROTECTED]> writes:
> > But I am still missing something: how can we get the benefits of
> > using a patching strategy, that is to break up changes into logical
> > components, with the VCS strategy?
Le Fri, Feb 01, 2008 at 12:01:15AM +1100, Ben Finney a écrit :
> Make commits to the VCS branch for the package, at the same level of
> granularity (or finer) as you would write individual patches. Be sure
> to describe the commit with a good message, just as you would comment
> a patch file. With any decent modern VCS, each individual commit can
> be inspected at any later date, including generating a patch against
> another arbitrary revision.
The major flaw I see in this proposal is that the information conveyed
in the paches of debian/patches are separated from the Debian source
package. Internet connection would be required, unless the logs are
shipped as part of the package in some organised format.
In the end, the use of debian/patch is — at least in my hands — not a
technical tool to manage changes, but a communication tool to make the
changes easily understandable to fellow team members. Unlike commits,
patches are a single entity. In the VCS approach
Re: How to cope with patches sanely
Hi Lars, I do not get your point.
If you are concerned that the persons who sent you a package to sponsor
have put malicious code in it, what I guess you will first review is
wether the scripts you have to execute to test the packages are safe. If
you trust the orig.tar.gz tarball and if it has the same md5sum than
upstream, having all of the packager's work under the debian directory
seems to be an advantage to me. Once it is clear that the packager did
not put bad things in the packaging scripts, if inspecting the content
of debian/patches is not your preffered way to work, you can run
'debian/rules patch' safely. And if you are doing a lot of sponsoring,
how likely is it that cdbs, dpatch and quilt are not installed on your
system? In this sponsoring scenario, the benefit of not using a patch
system is mostly to have less lines packaging code to audit.
What I thought we were discussing is that there are too many patch
systems in Debian, and that people who want to modify existing packages
(NMUers, QA team, Security team) can not be requested to learn how to
use them to patch the sources ('debian/rules patch' in 99,99 % of the
cases), or — more seriously — are annoyed that after having modified an
existing package dpkg-buildpackage will fail because 'debian/rules
unpatch' will not work anymore. Shall we conclude that the idea of
automatically applying the patches when the sources are unpacked is
ruled out by the complexity and the side-effect security issues that it
would create ? In the end, checking by hand wether a patch system is
used is not such a big deal: the information is very obvious in most of
the cases, and the standardisation of targets such as 'patch-new', as
proposed earlier, would be much more useful. And thanks to the code
factorisation through makefile includes, these new targest could be
propagated quickly.
I just have read a few more messages in this thread. Maybe it is too
late here, but sorry, I do not understand everything. I have nothing
against change, but if the change is not beneficial to me, and if nobody
helps me to understand, how can I change my tools?. I know I will never
NMU the glibc or the kernel anyway, so I have no incentive or pressure
to study power-tools that will not give me so much benefits in regard to
the investment. However, if somebody could take a video of Pierre's talk
at FOSDEM, I would be grateful. Any howto for dummies would also be
appreciated. Just reading mails saying "your're wrong" with parcellar
inline replies will not make me smarter. In the end, this whole thread
started because powerusers need patch users to stop using patches, not
the reverse. So friends, please come down at our level, and explain us
what to do.
Have a nice day,
--
Charles
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely? -> Tentative summary on http://wiki.debian.org/debian/patches
Le Thu, Jan 31, 2008 at 11:52:28PM +0100, Andreas Tille a écrit : > On Thu, 31 Jan 2008, Steve Langasek wrote: > > >No, but I think it's a *bug* that this is not the common case. If more > >packages were maintained in distributed VCS, it would become practical to > >consider publishing official "Debian" branches in an organized fashion, > >keeping them synced with the maintainer's branch and letting NMUers push > >their own changes to the Debian branch so that they're trivially mergeable > >by the maintainer with full change history. > > Well, I have no personal experience with other VCS than CVS and SVN > but I see some sense behind your arguing and I'm perfectly willing > to enhance my skills if I see some kind of master plan behind it > to enhance Debian in general. Good morning, afternoon or evening everybody, In order to help the master plan to be prepared, I tryed to update the summary of the discussion in the wiki: http://wiki.debian.org/debian/patches Of course, please feel free to rephrase, reorganise, complement and alter the page. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#463643: no i386 and powerpc build daemons available which can run 64bit binaries
Le Fri, Feb 01, 2008 at 11:11:19PM +0100, Matthias Klose a écrit : > Package: general > Severity: important > > There are no i386 and powerpc build daemons which run a 64bit kernel. > This means that packages requiring testsuites to be run for 64bit > won't run and won't be tested on a regular basis. If we do want to be > able to test packages build for a biarch setup we should have build > daemons to be able to run the testsuites for these packages as well. > > This currently affects at least gcc-4.X and glibc. Hi Matthias, Apparently there are ppc64 machines available here: http://tuxppc.rz.uni-augsburg.de/ I do not know if they run the 32- or 64-bit port in their userland, however. At worse, you can also look for people having such installations on the following wiki page: http://wiki.debian.org/VolunteersForPowerPC Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan
Re: How to cope with patches sanely
Le Fri, Feb 01, 2008 at 11:42:49AM +0200, Lars Wirzenius a écrit : > > At the moment, I can unpack a source package and then review it before I > run anything. You propose to make things more complicated by having to > review things before unpacking. I find that to be an unwanted, > unnecessary, and _dangerous_ complication. > We can create ways in which > patches are applied by dpkg-source directly, for example, instead of > having to run code from the package. That's the point of my > participation in this sub-thread: to stop the _wrong_ way of > implementing this. Hi Lars, hi all, Of course, the idea of having dpkg-source applying the relevant patches trough its own routines is better than having it calling 'debian/rules patch', for the security reasons you explained before. I have reviewed bug #250202, which was nicely summarised by Russ Allbery in early January, and tried to update the summary of our discussion on the wiki and to integrate ideas from bug #250202. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=250202#335 http://wiki.debian.org/debian/patches As said before, the direction that is currently taken at the Policy level would be to require documenting how to "make the source ready for editing" in a file called README.source. It would be recommended to implement a 'patched' target that would take care of this. The security issue you raised has also been noted in #250202, therefore it is not proposed to automate the calling of this rule (in addition, it would require to know the build-dependancies before unpacking, which is not convenient). So I guess that if you like your idea of implementing patching natively in dpkg-source, it is recommended to contribute it to the discussion of bug #250202. There is another possibility that has been suggested, which is to build the source package with the patched sources. An immediate side-effect of this is that it overloads the .diff.gz, but such kind of overloading has apparently been tolerated in other cases, in particular for packages using autoconf/autmake, so why not? Lastly, I would like to ask a quesiton about Wig&Pen: as it would be illegal to provide both a .diff.gz and a .debian.tar.gz file at the same time (http://www.dpkg.org/dpkg/NewSourceFormat), it seems that it matches well the debian/patches workflow, except that the trick of patching the sources at clean time would not work anymore. But the biggest problem may be that unless I missed something, there was no clear answer when it was asked if somebody was woring on Wig&Pen. Is there sombody working on Wig&Pen? Is the format consensual enough that it would be accepted in Debian? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch, "diff -u" and "very big projects"
Hi all,
http://wiki.debian.org/debian/patches is world-writeable, and attempts
to summarize what was said in this thread and in the Policy discussions
about 'README.source'. Do not hesitate to edit it !
Le Sat, Feb 02, 2008 at 10:52:01PM +0900, Osamu Aoki a écrit :
>
> You have column for "accepts diff -u output" and "No" for dpatch. I am
> not quite sure what is the criteria for you but to me dpatch accepts
> "diff -u" output for "patch -p1". At least that is what I did as lazy
> person. All I had to do was add some header text copied at the start of
> patch file.
>
> So at least: Yes (by adding header text)
Well, it is exactly what I meant by "No": if somebody sends a patch made
by {{{diff -u}}} it can not be used by dpatch without processing. I
replaced "No" by "Header needs to be added", but feel free to change it.
Le Sat, Feb 02, 2008 at 02:13:21PM +, Sune Vuorela a écrit :
>
> It claims that debian/patches is "not very convenient for very big
> projects"
>
> I very much don't agree. I am quite satisfied with working with
> debian/patches and quilt and cdbs simple patchsys.
Well, it was said in the thread that for very big projects the patch
systems are not convenient, but if it is not consensual it is better to
remove this from the summary, unless it is really an issue for Debian.
Have a nice Sunday,
--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan
Under the snow!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Standardisation of the name of the patching targets included in debian/rules.
Dear maintainers of CDBS, dpatch, and quilt, if you are subscribed to [EMAIL PROTECTED], you must have noticed the long discussion about patch systems. An idea that was quite popular was to standardise the patch target in all patch systems used during package building. Here is a summary of the targets used by the different makefile includes available to the developpers: FilePackage To patchTo depatch /usr/share/dpatch/dpatch.make dpatch patch unpatch /usr/share/quilt/quilt.make quilt patch unpatch /usr/share/cdbs/1/rules/patchsys-quilt.mk quilt apply-patches reverse-patches /usr/share/cdbs/1/rules/simple-patchsys.mk cdbsapply-patches reverse-patches /usr/share/cdbs/1/rules/dpatch.mk cdbsapply-dpatches deapply-dpatches Since these five files provide patching facilities to a large number of Debian source packages, it would be very advantageous if they could use the same name for the patching and depatching rules: developpers could use them without needing ab initio knowledge of the underlying system. Obviously, there is no solution that wouldn't require a change in at least two packages, and that is the reason I contact all of you and CC debian-devel. Have a nice day, -- Charles Plessy Debian-med packaging team Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Le Tue, Feb 05, 2008 at 02:16:09PM +0200, Lars Wirzenius a écrit : > Specifically I want "dpkg-source -x" to unpack a source package so that > it is ready for modification, and "dpkg-source -b" to build a new source > package after it's been edited. Patch systems can and should conform to > that, since it's important for those doing archive-wide QA. Hi Lars, thank you for keeping us focused on the real problem. I have been trying to think about it and still did not find an elegant solution. Suppose that, as discussed earlier, "dpkg-source -x" provides source ready for modification: Case 1: It is because all the changes were in the diff.gz. Case 2: It is because a clean way of applying the contents of debian/patches has been developped and used. In that case, unless "dpkg-source -b" has been similarly engineered to turn the new changes into a new patch, things will fail when "debian/rules clean" calls the unpatch rule and the changes overlap an existing patch. Case 3: It is because the sources have been packed patched. In that case, "dpkg-source -b" is expected to work. Now, let's remember the use case for these scenarii: it is when the packages is modified for NMU or QA. If the NMU'ed package is to go back in the hands of its maintainer (not MIA or so busy that he can not do more than one upload per year, of course), as I wrote earlier, why not simply send a diff in a bug report? Then the work overhead of integrating the changes in the source package goes to the person who chose the packaging workflow. Otherwise, let's sees what happens with Cases 2 and 3. In Case 3, the changes that you would make would be hidden in a diff.gz file that would be bloated by design: it would already contain a mixture of modifications to the source and patches shipped as patches to a patch. For the maintainer, the most efficient tool to recover your changes from this would be a debdiff with the old version, which then calls the question of why just sending a diff instead of producing a new source package would not be enough. The easier scenario is of course the variant of Case 2 in which where a automagic dpkg-source would take care of detecting the patch system and turn your modifications into a new patch. But I have not seen any person volunteer for working on such a modification. So maybe the simplest solution would be the following : - Standardize the name of the patch rule so that "debian/rules patch" does the job. - dpkg-source -b && debian/rules patch - make a diff and send it to the BTS. or, in the case of unmaintained packages: - get rid of the patch system if you think that it is not good for QA work on it. It leaves the problem of trusting the command "debian/rules patch" when working on non-official packages, but as I wrote before, the other targets of debian/rules would have to be audited anyway, so why not checking them first, and then run "debian/rules patch" ? (or decline to sponsor the work of persons storing their changes in debian/patches). Of course, I would be very interested to hear better solution, because as I wrote, this one is not particularly elegant. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
Le Wed, Feb 06, 2008 at 04:30:01PM +0100, Jean Parpaillon a écrit : > > 3. All advertising materials mentioning features or use of this > software must display the following acknowledgement: > This product includes software developed at the University of > Tennessee, Knoxville, Innovative Computing Laboratories. Bonjour Jean, This is the "advertisement clause" of the original BSD licence. Some works in main are or were distributed under this clause, so it is considered DFSG-Free. However, distributors of Debian can easily infringe this clause: for instance, if an hypothetical magazine, "Clusterised Linux" would sell an issue with a DVD of Debian Lenny and advertise it with a slogan such as "Debian Lenny: faster with upgraded kernel and HPL memory distribution", the university of Tenessee could obviously claim that the licence has not been respected because their name has not been cited. This example is maybe a bit artificial, but the point is that with such licences in main, redistributors who use advertisement should in theory read all the copyright files to check who to acknowledge. For this reason, I wouldn't recommend to include this program in main. But there is a much better solution. The problem has been well explained on FSF's website: http://www.gnu.org//philosophy/bsd.html and importantly, the university of Berkeley from which this licence originates has now abandonned the advertisement clause. This is a strong argument, and with it I was able to obtain the relicencing of a 4-clause-BSD-licenced program by the Whitehead Institute. I think that you have your chances with the university of Tenessee. Have a nice day, -- Charles Plessy Debian-Med packaging team. Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
Le Wed, Feb 06, 2008 at 06:44:38PM -0800, Russ Allbery a écrit : > Charles Plessy <[EMAIL PROTECTED]> writes: > > > This example is maybe a bit artificial, but the point is that with such > > licences in main, redistributors who use advertisement should in theory > > read all the copyright files to check who to acknowledge. For this > > reason, I wouldn't recommend to include this program in main. > > There is already much software in Debian main with this license and other > Debian Developers who do not agree with this and who will continue to > include such software in Debian main. (It is, after all specifically > called out as a free license in the Debian Free Software Guidelines.) So > the practical impact for a Debian derivative of including or not including > one more package with the four-clause BSD license is minimal. Hi Russ, I think that it is a bit frivolous to distribute software with advertisment clause in main and not properly warning the redistributors, who are the most likely persons to infringe the clause. We should remeber that for other aspects of licencing and intellectual property management, Debian is much more rigorous, so the presence of 4-clauses BSD licences is contradicting the principle of least surprise, that is usually a good guidance. Importantly, the copyright holders of such programs are often not the programmers themselves, but the universities, who nowardays face very strong financial pressures and delegate more and more the management of the intellecutal property to specialised services, who can be ran by people who know nothing about the spirit of free software that blessed the researchers when they wrote their programs. This is why, as a personnal choice, I do not take the responsability of introducing new packages with the BSD advertisement clause in Debian, and I suggest others to refrain as well. Anyway, I really think that there are good chances to obtain a relicencing, that is by far the best way to find a solution that pleases everybody. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
Le Wed, Feb 06, 2008 at 10:27:55PM -0800, Russ Allbery a écrit : > > Am I missing something? This ? http://web.archive.org/web/19990210065944/http://www.debian.org/misc/bsd.license http://web.archive.org/web/20001205083200/http://www.debian.org/misc/bsd.license -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
news from mips?
Le Sat, Feb 09, 2008 at 08:10:20PM -0500, Philippe Cloutier a écrit : > > it would be much more efficient to work on buildd > redundancy (or other improvements to the buildd network). By the way, is there a plan to solve the problem of mips not keeping up apart waiting for a miracle to happen? Sorry to be rude, but I am just so surprised that there is a such big problem and that apparently nothing is done. If people are working on the issue, just let us know, they will get many kudos and everybody will be happy. In the absence of any communication, you know, there is the usual frustration... -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: news from mips?
Le Mon, Feb 11, 2008 at 05:36:21PM +0100, Martin Michlmayr a écrit : > * Charles Plessy <[EMAIL PROTECTED]> [2008-02-11 19:26]: > > I am really thankful for Tim and Martin to work on a MIPS machine, but > > currently we do not even know if there is a plan to make it a buildd, > > No, it will be a porter machine. Thanks for the clarificaiton ! As a workaround for the build queue, since MIPS can be emulated I was wondering if it would be acceptable to upload mips or mipsel binary packages together with the source one when we perform upgrades. Especially when we do not expect the package to be used on MIPS anyway. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: pre-building NEW packages, when they only introduce new binary packages
Le Mon, Feb 11, 2008 at 02:44:59PM -0500, Philippe Cloutier a écrit : > > If the NEW package gets earlier in the queue, it's built more quickly, > but packages that come later are built more slowly. Dear Philippe, if the ressources are scarce, I think that it would be fair that the internal competition for the access to them would be organised in a productive way. The current system disfavours the works that changes the structure of the package. How does this fit in a strategy to optimise the usage of the buildd power in Debian? Of course there are alternatives to competition. When a buildd has a 15-day queue for more than a month, we could agree to refrain from uploading changes that can be postponed, in the same spirit as the people who share their cars when trains are on strike. An alternative approach would be to add a buildd, but for a reason that I do not understand, it seems to be off-topic on this list. So let's learn the "décroissance" way in Debian, it is a good training for real life anyway. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pre-building NEW packages, when they only introduce new binary packages
Le Sun, Feb 10, 2008 at 08:06:38PM +0100, Evgeni Golov a écrit : > On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote: > > > > That probably won't make much time difference on "fast" archs (i386, > > > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes > > > hold up testing transition :(). > > A missing build will only slow testing migration if the package wasn't > > built when the unstable testing delay is over. Since almost all uploads > > to NEW are low urgency, the build would need to take over 10 days to > > affect the time to testing migration. > > pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet > uploaded] today), so it *can* make a difference (not a really big one > though in this case) Indeed, especially that it has been said that having the buildds not keeping up is not uncommon during a release cycle, implementing a mechanism to reduce the impact of this problem would be a good thing. We are ending up in a similar stress situation as for last release, when uploading to NEW many weeks before the freeze we were wondering if the package would be part of the release or not. People with responsibilities in Debian's core infrastructures should consider that it is demotivating for many. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
Le Sat, Feb 09, 2008 at 01:26:55PM -0500, Joey Hess a écrit : > Riku Voipio wrote: > > I think the short term solution to this dilemma is to compile a list > > of attributions needed to be included in advertizment material. > > Also a list should be compiled attributions needed n documentation > > (such as libjpeg's). Obviously most distributors/boob writers will > > not notice such lists, but that's a different problem... > > Most writers don't have to worry about it, it's not as if we advertise > Debian as "Debian.. now with Thomas G. Lane's JPEG support and OpenSSL". > The advertisement clause tries to not allow those specific attributions > to be used in advertisements; it does NOT require that advertisements > contain any specific list of citations. Actually, this is true for libjpeg and false for openssl and other programs using similar BSD-related clauses. libjpeg: Permission is NOT granted for the use of any IJG author's name or company name in advertising or publicity relating to this software or products derived from it. This software may be referred to only as "the Independent JPEG Group's software". openssl: All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)" Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: news from mips?
Le Mon, Feb 11, 2008 at 11:28:48AM +0200, Riku Voipio a écrit : > On Mon, Feb 11, 2008 at 12:08:13AM +0900, Charles Plessy wrote: > > Sorry to be rude, but I am just so surprised that there is a such big > > problem and that apparently nothing is done. If people are working on > > the issue, just let us know, they will get many kudos and everybody will > > be happy. In the absence of any communication, you know, there is the > > usual frustration... > > I wonder - after a quick glance on debian-mips mailing list, > it seems you _have_ been communicated on this issue: > > http://lists.debian.org/debian-mips/2008/02/msg00017.html > > You are even in the To: list of that mail... Well, this email says that somebody needs some hardware to put a MIPS machine on line. The kind of mail I would have liked to receive, for instance on -devel-announce would be for instance: Example 1: -- Hello, this is a message for the MIPS porters. We noted that many package transitions are delayed because of they are not yet build on mips and mipsel. We are really sorry for the inconvenience and we are currently working with the persons responsible for the buildds to find a solution. Example 2: -- Hello, this is a message from the MIPS buildd administrators. During the past two weeks, the queue in the machines we are in charge of has been growing, and this is causing delays for the testing transition of the packages of may of you. This was caused by an unusual number of uploads, and we expect that normal operations will resume within three weeks. This kink of peak is exceptionnal and we hope that it will not happen again this year. Example 3: -- Hello, this is a message from the MIPS buildd administrators. The Debian archives is growing and our current buildds become undersized for the task: a queue has started to form, resulting in delays for the transition of your packages. We are working on increasing the build power for the mips and mipsel arches, and hope the queue to dissapear within a month. I am really thankful for Tim and Martin to work on a MIPS machine, but currently we do not even know if there is a plan to make it a buildd, nor if the problem is really a problem of load or just an unattended bug, or whatever else. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: news from mips?
Le Wed, Feb 13, 2008 at 03:40:24PM +0100, Florian Lohoff a écrit : > > Ryan and me have been communicating on a hardware mod on rem - one of > the mipsel buildds. Basically the machine is running on a PIO based ATA > disk because of the fundamentally broken design of the IDE interface > (abusing some leftover GPIO pins). I already got hold of a DMA capable > PCI controller which will be put into the machine most likely end of > this week and will bring a performance boost as it has been seen on > other BCM based buildds. Dear Florian, thanks a lot for the information and the work. In the future, maybe this kind of issue could be more easily tracked if the ports had their own pseudo-packages in the BTS ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Meaning of the "Altering package upload rules"
Le Thu, Feb 14, 2008 at 01:12:44PM +0100, Enrico Tassi a écrit : > On Wed, Feb 13, 2008 at 11:07:22PM +0100, Lucas Nussbaum wrote: > > On 13/02/08 at 22:21 +0100, Stefano Zacchiroli wrote: > > Currently, we already have several DDs building their packages without > > using an up-to-date, clean sid chroot. If we start throwing away the > > Even if the package is rebuilt, the uploaded debs are not useless. > You may debdiff them and eventually informe the developer that: > - his build environment is corrupted (or the buildd's one) > - his package build process is installation sensitive (behaves > differently on a different installation). Hi all, This is a very good idea, but the reason why source-only uploads are not allowed is that there are concerns that if the binary package is not used for real, the quality of the source package will drop. Within this hypothesis, there is no incentive for the laxist developper to use the valuable feedback that you propose. When he communicated about source-only uploads in his email of January 2007, James Troup wrote: "This is not something I personally think is a good idea but I won't stand in the way of consensus of the Release Managers and the developer community as a whole." http://lists.debian.org/msgid-search/[EMAIL PROTECTED] Therefore, to move forward, It seems that the opinion of the release managers is needed. The other concern of James Troup is that the i386 buildd may not keep up. So I guess that another piece of the puzzle is in the hand of the i386 buildd maintainers, the release team, the i386 porters, and the system administration team. Then, because "a consensus between the Release Managers and the developer community as a whole" has been required, a GR will be needed. Since it is a necessary step, the writing of it may be a useful tool to clarify arguments before presenting them to the persons in charge ? Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standardisation of the name of the patching targets included in debian/rules.
Dear developpers, following the discussion on patch systems and standardisation, here is the wishlist but I sent to the cdbs package. (#466259) I hope that it can lead to some progress… Have a nice day, -- Charles Plessy - Forwarded message from Charles Plessy <[EMAIL PROTECTED]> - Date: Sun, 17 Feb 2008 23:37:31 +0900 From: Charles Plessy <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: cdbs: Standardisation of the name of the patching targets included in debian/rules. X-Mailer: reportbug 3.31 Package: cdbs Version: 0.4.48 Severity: wishlist Le Sun, Feb 03, 2008 at 06:32:42PM +0900, Charles Plessy a écrit : > Here is a summary of the targets used by the different makefile > includes available to the developpers: > > File Package To patchTo > depatch > /usr/share/dpatch/dpatch.make dpatch patch unpatch > /usr/share/quilt/quilt.make quilt patch unpatch > /usr/share/cdbs/1/rules/patchsys-quilt.mk quilt apply-patches > reverse-patches > /usr/share/cdbs/1/rules/simple-patchsys.mkcdbsapply-patches > reverse-patches > /usr/share/cdbs/1/rules/dpatch.mk cdbsapply-dpatches > deapply-dpatches Dear CDBS hackers, Two weeks ago I have contacted the mainainers of the three most popular patch systems in Debian, to ask them their opinion about the standardisation of the name of the targets they use in the includes they provide for debian/rules makefiles. I have got an answer from the quilt maintainers, saying that they will follow the conclusions of the discussion, and the opinions expressed on debian-devel are supporting the idea of using patch and unpatch as target names. Since it is the name already used in dpatch, and since the quilt maintainers agreed to modify /usr/share/cdbs/1/rules/patchsys-quilt.mk if needed, the most straightforward way to reach standardisation would be if you would change /usr/share/cdbs/1/rules/simple-patchsys.mk and /usr/share/cdbs/1/rules/dpatch.mk to support the use of 'patch' and 'unpatch' instead of 'apply-patches', 'apply-dpatches', 'reverse-patches' and 'deapply-dpatches'. The direct benefit of such a standardisation would be that in most cases, when a 'debian/patches' directory exists, there would be an obvious command to try for applying the patches, that would work in most of the cases. I do not know enough the internals of CDBS to evaluate if my request would be easy to implement, but in any case, feedback would be most welcome, to know if this is an open issue or not. Have a nice day, -- Charles Plessy Debian-Med packaging team Wakō, Saitama, Japan - End forwarded message - -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466682: ITP: emboss-kaptain -- graphical interface to EMBOSS using Kaptain
Package: wnpp Severity: wishlist Owner: Charles Plessy <[EMAIL PROTECTED]> (Hope I am not breaking parsers... how about using a template that is directly cut-pastable in/from debian/control and debian/copyright ?) Source: emboss-kaptain Homepage: http://userpage.fu-berlin.de/~sgmd/download.html Description: graphical interface to EMBOSS using Kaptain EMBOSS.kaptn is a graphical user interface (GUI) for more than 200 programms of the EMBOSS sequence analysis package. It uses Kaptain, a universal front-end for command line applications. EMBOSS is a collection of high-quality free Open Source software for sequence analysis. With EMBOSS.kaptn it integrates nicely into X window based desktops like KDE. X-Source-Downloaded-From: http://userpage.fu-berlin.de/~sgmd/download.html X-Upstream-Author: Thomas Siegmun Files: * Copyright: © 2001-2003, 2008 Thomas Siegmun License: GPL-2+ The maintainer of the Debian kaptain package is apparently MIA (no upload since two years, most packages NMUed), however it is said in the EMBOSS.kaptn package that Kaptain's upstream is planning a new release this year. Kaptain is out of the scope of the Debian-Med packaging team, to I would be happy if somebody showed interest in keeping the kaptain package alive in Debian. EMBOSS.kaptn contains a patch to build Kaptain with QT4. EMBOSS.kaptn itself is mostly .kaptn and .desktop files, and therefore is a low-hanging arch: all fruit. Have a nice day, -- Charles Plessy Debian-Med packaging team, Wakō, Saitama, Japan.
Re: the new style "mass tirage" of bugs
Le Thu, Feb 21, 2008 at 10:54:09PM +0100, Michael Tautschnig a écrit : > What about the following (happy flaming...): Let's just pick > openoffice.org. Rene needs help. It has 340 open bugs. We're > somewhere around 1000 DDs. Makes 3 developers per bug. Let's just > randomly form teams of 3 from all DDs and assign a single bug to each > team. One week to submit a patch to the BTS. Hi all, Similar to the BSP model, bug triaging parties could also provide nice opportunities to do that kind of effort in synergy, (and to socialise afterwards). Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Le Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava a écrit : > > That is not the case when using featrure branches, the NMUer can > get the information they need. > > But if you are a security NMUer, you have a short time frame, Hi all, actually, we as packagers have wrote a lot of statements a lot in the name of NMUers and the security team, but in fact independant opinions of NMUers have not been read often in this thread, nor from the security team about what they expect from source packages. Therefore we can all be plain wrong, as we have no evidence that NMUers want what we are arguing for: stack of patches and/or link to a fully version-controlled source tree. The only thing that seems to make a consensus is that when people have to modify a package that they have not created, and that it uses a patch management system, they waste time trying to figure out what is the debian/rules target to patch the source tree. Changing this would need to modify two or three packages out of dpatch, quilt, and cdbs, and unfortunately only the maintainers of quilt package have expressed interest in a standardisation. Therefore we did not make progress since the beginning of the discussion: - The most efficient way to deal with changes to the sources for the packager is to use his preferred tools. - We do not know if the whole concept of breaking up the monolithic diff into logical units is something that the persons who often do NMUs in Debian are intersted in. - When modifying a package that uses dpatch, quilt or simple-patchsys, developpers have to find out by themselves if the target for patching the sources is patch, apply-patches or apply-dpatches. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Le Sun, Feb 24, 2008 at 10:47:05AM +0100, Raphael Hertzog a écrit : > > > - When modifying a package that uses dpatch, quilt or simple-patchsys, > > developpers have to find out by themselves if the target for patching > > the sources is patch, apply-patches or apply-dpatches. > > Once the new dpkg-source format is in standard use, those rules disappear > completely... because they are no more needed during build. I must have missed something. I thought that the new format was to keep the debian directory in a tar.gz format. With this format, people who want to modify upstream sources will have to use a patch system. What is the plan to make the patch targets in debian/rules unneeded? Have a nice day (and thank you for your work on a new format for source pacakages.) -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: news from mips?
Le Fri, Feb 22, 2008 at 09:55:08AM +0100, Florian Lohoff a écrit : > > The mipsel buildd rem has a new disk and the buildd dir will be moved > which will speed it up a lot (PIO vs DMA) Dear Florian, this is good news: we can see mipsel getting better on the buildd stats: http://buildd.debian.org/stats/graph2-week-big.png However, it does not give much help for packages to migrate in testing: the queue on the mips buildd is still growing. Is there any plan to solve this problem ? Some packages are blocked for almost a month, and judging from the absence of buildd logs for mips(el) for some packages that recently migrated, it seems that the best way to deal with the problem is to upload binary built elsewnere… I know that it is not pleasant to hear, but again: for the package I care about and that are waiting to be built on mips, I have never had any evidence that they have users on this port. I would be glad to be proven wrong, but in the meantime, we are delaying service to our users for no benefit at all. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Buildd backlog and testing transition.
Le Fri, Feb 29, 2008 at 10:40:57AM +0100, Marc 'HE' Brockschmidt a écrit : > > Due to kernel problems, the mips* buildds haven't been very reliable in > the past few weeks, creating a lng backlog of packages that need to > be built. As there seems to be a workaround for the kernel bug, this > should start getting better from the weekend on. As a maintainer: Just > wait. Dear Marc, it is good news to read that there is a solution being found. However, I am a bit confused because previous messages were suggesting that the problem was disk speed, not downtime. In the meantime, could the release team do us the favor of letting the packages migrate? I just got a message from a user who wants to use one of the blocked packages (emboss), and I am just so ashamed to answer him that he has to use unstable just because it is not built on a platform where nobody is using it. Please. Our work is left aside for no benefit, and if I understand correctly, transiently allowing the migration is just a matter of changing a configuration file two times. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary vs "real debian" packages
Le Fri, Feb 29, 2008 at 03:05:58PM -0800, William Francis a écrit : > > my contents are not source (configure, make, etc), rather I'm more > interested in the preinst/postinst scripts, the Depends part of the > control file, a few config files and placing a few scripts on the > filesystem that require no compiling. > Further, I understand the concept of an upstream provider and > understand that I don't have one in this case Dear William, If you do not plan to release the packaged files separately, you may be interested in the "native" format of source packages, in which the debian directory and the upstream files are contained in the same tar archive. The unpacked source package looks the same be it native or not, so general tutorials are good readings anyway. You can refer to the new maintainer guide for instance: http://www.debian.org/doc/maint-guide/ If all you have to do is move files, you can shortcut a lot of the complexity by using the common debian build system (CDBS): http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml If you have more questions, they may be more relevant on the [EMAIL PROTECTED] mailign list: http://lists.debian.org/debian-mentors/ Have a nice week-end, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildd backlog and testing transition.
Le Sat, Mar 01, 2008 at 10:45:31AM +0100, Florian Lohoff a écrit : > > So you might devote your time to > > a) Find the cause of the build crash > b) Hunt down the kernel bug in 2.6.24 > c) Poke at the buildd admin to move the buildd to the new disk subsys This is ridiculus and provocative. I have no interest in the MIPS architecture, and all that I ask is that we can do our works independantly. I would be happy to help by adapting my packaging work, for instance by saving buildd time with less uploads and test disabling on MIPS. But that was never requested, and even argued against. I do not know what else to propose. Why don't the MIPS porters support a request to let packages migrate to testing while they find a solution? Why is it impossible to run the kernel that was used before mid-january? When you will finally have solved your problem, what will Debian have gained in having prevented bugfixes to enter testing for two monthes? If it is impossible to set up backup buildds nor to communicate with your buildd admin, then please do not ask the whole project to wait for your problems to be solved, nor to solve them for you. Please let our pakcages migrate to testing. Thanks for respecting our work, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
