Re: first proposal for a new maintainer policy
Apologies are due for my not trimming the crossposting before; I meant to, but I forgot to. As I understand things, there should be no crossposting amongst the debian mailing lists. If I make further comment, therefore, I will be careful to trim the mail distribution to one of them only, and send a message like this one to let possibly interested others know where the thread went. I am making a comment; I'm choosing debian-policy as the list. See it there. -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: debian-keyring
In the message identified by <[EMAIL PROTECTED]>, Dale Scheetz <[EMAIL PROTECTED]> wrote: > Thank you. That was the point I was so poorly trying to make. No > denigration was intended (just a bit of jealousy at not having any spare > time myself) I'm not a developer, but I see how the debian IRC channel generally operates. I am there quite a bit, helping new people and sometimes reporting bugs & etc. If you haven't been there watching, you probably need to check your characterization of the folks there being there because they have, in your words, "spare time". Reason: it still smacks of your opinion that it isn't used to do real work, that the ONLY REASON why debian developers are there is to _use up_ their "spare time". Go there. Watch. Then express your opinion. Or don't (but if you choose this, then you have only your guesses to go on; no facts.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Thank you for signing the guestbook
Thank you for signing the guestbook! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please Improve Debian for Multimedia Production
Grammostola Rosea, Hi. I took the suggestion of one of the replies to your original post and read about debian pure blends, and at first I thought demudi was a pure blend; it's listed as one of the projects but is not actually a pure blend, which I guess means they might have updated apps and specifically compiled kernels to support various pro audio needs. I want also to direct your attention to the kernel, as it has the possibility to be more supportive of those specific needs, by having low latency and real-time extensions patched and enabled. The debian folks (especially "waldi" aka Bastien Blank will say some or all of these are less stable than they could be -- perhaps googling around or asking him when he's not so busy will drum up some details.) To the group, I'd like to see Demudi become a pure blend. What are the issues? On Fri, Mar 20, 2009 at 7:02 AM, Grammostola Rosea wrote: > Hi, > > Since a while I'm pretty active in using Debian/Linux for Multimedia > production, especially focusing on music production (check > www.linuxmusicians.com for instance). > > Debian is a great system to use for this. Unfortunately there are nice > music production applications which are not in Debian yet or are > pretty outdated (also those in unstable). It would be nice if we could > improve Debian for multimedia production and package more multimedia > packages and keep them up to date. > > For instance, I posted some apps which are not in Debian right now as wishes > (RFP): > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=rosea.grammost...@gmail.com > > (There is work on progress on Frescobaldi, Rumor (my first Debian package ;) > ) and Gtklick.) > > Of course we have the Debian Multimedia Team, which takes care of a lot of > multimedia packages for Debian. So if you like to help in this progress, the > best thing you could do imo is joining the Debian Multimedia Team: > > http://wiki.debian.org/DebianMultimedia > http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers > > Thanks in advance, > > \r > > > ps: I'm not an official member of the Debian Multimedia Team myself. I'm > just a musician which uses Debian now, but I think I'm gonna join the team > myself. I recently build my first Debian package :), so I'm almost ready to > join ;) > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: kernel 2.0.34 and hamm
[EMAIL PROTECTED] said: > I don't agree that we have to delay the release of hamm to have 2.0.34 > as a hamm package. I do :) Speaking purely as a user, I think the job should be done right. Speaking as a debian advocate, it would be highly embarrassing to try to explain something like "Oh yeah, the new kernel is there, but you can't use it yet since ..." where ... stems from the person's need for some dependant package. Example: say he needs pcmcia. So... if you're gonna put the kernel or the new gimp, do it right: compile whatever else needs those packages and do the testing. We all know debian hamm is relatively stable... but such a move would lose you folx who would otherwise use it. A kernel is just plain too important to cut corners as you suggest. -Jim who doesn't have a vote here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.0.34 and hamm
[EMAIL PROTECTED] said: > How is this different from bo, where we also had three kernel versions > available and only had pcmcia modules for the first two? No difference. And no improvement. :) -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: so what? Re: Debian development modem
[EMAIL PROTECTED] said: > We must decouple our development tracks much more. I propose that we > resolve never again to plan a release with is not fully backward > compatible with the current stable version. I like this idea most of the time... but there are times when you just have to make a clean break. Going between libc versions was one of those times, as was going from a.out to elf. Otherwise, what are major number changes for? Are you unhappy with the result (hamm)? I'm not... -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Base Set: Suggested additions & removals.
Hi all... another comment from the peanut gallery (i.e., non-voter) :) [EMAIL PROTECTED] said: > We _must_ have a vi (or at worst, vi clone) available in the base > system. Why? I think you see vi as I see gpm and they see mc: as an "essential convenience". Fact about VI: it has two modes which make the keys mean totally different things and don't announce themselves except thru the terminal bell. My opinion about this: (deleted; form your own :) Historical fact about VI: some people got really, really good at using it :) -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ircII is now free.
[EMAIL PROTECTED] said: > As far as being 'happy' about it.. well, it's nice that it's cleared > up, but.. I don't think we changed much other than some licensing > details. This software wasn't intended to be non-free... If > anything, I'm happy to put this behind me and get on with other > things. > I think it's more of an honest "victory" when something that isn't > free becomes free. You have a point... but I think victories should be taken when and as they can be got. You got it. Now take it. And congrats David :) -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Base Set: Suggested additions & removals.
> Raul Miller <[EMAIL PROTECTED]> writes: > > > Jim <[EMAIL PROTECTED]> wrote: > > > Why? I think you see vi as I see gpm and they see mc: as an "essential > > > convenience". > > > > vi has the advantage of being backward compatible into the early '80s. > > > > The only unix editors which vie with vi for standardness are ed (the > > unix standard), and emacs (backwards compatible into the early '70s). > ^ > Now _THAT'S_ a great idea... A boot disk with emacs... Hmmm... Size... > Darn... :) Yeah, that is too bad... Isn't ease of use more important than standardness when it comes to an editor to be used for a rescue situation? I think that I would try doing an alternative set of boot disks to see how folx liked them. Is it possible to make mc use vi? On the rescue disk, size is at least neck and neck with ease of use. What is it people see in vi in terms of _using_ it? My opinion FWIW is that vi's presentation rivals that of dselect in general, with vi inching dselect out for not forcing one to follow a set path without saying what that set path should be. So, why do the vi users like _using_ vi? (Someone already said "it's standard"... can I get real reasons now? :) -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Base Set: Suggested additions & removals.
[EMAIL PROTECTED] said: > The editor expert who cannot even break his lines at 80 characters .. So shoot me; I'm using exmh, which appears to wrap words and doesn't get around to actually inserting the carriage returns... And I'm no expert... I just wanna know what all the furor is over vi :) -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc problems with /usr/lib/crt1.o
[EMAIL PROTECTED] said: > I recently upgraded to the hamm distribution. Ever since the upgrade > I have not been able to compile anything with gcc. It seems part of your upgrade wasn't completed... you probably need to install libc6-dev. -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim really does need to be the standard MTA in slink
in the message IDed as <[EMAIL PROTECTED]>, Robert Woodcock <[EMAIL PROTECTED]> wrote this on Mon, 05 Oct 1998 20:31:24 PDT: > Yeah, I know this makes at least the second reincarnation of this thread in > the last 6 months, but I really think exim should be the standard MTA in > slink. (I am not a voter here.) Fine... but PLEASE don't make decisions that would make any of the other mailers unusable to any degree (that's for everyone else), -especially- sendmail (that's for me). -Jim
Re: KDE hurts Qt (was Re: LICENSES)
> Chris Waters <[EMAIL PROTECTED]> wrote: > > This is the really sad part about this whole mess. Qt is a nice > > library. Non-free, but not everything has to be free. But because of > > the refusal of the KDE developers to FIX THE KDE LICENSE PROBLEMS, a > > lot of people are being turned off of Qt! Qt doesn't deserve this, and > > I think the KDE team should: 1) fix their license problems, and 2) > > apologize to Trolltech. > > I think they should fix their license problems, but I do not think that an > apology is warranted. After all, the Qt license explicitly *encourages* > application developers to license their code with the GPL. And that's a good thing... but wil the GPL prevent distribution of binaries made linked to Qt, or object files compiled against Qt? If so, then is TrollTech implying falsehoods about the GPL? I.E., are they implying that people can distribute such binaries? Or, is it the KDE folx that are doing that implying? Or both? If TrollTech is saying that people can release GPLed code compiled/linked against Qt and this is not so and they are refusing to fix this, what is the reason for this? Are they trying to get free software and/or ideas that won't be permitted to be released in a normal way? How does this benefit them, if in any way at all? If it's KDE saying the same thing, then how do they benefit, if at all? If both, then how does the system containing both Qt and KDE benefit? If neither, why does the controversy exist? > If anybody should apologize, it's Trolltech. [If they choose.] Maybe... I'm having trouble keeping up with who should apologise to whom... I think KDE's use of Qt hurts KDE and also hurts the open source concept. Whether it hurts Qt is not relevent, IMO. However, because Qt is non-free, Qt also tends to harm free-software development. At one point, Bruce Perens suggested this harm is at the very core of linux. I don't agree with this because the very core of linux is the kernel and only the kernel. Outside of that, there are wayyy too many combinations of software packages that people use regularly and each, to whatever degree, has its following. So, I don't see this as one of the larger issues in the mass usage of linux and supporting entities as a whole. However, I do see that if linux were easier to install and configure, it would be in greater use. I also see that if linux had a common face, this could also increase usage. But I don't see linux getting a common face anytime soon, as each individual will continue to use those software packages they prefer. I think it boils down to this: everyone involved should read and understand the GPL (and the ORIGINAL INTENT thereof). Everyone who distributes software might need to consult a lawyer (especially KDE and Qt makers) to ensure that their use of the GPL is actually in their interest, and that they are using it correctly according to its letter and its original intent. Whoever is using the GPL in a way that conflicts with its terms should stop immediately and correct the situation. Without further study into the situation, I can't tell who is or is not doing so. -Jim
Re: LICENSES [was: Re: Have you seen this?]
> > In my opinion, Qt is not a section of KDE, it is not derived from the > > KDE and it must be considered independent and separate from the KDE. > > In other words: The KDE's usage of the GPL does not cause the GPL, and > > its terms, to apply to Qt. > > Indeed Qt is not part of the problem indeed > > But when you distribute the same sections as part of a > > whole which is a work based on the Program, the distribution of > > the whole must be on the terms of this License, whose permissions > > for other licensees extend to the entire whole, and thus to each > > and every part regardless of who wrote it. > > > > Qt is not distributed as part of KDE. It is distributed as part of > > various distributions that also include the KDE, but only by "mere > > aggregation [...] on a volume of a storage or distribution medium" > > which the GPL okays elsewhere in the text. > > It is not a mere aggregation. If I remove Qt KDE is unusable. I note here, a point that most ppl probably know: It is certainly not the fault of the Qt ppl that KDE would be unusable without Qt's presence. Qt is not owned by the KDE ppl, so Qt folx should not be affected by KDE's decision to use KDE. If, on the other hand, Qt decides to say that they "like" (whatever that means, and in whatever form it comes) KDE's use of Qt, then at that point, they are possibly in it together. For example, if Qt does anything to facilitate KDE's success in its present (with-Qt) state, then I would take on the opinion that they are both in the situation together, and responsible for the results thereof. (Like my opinion means anything :) > KDE requires Qt currently. So KDE is non free. _No_. This does not necessarily follow, even if both statements may both be true. KDE simply depends on something that is non-free. If KDE itself can be (1) obtained in source, (2) altered and then (3) redistributed in its altered form and (4) have all these with the only restriction being that further restriction cannot be applied, it is free. If it presently depends on something that is non-free, we know the drill: the source is available. Therefore, anyone can fix it. > Similarly Linus does not distribute KDE with the kernel so its not in > the base distribution. I see your point here as "KDE does not come with the linux os (that being the kernel) therefore the clause in the GPL, making an exception for a piece of software included with an OS, does not apply." I would agree, however we should watch this MicroSoft lawsuit carefully: it might redefine what can be considered part of an OS. (Of course, it won't change what Linus distributes.) I would make the same observation about Qt: Linus doesn't distribute Qt with the kernel either. So KDE would have a reason to not assume the exception in the GPL wrt Qt. > On Solaris KDE is shipped even though no Sun > product includes Qt. So the case there is even more blatant Could you elaborate a bit here, if only addressing the elaboration to me? why is this more blatent? -Jim
Re: LICENSES [was: Re: Have you seen this?]
> > However, the license for that derived work (I'll call it A) claims > > that the whole of A must be GPL'd. However, Qt is not part of A (the > > GPL says "section of"). Qt provides services to A, and A depends on > > those services: A very different thing. > > Qt is part of the derived work. It is linked to it and the work A does not > function without it. It is also not a public API and your message to Preston > concerning possible legal action against harmony makes it clear you regard > the item as actively protected IPR not an open API I understood the meaning of "is derived from" to be "using the source code to make a derivative of" as opposed to "using the services of". If I use libc, I don't think I am creating a libc. Unless I am, I'm not deriving, I think. If I use libc, I simply use the services. Hence, libc is "a section of" the thing I am making, and does not derive from it. How is this wrong? Is it "strategic" to look at sections as derivations? -Jim
Re: LICENSES [was: Re: Have you seen this?]
> > If I use libc, I don't think I am creating a libc. Unless I am, I'm not > > deriving, I think. If I use libc, I simply use the services. Hence, libc > > is "a section of" the thing I am making, and does not derive from it. > > Your program derives from libc by being linked with it. This is precisely > why an LGPL has to exist. So this isn't "derivative" in the sense of the OOP idiom "IS-A"... and you're saying that all I have to do to "derive from" something, is to include it unmodified or modified? -Jim
Here's my .xsession (was Re: User-selected window-manager in an easy way)
Here's my .xsession... it assumes the window manager is not the session controller, and something else is (but that can be changed pretty easily) --- file: .xsession --- #!/bin/bash # # logout button .xsession allowing fav window mgr by Jim Lynch # # This .xsession prepares for gnome by having something other than # the window mgr be in the foreground, such as a logout button. # # As always, when the foreground process goes away, the session ends. # This is true whether the fore is a wm, a logout-button or a session # manager separate from the wm. # # This .xsession has logout-button be the foreground process. Pushing the # logout button causes the logout button process to end, which implies # the .xsession foreground process ends, which ends the session. # # This .xsession will also launch xearth and an xterm. # Now find a window manager... we want one that's installed... run it... # start by assuming that before we start looking, we haven't found anything foundWM=false echo "1 $foundWM" # Favorite window manager # set this to your favorite WM, or to nothing if you're willing to accept # whatever comes myWM=fvwm2 if [ "$foundWM" = "false" ] then favWM=`grep $myWM /etc/X11/window-managers | head -1` aWM=`echo $favWM | sed 's/#.*//'` if [ -x "$aWM" ] then theWM=$aWM foundWM=true fi fi echo "2 $foundWM" if [ "$foundWM" = "false" ] then if [ -e /etc/X11/window-managers ] then for i in `sed 's/#.*//' /etc/X11/window-managers` do if [ -x $i ] then theWM=$i foundWM=true break fi done fi fi echo "3 $foundWM" # still didn't find a wm?? OK, twm isn't the best, but we'll settle if [ "$foundWM" = "false" ] then theWM=twm foundWM=true fi echo "4 $foundWM" # launch the selected or otherwise found window manager in the background. $theWM & # launch xearth and an xterm. xearth & #xfishtank & #xterm -ls & # launch the session-controlling process. If it dies, so does the session. #exec logout-button exec gnome-session # end of .xsession # Here's the original .xsession # #!/bin/bash # # # NOTE: this part taken from the else part of the final "if" # # in the global /etc/X11/Xsession by [EMAIL PROTECTED] # # # # i.e., look at this code as the default behavior and # # modify to taste # # xterm -ls & # if [ -e /etc/X11/window-managers ]; then # for i in `sed 's/#.*//' /etc/X11/window-managers`; do # if [ -x $i ]; then # exec $i # fi # done # fi # exec twm ---
Here's a diff to my .xsession (was Re: Here's my .xsession)
Hi, already found a problem: comment lines in /etc/X11/window-managers that match the chosen favorite window manager cause the script to fail weirdly... Problem reported by [EMAIL PROTECTED] this patch filters comment lines first. (Note to Branden: you might want to use this logic, or something like it, in the global Xsession.) This also removes the debug echos that show which stanza finds the wm. --- --- xs Tue May 11 07:09:53 1999 +++ .xsession Tue May 11 07:42:03 1999 @@ -21,28 +21,26 @@ # start by assuming that before we start looking, we haven't found anything foundWM=false -echo "1 $foundWM" - # Favorite window manager # set this to your favorite WM, or to nothing if you're willing to accept # whatever comes myWM=fvwm2 +# try to find my favorite wm if [ "$foundWM" = "false" ] then -favWM=`grep $myWM /etc/X11/window-managers | head -1` -aWM=`echo $favWM | sed 's/#.*//'` +tmpWM=`grep -v "^#" /etc/X11/window-managers | sed 's/#.*//'` +favWM=`echo $tmpWM | grep $myWM | head -1` if [ -x "$aWM" ] then - theWM=$aWM + theWM=$favWM foundWM=true fi fi -echo "2 $foundWM" - +# try to find ANY wm (the first one found to be executable) if [ "$foundWM" = "false" ] then if [ -e /etc/X11/window-managers ] @@ -59,8 +57,6 @@ fi fi -echo "3 $foundWM" - # still didn't find a wm?? OK, twm isn't the best, but we'll settle if [ "$foundWM" = "false" ] @@ -69,20 +65,19 @@ foundWM=true fi -echo "4 $foundWM" - # launch the selected or otherwise found window manager in the background. +# !!note!! the window manager is NOT the foreground process because it is +# NOT the session controller (as would be the traditional case). $theWM & -# launch xearth and an xterm. xearth & #xfishtank & #xterm -ls & # launch the session-controlling process. If it dies, so does the session. -#exec logout-button +#exec logout-button # anyone wanna a logout button? send me mail :) exec gnome-session # end of .xsession @@ -94,7 +89,7 @@ # # NOTE: this part taken from the else part of the final "if" # # in the global /etc/X11/Xsession by [EMAIL PROTECTED] # # -# # i.e., look at this code as the default behavior and +# # i.e., look at this code as the default session behavior and # # modify to taste # # xterm -ls & --- -Jim
jdk not working in potato, working jdk removed from incoming, license problem
Hi I am given to understand that someone has found a problem in the license of jdk, to the point that same person finds that debian cannot distribute the jdk at all. I was told that the problem found in the license has existed for a long time. If this is the case, WHY is a jdk that doesn't even work in potato? By precisely the same token, why is there a jdk in ANY debian dist?? Is there a difference in the license between versions? Has anyone talked to Sun? If this is NOT the case, Can this be resolved quickly please? I would imagine that it is the intent of Sun that Java in its pure form would make it big. I have a few java projects that I'm taking off the back burner presently, and now this. Inquiring, jdk-using minds want to know. -Jim
First post as maintainer :) (about 2-3 screenfuls)
Hi... First off Glad to be here; thanks for accepting my app I'd like to maintain maybe 1 or 2 easy packages, pwgen comes to mind (Hi Vincent :) Also, I have some stuff I wrote that's unpackaged I'd like to package eventually, but I'm not so sure they'd be easy... Let me try to drum up some interest in them with a short description of the most important one (I need other help on them, they have internal documentation, but I'd like to add some more user docs) "Roster" is a set of perl scripts that take a a file previously downloaded from a school district Admissions and Records database, converts it to a copyrighted/GPLed file format and then merged into another copyrighted/ GPLed file format. Once there, student accounts can be added to arbitrary numbers of arbitrary kinds of servers. Master departmental lists as well as individual class lists are generated in two forms (printable, tab-delimited) are mailed out to teachers. The scripts handle midterm adds and drops. Anyone can get the scripts at http://www.laney.edu/pub/jim/roster/ and there are a few things in /pub/jim other than roster iirc. When the foreign database is processed, a login name is assigned by a process which can be changed by someone with a reasonable knowledge of perl; when a new student is merged in, a password is assigned by a similar process. The perl subroutines defining these processes are in their own file and can be arbitrarily altered in order to implement any needed naming or password conventions. I am in the process of OOPizing the scripts, and have done the following abstractions: Roster::Entry records are those to be merged into the main database, whose type is Roster::People::User. A Roster::Server is a go- between class that hides the kind of server (Roster::ServerType) to allow generic treatment of the servers to which students are added. Present server types supported are in Roster::ServerTypes: NT, UnixNewusers, Novell3xx, and presently working on UnixBSDIAdduser and Novell4xx. Each server type is a single perl module file, so new server types are easily added. Once a server type is known, you add one line to an auxilliary database and run the mk-logins.perl script and go add the accts. I'm planning on adding other abstractions (such as Teacher, StaffPerson, Admin, etc.) as they become needed and useful. I admin the internet at Laney College, an Oakland, California community college which is a part of Peralta Colleges, a four-campus college district. These scripts were written by me to support adding accounts to the servers at the Laney CIS computer lab. (I volunteer there, so the scripts are mine.) The roster scripts have been in use for approximately 6-8 semesters (incl. summer session) and have been quite stable since the start. Problems that came up were solved by a quick script. I'm looking to let more schools use this project, both in and out of the Peralta district. Presently, two labs within the district use them. I would like some help, especially in the area of documentation and new server types (I presently need help with Novell4's uimport command) and would like to have a man page for each script as well as one for each file format in the database. Questions welcome, and I note that maybe 20-25 man pages need to be created to give you an idea of the volume. The latest TODO list refer to this need only fleetingly, the next version thereof will make each man page needed explicit. -Jim
Re: Linux Core Consortium
Bruce,
The history there is much more complex that that; you are
oversimplifying. In fact, with my perspective, the failure occurred
before that, but (un)intended consequences of the Consortium agreement,
which disenfranchised the flourishing community we had built. Pay for
say, and centralized development teams funded by such payers, are a
major trap.
Equally important, however, was that UNIX went to the high end, where
there was profit to be made in the short term (but no volume), and M$
went to the low end, where there was volume, and eventual major profit.
That being said, certainly UNIX's disunity was a major aid to Microsoft.
Repeating that history would not be good.
- Jim
On Thu, 2004-12-09 at 10:53 -0800, Bruce Perens wrote:
> William Ballard wrote:
>
> >What makes you think you'll be any more successful than when the Unix
> >Consortium tried to do the same thing for Unix?
> >
> >
> The members considered that they had proprietary value at the level at
> which they were collaborating. We conclusively do not, because of the
> Open Source nature of the software.
>
> About the worst occurrance in the entire saga was the day that the X
> Consortium got together and decided that there would be no canonical X
> widget set, so that they could all differentiate from each other at that
> level. So, everyone had to turn to Microsoft to provide a canonical
> widget set on top of other manufacturer's hardware, and MS ate the X
> consortium's lunch.
>
> Thanks
>
> Bruce
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote: > On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: > > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > > > But a total of eleven is insane. > > > > It is sometimes hard to get them all to work, yes. > > > > It also vastly increases the quality of the Free Software in our > > archive, as we discover bugs that appear only on one architecture. > > That's an overstatement. Simply having two architectures (i386 and ppc) > would be enough to reveal nearly all portability bugs. > Actually, my long experience is that it takes more than 2; but at, say, 4 systems (both byte orders, both 32 and 64 bits) you get most of them. More important at that point is getting better compiler coverage; gcc and friends is *not* the only compiler suite in the world, and different compilers uncover a different spectrum of bugs. - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, 2005-02-21 at 16:12 -0800, Brian Nelson wrote: > Yeah, definitely. If our goal is making our software as portable and > bug-free as possible, we'd be better off running fewer arches but with a > greater variety of compilers. > > Now if there were only any viable free alternatives to GCC... > Well, in the goal of better software, I'm willing to use closed source compilers. I like finding bugs that way, *before* getting bug reports... And yes, the ARM compiler has some *strange* defaults... Whomever picked their defaults didn't do ARM favors, even if it if they might be conformant to the C standard.... - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I/O hardware, control of external transistors
Hiya, I'm with a team building custom PC 104 form factor, low power computers for remote locations. The CPU is Pentium II class, the OS is Debian Linux. We want software control over three different transistors (screwed to the inside of the case). We're having trouble figuring out what features (in the kernel, or device drivers, or external commands, or some package for some language such as perl or python or some C libraries...) give us control over logic levels of pins, and which pins (serial RS-232, parallel, what?). Anybody got experience with this stuff? jim [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is xprint still used by mozilla, etc?
Note that while my opinion matches Keith Packard's (we'd like to see
xprint go away, but there are also dependencies on it), Roland Maintz
has done much work to improve its behavior in the recent X.org X
releases. Of course, Debian is still stuck in the past, while pretty
much the rest of the world is on X.org
Note that Motif applications in general are likely to have dependencies
on xprint into the indefinite future. While these are not important in
open source at this date, they are very important in commercial settings
converting to use Linux from UNIX.
- Jim
On Fri, 2005-03-11 at 13:20 +0100, Norbert Preining wrote:
> On Fre, 11 MÃr 2005, Drew Parsons wrote:
> > Xprint works perfectly fine out of the box.
>
> There are several bug reports, some of them I have contributed to, but I
> guess some of them are filed against mozilla and not xprint, which in
> fact was an error:
> 263558
> and then there are some more problems about using Comic Sans instead of
> any reasonable sans font.
> and and and.
>
> So "out of the box" is an euphemism!
>
> Best wishes
>
> Norbert
>
> ---
> Norbert Preining Università di
> Siena
> sip:[EMAIL PROTECTED] +43 (0) 59966-690018
> gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5
> B094
> ---
> GASTARD (n.)
> Useful specially new-coined word for an illegitimate child (in order
> to distinguish it from someone who merely carves you up on the
> motorway, etc.)
> --- Douglas Adams, The Meaning of Liff
>
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 4GB address space
On 02/28/06 04:19:45PM +0100, Mad Props wrote: > Hi, > > i'm interested in whether it is possible to modify the Linux kernel so that > user applications can use the whole 4GB of virtual address space while the > kernel runs it's own AS. > > If yes, how complicated would that be ?? > > Thanks, > > Thomas Yes it's possible and there have been patches posted on lkml that do that, but it incurrs a performance hit and it's usually easier just to get a 64-bit machine these days. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cvs.debian.org [Was: Using CVS for package development]
> We are running cvs.debian.org over an ISDN line. Currently the only > code under it is the Deity project. > > I can make other source trees and set up other users if others want to > do distributed development this way. > > Unfortunately, I haven't been able to set up "world read access" yet > because CVS always wants write access to the directory (for lock files) > so currently it is either group read/write or world read/write. What about cvsup? All I know about it is that the FreeBSD use it to distribute their sources... It would be nice to be able to have an automated procedure to make any package in the Debian source tree available via CVS so that a group of people could work on it simultaneously. (no hurry though, just an idea) Another idea... is "coda" (an afs/nfs replacement from Carnegie-Mellon) a possibility for building a really large filesystem spread across multiple machines on the internet? Cheers, - Jim pgpMQEQVTH2mA.pgp Description: PGP signature
Re: long list of give away or orphaned packages
> Im not dissing your work, its excellent ;) Just hoping things can be a > little more open... It seems like its getting to be an old boys club. > You guys are pretty mature compared to the IRC channels, but it seems that > already the administration is top heavy, taking away a lot of coding/devel > time. I think that's just because we're close to making a release. We'll probably all loosen up again when we're doing 100% development. :-) There's been remarkably little discussion going on in debian-private (ie. behind closed doors), so I would say we're becoming more open, if anything. Cheers, - Jim pgpBrK60v79CD.pgp Description: PGP signature
Re: default file perms
dpkg-cert already does something like this. Klee is going to fold the capabilities of dpkg-cert into dpkg, so I think a solution is on the horizon. :-) We just have to wait patiently for Klee and his upcoming proposal to overhaul dpkg. Cheers, - Jim pgpD2sxtAmlaW.pgp Description: PGP signature
Re: Using CVS for package development
> Andreas Jellinghaus <[EMAIL PROTECTED]> writes: > > > great. since i meet other debian developers at the linux congress, i my > > a big friend of a cvs server with all debian packages. does anyone have > > a server with enough hard disks and a good conection to run it ? > > Some problems arise: > > Should this CVS repository be mandatory, i.e. does every Debian > package have to be there? Definitely not - that would be a waste. Most packages are pretty simple, so having a shared CVS isn't all that useful for those packages. But it might be nice to be able to add an arbitrary package to the repository via a CGI script or something like that. Cheers, - Jim pgp2C2rx4h4bm.pgp Description: PGP signature
Re: Possible bug in dpkg-source? Possible fix?
> I'm using dpkg-dev 1.4.0.17. The problem is that not just with > source packages I create. It is with all source packages I'm > downloading, e.g., hello. > > The type of error I'm getting is as follows: > > dpkg-source: failure: remove patch backup file > hello-1.3/debian/substvars.dpkg-orig: No such file or directory [ Excellent and absolutely correct analysis snipped ] This has been fixed already in 1.4.0.18 (in Incoming) which has been there for a few days. I got burned by that one too. Cheers, -Jim pgpHX6kgJ8c2Y.pgp Description: PGP signature
Re: FreeQt ?
> As for OSS -- I had the impression that if I submitted patches to make > the modules *accept* command line arguments, they wouldn't be > included. But yeah, if they're straight GPL'ed that's good enough; I > could still distribute such patches even if they weren't included. > (and actually, everything in the *kernel* sources looks fine; I think > I was probably interpreting stuff that I saw on the usslite website. > So strictly speaking we're back to *one* bad example, which is QT...) And then there's Cygnus, and cygwin32.dll - which is under the GPL, not the LPGL... (sorry for the cheap shot) Cheers, - Jim pgpKccdk9pWdC.pgp Description: PGP signature
cygwin.dll license (was Re: FreeQt ?)
> yeah, cygwin32.dll is under the GPL. So? It's a DLL, like libc5 and > libc6 are... [the *only* thing I'm aware of that actually uses the > LGPL is libg++; it was as much of an experiment as anything, and I'm > not aware of any not-otherwise-free software taking advantage of those > terms...] Just because libgcc is on "special" terms is no reason for > cygwin32.dll to be (cygwin32 is *more* than even a libc, it's got a > fair amount of emulation code in it, so it looks like you have unified > file descriptors... and you don't want to look at the internals of > select...] I just brought this up, since it was my understanding that if you want to write a commercial program (ie. not under the GPL), and link it against cygwin.dll, you've got to pay Cygnus $$$. Not all that different than the restrictions on Qt, really. I don't think this situation exists with libc5 or libc6 (ie. Netscape and Sun's JDK are linked against it). I'm not familiar with the licenses on everything though -- I hate reading the fine print. If I'm wrong on this issue (I hope I am), please correct me. Cheers, - Jim pgpLjYTjNzXwK.pgp Description: PGP signature
Re: cygwin.dll license (was Re: FreeQt ?)
> Two questions: (1) in what way is cygwin32.dll different from libc5.so > in this regard (since the license for both is the same: GPL) libc5 appears to be under the GPL, while libc6 appears to be under the LGPL. Weird. Does that mean that anything that is linked against libc5 has to be GPL'd? I'm surprised I haven't heard more about this - I obviously don't know the whole story. Maybe there is just widespread abuse of the GPL. If everyone is just ignoring it, that doesn't provide much legal protection for Cygnus if they're trying to make money off of cygwin.dll. > (2) the discussion wasn't writing *comercial* software with > anything, but writing *free* software with a pseudo-free package like > Qt... so how did we get here? There's *certainly* no problem writing > gpl'ed software with cygwin32.dll :-) There's not really any problem writing *free* software with Qt either. That's why I deliberately confused them together... Free software shouldn't be about confusion. > ps. A friend of mine with whom I've been discussing this says that > if we took all the time we've spent flaming about this and actually > *wrote some code* we wouldn't have the problem in the first place :-) I am working with cygwin.dll right now actually, trying to get dpkg to port to it (well, trying to hack it so I can get Perl to go, so then I can attempt to build dpkg). Klee is going to update the cross-compiler to assist me. Hopefully, cygwin.dll can become a part of the Debian distribution for a Win32 port, playing the same role as the Linux kernel. But it would be a shame if we have to reclassify the copyrights on every package in the distribution (and prohibit non-free stuff) just because of it. Cheers, - Jim pgpyPc6e7CsBE.pgp Description: PGP signature
Re: cygwin.dll license (was Re: FreeQt ?)
> Yes, very limiting. The code actually cannot be linked statically! Can't be linked dynamically either... read the GPL. Cheers, - Jim pgp6b75kk1gUm.pgp Description: PGP signature
Re: cygwin.dll license (was Re: FreeQt ?)
> For some more perspective on the "interface" argument, go back and see > some of the flaming a year or two ago about the GNU "libmp" (multiple > precision integer math library.) Actually, I had a very similar polite argument with RMS via private e-mail (about linking Java libs with mixed GPL/LGPL/proprietary licenses). He was pretty solid on the fact that run-time linking is the same as "compiled-in" linking. What I think it comes down to is this -- if the GPL'd code comes from a company that is willing to hire lawyers -- you'd better pay attention to the fine print, otherwise, don't worry about it that much. I'm sure that there are plenty of libraries out there that have been put under the GPL, because the author couldn't be bothered to worry about the implications. I've seen a few Java ones that fit this bill. You could probably use these in a commercial app, and nobody would care. The Linux kernel is GPL'd, but proprietary stuff gets dynamically linked to it indirectly via OS calls and such. This hasn't been an issue, since Linus Torvalds isn't going to sue you. The FreeBSD guys would have you believing otherwise. Cygnus is trying to sell commercial licenses, so that implies that they would be willing to sue. This is going to be an issue for us, the Debian project, when I finish porting dpkg to cygwin32. The GPL was a quick hack designed to cover stand-alone apps. It was never intended to be used for libraries and other dynamically-linked code where the legal implications are much more far-reaching. That's why the LGPL came into existence - the GPL was just too restrictive. The GPL is a very restrictive license. In many ways, it is just as restrictive as the Qt license. Particularily in the case of libraries, using it as Cygnus is doing (to make money) goes against the spirit of Free Software. At least with Qt, Troll Tech is very up-front about the fact that it is commercial software, which they are licensing for free. Cygnus, on the other hand, called their work the "GNU-Win32 project", promoted it as genuine true-blue GPL'd "Free Software", solicited patches from the user community, and then, after 17 betas or so (maybe not all public), they issued a marketing announcement that "commercial" licenses could be arranged. Many people on the mailing list were not impressed -- they felt that they had been cheated. Don't get me wrong, I like the work Geoffrey Noer and others have done -- I'm still going to use it. But I don't consider it to be "Free Software" in spirit, even if it is under the GPL. I'd like to see Debian maintain some lofty goals as to what constitutes "Free Software", so I think that discussion on these topics is healthy. Just calling 'em like I see 'em. Cheers, - Jim pgp2R1wJKPNJd.pgp Description: PGP signature
Re: [boldt@cardinal.math.ucsb.edu: Info package: .dsc missing. And: TkInfo]
There already is a tkinfo package (version 1.3). cas <[EMAIL PROTECTED]> is listed as the maintainer. Cheers, - Jim pgpjw0BNcP82y.pgp Description: PGP signature
Re: cygwin.dll license (was Re: FreeQt ?)
> [ I've not been following this thread too closely, > so if I've got the wrong idea, please forgive me ] > > > The GPL is a very restrictive license. In many ways, it is just as > > restrictive as the Qt license. Particularily in the case of libraries, > > using it as Cygnus is doing (to make money) goes against the spirit > > of Free Software. > > Wrong. (I think I'm right) > There is no obligation to give things away for no money when writing free > software. No, there isn't an obligation. There isn't an obligation to even have to write free software. I have no problem with people who write proprietary software -- something's got to pay the bills. But there are varying degrees of freedom. There exists "Free Software" where somebody isn't trying to make a buck off of it. Most "Free Software" falls into this category. The GPL license is used by many of these packages in order to prevent anybody from putting the software under a proprietary license in order to 'extort' money (and other things) from out of the user base. The cygwin.dll case in an example where the GPL is being used to restrict the rights of other people using the code so that they can't do something taboo such as charge money, while at the same time, reserving the right for the authors to do the exact same thing. To me, this is clearly hypocritical, and I don't consider that software to be as 'free' as it could otherwise be. If cygwin.dll was put under the LGPL, it would be a more 'free' piece of software that if it was under the GPL. But then Cygnus couldn't 'extort' money from their users (some of whom may be writing commercial software to put food on the table for their kids). [I use the word, 'extort' in a Free Software sense, since the library is being passed off as Free Software] There's something wrong with thinking that just because something is under the GPL, it is automatically as 'free' as is could be. > I presume that the what they are selling is the right not to be bound by the > GPL restrictions that would normally apply --- is that correct ? That's true. But if there is a great demand for relaxed restrictions, a true-blue free software author would investigate using a less restrictive license, such as the LGPL, rather than prying money out of the hands of the users. (hopefully I'm clearing up some people's thinking on this topic) Cheers, - Jim pgpl9QeB0Kulz.pgp Description: PGP signature
Re: cygwin.dll license (was Re: FreeQt ?)
Jason Gunthorpe wrote: > I really must admit I find the GPL very cryptic, it's hard to say exactly > what it means if you look at very small detail. I do think that it makes > sense however that you should be able to put RCS in a dll and link to the > dll. That depends, if you put it in a .dll, and the original author is just a student, or a hobbiest, it's unlikely that you would ever have to prove your point in court. But if the original author is a commercial entity that is trying to make money, or perhaps the FSF that has a point to prove, you might find yourself in court, with a bunch of expensive lawyers on the other side. Cheers, - Jim pgpdA77lNmXjz.pgp Description: PGP signature
Re: cygwin.dll license (was Re: FreeQt ?)
> On Jun 2, Jim Pick wrote > > The cygwin.dll case in an example where the GPL is being used to restrict > > the > > rights of other people using the code so that they can't do something taboo > > such as charge money, while at the same time, reserving the right for the > > authors to do the exact same thing. To me, this is clearly hypocritical, > > and I don't consider that software to be as 'free' as it could otherwise > > be. > > First off, this list isn't the right forum to discuss Cygnus morality > issues. Can someone point out a better forum? I'm not saying that they're being immoral. I don't think they have properly addressed the issues though. Maybe that means they would be open to releasing the cygwin.dll under the LGPL in addition to the GPL and their proprietary license. > Second, I find it hard to conceive of some case wher Cygnus would > sue someone for selling commercial software which happened to use > a DLL authored by Cygnus. It would trash their (Cygnus's) reputation, > and eat into their bottom line. Cygnus has made it clear that they intend to make money off of cygwin32. How aggressively they do that, I don't know. > Third, I think you're (Jim, I mean) making a mountain out of a mole hill. Perhaps. Cygnus hasn't released enough information for me to decide whether it is a mountain or a mole hill. I hope it's a mole hill. Just so you understand why I'm so interested - I'm working on porting dpkg to cygwin32. That way, we'll be able to host the entire Debian distribution on top of Windows 95 and Windows NT (at least the stuff that will port). It would just be another Debian port, like PowerPC, Sparc or Alpha. This could potentially be a really big thing. :-) Little licensing details could really come back to haunt us. Imagine if everybody that wanted to make a non-free application that ran on top of Debian GNU/Win32 had to pay Cygnus a licensing fee. Imagine if Microsoft demanded that everybody had to use a certain license in order to run on top of their operating system. > Can't we talk about something more interesting? This is interesting! :-) (Nobody's forcing you to read this thread) Cheers, - Jim pgpv1yZd6vYvT.pgp Description: PGP signature
Re: the ncurses "brushfire" -- anybody want to take over the project?
> The senior maintainers and copyright holders of ncurses (Zeyd benHalim > and myself) both feel very strongly that Thomas Dickey hijacked the > project in a way that was unethical, injurious to the interests of > the free-software community, and arguably flat-out illegal under our > license terms. ^^ Huh? You mean it's not free software, right? I just looked at the license (in /usr/doc/copyright/ncurses3.0 on my system) - and I was alarmed to see that there was no grant of license to actually modify the code. I then went to check the actual source code, and again, the same thing. If other people are not allowed to modify the code, then ncurses does not qualify for the Debian stamp of approval as 'free software', and should be moved to non-free. In addition, all of the programs compiled against it should be moved out of the main distribution, and into contrib. I'm sure glad I've never programmed anything against ncurses. Or did I miss something? Cheers, from a slightly alarmed, - Jim pgpttMU8Baz4N.pgp Description: PGP signature
Re: the ncurses "brushfire" -- anybody want to take over the project?
I just wrote: > In addition, all of the programs > compiled against it should be moved out of the main distribution, > and into contrib. (I just noticed that dselect/dpkg falls into this category) This is not a good situation. Cheers, - Jim pgpPwqLOmli3A.pgp Description: PGP signature
Re: the ncurses "brushfire" -- anybody want to take over the project?
Eric S. Raymond wrote: > I don't yet know. I believe Debian's position on this is (a) > unreasonable, and (b) not even internally consistent. Are you going > to also cease immediately distributing all of the important software > released under the Artistic License and similar ones? I don't think this is true. All those licenses allow modifications (unless we've missed another one). Debian is getting more consistent on this all of the time. Obviously, we weren't too consistent when ncurses got into the distribution, with a license that doesn't permit modifications. It looks like it was introduced very early in the history of Debian, so it escaped public scrutiny. Maybe Bruce could send Eric a copy of the draft "social contract", just so he can see how consistent we are trying to be. I'm in favor of relegating ncurses to the non-free distribution, ASAP. (for current hamm development) dselect (our package selection tool) will have to be rewritten to use some other library. This will probably take some time, though. I'm not sure how we will resolve having the core of our packaging system dependent on a "non-free" package. Maybe we're going to have to strip dselect out of the dpkg package, and put it into a separate package to go into the "contrib" directory. Ugly. Of course, this can be reversed if Eric Raymond (and Zeyd M. Ben-Halim) resolves the licensing situation - saving us a lot of work. Cheers, - Jim pgpvQ2RmE1Pwd.pgp Description: PGP signature
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
Brian White wrote: > I agree with you on this. I personally believe that Debian should relax > this requirement about non-modifiable & redistributable code not being > suitable for the primary distribution. I've never seen how it helps any > cause other than sticking a finger in the eye of those who might like > to keep some medium of control over their work. We do allow software licenses that require derived works to have a different name. I believe that adding that restriction to the ncurses license might allow Eric to retain control over the "ncurses" brand name, and still qualify for Debian's "Free" stamp of approval. Any derived works (like that ncurses 4.0 stuff) would have to be renamed, if they want to use the ncurses 3.0 code. That way, there's no confusion - and Eric's toes don't get trampled. But we should stick with the requirement for having all the code in the core distribution being modifiable. (that's the #1 reason I use and develop for Debian) Cheers, - Jim pgphoo3srd6qS.pgp Description: PGP signature
Re: 1.3 installation report
> I did find a serious problem after rebooting (ok, I could probably have > done this more subtle) the machine to start xdm. From reading several > debian related lists I already knew that xdm will break with shadow > passwords. However, I doubt if everyone who just installed debian 1.3 will > realize that it is this combination that prevents him/her from logging in. > The fix is very simple: ctrl-alt-F1; log in as root; shadowconfig off; > return to x and log in normally. But you do have to know this.. and there > is no warning when installing shadow or xdm. Arrrghhh! I spent two hours yesterday (past midnite) on the phone with a client trying to figure out how we messed up the xdm install. This flaw needs to be publicized a bit more. I'm sure I would have figured out the problem via the bug system eventually - but I shouldn't have to do that. Is there a document where "Errata" can go? How about a release-specific FAQ that we can update after 1.3 has been release? I can think of a number of questions that could go onto it. This could be prominently featured on the web site and the ftp server. Cheers, - Jim pgppoWRhgYUGn.pgp Description: PGP signature
Re: cygwin.dll license (was Re: FreeQt ?)
> On Jun 2, Jim Pick wrote > > Just so you understand why I'm so interested - I'm working on porting dpkg > > to cygwin32. > > Porting or re-implementing? If it's a port, dpkg is already under > gpl, so cygwin32 being under gpl shouldn't be an issue. [Even if > it wasn't, I don't understand how a gpl'd dll could be considered > a problem.] That's true. I was just thinking about all the packages that use it. It's worth doing, even if Cygnus doesn't want to LGPL their license. At least we could port the 1000+ packages in the main distribution. The non-free stuff would be questionable. Let's kill this thread - I made my point - ie. "just 'cause it's GPL'd doesn't automatically make it as 'free' as humanly possible". When I actually get dpkg to work, we can start up a new mailing list, and continue the discussion there. Cheers, - Jim pgpClFc3F4Yxq.pgp Description: PGP signature
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> Well, it's fine for the author to _require_ that modifications in the > program be returned to the author. It's just not acceptable for the > author to not allow modifications to be distributed. I don't think we should accept licenses that require modifications to be returned to the author, or require assigning the copyright for modifications to the license holder. That's my (strong) opinion. There needs to be more debate. Cheers, - Jim pgpkkuccPIOcW.pgp Description: PGP signature
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> Regarding the assignment of copyright, I took that out of the draft > document. Yay! I knew you were a good guy! :-) Cheers, - Jim pgptBXGtMKzg2.pgp Description: PGP signature
Re: Postgres95/PostgreSQL
John Goerzen wrote: > Back in March, Siggy had indicated that he would be taking over > PostgreSQL development (the Postgres95 package currently in Debian is > now very out-of-date). I e-mailed him about this and got no response. Back on May 7, Siggy posted the following: > Hi all, > > after losing almost everything (including backup tapes) in a house fire > on April 2, I finally I find the time to read my email on a friend's > machine. With a backlog of more than 7000 messages I can answer only > to the most urgent ones. > > As things are going, I will need another 2 weeks before being able to > work on Debian again - too late for the release I assume. > > If there are urgent changes pending, will anybody kindly upload a > non-maintainer release for the following packages: > > postgres95 > mgetty > hwtools > linux86 > > Thanks > Siggy So it looks like he's probably still recovering his system > So...is anybody out there planning to take over PostgreSQL? If not, I > can take a look at it. If it will require a tremendous amount of > time, I probably won't be able to do it; otherwise, I can give it a > try. That would be great. I really need it here too. I even sent an e-mail message to Emanuele Pucciarelli (who's listed as the previous maintainer) saying I'd be willing to take it over. Of course, I'd rather not do that, since it's a pretty large package, and would take quite a bit of effort. PostgreSQL 6.1 should be coming out in a few days. It looks good. :-) Cheers, - Jim pgpQ0GwzNIGNm.pgp Description: PGP signature
Re: jdk1.1 - no dynamic Motif linkage package
> Jim, > > why didn't you upload shared Motif library version of jdk1.1-runtime? > I just wonder if there is any reason for that. > > Thanks. > > Alex Y. The jdk1.1-runtime package can be used either way - read the /usr/doc/jdk1.1/README.linux.gz file for details. You can use a shared Motif library with it if you set the DYN_JAVA variable. I haven't tested that, since I don't own Motif. Cheers, - Jim pgpHVdvHhHvko.pgp Description: PGP signature
Re: New package notices via bug tracking system.
> Joey Hess <[EMAIL PROTECTED]> writes: > > The real reason I'm replying to this: I wonder what the other developers > > think about bug reports that just say a new version is available (as opposed > > to, a new version is available, and fixes this nasty bug). > I think it's a good idea. I don't always notice when a new version of > one of my packages is released, and the bug system makes a nice > reminder once I've been notified. > > -- > Rob Me too. The "bug" system is sort of a mis-nomer, it's also great for feature requests and notifying that a new version is available. People shouldn't interpret the number of bugs against a package as an indication of its quality -- they could all just be requests for enhancements. Cheers, - Jim pgp3GWMc2QuE0.pgp Description: PGP signature
Re: Status of Debian Policy
> > All packages that provide HTML documentation should register these > > documents to the menu system, too. Check out section section 4.1, `Web > > servers and applications' for details. > > Is that as well as registering with dwww? I'm changing the way documents register themselves with dwww (again). Hopefully, I'll get enough accomplished so that I can upload something to experimental today. I wouldn't encourage anybody to register their documents with dwww just yet, since it's all going to change. Hopefully, I'll get past the prototype stage in the next month or so, and there will be a standard supported way of registering documents with dwww. Cheers, - Jim pgpiSxdDQz1vZ.pgp Description: PGP signature
Gone for a week
I'm going to be away from my computer for approximately a week, while I travel to Vancouver and Nanaimo (B.C., Canada) on business. I probably won't be able to fetch my mail. Unfortunately, I slipped behind schedule for a few things - so I won't be uploading the "experimental" version of dwww today, as I promised. Also, I haven't had time to do the Debian 1.3 Release FAQ - does anyone else want to take that over? If not, I'll pick it up again when I get back next week. Also, if new clients for the des-solnet package come out - please feel free to package them up (so we don't fall out of 1st place). If anybody really, really wants to talk to me - just call my pager number (listed on my home page). Cheers, - Jim pgpzGzi7St7wK.pgp Description: PGP signature
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
> > I suggest to use [EMAIL PROTECTED] as common identifier for Debian > > friends. In case we get the money (why should we ?) I suggest to pass > > 50% to Linux International and keep 50% for Debian. > > Please use an address at Linux International, not one in the Debian > domain. It is not our policy to compete with other Linux distributions. > If we are to join this challenge, it should be for all Linux, not for > Debian alone. > > > Thanks > > Bruce That's silly, Bruce... I get the impression that you've been hoodwinked into thinking there is an "official Linux team" - there ain't - there's a linuxnet.org team, organized by those IRC guys. The odds of winning any of these contests (even with a strong team) is something like 1 in 10,000 - so the objective isn't to win - it's just to compete. Your argument is sort of like saying we shouldn't buy a lottery ticket and write "Debian" on it, because someone else bought a lottery ticket and wrote "Linux" on it - and they might be offended if we won. Having teams makes it a bit more fun. Having 1 team (ie. a Linux team) sort of kills the competition aspect of it all. So I'm still in favour of using the [EMAIL PROTECTED] address, even though that address is just an auto-responder. Once I get my experimental dwww release out (hopefully tomorrow), I'll package up an "rc5-bovine" package to replace the "des-solnet" package. Cheers, - Jim pgpj8KA8GlAA8.pgp Description: PGP signature
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
> People did complain that we were promoting Debian to the > detriment of Linux. Yes - but remember, some of the people participating in these contests were acting pretty infantile. Instead of focusing on solving the problem, they want their team to be at the top of the list at all costs, including 'spamming' the servers to increase their odds. The people who wrote to you complaining about the fact that there was a [EMAIL PROTECTED] team were just trying to get people to join their team - so they could get some more "nerd glory" or something. I'm surprised that you've taken them so seriously, and that you think they even reflect the sentiments of even a fraction of the Linux community. This is such a small thing -- nobody cares. If you were to take a poll of Linux people about this, they'd overwhelmingly vote for 'go away, I don't care'. BTW, in case you didn't notice - we do compete with the other Linux distributions every day -- for the honour of having our system installed on users computers. But, I do agree that we shouldn't be competing against the wishes of the Linux community at large. In summary: Why the hell do we have to be so damn politically correct? I'm mostly in this for fun. :-) Cheers, - Jim pgp36FYtOOWOR.pgp Description: PGP signature
Re: FW: [NTSEC] (Fwd) DESCHALL Press Release
> I have some computers up running in that challenge and I could easily > contribute there output to the debian group, if we are going to have > one. > > So will we have one, or will we do it each one by himself? It's up to you - nobody's really organized anything. Some people are already running for [EMAIL PROTECTED] It's sort of fun watching the team stats move up the chart if the team is large enough. As I understand it, the Bovine RC5 challenge is just a continuation of the zero.genx.net effort that was discontinued earlier (same clients, different servers). I'll probably release the "rc5-bovine" package with a default for the [EMAIL PROTECTED] team, but that can be easily changed (just like the previous "des-solnet" package). I know that this is against Bruce's wishes - but hey, it's not like we're organizing a mutiny or anything (although Bruce seemed to take it that way last time). :-) Cheers, - Jim pgpPzqjWq0teT.pgp Description: PGP signature
Re: Moving away from MD5
Thomas Koenig wrote: > I think we should start moving away from MD5 as our main hash function. > An attractive alternative would be RIPEMD-160. > http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html This is probably a good thing to agree to do, before Klee redesigns dpkg to handle verification and other things (I think he's in California doing contract work right now). One drawback is that it is 3 times as slow - and I assume that the output of the hash function is going to take 25% more bytes to represent it. Is there an equivalent of the md5sum program for it? Sound like a good idea to me, but I'm no expert on crypto. Cheers, - Jim pgpQV4UJ6Zh2Y.pgp Description: PGP signature
Documentation stuff
Hi! Sorry for being absent from most of the conversation, and not getting my latest release of dwww out... - I was working in Vancouver last week, came back, got sick, one of my main modems burnt out (lightning?), I replaced it, upgraded my server, messed up PPP, didn't configure the modem correctly, clients calling me up giving me more work, etc, etc, etc... - so I'm way behind schedule on dwww. Here's my ideas for the documentation stuff: 1) a web server, dwww, etc. should be optional - not a core part of the system. I hope to fix up dwww so that it is much faster, powerful, nice, etc. - but the HTML documentation should be browseable without having all this stuff installed. dwww is meant to integrate the existing documentation formats for convenience, but not replace all of them. 2) All the documentation should be viewable via HTML if dwww is installed - but it shouldn't be necessary to have HTML versions of something that is already in info or man format. If there is an HTML version that looks better, by all means include it (if it's small, put it in the same package, otherwise use a separate package). 3) I'd recommend using something like Debiandoc-SGML for documentation written directly for Debian. But this should be optional. I like it because it will work nicely with dwww (and without), plus it is fairly consistent, and can be converted to multiple formats. We discussed some nice enhancements for it on the debian-doc mailing list which should work quite nicely. Oh yeah, we still need separate /usr/doc//README files, and man pages too... HTML shouldn't be used to replace these. HTML shouldn't be used to replace info files shipped with GNU software either. 4) HTML documentation, if it exists, should be gzipped. Lynx and Netscape can handle the compressed files, provided that the links are straightened out using a tool like fixhrefgz. I was going to stick that tool into a "dwww-dev" package + possibly some other ones. (I've got a few Debian installations on 386's and 486's with less than 150MB of disk total) - I'm going to experiment with straightening out the jdk1.1 documentation... e2compr isn't really an option, in my opinion, since it restricts the portability of the entire system. 5) It would be nice if Diety could install just documentation, or just the binaries, and no documentation. 6) dwww will let us serve documentation directly off of an external site, so it would be nice to have a way of installing the packages with no documentation at all. 7) Cacheing - I'm going to split the cacheing in dwww into a separate package. That way, it should be easy to improve it, not use it, or use something like squid instead. That's it for now... Cheers, - Jim pgpw3ccz7lJlO.pgp Description: PGP signature
Re: fixhrefgz - tool for converting anchors to gzipped files
[ I hate to wade into this, but ] > >However, as you surely know, this does not work without web server, since > >the browsers are not looking for "foo.html.gz" if "foo.html" is > >referenced. > > Yes. But if you change the references then the web-serverws will no longer > do on the fly decompression. They will serve the links as .gz which is not > universally supported by web-browsers not under Debians control. For cases where people want to use a web browser that doesn't grok gzip, we could use dwww (I think). > >Thus, we are considering changing the "href's" to "foo.html.gz" and fix > >the browsers, where possible, to uncompress the file on-the-fly. If the > >browser cannot be fixed (for example, if we don't have the source code) we > >could probably offer a simple web server (e.g. boa) to do this > >automatically. > > Please think about this. > > You are proposing that a web-server is supposed to be searching through > the .html code it serves and replace all links referring to .html.gz by > .html links? dwww does this - it's not trivial. This is definitely not the job of a web server. So here's my stand: - let's munch up the links to point to ".html.gz" files. Ugly, I know, and a bit of work, but then we don't need to force people to install a web server. I think it's pretty important that we don't force people to run stuff they don't want. - we should compress html, because lots of people (like me) are using Debian on machines with almost no hard drive. - Lynx and Netscape work with the compressed links (correct me if I'm wrong), and we could use a web server/dwww combination to allow other browsers to work too. - all the documentation isn't going to be HTML anyways - just "book-like" stuff. So what's the big deal anyways. No need to start a flame-war. - the other option would be to leave HTML full uncompressed, which would be easiest Cheers, - Jim pgp18O0coF5QA.pgp Description: PGP signature
Re: Documentation stuff
> I really want the glimpse searching that TkMan has, but within the
> XEmacs interface. `dwww' has it, but for some reason it does not find
> as many manual entries as Tkman does for the same search. I wonder
> why? Perhaps a generalized perl script (or pull the tcl out of tkman
> that does it?) could do the search, and spit out the links for XEmacs
> or dwww to parse and display?
I'm changing the way dwww is put together, so any type of searching
can be added. The way searching works right now isn't great. Remember,
dwww is still a work in progress.
> I'm using W3 now, so html isn't that bad an option. I can still have
> almost everything inside the editor interface that way. I really love
> having `webster-www' bound to {f2}, so I can look up a word in a
> really nifty fashion.
Once dwww matures a bit, it would be nice to have an emacs interface
to it (via w3-el). That should be easy to do.
> It occured to me today that it would be good to have an rfc index,
> too. Maybe it would have the 's link through a cgi script
> that would check for a local copy, then go get a remote one if the
> local one's not around? Perhaps it could cache them?
I'm going to build a dwww-dev package which will make it easy to
build indexes for specific packages that work with dwww and it's
upcoming documentation menu. It's going to work just like you say.
> I've got the doc-rfc package installed. `dwww' might call on a
> module for searching that someday, perhaps.
Perhaps sooner than you think. :-)
> Gee, maybe HTML should support alternative URL's? The first try to
> the local copy, if that's not there, then call out to a server on the
> net. There could be style variables in the markup to set
> up the base directories/servers.
We had the exact same discussion on the debian-doc mailing list.
> Jim> 4) HTML documentation, if it exists, should be gzipped. Lynx
> Jim> and Netscape can handle the compressed files, provided that
> Jim> the links are straightened out using a tool like fixhrefgz.
>
> Can't apache do that? I think there's a mod-rewrite that will do
> what we need. Though I suppose not everyone runs apache... You tell
> me and we'll both know. I think it's a good idea to have a
> light-weight server that can launch from xinetd.
The only way to straighten out the links is to change the contents of
the web page. dwww does this (sort of). I think mod-rewrite only
works on the requested URL, not the URL's in the document. So I
don't think Apache can do this by itself.
Anyways, I think using a tool like fixhrefgz to fix the links in the
source document is required if we compress docs, since it's a nice
capability of being able to surf the documents straight off the
hard drive, without using a web server.
As for this lightweight server stuff - I tried all the web servers
when I was testing dwww - and Apache was probably the least resource
intensive and the fastest. Of course, it was the most configurable
too - maybe that's why it's called a "heavyweight".
Cheers,
- Jim
pgpjsk2Ig1HH6.pgp
Description: PGP signature
Re: Documentation stuff
Karl wrote: > > Can't apache do that? I think there's a mod-rewrite that will do > > what we need. Though I suppose not everyone runs apache... You tell > > me and we'll both know. I think it's a good idea to have a > > light-weight server that can launch from xinetd. I wrote: > The only way to straighten out the links is to change the contents of > the web page. dwww does this (sort of). I think mod-rewrite only > works on the requested URL, not the URL's in the document. So I > don't think Apache can do this by itself. I just looked at the mod-rewrite web page - it looks like it does rewrite the documents - pretty powerful stuff. Sorry if I misinformed anyone... Cheers, - Jim pgp58VFG49WhH.pgp Description: PGP signature
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
> >You can't fix the browsers, because we don't have the source for important > >browsers like netscape. > > You mean the Debian Project caving in and changing its standards because > some non free product cannot be changed? Where is our commitment to free > software? We shouldn't be changing the way browsers work. Most browsers follow the HTTP/1.0 or 1.1 standard - including Netscape - and I don't think it's smart to develop a "debian-specific" HTTP protocol extension -- that's what you are suggesting, in essence. (or maybe you just mean modifying the behaviour on file:/ URL's - I guess there isn't really a defined standard protocol for handling that sort of thing - it's highly browser dependent. We shouldn't be using that feature if it's so undefined - maybe you want to draft an RFC or a W3C standard? ) I really only see two possible outcomes to this debate: 1) Store HTML files uncompressed and don't munge the links - all web browsers will work, no web server required - wasteful of disk space (particularily for large documentation packages, like the Java JDK docs, or info-style "books") - note that these types of documents tend to be monolithic, so they could be put into separate optional documentation packages - the system administrator could use a compressed filesystem like e2compr to conserve disk space 2) Store HTML files compressed and munge the links with a tool like fixhrefgz - Lynx and Netscape work with no web server required (I think) - other web browsers will work, if they use a web server such as boa, or a web server and dwww - currently, at least on my system, not a single documentation package with .html.gz files has had the links fixed so that it works when browsing directly from the filesystem (and I maintain two of those packages, oops - even worse the jdk1.1 docs have compressed and uncompressed files - arrrgh) - it's extra work for the developers, and error prone too - I think Lars was advocating this, and I was too Christoph seems to be advocating: 3) Store HTML files compressed, and don't munge the links - Lynx (and others) might work without a web server if they were modified - Netscape wouldn't work without a web server - other web browsers will work, if they use a web server such as boa, or a web server and dwww I was advocating solution #2 - but after looking at the current state of the documentation - I think I'm going to switch to solution #1 - storing uncompressed HTML files. We're not really talking about a large amount of disk space on the base system, unless the user installs documentation packages such as the Java JDK docs. Plus - hard disks are cheap - I just bought a 5GB drive for $600 CDN. And dwww will probably evolve to make it easy to view the documentation that is installed on a remote system (on the Internet or via an Intranet). Plus, finally, it's the simplest solution. Cheers, - Jim pgpKgSu5NTiUZ.pgp Description: PGP signature
Re: Sub-categorizing the /usr/doc directory.
One complication I can think of - dselect and the ftp sites have the concept of "overrides", where Guy can change the section a package is assigned to. This wouldn't be reflected in the /usr/doc directory - of course, this might not really matter. Cheers, - Jim pgpkROZcuIbKB.pgp Description: PGP signature
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
> I only advocated this as a compromise. I am for #1. And I would go further > and abolish all compression everywhere. Compression should only be done if > its transparent for all apps (e2compr or zlib?). I have seen so many > broken packages because of manpage compression etc etc. The clean solution > would be to stop this once and for all. I'm with you on this. :-) I just did a "du -s /usr/doc" on my 386DX/33 (8MB RAM, 2-200MB HD) - and it only has 11MB of docs installed. So uncompressing those isn't going to kill me - I'm sure most other people using old hardware have similar usage. Who objects? Cheers, - Jim pgpiEuZGm0yLn.pgp Description: PGP signature
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
> > I just did a "du -s /usr/doc" on my 386DX/33 (8MB RAM, 2-200MB HD) - and > > it only has 11MB of docs installed. So uncompressing those isn't going > > to kill me - I'm sure most other people using old hardware have similar > > usage. > > > > Who objects? > > I do. > text/html/ps usually compress very well. > Uncompressing them will probably take something like 3 to 5 times more. > (The smallest machine on which I have debian has a 80 MB HD) Ok, I did some more testing. /usr/doc (with compressed files): 11.072 MB /usr/doc (totally uncompressed): 25.915 MB I was going to check out what size it would be if I uncompressed all the .html.gz files, but there were none - so it makes no difference. The type of packages that typically will include lots of HTML documentation are packages for developers (like the Java JDK docs) which typically will not be installed on an old 386 or 486 being used as a router or low-volume web/e-mail server. I'd prefer compressing man pages and text files - but not HTML documents. It's a fair compromise - and it doesn't impact the disk space requirement on my fairly typical low-end 386 installation by a single byte. Makes you sort of wonder why everyone is so excited... :-) Cheers, -Jim pgpj3MW1K1qbk.pgp Description: PGP signature
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
> Hi, > > Also, 11M may not be a typical install. I get a far higher number: > __> du -s /usr/doc > 92026 /usr/doc > > Uncompressing this is very likely to annoy me. 11M was for my old 386 box (no X installed) - I'm only using about 200M total on that system. That works out to about 5% of the disk space. The system is quite ancient, but it works great as a Linux machine. If you've 92M of documentation - you probably have a much larger disk - but the % of space dedicated to documentation is probably still around 5%. (My development system has 123M of docs out of a 2GB filesystem - 6.1%) I think you'll find that if we compromise, and store most of the documents in compressed format, except for the HTML documents, your overall disk consumption will not increase by much (as a percentage of the overall disk usage) - maybe the percentage of disk space used for documentation would increase to 7-8% at the most. I'd gladly buy more disk space in order to install more documentation only packages (if they were available). Buying disks to store on-line documentation (even fully uncompressed) is a bargain compared to buying off-line books from Tim O'Reilly and company. Cheers, - Jim pgpxbuMEWh7i2.pgp Description: PGP signature
debian-non-US mirrors (was Re: debmake)
> I couldnt help but notice that there are no Canadian or even American > (South or Central) mirrors of debian with the non-us category. Actually, I do have one on my server (in Canada): ftp://ftp.jimpick.com/pub/mirrors/debian-non-US/ Canada doesn't have a NSA-like organization that has to protect it's turf - so the regulations are pretty loose. The only thing not permitted is re-exporting crypto stuff that was illegally exported from the US, AFAIK. Cheers, - Jim pgpn5L0mKxfq1.pgp Description: PGP signature
Re: Vision of new installation method using webserver
Sounds slick. It wouldn't be too hard to do. It would be slick to have some more network smarts (like DHCP, and dialup to an ISP) on the boot disks (or some variant thereof). As for configuration via the web - check out the GPL'd Java telnet applet I've got installed on my webserver (http://www.jimpick.com/telnet/) - a simple solution would be to put that on the install disks, along with a small web server and some CGI scripts to do the initial configuration - and bingo, you can configure the machine from any Netscape or Internet Explorer machine than can talk HTTP, FTP, and Telnet to it. (of course, firewalls can be a pain) Cheers, - Jim pgpdEqCFsa6KB.pgp Description: PGP signature
Re: Debian GNU/Linux Logo chosen
> The logo I chose is > > http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/profile/si02.html Good choice. You forgot to give some credit to the artist (Simon?) though. Do you think SPI should trademark it? What sort of licensing do you think would be best? What does the original artist think? In order to use the BSD daemon (ie. on product packaging, literature, T-Shirts, etc.) you need express written permission from Marshall Kirk McKusick. http://www.freebsd.org/daemon.html Conversely, the Linux penguin by Larry Ewing was included in the kernel source - so I imagine that means it is covered by the GPL. Actually, Larry grants permission to use/modify it on his web page. http://www.isc.tamu.edu/~lewing/linux/ Cheers, - Jim pgpt0YgkOvQE5.pgp Description: PGP signature
Re: going to package e
Raul Miller <[EMAIL PROTECTED]> writes: > I intend to package the beta enlightenment window manager, imlib, and > the default themes. If anyone wants to do it instead, I'll happily > fall back to kibitz mode -- let me know. Lalo Martins <[EMAIL PROTECTED]> did a package of beta 12, back in August, but he didn't upload it since he was waiting for developer status. I wonder what happened? Did we lose another one? Anyways, his old package is at: ftp://ftp.mandrake.net/pub/enlightenment/debian-deb/ For some reason, there's no source packages. Cheers, - Jim pgpsJbx6HUNhZ.pgp Description: PGP signature
Thread safe X libs?
Check out the forwarded message below. I get the same error using Debian unstable. Does this mean that Red Hat has thread-safe X libs and we don't? Cheers, - Jim --- Begin Message --- On Tue, 9 Dec 1997, Sascha Ziemann wrote: > [EMAIL PROTECTED]:/home/szi$ phaser_chess > warning -- no way to trap SIGPIPE. > > ** ERROR **: an x io error occurred > IOT trap/Abort You probably don't have thread-safe X libraries. An easy way to get them is to install RHL 5.0... -- Elliot http://www.redhat.com/ "They don't let my code go into shipping products," Gates said. "They haven't done that for eight years." (at the 1997 PDC) --- End Message --- pgpaJ5myB5NRh.pgp Description: PGP signature
Re: Thread safe X libs?
[EMAIL PROTECTED] (Mark W. Eichin) writes: > > Check out the forwarded message below. I get the same error using > > Debian unstable. Does this mean that Red Hat has thread-safe X libs > > and we don't? > > Well, I wouldn't mistake that for a bug report... no indication of > *what* is producing the error, why it would have *anything* to do with > the thread-safe libraries, or that it actually *does* work on RH5. If > the program was built with libc5, it's unlikely to be able to be > thread safe. > > If you could perhaps come up with a *real* demonstration, and an > indication of what release you tested it against, it might actually > mean something... or at least it would give me a starting point to > look for the problem. Every X release for a long time has been built > _REENTRANT, and the 3.3.1 libs are built with some threading options > turned on (I'd have to look at the config files to see what, though.) It wasn't intended to be a bug report. I'm not expecting anybody to debug the problem. I just had the same runtime error as the other guy (I compiled on my hamm system), and I didn't know if I should buy into Elliot Lee's explanation of the cause. I was just looking for confirmation that Debian has thread-safe X libs. So I can now tell Elliot that there is a real bug somewhere, and it's not the fault of not having thread safe libs. I'll move the discussion back to the Gnome list now. If Debian has thread-safe X libs (as you say, and as I thought), then the problem needs some deeper debugging. If it turns out that Red Hat has set up their X differently than Debian, I'll get back to you. Thanks for the quick response. Cheers, - Jim pgp3ZflUtDMZs.pgp Description: PGP signature
ldconfig warnings
Hi, This is a minor annoyance, but it always bothers me. When upgrading or reconfiguring, I chronically end up with "orphaned" lines in /etc/ld.so.conf. ie. Currently, on my main Pentium system... ldconfig: warning: can't open /usr/X11R6/lib/libgtk.so.1.0 (No such file or directory), skipping ldconfig: warning: can't open /usr/X11R6/lib/libgdk.so.1.0 (No such file or directory), skipping ldconfig: warning: can't open /usr/openwin/lib/libgtk.so.1.0 (No such file or directory), skipping ldconfig: warning: can't open /usr/openwin/lib/libgdk.so.1.0 (No such file or directory), skipping Currently, on my 386 system... ldconfig: warning: can't open /usr/local/lib (No such file or directory), skipping ldconfig: warning: can't open /usr/lib/i486-linuxaout/libdb.so.1 (No such file or directory), skipping ldconfig: warning: can't open /usr/lib/libpthread.so (No such file or directory), skipping ldconfig: warning: can't open /usr/lib/libjpeg.so.6a (No such file or directory), skipping It's easy enough to fix, just edit the /etc/ld.so.conf file and remove the offending "orphaned" lines. Anyways, I'm sure this is a chronic annoying problem everyone is experiencing. Is the cause is due to incorrect packaging of the shared libraries? I'm not sure. I'm just wondering if there is a way of automatically cleaning up after those (buggy?) packages are long gone... Or perhaps we need to enforce policy a bit better. If somebody could explain what exactly is going wrong in these packages - ie. what policy are they violating? Or is it dpkg's fault? Cheers, - Jim pgpxieJE6BPVo.pgp Description: PGP signature
Re: ldconfig warnings
> Yes, it is discussed in the Debian Packaging Manual, section 12. > See: > /usr/doc/dpkg/packaging.html/ch-sharedlibs.html > > You should just go ahead and file bugs against packages which don't > include the .so link as part of the package. If I understand this correctly, there is no need to use ldconfig in the postinst script, correct? ie. A quick survey of the packages on my system: $ grep 'ldconfig' /var/lib/dpkg/info/*|wc -l 112 And I've only got around 400 packages installed (and not too many libraries) - so I think we've got a serious problem. We ought not to release 2.0 in this state. The shared library thing has always confused me a bit because I tend to pick these things up by example - but if everybody's doing it wrong... Should I file bug reports? What severity? Or am I unduly alarmed? Cheers, - Jim pgp1PX1WUmeaj.pgp Description: PGP signature
Re: Mail delivery failed: returning message to sender (fwd)
> I don't know if this is a bug with procmail(3.10.7-1.5), exim (1.81-1), or > me, so I thought I would ask. I recently switched to exim from smail on my > hamm (currently as up to date as possible) which unfortunately bounced all > of my mail. It seems that exim doesn't like the mail filter pipe used by > procmail in my .forward. The error message is below whivh also includes a > copy of my .forward. Any ideas what is wrong? It seems to me that somehow > the blank assigned to IFS is not being passed properly. Any help is > gratefully appreciated. Cheers. This .forward file worked for me for procmail on exim: "|/usr/bin/procmail USER=jimtest" It took a bit of trial and error to figure that one out. I'm not sure what -Qf- does, you might want to add that too. Hope that helps... Cheers, - Jim pgpEHPfM3508V.pgp Description: PGP signature
Re: slib and Debian ?
[ Sorry for the exploding cc: list - this is a Debian packaging issue, so please limit the follow-ups to debian-devel. ] Mark Galassi <[EMAIL PROTECTED]> writes: > Jim> Perhaps I should declare a dependency on the slib package, > > Absolutely not! It would be a great loss if Guile were *forced* to > depend on slib. > > Guile is an embeddable library implementing R4RS Scheme, and is quite > useful as that, even without slib. > > That's why I suggested that both Guile and slib try to create the > catalog, that way the one that is installed last will do the creating. > > [by the way, I think that creating the catalog at run time instead of > install time is really non-robust, but we are stuck with what Aubrey > gives us in his otherwise awesome slib] OK. I agree that declaring a dependency isn't really good. I was just being lazy, hoping nobody would call me on it. The code for 'registering' slib with guile ought to be in the slib package (I'm not the maintainer of that package, Rob Browning is). It might go into a 'slibconfig' script. Of course, there are quite a few different Scheme packages other than guile that might also work with slib - so that makes things a bit ugly for Rob. When guile (or another Scheme) is installed on a system that also has slib, it could call the proposed 'slibconfig' script from the slib package. Here's a possible slibconfig script with support for Guile in it: #! /bin/sh if [ -d /usr/share/guile ]; then (cd /usr/share/guile guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" ) fi This would be called from the postinst of slib and guile. Rob, if you think this is a good idea, I could make a non-maintainer release of slib (only supporting guile) -- or I could wait for you to make a release. Cheers, - Jim pgpKiPEyrxfOf.pgp Description: PGP signature
Re: Financial support
> Pardon me for a nosy question. Does Debian have any money flowing in > from users that is used to compensate full-time Debian developers? Debian does solicit donations to Bruce Peren's "Software in the Public Interest, Inc." non-profit to help defray costs (like Internic fees, etc.). Here's a list of the donations so far: http://www.buoy.com/debian/misc/donations.pl Unfortunately, there is no record of outflows there. I imagine that SPI will have to do an annual report eventually where all that info is public. SPI is in the business of giving out "grants". Most notably, they have committed $1000 to the Gnome project (www.gnome.org). I'm not sure what the Miguel and the other Gnomers are going to do with the money, but it is a nice token of political support. Personally, I have no problem spending business time to contribute to Debian - it's a good image/reputation builder. I do have to keep myself in check to make sure I don't "overcommit" my time to the project though. Look for an updated dwww package and a new "kaffe+kore" package this week from me. Cheers, - Jim pgpfxZDfPhuUF.pgp Description: PGP signature
Re: dhelp 0.2 - a online help system
[EMAIL PROTECTED] writes: > I like it but... I like it too. > 1) How about dwww? (Yes, I know dwww needs a web server...) I think I'll add support for .dhelp files to dwww too. > 2) I really dont like to have 2/3/... methods of building indexes > of documentation installed in the debian system. What about integrating > all that stuff? (menu, dwww, dhelp, etc...) I agree - we should eventually have only have one index. I've been working on yet another way of building an index, but I'm been very slow working on it. > 3) The policy says the preferred doc format is HTML (fine) but > it says nothing about how to access it. Any ideas before we poor > developer have to write a dozen of different conf files to support > all that new help systems? (menu entries, .dwww-index, .dhelp, etc...) I'd consider all documentation menu systems "experimental" at this point, so I wouldn't worry about it yet. Just support a particular menu style if you feel like playing with it. FWIW, the menu system I'm working on was going to be SGML/DSSSL based, so Marco's .dhelp menu format is perfect for that. I'll be able to use the .dhelp format as input. Short term (in the next few days), I'm also going to enhance the dwww menu-package based menus. I'll see if I can write a .dhelp to "menu" converter. That way, package authors can write a single .dhelp file, and support all the menu-building packages (dhelp, menu, and dwww-next-generation). The next dwww should be ready by Sunday, at least. Cheers, - Jim pgpI4G57nF7q9.pgp Description: PGP signature
The next dwww (was Re: Financial support)
> > Look for an updated dwww package and a new "kaffe+kore" package this week > > > Yuhuu! > > Is it the version with the "big step forward", you promised some time ago? Unfortunately, not. It's more of a "fix as many of the 40 bugs as possible" release. It'll be a little step forward, setting the stage for the "big step forward" release in a month or so. Don't expect much new for the next release, except support for the index on multiple heirarchial pages (I haven't tried menu's support for that yet), and maybe support for .dhelp files too. The "big step forward" release should have much better support for a wider range of meta-data, a DSSSL-based menu building system (yes, yet another menu building system), better search capabilities, and an extensible architecture. I've got some additional plans that go beyond that release too. (oh yeah, since Brian is still cc'd to this - I should mention that I'd like to do a pgsql package too, now that we have an updated postgresql package again) Cheers, - Jim pgpr6gOMexbxY.pgp Description: PGP signature
Re: Bleeding edge FTP repository updated to glibc2 + egcs.
Paul Seelig <[EMAIL PROTECTED]> writes: > Has anybody already noted this here? [ Cut - Posting about Yggdrasil packages - RPM/deb/slackware/yggdrasil from common source ] Looks interesting! I wonder if they are proposing a new source packaging format - or if they are building all the binary packages from an unpacked tree. Judging by the contents of their build.log and install.log files, it seems they just have one huge FreeBSD-style "make world" happening. I looked at one of the SRPMs, and saw no Debian stuff. I don't think they have a source packaging format. Too bad. But they must have all the source in place to do multiple binary packages... they just haven't put it up yet. I'd like to see a common source packaging format that could be used to generate any type of binary package. I'd advocate using such a source format for Debian - because then we could help organize people who want to do 'contrib' packages for other distributions - and as a spin-off, reduce some of the duplicated work in the free software community. It would also be an excellent step towards a unified binary packaging format. Whether or not we want to deal with 'outsiders' is another matter altogether. We might get distracted somewhat from our Debian integration work if we are trying to produce portable packages. Also, I'm not sure if our one maintainer per source package system is flexible enough to deal with supporting multiple architectures, languages, and multiple distributions too. I don't think it would be too much work rigging the ability to generate RPMs into our package building process, or to use Red Hat 'spec' files with dpkg-dev. Someday I'm gonna figure out how to do that. Cheers, - Jim pgpOYsfsTWRG8.pgp Description: PGP signature
dwww Missing-in-action
Sorry, For those holding their breath... I had system problems this weekend. I'll have dwww ready next weekend. Cheers, - Jim pgpFTRhdIqcvr.pgp Description: PGP signature
Re: Guile question: What was bug #14213???
[EMAIL PROTECTED] (Karl M. Hegbloom) writes: > The changelog lists only a bug number, with no description of what > the bugs were. They are no longer in the bug tracking system. You are hitting on one of my pet peeves - we should have a perpetual bug archive for closed bugs. > Can you explain why you couldn't compile with threads or dynamic > linking? It was a co-ordination issue with the Gnome package - I don't think Gnome would compile when threads were included. I didn't know what to do to make it work (when using guile) - and there is no documentation. I think thread support and dynamic-linking in 1.2 are experimental - so I think it's fair to leave it out. Everything seems to work when those are left out. I assume Guile 1.3 will be a big improvement. > I'm putting together a guile-core snapshot package, perhaps > for release if I feel like I have it under control. It will come > with the guile-scsh too, I hope. That should be good for gnome. :-) Cool. Say, if you are going to to do that, do you want to take over the guile package? You can have it, as there should only be one guile maintainer, IMHO. > I've Cc'd debian-devel to show others what can happen when we don't > put proper detail into the changelogs. The bug number alone is no > good; the tracking system purges them after a period of time, so the > only record is in the changelog or CVS logs (which are more difficult > for others to get at, obviously.) I don't think the changelog is the place to give full-blown bug descriptions. They can be very hard to describe at times. A little hint as to what the bug was in this place would have been nice - but I'm not sure I could have described what the bug was in under ten lines of description. > > guile (1.2-3) unstable; urgency=low > > * Removed --with-threads and --enable-dynamic-linking options > (should fix #14213, 14214 - Thanks John Goerzen) > * Added ldconfig to postinst > Fixes Bug #41212 - Thanks Jogn Goerzen > > -- Jim Pick <[EMAIL PROTECTED]> Wed, 29 Oct 1997 22:27:48 -0800 Hmmm - I can't remember the details of #14213, #14214 - I should have a copy on my machine, but I think I must have filed in into the wrong mail folder. :-( > karlheg, who aspires to understand the implementation of Scheme someday. Read the Wizard book (SICP). :-) Cheers, - Jim pgpgJxiwU2N1z.pgp Description: PGP signature
Re: Number of Maintainers
Brian Bassett <[EMAIL PROTECTED]> writes: > After both Manoj Srivastava and Bob Hilliard pointed out to me the faults > in using the Maintainers file for determining the number of maintainers, I > have decided to use the Debian PGP keyring. After deleting duplicate keys, > the keyring says that there are 313 developers, making Q 8.85 and K 5. > > Brian You know what would be cool - if the www.debian.org homepage had a running count of the number of maintainers! That's Debian's biggest selling point, as far as I'm concerned. Cheers, - Jim pgpKezikvA920.pgp Description: PGP signature
Re: jdk1.1-runtime
Corey Miller <[EMAIL PROTECTED]> writes: > When I try to install jdk1.1-dev (I want to install JavaICQ, which > makes use of the jdk), it says that it depends on jdk1.1-runtime. I was > wondering where I could find this package? I looked in incoming, frozen, > unstable, and even used the package search utility on www.debian.org. > Thanks for you help, It got nuked when hamm was frozen (source is still in project/orphaned, I think, but the binary is gonzo) Stephen Zander <[EMAIL PROTECTED]> is working on uploading jdk1.1.5 - so I didn't bother with fixing 1.1.3. You can still get it from: ftp://ftp.jimpick.com/pub/debian/pkgs-old/jdk1.1/1.1.3.v2-1 Sorry for any inconvenience. Cheers, - Jim pgpAKlUEDo85e.pgp Description: PGP signature
Re: intent to package jstation
Stephen Zander <[EMAIL PROTECTED]> writes: > Bummer! I can't help here unfortunately (I'm a jdk source licencee) but > I thought Jim Pick had expressed an intention of persuing free JVM > implementations. > > Jim? I'm freeing up the rest of this week, so I will be able to work on all my Debian stuff I've had on hold for awhile. I wouldn't hold your breath for a totally free Java implementation yet - both Kaffe and Japhar depend on the non-free Sun class library. Some work has been done on a free class library (kore) - but this hasn't been integrated into either kaffe or japhar at this point (except for an older version of kaffe). Cheers, - Jim pgpT0uNziyXhv.pgp Description: PGP signature
Re: /tmp exploits
Ian Jackson <[EMAIL PROTECTED]> writes: > We should modify our libc so that opening a file in /tmp or /var/tmp - > determined by simple string comparison of the filename passed to > open(2) - fails if O_CREAT is specified without O_EXCL. > > We should do this in slink. That way almost any program with a /tmp > security hole will stop working straight away and _have_ to be fixed. That seems pretty extreme. If we are going to do something like that - couldn't we just get rid of /tmp altogether? Cheers, - Jim pgpmnJk9VgFPx.pgp Description: PGP signature
Re: Gnome debs?
David Welton <[EMAIL PROTECTED]> writes: > > GNOME is currently not very stable and things are changing very > > rapidly. Jim Pick is the GNOME guy for Debian. Give it a few more > > weeks and I think you will see more. I've got most of the packaging for gnome 0.13 done. Unfortunately, the gdk_imlib 1.1 stuff wrecked things - gnome 0.13 required a newer version (which was only available in CVS). Everything would build, but most of the binaries would not run. Raster released gdk_imlib 1.2 a few days ago, so I may be able to release some gnome stuff that works sometime this week. > The thing I was wondering about is getting support in their build > scripts for debs. Every morning they get some rpm's generated > automatically. I was wondering if it might be feasible to do this > to make some debs too, or if it would be just a waste of time:-/ I was thinking of building snapshot Gnome packages from the CVS that I might update weekly from here. I thought about doing it daily, but that would be too much work. My thought was to put this in a non-standard location (ie. under /opt) so that they wouldn't interfere with released versions of Gtk, Gnome, etc. The debian/rules will be different for the snapshot packages than the released ones - so I'll have to figure out a scheme to work around that. Perhaps the Red Hat labs guys would be willing to build the .debs too. Even if they were willing to do that - they might not be the best choice to do it, as they wouldn't be testing the .debs. Once I get the packages built, I'm going to see if I can get the "debian" directories put into the Gnome CVS. Cheers, - Jim pgpGsDUPMAxSS.pgp Description: PGP signature
Re: on forming a new Linux Distributionx
[EMAIL PROTECTED] (Bruce Perens) writes: > From: Raul Miller <[EMAIL PROTECTED]> > > For what it's worth, GIF support is doable with free software, just not > > compressed gifs. [gif supports a variety of compression mechanisms, > > including "none".] > > The patent expires in August. > > Bruce No it doesn't. Here's the patent: http://patents.uspto.gov/cgi-bin/ilink4?INDEX+0+4464650+F Note the date it was granted - Aug. 7, 1984 Add 17 years, and it expires August 7, 2001. Correct me if I'm wrong. (I think they've changed the rules to be 20 years from initial filing date as of 1995 - but this is an older patent) Here's the Unisys position: http://www.unisys.com/LeadStory/lzwfaq.html (no mention of the date) Cheers, - Jim pgpQsgYpNxkyt.pgp Description: PGP signature
Yet another Linux distribution! :-)
here will be stable and development branches. There will be a new stable release approximately every two months (built from packages from the Debian unstable distribution, but tested). Security bugs will be immediately put into the stable release. Because there will only be a small set of packages to test, and a small closely-knit release team, rapid stable releases can be done. For the most part, the development branch will just be a strict subset of the Debian unstable distribution. Basically, it will be the same packages. Due to the differing release schedule, there will probably need to be quite a few non-maintainer fixes - but these will all be pushed upstream to Debian. Any packages tha I develop specifically for this distribution, I will also upload to Debian. There will be a separate bug system, but most bugs will be fed "upstream" to the Debian bug system (with patches if they are easy fixes). There will be relatively few bugs, because the packages released into stable will have been rigorously tested. There will be separate mailing lists in addition to the Debian mailing lists. Unlike Bruce's project - this project will have a symbiotic relationship with Debian. If it works, it will attract new users to the Debian code base. Also, the more successful Debian is, the more successful this subset of Debian will be. I'd like to see more people announce that they want to develop their own "subset" Linux distributions based on Debian. I'd be willing to collaborate on tools to make this easier. The big problem with Bruce's idea of developing yet another volunteer distribution is that he will once again have no control over what the volunteers will be doing. He'd be much better off using the same model I am going to use, which allows for near 100% editorial control, without giving up the benefits of having hundreds of developers feeding code in. Of course, if he wants to base a distribution on rpm rather than dpkg (bad idea, IMHO), he'd be better off basing his work on the Stampede distribution, and organizing a recruiting campaign for them. In summary, don't hold your breath for my "subset distribution" of Debian - it will take a long time to pull together. But I strongly believe that this is a model Debian should encourage. The Debian distribution "proper" may never have more market share than the commercial distributions such as Red Hat, Caldera, and SuSe. However, it is entirely possible that derivative subset distributions of Debian could dominate the Linux marketplace (especially given the technical superiority of Debian). Cheers, - Jim pgp81Sm0FdFN3.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
Mark Baker <[EMAIL PROTECTED]> writes: > On Fri, May 01, 1998 at 11:10:39PM -0700, Jim Pick wrote: > > > - targetted towards desktop use only, no server apps, just a few games > > > > - minimal size - optimized for installation via 28.8k modem via FTP, > >which will be the primary distribution mechanism (not CD). > > These don't seem consistent to me. If people are the wrong side of a dialup > link, they need to have a local MTA (actually most people ought to have that > even if they're not, although the configuration is significantly simpler if > they're on a permanent fast network connection and so don't need local > mailboxes) and a local news server. Oh yes, it will have an MTA. When I said "no servers", I meant stuff like web servers, SQL databases, etc - stuff you might find on an Internet server or LAN server. In reality, there will dozens of "servers" for personal use. I'm going to use CORBA-based stuff wherever I can, so all those objects could technically be considered to be "servers" as well. > Other than that, it sounds good---not for me, and probably not for the > majority of Debian's existing users, of course, but for people who want a > simple desktop OS that's easier to use than Windows. And existing Debian users don't have to choose, because I'm not leaving Debian, and I'll put the same stuff into Debian (as long as it fits policy). :-) Cheers, - Jim pgpBw0vmkieOE.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
Drake Diedrich <[EMAIL PROTECTED]> writes: > On 1 May 1998, Jim Pick wrote: > > > I'd like to see more people announce that they want to develop their > > own "subset" Linux distributions based on Debian. I'd be willing to > > collaborate on tools to make this easier. > >Interesting. I'm starting up an ISP with a Debian focus, and planning > to produce configuration-packages which will be added into the local > Debian mirror, producing a (barely) derivative Linux distribution. > I suspect many consultants and ISPs will begin doing this. I worry about > name collisions in real derivatives though. >We may need some new policies with respect to derivatives, so we avoid > clashes. Off the top of my head: > 1) Derivatives are allocated a subdirectory in /opt by Debian. As far as people developing local packages to add on to Debian (which is not really what I am planning) - I don't think additional policy is needed for that, because they are "local" packages, so it is a matter of "local" policy. Cheers, - Jim pgps2YHr5ndAl.pgp Description: PGP signature
Re: Time to say goodbye...
Christian Schwarz <[EMAIL PROTECTED]> writes: > The discussions of the last days have shown me clearly, that I can't > implement my ideas WRT policy/QA anymore. > Therefore, I've decided to leave the Debian project. Sorry to see you leave. I must admit, I've been entirely negligent in following the policy discussions - due to lack of time, I've skipped them entirely. Instead, I've been relying on you to form a consensus and write them up into official policy. I suspect that most of the other "older" maintainers are the same way - they've skipped the policy discussions altogether - which would explain your perceived lack of support. I discovered about a year ago that the policy discussions are very draining and mostly negative, and seldom go anywhere. The only people who get anything accomplished in Debian are the people who actually do packaging and coding (although having a policy editor role is still important). I don't know how you held out for so long. Perhaps, instead of leaving Debian completely, try this -- just resign as the Policy guy first, and continue as a regular developer. I think you'll find it to be much more relaxed and enjoyable. This project is infamous for letting people "burn out" unnecessarily. Cheers, - Jim pgprDA7ghvuct.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
Hamish Moffatt <[EMAIL PROTECTED]> writes: > I think smail or exim would do fine. I'm in love with exim myself. :-) The whole exim package is about 500k, which only takes 5 minutes or so to download via modem - so I'd probably stick with that (unless something better comes along). MTA choices are easy, because there is very little user-visible stuff involved. The choice of a single MUA will be much more contentious. Cheers, - Jim pgpQamcOAgCHt.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
John Labovitz <[EMAIL PROTECTED]> writes: > Jim Pick <[EMAIL PROTECTED]> said: > > > The whole exim package is about 500k, which only takes 5 minutes or so > > to download via modem - so I'd probably stick with that (unless > > something better comes along). MTA choices are easy, because there is > > very little user-visible stuff involved. > > have you looked at ssmtp? i just took a quick look at the source, and > it seems that it's *extremely* simple -- sounds like a good one for a > send-only MTA. I haven't looked at it. It's only 15k! That would be a really good choice if it actually does the job. :-) Cheers, - Jim pgpfQROkXt0Ry.pgp Description: PGP signature
Re: Yet another Linux distribution! :-)
> > What news servers besides slrn support reading news directly from the news > > spool w/o a news server? > > tin (rather than tin -r or rtin). Gnus (in emacs). Cheers, - Jim pgppKPgXPsA90.pgp Description: PGP signature
Re: And now for something completely different... etch!
On 06/22/05 12:02:53PM -0500, Manoj Srivastava wrote: > On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein <[EMAIL > PROTECTED]> said: > > >> > - inetd begone! -> xinetd (better mechanism to control DoS, > >> > separation, etc.) > > >> xinetd begone. There is no justification for using anything > >> resembling inetd on a modern system. > > > What planet do you live on? I want MORE use of inetd, not less. I > > want to be able to select a service, and tell the system whether I > > want it running all the time, or only when needed. > > Why? What you offer here are preferences and opinions, with > nothing to back them up. Previous posters in the discussion have > offered reasons not to use inet daemons -- off the top of my head, it > was a) in the current day and age, an idling daemon does not consume > a significant amount of resources, b) a inted daemon adds complexity > to the mix, and another point of failure/attack c) It adds latency to > response for the daemon (I may have missed other points). > > What do you have to counter these points? I can speculate that > you may disagree with point a above, but if so, I think in my > experience point a has been justified. >From the security aspect using xinetd automatically gets you things like connection rate limiting, tcp wrappers support, source address restrcitions, available time restrictions, connection logging, interface binding, etc. Sure some daemons already sport those options, but not all do and if a standard is to be chosen it should be safer one. If you know the service well enough to configure it you probably also know how to disable the xinetd instance and enable the init script. > > manoj Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of inetd for etch
On 08/15/06 09:49:54AM +0200, Andreas Metzler wrote: > Hello, > This seems to be totally overengineered. Having MTA a provide sendmail > which uses MTA b for remote deliveries is no common usage scenario on > which any effort should be spent in the Debian packaging > infrastructure. > > Actually the only sane explanation for wanting to install two MTAs I > ever heard of was "I am running X now and want to switch to Y. - I'd like > to test Y in the real system before going live." > I know of at least one firewall product that includes 2 copies of sendmail, one for accepting messages from the Internet and one for processing and sending them to the internal servers. They do this along with an RBAC system like SELinux so that break into the network via sendmail is virtually impossible since even if you break into the externally accessible sendmail you can't go any farther. Whether Debian should work on making this possible too or not, I can't say. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On 08/26/06 03:26:12PM +, Sam Morris wrote: > On Sat, 26 Aug 2006 16:02:04 +0200, Hendrik Sattler wrote: > > Am Samstag 26 August 2006 15:15 schrieb Theodore Tso: > >> No support for: (The * are critical) > >> > >>* SATA Hard Drives (*) > >>* Intel AD1981 HD Audio (*) > > > > This stuff did not even exist when Sarge was released. Half of userland > > would > > not fit this hardware, so who cares. > > How do other long-lived distributions handle this problem? How does one > install RHEL 4 on such a machine? RH releases updated install discs periodically. I haven't had any hardware issues with them so I never compared the contents of the discs but I would assume that they update the kernels with each update release. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Desktop task(sel) in Etch? (Bug #389092)
On 09/26/06 02:25:21AM -0700, Steve Langasek wrote: > On Tue, Sep 26, 2006 at 09:12:58AM +0200, Christoph Haas wrote: > > What I would expect at least: > > Rename the task from "Desktop" to "Desktop (Gnome)" so more experienced > > users know what's coming up. > > Should we also have "Mail Server (exim4)" and "Mail Server (postfix)" for > the same reason? > The difference here is that removing exim4 and replacing it with postfix is a lot less work than it is Gnome->KDE since you can't just remove the 'gnome' metapackage and have all of Gnome be gone. If there was an easy way to do that I doubt anyone would care what the default choice was. Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
