Re: Please allow the migration of the packages stalled in the MIPS buildd backlog.
What about simply decoupling mips/mipsel's version numbers so an out of date package on mips(el) doesn't stall out the rest of the testing. Having (somewhat) setup britney/update_out to generate testing for m68k, it should just be a matter of adding of adding mips and mipsels, to the proper lists in update_out.py. As it stand armel uses this (hence why in update_excuses it says Ignoring armel dependency). As I haven't fully gotten britney running, there could obviously be a big problem, but it might be a fessible way to allow mips/mipsel to have testing, and not break everyone else. Michael On Sun, 2 Mar 2008, Lucas Nussbaum wrote: Date: Sun, 2 Mar 2008 18:57:03 +0100 From: Lucas Nussbaum <[EMAIL PROTECTED]> To: debian-devel@lists.debian.org Subject: Re: Please allow the migration of the packages stalled in the MIPS buildd backlog. Resent-Date: Sun, 2 Mar 2008 19:26:18 + (UTC) Resent-From: debian-devel@lists.debian.org On 02/03/08 at 23:34 +0900, Charles Plessy wrote: I have not asked MIPS to be removed from the list of released architectures. I have asked testing migration to be uncoupled from MIPS building while the buildds are suffering. In a previous thread it has been suggested that this operation requires a minimal amount of work. It requires a minimal amount of work to remove mips from the architectures considered for testing transitions. On the other hand, it requires a lot of work if we still want to release with mips after that, because from that point, testing and testing-mips will start diverging. Getting them back in sync will be really hard, and actually, it's likely to cause us to release without mips. So, even if it would be better to have testing be in good state, it's not a release blocker yet, and developers should concentrate on fixing bugs. Users can use testing + apt pinning. I use that on all my !stable systems. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
I'm going to have to agree with this; I admin m68k buildds; I had to preinstall most of the texex packages simply because it was taking hours (and that is not an exaggeration) to install them all, and then remove them all again. A trigger based system would help relieve this problem. I had a similar slowdown installing texex packages on a slower powerpc That being said, I neither agree nor disagree with the hijacking of dpkg, but triggers are important, especially for slower architectures. Michael On Mon, 10 Mar 2008, Adam Borowski wrote: Date: Mon, 10 Mar 2008 00:07:15 +0100 From: Adam Borowski <[EMAIL PROTECTED]> To: debian-devel@lists.debian.org Subject: Re: dpkg semi-hijack - an announcement (also, triggers) Resent-Date: Sun, 9 Mar 2008 23:11:16 + (UTC) Resent-From: debian-devel@lists.debian.org On Sun, Mar 09, 2008 at 02:17:15PM -0800, Mike Bird wrote: On Sun March 9 2008 14:46:50 Cyril Brulebois wrote: Is dpkg handling the boot sequence? Or are you confusing that with dependency-based initscripts? I hope I'm not mis-stating Frans's position when I say that Frans believes dpkg triggers are the best way to install dependency-based initscripts[0]. Otherwise the installer unnecessarily and repetitively globally recalculates initscript dependencies for each package installed. I expect dpkg triggers would also be valuable for things like mktexlsr runs when working with texlive. AOL. Try installing anything tex-related on a slow or mid-speed machine. So, what about leaving the bikeshed painted in Ian's color, and starting from that point? There are two strong technical arguments: 1. triggers being a vital piece, and 2. diverging from Ubuntu is badly counter- productive. And then you can duke it out about NULL vs (char*)0 to your heart's content. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470995: ITP: devotee -- Debian voting system
Package: wnpp Severity: wishlist Owner: Michael Casadevall <[EMAIL PROTECTED]> * Package name: devotee Version : 0.1patch2 Upstream Author : Manoj Srivastava <[EMAIL PROTECTED]> * URL : http://www.debian.org/ * License : GPL Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : Debian voting system Devotee is the debian voting system, used when offical matters are called to a vote. It intergrates with LDAP, and GPG, and isolates each voting task into a seperate program to ensure votes are not lost due to an error in devotee. -- System Information: Debian Release: lenny/sid APT prefers gutsy-updates APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy-backports'), (500, 'gutsy') Architecture: i386 (i686) Kernel: Linux 2.6.22-14-generic (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Future of the s390 port
On Mon, Aug 31, 2009 at 12:46 PM, Marco d'Itri wrote: > On Aug 31, Bastian Blank wrote: > >> I doubt that I would be able to push this port through another release >> in the current state. The consequence would by that the port dies >> completely and with it the only free and released distribution for this >> machines. > Is this really an important problem? > Does a significant number of people actually use Debian/s390 on > production servers? And if they exist, why they are not helping? > I think a bigger question is where do you find hardware where you can get remote root on; I'm not very familiar with s390 or mainframes in general, but its not a piece of hardware one individual person would own. I'm aware of the Hercules emulator, but that doesn't seem like it would be useful for general development of a port. Michael > -- > ciao, > Marco > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkqb/koACgkQFGfw2OHuP7G4NACfSPn2hWvMsEU1DhfSCk0M9boh > vi0AnR2IzJJyChe76F4vORV79qdP/9hi > =QbZi > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Package management unsafe?
Maybe a check should be added to APT to flag a warning if there has been no updates for a significant period of time? That way if a mirror ever does that, its more detectable. Michael On Fri, Jul 11, 2008 at 8:55 AM, Steinar H. Gunderson < [EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson wrote: >> http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html >> >> What are people's thoughts on this? > > It's been known for quite a while. (I asked one of the guys publishing it, > and he was fully aware of that, but felt it was still important to bring > light to it.) > > In any case, it's pretty hard to exploit as long as you have security updates > on a different (trusted) server. The best thing you can do is DoS the process > so the user's package management software crashes, or simply never update > your mirror so users don't get updates. > > /* Steinar */ > -- > Homepage: http://www.sesse.net/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Re: Package management unsafe?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It doesn't have to have updated packages, maybe have something like this APT-Ping: *timestamp* and then push out a new packages file with just an updated timestamp in it. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFId//JpblTBJ2i2psRAu6uAJ48+knPTzxi1InA/Wg3AN4m2Rt8WwCfa/ES rddl6+w/Kw+7UBVNQLjLplE= =fGdJ -END PGP SIGNATURE- On Fri, Jul 11, 2008 at 8:39 PM, Frank Lichtenheld <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote: > > Maybe a check should be added to APT to flag a warning if there has been > no > > updates for a significant period of time? That way if a mirror ever does > > that, its more detectable. > > That really doesn't make any sense for stable users since our point > releases aren't exactly weekly ;) > > Gruesse, > -- > Frank Lichtenheld <[EMAIL PROTECTED]> > www: http://www.djpig.de/ >
Re: Packages getting marked not-for-us
Correct me if I'm wrong, but it seems like a pretty bad idea to NFU software that can be compiled on an architecture even if it doesn't seem that useful. I have the X11 libraries on my NSLU2, which lacks any graphical output, but I use it as an X11 server. That being said, I can see the point from the s390 build admins; as a m68k porter, I don't think we need to spend the time compiling fight sims and such for an architecture that has no where close to the processing power to run it, and thus I can see why NFUing useless packages can help save wear and tear on the s390 buildds. Michael On Tue, Aug 5, 2008 at 4:58 PM, Mark Brown <[EMAIL PROTECTED]> wrote: > On Tue, Aug 05, 2008 at 12:21:52PM -0500, John Goerzen wrote: > > > This seems to happen to me most often on the s390 build daemon, and has > > happened with at least 3 to 5 different packages now. (Current example > > is hpodder). In fact, I don't think I've ever seen it happen elsewhere. > > > It seems to happen when build-deps don't get satisfied, or where there > > is some problem installing the build-deps. > > This is quite common with the s390 buildd - it tends to happen when it > appears that the package may not be useful on s390 (eg, due to apparing > to require hardware not available on s390), apparently based on the > package description. > > -- > "You grabbed my hand and we fell into it, like a daydream - or a fever." > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > >
Re: What is the target used by buildd?
sbuild calls dpkg-buildpackage to build the package. It doesn't touch the rules file directly. On 8/8/08, Francisco Moya <[EMAIL PROTECTED]> wrote: > Hi, > > I believed buildd.debian.org was meant to build only binary-arch packages. > > But in recent build logs of the zeroc-ice package: > http://buildd.debian.org/build.cgi?pkg=zeroc-ice;ver=3.3.0-4 > I found buildd tried to build a binary-indep package (libzeroc-ice-3.3-cil). > > Using ./debian/rules binary-arch in a chrooted environment in an x86 box > works as expected. I made my x86 build log for binary-arch target available > at > http://arco.esi.uclm.es/~francisco.moya/debian/zeroc-ice_3.3.0-4_i386.build > > Is this a buildd/sbuild/wanna-peruse bug? > > Thanks > > Francisco Moya <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: projectb users - we want you
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm not a DD so I can't add myself to the list; I'd like to see better support for importing dsc files and binaries into the archive (aka to importing an existing archives (import-archive now works though after I gave it a lobotomy). Database wise, the only thing I could see being a worthwhile improvement to whats already there would maybe be moving the bug closed lists to the database so they can be queried without having to go parsing through text files. That being said, that improvement probably would only affect Debian itself, and very few dak/projectb users. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: http://getfiregpg.org iEYEARECAAYFAkihSYMACgkQpblTBJ2i2puKxACeOdvLRWO/xmhMOINRnlpjk8ja tekAn0AblyCJ4JX+NBBuahMebKXkYBff =SoLc -END PGP SIGNATURE- On Mon, Aug 11, 2008 at 5:38 PM, Cameron Dale <[EMAIL PROTECTED]> wrote: > On Wed, Aug 6, 2008 at 12:13 PM, Joerg Jaspert <[EMAIL PROTECTED]> wrote: >> Please login to merkel and add yourself to ~joerg/projectb.users (the >> file is mode 666, so everyone with login is able to do it). > > Done. I'm surprised at the few entries after almost a week. Is no one > using projectb, or is everyone busy at debconf? > >> Also, as a user, or potential user, of that database - feel free to let >> us know what other data you would like to see in it. We might actually >> put it into the database then. (It has to be related to the archive in >> some way, so we wont randomly list, eg., bug data or something, but one >> example would be adding the descriptions or so). > > I'd like to have access to all of the hashes of the files, SHA1 in > particular, instead of just the MD5. > > Also, there's some information available in the archive that doesn't > seem to be available in projectb, but that it would be nice to have. > The suite_architectures table is incomplete (only listing unstable, > experimental, sarge-r0, and etch-m68k). And there also isn't a way to > determine the codenames from the suite names without looking in the > Release files. > > Thanks, > Cameron > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a local mirror of m68k, and both kfreebsd ports, and they're roughly 70-80GB including source. If ries has become so full that space is becoming an issue, then dropping arm, hurd-i386, and m68k is a stopgap move at best (your only going to recover maybe 50GB, 10 for hurd (it only has half the archive built), and 20 each for arm and m68k). As for CPU usage and RAM, I'm not really seeing it; dak itself only is "executed" during dinstall, where automatic processing of all dak queues are run. GPG signatures are checked during import, which should not be much of a burden. The only thing that should be CPU intensive is apt-ftparchive generate, and only when importing a new archive or rebuilding the packages files after trashing the cache files (on modest hardware, it takes apt-ftparchive to do a full rebuild of an architecture roughly 40 minutes, but unless there is an issue with the caching, I don't see what the burden on resources is. As for chopping up the archive into subsections, dak itself can handle managing multiple archives pretty well (I'm not sure how great it is about moving stuff from section to section, but that can be fixed with a simple python script). It makes sense for me that each section that already exists could be divided, so instead of say, just unstable, have unstable-net, unstable-devel, unstable-base, etc. This has the wonderful added bonus that having a new architecture could have their own testing for sections they have fully built. For some of the larger package groups (KDE, GNOME, XFCE), those can each be their own section. Each architecture's porters can choose what sections to include. I'd say go one step farther and have a release manager appointed from each section to handle that release; which has the added bonus of also revealing the workload on the current RMs. Priority should determine if something MUST be present to do any release. Pretty much make it so anything that is Priority required or higher must be built, and the rest is up to the architecture porters. As for architectures wanting to get into debian, shX is currently looking at least four ports just to handle the subarchs (that's a discussion for another time), netbsd-* is dead (has been since '02),. kfreebsd-* is pretty close to releasable; they've got the archive built in the high 80s, and are keeping up). It seems to me the current policy of the ftp-masters is to only accept a port once its fully built and releasable; armel is the only relatively new port, and that was completely staged on d-ports, and didn't join sid on the archive until it was reasonable. When did it that become debian policy? Running a dak server is not the easiest task in the world (d-ports uses mini-dak), and configuring and managing a local wanna-build isn't that easy, especially considering there is virtually no documentation, and a lot of of it is trial and error. All other ports were built within sid itself, hell, m68k was the first port of debian, which created the buildd and wanna-build infrastructure alll other ports use! An added note on this subject is the constant trouble of adding SSH keys to buildd.d.o. and general wanna-build administration. hurd-i386 currently hosts their w-b on debian-ports, and m68k has had constant issues getting keys added to the point of sheer lucidity. How hard is it to copy and paste a few lines into buildd-m68k authorized keys? It just seems that any more with less then 100 users seems to be well a second class citizen. A part of me wonders when other ports with limited userbases are going to start getting dropped; for me, one of the biggest strengths of Debian was the fact that it runs on pretty much everything (only Gentoo can match in platforms supported at last count). As for dropping architectures, this was proposed as part of the vancouver proposal, but I don't understand why we're following this if the rest of the proposal was NEVER implemented. According to the proposal, the four most popular architectures (i386, amd64, ia64, and powerpc) would remain on ftp-master, and the rest would become second-class citizens, and be moved to scc.debian.org. That same server would also run a full blown dak and handle accepting new architecutres. As far as I can tell, that never happened, and debian simply changed that architectures must be fully bootstrapped and built before they will be accepted vs. just requiring three DDs to advocate the port. I also read that doorstop.debian.org would be created for hosting newer architecture, which would run dak and such; again, never implemented. Right now,all we have debian-ports, which isn't even an official Debian service for hosting new architectures, and is currently maxed out. If the problem with adding new architectures is that reis is maxed out, the solution is not dropping old architectures, its upgrading the server since just removing older ones is a stopgap solutions at best. I've been told ther
Re: Upcoming changes to supported architectures
Well, there was talk about implementing a Platform: field in dpkg to mark a package Linux, Kfreebsd, or Hurd specific without having to adding !kfreebsd-i386, etc. to the arch list or P-a-s. Not sure where that went (although I think dpkg now recognizes the field, which means quinn-diff and perhaps apt-ftparchive would be needed to get it into the Sources file, and such). Putting packages that are unwanted in an architecture for NFU is fine if the port is unreleased, but just a week or go, we had an issue with a package because the S390 buildd admins had deemed it useless and added it to that list. Michael On Fri, Aug 15, 2008 at 9:03 PM, Samuel Thibault <[EMAIL PROTECTED]> wrote: > Michael Casadevall wrote >> kfreebsd-* is pretty close to releasable; they've got the archive >> built in the high 80s, and are keeping up). > > BTW, it may be worth noting that a bunch of packages still include > headers: in the Failed part of hurd-i386, 178 packages out > of 1320 fail at least because of inclusion of #include > (there could be others hidden by other compilation problems). That's > 2.29% of the 7748 packages in our wanna-build database!... And we still > have 1952 packages in the dep-wait state, a lot of them probably include > too... > > Some of these packages could probably be fixed into automatically > disabling some linuxish features, or use more standard headers (like > sys/types.h...), but still a bunch of tools use for a > very good reason. The 95% figure may have to be revised unless we ask > non-linux ports to implement linuxish interfaces... > > Samuel > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
I'll add my two cents. I have some experience with radios. The FCC requires all radios to be certified before they can be sold, and there is a requirement that you must not make a device that is easily modifiable to operate outside the limits put forth by the FCC. In this case, it would be illegal to release the firmware's source code since it would violate the FCC rules, violate and void the radio's certification (and this also applies to Wifi/Bluetooth devices). I do agree firmwares fall under the DFSG and the social contract, and they should be split out, but included on the CD/DVDs so I can at least enable full hardware support out of the box. Michael On Thu, Oct 30, 2008 at 1:11 PM, Michelle Konzack <[EMAIL PROTECTED]> wrote: > Am 2008-10-30 17:49:40, schrieb Giacomo A. Catenazzi: >> But most of the firmwares are outside wireless communication. > > Right, but they are some like the one from me. > >> How many manufacturers was sued because users burn the monitors >> (it was very easy) or other hardwares (e.g. try with hdparam) ? > > Do you think, someone (manufacturers) is making it public? > >> How many non conforming GSM devices are sold? How many of such devices >> are recalled by manufactures? > > You can not even sell GSM devices, if your software is not certified. > The recalls are very very low... because they are tested > > Thanks, Greetings and nice Day/Evening >Michelle Konzack >Systemadministrator >24V Electronic Engineer >Tamay Dogan Network >Debian GNU/Linux Consultant > > > -- > Linux-User #280138 with the Linux Counter, http://counter.li.org/ > # Debian GNU/Linux Consultant # > Michelle Konzack Apt. 917 ICQ #328449886 > +49/177/935194750, rue de Soultz MSN LinuxMichi > +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I hereby resign as secretary
The problem is you can't wave a magic wand, and fix the community. It's a self-feeding cycle which goes on and on and on. Even if we had a Code of Conduct for Debian, unless it was strongly enforced, its the same problem. Whether the ballot was valid or not was immaterial, the response to it was clearly inappropriate. If we flamed people to hell and called for their removal for every mistake, we won't have a single developer or user left. Maybe its worth considering adopting a CoC for Debian, and actually enforcing it, but that's someone for the community to decide, should we ever get past flaming each other to get something done. Michael On Fri, Dec 19, 2008 at 3:18 AM, Lionel Elie Mamane wrote: > On Thu, Dec 18, 2008 at 11:57:06PM -0600, John Goerzen wrote: > >> Well, I haven't left, but I do far less with Debian now than I used >> to. > >> It is still my preferred OS for a variety of reasons. (...) > >> I get no joy whatsoever out of the current mailing list >> discussions. (...) We're here to make a Free operating system, dammit. >> People that are not here to make a Free operating system shouldn't be >> here. > >> I have considered leaving the project several times this year. The >> fun of being a Debian developer went away long ago. I maintain >> packages for my own utility now, at home and at work, and that's it. > > I do recognise in me the same symptoms as those you describe. I > haven't really analysed much to have an opinion on whether I ascribe > them to the same causes as you or not. > > Several of my DD friends have solved the problem by unsubscribing from > d-de...@l.d.o, d-v...@l.d.o, etc. > > -- > Lionel > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
On Mon, Dec 22, 2008 at 5:55 AM, Russell Coker wrote: > On Monday 22 December 2008 17:55, "Paul Wise" wrote: >> On Mon, Dec 22, 2008 at 6:08 AM, Kjeldgaard Morten >> >> wrote: >> > Another model that I think has not been discussed is never freezing >> > stable. >> >> Freezing is the whole point of stable, if we didn't freeze it, it has >> no reason to exist. > > In the current design "stable" means frozen. > > The suggestion was that you have a branch named "stable" (which actually could > be given some other name) that consists of packages that have been > through "testing" and found to pass some criteria suggesting quality (in the > same way that "testing" has packages that have passed through "unstable" > after some days of delay without new versions). > > Then the frozen branches would have some name other than "stable". > > Basically it's a suggestion for two levels of "testing". > The thought of a rolling release system has a lot of appeal to me for desktop usage, but not for server usage, since each update contains the potential to break things. It might be worth investigating into, I know such infrequent releases makes using RELEASE-backports, or running testing becomes almost essential if you want updated tools. > -- > russ...@coker.com.au > http://etbe.coker.com.au/ My Main Blog > http://doc.coker.com.au/ My Documents Blog > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Thoughts about including scsiaddgui
Hi, On Thu, 2007-08-30 at 09:43 +0200, Steinar H. Gunderson wrote: > On Thu, Aug 30, 2007 at 08:22:36AM +0100, Neil Williams wrote: > > Yes. Except that you don't have to go trying to find someone. You should > > file a RFP bug against wnpp and wait until someone has sufficient > > interest and skills to take on the maintenance of this package in > > Debian. > > Has there ever been a case where an RFP bug has actually stimulated anyone > into packaging a given piece of software? I packaged nrss two days ago (its still on mentors.debian.org) due to an RFP, and after that one gets a sponsor, I'll probably see if any other packages there interest me, and then package them. Michael > > /* Steinar */ > -- > Homepage: http://www.sesse.net/ > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
