Re: Your biggest achievement during past DebConfs (aka new DebConf promoting campaign)
[Joey Hess] > At DebConf3 in Oslo, I finally met the other Debian Installer developers > gathered together in person, and after a week of challanging work, we > achieved the first successful installation of Debian with it. Are you sure the first successful installation of Debian happened during DebConf3? I remember giving a talk about Skolelinux at that conference and how Skolelinux used d-i to automate the Debian installation. During the talk I ran the installation as a demonstration, and I suspect I would not have tried to do this if I had not done a d-i installation before DebConf3. But my memory is flaky, so I just wanted to ask if anyone remember when d-i actually was able to install Debian for the first time. > This reinvigorated our team, leading to many new members, more rapid > development, and many more developer gatherings. The resulting program > has since been used to install Debian, and derivative distributions, > on tens of millions of systems. Yeah. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flty2qfijd@diskless.uio.no
Re: Debian hardware certification
[Thomas Goirand] > The plan would be to test the hardware (probably with a live CD > using a KVM over IP). If it doesn't work, see what driver isn't > present, and if the backported kernel has the fix. If it does, in > some cases, we could add a patch in a Debian point release, if it's > not too intrusive. I once wrote this check list to test new machines (quickly translated from Norwegian). Perhaps it can be the start of a test framework? Follow these steps to test a new computer model: 1) Boot live DVD or install machine via PXE and boot the resulting installation (we had PXE set up in the network where this was done). 2) If the KDE desktop show up, then the video card is working with X.org. If a small sound is played when KDE is started, the sound card is working. 3) Start a web browser, and visit a web site, for example http://www.skolelinux.org/. If this is working, the network card is working. 4) Choose "Science & Math->Stellarium" from the K menu, and see if the program have quick response. If this is OK, the accelerated 3D graphics support is working. 5) Plug in a USB stick. If a popup show up after a while, the USB subsystem is working. 6) Run nvram-wakeup as root to see if the motherboard and BIOS version is supported. The last point were included because we wanted the ability to shut down machines in the evening and turn them automatically on in the morning. Checklist: [ ] machine boots [ ] X.org video driver working [ ] X.org 3D acceleration working [ ] sound card working [ ] network card working [ ] usb subsystem working [ ] nvram-wakeup supported This cover the most vital parts of a computer. It should probably be extended for laptops and other kinds of hardware. > Having a hardware certified program would increase adoption of > Debian among server users. It will also help Debian fans to buy the > correct hardware they need. Certification have some risks regarding how people view the certification and the project doing it, if problems show up after the test is done (with new versions of the software, or changes to the hardware), and one need to have a clear plan on who is responsible for fixing any such problesm. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flr57rghxe@login2.uio.no
Re: Svgtune
[Andreas Tille] > Any link to the rejection message to learn about the reasons? > Sounds like a cool tool. Searching on Google for wnpp svgtune sent me to http://bugs.debian.org/544071 >. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl1v68wedj@login1.uio.no
Re: buildd/porter/maintainer roles again
[Clint Adams] > Shouldn't it be the responsibility of the buildd admin (if, for some > reason, the buildd admin is not a porter) to notify an > architecture's porters of any porting issues manifesting themselves > in a package build? You bring up the important topic of expectations on who is responsible for what regarding porting of Debian packages to the architectures in Debian. I believe it is important that the separation of responsibilities between package maintainers, porters and buildd maintainers is described somewhere autorative, to ensure that the entire project have a common understanding on who is responsible for what and hopefully avoid or reduce the number of conflicts between package maintainers, porters and buildd administrators. To ensure the various ports of Debian to not put unreasonable strain on package maintainers, I believe it is important that most of the responsibility of getting a package working on a architecture where the package have never built before is placed on the porters and buildd administrators. If this responsibility instead is placed on package maintainers, I believe it is a good idea for Debian to drop the lesser used architectures to ensure they do not slow down the rate of improvement in Debian. Those caring for an architecture (which I assume is the set of porters and buildd administrators) need to be the ones responsible for providing patches to package maintainers to get the architecture working with a given package. Of course this work need to be done together with the package maintainers, but I believe it is unreasonable to expect maintainers to spend time on trying to get their packages working on architectures they do not care for, and am sure it is the way to get Debian to throw out lesser used architectures. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flk4ozs8yj@login1.uio.no
Re: Squeeze, firmware and installation
[Steve McIntyre] > Yup, definitely. We already have an "unofficial non-free" area on > cdimage.debian.org which is where we've been pushing the firmware > zip/tar.gz files already. I'll set up the extra images to be dropped > in there. A few days ago, I extended hw-detect to look for firmware (u)debs in /firmware/ (for PXE boot images) and /cdrom/firmware/, so if you create a CD/DVD with the firmware .deb files in a firmware/ directory in the root of the CD, it should work out of the box. Any license question asked in the package preinst should be displayed, and the firmware package will not be used if the license isn't accepted. The change is in the daily built d-i images already. Please report back if it do not work for you. > I'm guessing that we're not likely to want the extra images for all > architectures: i386/amd64/powerpc(?). Any others? I have no idea. I only use i386 and amd64. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flfx1hxuyc@login1.uio.no
Re: Welcome to our 2010 Debian Google Summer of Code students!
[Steve Langasek] > Although it seems this isn't actually non-free software, I find your > response here inappropriate because it implies developers have no > right to object to a GSoC project done in Debian's name that > involves non-free software. Actually, it implies that there is a time for everything, and objecting to GSoC projects should be done while the project descriptions we offer are being drafted and before they are presented to students, and while student projects are being evaluated, not after the project have presented projects to students and students have accepted them. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flsk61bolr@login2.uio.no
Re: Squeeze, firmware and installation
[Tollef Fog Heen] > It's not uncommon to install machines you are not physically close to > and where plugging in hardware is therefore hard, so having it on the > install media already is quite useful. Yes. It would allow one to create ones own installation CD with firmware included, and get the installer to find them out of the box. I've created a patch for this, available from http://bugs.debian.org/574116 >, but have not had time to test it yet. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flbpctb0dt@login1.uio.no
Re: Welcome to our 2010 Debian Google Summer of Code students!
[Josselin Mouette] > Sorry but I have to object to a project that is based on non-free > software. Especially when we have free and superior packages in the > archive that provide similar functionality. Objection noted, and it is of course accepted and understood that you do not help out with this project. I do on the other hand expect you to not create hurdles for the student to allow the student to be as productive as possible. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flsk6hbd2f@login1.uio.no
Re: Debian money
[Gunnar Wolf] > Some of the big distributions have no moral problem in including > Adobe's propietary plugin, though. We do. Really? I was not aware that it was a moral issue. I thought it was a question of licensing, where the license from Adobe prohibited distribution on the web by third parties. Where did I misunderstand? Which big distributions publish and distribute the Adobe plugin on the web? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian money
[Giacomo A. Catenazzi] > It is useful not only for Debian, so IMHO Debian could donate some > money, but only if other big distributions (RedHat, SuSe/Novel, > Ubuntu, etc.) do the same. I find this to be a rather useless requirement to have, unless the goal is to do nothing. If something is a good idea to do, Debian should do it independently of what the other distributions are doing, otherwise we will waste time trying to convince other distributions instead of spending time on improving Debian. Are you volunteering to convince the other big distributions to donate money to the same projects Debian want to donate money to? I am not. A better approach would be to state that Debian will donate some money and propose publicly for other distributions to do the same. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian money
[Frans Pop] >> 6 Fund other related projects >> >>a Debian Edu. Clearly good for us to do - heavily linked with >> Debian. > > Not sure about that. IMO it's up to the schools and governmental > institutions that use Debian Edu to sponsor that. However, I have > no problem with Debian sponsoring development meetings that aim to > work on Debian Edu, but that comes under the heading of "Fund > developer gatherings". Almost all expenses in the Debian Edu project are for developer gatherings. We try to organize 7-8 gatherings a year, and the cost per gathering is around 2500 EURO, thus giving us a yearly need for 2 EURO. In addition to this, we buy test hardware for use at the developer gatherings, have funded a user conference once, and funded travel and lodging for debconf and other conferences. We funded a Gnash developer gathering last year. The Debian Edu project is almost out of funds, and need more donations. :) >>b Gnash. Petter is very keen on this, but I'm not so sure. Don't >> they have other ways to get funding? Thoughts? > > I don't think Debian as a project should sponsor upstream > development. That's up to individual DDs. A working free software implementation of the flash web plugin is a requirement for Debian to provide a complete free software based desktop. At the moment flash is used on so many web sites that the common user will not accept a browser without working Flash. I believe that should be a priority of the Debian project to provide a complete free software desktop. And as Gnash is one of the few projects where money will help speed up development, I believe spending Debian money on Gnash is a good idea. Why should Debian not sponsor upstream development for projects that are important to Debian? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Distributing software written by hostile upstream developers
[Steve McIntyre] > There has been some discussion in the last couple of years about > whether or not Debian should distribute software that was written by > developers that we consider to be "hostile". In my opinion, the current recommendation in the developer references is enough for now: If you find that the upstream developers are or become hostile towards Debian or the free software community, you may want to re-consider the need to include the software in Debian. Sometimes the social cost to the Debian community is not worth the benefits the software may bring. If someone really want to maintain such package, we should not prohibit it, but we should make it clear that it is strongly recommended to not maintain such package, and that the advantage of the software should be weighted against the problems it causes for the Debian community. Perhaps we should also suggest that one start working on alternatives for packages with hostile upstream, instead of spending time on social interactions with upstream. :) > I also ended up talking to multiple people at DebConf about this > issue and it was suggested that we should have a proper project > discussion on this front, maybe leading to a GR to properly gauge > the opinion of the project as a whole. I do not believe this warrant a full GR vote. A simple web survey would be enough, in my opinion. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching the default startup method
[Andreas Barth] > Hi Petter, Hi, and sorry for the late reply. With a kid in the house, I have so little free time to spend on Debian, and ended up focusing on trying to fix the issues you brought up instead of spending the time to write a proper reply to you first. > I appreciate that you're working on improving the experience of our > users during startup, e.g. by adding dependency information to the > init scripts. I think that will in the long run be good for Debians > users. Thank you. > For this reason I propose that you undo the dependency, and keep on > maintaining and improving insserv, and convincing people by the good > quality of the package and its usefulness to install it (instead of > forcing it on the people by a hard depends). This migration is done to fix some long standing bugs in the boot system, which has previously been very hard or impossible to fix properly with the API using static sequence numbers provided by update-rc.d. The work to update init.d headers have been going on for around 5 years, and a lot of people have been using this flawlessly for several years. Most scripts have correct or good enough dependency information, and the few ones that do not are buggy and need to be fixed. This is part of the reason the boot system team believe swithcing now was the right thing to do, to ensure that any remaining problems can found and fixed in time for Squeeze. It is time to get rid of the ordering bugs in the boot system, and switch to a mechanism that will give a robust and correct boot and shutdown sequence for the future. As you probably already saw in the boot system announcement[1] the boot system team have been working on, and finally managed to publish this weeked, the migration path has been changed a bit, to make it easier to postpone the migration and move the responsibility of tracking if the migration is done or not to the sysv-rc package were it belong. Earlier, the debconf question was priority medium, while now it is critical. Not changing the debconf priority before changing the default to dependency based boot sequencing was a mistake on my part. Errors blocking migration are now shown using a debconf template, and the wiki documentation[2] have been updated to help out with migration problems. We will follow any reported issues closely, and continue to spend our time on the issues to make this transition as smooth as possible. 1 http://lists.debian.org/debian-devel-announce/2009/09/msg3.html 2 http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: LSB 3.1 status for etch
Is etch now LSB compliant? Is it time to update policy to specify LSB 3.1 instead of 1.3? Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LSB 3.1 status for etch
[Jeff Licquia] > There is now. Bug #381348, with the full scoop and a proposed fix. And a fixed cpio was just uploaded. Time to update policy? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LSB 3.1 status for etch
[Jeff Licquia] > Most of the current tests pass. Of those that don't, most are > recognized deficiencies. In sum, there are two potential issues > with Debian and the LSB: a possible bug in cpio, and an issue with > the libX11 ABI that is common to X.org distributions. If I got this right, we could fix one issue with cpio and claim Debian is compliant with LSB 3.1? I guess now is the time to fix cpio and update policy, then. :) Is there a BTS report describing the problem with cpio? I am not sure what to look for in http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cpio>. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wiki.debian.org: Who's maintaining it
[Jonas Smedegaard] > What more specifically fails with the stable version? I am not sure what details you are missing, but I can try to walk through the features I am looking for, and hopefully you find the info you need. When I visit wiki.skolelinux.de, there is a scroll menu in the part of all pages with "More Actions:", and one of the options there is "Render as Docbook". This allow me to get a XML document with docbook tags representing the wiki page. When I visit wiki.debian.org, there is on each page (right side bar) an scroll menu called "More Actions:", and there I am unable to find any option to generate the docbook version of the page. If the 'Render as Docbook" option was working on wiki.debian.org, I would be able to extract the docbook version and thus use it to generate PDF documents from the wiki. Is this specific enough? Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wiki.debian.org: Who's maintaining it
[Jonas Smedegaard] > Docbook support was included with 1.3.4 too, but you might be right > that it is broken in that release. If so there's a change that it can > be worked around by plugins, fulfilling the requirement of staying with > stable packages. The option seem to be missing from wiki.debian.org. At least I fail to see any way to extract a docbook version of the wiki pages. So I do not know if it is broken as much as it is missing. Perhaps it is just a configure option, and currently disabled? > Perhaps move (this branch of) the discussion to debian-devel? If > doing so then please cc me, as I am not subscribed to that list. I keep it here for now, as I guess it will either die out soon as no actions will be taken to modify wiki.debian.org, or we take it to private mail to work out the details if it is going to be modified. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wiki.debian.org: Who's maintaining it
[Martin Schulze] > The version should stay with the version currently in Debian stable. Any chance of having the version in Debian stable support docbook export? If not, we can not maintain the documents on wiki.debian.org, and need to maintain them on our own wiki. That is a bit sad, as we would like the Debian Edu documents to be available from the official Debian web pages. I managed to figure out the versions if moinmoin. wiki.debian.org uses 1.3.4 while wiki.skolelinux.de with the working docbook export uses 1.5.3-rc2. I'm not sure when the docbook feature was introduced, but it must be somewhere in that version span. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wiki.debian.org: Who's maintaining it
[Jonas Smedegaard] > As the python moin wiki maintainer I welcome this coordinated effort. > > I myself have failed locating the admins of the Debian wiki[1], so is > happy for this clarification :-) Would it be possible to have the moinmoin version on wiki.debian.org upgraded? The current version do not seem to support creating docbook output. I'm not sure which version of MoinMoin includes this feature, but it is present on http://wiki.skolelinux.de/>. Having docbook export make it easy to create Postscript and PDF versions of the pages, and we plan to use it in Debian Edu to produce teacher friendly documentation. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: summer of code: what's next?
[Baruch Even] > Mentors should comment and grade proposals on > http://code.google.com/soc/debian/open.html Right. I guess I should have a look then. Just got 'Invalid user' when I had a peek now. I've already been contacted by a person interested in working on one of my proposed projects, and already gave him some clues on his more detailed project plan. I guess that means the studens are already pouring into SoC. :) Friendly -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: irc.debian.org
[Steve McIntyre] > I can see that more and more of my own Debian IRC discussions are on > oftc, to the extent that I'm (currently) not on any freenode > channels at all. For me it is the other way around. I am currently on one channel on OFTC, while I am on 7 channels on Freenode, 4 of them related to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Summer of Code 2006, should Debian take part?
Google is planning to organize a Summer of Code program this summer as well[1]. They are now accepting application from mentoring organisations, and I believe (as well as others who voiced this idea elsewhere) Debian should take part too. I've started a wiki page[2] to coordinate this. Please fill it with information, as we discuss here if Debian should participate, and what form our participation should have. 1 http://google-code-updates.blogspot.com/2006/04/summer-of-code-2006.html 2 http://wiki.debian.org/SummerOfCode2006 Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
[David Weinehall] > Since all Ubuntu packages are recompiled against a different set of > libraries, the bug might not even affect the Debian package, even though > they share the same source. The same can be said about Debian architectures, when the autobuilder build the packages at different times and with different sequences, leaving the same source package build with different libraries on different archs in Debian. I guess on a good day we might see Ubuntu as another arch for the packages were the same source is used... > Hence having Ubuntu developers triage the bugs to rule out such > issues before they are forwarded to Debian's BTS is always a good > thing; Yes, this is generally a good idea. :) > thus the maintainer field should be changed for *binary packages*. This is probably a good idea, yes. Personally I do not mind being the "maintainer" of binary packages build from unmodified sources in Ubuntu. I'm do not have any problem with being listed as "maintainer" for modified packages either, but would prefer people with ubuntu to do triage before a bug is reported to BTS, to make sure the problem isn't related to the ubuntu environment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on "switching to vim-tiny for standard vi?"
[Gunnar Wolf] > Well, it was also the default behavior for some time with the > pre-Sarge installer - I don't know why it was dropped (in the back of > my head I hear a little voice telling it was buggy or something, but > I've been taught not to listen to those little voices). I'd like to be > part of the standard install (of course, after answering a question, > as many people will not want to be silently reporting their data). It was taken out of the sarge installer when tasksel was modified, because the method used by the installer to include the popularity-contests question no longer was present in tasksel. This feature was not reimplemented in time for the sarge release, but shortly thereafter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Experiment: poll on "switching to vim-tiny for standard vi?"
[Chris Waters] > The problem with this is that popcon tends to be self-selecting for > "fan-boys". People setting up serious servers with Debian are not > going to be installing extraneous software like popcon, and casual > users are unlikely to find it interesting enough to install even if > they happen to notice its existance. I suspect you have not tested the etch installation lately. The popularity-contest question is asked as part of the standard installation path, so it is no-longer just for the few that know about it. I do not know how you define "serious servers", but I know of quite a few servers with popularity-contest installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Complaint about #debian operator
[Paul Johnson] > If they're related to Ubuntu, they're primarily about Ubuntu, don't > ask them in Debian. Debian didn't come from Ubuntu, after all, most > people on Debian don't know or care about Ubuntu problems. This is slightly exaggerated, as several of the problems experienced and solved in Ubuntu are problems also present in Debian. Because of this, I try to keep an eye on the problems and solutions in Ubuntu and other distros. I suspect this is the case for other people as well, and thus do not believe your statement "most people on Debian don't know or care about Ubuntu problems". I'm not sure if your message is improved by your writing style. It appears very aggressive to me, and that lowers my trust in it. You might want to take this into consideration when you compose your future messages. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automated testing - design and interfaces
[Daniel Burrows] > To me, this sounds like the argument that "I don't need seat belts > or air bags because only bad drivers crash and I'm a good driver". Or even better, "using seat belts is showing distrust to the driver". :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intel devices supported on Debian
[Max Alt] > They have also already been submitted upstream ( kernel.org, > alsa.org , x.org) and can be downloaded at intel.com/go/linux. This sounds great. I hope Intel is able to spend the time to get the drivers accepted upstream as well. It would make it so much easier to get the correct drivers. I look forward to seeing these changes in Debian. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status update from Create Commons workgroup?
[Andrew Suffield] > I thought that had been sent back to them some time ago... we've seen > a draft that's probably okay except for a few details that are kinda > uncertain and some wording that's just plain weird. Right. Perhaps there is some confusion somewhere, as Mr. Lessig did not know about a reply when I spoke with him 2005-10-21. > I don't see any reason why it won't get fixed and turn into the > basis for the next versions of the CC licenses, but AFAIK we're > waiting on CC right now. Sounds good. I hope a solution can be found. > That's Evan's problem though, go ask him. I just read licenses. Right. Cc to him, in case he does not read -project, to bring this thread to his attention. I hope I picked the right Evan. :) >> If we knew which of the two suggestions "did not have the effect >> intended" (and why), we could come up with plenty of alternate suggestions. > > Bad explanation on our side, or misunderstanding on theirs. I > believe these have all been cleared up now. Even better. I really look forward to see the positive outcome of this discussion. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status update from Create Commons workgroup?
[Nathanael Nerode] > If we knew which of the two suggestions "did not have the effect > intended" (and why), we could come up with plenty of alternate > suggestions. In addition, a few of our suggestions were of the > "this is way too confusing to read" variety rather than the "this is > non-free" variety, and if they didn't take those, that's just fine. Well, if I understood him correctly, he had send feedback to Debian and was waiting for a reply. Not sure who he sent it too, but it would be nice if someone on "our" side knew the status. I'm not sure who actually ended up in the Debian workgroup on this topic, but hope the DPL team have a clue. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Status update from Create Commons workgroup?
What is the current status of the work going on to try to make some of the Creative Commons licenses acceptable according to the Debian free software guidelines? I know there were a workgroup being formed in March, and I hope they are doing good work. I spoke with Lawrence Lessig yesterday, asking him for updates and if he believed it would be possible to get the licenses acceptable by Debian. He said he had not heard news on the topic for half a year, and that he was waiting for feedback from Debian. He said that the suggested changes had been accepted except two suggestions, which he claimed did not have the effect intended. So, what is the experience on Debians part? Are we getting closer to a solution? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Approaching VMware (and others) to get Debian listed as supported ?
[Yann Dirson] > Debian is not listed in the list of supported OS on the VMware > website[1]. We all know here there is no reason for it not to work, > especially given the huge number of other distros listed there, but > in the corporate environment, yada, yada. Actually, it is not that straight forward to get a host OS working properly in VMWare. For example, RHEL 4 failed to work properly for a while. The clock was not going with the correct rate. I believe this is fixed in WMware now. :) So there is some work and testing needed on the kernel (or WMware) side to get VMware working with debian. Not sure what the status for woody, sarge and etch is at the moment. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Naming of init.d scripts and the LSB
[Steve Langasek] > The goal of the LSB is to provide a standard that ISVs can write to > -- *not* to make life easier for admins moving from distro to > distro. Hm, that is sad. Because some of us with a large number of machines, do need to handle cross-distribution consistency. Not to move from distro to distro, but because a few hundred machines rune each of the distros. :) I hope someone try to make life easier for admins needing to administrate a lot of machines with different distros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Naming of init.d scripts and the LSB (Was: Delegation for trademark negotiatons with the DCCA)
[Steve Langasek] > Debian packages shouldn't have to compete with the LSB for its own > namespace. Well, assuming that it is a good thing to have cross-distribution consistency, because this make users more comfortable with moving to Linux from their current platform, I believe it would be a good thing to also have consistent naming of init.d script across linux distributions too. We do not consider it to compete with POSIX to follow the specifications and APIs provided by that standard, and most of us realize that it is an advantage for all distributions that the functions behave the same across distributions. We do not consider the libc API to be Debians namespace. The same way, system administration tools, documentation and other administration-related systems will be easier to handle for users and system administrators if all Linux distribution have consistent naming for init.d scripts. I fail to see the advantage of reserving this as a Debian namespace and consider the LSB as something we do not want to use to create consistency across distributions in this area. Time to rename the thread. Please strop the 'Was'-part when replying. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting LSB 3.0 support into Debian (Was: Delegation for trademark negotiatons with the DCCA)
[Horms] > "Stealing" them might be easier than you think, I beleive that most > of the LSB work being done for DCCA is being done by Jeff Licquia of > progeny, who is also working on the Debian LSB effort. Oh, have no doubt, I do not consider it hard to steal this back. I know Jeff personally as a skilled and understanding debian developer, though way to overworked for his own good, so I believe he is doing his best to push things back in the limited time he got available for it. Because of this, I believe we should not wait for anyone else to find time to move these changes back to debian, but instead go out, each and every one of us, and pick the good pieces from the net and integrate them back into debian. :) I'll do it for my packages. I hope the rest of you do it for yours. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Getting LSB 3.0 support into Debian (Was: Delegation for trademark negotiatons with the DCCA)
[Sven Mueller] > They announced that the DCC Alliance will support LSB 3.0. However, > every press item I saw on this matter reported that _Debian_ > supports LSB 3.0 (which isn't officially announced yet, as far as I > know). Getting LSB 3.0 support in Debian sounds like a great idea. Lets make it happen, by stealing the patches from this DCC resistance, or accept the patches they probably supply into BTS. :) (Yes, I intentionally ignore the trademark issue, as several good people seem to work on that task already. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Software Packages in "stable" - [security]
[Joe Smith] > I doubt you will forget Microsoft (the enemy). You will just much > prefer Debian, or so we hope. Microsoft is not the enemy. Microsoft is mostly irrelevant, and a slowly dying dinosaur. Trying to fight Microsoft will mostly be a waste of time. At least I fight for free software, not against non-free software. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Popularity contest
[Henning Makholm] > No. Why not? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pledge To Killfile Andrew Suffield
[Andrew Suffield] > On Sun, Aug 14, 2005 at 09:28:26PM +1000, Hamish Moffatt wrote: >> Fortunately nobody needs to justify their decision to killfile >> you to anyone but themselves. Or even a decision for a group to >> collectively killfile you. > > So what you're saying is that mob rule is acceptable to you. > > I think that's pretty sickening really. You'll probably get exactly > what you want. No, that is not what he is saying. I am sure you understand it too. He said that each individual reader can choose to ignore your postings, and there is nothing anyone else can do to force people to read messages they do not care to read. If you or anyone else were to succeed in forcing people to read your postings, we would all have to live in a totalitarian state which controlled each reading patterns. Most of us are not living in such controlled environment, so there is no way to control our reading. The fact that you believe your own misinterpretation of the words from Hamish Moffatt to be sickening, tells more about yourself then about anything else. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pledge To Killfile a person
[Andrew Suffield] > I acknowledge that I occasionally write mails which can be sharp and > pointy, but generally it's just in response to similarly sharp > mails. It's hardly uncommon in Debian; Perhaps not, but is it smart to send such messages, and is it the kind of messages you want to be remembered by? I suspect we would reduce the conflict level and increase productivity if there were less such messages. Replying with strong language to a message with strong language tend to just escalate the conflict, and in my experience rarely end in a constructive way. > I've made a quick review of my sent mail in the past few months, and > the mail I've seen on the lists in that time frame, and I don't > think my percentage is any worse than anybody else (and it's better > than many). Neither is the number of large threads I've spawned (I > found two, and I went back two years). The only difference is that > other people don't have rumours being spread about them. Perhaps others are better, perhaps others are worse. One question you could ask yourself is if you want to be a person increasing the percentage of "sharp mails" as you put it, or a person decreasing that same percentage. For myself, I try to bring that percentage down. And I tend to find the messages and meaning of people without strong and abusive language more relevant and interesting, and I value those peoples meaning higher than I value others. If you want your intentions, meanings and messages to be read and understood by as many as possible, it might be an idea to rephrase them using less strong language. If you do not really care about how many read and understand your messages, continue as you are. :) Removed your name from the subject. I believe it is a bad idea to have names in subjects, as the name linger on while the topic being discussed tend to drift far away from the original topic. -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ping the mirrors team
[Martin F Krafft] > I am not sure this is such a good idea for privacy reasons. If I > mail mirrors@, I am not warned that my message will be publicly > readable. You actually thought correspondence with a free software project would be non-public? I find that rather unusual. I would say that unless explicitly told otherwise, the correspondence with the project addresses should be expected to be public, and see no problem in sending the mirrors@ address into a publicly available forum. It might be wise to mask the mail addresses to make it a bit harder to harvest them, but that is another issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why isn't queue/new world-readable?
[Joe Smith] > Also, Based on another message I read (on this very list IIRC) > Debian is used by the government as an example of the propper way to > export open source cryptographic software. If this is correct that > is a nearly fail-safe defence against any possible claims. Therefore > I reccomend making zero changes without consulting with both a > lawyer and a represxentive of both the BXA and NSA. It is possible to assist with the packages in the new queue if the packages are available from somewhere else (normally the case), and this location is listed in the wnpp request. If this is the case, people wanting to help out can visit http://qa.debian.org/~anibal/debian-NEW-summary.html> or http://ftp-master.debian.org/new.html>, click on the bug number to visit the WNPP request, and review the package in question for packaging problems. The review information can be sent to the prospective maintainer and the WNPP request, and hopefully problems will be fixed before the ftpmasters need to look at the package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Utnubu Team Founded - Merging Ubuntu changes to Debian
[Goswin von Brederlow] > If anyone is intrested in adapting this drop me a note. Please provide URL and repository for this source? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Utnubu Team Founded - Merging Ubuntu changes to Debian
[Joachim Breitner] > I invite everyone interested to join the Utnubu Team. Utnubu stands > for doing what Ubuntu does, just the other way around: We want to > take the things Ubuntu does and that are missing in Debian, and - > where appliciable - put them in Debian. Great effort. There are already some effort to make it easier to track changes between distributions. I hope these tools will make it easier for you in the future to track the changes done by Ubuntu and others. Some of these efforts are being done within the debian-custom community. You probably want to participate in that mailing list as well as the Utnubu lists. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bad press related to (missing) Debian security
[Martin F Krafft] >> There should be a larger team which monitors security lists, fixes >> bugs, helps maintainers to fix bugs etc. > > There is a problem with that, namely responsible disclosure. The > team cannot be too big or else the other organisations in the > consortium will object for danger of leakage. > > I think what we do need though is an infrastructure which makes it > easier for people to contribute on public issues. There already exist a larger team monitoring security lists, CVE reports, fixing bugs and helping maintainers fixing bugs etc. It works in public, and accept help for everyone interested in participating. It is the testing security team, http://secure-testing.alioth.debian.org/>. I believe that all people interested in helping out with the security work in Debian should make an effort in this team. This will directly help the security status of Debian unstable and testing (security fixes for testing are normally uploaded into unstable), and indirectly help the stable security team as this team get a list of security issues to track, proposed patches, knowledge about the security issues discovered, and thus less work fixing the publicly known security issues. In addition, it can form a good recruitment base for the stable security team. Those proving themselves in the public work with testing security, will be good candidates for the stable security team. Isn't this a good way to do it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Branden's mail policies
[Adam McKenna] > It is fine for individual developers to act like antisocial fuckwits. Sure. Just carry on the way you are. :) > It is not acceptable for our DPL to behave that way (not when acting > in his role as DPL, anyway). Good thing he isn't behaving like that. He is not the one rejecting non-spam emails, remember. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SPONSORSHIP
[Edwin Muzofa] > I would humbly request for your help in terms of sponsership for our > computer club to venture into different projects aimed at raising > awareness of Information Technology in our society. iwill be very > greatful if im considered. What kind of help do you need? Your request is very generic, so it is hard to know if the Debian project or its members can help you or not. Please keep Friendly, -- Petter Reinholdtsen Random Debian Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Discussion of bug #311683, default kde install shows porn
[Sven Luther] > I doubt that very many redhat entreprise users install it at home or > schools though. I don't. :) Here at the University, we have a license for home users as well. But if it is so in RHEL, I am pretty sure it is so in Fedora as well. And perhaps you can believe that Fedora is installed at home or in schools? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Discussion of bug #311683, default kde install shows porn
It might be interesting for you to know that this screensaver in question is enabled by the random kde screensaver in RedHat Enterprise Linux too. I haven't seen any outcries against redhat because of it, and thus suspect the danger of bad press appearing because of this to be very limited. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL freedoms
[Nathanael Nerode] > Suppose the GCC manual was not licensed for use in essays on the > economics of free software. (It actually provides some great > examples of funding methods, and quoting some of the sections on > various features to go with the information on how they were funded > would be quite useful.) Wham, we lose freedom. Oh, wait -- it isn't > licensed for such use. As far as I know, quoting is covered within the fair use rights, and do not have to be covered by the license to be allowed. It is covered by law. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new queue process tweaks
[Manoj Srivastava] > Ah, if you stipulate that the secretary has the judgement to figure > out what is a "real request" as opposed to junk, I have no > objections. I do. :) If the secretary can't separate those two, the secretary need some education on how to do it, or to be replaced. It should be a core skill of a secretary. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new queue process tweaks
[Manoj Srivastava] > A number of message sent to the secretary are discarded without > comment. Does the project really want the secretary to be responding > viagra ads? Were did you get that idea? You must have read something out of my text that was never intended. Even the Norwegian government responds to non-directed advertisements. I've never heard the government report any problems separating the real requests from junk mail. Do you expect the secretary of Debian having problems separating the two? Personally, I trust the secretary to be able to separate junk mail from real requests. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new queue process tweaks
[Anand Kumria]
> Similiarly it would be nice if the Debian project decided to be more
> Morton-like, that is explicit acceptance or explicit rejection,
> rather than Linus-like (implied rejection) in its handling of
> things.
I agree when it comes to the correspondence with the official
positions in Debian, and not only the ftp-masters. The person sending
a request to an official position in Debian, the DPL, the tech
committee, the secretary etc, desert an answer within a reasonable
time frame. Even if the answer is short and undecided, it will at
least verify that the message was received. In Norway, the law
require all government offices to reply within a reasonable time,
normally interpreted to mean within a month.
And the answer do not have to include much information. An fun
example from a nice book with various correspondence with people in
official positions ("Til Saken! 2" by Jomar Engebretsen) include this
complete answer from the royal court: "H. M. The King has ordered me
to confirm the arrival of your letter dated May 30th". The letter in
question proposed to run an election for the next king, to allow the
Prince off the hook as he didn't seem too happy about his future
task. :)
> To me, making the committment that a package is decided upon after X
> weeks (I'm suggesting 8), if there is no outcome pending it be
> referred
As I said, in Norway the government is required to give feedback
within a month. I believe this is a good requirement for the
government to have, and suspect it would do Debian good too.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disbursement approvals and email privacy
[Martin Schulze] > I don't think that the amount of reimbursed money needs to be put in > public and that -private would have been a better place instead. In debian-edu, we have a good experience with making the economical status public, to allow all project members to keep an eye on the current income and spending of funds. It is available from http://www.linuxiskolen.no/okonomi/> for those reading Norwegian, I the software is available for all those who want it. I recommend SPI do something similar. But we do not publish the names of those receiving reimbursement due to privacy concerns. We might have gotten away with it, but someone decided it was not worth the effort. For those details, one can ask. In addition, there are always to people involved in approving expenses, the leader of the member organization and the treasurer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free but distributable packages and kernel firmware
[Sven Luther] > My image of this would be for the debian-installer to recognize that > a given piece of hardware needs a driver module that is in > non-free-but-freely-distributable, Assuming such modules are distributed as debian packages, I believe discover v2 can make such information easily available (information like this HW work better when this package is installed). Perhaps it is the good place to keep such information? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debconf5 IRC meeting minutes
[Lars Wirzenius] > http://wiki.debian.net/?Debconf5Meeting20050404 Hi I saw this entry in the summary: > Status of audiovisual recordings of talks and networking (h01ger): > We need firewire video cameras with tripods, lockable server room, > physical network layouts, locations for switches, wireless network > layout, servers with firewire for recording and streaming, file > server for user directories, cpu servers, general servers, at least > one printer, fat router, firewall, and probably other stuff. Holger > will discuss with mooch and liiwi. For the video recording, do remember post-processing. In Oslo, we tried to do video recording, but when the recordings were done, no-one had thought about the need for post-processing, and the tapes just ended up on my desk. They are still there. :) Also, the audio recording level is important. Part of the problem with the tapes from Oslo was that the audio level was too low, so they would require a lot of work to make sensible video films from them. (Hm, not sure if this is the correct list to send it to, but will take my chance. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Small teams and other platform positions...
[Martin Schulze] > How to you fund the time people need to travel to and stay at the > meetings? Until now, we haven't. As I said, those already investing lots of time into Debian tend to get their travel and lodging expenses covered to join the meetings in questions. Experience have shown that at least some of these are able to re-prioritize their time to be able to join these meetings. I'm aware that some people want/need to have their lost work-time funded as well. Those unable or unwilling to spend holiday or talking days/hours off in exchange for working overtime do have a problem joining such meetings. But at least in my head it is a question of priorities. As far as I know, most of us joining the d-i devcamp spent our holiday to go there. Those of us going to the debian-edu devcamp coming up in Greece or the CDD devcamp in Spain do the same. So I offer my holidays and time, and get the travel and lodging funded in return. I do not believe this is such a bad bargin. :) > Given the answers (and non-answers) to replies of the Vancouver > prospectus, I wonder if some people have not simply decided > otherwise. I was unable to read all the thousands of email flooding in after the proposal, so I'm not really sure what you are referring to here. But I do not believe anything is set in stone yet. I'm glad to see the positive results from the meeting; a revitalisation of the ftpmaster team and better coordination between the ftpmasters and the release team with regard to the upcoming Sarge release. With that background, I do not see the point of writing so much about the thoughts presented for the Etch release. I see it as a tactical blunder to post both these points in the same email, as the latter took the focus away from the former. And in hindsight, I also believe it would have been better to write down more of the thoughts behind the Etch proposal and make it easier to understand that the text was a proposal to solve the release problems as seen by the release team and the ftp-mastesr, not the only solution. [Btw, it has been brought to my attention that several people believe I am paid by debian-edu to work on Debian. This is not the case. I've been working full time at the University of Oslo since 2001, doing Debian work in my spare time. This is about to change, as I will be working 40% for Skolelinux from April 1th. Debian Edu have only two Debian developers working full time on Debian Edu and Debian stuff: Joey Hess and Andreas Schuldei. (And two others working on political stuff here in Norway. :)] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Small teams and other platform positions...
[Vaidhyanathan Mayilrangam Gopalan] > If we do, then we are essentially saying that only those developers > who are rich enough (in terms of money, time , ability ) to travel > are only ones who are worthy of contributing. It has got nothing to > do with the amount of work they are putting into Debian. This is not really the case. Those spending lots and lots of time and doing lots and lots of work on Debian related activities, do tend to get their travel funded to go to such meetings. The two debian-installer devcamps was funded by Debian Edu. Several of the central people in Debian got their travel to the 2003 and 2004 devcamp/debconf funded by HP, Lindows, Canonical and others. The ftpmaster/release team gathering was funded by Debian Edu. The Custom Debian Distro workshop in Spain will be funded by some Spanish government agency. And these physical meetings have proven effective both as a way to speed up the progress in Debian, and to grease the interaction on-line after the meetings. No-one has proposed to replace all the on-line interaction (email, IRC, etc) with physical meetings. We are talking about giving the existing teams, with the currently active members, an opportunity to meet and talk and coordinate and come up with new ideas, not to exclude everyone else, but as a way to speed up progress. I've been to a few such meetings, and everyone there have been very clear on the need to keep the rest of Debian involved. That is the reason the summaries keep flowing from these meeting, bug reports are created to organize the ideas, design proposals are written and posted on the mailing lists, and the people at these meetings keep hanging out on IRC, reporting what is happening to those unable to join. So I not believe the danger is really present, as all those heavily involved in Debian are aware of the importance of keeping the development process open to all the capable people in the Debian community. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
