Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...
Steve Langasek <[EMAIL PROTECTED]> writes: >> The typical situation here is that code that has the same set of DFSG >> bugs is already in place and so it is questionable of what a reject >> really achieves (i.e. does the archive become more DFSG-compliant or >> not) and quite typically fixes some RC bugs (not always trashing >> people's hardware). > > This does not seem to be a position universally held by the ftp team What is the designated way for escalating a dispute like this with ftp-master? With "Like this" I mean packages that have been held back in NEW for a very long time without response or REJECTED with an reason not acceptable to the maintainer? Does mediating this kind of issues fall under the authority of the TC, or should they be escalated rather to the DPL? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs
Tatsuya Kinoshita <[EMAIL PROTECTED]> writes: > Anyway, I'll add more information to the package description and > README.Debian. Also, I'll consider the conflict of EasyPG. The > alpaca feature should not be enabled when EasyPG's epa-file feature > is enabled. How about integrating/merging alpaca into EasyPG? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...
Reinhard Tartler <[EMAIL PROTECTED]> writes: > With "Like this" I mean packages that have been held back in NEW for a > very long time without response or REJECTED with an reason not > acceptable to the maintainer? Does mediating this kind of issues fall > under the authority of the TC, or should they be escalated rather to the > DPL? Well, if a package is in NEW for a long time, that's something that really cannot be mediated, as it probably means that none of the ftpmasters (or assistants) have had the time to look into it (meaning it is very likely a very complex package with licensing issues), and no authority in Debian can force any project member to do work the member doesn't want to do. If a package is REJECTED with a reason the maintainer thinks is invalid, I think the first step should be to tell the ftpmaster (as a group) the reasons. It is always possible that a ftpmaster (as a person) has made a mistake. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
Le jeudi 23 octobre 2008 à 16:08 +0200, Robert Millan a écrit : > On Thu, Oct 23, 2008 at 08:36:24AM +0200, Raphael Hertzog wrote: > > Your lack of knowledge of Debian processes sucks (that means: you > > annoy us (at least me) with your stance and the fanatic way you defend it > > in public, please stop this and come back to more constructive > > discussions). > > And I take it that Thomas is supposed to take your attitude as an example > on how being constructive? Maybe you should take it that even our favorite care bear is starting to be pissed of by his behavior. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...
On Fri, 2008-10-24 at 10:57 +0300, Kalle Kivimaa wrote: > Reinhard Tartler <[EMAIL PROTECTED]> writes: > > With "Like this" I mean packages that have been held back in NEW for a > > very long time without response or REJECTED with an reason not > > acceptable to the maintainer? Does mediating this kind of issues fall > > under the authority of the TC, or should they be escalated rather to the > > DPL? > > Well, if a package is in NEW for a long time, that's something that > really cannot be mediated, as it probably means that none of the > ftpmasters (or assistants) have had the time to look into it (meaning > it is very likely a very complex package with licensing issues), and > no authority in Debian can force any project member to do work the > member doesn't want to do. > > If a package is REJECTED with a reason the maintainer thinks is > invalid, I think the first step should be to tell the ftpmaster (as a > group) the reasons. It is always possible that a ftpmaster (as a > person) has made a mistake. Indeed, I recently actually had this happen to me. An upload that I made was rejected by an FTP Master (for convenience copies of code) - when I pointed out to the FTP master the reason(s) why this was there (was actually modified from upstream, debian didn't have the latest package, the latest packages had huge API changes, etc etc) - he was happy to let it through. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503279: ITP: libjakarta-ecs-java -- Element construction set for various markup languages
Package: wnpp Severity: wishlist Owner: Kalle Kivimaa <[EMAIL PROTECTED]> * Package name: libjakarta-ecs-java Version : 1.4.2 Upstream Author : Stephen Nagy <[EMAIL PROTECTED]> and Jon S. Stevens <[EMAIL PROTECTED]> * URL : http://jakarta.apache.org/ecs/ * License : Apache 2.0 Programming Lang: Java Description : Element construction set for various markup languages Generation API directly supports HTML 4.0 and XML, but can easily be extended to create tags for any markup language. Documents are created through native Java objects instead of gegnerating the markup directly. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Wed, 22 Oct 2008, Manoj Srivastava wrote: > On Tue, Oct 21 2008, Henrique de Moraes Holschuh wrote: > > On Tue, 21 Oct 2008, Manoj Srivastava wrote: > >> acceleration, right? So the box can be installed, and is usable for > >> non-gaming purposes. The drm stuff can possibly be gotten from non > > > > You can always use VESA, yes. I don't think the X.org driver can get an ATI > > GPU to work without the memory management *microcode* (but I didn't know > > that > > thing was still non-free). > > That should be good enough to install, and then add non-free to > sources.list and get the firmware required for the driver to work > (absent a non-free debian installer that bundles non-free bits). This > is no different from what I have had to do already for my nvidia card > (degraded X support until I arranged to have non-free nvidia drivers > installed). I would think that was an acceptable solution. As someone who only owns ATI GPUs and one legacy nVidia GPU (I don't have any Intel, basically because I couldn't get good enough screens in the Laptops with Intel graphics at the time I bought them and when I got the nVidia, ATI was still as closed as a clamp), I would consider the above solution to be acceptable. I also deem it acceptable if we as a project were to proceed by refusing to add any and every *new* driver that requires non-free components to Debian, adding them to non-free when possible, and removing them completely when we don't have the right to distribute the non-free components at all (i.e. it is not good even for non-free). I can deal with a two-step install process for my video cards, as long as it is properly documented. But I would serioulsy recommend that we produce easy to use non-free installer disks to go along with the Debian installer disks, not because of the GPUs, but because of the network cards. If this would slow down the release too much, make these AFTER the release, there is no reason why we can't release non-free a bit later. Whether ATI microcode still deserves to be in non-free is an orthogonal issue. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Fri, Oct 24, 2008 at 10:20:43AM -0200, Henrique de Moraes Holschuh wrote: > I can deal with a two-step install process for my video cards, as long as it > is properly documented. But I would serioulsy recommend that we produce > easy to use non-free installer disks to go along with the Debian installer > disks, not because of the GPUs, but because of the network cards. If this > would slow down the release too much, make these AFTER the release, there is > no reason why we can't release non-free a bit later. I recently installed a new server with Etch which uses a bnx2 network chip. This requires firmware from non-free. It wasn't particularly hard to install the firmware package on another box, copy the resulting firmware file to a usb stick, and mount it from vt2 and place it in the firmware directory so that the installer could load the network driver. A slight bit of work, but not hard. I do not expect debian to produce an installer with non-free code included. After all non-free is not part of debian as far as I understand things. Documenting the requries steps would be nice of course. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs
On October 24, 2008 at 9:18AM +0200, siretart (at debian.org) wrote: > How about integrating/merging alpaca into EasyPG? I'll request the always-use-symmetric option to the EasyPG developer, which is a major blocker of migrating from alpaca to EasyPG, I think. Anyway, alpaca is a different implementation and well maintained by the other developer. I think that the alpaca package isn't meaningless even if less people use alpaca than EasyPG. Thanks, -- Tatsuya Kinoshita pgpzcAasrq3sE.pgp Description: PGP signature
Bug#503305: ITP: libjabsorb-java -- Java to Javascript object request broker
Package: wnpp Severity: wishlist Owner: Kalle Kivimaa <[EMAIL PROTECTED]> * Package name: libjabsorb-java Version : 1.3 Upstream Author : Jabsorb Team <[EMAIL PROTECTED]> * URL : http://jabsorb.org/ * License : Apache 2.0 Programming Lang: Java Description : Java to Javascript object request broker Simple and lightweight Ajax/Web 2.0 framework that allows you to call methods in a Java web application from JavaScript code running in a web browser as if they were local objects residing directly in the browser. jabsorb handles all the details of marshalling and unmarshalling objects back and forth between the client and server so that you can focus on writing your application features. jabsorb makes use of the JSON-RPC protocol for it's transport mechanism. JSON-RPC is a standard protocol and jabsorb can interoperate with other standard JSON-RPC clients and servers that may be written in other languages. Starting with jabsorb 1.2, additional ORB functionality has been added, and it extends the basic JSON-RPC protocol to allow for passing data structures that contain Circular References. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...
Hi Steve, Steve Langasek wrote: > On Thu, Oct 23, 2008 at 09:44:33AM +0200, Thomas Viehmann wrote: >> Raphael Hertzog wrote: >>> Every kernel upload changing the ABI goes through NEW. > >> The typical situation here is that code that has the same set of DFSG >> bugs is already in place and so it is questionable of what a reject >> really achieves (i.e. does the archive become more DFSG-compliant or >> not) and quite typically fixes some RC bugs (not always trashing >> people's hardware). > > This does not seem to be a position universally held by the ftp team, given > that a library I uploaded to binary NEW ths summer for a > release-team-approved transition was rejected over a source-only issue of > not mentioning in debian/copyright a pre-existing user guide not shipped in > any of the binary packages. Or is it only kernel DFSG-compliance bugs that > get ignored in binary NEW, while all the other nitpicky checks are grounds > for a package reject? Thank you for voicing your concern about inconsistencies you perceive in the processing of NEW (note that "binary NEW" is not a separate location to upload to). As with any manual process, particularly when handled by several individuals, NEW processing will quite probably not be as deterministic as one might wish, if only in the style of reject messages, but probably also in cases that are not entirely clear. As you may know, the ftp team is split into roles of ftp-master and ftp-assistant, with myself being listed as assistant[1]. I have to balance my (felt[2]) obligation to provide the project with information about my work in that position with the fact that my this work necessarily involves assessments that are neither necessarily uniform nor binding for other members of the ftp team. My comment you quote above gives some rationale of why I did choose to add overrides for certain binaries added by linux-2.6, as Raphaël pointed out I had. If you disagree with the descision of letting these pass through NEW, I would be very happy to learn why I should not have done so in your opinion. Unfortunately, you do not give a reference, but if the upload of yours that you have in mind is freetds[3], let me venture that perhaps the considerations[4] I offered in the thread you started about it in July might actually help to put both things into more context. I am sorry to hear that these explanations were not satisfactory to you but must admit that I may have overlooked previous indication of how they fall short. Note that I do not agree with you on the issues you raise in[3], but you surely have more information to add when you bring it up here. If just did not want to pass the excellent chance of someone on the ftp team actually posting something to add some flames about the pet grudge you hold when I was trying to provide information to enable the project at large to take into account the rationale of actions when deciding whether to instruct the people to make better decisions than they do by their own, that is very valuable to me, too. You could be even more effective by CCing the DPL as surely he will be happy to correct appointments his predecessor made precisely eight months ago on this day[5] when they do not work out as expected. Again, thank you for helping to improve Debian's processes by providing your critique. Kind regards T. 1. http://www.debian.org/intro/organization 2. I had the impression that sometimes the ftp team is criticized as not operating transparently enough and think that it is reasonable that the project deserves explanations when they feel that a decision needs scrutiny. 3. http://lists.debian.org/debian-project/2008/07/msg00017.html 4. http://lists.debian.org/debian-project/2008/07/msg00032.html 5. http://lists.debian.org/debian-devel-announce/2008/02/msg9.html -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
Kalle Kivimaa <[EMAIL PROTECTED]> wrote: > Would it be a good compromise between SCs #1, #3 and #4 if we made an > exhaustive list of non-free bits in main, and make it our goal that the > list gets smaller between each release and not to add anything to > that list? The last part of the sentence is unrealistic, because the list would only describe the *known*to*be* non-free bits. There are unknown non-free bits already in the archive[1], and there might be some that slip in by new upstream releases. Regards, Frank [1] Our up-upstream has recently started a license auditing and found several, just look at texlive's most recent RC bugs -- Frank Küster Debian Developer (TeXLive) ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Correct way to move /etc config files
On Tue, Oct 21, 2008 at 11:13:18PM -0400, James Vega wrote: > On Tue, Oct 21, 2008 at 07:32:48PM -0700, Steve Langasek wrote: > > On Wed, Oct 22, 2008 at 01:00:34AM +0200, Luca Capello wrote: > > > Hi there! > > > This mail originates from the discussion at [1]: simply, I need to move > > > an /etc file (/etc/frameworkd.conf) from one package (fso-frameworkd) to > > > another one (fso-config-gta02). > > > However, I don't really know the best way to manage this situation and I > > > cannot find any reference on the Debian Developer's Reference [2] nor on > > > the Debian Policy [3] nor the Debian wiki [4]. > > Use Replaces:, just as for other files that move between packages. > As I understand it, you should also remove the conffile[0] from the > original package according. That's part of "just as for other files that move between packages", yes. :) Replaces: is for /moving/ files between packages; if the file is supposed to be in both packages, that needs to be a Conflicts:. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs
On 11548 March 1977, Tatsuya Kinoshita wrote: >> How about integrating/merging alpaca into EasyPG? > Anyway, alpaca is a different implementation and well maintained by > the other developer. I think that the alpaca package isn't > meaningless even if less people use alpaca than EasyPG. There is the emacs-goodies-el package, this would fit much better than a one-file-only package imo. -- bye, Joerg Lalalala ... Ich bin die Sponsoren-Schlampe - Wer hat heute Lust? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem with libtool relinking
Hi all, I have a problem with libtool; it's an issue that seems to have been affecting people for years but I'm having real trouble hunting down a solution (which I'm sure exists). My problem is that regina-normal currently needs to build-conflict with earlier versions of regina-normal-dev. Otherwise, if an earlier version of the development libraries is installed, libtool will relink some libraries against these old versions at the make install stage. The precise situation is this. The regina-normal source package builds and installs libraries A and B, where B links against A. At the build stage, everything is fine. At the make install stage, library A installs without problems into the DESTDIR, but then libtool tries to relink library B against the older A in /usr/lib (and fails because the older library is missing some new symbols). If I don't have regina-normal-dev installed, then B relinks without problems and also installs correctly into the DESTDIR. This happens with the most recent libtool in sid, and I am configuring with --enable-fast-install (thus the executables don't get relinked, but library B is still being relinked regardless). Does anyone know if there is a better solution than a build-conflicts? Looking through the gimp changelog (as an example), it seems that this problem has been seen and dealt with before in other packages. Anyway, if anyone has ideas then I'm all ears. Ta - Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Thu, Oct 23, 2008 at 01:02:30PM -0500, Ean Schuessler wrote: > Its a lot like exercise. Its not convenient and its not easy but in the long > run its a good idea. Nice pun! :) -- Chris. == I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. -- Stephen F Roberts -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Thu, Oct 23, 2008 at 12:23:22PM -0500, Manoj Srivastava wrote: > On Thu, Oct 23 2008, martin f krafft wrote: > > It's all a matter of defining what your priorities are, which brings > > us back to the Social Contract, which says that these include: > > - 100% freeness > > - cater best to the interests of our users > Frankly, this mindset infuriates me. It frames the discussion > incorrectly, it implies that freeness and user interest are at > odds. No, it acknowledges that freeness and user interest are *sometimes* at odds, and leaves it up to humans with faculties of reason to sort out which of these two competing factors takes precedence in any given situation. Otherwise, it might as well have just said "Our priority is our users"; if you believe that what's best for free software is *always* what's best for our users, and that what's best for our users is to use only free software, then there's no need to spell this out as two *separate* priorities, right? For users whose world is not circumscribed by the boundaries of the Debian project, it is often the case that their short-term needs cannot be satisfied by strictly free-software solutions. To demand, then, that users make do with Free Software when it doesn't meet their needs is self-defeating: it denies us the support of users who are potentially sympathetic to the principles of Free Software, and it denies them the use of the best OS on the planet. To forestall the inevitable strawmen, I'll say plainly that I am *not* arguing that this justifies including non-free software in Debian proper. What I *am* arguing is that we are called by the Social Contract to help ensure Debian's continued utility to the general population, because if nothing else, that's where we find the next generations of developers who will keep our project alive. This doesn't mean we should all drop what we're doing and work on the firmware issue; but at the very least, developers shouldn't be sanguine about proposing the outright removal of firmware blobs, with no support for loading them from non-free, as a "solution". > The same goes for people who are complaining oabout advocates > of the social contract and libre software, calling them folks who do > not care for users. I contend that people who stuff main with non-free > stuff _are_ the ones acting against the interests of the users in the > long term, It's pretty insulting to suggest that there is a non-zero set of developers who have been "stuffing" non-free stuff into main, particularly when the very kernel team that's being maligned by this implication is the same group that has already done the heavy lifting of as much of the sourceless firmware removal as we've achieved so far. > Why is not putting non-free firmware in non-free not the right > thing to do? It is the right thing to do; and while I know there are people that disagree, I haven't seen anyone in *this thread* disagree with that. But there are lots of other things that are "right" to do, and not all of them are possible to achieve at the same time with limited resources. Is it still the Right Thing to remove non-free firmware if we don't also make it possible to load it from non-free at the same time? Is it the Right Thing to delay the next release indefinitely while the firmware problems are sorted out? Right now, I suspect the right thing to do might be for me to abandon this thread and go fix some bugs instead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Fri, Oct 24 2008, Steve Langasek wrote: > On Thu, Oct 23, 2008 at 12:23:22PM -0500, Manoj Srivastava wrote: >> On Thu, Oct 23 2008, martin f krafft wrote: > >> > It's all a matter of defining what your priorities are, which brings >> > us back to the Social Contract, which says that these include: > >> > - 100% freeness >> > - cater best to the interests of our users > >> Frankly, this mindset infuriates me. It frames the discussion >> incorrectly, it implies that freeness and user interest are at >> odds. > > No, it acknowledges that freeness and user interest are *sometimes* at > odds, and leaves it up to humans with faculties of reason to sort out > which of these two competing factors takes precedence in any given > situation. In the long term, I do not think that is the case. In the short term, sure, and we have determined that the place to put non-free things that users might need to address their needs is called the non-free part of the archive. > To forestall the inevitable strawmen, I'll say plainly that I am *not* > arguing that this justifies including non-free software in Debian > proper. What I *am* arguing is that we are called by the Social > Contract to help ensure Debian's continued utility to the general > population, because if nothing else, that's where we find the next > generations of developers who will keep our project alive. Back when we were deciding about all this, Alex Yukhimets argued against the free requirement, saying that including the non-free netscape browser was absolutely critical to the survival of Debian, since other wise we'd have no users. Surprisingly, we survived then, and I suspect we'll survive now. And despite not including non-free netscape in main, the fact we had a social contract that we followed made Debian stronger. > Otherwise, it might as well have just said "Our priority is our > users"; if you believe that what's best for free software is *always* > what's best for our users, and that what's best for our users is to > use only free software, then there's no need to spell this out as two > *separate* priorities, right? And, if you continue to read just a wee bit longer, you'lll see we also say that we will provide such stuff that users need that does not meet our definition of free in -- surprise --- the non-free section. > This doesn't mean we should all drop what we're doing and work on the > firmware issue; but at the very least, developers shouldn't be > sanguine about proposing the outright removal of firmware blobs, with > no support for loading them from non-free, as a "solution". It is not an ideal solution, but is better than sloshing it all under the carpet and pretending all is kosher with our supposed to be 100% free OS. > >> The same goes for people who are complaining oabout advocates >> of the social contract and libre software, calling them folks who do >> not care for users. I contend that people who stuff main with >> non-free stuff _are_ the ones acting against the interests of the >> users in the long term, > > It's pretty insulting to suggest that there is a non-zero set of developers > who have been "stuffing" non-free stuff into main, particularly when the > very kernel team that's being maligned by this implication is the same group > that has already done the heavy lifting of as much of the sourceless > firmware removal as we've achieved so far. Is it any less insulting to say people who want to explicitly acknowledge that we are failing to meet the standards we set ourselves are "user haters", de-constructive whiners and zealots? If insults are what get your goat, I can list a number uttered by people on this thread against people who are raising concerns about silently slipping in non-free stuff in main. Indeed, we have been slimed by the Debian equivalent of being Terrists. >> Why is not putting non-free firmware in non-free not the right >> thing to do? > > It is the right thing to do; and while I know there are people that > disagree, I haven't seen anyone in *this thread* disagree with that. > But there are lots of other things that are "right" to do, and not all > of them are possible to achieve at the same time with limited > resources. Is it still the Right Thing to remove non-free firmware if > we don't also make it possible to load it from non-free at the same > time? Is it the Right Thing to delay the next release indefinitely > while the firmware problems are sorted out? Yes, loaded question, and yes again. I have a piece of hardware not supported by free software. I install the OS, and go through a step where I access the driver from non-free post-install and get the full functionality in a second step. I think that is perfectly acceptable. With netwrok hardware, the ubiquitous USB drive and sneaker net is fine too. It should not take us a
Re: Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs
On October 25, 2008 at 12:34AM +0200, joerg (at debian.org) wrote: > On 11548 March 1977, Tatsuya Kinoshita wrote: > > >> How about integrating/merging alpaca into EasyPG? > > Anyway, alpaca is a different implementation and well maintained by > > the other developer. I think that the alpaca package isn't > > meaningless even if less people use alpaca than EasyPG. > > There is the emacs-goodies-el package, this would fit much better than a > one-file-only package imo. Peter, the emacs-goodies-el package maintainer, do you think so? If so, I'll reassign this wnpp bug to the emacs-goodies-el package and tell you the information for merging alpaca. Thanks, -- Tatsuya Kinoshita pgpaeWSUZ4ckW.pgp Description: PGP signature
