Re: unmets in potato
On Tue, Mar 14, 2000 at 10:34:54PM +0100, Matthias Berse wrote: > On Tue, Mar 14, 2000 at 03:16:56PM +0100, Martin Waitz wrote: > > compile devicd3dfx-source and you are done :) > Am I the only one where make-kpkg modules-image fails on devicd3dfx? I > have to do it manually! But maybe that's related to my non debian > 2.2.14 Kernel??? Did you use make-kpkg (in package kernel-package) to build your kernel? If not, you should. After building a kernel-image, you should then be able to build modules-image and have a kernel and device3dfx-module package you can install.
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 05:27:26PM -0500, Ben Collins wrote: > Well, it's really sad that you like to dredge up year old context for > this thread to suit your mundane arguments, they have little context > with what I was saying. actually, it's really sad that you haven't learnt that closing down 'unstable' is a disastrously bad idea. you've been with debian long enough now to have learnt that. > > you miss two important points. the first is that the release is > > not everyone's highest priority. the second is that some people > > have nothing to contribute to frozen/stable, so discouraging (or > > preventing) them from working on unstable is counterproductive. > > Once can argue that the reason is because they don't know how they can > help. one could argue that, but one would be wrong. > Everyone within Debian has a stake in frozen, simply by being a > member, and every can help. There is nothing preventing that. sure, everyone can help (but that doesn't necessarily mean that the freeze/release process will go faster...in fact, for some tasks it is guaranteed to slow it down). however, there is no reason to require everyone to help or even to care very much about frozen/stable. > > both of these points are proved by the fact that we have over 500 > > developers yet, according to your own words, "we are short on needed > > resources for getting potato release ready". if everyone, or the > > majority...or even a substantial minority, had your priorities then that > > would not be the case. > > First of all, you need to check your numbers. Last I checked there were > ~350 official developers in the keyring. last i checked we were approaching 500. irrelevant, anyway. 350 or 500, it's still more than enough to prove my point. > Right, so this proves my point in that we should encourage developers > to put a priority on frozen and the next release cycle. no, it doesn't prove it at all. adding many more people to the task of getting the stable release out the door will not speed it up - if anything, it will slow it down. > And please stop refering to stable. That is not my main concern here, > and I never brought it into this conversation. do you have some kind of comprehension problem with the english language? my references to the 'stable release' are obviously referring to the work that needs to be done to get potato released. > > in any case, simply adding more people to the project won't make > > it happen any faster. what WILL make it faster is to fork off the > > stable release as a sub-project of debian, and give the release team > > absolute authority over the release, with the right to make NMUs of > > any package and make any other changes for any reason they see fit. > > as with any other debian initiative, any developer (or user) would > > be free to work on it or not as they please. > > How would that help? That is simply a superficial thing. > > Calling it a "seperate project" would do nothing to improve the > situation. it is far from superficial. co-ordinating the activities of a small group of 10-30 (estimated) people is a lot easier and a lot more efficient than co-ordinating the activities of 300 or 500 people. by "forking" the release as a sub-project, and granting complete authority and responsibility to those who give enough of a damn to join the release team, you can minimise the delays and interruptions caused by the vast majority of developers who work on unstable yet have little or nothing to contribute to the release process. > Plus that creates havoc with changes made to the frozen release that > aren't in unstable. So we get split bug reports and a lot of other > crazy things. that's something for the release team to worry about - after all, they're the ones who are going to face the problems caused when it comes time to do the next freeze/release. i.e. there will be an inherent sanity-check on their changes, caused by their desire to make future versions as easy to produce as possible. > > also, the issue is not "man-power", the issue is "man-hours" - i.e. > > how much time any of the people doing the important jobs can devote to > > debian. most of them have full-time jobs or are full-time students and > > are working on debian in their spare time. the really imporant tasks > > can't be sped up by some kind of time-sharing arrangement. > > Ok, let's play word games. "Man-hours" is a direct result of "man-power". no it is not. more precisely, the relationship is nowhere near as simple as what you are trying to make out. does it just suit your argument to play dumb or what? the following should be elementary knowledge, especially to anyone in the computer industry (who should have at least superficial knowledge of the ideas in the _The Mythical Man Month_ by Frederick Brooks), but you appear to need to have it pointed out: having 10 times as many people does not mean you get 10 times as much work done or even the same job done in 1/10th the time. e.g. if
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 11:50:05PM +0100, Josip Rodin wrote: > > > Uh, which were the packages in question? Did you report it at the > > > time? > > > > no need, the holes were already well known - and fixed in unstable. > > Security fixes have to be (and are) fixed in stable, too! most are. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 05:43:38PM -0500, Michael Stone wrote: > On Tue, Mar 14, 2000 at 05:27:26PM -0500, Ben Collins wrote: > > > it doesn't distract me at all. i mostly ignore it these days as it is of > > > little or no relevance to me. > > > > Safe to say, that is a really self-centered attitude. One which I hope > > that most developers don't have. Not a very team oriented situation if > > everyone felt that way. > > OTOH (to play devil's advocate) the stable process seems to continually > get bogged down. Slipping deadlines, inappropriate package upgrades, > etc., begin to make things seem hopeless. When push comes to shove, > things usually get done--but what's the push right now? good to see that someone sees my point (although it's not solely my point - it has been made several times by many others over the years). amongst numerous other benefits, snapshot CDs will take the pressure off the release team and allow them to take as much time as they feel is necessary to produce the 'perfect' release. craig -- craig sanders
ITP: bdfresize
Hello. I intent to package bdfresize. ftp://ftp.cs.titech.ac.jp/pub/X11/contrib/Local/bdfresize-1.4.tar.Z> bdfresize - Resize BDF Format Font Bdfresize is a command to magnify or reduce fonts which are described with the standard BDF format. /* * Copyright 1988, 1992 Hiroto Kagotani * * All Rights Reserved * * Permission to use, copy, modify, and distribute this software and its * documentation for any purpose and without fee is hereby granted, * provided that the above copyright notice appear in all copies and that * both that copyright notice and this permission notice appear in * supporting documentation, and that the name of Hiroto Kagotani not be * used in advertising or publicity pertaining to distribution of the * software without specific, written prior permission. * * * HIROTO KAGOTANI DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO * EVENT SHALL HIROTO KAGOTANI BE LIABLE FOR ANY SPECIAL, INDIRECT OR * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF * USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR * OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR * PERFORMANCE OF THIS SOFTWARE. * * Author: * Hiroto Kagotani * Dept. of Computer Science * Tokyo Institute of Technology * 2-12-2 Ookayama, Meguro-ku Tokyo 152 Japan * [EMAIL PROTECTED] */ Regards. -- Takuo KITAME / [EMAIL PROTECTED] - It was a dark and stormy night... -
Re: realplayer installer and frozen
Lars Wirzenius wrote: > I agree with Branden: remove the installer from potato. The problem that I forgot to mention is that anyone who upgrades from slink to potato w/o upgrading realplayer, and had realplayer installed via the installer in slink, is going to find that the old realplayer they have installed realplayer no longer works. Library incompatabilities of some kind cause it to crash. -- see shy jo
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On 14-Mar-00, 18:58 (CST), Craig Sanders <[EMAIL PROTECTED]> wrote: > actually, it's really sad that you haven't learnt that closing down > 'unstable' is a disastrously bad idea. you've been with debian long > enough now to have learnt that. How do you know? We've never tried it. You and others say it would be a disaster. I and others think it would help. Proof by assertion isn't. > However, there is no reason to require everyone to help or even to > care very much about frozen/stable. Except that it is part of what Debian does. Joining the org implies at least some interest in the goals. If you disagree with the goals, lobby to change them. > by "forking" the release as a sub-project, and granting complete > authority and responsibility to those who give enough of a damn to join > the release team, you can minimise the delays and interruptions caused > by the vast majority of developers who work on unstable yet have little > or nothing to contribute to the release process. Why do you continue to insist that they can't contribute? They can test installs, they can fix bugs, they can improve docs. > that's something for the release team to worry about - after all, > they're the ones who are going to face the problems caused when it comes > time to do the next freeze/release. Yeah, this release team should take on all responsibility for all the other peoples packages. Beautiful. Never mind that the next freeze, those problems *still* exist because the maintainer of the package doesn't need to care about fixing bugs or following policy; after all, it's "something for the release team to worry about". > > > also, the issue is not "man-power", the issue is "man-hours" - i.e. > > the following should be elementary knowledge, especially to anyone in > the computer industry (who should have at least superficial knowledge of > the ideas in the _The Mythical Man Month_ by Frederick Brooks), but you > appear to need to have it pointed out: > > having 10 times as many people does not mean you get 10 times as much > work done or even the same job done in 1/10th the time. e.g. if 1 person > can dig a hole in 10 minutes, having 10 people work on it does not mean > that you can dig the same hole in 1 minute. in fact, most likely that > same hole will take at least 20 or 30 minutes due to the hassle of > organising everyone and, even worse, everyone getting in each other's > way and interfering with their work. Apparently you need to go back and read MMM again, and tCatB as well: you missed the point that the reason that productivity does not vary linearly with people has to do with how easily the tasks are done in parrallel. 10 people *can* dig 10 holes 10 times as fast as 1 person. And what computing task *is* well done in parallel? Testing and debugging. That's why the whole Bizzaar methodology works! > so how many people can work on the one problem (say, the boot-floppies) > at the same time? it *might* go faster if there were 2 or 3 people > working on it rather than just one, but it would *certainly* go a lot > slower if there were 20 or 30 or 300 people working on it. It would go a hell of lot faster if 30 or 300 people would test the damn things and report problems with their various hardware configurations, and the choices/options they used in their particular install situation. But no, you'd rather they uploaded yet another clock tool. > what i said was that i want to see the real debian (aka "unstable") > become more accesible to the majority of our users. the way to do this > is by making regular snapshot releases. There is nothing stopping anyone from making snapshot releases of unstable. Mirror the archive. Burn a CD. Done. That's what a snapshot is. God forbid you make the snapshot on a day that perl is broken, of course. Or dpkg. Or glibc. Damn unreliable Debian PoS. I think you have a very narrow idea of what "most users" want. > this capability has been touted as one of the advantages of the > package pools ideas every time it has come up over the last few years. That's right, it has. If it's so important, why haven't people (you!) gotten off your ass and done something about it? If you want to work on the unstable stuff, I think the package-pool implementation would good place to start. > your proposal, quite frankly, stinks. your position is that if people > won't or can't work on what YOU consider to be important then you > don't want them to work on anything at all...they should just twiddle > their thumbs and wait for 'stable' to be released before they are > allowed to contribute anything. Your attitude, quite frankly, stinks. Your position is that that once you've uploaded a package, you have nothing else to contribute to the project. Instead, other people should babysit your packages to make them work with the rest of the system. Debian is supposed to be a team, a group of people working to create something good and valuable. If we're not going to be that, we might as wel
Re: WANPIPE X.25
> Is there anybody here using the Sangoma WANPIPE cards to do X.25? I'm doing exactly that.
Debian Weekly News - March 14th, 2000
-- Debian Weekly News http://www.debian.org/News/weekly/current/issue/ Debian Weekly News - March 14th, 2000 -- Welcome to Debian Weekly News, a newsletter for the Debian developer community. Another Bug Horizon has been set for March 27th. [8]115 packages are in danger of being removed and once again some very important packages are among them. Richard Braakman also [9]mentioned that he hopes to start the first test cycle "right after that date", and only important bugfixes are now allowed into frozen. Debian 2.1 has been out for a year as of this week. The new-maintainer process is beginning to reopen. Dale Scheetz [10]posted a call for sponsors of prospective new maintainers to submit them to the application process. This will be used to test the identification process. Deja vu: Important new releases of [11]X, the kernel, and apache are out or looming on the horizon, and Debian is in the middle of a freeze. What to do? Mainly [12]discuss the same issues we did last time: package pools, changing release frequency, updates to stable, etc. Debian GNU/Linux For Dummies is due in May, according to [13]this web page. With [14]7 Debian books already in print, in 3 languages, it's clear we've reached the point where another Debian book is no big deal. It's more interesting to consider how a "Dummies" book with Debian on the cover may change our userbase.. Debian Project Leader elections [15]close on the 16th. Note that DWN incorrectly reported they would close last week; the date on the ballots was wrong. If you still haven't voted, a few days remain. A security fix for mtr is [16]available. New packages in Debian this week include the following and [17]6 more: * [18]netscape-base-472: 4.72 base support for netscape * [19]netscape-smotif-472: This installs a standard set of netscape programs * [20]netscape-smotif-472-libc5: This installs a standard set of netscape programs (libc5 version) * [21]netscape-java-472: Netscape Java support for version 4.72 * [22]communicator-base-472: Communicator base support for version 4.72 ([23]help, [24]static motif bin, [25]static motif bin (libc5), [26]spell-check) * [27]navigator-base-472: Navigator base support for version 4.72 ([28]help, [29]static motif bin, [30]static motif bin (libc5)) _ References 8. http://master.debian.org/www-master/debian.org/Lists-Archives/debian-devel-announce-0003/msg00015.html 9. http://master.debian.org/www-master/debian.org/Lists-Archives/debian-devel-announce-0003/msg00014.html 10. http://master.debian.org/www-master/debian.org/Lists-Archives/debian-devel-announce-0003/msg00013.html 11. http://master.debian.org/www-master/debian.org/Lists-Archives/debian-devel-0003/msg00534.html 12. http://master.debian.org/www-master/debian.org/Lists-Archives/debian-devel-0003/msg00495.html 13. http://www.buy.com/books/product.asp?sku=30576349 14. http://master.debian.org/www-master/debian.org/distrib/books 15. http://master.debian.org/www-master/debian.org/Lists-Archives/debian-devel-announce-0003/msg00011.html 16. http://master.debian.org/www-master/debian.org/security/2000/2309 17. http://master.debian.org/~tausq/newpkgs-2313.html 18. http://master.debian.org/www-master/debian.org/Packages/unstable/web/netscape-base-472.html 19. http://master.debian.org/www-master/debian.org/Packages/unstable/web/netscape-smotif-472.html 20. http://master.debian.org/www-master/debian.org/Packages/unstable/web/netscape-smotif-472-libc5.html 21. http://master.debian.org/www-master/debian.org/Packages/unstable/web/netscape-java-472.html 22. http://master.debian.org/www-master/debian.org/Packages/unstable/web/communicator-base-472.html 23. http://master.debian.org/www-master/debian.org/Packages/unstable/web/communicator-nethelp-472.html 24. http://master.debian.org/www-master/debian.org/Packages/unstable/web/communicator-smotif-472.html 25. http://master.debian.org/www-master/debian.org/Packages/unstable/web/communicator-smotif-472-libc5.html 26. http://master.debian.org/www-master/debian.org/Packages/unstable/web/communicator-spellchk-472.html 27. http://master.debian.org/www-master/debian.org/Packages/unstable/web/navigator-base-472.html 28. http://master.debian.org/www-master/debian.org/Packages/unstable/web/navigator-nethelp-472.html 29. http://master.debian.org/www-master/debian.org/Packages/unstable/web/navigator-smotif-472.html 30. http://master.debian.org/www-master/debian.org/Packages/unstable/web/navigator-smotif-472-libc5.html -- see shy jo
Using Debian's make-kpkg to build kernels
The Philadelphia Area Debian Society (PADS) (http://www.CJFearnley.com/pads/) presents Using Debian's make-kpkg to build kernels When: Wednesday 15 March 2000, 8:00 PM - 9:30 PM Speaker: Chris Fearnley, Chief Technology Officer, LinuxForce Inc. Where: IQ Group, 6th floor (its the room with a big Q on the door) 325 Chestnut Street Philadelphia, PA Abstract Debian's kernel-package package provides make-kpkg to help build kernels. We will discuss the advantages and some guidelines for using this convenient tool. Social Dinner Attendees are invited to gather for dinner prior to the meeting at 6:30 PM at Xando, 325 Chestnut Street, Philadelphia, PA. Please RSVP so we can get an appropriate sized table. -- Christopher J. Fearnley | LinuxForce Inc. [EMAIL PROTECTED] | Chief Technology Officer http://www.LinuxForce.net | Design Science Revolutionary "Dare to be Naïve" -- Bucky Fuller
Re: realplayer installer and frozen
On Tue, Mar 14, 2000 at 07:09:31PM -0800, Joey Hess wrote:
> Lars Wirzenius wrote:
> > I agree with Branden: remove the installer from potato.
>
> The problem that I forgot to mention is that anyone who upgrades from slink
> to potato w/o upgrading realplayer, and had realplayer installed via the
> installer in slink, is going to find that the old realplayer they have
> installed realplayer no longer works. Library incompatabilities of some
> kind cause it to crash.
I would definitely put new realplayer installer package in potato.
At least this would be a big favor to our users.
Thanks,
Alex Y.
--
_
_( )_
( (o___ +---+
| _ 7 |Alexander Yukhimets|
\(")| http://pages.nyu.edu/~aqy6633/ |
/ \ \ +---+
Re: Debian and GNOME, partnership with Helixcode?
[redirected to debian-devel] On Wed, 15 Mar 2000, Fabien Ninoles wrote: > On Tue, Mar 14, 2000 at 06:29:06PM -0500, Jaldhar H. Vyas wrote: > > The KDE packages in CVS contain Debian directories. They are not always > > perfect but allow anyone tracking KDE development to build packages. So > > for me it doesn't matter that KDE snapshots aren't available directly from > > Debian. I can make my own. > > No, that's clearly not enough! > Packaging for a distribution is not as simple as it seems. > I always prefer to keep the debian directory separate from > the original package, which permits me to make debian revisions > without affecting the release cycle of the program itself. The great thing about all our stuff being in a seperate directory is that non-Debian users need not be concerned about it. It's just a little extra baggage in the tarball for them. I don't see why the functionality or non-functionality of the Debian directory would affect them at all. For Debian users synching the upstream and Debian releases is more important. But remember Debian, KDE, and GNOME are all public projects. You can belong to and contribute to more than one if you like. A single person can speak out about Debian issues during the Gnome/KDE release cycles and Gnome issues during the Debian release cycle. > Also, > as Jason pointed out, having the debian tree is not enough to > for a source to be considered a debian package; Yes but it's a big start. Many times we find Debian packages that are not perfect in their initial release. It's only after several bug reports/release that they reach "Debian quality." They usually do this pretty quickly because we have lots of vocal users to give input. I don't see why other projects cannot take advantage of those same people. > it should also > well integrated into a Debian environment. For example, I try > KDevelop not a long time ago. When I run it, it asked me a lot > of questions about where *its* files (like documentation) are > installed, then try to install things under /usr/local then stop > functionning properly. Did you report this to the maintainer? Was he interested in replying? > Yes, I could surely repair it repair it and contribute the changes back upstream. > but a well-behave debian package should mostly be ready to be > used after installations, with only system and user specific > configuration needed to be done (good default should be > provided when possible). So for me, KDevelop wasn't debianized. > It simply used the Debian tools to compile itself and create > a compatible binary archives, not a true .deb files. > True but this is still a win for the user. Kdevelop doesn't get everything right but at least it follows the Debian file system structure. It has the right dependencies. It registers with the menu system. That's at least a little less work that the user has to do than if he is installing a tarball into /usr/local. > > There seems to be a lack of communication. Either the Debian packagers > > are not contributing their work upstream or the Gnome hackers are refusing > > to take it. I'm sure neither group really wants that. > > See my comment previously. I really think that if a developer can't > follow closely a distribution, she should let the distribution maintainers > do the work. Miguel said they didn't make .debs because it was too hard. What is so hard that intelligent people can't follow? We have lots of documentation. development tools like dh_make and debhelper, QA tools like Lintian, lot's and lots of prior art. Somehow I think the problem is not wanting to do the work not finding it too difficult. > However, I'ld like to see a standard meta-info files about > the package, which had informations necessary to create a packages, like > compilation commands, files (including informations like documentation, > binary or data), menu entries (means execution), name, author, copyright > file, changelog files, daemon, etc... This will really help to create more > package and even an automated tools (just like autoconf) that generate > everything needed according to your installation. I'm not sure if it's > feasible but I'ld thought that a tool like autoconf wasn't possible too > if I doesn't use it so often ;) > Didn't someone recently do an ITP for a program that let you create packages in different formats? If it works well it would be cool. > > Bad idea. Individual developers can and probably should work with Helix > > etc. but Debian as a project should not take a stand for or against any > > desktop until one clearly emerges as the winner. (and when and if it > > does, it will be KDE ha ha.) > > Sorry, I don't see the point to have only one winner? > Say what you like about Windows but having everything use COM as the underlying architecture is a big plus. Having two seperate component architectures (three if I have understood Mozillas XPCOM correctly) is wasteful and unnecessarily slows th
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, Mar 14, 2000 at 09:23:42PM -0600, Steve Greenland wrote: > On 14-Mar-00, 18:58 (CST), Craig Sanders <[EMAIL PROTECTED]> wrote: > > actually, it's really sad that you haven't learnt that closing down > > 'unstable' is a disastrously bad idea. you've been with debian long > > enough now to have learnt that. > > How do you know? We've never tried it. You and others say it would > be a disaster. I and others think it would help. Proof by assertion > isn't. because if developers had to wait 12 or 18 months to get their new stuff into debian then there would be very few developers who would bother. that constitutes a disaster. it would be the death of debian. > > However, there is no reason to require everyone to help or even to > > care very much about frozen/stable. > > Except that it is part of what Debian does. i am glad you recognise that it is only *part* of what debian does. > Joining the org implies at least some interest in the goals. If you > disagree with the goals, lobby to change them. i do not disagree with debian's goals. if i did then i wouldn't be here. > > by "forking" the release as a sub-project, and granting complete > > authority and responsibility to those who give enough of a damn to > > join the release team, you can minimise the delays and interruptions > > caused by the vast majority of developers who work on unstable yet > > have little or nothing to contribute to the release process. > > Why do you continue to insist that they can't contribute? i don't insist that at all. quite the contrary, i insist that they continue to contribute in whatever way they see fit, including the option of uploading new stuff to unstable. > They can test installs, they can fix bugs, they can improve docs. not everyone has the time, patience, inclination, skills, desire or whatever to do these things. if somebody wants to work on these things, then that's fine. if somebody wants to work on unstable, where is the problem? > > that's something for the release team to worry about - after all, > > they're the ones who are going to face the problems caused when it > > comes time to do the next freeze/release. > > Yeah, this release team should take on all responsibility for all the > other peoples packages. wrong. they take on the responsibility for the RELEASE. if that means that they feel they have to make a change to somebody else's package then so be it, they should have the right to do so. delegate complete authority to the release team to do whatever they feel is necessary to produce a high-quality release version of debian. if the maintainer of a changed package agrees with their decision then they will incorporate the changes into their version of the package. if not, then there is a dispute which will eventually need to be resolved. big deal, shit happens, deal with it on a case-by-case basis. > Beautiful. Never mind that the next freeze, those problems *still* > exist because the maintainer of the package doesn't need to care about > fixing bugs or following policy; that might happen in a tiny minority of cases, but it's hardly likely to be the normal case. there's no need to paint it in such black & white terms, either. there are legitimate grounds for a package maintainer to disagree with the release team, without wearing those insulting labels. > after all, it's "something for the release team to worry about". if the maintainers and the release team are doing their job properly then this will rarely be a problem. in the few cases where it does become a problem then we deal with it in the usual way - have a discussion or flamewar on debian-devel and eventually reach consensus (or at least, adapt policy so that the current ambiguity is resolved) > Apparently you need to go back and read MMM again, and tCatB as well: > you missed the point that the reason that productivity does not vary > linearly with people has to do with how easily the tasks are done > in parrallel. 10 people *can* dig 10 holes 10 times as fast as 1 > person. And what computing task *is* well done in parallel? Testing > and debugging. That's why the whole Bizzaar methodology works! testing packages is not the only delay in the release cycle. for example, the boot floppies were a significant delay this time around. that's not surprising at all, they usually are...there's a lot of new development and a lot of work in making sure all the new base packages and new kernel work properly as an install set. even if everything in the freeze/release cycle were perfectly parallelizable, that would still be no justification for closing off unstable. not everyone has the ability or the desire to contribute to frozen - they should be allowed to contribute to unstable as they always have been. > > so how many people can work on the one problem (say, the > > boot-floppies) at the same time? it *might* go faster if there were > > 2 or 3 people working on it rather than just one, but it would > > *certainly* go
Re: Danger Will Robinson! Danger!
On Wed, Mar 15, 2000 at 12:46:39AM +0200, Ari Makela wrote:
> John Lapeyre writes:
>
> >Maybe you find it easy. But you are relatively elite in debian
> > knowledge.
>
> I'm not a beginner. I even earn my living as an unix
> administrator. But I'm certainly not a unix guru.
>
> >I got a notebook two months ago. The video, sound, and pcmcia are
> > not supported by slink.
>
> Are these really a big problem? During the summer same happened to me and
> what I did was following:
>
> I installed Slink. I went to a local xfree86-mirror and got SVGA
> xserver version 3.3.5 which supports NM2200 chip. I dropped it in
> place of the distributed. Yes, that's a wrong way of doing things but
> it has always worked for me. I didn't know about http://www.debian.org/%7evincent/ > at the time (BTW: this is a
> problem, people don't know about these unofficial updates).
>
> Sound support for esssolo-1 came when I compiled 2.2-kernel. There
> are instructions what needs to be updated on Debian web site.
>
> PCMCIA is not needed for installation and it can be compiled later. It
> doesn't have to work at first.
Ever installed on an older laptop? I spent 3 days trying to install on my
laptop because it didn't have a CDROM, so i had to get base off of the
network(and i know that i could put it all on floppies, but i have a really
hard time finding 1 good one to boot off of, and I know i'm not alone).
>
> I feel that anyone who tinkers with GNU/Linux - or with any unix or
> unix clone - should be able to do above things if documentation is
> available. Documentation in one place instead of several web pages
> which are hard to find. I've not seen such a document. Is it that I
> haven't found it or is it non-existent? If latter is true I could
> write some kind raw version if others agree with me on this.
>
> >Maybe people who can't do that are lazy and stupid and don't
> >deserve Debian.
>
> And you say you don't use sarcasm? :)
>
> >People can't ship stable Debian on new machines, but they can ship
> > RH and SuSE.
>
> I agree that many users cannot replace the kernel on the rescue disk
> like I did. One needs some knowledge and also a Linux system which
> most people don't have. But it's not so hard that it might sound,
> either. It's enough that it works on one system, it doesn't have to
> result a system where every device works.
>
> I feel Athlon is the most important problem. As far as I remember
> this is the only case where it has been impossible to install Debian
> on an Intel system if we don't count very exotic hardware.
>
> > (I don't want to attack with the sarcasm, just to make a strong point).
>
> It seems that I am not able to write what I think so I try again:
>
> I don't deny that there are problems for some users but in most cases
> "stable is too old" problems can be solved relatively easily. This
> could be made easier for inexperienced people if two things would be
> done:
>
> - if it would be easier to find the unofficial updates for
> xfree and Gnome.
> - as simple and short documenation as possible where it is
> told how Debian is updated.
>
> If the development cycle were faster there might not be enough time to
> test enough. That's what I'm afraid of. The pool system might be a
> solution.
>
> --
> #!/usr/bin/perl -w -- # Ari Makela, [EMAIL PROTECTED],
> http://www.iki.fi/hauva/
> use strict;my $s='I am just a poor bear with a startling lack of brain.';my
> $t=
> crypt($s,substr($s,0,2));$t=~y#IEK65c4qx AR#J o srtahuet#;$t=~s/hot/not/;my
> @v=split(//,$t);push(@v,split(//,reverse('rekcah lreP')));foreach(@v){print;}
Erik Bernhardson
[EMAIL PROTECTED]
--
It is better to remain silent and be considered a fool, than to speak and
remove all doubt.
-- Mark Twain
pgpazI9KfX4xJ.pgp
Description: PGP signature
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Le Wed, Mar 15, 2000 at 06:06:24PM +1100, Craig Sanders écrivait: > and fuck you too! how dare you fucking misrepresent my position and > twist what i said in such a reprehensible manner? > > if you don't fucking understand what i'm saying then shut the fuck up. Could you stop use those FUCKING words ? Can't you be polite ? And yes, your attitude stinks ! You have 3 RCB open against your packages (11, 25 and 21 days old), so YOUR FUCKING job is to close those FUCKING RCB and not concentrate on woody or whatever you care ... If all maintainer could correct their own bugs, then there would be no need to work on someone else package just to make it ready for potato ! And you also have 50 other bugs to correct on your little packages. You're certainly NOT the guy who can speak loud, you're not an example to follow ! Really, from time to time I think we should close debian-devel since we're loosing time on discussion that are not worh it and/or with people that should be doing something else than flaming here ... A funny new rule would be that anybody having a RCB on one of its packages, can't post to the Debian lists unless it's specifically for correcting those bugs ... Cheers, -- Raphaël Hertzog >> 0C4CABF1 >> http://tux.u-strasbg.fr/~raphael/ CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 12:10:54PM +1100, Craig Sanders wrote: > > > > Uh, which were the packages in question? Did you report it at the > > > > time? > > > > > > no need, the holes were already well known - and fixed in unstable. > > > > Security fixes have to be (and are) fixed in stable, too! > > most are. IMNSHO *all* of them must be. It would be wrong to leave the users of stable `in the cold'. Those bugs that aren't fixed in stable are the worst release-critical bugs. -- enJoy -*/\*- don't even try to pronounce my first name
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 09:35:35AM +0100, Raphael Hertzog wrote: > Le Wed, Mar 15, 2000 at 06:06:24PM +1100, Craig Sanders écrivait: > > and fuck you too! how dare you fucking misrepresent my position and > > twist what i said in such a reprehensible manner? > > > > if you don't fucking understand what i'm saying then shut the fuck up. > > Could you stop use those FUCKING words ? Can't you be polite ? i respond to insults in whatever fucking manner i see fit. if steve had stuck to the fucking issue and refrained from being an insulting prick then i wouldn't have felt any need to swear at him. > And yes, your attitude stinks ! You have 3 RCB open against your > packages (11, 25 and 21 days old), so YOUR FUCKING job is to close > those FUCKING RCB and not concentrate on woody or whatever you care > ... fuck off. these 3 RCBS are news to me, but that's no fucking suprise because it wouldn't be the first fucking time that the fucking bug tracking system failed to fucking send a bug report to the fucking maintainer. Here's a fucking clue for you: I DO NOT DO WHAT YOU FUCKING TELL ME TO, GET THE FUCKING PICTURE? i'll close them when i fucking feel like it and when i have the fucking time. > Cheers, fucking hypocrite. if you're going to be an arsehole in email, the least you can fucking do is get rid of the phony fucking "Cheers". no fucking regards, craig ps: fuck you too, arsehole. pps: i'll use whatever fucking words i like. if you don't like it, then don't fucking read it. go censor your fucking self. -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 10:05:09AM +0100, Josip Rodin wrote: > > > Security fixes have to be (and are) fixed in stable, too! > > most are. > > IMNSHO *all* of them must be. It would be wrong to leave the users of stable > `in the cold'. Those bugs that aren't fixed in stable are the worst > release-critical bugs. most are. most of them even in a timely fashion. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
15.03.2000 pisze Craig Sanders ([EMAIL PROTECTED]): [cut] Gentlemen, I have seen ``South Park: The Movie'' and I like it -- in the cinema. Not here. I don't like to see developers of my favourite Linux distribution to behave in such a childish way. Would you kindly like to get your toys and go to the other sand-box to play (or fight, or kill yourselves, I don't care)? sincerely, Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] Lásku moji kníže Igor si bere nad sklenkou vodky hraju si s revolverem havran usedá na střechy Petěrburgu čert aby to spral -- Jaromir Nohavica
Embedded(/RT) Debian? Embeddian GNU/Linux?
Hi, does anybody know, wether there are ideas or plans to make an Debian GNU/Linux especially for embedded and/or realtime systems, i.e. "Embedian GNU/Linux"? I think, that the Linux Router Project was once based on Debian, but this is very specialised on one task. And I don't know what Mobile Linux (Crusoe) will be. I think, that the standard Debian GNU system is not well suited for embedded systems, because - policy requires docs and man pages, but one does not want any docs or man pages on an embedded system; - the base system/required packages is far too much for embedded systems, e.g. one does not want perl necessarily; - packages have to be even more fine-grained, or one does need some options to install packages partially. OTOH, embedded Debian GNU would be cool, because, - superior package management; - large number of packages in potato; - good Debian infrastructure; - it would be easy to have one distribution, that would work for a lot of different computers, like routers, telephones, VCRs, ATMs, washing machines, PDAs... Well, is there sth. like this already or are people working on this? TIA, -- W. Borgert <[EMAIL PROTECTED]>
Re: aptitude
On Sun, Mar 12, 2000 at 08:00:27PM -0500, Fabien Ninoles wrote: > > You just miss another one: sl-stormpkg from Stormix. > Sure, it's not on potato but add > deb ftp://download.stormix.com/storm potato main > in sources.list and install sl-stormpkg. > > It's GPLed, GNOME-based, used whatever commands you want for > updating/upgrading (default is the dselect apt methods) > under whichever (including current tty) x-terminal. > Use it for a month now and really love it. Since it's GPLed where can i find sources? I'd like to compile it for PPC. I tried to find it on download.stormix.com but failed -- Robert Ramiega | [EMAIL PROTECTED] IRC: _Jedi_ | Don't underestimate UIN: 13201047 | http://www.plukwa.net/ | the power of Source
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 09:35:35AM +0100, Raphael Hertzog wrote: > You have 3 RCB open against your packages (11, 25 and 21 days old), right. one of them for a package (spamdb) which doesn't even exist anymore so it's a bit difficult to see how it could be "release critical". two of them for the same package (vtun). again, they hardly seem "release critical" i haven't yet decided what to do about vtun. i'll probably get around to upgrading it to the latest version one day, but i made a mistake packaging it in the first place - i thought it would be useful, but i don't even use it any more. it's not a particularly important package (both cipe and tunnelv do a much better job of the same kind of thing) and it would be small loss to debian if it happened to get dropped from frozen while i'm taking my time deciding what to do. if anyone cares enough about vtun to adopt the package or do an NMU before i get around to it, feel free. > And you also have 50 other bugs to correct on your little packages. the bulk of those are for spamdb, which doesn't exist any more - it's obsolete (and i gave over a year's warning that i was going to orphan it - nobody cared enough about it to bother adopting it in that time). most of the rest have actually been fixed, but i must have got the BTS syntax wrong when closing the bugs in the changelog. craig -- craig sanders
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Tue, 14 Mar 2000, Ben Collins wrote: > First of all, you need to check your numbers. Last I checked there were > ~350 official developers in the keyring. Right, so this proves my point in > that we should encourage developers to put a priority on frozen and the > next release cycle. And please stop refering to stable. That is not my > main concern here, and I never brought it into this conversation. No, that means you should OPEN NEW-DEVELOPERS! Jesus! On the one hand I hear all of these complaints about not having enough help and the other hand is flipping a big 'ol bird at anyone who's offering to help. The only way I see new manpower being added to Debian ATM is cloning, and I'm kind of hoping nobody in Debian qualifies as sheep or pigs. > ---===-=-==-=---==-=-- > / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ > ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' > `---=--===-=-=-=-===-==---=--=---' > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > The Internet must be a medium for it is neither Rare nor Well done! mailto:[EMAIL PROTECTED]">John Galt
I don't get copies of bug reports to my packages
For some reason, since a while I don't get copies of bug reports against my packages mailed to me. I'm tracking debian-bugs-dist now and checking the web page once in a while, but this is less than satisfying. Is this feature of the BTS still supposed to work, and how can I check what goes wrong ? Gregor pgpxl1BMfT1ZR.pgp Description: PGP signature
Re: I don't get copies of bug reports to my packages
Previously Gregor Hoffleit wrote: > For some reason, since a while I don't get copies of bug reports against my > packages mailed to me. I'm tracking debian-bugs-dist now and checking the > web page once in a while, but this is less than satisfying. mee too. Same for bug submitters btw, I had to dig into my debian-bugs-dist folder today to see what a maintainer said to a bugreport I filed and why it was listed as closed on the rc-bugs page :( Darren: can you investigate? Something seems to be *seriously* broken.. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
ITP: e16keyedit
e16keyedit is a gtk+ based keybinding editor for the enlightenment window manager. The license is BSD-style. -- [EMAIL PROTECTED]
Re: I don't get copies of bug reports to my packages
On Wed, 15 Mar 2000, Wichert Akkerman wrote: > mee too. Same for bug submitters btw, I had to dig into my > debian-bugs-dist folder today to see what a maintainer said to a > bugreport I filed and why it was listed as closed on the rc-bugs page :( Ditto. I was really surprised to find a bug severity important the day before which was two weeks old. It is not my habit to have important bugs open so long id they are easy to solve :-(. Kind regards Andreas.
'impact' ttf license?
hello i'm planning to package a perl tool i made (available at http://tools.desire.ch/perlbeat) which includes some gifs using the IMPACT (windows) truetype font. now i wonder if this is ok, because i don't know about impact's license. does anyone? thanks for your help Stefan
Re: Becoming a developer
Kenneth Scharf wrote: > > >From what I read on this subject, I thought that most > of the flame war was on KDE, and that it might be > possible to include KDE IF, they made certain specific > releases in their license. Since I thought that RMS > had appoved the newer QT license as a free license > (does KDE yet use Qt2, which is the new QT license?), > that this problem was going away. > > I admit I am NOT a legal expect on this kind of stuff. > Is there a way to search the archives on debian-legal > for QT? Maybe some of my questions will have answers > there (If one can wade through the flames). Is there > a way (via license modification disclaimers) that a > program written using QT can be GPL'ed at all? > Finally I note that debian DOES have the QTLib in the > distro, will this remain (allowing users to at least > use such programs via source)? This is what I have understood so far, but cannot guarentee corectness: The free QT liscence with QT2 is a fully valid open source liscence. It is completely compatible with DFSG. Linking to it with pure GPL code is not allowed however ( a deficiency with the GPL not the QT liscence) You could however slightly modify your liscence to allow QT2. There are many other DFSG free liscences out there that allow QT2, you could use one of these instead of GPL. > I don't know if I would attempt to re-write QSSTV to > replace the QT calls with GTK calls, but that would be > a last ditch idea. It truly would, QT is FAR superior to GTK!! Cheers, John
new version in frozen?
I just checked through the bugs open against quota and found that quite a lot of them are fixed in the new upstream version 2.00-pre4. Yes, it is not final so far but probably will be pretty soon. Now I wonder if it is possible to add this version to frozen. If not all bug fixes have to be backported and frankly I'm not interested in that kind of work. Re-packaging the new upstream version seems to be much less work. Comments? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Re: new version in frozen?
On Wed, Mar 15, 2000 at 08:32:48AM +0100, Michael Meskes wrote: > I just checked through the bugs open against quota and found that quite a > lot of them are fixed in the new upstream version 2.00-pre4. Yes, it is not > final so far but probably will be pretty soon. Now I wonder if it is > possible to add this version to frozen. If not all bug fixes have to be > backported and frankly I'm not interested in that kind of work. Re-packaging > the new upstream version seems to be much less work. There is a point where backporting is actually more risky than using the (presumably tested) new upstream version. However, what else has changed in quota 2.00? Are there incompatibilities? Richard Braakman
Re: Becoming a developer
On Wed, Mar 15, 2000 at 11:32:42AM +, John Travers wrote: > This is what I have understood so far, but cannot guarentee corectness: > > The free QT liscence with QT2 is a fully valid open source liscence. It > is completely compatible with DFSG. Linking to it with pure GPL code is > not allowed however ( a deficiency with the GPL not the QT liscence) wrong, it's a deficiency with the Qt license. the clause in the GPL which it conflicts with is there quite deliberately - its purpose is to prevent GPL-ed code being stolen through sneaky maneuvers with shared libraries. > You could however slightly modify your liscence to allow QT2. correct. the copyright owner(s) can license their software however they like - they can give an explicit permission to link their GPL-ed code with Qt. > There are many other DFSG free liscences out there that allow QT2, you > could use one of these instead of GPL. the trouble with that is that the GPL offers the best protection (for developers and users) of all the free software licenses. IMO it is a mistake to encourage the use of other licenses. > > I don't know if I would attempt to re-write QSSTV to replace the QT > > calls with GTK calls, but that would be a last ditch idea. > > It truly would, QT is FAR superior to GTK!! if you only want to work in C++, and if you don't care that it's incompatible with the GPL. craig -- craig sanders
Re: new version in frozen?
On Wed, Mar 15, 2000 at 12:45:40PM +0100, Richard Braakman wrote: > On Wed, Mar 15, 2000 at 08:32:48AM +0100, Michael Meskes wrote: > > I just checked through the bugs open against quota and found that quite a > > lot of them are fixed in the new upstream version 2.00-pre4. Yes, it is not > > final so far but probably will be pretty soon. Now I wonder if it is > > possible to add this version to frozen. If not all bug fixes have to be > > backported and frankly I'm not interested in that kind of work. Re-packaging > > the new upstream version seems to be much less work. > > There is a point where backporting is actually more risky than using > the (presumably tested) new upstream version. The only RCB left in quota is a *packaging* bug. IMHO, that should get fixed and the new version of quota should go into woody--better the devil we know that the devil we don't. (And we really don't need another "well, this new version is ok" exception in potato. RCB's only, and lets get this thing out the door.) -- Mike Stone pgpV0RencD1Cz.pgp Description: PGP signature
Re: priority of x-window-manager
Branden Robinson <[EMAIL PROTECTED]> writes: [policies snipped] > Also, I don't understand what this will buy us. An app, such as a window > manager, can be internationalized, but it might not be localized for the > user's locale. > > IOW, it doesn't seem to me that a window manager is any more useful from a > user's perspective if it is internationalized, if it doesn't have > localization for this locale. > > Therefore, I am not sure that escalating the priority of i18n'ed window > managers is really going to accomplish anything. > > Moreover, Debian doesn't have a default window manager, and may never. The > point of these priority values is to "reward" the ones that are better > integrated into our system. > > But there may be some aspects of i18n that I am missing here. Please take > this opportunity to educate me on the subject. My mind can be changed. :) You misunderstood "i18n" as just the translation support (and "l10n" as the translations). Translation is just a category of i18n. Atsuhito means i18n for the correct character displaying. Korean (and maybe Japanese) X users often see the Netscape titlebar incorrectly displays Korean web page title. Many of the window managers still don't care about this and just draw the raw string with XDrawString(). The correct behavior is decoding the received compound strings and drawing the decoded ones with XmbDrawString(). -- Changwoo Ryu IDIS Co.,Ltd.<[EMAIL PROTECTED]> Debian GNU/Linux <[EMAIL PROTECTED]>
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 09:03:18PM +1100, Craig Sanders wrote: > On Wed, Mar 15, 2000 at 09:35:35AM +0100, Raphael Hertzog wrote: > > You have 3 RCB open against your packages (11, 25 and 21 days old), > > two of them for the same package (vtun). again, they hardly seem > "release critical" > > i haven't yet decided what to do about vtun. i'll probably get around > to upgrading it to the latest version one day, but i made a mistake > packaging it in the first place - i thought it would be useful, but i > don't even use it any more. Hmm. I don't see this on the list of orphaned packages. It also doesn't seem like you indicated this to [EMAIL PROTECTED], so how would the release manager know it? -- Mike Stone pgp0I6zOe5nD0.pgp Description: PGP signature
Permission policy
I need some advice to solve a recent bug report regarding a frozen package. The program needs rx-permissions for a device belonging to the cdrom group and rw-permissions for a device belonging to the audio group. Until now the program is sgid cdrom to work correctly with the cdrom-device without changing the permissions for that device but I do not see a simple solution for the audio access without making the audio device world readable and writeable which is certainly a violation of the policy. Any ideas? Best wishes Volker -- - Volker OssenkopfKOSMA (Kölner Observatorium für submm-Astronomie) Tel.: 0221 47034851. Physikalisches Institut der Fax.: 0221 4705162 Universität zu Köln E-Mail: [EMAIL PROTECTED] -
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 07:07:51AM -0500, Michael Stone wrote: > On Wed, Mar 15, 2000 at 09:03:18PM +1100, Craig Sanders wrote: > > i haven't yet decided what to do about vtun. i'll probably get around > > to upgrading it to the latest version one day, but i made a mistake > > packaging it in the first place - i thought it would be useful, but i > > don't even use it any more. > > Hmm. I don't see this on the list of orphaned packages. try reading the words in front of you. i have not yet decided what i'm going to do about vtun. i will probably upgrade it to the latest version one day. if someone wants to take it over or do an NMU before i get around to it then they should feel free to do so. > It also doesn't seem like you indicated this to [EMAIL PROTECTED], once again: "I haven't yet decided what to do about vtun". craig -- craig sanders
Re: aptitude
On Wed, Mar 15, 2000 at 10:55:38AM +0100, Robert Ramiega wrote: > On Sun, Mar 12, 2000 at 08:00:27PM -0500, Fabien Ninoles wrote: > > > > You just miss another one: sl-stormpkg from Stormix. > > Sure, it's not on potato but add > > deb ftp://download.stormix.com/storm potato main > > in sources.list and install sl-stormpkg. > > > > It's GPLed, GNOME-based, used whatever commands you want for > > updating/upgrading (default is the dselect apt methods) > > under whichever (including current tty) x-terminal. > > Use it for a month now and really love it. > > Since it's GPLed where can i find sources? I'd like to compile it for PPC. > I tried to find it on download.stormix.com but failed It's in ftp://download.stormix.com:/storm/dists/rain/main/source/ if I understand correctly, rain is their stable distribution and potato is just a recompilation of some packages for upgrade purpose. > > -- > Robert Ramiega | [EMAIL PROTECTED] IRC: _Jedi_ | Don't underestimate > UIN: 13201047 | http://www.plukwa.net/ | the power of Source -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 11:18:49PM +1100, Craig Sanders wrote: > On Wed, Mar 15, 2000 at 07:07:51AM -0500, Michael Stone wrote: > > On Wed, Mar 15, 2000 at 09:03:18PM +1100, Craig Sanders wrote: > > > i haven't yet decided what to do about vtun. i'll probably get around > > > to upgrading it to the latest version one day, but i made a mistake > > > packaging it in the first place - i thought it would be useful, but i > > > don't even use it any more. > > > > Hmm. I don't see this on the list of orphaned packages. > > try reading the words in front of you. i have not yet decided what i'm > going to do about vtun. i will probably upgrade it to the latest version > one day. if someone wants to take it over or do an NMU before i get > around to it then they should feel free to do so. How would people know that if it's not on the list? If you put it on the list and then change your mind, you can take it off. If you orphan it and later decide you want to upgrade it, *you* can do an NMU. But by doing nothing you make it very difficult for other people to maintain your package for you. -- Mike Stone pgpvQGajt2aWv.pgp Description: PGP signature
Re: I don't get copies of bug reports to my packages
On Wed, Mar 15, 2000 at 11:25:47AM +0100, Gregor Hoffleit wrote: > For some reason, since a while I don't get copies of bug reports against my > packages mailed to me. I'm tracking debian-bugs-dist now and checking the > web page once in a while, but this is less than satisfying. I noticed that [EMAIL PROTECTED] bot processes the messages you send to id silently, then processes it again, but this time mailing the report to you. It is also known that the locking in the BTS isn't implemented properly so any messages that you send while the web pages are being regenerated will get stuck in the incoming mail queue (or something like that, I don't quite recall the details correctly). Darren Benham and Adam Heath (they are behind [EMAIL PROTECTED]) spoke about this on IRC on several occasions. Word has it that Johnie Ingram has some patches for that Perl code, but I don't think these patches were applied... It actually seems that subscribing to -bugs-dist mailing list is useful right now... although it is so damn painful when you don't have lots of time to sift through it. :( -- enJoy -*/\*- don't even try to pronounce my first name
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
[ ok I'll keep calm this time ] Le Wed, Mar 15, 2000 at 09:03:18PM +1100, Craig Sanders écrivait: > right. one of them for a package (spamdb) which doesn't even exist > anymore so it's a bit difficult to see how it could be "release > critical". That's possible, but then it would be great if you could close all the bugs related to spamdb so that they won't burden us anymore ... > two of them for the same package (vtun). again, they hardly seem > "release critical" Then it's your job to lower the priority and/or to close them. I don't want more from maintainer, I just want that they do what they have to and it's not that much ... it's not difficult to check once a week your page on the BTS. > most of the rest have actually been fixed, but i must have got the BTS > syntax wrong when closing the bugs in the changelog. The same problem applies to many developers, but that must change, when a bug is gone, it must be closed in the BTS or the BTS will be worthless one day or another. Cheers, -- Raphaël Hertzog >> 0C4CABF1 >> http://tux.u-strasbg.fr/~raphael/ CD Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd Formations Linux et logiciels libres : http://www.logidee.com
Re: priority of x-window-manager
Hi, From: Changwoo Ryu <[EMAIL PROTECTED]> Subject: Re: priority of x-window-manager Date: 15 Mar 2000 21:04:47 +0900 > Korean (and maybe Japanese) X users often see the Netscape titlebar > incorrectly displays Korean web page title. Many of the window > managers still don't care about this and just draw the raw string with > XDrawString(). The correct behavior is decoding the received compound > strings and drawing the decoded ones with XmbDrawString(). Yes! When non-European people talk about internationalization, they often talk about displaying and inputing their native character, such as Kanji, Hangul, Cyrillic, Thai, and so on. A window manager is a software on which many softwares run. Thus a window manager which cannot display native characters avoids many softwares (which are internationalized --- Netscape is an example) to work well. Thus I support Atsuhito Kohda's idea to add points to "internationalized" window managers which can display native characters. Please read a document on internationalization which is found in DDP (Debian Documentation Project) web page. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://surfchem0.riken.go.jp/~kubota/
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 03:24:29AM -0700, John Galt wrote: > On Tue, 14 Mar 2000, Ben Collins wrote: > > > > First of all, you need to check your numbers. Last I checked there were > > ~350 official developers in the keyring. Right, so this proves my point in > > that we should encourage developers to put a priority on frozen and the > > next release cycle. And please stop refering to stable. That is not my > > main concern here, and I never brought it into this conversation. > > No, that means you should OPEN NEW-DEVELOPERS! Jesus! On the one > hand I hear all of these complaints about not having enough help and the > other hand is flipping a big 'ol bird at anyone who's offering to help. > The only way I see new manpower being added to Debian ATM is cloning, and > I'm kind of hoping nobody in Debian qualifies as sheep or pigs. > New Maintainer is OPEN. They posted a call for applications from currently sponsored developers last week. This means that people who are currently helping via the sponorship program are going to get in quite quickly. IMNHO, this is exactly the right thing to do. People who have shown that they are willing to contribute, even if it means waiting, have shown they have what it takes to become a developer. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Apt-Problem
Hallo, since last week I have a problem when upgrading potato. In the dselect install process after obtaining the necessary packages I get mysterious "Size mismatch" for all packages. All the packages are stored /var/cache/apt/archives/partial and a `dpkg -i /var/cache/apt/archives/partial/*` seems to be working perfectly. Today I tried it once more because it might be caused by some problems with the dpkg package which had known problems. But it is the same today. I tried another Debian mirror and tried to disable the proxy cache but nothing worked. Here is an example with a single package to demonstrate the problem: ~# apt-get install libtool Reading Package Lists... Done Building Dependency Tree... Done The following NEW packages will be installed: libtool 0 packages upgraded, 1 newly installed, 0 to remove and 13 not upgraded. Need to get 177kB of archives. After unpacking 681kB will be used. Get:1 http://ftp.tu-clausthal.de potato/main libtool 1.3.3-9 [177kB] Failed to fetch http://ftp.tu-clausthal.de/pub/linux/debian/dists/frozen/main/binary-i386/devel/libtool_1.3.3-9.deb Size mismatch E: Unable to fetch some archives, maybe try with --fix-missing? As I said I could install the package using dpkg -i /var/cache/apt/archives/partial/libtool_1.3.3-9.deb without any warning/error. That's really strange! :-((( Anybody else got this problem? Andreas.
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Steve Greenland wrote: > There is nothing stopping anyone from making snapshot releases of > unstable. Mirror the archive. Burn a CD. Done. That's what a snapshot > is. As one of the many people who does not have cheap, fast, reliable internet access, I would like to say that for me to mirror 650 MB of debian and burn a CD of it would cost around $130 in charges and 2 and a half days of straight downloading if I was lucky. Probably much longer. So I'd like snapshots, but really I run stable run until the moment frozen becomes stable at which I can get a CD on which everything has a good chance of working, because if anything breaks I'm pretty much stuffed. -- Martijn van Oosterhout <[EMAIL PROTECTED]> Trust the computer industry to shorten "Year 2000" to Y2K. It was this kind of thinking that caused the problem in the first place.
Re: Apt-Problem
> On Wed, 15 Mar 2000 14:17:54 +0100 (CET), Andreas Tille <[EMAIL > PROTECTED]> said: Andreas> http://ftp.tu-clausthal.de/pub/linux/debian/dists/frozen/main/binary-i386/devel/libtool_1.3.3-9.deb Andreas> Size mismatch E: Unable to fetch some archives, maybe try Andreas> with --fix-missing? Andreas> As I said I could install the package using dpkg -i Andreas> /var/cache/apt/archives/partial/libtool_1.3.3-9.deb Andreas> without any warning/error. I got the same error when I was doing an apt-get upgrade last night. It was with man-db. But when I did an apt-get upgrade after sometime again, it did not reget the package again, but installed with the same old package succesfully. anybody knows what this is ?? - Khader -- Syed Khader Vali (Siddiq) Debian GNU/Linux ( Woody ) http://www.sidcarter.com
Re: Danger Will Robinson! Danger!
On Tue, Mar 14, 2000 at 11:29:42AM -0500, Jacob Kuntz wrote: > the most commonly installed packages today, and i had to build them for a > dozen machines because stable was too far behind. That's your own fault! If you are that experienced that you can build you own packages you probably should know that the vast majority of packages from potato compiles fine under slink. It is as easy as 'apt-get -b source ' If you have a recent enough apt to recognize the source switch and a properly set up /etc/apt/sources.list. OTOH why not use the prebuild packages from unstable? They will not be more unstable than newer upstream-source... Thanks, Matthias -- +-created at Wed Mar 15 09:15:19 CET 2000-+ |Matthias Berse Phone:+49-2323-42397 | \Bachstr.28 44625 Herne, GermanyeMail: [EMAIL PROTECTED]/ Yevtushenko has... an ego that can crack crystal at a distance of twenty feet. -- John Cheever
Re: Apt-Problem
On 15 Mar 2000, Syed Khader Vali wrote: > I got the same error when I was doing an apt-get upgrade last > night. It was with man-db. But when I did an apt-get upgrade after > sometime again, it did not reget the package again, but installed with You are mory lucky than me because I tried the same several times but without success :-(. > the same old package succesfully. anybody knows what this is ?? I really hope so because I might be in the situation to convince a Win admiring man from the power of Debian. This would be a bad demonstartion :-(. Kind regards Andreas.
Re: new version in frozen?
On Wed, Mar 15, 2000 at 07:01:25AM -0500, Michael Stone wrote: > The only RCB left in quota is a *packaging* bug. IMHO, that should get Correct. > fixed and the new version of quota should go into woody--better the > devil we know that the devil we don't. (And we really don't need another > "well, this new version is ok" exception in potato. RCB's only, and lets > get this thing out the door.) I'm not so sure. Frankly, I don't like the idea of having to check each patch to see if it is correctly done (I assume the upstream has done it correctly). Also I'm not sure our patches fixed the same bugs as the upstream version. For instance I never read about: * Fixed problems when turning off one type of quota taking offline the other type too. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Re: new version in frozen?
On Wed, Mar 15, 2000 at 12:45:40PM +0100, Richard Braakman wrote: > There is a point where backporting is actually more risky than using > the (presumably tested) new upstream version. I thinks so too, yes. > However, what else has changed in quota 2.00? Are there incompatibilities? I don't know any incompatibility. From the CHANGES file there wasn't so much action except bug fixes. One command 'setquota' was added and some source files were restructured to make sure ngs are coded only once. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Re: 'impact' ttf license?
thanks to all of you for the information. Stefan On Wed, Mar 15, 2000 at 05:02:26AM -0800, Joseph Carter wrote: > On Wed, Mar 15, 2000 at 12:17:04PM +0100, Stefan Ott wrote: > > i'm planning to package a perl tool i made (available at > > http://tools.desire.ch/perlbeat) which includes some gifs using the IMPACT > > (windows) truetype font. > > now i wonder if this is ok, because i don't know about impact's license. > > does anyone? > > Distribution of rendered fonts is legal provided that you aquired the font > rendered legally. That is to say, if you have a legal copy of a font you > are entitled to use it. Case law for this predates computers by at least > 100 years and comes from the day that fonts were made of metal and put > into printing presses. > > -- > Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 > Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC > The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 > > stu: ahh that machine. Don't you think that something named >stallman deserves to be an Alpha? :-) > jgoerzen: no, actually, I'd prolly be more inclined to name a 386 > with 4 megs of ram and a 40 meg hard drive stallman. > with a big fat case that makes tons of noise and rattles the floor > * Knghtbrd falls to the floor holding his sides laughing > and.. > double-height hard drive
Re: new version in frozen?
On Wed, Mar 15, 2000 at 01:56:09PM +0100, Michael Meskes wrote: > On Wed, Mar 15, 2000 at 07:01:25AM -0500, Michael Stone wrote: > > fixed and the new version of quota should go into woody--better the > > devil we know that the devil we don't. (And we really don't need another > > "well, this new version is ok" exception in potato. RCB's only, and lets > > get this thing out the door.) > > I'm not so sure. Frankly, I don't like the idea of having to check each > patch to see if it is correctly done (I assume the upstream has done it > correctly). Why would you be checking patches? The quota in potato has been tested and there are no RC bug reports for it. What needs to change? -- Mike Stone pgp671srloe7D.pgp Description: PGP signature
A "progressive" distribution
After reading this nice diskussion with all it's aspects, I want to complete the mess and suggest a "distribution" called e.g. "progressive" beetween stable(frozen) and unstable. As I understood the problem, at the moment, only the stable distribution is able to be distributed, while the unstable branch is to unstable and there's no distrubution in between. (To simplify I count the frozen as stable short before release here.) When potate becomes stable, a branch called e.g. "progressive" could be created between the branches "stable" and "unstable". This branch (sorry for using this term, but I don't like distribution so much) would start with the modules from stable and subsets of unstable would be added, if they are usable. The term subset I use for packages that contain together like one ore more basis packages (libc,xfree,perl,... or just something like emacs) and those packages depending on this basis package. (Note that I mean basis as basis of dependencies not basis of the whole or larger parts of distribution) And usable shell mean, that this package can be used for average use without the need of Debian-like-tability. With the next freeze, this "progressive" branch could be copied to "froozen" and new useable packaged from unstable would go to "progressive", while those in frozen are kept and only made more stable. Doing this there would be a distribution in between, where new versions of products can reside and easily be used. Someone should be easily use a snapshot of progressive at an good moment to form a not-so-stable but up-to-date unofficial release, which could also be called less inoffical, if there is a common will for this. Though some advantages this would cause at least two problems: On the one hand this proposal would prohibit the current way of naming, because with any release a new distribution is created beetween stable and unstable, so some branch would change name and the old name would be used for a possibly totally other branch. So unstable( and perhaps progressive) had to be without name and just be "unstable". This coresponds to the loss of a cycle for the whole distribution. Changes would start in unstable and go through the phases of unstable, progessive and froozen before they become stable. On the other hand would this proposal multiply the number of branches to up to four when there will be the next freeze and stable,frozen,progressive and unstable beeing all together. This made me the most headacke, but I think it's not so much of a problem, as many work to make the frozen version of his package will seriously prevent him from working so much on the unstable version, that this could become "usable". So most packages would be either the same in frozen and progressive or they would be same in progressive and unstable. Hochachtungsvoll, Bernhard R. Link
Re: TeTeX bugs
Denis Barbier <[EMAIL PROTECTED]> writes:
>
> On Tue, Mar 14, 2000 at 01:11:03PM +0100, Stephane Bortzmeyer wrote:
> > Since the teTeX in slink works fine and the one is potato is broken
> > (a bug in babel which prevents compilation of *every* document in
> > French), I prefer the old stuff.
>
> I've provided information to close #42698, here it is again
> PS: I'm not a Debian developer.
>
> --- tetex-src-1.0.orig/latex/base/ltoutenc.dtx Thu Mar 4 09:51:25 1999
> +++ tetex-src-1.0/latex/base/ltoutenc.dtx Wed Mar 15 00:02:29 2000
> @@ -800,6 +800,7 @@
> %\begin{macrocode}
>[EMAIL PROTECTED]
> \accent#1 [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> %\end{macrocode}
> % \end{macro}
> %
>
I will bring this patch in in the next day. I was busy fixing some
other packages.
Christoph
--
Christoph Martin, Uni-Mainz, Germany
Internet-Mail: [EMAIL PROTECTED]
--export-a-crypto-system-sig -RSA-3-lines-PERL--
#!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
Re: TeTeX bugs
Denis Barbier <[EMAIL PROTECTED]> writes: > > On Tue, 14 Mar 2000, Dylan Paul Thurston wrote: > > > On Tue, Mar 14, 2000 at 01:11:03PM +0100, Stephane Bortzmeyer wrote: > > > Since the teTeX in slink works fine and the one is potato is broken > > > (a bug in babel which prevents compilation of *every* document in > > > French), I prefer the old stuff. > > > > Surely that should be an important bug (#42698)? In fact, browsing > > the bugs against tetex-base, several of them seem important, including > > at least one security bug (#57746, same as #32652). Should I upgrade > > them? Unfortunately, the security bug seems non-trivial to fix. > > Where is this security flaw? > There has been no response to the question asked by Christoph Martin on > 1 Feb 1999 > http://cgi.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=32652> > We discussed that issue widely in the past. There is no real risc in having this directories world writable. If only ths ls -lR file is not writable. This file is updated from cron every night and we are working on a suid-script which can do it from users. Christoph -- Christoph Martin, Uni-Mainz, Germany Internet-Mail: [EMAIL PROTECTED] --export-a-crypto-system-sig -RSA-3-lines-PERL-- #!/usr/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/
ZnO pressure sensor varistors, negative temperature coefficient (NTC) and positive temperature coefficient (PTC) full range product
Guangdong Foshan Kestar Electronic Co., Ltd. is specializing in ZnO pressure sensor varistors, negative temperature coefficient (NTC) and positive temperature coefficient (PTC) full range products. We have implemented of ISO 9002. We devote ourselves to customers' satisfaction, excellent quality, prompt delivery and reasonable price. Our large R & D engineering staff can handle customer designs and best service with absolute professionalism. If you have any request, please do not hesitate to contact us. [EMAIL PROTECTED] --- Above supply information is provided by Gold Line Business Information Service Company. Our service mainly includes: to help all the manufacturers in mainland of China with sales promotion and overseas marketing. And meanwhile we offer Chinese market and products information consulting service for foreign buyers or importers. If you are now looking for any product in good quality and at favorable price, it is the great opportunity to be of your service with manufactures and products as well as other related information. Any inquiry, please feel free to contact us know. Gold Line Business Information Service Company Limited Address: 7/F, Science & Technology Center, No. 3, Nanxing San Road, Guicheng District, Nanhai City 528200, Guangdong Province, China Tel: +86-757-6336 141 / 6239 656 Fax: +86-757-6336 141 E-mail: [EMAIL PROTECTED] Contact Person: Keng Xing --´ËÓʼþÓÉÍòÏó»Ã¾³³öÆ·µÄ"ÓʼþÅú·¢Õ¾"·¢ËÍ--- ÍòÏó»Ã¾³Óлú·¿¾ÖÓòÍø¹ÜÀíÈí¼þÕÂÓãÖúÀí¡¢ÓʼþÅú·¢Õ¾¡¢ ¶ÔÑÛÉñ¹¦¡¢Ð£Ô°³©ÏëÇúµÈÈí¼þ£¬»¶Ó¹âÁÙÏÂÔØ£º http://cookey.126.com »¶ÓʹÓà http://2888.com Ãâ·Ñµç×ÓÐÅÏä¼°·ÖÀàÐÂÎÅ¡¢¸öÐÔ»¯±¨¿¯¡¢ ¾«ÃÀºØ¿¨¡¢×Ô¶¯ÃØÊé¡¢ËæÉíÐÅÏä¡¢ËæÉí±Ê¼Ç¡¢¹©Çó¡¢ÕÐƸÇóÖ°ÐÅÏ¢µÈ¡£ -
Re: Embedded(/RT) Debian? Embeddian GNU/Linux?
In article <[EMAIL PROTECTED]> you wrote: > does anybody know, wether there are ideas or plans to make > an Debian GNU/Linux especially for embedded and/or realtime > systems, i.e. "Embedian GNU/Linux"? The problem is that "embedded" covers such a huge range these days. I've built several embedded systems using Pentium motherboards and smallish units of compact flash for disk... but I've seen systems with large disks described as embedded based on what they were doing. The way I've handled this, and the way I think others I've talked with on IRC have been handling it, is to in effect build a subsetting tool. You install into a spare partition or something the packages you want, then selectively copy out of that tree the pieces you need for the actual embedded system. It would be neat to have such a tool packaged and available as a standard part of Debian instead of reinventing the wheel each time. > - packages have to be even more fine-grained, or one does > need some options to install packages partially. Nah, this is far enough from the Debian primary target that I think the right thing to do is leave the current packaging structure alone, and post-process an installed system to extract the subset of files needed for the embedded target. Even something as simple as a selective copy with configurable exclusion lists will do. > - superior package management; You really, really, don't want /var/lib/dpkg on an embedded target... it gets huge quickly. The trick is to get the benefits of a packaging scheme like Debian's without having to carry that baggage into the actual embedded system. Bdale
Re: A "progressive" distribution
"Bernhard R. Link" wrote: > > After reading this nice diskussion with all it's aspects, I want to > complete the mess and suggest a "distribution" called > e.g. "progressive" beetween stable(frozen) and unstable. > > As I understood the problem, at the moment, only the stable > distribution is able to be distributed, while the unstable branch is to > unstable and there's no distrubution in between. (To simplify I count the > frozen as stable short before release here.) > > When potate becomes stable, a branch called e.g. "progressive" could be > created between the branches "stable" and "unstable". This branch (sorry > for using this term, but I don't like distribution so much) would start > with the modules from stable and subsets of unstable would be added, if > they are usable. The term subset I use for packages that contain together > like one ore more basis packages (libc,xfree,perl,... or just something > like emacs) and those packages depending on this basis package. (Note that > I mean basis as basis of dependencies not basis of the whole or larger > parts of distribution) And usable shell mean, that this package can be > used for average use without the need of Debian-like-tability. > Do you mean like, Slink 2.1 r1, 3.1r2, 2.1r3, 2.1r4 ? Id like to see a rolling stable release, where unstable package have to meet a certain pre-defined criteria before they can be considered stable. Like to be stable, a package must not have any rc bugs, or have any rc bugs in its dependencies. It would also have to be exposed to the masses for a certain period of time in unstable before being considered for stable. This type of arangment could be automated prety well, it would depend on people reporting bugs and would place extra strain on bug tracking, but i think it would be easier than trying to get all the latest versions of each package bug free at one point in time. A "rolling" stable release such as this may well scale better than the traditional release model. Just a thought Glenn McGrath
Re: A "progressive" distribution
In article <[EMAIL PROTECTED]> you wrote: > After reading this nice diskussion with all it's aspects, I want to > complete the mess and suggest a "distribution" called > e.g. "progressive" beetween stable(frozen) and unstable. I gather you haven't read the discussion of package pools in the archive? First things first. Let's get potato released, and then get pools and flavors implemented before we try to release woody. Bdale
Re: priority of x-window-manager
On Wed, Mar 15, 2000 at 09:04:47PM +0900, Changwoo Ryu wrote: > You misunderstood "i18n" as just the translation support (and "l10n" > as the translations). Translation is just a category of i18n. > Atsuhito means i18n for the correct character displaying. > > Korean (and maybe Japanese) X users often see the Netscape titlebar > incorrectly displays Korean web page title. Many of the window > managers still don't care about this and just draw the raw string with > XDrawString(). The correct behavior is decoding the received compound > strings and drawing the decoded ones with XmbDrawString(). Thanks for the clarification. I'm willing to support such a priority increase now; but first, please come up with a list of specific things that a window manager needs to do. We can't just say "add 10 points if the window manager is internationalized" without telling the possible thick-headed American package maintainer how to determine whether it is or not. :) One item would obviously be: + The window manager should use XmbDrawString() instead of XDrawString() for non-error/non-diagnostic text output. Please come up with more, if there are any, and I'd be happy to make a new policy proposal incorporating your suggestions. -- G. Branden Robinson| I've made up my mind. Don't try to Debian GNU/Linux | confuse me with the facts. [EMAIL PROTECTED] | -- Indiana Senator Earl Landgrebe roger.ecn.purdue.edu/~branden/ | pgpv5mHi93o7V.pgp Description: PGP signature
Embedded(/RT) Debian? Embeddian GNU/Linux?
My first mail seems to got lost. excuse me if this turns up twice. In fact I am working on an minimal debian (-based) system. I am building an embedded system which tries to be as small as possible. I started with the linux router project, took some parts from the bootfloppys and wrote some Makefiles to take essential Binaries etc out of my running potato. Right now (since half an hour) I have a 2.2.14 kernel, glibc-2.1.3, busybox plus some other stuff in 1382 Kbytes (unpacked) in the ramdisk. (this does not count the kernel, of cause. It is booted from floppy, where it takes 905 kbyte alltogether. It should be easyly adaptable and is modular by design (like lrp is). Anyone intersted should get back to me. I would be glad to cooperate. It is gpl, of cause. I am not on this list, so please reply to me privatly, too.
Re: Embedded(/RT) Debian? Embeddian GNU/Linux?
Andreas Schuldei wrote: > In fact I am working on an minimal debian (-based) system. > > I am building an embedded system which tries to be as small as possible. > I started with the linux router project, took some parts from the > bootfloppys and wrote some Makefiles to take essential Binaries etc out > of my running potato. > > Right now (since half an hour) I have a 2.2.14 kernel, glibc-2.1.3, > busybox plus some other stuff in 1382 Kbytes (unpacked) in the ramdisk. > (this does not count the kernel, of cause. > > It is booted from floppy, where it takes 905 kbyte alltogether. > > It should be easyly adaptable and is modular by design (like lrp is). I'm interested. I'd like to be able to make a boot disk with ntfs & vfat support so I can use it as a rescue disk for hosed windows boxes. Ideally, I'd like to see a shell script that asks what network card the target box uses and creates a new rescue floppy with just that module. jpb -- Joe Block <[EMAIL PROTECTED]> CREOL System Administrator Social graces are the packet headers of everyday life.
Re: Apt-Problem
On Wed, 15 Mar 2000, Andreas Tille wrote: > Reading Package Lists... Done > Building Dependency Tree... Done > The following NEW packages will be installed: > libtool > 0 packages upgraded, 1 newly installed, 0 to remove and 13 not upgraded. > Need to get 177kB of archives. After unpacking 681kB will be used. > Get:1 http://ftp.tu-clausthal.de potato/main libtool 1.3.3-9 [177kB] > Failed to fetch > http://ftp.tu-clausthal.de/pub/linux/debian/dists/frozen/main/binary-i386/devel/libtool_1.3.3-9.deb > Size mismatch > E: Unable to fetch some archives, maybe try with --fix-missing? This means your mirror is broken, try another site. Jason
Re: A "progressive" distribution
> > In article <[EMAIL PROTECTED]> you wrote: > > > After reading this nice diskussion with all it's aspects, I want to > > complete the mess and suggest a "distribution" called > > e.g. "progressive" beetween stable(frozen) and unstable. > > I gather you haven't read the discussion of package pools in the archive? > > First things first. Let's get potato released, and then get pools and > flavors implemented before we try to release woody. > I'm all for that if you think the pools idea has any chance of being implented in our lifetime. A really simple way of handling a "progressive" distribution would be to mutate "frozen". After potato ships have frozen become thaw. Thaw would be unstable except there is a lag time between .debs hitting unstable and migrating to thaw. This lag time should be long enough to catch any critical bugs where we could tag the package from moving into thaw until those bugs are fixed. When a new stable is ready to be shipped out we'd simply "freeze" the thaw and prod the developers to fix thier critical bugs. What problems would the above cause? Could we code around issues like say php xx.3 requiring apache xx.3 and apache not hitting thaw due to a crit bug? The system would need to know to keep php xx.3 out until apache become thawable. -Mark
Re: A "progressive" distribution
i have seen a lot of discussion about a distribution half way between stable and unstable. on the surface that sounds like exactly what we need, but at least one person pointed out that this is not the way to manage a project with hundreds of developers working against hundreds of seperate releases cycles. i wish i could remember who said that first, you really hit the nail on the head. the deadline-based release cycle may work great for commercial projects, but quite possibly not for projects like Debian. i think we need something a little more organic. try this hypothetical release method out: there are two trees. let's call them devel and production. debian saavy folks (maintainers) run devel. new packages are uploaded to devel where they are tested extensivly. when a package has been in devel for more than (for instance) two weeks, and it has no release critical and few important bugs, it graduates into production. the production branch should always work. a system could be put in place where you could always get an iso image of the production branch that is recent to within a few days. i imagine that we would need to get pools in place before we could even attempt this. this type of system could probably work along side of whatever else we decide to to about release cycles. -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) "think free speech, not free beer." (gnu foundataion)
Re: A "progressive" distribution
Jacob Kuntz wrote: > the production branch should always work. a system could be put in place > where you could always get an iso image of the production branch that is > recent to within a few days. i imagine that we would need to get pools in > place before we could even attempt this. this type of system could probably > work along side of whatever else we decide to to about release cycles. This "production" branch presents a few problems to package maintainers unless some extra procedure is detailed. If the packages are being constantly updated, and a library (a dependency of package "foo", which I package) is changed so that it is no longer link-compatable with "foo", I have to rebuild and upload "foo." While this would not normally be a problem, say I'm working on "foo2" in the "devel" branch. With Debian's current "stable" / "unstable", I only have to worry about building packages against "unstable" (while I'm adding more features, fixing bugs, etc.). With "production" / "devel", I would need to track two branches. As it is now, I can pretty much leave "foo" in "stable" and not touch it (unless someone discovers security problems, etc.). This message wasn't really intended as a critique of your idea, Jacob. Rather, I wanted to take a little time to ask the Debian community to pay attention to what the FreeBSD guys do with their distributions. Please don't immitate FreeBSD's release practices. The FreeBSD guys tag a release "RELEASE" when they feel it's ready for lots of people to download, compile, and use. The "RELEASE" branch is usually of very high quality, but like all software, it has problems. Instead of continually releasing new "RELEASE" branches, they have a "CURRENT" branch of their distribution. This branch is the "RELEASE" branch plus fixes to things that had problems in the original release. So far, this plan works very well. Now comes the tricky part. FreeBSD offers a "STABLE" branch which is usually anything BUT stable. I followed this branch on two machines (just a few months ago), and I was subscribed to the "STABLE" mailing lists. "STABLE" is similar to what Jacob calls "production". The FreeBSD handbook (at http://www.freebsd.org/handbook/stable.html): If you are a commercial user or someone who puts maximum stability of their FreeBSD system before all other concerns, you should consider tracking stable. This is especially true if you have installed the most recent release (3.4-RELEASE at the time of this writing) since the stable branch is effectively a bug-fix stream relative to the previous release. "STABLE" breaks just about every day (a cvsup to their source trees and a "make world" will fail). Sometimes you can build a kernel that does very odd things (a friend of mine built a "STABLE" kernel off the recent RELENG3 tree, and the first time his machines would run out of RAM, they would handle the situation (killing the offending process), but the second time, it refused to allow any more malloc() until the kernel gave out). Of course one could choose to not continually update and build from the "STABLE" tree, but then what's the use of having updated code? Picking on FreeBSD's kernel probably isn't the best way to make a point about Debian's packaging policies, so here's my simple suggestion: Keep the "stable" and "unstable" (with the "frozen" step towards releases), but release more often. A year between releases is very painful, when I need to install somewhat recent software on a new host. Maybe double the release rate (aim for once every 6 months)? -- Shaw Terwilliger
Re: A "progressive" distribution
I really don't think that a "progressive" branch is necessary. The problems involved in keeping track of three branches at one time and trying to keep version dependencies in order between branches would far out weigh any benefit that would be created by such a branch. IMHO the structure (stable, frozen, unstable) is more than adequate. The problem that I see is that there is too much time between stable releases. I think that shorter and much more regular time periods between freezes is necessary. By fixing the number and date of freezes, with say three or four a year, and letting everyone know long in advance of the freeze it would allow developers to schedule when all bugs must be removed by. Also the fact that the time period would be much shorter would make changes between stable versions less drastic and therefore easier to handle. Ed "Bernhard R. Link" wrote: > > After reading this nice diskussion with all it's aspects, I want to > complete the mess and suggest a "distribution" called > e.g. "progressive" beetween stable(frozen) and unstable. > > As I understood the problem, at the moment, only the stable > distribution is able to be distributed, while the unstable branch is to > unstable and there's no distrubution in between. (To simplify I count the > frozen as stable short before release here.) > > When potate becomes stable, a branch called e.g. "progressive" could be > created between the branches "stable" and "unstable". This branch (sorry > for using this term, but I don't like distribution so much) would start > with the modules from stable and subsets of unstable would be added, if > they are usable. The term subset I use for packages that contain together > like one ore more basis packages (libc,xfree,perl,... or just something > like emacs) and those packages depending on this basis package. (Note that > I mean basis as basis of dependencies not basis of the whole or larger > parts of distribution) And usable shell mean, that this package can be > used for average use without the need of Debian-like-tability. > > With the next freeze, this "progressive" branch could be copied to > "froozen" and new useable packaged from unstable would go to > "progressive", while those in frozen are kept and only made more > stable. > > Doing this there would be a distribution in between, where new versions of > products can reside and easily be used. Someone should be easily use a > snapshot of progressive at an good moment to form a not-so-stable but > up-to-date unofficial release, which could also be called less inoffical, > if there is a common will for this. > > Though some advantages this would cause at least two problems: > > On the one hand this proposal would prohibit the current way of > naming, because with any release a new distribution is created beetween > stable and unstable, so some branch would change name and the old name > would be used for a possibly totally other branch. So unstable( and > perhaps progressive) had to be without name and just be "unstable". > This coresponds to the loss of a cycle for the whole > distribution. Changes would start in unstable and go through the phases of > unstable, progessive and froozen before they become stable. > > On the other hand would this proposal multiply the number of branches to > up to four when there will be the next freeze and > stable,frozen,progressive and unstable beeing all together. This made me > the most headacke, but I think it's not so much of a problem, as many work > to make the frozen version of his package will seriously prevent him from > working so much on the unstable version, that this could become > "usable". So most packages would be either the same in frozen and > progressive or they would be same in progressive and unstable. > > Hochachtungsvoll, > Bernhard R. Link > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A "progressive" distribution
On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote: > The problem that I see is that there is too much time between stable > releases. I think that shorter and much more regular time periods > between freezes is necessary. By fixing the number and date of freezes, > with say three or four a year, and letting everyone know long in advance > of the freeze it would allow developers to schedule when all bugs must > be removed by. Also the fact that the time period would be much shorter > would make changes between stable versions less drastic and therefore > easier to handle. How does this account for drastic changes to something like libc that might take weeks or months to shake out? -- Mike Stone pgpYZCckGUTEe.pgp Description: PGP signature
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
I'll believe it when I see a newly minted developer. It never should have been closed in the first place, so therefore I see the fact that it HAD to be opened as doubt-inspiring as to whether there will ever be a newly minted developer. Until I see a working new-developers mechanism, I see complaints about lack of manpower as rhetorical at best, hypocritical at worst. On Wed, 15 Mar 2000, Ben Collins wrote: > On Wed, Mar 15, 2000 at 03:24:29AM -0700, John Galt wrote: > > On Tue, 14 Mar 2000, Ben Collins wrote: > > > > > > > First of all, you need to check your numbers. Last I checked there were > > > ~350 official developers in the keyring. Right, so this proves my point in > > > that we should encourage developers to put a priority on frozen and the > > > next release cycle. And please stop refering to stable. That is not my > > > main concern here, and I never brought it into this conversation. > > > > No, that means you should OPEN NEW-DEVELOPERS! Jesus! On the one > > hand I hear all of these complaints about not having enough help and the > > other hand is flipping a big 'ol bird at anyone who's offering to help. > > The only way I see new manpower being added to Debian ATM is cloning, and > > I'm kind of hoping nobody in Debian qualifies as sheep or pigs. > > > > New Maintainer is OPEN. They posted a call for applications from currently > sponsored developers last week. This means that people who are currently > helping via the sponorship program are going to get in quite quickly. > IMNHO, this is exactly the right thing to do. People who have shown that > they are willing to contribute, even if it means waiting, have shown they > have what it takes to become a developer. > > -- > ---===-=-==-=---==-=-- > / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ > ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' > `---=--===-=-=-=-===-==---=--=---' > Sacred cows make the best burgers Who is John Galt? [EMAIL PROTECTED], that's who!!!
Re: A "progressive" distribution
On Wed, Mar 15, 2000 at 14:12:49 -0500, Jacob Kuntz wrote: > try this hypothetical release method out: > > there are two trees. let's call them devel and production. debian saavy > folks (maintainers) run devel. new packages are uploaded to devel where > they are tested extensivly. when a package has been in devel for more than > (for instance) two weeks, and it has no release critical and few important > bugs, it graduates into production. > > the production branch should always work. But it won't. This approach ignores the fact that "stability" is a property of a release as a whole (the set of packages and their interdependencies, ISOs, boot floppies and the upgrade path from the previous release) rather than the sum of the stability of individual packages. Ray -- ART A friend of mine in Tulsa, Okla., when I was about eleven years old. I'd be interested to hear from him. There are so many pseudos around taking his name in vain. - The Hipcrime Vocab by Chad C. Mulligan
Re: A "progressive" distribution
On Wed, 15 Mar 2000, J.H.M. Dassen (Ray) wrote: > But it won't. This approach ignores the fact that "stability" is a property > of a release as a whole (the set of packages and their interdependencies, > ISOs, boot floppies and the upgrade path from the previous release) rather > than the sum of the stability of individual packages. > A possibly naive question: apt-get will refuse to install packages if their dependencies aren't met. Why can't dinstall do the same? It would put any newly uploaded package in a waiting queue until all its dependencies were met. It wouldn't help with out and out buggy programs but at least it would catch dependency problems. -- Jaldhar H. Vyas <[EMAIL PROTECTED]>
Re: A "progressive" distribution
> On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote: > > The problem that I see is that there is too much time between stable > > releases. I think that shorter and much more regular time periods > > between freezes is necessary. By fixing the number and date of freezes, > > with say three or four a year, and letting everyone know long in advance > > of the freeze it would allow developers to schedule when all bugs must > > be removed by. Also the fact that the time period would be much shorter > > would make changes between stable versions less drastic and therefore > > easier to handle. > > How does this account for drastic changes to something like libc that > might take weeks or months to shake out? Well say that there are 3 releases a year. That gives say 3 months for devel. With a freeze scheduled to start at the beginning of the 4th month and a stable release at the end of a month of freeze. I think that even the most drastic changes can be worked out in the course of 4 months. Now if something _can't_ be completed in that time frame just postpone it until the next freeze. Since the next stable would only be 4 months off the penalty for not making it into the stable isn't that severe. With only the 3 months of changes I don't think that a freeze will take as long as it has with a 6 or even 12 month devel cycle. Ed
Re: A "progressive" distribution
On Wed, Mar 15, 2000 at 03:06:57PM -0500, Jaldhar H. Vyas wrote: > On Wed, 15 Mar 2000, J.H.M. Dassen (Ray) wrote: > > > But it won't. This approach ignores the fact that "stability" is a property > > of a release as a whole (the set of packages and their interdependencies, > > ISOs, boot floppies and the upgrade path from the previous release) rather > > than the sum of the stability of individual packages. > > A possibly naive question: apt-get will refuse to install packages if > their dependencies aren't met. Why can't dinstall do the same? It would > put any newly uploaded package in a waiting queue until all its > dependencies were met. It wouldn't help with out and out buggy programs > but at least it would catch dependency problems. Yes, such a queue was part of the "incremental release process" proposal (which people then told me shouldn't have been proposed, and is now being more-or-less implemented by someone with no developer feedback at all). It's not hard to implement. Search the archives for the proposal if you want details. []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the personal page Debian GNU/Linux---http://www.debian.org Brazil of Darkness--- http://zope.gf.com.br/BroDar
Re: realplayer installer and frozen
On Wed, Mar 15, 2000 at 01:00:59AM -0500, Alex Yukhimets wrote: > On Tue, Mar 14, 2000 at 07:09:31PM -0800, Joey Hess wrote: > > Lars Wirzenius wrote: > > > I agree with Branden: remove the installer from potato. > > > > The problem that I forgot to mention is that anyone who upgrades from slink > > to potato w/o upgrading realplayer, and had realplayer installed via the > > installer in slink, is going to find that the old realplayer they have > > installed realplayer no longer works. Library incompatabilities of some > > kind cause it to crash. > > I would definitely put new realplayer installer package in potato. > At least this would be a big favor to our users. I tried the woody installer on a potato system. It installed realplayer, but it doesn't seem to work. No messages or core dump--nothing happens. I also tried installing the tarball and installing the .deb created by running alien on the .rpm, with the same results, so it would appear that the installer is not the problem. On the other hand, the old realplayer worked just fine for me in potato. Unfortunately there does not appear to be any way to get it back. -- Bob Nielsen, N7XY (RN2)[EMAIL PROTECTED] Tucson, AZ DM42nh QRP-L #1985 SOC #77http://www.primenet.com/~nielsen
Re: A "progressive" distribution
On Wed, 15 Mar 2000, Ed Szynaka wrote: > > > The problem that I see is that there is too much time between stable > > > releases. I think that shorter and much more regular time periods > > > between freezes is necessary. By fixing the number and date of freezes, > > > with say three or four a year, and letting everyone know long in advance > > > of the freeze it would allow developers to schedule when all bugs must > > > be removed by. Also the fact that the time period would be much shorter > > > would make changes between stable versions less drastic and therefore > > > easier to handle. > > > > How does this account for drastic changes to something like libc that > > might take weeks or months to shake out? > Build daemons could take care of the 90% or so of packages that would just need a recompile. -- Jaldhar H. Vyas <[EMAIL PROTECTED]>
Re: A "progressive" distribution
On Wed, Mar 15, 2000 at 03:17:09PM -0500, Ed Szynaka wrote: > > On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote: > > How does this account for drastic changes to something like libc that > > might take weeks or months to shake out? > > Well say that there are 3 releases a year. That gives say 3 months for > devel. With a freeze scheduled to start at the beginning of the 4th > month and a stable release at the end of a month of freeze. I think > that even the most drastic changes can be worked out in the course of 4 > months. That assumes that the change is made at the beginning of the devel period. That never seems to happen. People *always* hold something until just before the freeze. > Now if something _can't_ be completed in that time frame just > postpone it until the next freeze. Once it's in, it seems to be really hard to remove/postpone it. If we change that, then releases will fall into place without discussions of arbitrary time cycles. If we don't change that, then the short cycles are no more enforcable than what we have now. Drawing up new plans without addressing the cultural issues behind this are a waste of time. (Does anyone remember pushing back the freeze because people wouldn't be able to work on it over the holidays? Does that seem like a good idea in hindsight?) -- Mike Stone pgpOCadJgU7k9.pgp Description: PGP signature
Re: A "progressive" distribution
On Wed, Mar 15, 2000 at 15:06:57 -0500, Jaldhar H. Vyas wrote: > A possibly naive question: apt-get will refuse to install packages if > their dependencies aren't met. Why can't dinstall do the same? It could do so. > It wouldn't help with out and out buggy programs but at least it would > catch dependency problems. It would catch problems with the dependencies a package declares. But it's no substitite for integration testing, part of which checks that the declared dependencies of a package accurately reflect the real dependencies. Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan
Re: A "progressive" distribution
On Wed, Mar 15, 2000 at 03:27:18PM -0500, Jaldhar H. Vyas wrote: > On Wed, 15 Mar 2000, Ed Szynaka wrote: > > > How does this account for drastic changes to something like libc that > > > might take weeks or months to shake out? > > Build daemons could take care of the 90% or so of packages that would just > need a recompile. That ignores the arguments over what needs to be recompiled, the time needed to discover problems, the time needed to make the compilations work, etc. Build daemons are not omnipotent. (Otherwise they'd be build deities...I digress.) -- Mike Stone pgpMr9JqgopLQ.pgp Description: PGP signature
Re: realplayer installer and frozen
On Tue, Mar 14, 2000 at 07:09:31PM -0800, Joey Hess wrote: > Lars Wirzenius wrote: > > I agree with Branden: remove the installer from potato. > > The problem that I forgot to mention is that anyone who upgrades from slink > to potato w/o upgrading realplayer, and had realplayer installed via the > installer in slink, is going to find that the old realplayer they have > installed realplayer no longer works. Library incompatabilities of some > kind cause it to crash. I see an empty package which uninstalls the previous version with a Cool, Blue debconf dialog: "Hey, blame Real!" here. Of course, a preinstallation dialog like "This crap is unsupported by Debian now. If you want it, paste this url on your wget.\nOr you can keep it and play with the funny segfaults." Is this ok? -- Jordi Mallach Pérez || [EMAIL PROTECTED] || Rediscovering Freedom, ka Oskuro in RL-MUD || [EMAIL PROTECTED]|| Using Debian GNU/Linux http://sindominio.net GnuPG public information: pub 1024D/917A225E telnet pusa.uv.es 23 73ED 4244 FD43 5886 20AC 2644 2584 94BA 917A 225E pgpwjz32blXxA.pgp Description: PGP signature
Re: Permission policy
hi, > The program needs rx-permissions for a device belonging to the > cdrom group and rw-permissions for a device belonging to the > audio group. > > Any ideas? users using your program and thus being able to access the sound / cdrom hardware should be in the cdrom+audio group for themself its not your programs task to gain access, it should already be provided by the calling process. you could print a message that the user should ask the sysadmin to add them to these groups if your open-call fails. -- CU, / Friedrich-Alexander University Erlangen, Germany Martin Waitz// [Tali on IRCnet] [tali.home.pages.de] _ __/// - - - - - - - - - - - - - - - - - - - - /// dies ist eine manuell generierte mail, sie beinhaltet// tippfehler und ist auch ohne grossbuchstaben gueltig. / pgpR8ukc7ZwKx.pgp Description: PGP signature
Re: Bug#58174
Le 2000-03-14 17:57:30 +0100, Michael Meskes écrivait : > This bug is listed as important bug against metamail. I do wonder though if > it is important enough to warrant a removal. This bug has been reported > against mime-support originally. Since no bug in mime-support was found it > was re-assigned to metamail. The bug log says: > > I've looked at the mailcap file and can't find any reason there why > there would be a problem. My guess is that it's metamail, but I > don't know why. > > So this does not exactly mean that there is an important bug in metamail. > And then there's the following report: > > I wasn't able to reproduce this bug. Both the slink and potato > versions of mime-support and metamail worked fine: > ... > > I don't think bugs like this should slow down our release cycle at all. IMO > this bug should be downgraded to normal. > > Comments anyone? I filed this bug report. And I probably shall be punished for it :-) This is probably the worst one I ever did ! There is no bug. I simply forgot the "-b" option in metamail... metamail was trying to get a header and not finding it. This bug report should be closed, and (hopefully) forgotten as soon as it can be. Sorry. -- Jean-Philippe Guérard
Re: A "progressive" distribution
On Wed, Mar 15, 2000 at 03:17:09PM -0500, Ed Szynaka wrote: > Well say that there are 3 releases a year. That gives say 3 months for > devel. With a freeze scheduled to start at the beginning of the 4th > month and a stable release at the end of a month of freeze. I think > that even the most drastic changes can be worked out in the course of 4 > months. Now if something _can't_ be completed in that time frame just > postpone it until the next freeze. Since the next stable would only be > 4 months off the penalty for not making it into the stable isn't that > severe. I hate to be overly harsh, but you I haven't seen around much before this thread. As such, I'm going to assume that you haven't been around very long as far as following this list. Anybody who has been around awhile can tell you that people just like you (and even a large segment of the existing developer base) says every single release that we need to freeze sooner and release more often---however pools will only complicate things and make it harder. Well uh, here's where the above "you don't know what you're talking about yet because you're still new" angle comes in... We've tried it. We tried it with hamm, slink, and now with potato. Freeze as soon as someone thinks it can be released in a few weeks DOES NOT mean it can be done in a few weeks. Freeze early doesn't mean a sooner release, it just means a more stale release faster. The pool solution is more complex. It requires that we constantly maintain two trees, plus a pool of unstable packages that just never really get released as a whole. A package does not become a release candidate until it's ready to become so. Sure that means more overhead on a package to determine whether or not it is going to be released. It also makes it harder for Debian to ship with every single piece of free software that doesn't guaranteed pull the system down to its knees. It also means per developerer there is more time required to maintain ones packages properly (though I would argue that unless your name is Joey Hess the extra time required is not terribly significant.) What does this gain us though? For all these disadvantages, what's it really worth? A distribution that is maintained in the near-release state that we CAN simply release any time we feel it is necessary. It's also easier to update than the current system which involves releasing security revisions to stable. Not only this but it is easier to make upgrades because they would happen more often and be more upgrade than the current complete new OS scenerio. We're running out of options because freeze early doesn't work. The other two options are the dist and a half (which was done for slink by Joey Hess and Shaleh.) As it turns out, the pools system allows us to have more of a real upgrade. The dist and a half system allows us to have a more focused upgrade. Which is more beneficial to our users? Both can be done in a matter of a couple of weeks. Both are actual versioned releases. The pools have more overhead, but they provide a real upgrade rather than just the dist with a few big notables like kernel, X, and Apache. IMO, dist and a half is mostly fluff as far as press releases go. potato and a half would be a potato dist with a 2.4 kernel, possibly some new X stuff if it can be done and a new apache. It's still out of date potato otherwise. I want a REAL upgrade! > With only the 3 months of changes I don't think that a freeze will take > as long as it has with a 6 or even 12 month devel cycle. As I said, you haven't been around much yet have you? -- Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 First off - Quake is simply incredible. It lets you repeatedly kill your boss in the office without being arrested. :) -- Signal 11, in a slashdot comment
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
I am going to attempt to install Potato over a 28.8/56k modem. I have downloaded and 'burned' all 15 floppies needed for the basic system, and will install that first. Then I will set up PPP, and fire up dselect (apt method). I have already done this at work (but on a T1->lan->proxy setup). I expect that the process will take several 'over-night' runs. You don't need to download 650mb worth of stuff, I suspect that for a typical debian install < 100mb of 'stuff' actually is needed to be downloaded. There are a LOT of functionaly duplicate packages, little used packages, and source packages on the CD's that few people make use of. That's why many of the books can come with Debian on a single CD, they have prunned out the stuff that most people won't use leaving a still very functional representation of Debian. In my case my dialup connection is a local call (basicly free) and $19.95 a month (for up to something like 250hrs) for the isp. This is probably typical for the average US user, I realize that in Europe and elsewhere you are probably paying more. I am still waiting on GD Flashcom to get my IDSL connection working, I had hoped it would be up by the time Potato was frozen but I will try the modem method meantime. Others have told me that they installed Debian this way, so I will try it at least once. > >Steve Greenland wrote: > >> There is nothing stopping anyone from making >>snapshot releases of >> unstable. Mirror the archive. Burn a CD. Done. >>That's what a snapshot >> is. >As one of the many people who does not have cheap, >fast, reliable >internet access, I would like to say that for me to>>> >mirror 650 MB >of debian and burn a CD of it would cost around $130 >in charges >and 2 and a half days of straight downloading if I was >lucky. >Probably much longer. >So I'd like snapshots, but really I run stable run >until the >moment frozen becomes stable at which I can get a CD >on which >everything has a good chance of working, because if >anything >breaks I'm pretty much stuffed. - = Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: An advise how to apply for the TkMan author to change his license.
> On Wed, Mar 08, 2000 at 03:18:47AM +0200, Shaul Karl wrote: > > [22:42:00 src]$ tail -n 9 tkman-2.1b4/README-tkman > > > > Permission to use, copy, modify, and distribute this software and its > > documentation for documentation for any purpose, without fee, and > > without a written agreement is hereby granted. This software is > > provided on as "as is" basis, without any warranty whatsoever. > > "documentation for documentation for" looks like a classic typo > (where the typist loses track of what's been typed and types a > phrase twice). > > If that's the case it should be a trivial fix. > The situation is that I am trying to maintain TkMan while applying to be a debian maintainer. The new TkMan license is stated above. Yet as far as I understand this license is not enough for asking to get TkMan into main since TkMan depends on rman which is in non-free. It's been more then a week when I posted my message but "Stephen M. Moraco" <[EMAIL PROTECTED]>, the debian maintainer of rman did not reply me. Should I wait more? Should I email him my message again? Is that because I am not a debian maintainer? I am considering approaching the author again, this time about rman. I already approached him about TkMan and he seems to be most cooperative. Suppose I was a debian maintainer, is it ethical of me to approach the upstream author about a package that I do not maintain claiming that one of my motivations is the desire to put TkMan into debian's main pool? Are there any other reasons why I should not approach him? -- Shaul Karl [EMAIL PROTECTED] An elephant is a mouse with an operating system.
Re: A "progressive" distribution
On Wed, Mar 15, 2000 at 01:34:22PM -0500, Mark Mealman wrote: > > First things first. Let's get potato released, and then get pools and > > flavors implemented before we try to release woody. > > I'm all for that if you think the pools idea has any chance of being > implented in our lifetime. I recall reading that it was being prototyped on lully...but lully is currently waiting for some replacement hardware. craig -- craig sanders
