Re: [desktop] foomatic-gui is born
On Wed, Nov 27, 2002 at 10:13:22AM -0200, Gustavo Noronha Silva wrote: > Em Wed, 27 Nov 2002 02:21:47 -0600, Chris Lawrence <[EMAIL PROTECTED]> > escreveu: > > > Yes, some sort of "su to root" prompt is probably a good idea; dunno > > if I can reuse the existing code or what. If not, something similar > > probably won't be hard to whip together (although I guess we probably > > have half a dozen "graphical su"s in Debian already). > > > > FWIW, the GNOME System Tools root prompts don't seem to work for me... > > > > Probably the best approach would be to use something like gksu in the > > menu entry; why reinvent the wheel? > > It would be good if we had a standard way of doing that... I talked to > walters about this some weeks ago, and he suggested it would be a good > thing to merge xsu, gnome-sudo and gksu (maybe others?). FWIW, I think this is very important... Something that (e.g.) Mac OS X has over linux is an elegant way to acquire (some) admin privileges in a graphical context. I think Debian needs this badly... Jules
Re:
On Tue, Jan 15, 2002 at 01:56:39PM +0100, Anton Feldmann wrote: > Sehr geehrte Programm bereitsteller, > > mein Name ist Anton Feldmann. Ich hätte gerne von ihnen gewust wann > woody frozen ist. Guten Tag. This is an english-language mailing list; please post in English here. The woody freeze has started, but progress is currently slow. I would be inclined to estimate that it won't be ready for Easter, but might be for summer. Jules
Re: Will woody ever become stable?
On Mon, Jan 14, 2002 at 02:49:00PM +0100, Adrian Bunk wrote: > I had a longer discussion with our release manager who said in this > discussion that there's no progress in the freeze of woody. We won't enter > the next stage of the freeze until the base and standard packages are in a > releasable state - and the number of RC bugs in these packages is > increasing (one reason is e.g. that some of these packages like > boot-floppies break when new upstream versions of other packages they > depend on are uploaded which may lead to RC bugs like #127405). woody is > officially frozen for several months but it's still possible for new > upstream versions of every package to enter testing. Hmm. I'll bite. I would like to ask our release manager for more information. More effort is required to herd the kittens. I really don't feel in-touch with how the freeze is going, and I imagine that I'm not alone in that. For example, I think I thought that Adrian is incorrect above, that certain packages are frozen. I thought I'd seen notes suggesting that some packages were frozen, in fact. Base? I would like to see weekly 'freeze update' reports, sent here, telling us what goals have been passed, and what the current stopping points are. Something like the following: Freeze Update - Status We are *still* trying to freeze standard and the task packages. This won't be possible until they are cleared of RC bugs ... ... Uploads Maintainers of base packages should only upload security fixes and fixes for serious bugs. These should be uploaded to woody-proposed-updates. Maintainers of standard and task packages should try to avoid new code, and work to fix bugs. Maintainers of (non-task) optional and extra packages should, at the moment, continue to track new upstream versions, but should also work to remove RC bugs. ... Or something like that. Is the above even a correct depiction? I don't know... Herd us harder! ;-) Jules
Re: Appropriate? mutt/mailx requires mail-transport-agent
On Mon, Jan 07, 2002 at 03:48:53PM -0800, [EMAIL PROTECTED] wrote: > Thanks for the replies. I believe that my confusion was founded in > the idea that an MTA both sends and receives mail. The ssmtp package > is an appropriate provider for the sendmail portion of the > mail-transport-agent without the corresponding burden of a local mail > receiver. ObPedant: Actually, the job you're describing isn't properly that of an MTA, rather an MSA: Mail Submission Agent. But in Debian terms they are unified. There are actually three jobs: MSA, MTA, MDA, for submission, transmission, and delivery. Sendmail and exim are all three of these (or, can be configured to be all three). ssmtp is, I believe, just an MSA. Jules
Re: Quake 2 sources GPL'd
On Sat, Dec 22, 2001 at 01:42:41PM -0500, Ben Collins wrote: > gcc to meet those same requirements? You do realize that there are > plenty of free levels out there for quake2 right? We don't have to > distribute that same code just to put quake2 in main. And do you realise that none of those levels is *any* use *at* *all*, without the commercial game data? The code simply won't load levels, as it stands, unless it has loaded the game data. Even if that protection feature was disabled (trivial, certainly) it still wouldn't work: all such free levels require some stuff from the commercial data, the weapons, the models, the textures, etc. Jules
Re: Quake 2 sources GPL'd
On Sat, Dec 22, 2001 at 11:06:11AM -0500, Ben Collins wrote: > On Fri, Dec 21, 2001 at 11:57:21PM -0800, Thomas Bushnell, BSG wrote: > > > > Ben Collins <[EMAIL PROTECTED]> writes: > > > > > That's not true. If it is possible to create game levels for it that are > > > free, than it is considered free. It's not like you can't get anything > > > but id's game data. > > > > I think it depends on whether there are any actual game levels around > > which are free. > > > > The distinction between contrib and main is not whether it is > > *possible* to create something free which the contrib software would > > be useful for; it's really whether there *is* such a thing. > > > > If the only practical use of the engine is to run non-free levels from > > id, then it belongs in contrib. If someone has levels (that at are > > all fun--that is, which are real games) which the engine works with, > > then it belongs (along with those levels) in main. > > So if I create a game with _no_ levels, but the tools to create them, > then is it none-free? Just because the only ones available are non-free, > doesn't preclude that it is possible to create your own. The engine has > much more uses than just to play games (as the README in the source > says, also for educational purposes). But the binary doesn't have educational purposes. The binary simply won't run, without some data files. I don't know if there's a freely downloadable shareware one like there was with quake1. Certainly I don't see how we can, in main, distribute a binary that does nothing but give an error message and exit. I could see it as a source-only package, though. Jules
Re: Quake 2 sources GPL'd
On Sat, Dec 22, 2001 at 09:51:17AM -0500, David B Harris wrote: > On Sat, 22 Dec 2001 14:37:48 +0100, > Peter Makholm <[EMAIL PROTECTED]> wrote: > > > There's no reason why the engine itself can't be included in Debian, > > > as far as I'm concerned. It doesn't absolutely *have* to have game > > > data, to > > > > But thats is an argument for putting all the stuff in contrib into > > Debian main. > > Like I said, if you look at it from an educational percpective ... :) > > But yeah, I see your point. I think in my mind the big difference is in > probability. Look at Lyx. It's in contrib because it requires libforms. > Upstream isn't interesting in rewriting it to not use libforms, and I > don't see any volounteers to come up with something a la lesstif. FYI: Upstream *is* rewriting LyX not to use libforms. And, also, libforms will be free software in the forseeable future, very likely. Either way, woody+1 will have lyx in main. Jules
Re: Potato to Woody upgrade problem
On Tue, Sep 25, 2001 at 09:28:39AM -0400, Dale Scheetz wrote: > > Now I seem to have some font problems. Netscape seems to be OK, but the > GIMP comes up with [] [] [] [] [] in place of the hint text. The title > bars are OK but any "filled in" text is just [] repeated. Any hints? Branden gives a detailed answer. I will add that for me, ensuring that I had 4.1 versions my X sever, my x font server, and the X fonts packages, and then restarting the machine (or, preusmably, just the appropriate servers) fixed the problem. Jules
Re: new port: and the winner is....
On Fri, Sep 21, 2001 at 05:00:48PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 21 Sep 2001, Richard B. Kreckel wrote: > > The social contract says "Our Priorities are Our Users and Free Software". > > Such a win-port might indeed serve some users. But for my own part, I do > > have some personal problems with making all free software win-compatible. > > Does it serve Free Software? Such ports frequently lead to crippled > > design [1] and frankly, I do not like to give people more excuses for not > > switching to an entirely free OS. > > Well, we cannot have Debian that runs over the Microsoft Windows(TM) kernel, > since the Windows kernel is an extremely non-free component, and nothing on > Debian can have a dependency on non-free *software*. Therefore there will > never be a Debian for arch "Windows" (or whatever it gets called). This view may be a little narrow. Many of the current debian architectures depend on non-free software in the bootstrapping process (e.g. BIOSes). And don't forget that before linux, free software was developed on non-free OSes most of the time... Jules
Re: Bug#66135: libtool_1.3.5-1(unstable): wrapping of binaries fails with -D__LIBTOOL_IS_A_FOOL__
On Fri, Sep 21, 2001 at 08:06:19PM +1000, Herbert Xu wrote: > Brian May <[EMAIL PROTECTED]> wrote: > > > > This "bug" is only because of debian/rules which continue to use an > > obsolete (and no longer required) hack in order to remove unwanted > > -rpaths. > > > Just remove the hack, it is no longer required. It no longer serves > > any useful function either. > > False. The rpath bug is still there. OK. Well why don't you explain, either here, or in bug 66135, how the bug is still there and what should be done? The simple statement that Brian's comment is 'False' doesn't really move us forward... Jules
Re: Graphing Debian Lists
On Fri, Sep 21, 2001 at 10:38:48AM +0200, Gerfried Fuchs wrote: > subscriptions add and unsubscribes substract from there. A graph for a > statistic is worth nothing if it doesn't have the zero point in it. > First unit statistics lesson. Rubbish. The correct lesson is to learn to always look at the scale before drawing conclusions. Once you've learnt that, graphs without a zero point have a place: they show more details. There is certainly no law against them. Zero-point graphs would make it easier to compare the different graphs, certainly, if that's what one wants to do. Personally the thing that jars me is the inconsistency: some graphs are scaled so that their vertical variation is more-or-less full range, whilst others take only a small percentage of the vertical height. But there is a limit to the amount of time it's fun to spent meddling with rrdtool options... Jules
Re: sysctl should disable ECN by default
On Fri, Sep 07, 2001 at 10:02:48AM -0500, Nathan E Norman wrote:
> Nazis. Hitler. Microsoft rules!
>
> (Die thread die!)
You fool you!
Godwin's law is powerless when deliberately invoked...
('s' a bit like the chronicles of thomas covenant, now I think about it)
Jules
Re: Student Looking for A Final Year Project
On Fri, Sep 07, 2001 at 03:18:35PM +0100, [EMAIL PROTECTED] wrote: > Hi > I'm a student at Kent University Canterbury UK I will be starting > my final year project some time next > year and I am looking to find a project that involves linux development > ideally kernel / module based or a port > of software to a specific platform. I am unsure as to what projects are > about as I have to do a unique project > and not a redevelopment of something that has already been done. Any > ideas. Well, that was a bit apropos of nothing... The most obvious think that jumps to mind in kernel development is to pick a random piece of unsupported hardware, reverse engineer its protocol and write a driver for it. For example, I believe there are quite a few unsupported digital cameras. Or perhaps lego mindstorms (or did someone already write a driver for that?). Use your imagination. Jules
Re: Base freeze on? Will autobuilders use it?
On Fri, Sep 07, 2001 at 09:50:14AM -0400, Peter S Galbraith wrote: > If they don't and rather continue to track unstable, then how > will new optional package enter testing before the `optional' > freeze? They may get built against library versions that aren't > in woody and thus never allowed to migrate to woody due to > unresolved dependencies? I keep asking this (or related questions) and no one seems to answer me ;) I think we need a fiat from on high. ajt? I believe the answer is that once base is totally frozen, there will be no new (unstable) versions of the libraries, so that the problem won't occur. Jules
ANother library problem: autobuilder for i386?
I just had to recompile balsa to make it installable again, after another of these volatile gnome libraries changed soname on me in sid. It was just a simple recompile, no source changes except the changelog. Of course, it's going to trigger recompiles on all the other architectures. And some of these may even be unnecessary, since the other architectures may have happened to do their recompiles *after* the new libraries were installed. Which made me think: It would be really cunning if there was an i386 autobuilder to do that for me, so I didn't have to waste bandwidth (and a version bump) on a version which isn't actually different. In principle, at least, there could be something which checked whether a recent sid install had rendered any other packages uninstallable (as the install of libgtkhtml15, which purged libgtkhtml14, had rendered balsa uninstallable). If so, it could attempt to auto-build it. If the auto-build didn't go through it could email the maintainer, file a bug, whatever. More extremely, it could trigger a rebuild whenever a source dependency increased its version (since the new version of the source dependency is what any *user* would get trying to compile from source). Thoughts? As an afternote: Yes, I know that my particular problem wouldn't happen if the gnome library maintainers did the 'oldlibs' trick keeping old libraries around. But I think it's fairly well accepted that that's not desirable at this stage of rapid development. Jules
Re: Fonts working "out of the box"
On Wed, Sep 05, 2001 at 11:45:38AM +1000, The Nose Who Knows wrote: > > What would be the best way of approaching these people who may find that > Free licenses are the best way to distribute their work? If we find > that fontographers are interested, we may gain a lot of good quality > work quite rapidly. Write them an email stressing the practical advantages, without boring them too much with a free software diatribe. For example, point out to these designers that if their fonts are DFSG free, they can be distributed with Debian (and Redhat and anything else) which will make the useful to a huge group of people who might not have heard about them otherwise. By all means post a draft of the letter here for comments. Jules
Re: Two sets of binary packages from one source package?
On Mon, Sep 03, 2001 at 05:00:58PM -0400, Colin Walters wrote: > James LewisMoss <[EMAIL PROTECTED]> writes: > > > So my first inclination is just to stop producing the gnome versions, > > but several users have requested that I not do so. > > If the GTK+/GNOME version of XEmacs isn't really usable, then it would > probably make sense to stop producing those packages until woody is > released. Or upload GTK+/GNOME versions to some other location, e.g. experimental, or your people.debian.org homepage. Jules
Re: Which versions of libraries are developers supposed to compile against?
On Sat, Sep 01, 2001 at 08:15:11AM -0400, Sam Hartman wrote: > Basically once your library is frozen don't upload major changes to > unstable until the release. If you know what you are doing and fully > understand the issues involved you can actually get away with a fair > bit more, but if you screw it up, there will be angry developers > lining up to flame you. OK, that's what I gathered would be the case. This seems a step back from the old freeze procedure, where you could upload to frozen (and, I assume, auto-builders were building against frozen) Jules
Re: Two debconf issues
On Thu, May 03, 2001 at 05:00:29PM -0400, Joey Hess wrote: > Wolfgang Sourdeau wrote: > > > It might happen if there was a good reason, but nobody has suggested one > > > yet. > > > I doubt there is one. > > > > I have one. It's that dependency on perl makes owners of 486 machines die > > of an heart-attack whenever an installation task has to occur... > > Bollocks. Profile running perl sometime. Then profile running dpkg. Let me second this. Perl is very, very fast. Perl is faster than most people's hand-crafted C code for certain tasks (mainly pattern matching type tasks, also its associative array implementation is pretty nippy). On my 68020 machine, using a short perl script was an order of magnitude faster than sed or awk, even for exactly the kind of pattern matching tasks that sed and awk are designed for. Perl ain't your problem, it really ain't. Jules
Re: Gnome bug 94684
On Fri, Apr 27, 2001 at 07:04:52PM +0200, Christian Marillat wrote: > >>>> "CW" == Colin Walters <[EMAIL PROTECTED]> writes: > > CW> Jules Bean <[EMAIL PROTECTED]> writes: > >> Programs shouldn't gratuitously break configurations which worked. > >> When woody is released, and people upgrade en masse to it, they will > >> want their configurations to carry on working. > > CW> In my experience, GNOME has had this problem since version 1.0; almost > CW> every time I've upgraded, something has broken. Most of the time I've > CW> just given up and nuked ~/.gnome and ~/.gnome-private, and then > CW> recreated my desktop configuration. > > CW> It doesn't seem very reasonable to expect the Debian packagers to try > CW> to fix upstream bugs like this. > > Ha, somebody understand me :) In which case, it's perfectly reasonable to just leave the bug open and not fix it. But don't close it. And do forward it upstream. Jules
Re: Gnome bug 94684
On Fri, Apr 27, 2001 at 12:08:31PM +0200, Christian Marillat wrote: > "TB" == Thomas Bushnell <[EMAIL PROTECTED]> writes: > TB> I'm perfectly happy for him to just do (3). But what he wants to do > TB> instead is declare real bugs non-bugs, on the grounds that he "can do > TB> nothing". If he can't even forward bugs upstream, there is a serious > TB> problem. > > *You* are a serious problem. What an unpleasant, and ridiculous, thing to say. Thomas is perfectly right that it's reasonable to report upstream bugs to debian, and expect them to be forwarded -- it is one of the jobs we carry out as maintainers. > > If you don't want to change your configuration each time you did a apt-get > upgrade, then install potato. Rubbish. Programs shouldn't gratuitously break configurations which worked. When woody is released, and people upgrade en masse to it, they will want their configurations to carry on working. Some debian packages, (postgres) when the changes to file formats are sufficiently complex, have contented themselves with warning the administrator that he'll have to fix things by hand. But the approach of breaking the configs without telling anyone you've done it, and without providing an upgrade path, is broken. Especially in apparently stable (as in, ready for every day use) software. Sawfish is apparently stable, and many people use it everyday. Upgrade paths can bee hard work --- possibly harder work then they seem to merit --- but it is something that debian has often been good at. If you don't want to/can't do the work, then fair enough. But leave the bug open. It is a bug. And don't insult users/fellow developers like that. Jules
Re: KDE2 - nice demolition job ...
On Mon, Sep 11, 2000 at 10:01:11PM -0700, Debian Linux User wrote: [snip] > > Please read: http://nm.debian.org > > > > -- > > Raul > > > > Oh well, at least nobody can say, "Well, nobody ever said anything ... ". > I tried. Well, what, exactly? Would you mind actually telling us what you mean? I thought Raul's email was to the point. The NM process is documented, there is a mailing list for its discussion, new maintainers are on their way in at an increasing rate: What exactly is your problem? Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-get and proxy
On Wed, Sep 13, 2000 at 07:55:11AM +0200, Andreas Tille wrote: > Hello, > > I'm in real trouble with apt-get and a squid proxy. First of all > I found out that in contrast to the manual of apt.conf the environment > variables > > ~# set | grep proxy > ftp_proxy=http://wr-linux01.rki.de:3128/ > http_proxy=http://wr-linux01.rki.de:3128/ In shells I've used, 'set' gives you the list of shell variables, not environment variables. Try 'export http_proxy' and/or 'env | grep proxy'. http_proxy has worked for my apt fine for well over a year now... Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian and KDE
On Thu, Sep 07, 2000 at 12:51:23PM -0300, Ben Woodhead wrote: > >From the article I have read about debian Stand On KDE, which said that > debian would like to help kde get there license issues resolved so kde could > be put into debian. Perhaps, that was not the case, and debian just wanted > to kick kde because you guys don't like it and the license issue was just a > reason for the kicking. You should be careful making allegations like that. It makes you sound like a... no, I won't use words like that on a public mailing list ;-) > If I was wrong, I would have expected to see some news on the homepage > saying "Yeah, KDEs is completely GPLed and will be included in debian", or > at least something like that. After all the reading I did where debian was > saying that they would love to have kde but its not free. Well its FREE know > and I still don't see any of the people that where complaining about the > license saying something about it. Don't you? Maybe you've been looking in the wrong place. It was discussed three time on this mailing list, which is public, and the KDE debian maintainer has been openly discussing his plans to upload Qt and KDE to main shortly. > >From my guess, I would say all the people that where talking about the > licensing issues are know just trying to think of something else to bitch > about. Well, maybe you should your guesses to yourself if you're just going to be rude. > Debian stands for something and I am proud of that, after all everybody else > jumped on the bandwagon for making money but Linux did not get this far from > money, they got here for the opposite reason. But I also think its about > time to say, great TrollTech caved and fixed the license, so you won and > that is GREAT, but its time to be real winners and say KDE is now free and > has the debian approval. After all that was (supposedly) the only problem. It indeed was the only problem, and KDE is going to be installed in debian. One of the several threads on debian-devel which made it quite clear that this is going to happen is archived starting at http://lists.debian.org/debian-devel-0009/msg00329.html So lets stop mudslinging, no? Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with mail system? [Fwd: Returned mail: User unknown]
On Thu, Sep 07, 2000 at 12:33:21PM +0200, Marco d'Itri wrote: > On Sep 07, Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > > >This is just your standard lack of reverse DNS.. Part of the anti-spam > >bit. The sender needs to get working reverse DNS I suppose.. > Looks like a stupid check, to me. It is. > Some very big ISP here have mailservers with no reverse mapping... Well, they are badly broken, you know? The IANA mandate is that /all/ machines on public IP address have reverse mappings. No exceptions. I won't rehash the old debate over whether it's better to tolerate broken behaviour (better resilience) or force broken behaviour to break worse (often the only way to force incompetent idiots to fix things). Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python 1.6 released and GPL incompatible
On Wed, Sep 06, 2000 at 11:43:21AM +0200, Gregor Hoffleit wrote: > Still, if 1.6 were to replace 1.5.2, we had to check all packages that > depend on Python, if we think their license is still compatible with the > new Python license, and remove them if it's not. I'd opt against this. Yup, that sounds bad. > 2) Include both Python 1.5.2 and 1.6 in woody/main. The 1.6 packages >would not satisfy the dependencies of existing packages; any maintainer >who'd make a package depend on Python 1.6 would have to make sure that >its license is compatible with the Python 1.6 license. Install in a parallel tree (/usr/lib/python1.6, e.g) and use alternatives to manage /usr/bin/python, so that someone can install 1.5 and 1.6 side-by-side. This would be my favoured solution. Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debhelper or fakeroot problem?
On Wed, Sep 06, 2000 at 05:51:28PM +0900, Atsuhito Kohda wrote: > From: Henrique M Holschuh <[EMAIL PROTECTED]> > Subject: Re: debhelper or fakeroot problem? > Date: Tue, 5 Sep 2000 23:08:55 -0300 > > > On Wed, 06 Sep 2000, Atsuhito Kohda wrote: > > > dpkg-shlibdeps: warning: unable to find dependency information for shared > > > library /usr/lib/libfakeroot/libfakeroot (soname 0, path > > > /usr/lib/libfakeroot/libfakeroot.so.0, dependency field Depends) > > [...] > > > What is the problem and is there anyone who encountered the same > > > problem? > > > > It happens here everytime as well, but I simply ignore it, as no bogus > > information (dependency) on libfakeroot is being inserted anyway. > > I see. And, yes, it does nothing bad in fact to a package > but it is annoying and makes one very uneasy. But it will be fixed in dpkg 1.7.0 which will use objdump not ldd. Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: GUI tools for common Debian admin tasks
On Tue, Sep 05, 2000 at 06:24:28PM +0200, Frederic Peters wrote: > So I drew the conclusion that what Debian needs for those users is simple > GUI tools. [some will respond here with "we don't want those users" and I > won't agree. This flamewar already happened. GUI tools doesn't mean you > have to use them. blah blah blah.] Warning: this is anecdotal. It's not a powerful logical argument. Beware. GUI admin tools are often written badly, they often fail to take into account every possible configuration and break strangely when invoked with a configuration they don't understand. They often have bugs, they often fail to give reliable or sensible error or status messages. In short, they often make the OS appear worse than it is: Redhat has a family of Tk GUI tools which, sometimes, exemplify this problem. Summary: If you write GUI admin tools, think very hard about how you will make them as robust and complete as the commandline ones. It is not easy. Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs
On Tue, Sep 05, 2000 at 02:00:42AM -0500, Joseph Carter wrote: > On Mon, Sep 04, 2000 at 11:54:05PM -0700, Joey Hess wrote: > > > Software has bugs, it's a fact of life. New software is more likely to > > > have unknown bugs that affect more people. What makes the Helix packages > > > so nice is the turnaround time for fixes. I don't know how they do it, > > > but they do. > > > > Maybe they have a dinstall delay of less than 24 hours :-P > > Maybe so. I'd still like to see someone take up maintenance of jinstall > and package it personally. I'd do it myself if I could grok the perl. > Perl so far is a language that I just don't understand. It defies the > conventional structured thinking I apply to the way I write my code. Well, if jinstall is badly structured, only I can take the blame ;-) However, it's a trivial pattern matching hack to move files into the right directories, and totally fails to do any of the clever stuff dinstall does. It did all I needed for gnome-staging at the time.. Jules -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: imap mailbox killer
On Thu, Aug 31, 2000 at 07:32:17AM -0400, Buddha Buck wrote: > > commands. So having extremely long X-Keywords in mail messages > > will screw things up. Double yuck. > > > > This is in imap-4.7c/src/osdep/unix/unix.c BTW. > > > > See the original message and the accompanying thread in debian-devel, > > archive/latest/67244 , Message-ID <[EMAIL PROTECTED]> from > > Cristian Ionescu-Idbohrn <[EMAIL PROTECTED]> > > This definately needs to be passed upstream... My mailbox was screwed > up as well, and I get my mail from a Solaris box, not a Debian one. My mailbox didn't get screwed up (thank god..) but I did get some very confused messages from Mutt. I though mutt was at fault, but evidently it was imapd... Jules
Re: Strange messages...
On Wed, Aug 30, 2000 at 04:17:42AM -0400, Dale Scheetz wrote: > Since my last upgrade to potato I've been getting a lot of messages like > the following: > > DEBUG: --Relation pg_rules-- > DEBUG: Pages 0: Changed 0, Reapped 0, Empty 0, New 0; Tup 0: Vac 0, > Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen > 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 [snip] > There doesn't seem to be any real information here. Can anyone tell me > what is triggering these messages? Well, they're from Postgres, I can tell you that much. Probably you have one of the debug trace options on in your postgres config files (in /etc/postgresql). HTH Jules
Re: FW: Firewall Project
On Mon, Aug 21, 2000 at 11:57:53AM -0700, Brent Fulgham wrote: > > > Can anyone comment on why Linux would be unsuitable for firewall use > > > in this configuration? > > > > Can you explain what an `active' packet is? > > > > That's my question as well. I can't find any reference to an "active" > packet definition. Could he mean some kind of "keep-alive" configuration? My guess (and it's only a guess) is that an 'active' packet (from the AS/400s point of view) is one sent down a connection that the AS/400 initiates, whilst a 'passive' packet is one sent down a connection initiated by the other end. In some primitive firewalling schemes connections can only be initiated in one directions (typically, in the case of a corporate firewall, only outbound connections). Needless to say, there is no 'limitation' of Linux in this respect --- a Linux firewall can be configured to forward and/or rewrite packets in any way desired. Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED]| technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: Compare .deb file to filesystem
> > I know debsums does part of this job, but AIUI only if the .deb > > contains md5sums information. > > > > This would be a useful tool for a maintainer with a complex package (I > > have an internal one here in mind) which he has been forced to edit > > the files 'in-place' to fix problems, and wishes to get a list of all > > files he edited. > > > > Does this exist? > > How close is debsums to what you want? It's close --- that's why I mentioned it --- but it requires the .deb to have md5sum information. This shouldn't be necessary, it should be simple enough to dpkg-deb -x the deb, then go through each file, comparing size and then contents (with `cmp'). Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED]| technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Compare .deb file to filesystem
This would be very easy to implement, so I thought I'd see if anyone else has already done it. I'd like a utility which takes a .deb file, another version of which is already installed. It checks (presumably by file size and md5sum) for all differences between the files on the file system, and the files in the deb, and lists them. I know debsums does part of this job, but AIUI only if the .deb contains md5sums information. This would be a useful tool for a maintainer with a complex package (I have an internal one here in mind) which he has been forced to edit the files 'in-place' to fix problems, and wishes to get a list of all files he edited. Does this exist? Jules
Re: NMU's completely removed from kaffe in woody
Woah. Calm down, everyone! On Fri, Aug 18, 2000 at 04:28:03PM -0400, Ben Collins wrote: > On Fri, Aug 18, 2000 at 03:06:55PM -0500, Ean R . Schuessler wrote: > > Well Ben, there are two reasons that I ignored the NMUs. > > > > The first reason is that Kaffe revisions have been so long in coming that > > the 1.0.6 source base bears little to no resembelence to the 1.0.5 > > source. Maintaining the patches that were done against 1.0.5 would be > > difficult at best and I was more concerned with getting 1.0.6 out so > > that people could use it. > > So superficial version numbers are more important than stability? I see. Rhetoric. In isolation, a new upstream version sounds like a good idea for woody; that's why we have unstable. > Problem is that the patches I applied to this had a lot to do with the > debian files (build failures because of faulty hard coded options). Which > means, you should have incorporated them. And this is a reasonable point. Ean, did you review the patches to the build scripts? > > So, in short 1.0.6 and the release after will both represent what are > > effectively new pieces of software and tracking bugs let alone source > > patches across those releases will be a waste of everyone's time. > > Hey, sounds _a lot_ like 10% of the rest of Debian packages! WOW. However, > that is no excuse to ignore a) valid patches and b) changelogs which > denote the history of the package as it pertains to Debian. Even if you > don't like it, it is still there, and should remain. Removing it in favor > of your personal image is not an excuse. I have to agree with Ben. The changelog should represent history. If a user with the current potato version upgrades, and finds the version he came from not mentioned in the changelog, he's gonna be pretty confused. > > > The second reason I chose to cut a lot of NMU changelogs was that you > > took it upon yourself to load them with vindictive, personal and > > unprofessional statements. Why you need to say things like "I wish the > > maintainer of this software would pay attention to his packages" in a > > changelog is completely beyond me. > > Vidictive? Hell, I could have said a lot worse. I don't think making a > request for some attention to your package was too much to ask. But it was the wrong place to make that request, and it does reflect badly on the project to have that kind of thing put in a place which, we agree, is supposed to be kept as history. > > > I insured that a 1.0.5 release was available days after it was > > released, as I did with 1.0.6, yet you continue to try and paint a > > picture of negligence. Frankly, it seems clear to me that its personal > > and I don't no why. Nor do I care. > > No, it's clear that removing patches and changelogs that I and others > took the time to NMU, was personal. It is not clear to me that either action was personal. Even if it was, perhaps we'll get a better distribution by working first on the assumption that it wasn't personal? > > > I spent all last week working in Transvirtual's offices, know Tim > > Wilkinson personally and have an active business relationship with TVT. > > I use Kaffe on a daily basis, package it for my own use and currently use > > it on a number of handheld devices including the MIPS platform (for more > > info see: http://www.pocketlinux.com). > > Irrelevant. No, it's not totally irrelevant. It may not excuse the fact that Ean altered the changelog and possibly ignored some useful patches, but it /does/ suggest that Ean may have the necessary experience, skills, and connections to make a good kaffe package. > > > In short, I don't want to belittle your comments but I would ask you > > to conduct yourself a little more professionally. At least try to bring > > issues to me (or at least debian-java) before you waste devel's time > > with issues that have little or no basis. > > Professionalism is what I did. I fixed the package, and made comments for > the maintainer. A simple request to do this yourself is not vindictive nor > unprofessional. Me having to do your job...now that makes you > unprofessional. Irregardless of how cozy you are with upstream companies, > you still need to fix bugs, not just killoff valid patches and work. On the other hand, being rude in the changelog is unprofessional, IMO. OK. None of the above is my business, to be honest, but it's out on an open list, so there you go. Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED]| technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: Implementing "testing" (was: Re: Potato now stable)
On Fri, Aug 18, 2000 at 09:26:34PM +1000, Anthony Towns wrote: > > Another reason to run unstable is to live on the actual bleeding edge: > testing will always be around two weeks out of date. That can be a fair > while, if you're impatient. > > Supporting this, there's some Apt changes in CVS that'll let people choose > a few packages from one distribution and leave the rest from another. Two > possibilities come to mind: either running "testing" most of the time, > but using a bunch of programs from "unstable" because you're interested > in their development; or running mostly from "unstable" except for a few > packages you can't afford to have break on that machine. Either way you > have a slightly larger buffer between an upload and it making it into > "testing". This seems to me to be important. Debian developers typically have to use unstable, or some of it, if they want to compile packages for unstable. This would allow us to pick-and-choose. For example, I maintain a couple of GTK packages and a GNOME package. I could use 'testing' mostly, but I could install 'unstable' versions of libgtk-dev, libgnome-dev. Then I can recompile balsa as necessary when new versions come out, and this might go some way towards eliminating the massive brokenness which strikes unstable when a new incompatible library version comes out (remember the libgtk1.1.17 era?). At least testing would be (almost) guaranteed a consistent set of packages. Also it's considerations like this which prompted me to start the 'gnome-staging' project when we had that big gnome upgrade. > > *shrug* If it turns out to be a problem, I think it'll end up being mostly > self correcting. And even if it's not, we're still in a better situation > than we are now because some bugs *definitely* won't make it into testing. Yes, you're right. Your suggestions certainly can't make anything worse than it is ;-) And they will probably make things better. I'm not convinced they're going to be the silver bullet for speeding our releases, but practical experience suggests that theoretical ponderings about the release process are almost pointless ;-) Jules
Re: Implementing "testing" (was: Re: Potato now stable)
On Thu, Aug 17, 2000 at 10:17:30PM +1000, Anthony Towns wrote: > Automated Process? > ~~ > So pretty much all the policy is encoded in some "automated process" > which updates testing. It works at the moment, basically as follows: > > 1. First, it loads up all the Sources and Packages files in > testing and unstable. > 2. It compares and contrasts them, working out what source > packages are new in unstable. > 3. For each of these new source packages it checks: > a. That the package has had two weeks of testing, > or it's a medium or high urgency package (and has > had either one week, or three days of testing). > b. That each binary has been recompiled for each arch > it's on. > c. That each binary has 0 RC bugs, or fewer than the > testing version does [4]. > 4. It then collects the source packages that pass 3, and > tries installing them in various combinations to see if the > number of uninstallable packages in "testing" either drops > or remains the same. If so, they're in. If not, they're not. I'd just like to bring up the only point which really worries me about all this... what is the incentive for people to run their machines on 'unstable'? Because a package lying for 3 weeks in unstable says nothing about it being bug-free if no one uses it... but if unstable is now going to be really unstable, I can see lots of the people who currently use 'unstable' using 'testing' instead, satisfying their need for bleeding-edge.. Jules
Re: Broken bootable SPARC CD#1, and why this happened
On Thu, Aug 17, 2000 at 04:10:53PM +0100, Philip Hands wrote: > It's almost impossible to remember all the little things that might go > wrong as well, so encapsulating that knowledge in a regression test > suit is definitely the way to go. In which vein, it might be helpful to have test machines around. Given enough warning, I'd normally be able to lend Phil a sparc for the duration of the CD test cycle, for example. Or it's possible that next year I'll have a sparc on a fast connection; one of the two. I suggest that before next time we go through this rigmarole we try to isolate definite testing volunteers for each architecture (for slink, for example, Steve not only burnt some sparc CDs for me to test, but gave me a SCSI CD to test them with...). Jules
Re: [Possibly Clueless] Deb base ISO images
On Tue, Aug 15, 2000 at 02:26:33PM +0100, Chris Ball wrote: > Hi, to all, and congrats on the potato release. > > I've been browsing cdimage. Do we release a base system as a 30/40-ish meg > ISO that can network to enable apt handling retrieval of anything else? One > would be really useful to me, and I'm sure to others too. The base packages > (for floppies etc) aren't always so easy or convienient, and I think an ISO > image would be a really good way to show the power of apt-get etc. > > I'll stop here, in case I'm being totally redundant or Just Plain Wrong. > Please let me know either way. If there isn't such an image available, why > was it decided against? I don't know the answer to your question, but I will point out that given a machine with a 'standard' ethernet card, and 'standard' disks, you can install off two disks (rescue and root from the images-1.44/compact directory), if you have ethernet access to a mirror. I don't know enough about CD building to know how hard it is to build cut-down bootable CDs. Jules
Re: Debian and GNOME, partnership with Helixcode?
On Wed, Mar 22, 2000 at 08:18:00AM -0500, Miguel de Icaza wrote: > > > We have done, in the past. I started a movement which ended with > > gnome 1.0 debs on gnome.org, if I remember correctly. Miguel - if, at > > release time (e.g. of 1.2 or 2.0) you want debian packages, the place > > to bug is [EMAIL PROTECTED] > > I am sorry, but I can not chase people down, much less at release > time. We did release October GNOME in October. Absolutely. It's not your job to chase us down. But you could send of a brief email saying 'official release is approaching, we'd like to have some .debs on gnome.org, could you provide them?'. Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED],jellybean.co.uk} | technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: Debian and GNOME, partnership with Helixcode?
On Tue, Mar 21, 2000 at 08:31:01AM -0500, Miguel de Icaza wrote: > > > The Debian packages, however, are *not* found in the GNOME ftp > > site. Why aren't they included and mirrored? > > Because nobody did contribute them. Every binary on the site was > contributed by someone. For example, recently we got mail from a > TurboLinux user, and he provided us with the packages for TurboLinux. > We have done, in the past. I started a movement which ended with gnome 1.0 debs on gnome.org, if I remember correctly. Miguel - if, at release time (e.g. of 1.2 or 2.0) you want debian packages, the place to bug is [EMAIL PROTECTED] Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED],jellybean.co.uk} | technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: ITP: GOB [Was: Re: GOB package?]
On Tue, Mar 21, 2000 at 04:26:37PM +, Mark Brown wrote: > On Tue, Mar 21, 2000 at 09:38:50AM -0500, Peter Teichman wrote: > > > A quick search through debian-devel and wnpp yields no ITP for > > Indeed. I'd been wondering if it were packaged under an unusual name or > something. > > > gob.. Maybe someone would like to pick it up? > > I'll do it myself if nobody else has a burning desire to, although quite > probably on the basis that anyone else who wants to take it is welcome > to. > > >From the web page (http://www.5z.com/jirka/gob.html): > > GOB is a preprocessor for making GTK+ objects with inline C code so > that generated files are not editted. Syntax is inspired > by java and yacc or lex. The implementation is intentionaly kept simple, > and no C actual code parsing is done. > > The license is GPL. This would be mildy convenient for me, since the next major release of balsa may require, or simply prefer, GOB, to build. [*sigh* why not just blasted use C++] Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED],jellybean.co.uk} | technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: Non-Debian Debian Packages (maelstrom and libsdl)
On Tue, Mar 21, 2000 at 12:42:52PM +, Christoph Baumann wrote: > Hi! > > I just came across some strange debs on > http://www.devolution.com/~slouken/SDL/download-1.0.html > > and > http://www.devolution.com/~slouken/Maelstrom/binary.html > > > I downloaded and extraced them. They aren't policy compliant and contain > evil dependencies. e.g. the maelstrom package has this: > Depends: sdl1(>=3D1.0) > sdl1 isn't a official Debian package it should be libsdl1. > As I'm the maintainer of maelstrom I'm rather concerned. I will now > contact this "maintainer". Well, be polite. There's nothing wrong with sam (or someone he knows) doing unofficial debs of hist software. If I were you, I'd just make him aware of the duplication of effort. Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED],jellybean.co.uk} | technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: Free Documentation License
On Sat, Mar 11, 2000 at 04:54:20AM -0800, Joey Hess wrote: > Jordi wrote: > > Should this new license be included in base-files? > > That seems very premature. Best wait until > > 1) It is a common-license > 2) debian-legal has vetted it > > Personally, I have to wonder if this type of thing is DFSG-free: Since it doesn't apply to software, that's a non-issue. It does, once again, re-raise the issue of whether we need to a) extend the DFSG to cover documentation, or b) establish some kind of debian guidelines for acceptable document licenses. Note that we do include a variety of textual works (documents) whose license doesn't comply with the DFSG. [As an aside the quoted problem isn't a restriction on use, it's a restriction on printing --- i.e. copying --- and it only requires you to acknowledge something, which we normally say is fine. But I didn't look closely yet]. Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED],jellybean.co.uk} | technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: spamblocking the lists
On Wed, Mar 08, 2000 at 03:28:37PM -0500, Joe Block wrote: > Jules Bean wrote: > > > > On Wed, Mar 08, 2000 at 10:45:07AM +0100, Nils Jeppe wrote: > > > On Wed, 8 Mar 2000, Stephane Bortzmeyer wrote: > > > > > > > > Can we please close the list from non-member submissions? > > > > > > > > NO! > > > > I, like many users of Debian, post from different mail addresses. Lists > > > > which are closed that way are really painful. > > So sign on with multiple addresses and set all but one nomail. It's > ludicrous to subject everyone to spam just to make things convenient for > a minority of users, especially if a fix exists that only those people > affected by the spamblock will have to implement. [meta: this question is inappropriate for this list, but I can't resist answering. Maybe we need a debian lists FAQ] There are a variety of perfectly valid reasons to post to a list you aren't subscribed to. From time to time, interested members of the free software community cc: an email to debian-devel because they want to alert us to some issue which is relevant. I very, very rarely get spam through -devel (or any debian list) and I don't have a problem with the current system. If spam is too much, then the solution, I suggest is to use the various blocking lists (maybe we do) and just possibly, in extremis, require explicit addressing as I suggested earlier. Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED],jellybean.co.uk} | technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: magnetic synchronous motor water pumps
On Wed, Mar 08, 2000 at 02:43:37PM +0100, Nils Jeppe wrote: > On Wed, 8 Mar 2000, Jules Bean wrote: > > > Making valid and useful actions impossible is not the way to fight > > spam. To fight spam, our spam-masters work quite hard to block open > > relays, etc. > > Alright, I really don't care as long as I don't get it in my mailbox. ;-) Delete it. It's not that hard. The spammers win if you waste time talking about them. If you just delete the mails immediately, it's easy. > > > One possible technique we could employ is to require that the list > > address appear visibly in the headers (to: or cc:). This would > > prevent Bcc'ing the lists which is a shame (and care would need to be > > taken with -private, which is also security), but it might be worth > > it. > > This is hardly a real solution. Spammers still could post stuff to the > list. > But they never do. [Most] Auto-spam software can't be bothered to fake the headers for all 100,000 recipients, so they send the same body 100,000 times. > > Do you use Orbs? Ask the listmasters. I dunno. -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED],jellybean.co.uk} | technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: Intent to package: src2tex
Takao KAWAMURA wrote: > Licence: > > Permission to use, copy, and modify this software and its > documentation is granted under no conditions. > > I will upload it to master in a few days. "..is granted under no conditions" reads like 'is not granted'. I.e., there are no conditions under which such license is granted. It isn't granted. A better phrase to use is "..is granted without restriction" Jules -- /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: An 'ae' testimony (SUMMARY)
Jules Bean wrote: > > I don't want to start a flame-war, so be gentle.. Oh well. I did, anyhow. > > I was just mindlessly (in a tongue-in-cheek way) evangalising Debian on > a mailing list I'm on, and I got a private response from a SuSE user. > He had installed Debian from a CD (he didn't say which version, I'm > afraid) and 'vi fstab' to mount his old partitions. > > Then he had attempting to do something which would have worked in vi (he > didn't give specifics) but doesn't work in 'ae', which resulted in the > file getting mangled, and saved. > > So he switched to SuSE. OK. We didn't really come to a consensus, be here's my what, IMO, best summarises our opinions: 1) If we don't have vi on the disks, we shouldn't pretend to. So, the vi-compatibility mode goes. (Has gone.) 2) We choose between 'ae' and 'ee' on their merits. At the moment, 'ae' is in the ascendant. If an 'ee' fan creates a version of 'ee' which fits on the floppies, and is sufficiently functional, maybe that'll be OK. Any other editor is also a candidate here, but we have space problems. 3) We ought to have at the back of our minds the possibility of separating the boot and rescue floppies. 4) We ought to investigate the possiblity of a CD-ROM based boot/rescue using more space, and hence giving us a better selection of editors. The bottom line, IMO, is that the vi-emulation mode caused more harm than good. I think the example I started the thread with was important, and only one person seems to disagree. Jules -- /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
An 'ae' testimony
I don't want to start a flame-war, so be gentle.. I was just mindlessly (in a tongue-in-cheek way) evangalising Debian on a mailing list I'm on, and I got a private response from a SuSE user. He had installed Debian from a CD (he didn't say which version, I'm afraid) and 'vi fstab' to mount his old partitions. Then he had attempting to do something which would have worked in vi (he didn't give specifics) but doesn't work in 'ae', which resulted in the file getting mangled, and saved. So he switched to SuSE. I'm aware this isn't a particularly helpful post - I'm not suggesting a solution, I don't know what the solution is. But it makes you think. Jules -- /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: (LONG) Correct non-US solution
Antti-Juhani Kaijanaho wrote: > > On Wed, May 19, 1999 at 08:26:21AM -0500, Richard Kaszeta wrote: > > Note that CTAN recently has split their archive into main and non-free > > trees based upon licenses like we do. :) > > Yes, I've noticed it. > > What criteria do they use? The DFSG? The OSD? A YAFSG (yet another > free software guideline)? > The DFSG (I posted this information to -devel about 2 weeks ago) Jules -- /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: jdk not working in potato, working jdk removed from incoming, license problem
"Seth M. Landsman" wrote: > > > Basically, we're in BLATANT violation of the license currently. It states > > quite clearly that redistribution is prohibited. So, plain and simple, > > we're shit out of luck. As someone else pointed out, Kaffe is just as > > good, with better response. But either way, we have to lose jdk or > > convince Sun to grant us special permission to redistribute. > > What is wrong with distributing an installation package like is > done with netscape and realaudio? > > For the record, kaffe is *NOT* as good as the blackdown JDK. I > have used both, and, as it is, kaffe crashes before my research system > loads, yet the blackdown jdk works flawlessly. So report the bug to the kaffe people, and then they'll fix it, and then kaffe will work for your research project. IMO, of course, kaffe is far better than JDK. Because it's GPL'ed. You don't have to agree :-) Jules -- /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: jdk not working in potato, working jdk removed from incoming, license problem
[EMAIL PROTECTED] wrote: > > 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. [This is intended to be a helpful comment - I hope it doesn't come across as a troll] Kaffe (www.kaffe.org) is, in my experience, a fast and efficient replacement for the JDK (1.1, some of 1.2 is implemented). It includes a native AWT and a JIT, and whilst performance isn't excellent, it's as good as jdk-interpreted, and it's open source. Completely. Including a reimplementation of classes.zip, clean-room, ground-up, with source code. The Kaffe team are, in my experience, swift to response to, and fix, bugs (more than you can say for Sun). So, if you have a Java project, at least assess whether or not it is feasible to use kaffe (and support open source!). Jules -- /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
[Fwd: New nonfree/ hierarchy on CTAN]
CTAN are adopting Debian's definition of free software! (Follow the links in this article, which was <[EMAIL PROTECTED]> in comp.text.tex yesterday) Jules (Any replies for me to read, Cc: I haven't (yet) resubscribed to -devel) Robin Fairbairns wrote: > > The CTAN team have been concerned, for some time, about the copyright > status of the material held on the CTAN archives. In the course of > preparation of the latest TeX Live disc, Sebastian Rahtz compiled a > list of the licence status of many available packages, and it is the > CTAN team's intention to extend that list to as full coverage of the > archive holdings as is possible. > > In parallel with this work, we have instituted a new hierarchy on > CTAN, called nonfree/; it is our intention to move all items, for > which there are significant distribution restrictions, to that > hierarchy. > > STRUCTURE > > The nonfree hierarchy mimics the structure of the main part of CTAN; > there are (or may in the future be) sub-hierarchies nonfree/biblio, > /fonts, /graphics, /indexing, /language, /support, /systems and /web > > For each entry in the non-free hierarchy, there is a corresponding > entry in the main part of CTAN, which is a symbolic link to the > nonfree/ hierarchy. Since CTAN does not index symbolic links, the > only appearance that a non-free item makes in the FILES.* files is its > instance on the nonfree/ hierarchy. The `quote site index' command > uses FILES.byname, so that it will always tell you if the item you're > seeking is not free. > > CRITERIA > > Licensing conditions that CTAN currently recognises are listed in > > http://www.tex.ac.uk/tex-archive/help/Catalogue/licenses.html > > In the terms defined therein, the nonfree/ tree will hold items whose > licensing is unknown, nocommercial, nosell, shareware, or other. > > Notes: > > 1. CTAN cannot hold matter whose distribution is restricted, anyway: > the archive has no control over what its mirrors might do. This is > why there is no category `nodistribute'. > > 2. The `nonfree' licensing category nosource _does_ stay in the main > CTAN tree; there are usable items on CTAN whose source is not publicly > available, but which are nevertheless freely usable and distributable > by all and sundry. > > 3. We need to treat unknown licenses as nonfree, because of the legal > situation in many countries that one is obliged to assume that an > author would not wish his/her propertty to be treated as if it were in > the public domain. We have, as yet, moved nothing of category unknown > to the nonfree/ hierarchy; we will be doing that job later in the > year. > > THE FUTURE > > The CTAN team are slowly moving items to the nonfree/ hierarchy. This > process may be expected to accelerate during the course of this year; > in particular, one may expect items of category unknown to be moved > starting next month (June 1999). > > If *you* are an author who has not responded to an enquiry about the > status of your stuff on CTAN, we urge you to release a new version > which makes its licensing status clear, and to upload that version to > CTAN in the usual way (see README.uploads on any CTAN site). Don't > forget to mail [EMAIL PROTECTED] -- uploads don't get acted > upon without such a message. > > If you don't do this, and we don't otherwise deduce the status of your > stuff, it is liable to be moved to the nonfree/ hierarchy, and to > disappear from future CD distirbutions of TeX. > > OTHER INFORMATION > > While CTAN is _not_ enforcing an open-source policy, we recommend > sites such as > > http://www.opensource.org/osd.html > > for discussion of the issues behind software licensing. -- /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: libg[dt]k-1.1.so.13? (was gnome-apt)
On Mon, 1 Feb 1999, Thomas Gebhardt wrote: > Hi, > > when I tried to have a look at gnome-apt_0.3_i386.deb > I found that it depends on several potato packages. > I tried to install as much as needed (well, as the deb dependencies > indicate) but still get some missing so dependencies: > > # gnome-apt > gnome-apt: error in loading shared libraries > libgtk-1.1.so.13: cannot open shared object file: No such file or directory You picked a bad moment. for one day there was a broken libgtk-1.1.13 in the archive. Please upgrade it today, and you'll be fine. J /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: suid-perl
On Sun, 31 Jan 1999, Chip Salzenberg wrote: > According to Jules Bean: > > On Sun, 31 Jan 1999, Chip Salzenberg wrote: > > > Every OS has a different set of mount options that may or may not be > > > relevant to setuid security. I don't see what 'higher level' would be > > > useful. > > > > The correct solution to this, surely, is for the mount nosuid to actually > > strip the suid bits of any files. So that any calls to stat() on a floppy > > simply won't see suid bits. > > I can see it both ways. > > Consider that I may wish to mount a filesystem nosuid for the purpose > of making a tape backup. Would I want the suid bits turned off in the > backup image? I think not. Why not just mount it somewhere only you can get at it? Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: suid-perl
On Sun, 31 Jan 1999, Chip Salzenberg wrote: > > As it is, noexec is almost useless. I can't help thinking that > > *all* interpreters *should* check noexec status. > > What's the point? Such files can be copied to /tmp and run there If one were trying to secure such a system then you would probably make all user-writable areas (i.e. /tmp and /home) noexec, Not that I'm trying to do this myself, but this seems to be what noexec is about (and fails to acheive). Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: suid-perl
On Sun, 31 Jan 1999, Chip Salzenberg wrote: > > The code exists to check the mount options relevant to an open file. > It's just a Small Matter of Programming to integrate that into the > Perl source code, and disable emultation of setuid scripts when the > 'nosuid' mount option is set. But, then every interpreter should do this (by analogy with you point below). Well, not a perfect analogy. But every suid-emulating interpreted. (Aside: Why hasn't linus patched the kernel so that suid scripts are secure? It's an easy task, surely?) > > And as for 'noexec', well, it's not relevant to Perl anyway. (All you > have to do is run "perl scriptname" instead of just "./scriptname".) > Or do you suggest that every single language compiler/interpreter must > check mount options? Should Java .class files be unusable if they're > on a 'noexec' filesystem? I don't _think_ so. As it is, noexec is almost useless. I can't help thinking that *all* interpreters *should* check noexec status. However, they don't.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: suid-perl
On Sun, 31 Jan 1999, Chip Salzenberg wrote: > According to Michael Stone: > > Quoting Wichert Akkerman ([EMAIL PROTECTED]): > > > What perl-suid should do is check the mountoptions for the filesystem on > > > which the script resides and abort if that was mounted with nosuid. > > > Should be quite simple actually.. > > > > But that's still not general enough. For example, you just missed the > > case of noexec... The solution should be done at a higher level, IMHO... > > Every OS has a different set of mount options that may or may not be > relevant to setuid security. I don't see what 'higher level' would be > useful. The correct solution to this, surely, is for the mount nosuid to actually strip the suid bits of any files. So that any calls to stat() on a floppy simply won't see suid bits. I honestly can't see why the fs driver doesn't use this approach currently - seems the simplest and most consistent to me. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: GTK oops?
On Sun, 31 Jan 1999, Jules Bean wrote: > On Sun, 31 Jan 1999, Jules Bean wrote: > > > Dear overworked gtk maintainer... > > > > Did you deliberately upload a version 1.1.14 of gtk1.1.13? Looks confused > > to me.. > > Doh! > > I'll shut up now. > > Lesson - read the changelog.. Going for the record in self-sustaining threads.. There *is* a problem here: [EMAIL PROTECTED] zcat /usr/doc/libgtk1.1.13/changelog.Debian.gz | head -8 7:43PM gtk+1.1.13 (1.1.14-1) unstable; urgency=low * New upstream version. Note source name did not change, as the soname is still .13, because .14 and .13 are binary compatible. * Make absolutely sure the postinst for libgtk1.1.13 only calls ldconfig on 'configure' calls -- Ben Gertzfield <[EMAIL PROTECTED]> Fri, 29 Jan 1999 21:11:44 -0800 [EMAIL PROTECTED] dpkg -L libgtk1.1.13 | grep /usr/lib 7:44PM /usr/lib /usr/lib/libgdk-1.1.so.14.0.0 /usr/lib/libgdk-1.1.so.14 /usr/lib/libgtk-1.1.so.14.0.0 /usr/lib/libgtk-1.1.so.14 So it does in fact provide a library with soname .14. This breaks programs linked against .13.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: GTK oops?
On Sun, 31 Jan 1999, Jules Bean wrote: > Dear overworked gtk maintainer... > > Did you deliberately upload a version 1.1.14 of gtk1.1.13? Looks confused > to me.. Doh! I'll shut up now. Lesson - read the changelog.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
GTK oops?
Dear overworked gtk maintainer... Did you deliberately upload a version 1.1.14 of gtk1.1.13? Looks confused to me.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On 30 Jan 1999, Chris Walker wrote: > > [1]Useful in UK academia where you have a fast network connection to a > mirror site. In Uk academia, the most useful site is http://sunsite.doc.ic.ac.uk/packages/debian J /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Bug#32595: remove obsolete and confusing acquisition methods: harddisk, mounted, cdrom, nfs
On 31 Jan 1999, Martin Mitchell wrote: > 1) A m68k computer with a 60Mb debian installation. Normally I use the nfs > method. Apt is just not feasible, it wants to copy everything over before > it starts - there simply isn't space on the disk to do this. Also the > runtime cost of starting dpkg on m68k is very high, so dselect is often > much faster, rather than apt's invoking dpkg separately for many packages. > (I am aware apt is more correct, however in practice so many invocations > of dpkg are rarely necessary) Hm. I'm pretty sure the apt with a file:/ URL doesn't copy, it installs straight from the remote. Or is this not true? > 2) A local mirror, hand constructed. No extra or useless packages in there. > Apt doesn't construct or handle this type of arrangement well by default. > The mounted method deals with this just fine. What problems does apt give? (I assume you're running dpkg-scanpackages to build local packages file?) Incidentally, I'm not claiming Martin's objections are foundless. I'm interested to see what limitations apt has (and then we can request them as features). Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Conflicts in libgtk*-dev
On 30 Jan 1999, Ole J. Tetlie wrote: > *-Jules Bean <[EMAIL PROTECTED]> > | > | The fact that the *actual* libgtk1.1-dev package conflicts with > | libgtk-dev, does not mean that the package libgtk1.13-dev, which provides > | libgtk1.1-dev, must conflict with libgtk-dev. > | > | Or, in the abstract: > | > | If A conflicts with B, and C provides A, then C need not conflict with B. > > So this would imply that gnome-apt is wrong to deny me > installing libgtk1.1.13-dev, right? Yup. As I demonstrated in my first message, plain apt will let you do it.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Conflicts in libgtk*-dev
On 30 Jan 1999, Ole J. Tetlie wrote: > *-Jules Bean <[EMAIL PROTECTED]> > | > | On 30 Jan 1999, Ole J. Tetlie wrote: > | > | > Am I overlooking something obvious here? > | > > | > libgtk1.1.13-dev provides libgtk-dev and libgtk1.1-dev > | > > | > but > | > > | > libgtk1.1-dev conflicts with libgtk-dev > | > > | > this means that gnome-apt refuses to install libgtk1.1.13-dev, > | > a package that I sorely need. Aren't these relationships somewhat odd. > | > | Nothing odd there. > | > | libgtk1.1-dev conflicts with libgtk-dev so that it won't be installed at > | the same time as any other package which provides: libgtk-dev. > > OK, I have probably misunderstood something. > > libgtk1.1-dev conflicts with libgtk-dev, and does not provide > libgtk-dev. I read the packaging-manual in a way that makes > it impossible to install _any_ package that provides both. No. The fact that the *actual* libgtk1.1-dev package conflicts with libgtk-dev, does not mean that the package libgtk1.13-dev, which provides libgtk1.1-dev, must conflict with libgtk-dev. Or, in the abstract: If A conflicts with B, and C provides A, then C need not conflict with B. > > The relevant sections(?): > > When one package declares a conflict with another dpkg will refuse to > allow them to be installed on the system at the same time. > > A special exception is made for packages which declare a conflict with > their own package name, or with a virtual package which they provide > (see below): this does not prevent their installation, and allows a > package to conflict with others providing a replacement for it. You use > this feature when you want the package in question to be the only > package providing something. > > -- > ...Unix, MS-DOS, and MS Windows (also known as the Good, the Bad, > and the Ugly). (Matt Welsh) > [EMAIL PROTECTED] [-: .elOle. :-] [EMAIL PROTECTED] > /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Conflicts in libgtk*-dev
On 30 Jan 1999, Ole J. Tetlie wrote: > Am I overlooking something obvious here? > > libgtk1.1.13-dev provides libgtk-dev and libgtk1.1-dev > > but > > libgtk1.1-dev conflicts with libgtk-dev > > this means that gnome-apt refuses to install libgtk1.1.13-dev, > a package that I sorely need. Aren't these relationships somewhat odd. Nothing odd there. libgtk1.1-dev conflicts with libgtk-dev so that it won't be installed at the same time as any other package which provides: libgtk-dev. In fact, all the libgtk*-dev packages should provide: libgtk-dev and conflict:libgtk-dev - so only one can be installed at any time. For example: pear# apt-get install libgtk1.1.13-dev Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: libglib1.1.13-dev The following packages will be REMOVED: libgtk-dev The following NEW packages will be installed: libglib1.1.13-dev libgtk1.1.13-dev 0 packages upgraded, 2 newly installed, 1 to remove and 0 not upgraded. Need to get 893k of archives. After unpacking 1186k will be used. Do you want to continue? [Y/n] Looks fine to me.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: 2.1.125 source in slink - why?
On Fri, 29 Jan 1999, Adrian Bridgett wrote: > dists/slink/main/binary-all/kernel-source-2.1.125 > > why?? and 2.0.33, 2.0.34, 2.0.35 > > 2.0.36 I can understand :-) 2.1.125 - because we needed it for sparc, so we uploaded the source. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
On Fri, 29 Jan 1999, Santiago Vila wrote: > On Fri, 29 Jan 1999, Jules Bean wrote: > > > On Fri, 29 Jan 1999, Santiago Vila wrote: > > > > > On Thu, 28 Jan 1999, Brandon Mitchell wrote: > > > > > > > About the xfonts problem. I haven't been following close enough to > > > > pardon > > > > my ignorance on the subject. What if we make the pseudo xbase package > > > > conflict with xfnt* packages < version x (a versioned conflict)? How > > > > will > > > > dselect handle this, will it upgrade the fonts to the new name? > > > > > > No, this would just make dselect to remove the old package. > > > > This doesn't change the current debate, but it occurs to me that a > > versioned provides would solve the renaming problem. > > AFAIK, there is no such thing as "versioned provides". Dpkg doesn't support them, no. I'm sure you knew what I meant as an abstract concept, though ;) It has been often discussed to implement them. I am merely observing (unhelpfully) that they would solve this problem too. J /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
On Fri, 29 Jan 1999, Santiago Vila wrote: > On Thu, 28 Jan 1999, Brandon Mitchell wrote: > > > About the xfonts problem. I haven't been following close enough to pardon > > my ignorance on the subject. What if we make the pseudo xbase package > > conflict with xfnt* packages < version x (a versioned conflict)? How will > > dselect handle this, will it upgrade the fonts to the new name? > > No, this would just make dselect to remove the old package. This doesn't change the current debate, but it occurs to me that a versioned provides would solve the renaming problem. j /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: voting instructions on the web [was: PLEASE remember to vote!]
On 28 Jan 1999, Gordon Matzigkeit wrote: > Hi! > > > Andreas Tille writes: > > AT> Sorry for my ignorance when deleting the mails under this topic. > AT> I was absend from the net for a longer time and couldn't read all > AT> my E-Mails. Please repeate the link where to vote for those like > AT> me who ignored the mails. I couldn't find a site to vote. > > After some searching, I found it at: > > http://www.debian.org/Lists-Archives/debian-devel-announce-9901/msg00017.html > > In the future, could somebody please put the ballot on the debian web > site in an obvious place (such as a link from the same page that > describes the alternatives and/or results). Well, it's on http://vote.debian.org, which is fairly obvious. I also received information about the ballot on the following lists: -private, -devel, -devel-announce and -vote. That's not exactly hiding the information.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote: > On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote: > > >> Since you do support -rpath in your system, you should probably extend > >> your dynamic linker to work in this case too, or risk taking the blame > >> for silently breaking applications, if the poor user ever understands > >> what happened to his program. > > > Note that 'we' (Debian) write neither the kernel, nor the dynamic linker. > > Sorry, I had assumed you had hacked the dynamic linker in order to > support the /libc5 compatibility libraries. Absolutely not. This is one of my main points, in fact. Our dynamic linker is already very good at solving versioning problems. It doesn't need us to guarantee the locations of libraries to work - it can get it all correct anyway. Therefore, we chose to solve that particular problem (the libc5-6 transition) by moving libraries around, knowing that our linker was up to the job. You are now saying that libtool, by giving no way of avoiding rpath, will not support this scheme. > > > You have previously objected to a proposed solution on the grounds that > > 'you want libtool to work on all systems'. It seems to me that if you > > want to make libtool work on Linux, you should find a way of disabling > > rpath, since rpath is broken on Linux. > > rpath is not broken, it just won't let one replace a library (meaning > moving a library to another directory and installing a new library in > its place) with one that appears to be compatible, according to the > version numbers, but is not. That's the root of the problem, and > that's why you want so much libtool not to use -rpath. > rpath is broken. You said as much yourself. rpath is broken because it *overrides* all other sorts of library searching. For all I know, there may be a design justification for this. My understanding of rpath was that it was an 'option of last resort' when you couldn't make it work any other way (and hence, the overriding of all other search options is justified). However, using rpath as default is bad for our setup. Since you think it is right to use rpath as default, I therefore claim it is broken. > I feel we're not going to make progress in this discussion unless > someone comes up with a bright idea about how to allow the user to > select when/how to hardcode rpaths or not. In the beginning of this > discussion, Thomas Tanner suggested that -rpath could be dropped if it > would specify a standard library search directory. Easy. Allow libtool to be run with the option libtool --no-rpath. This would then be run in all debian-maintained versions of libtoolized packages, and they'd work. Furthermore, when talking to software developers, I'd recommend they use this option by default, disabling it with a ./configure --use-libtool-rpath if the user really needs the functionality. > > However, our dynamic linker *does* understand the problem. And it *does* > > have a solution to it. And -rpath turns it off. So we cannot afford to > > use -rpath. > > As I have already pointed out, the solution is not complete, otherwise > you'd not be observing any problem. What do you mean the solution is not complete? It works. It works well. People developing only for linux, and not using libtool, wouldn't even *think* of using rpath since it is a) unnecessary and b) a bad thing. However, people don't develop only for linux (this is a very good thing). And because various OSes have wildly different rules for dynamic libraries, libtool was born to help developers keep their makefiles sane. And libtool is now deciding not to support the linux model. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote: > On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote: > > > On 27 Jan 1999, Alexandre Oliva wrote: > [watch indenting carefully : I wrote this next bit, of course] > > In general, it is not useful to have multiple versions of the same > > package. > > You're probably talking about the single-user workstation model. I'm > talking about a networked multi-user model, in which some users need > (for reasons only they understand :-) particular versions of, say, GNU > Emacs and gcc installed. In general, such a situation only arises because of a bug in the software. That is why I say that, in general, it is not useful. > > Nonetheless, you are refusing to support it. > > I'm not refusing to support it. I'm just inclined to avoid having an > easy-to-use flag to disable explicit hard-coding of library paths > because: > > 1) it would be hard to make it behave correctly in a portable way (and > libtool would be useless if it were not for being portable); Special case-it for linux, if you will. Libtool has plenty of special cases as it is. > > 2) it should not be necessary if you play by libtool rules, i.e., you > pre-declare where libraries are going to be installed and keep them > there forever (or until they're no longer needed); > We don't want to play by libtool rules. We don't see that as a sensible restriction. [more information to follow in a separate follow-up] Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote: > > > In normal cases the dymanic linker would figure this out one way or > > another with rpath this functionality is disabled as it overrides > > the library versioning scheme. > > > The linux dynamic linker will resolve things in some magical way based on > > the library dependencies and the program dependencies to locate the proper > > library in many cases - rpath does cripples, not enhances, this function. > > Since you do support -rpath in your system, you should probably extend > your dynamic linker to work in this case too, or risk taking the blame > for silently breaking applications, if the poor user ever understands > what happened to his program. You may be right. I haven't examined that situation in enough detail to explain why the designers of the dynamic linker implemented it the way they did. Maybe they got it wrong. Note that 'we' (Debian) write neither the kernel, nor the dynamic linker. You have previously objected to a proposed solution on the grounds that 'you want libtool to work on all systems'. It seems to me that if you want to make libtool work on Linux, you should find a way of disabling rpath, since rpath is broken on Linux. > It seems to me that the main problem has to do with library > versioning. Even though the existing library versioning mechanisms > are great to describe the evolution of the API offerred by a library, > they by no means describe the dependencies of a library, so we end up > with libraries that have the same version numbers but that are not > compatible at all. You're right. That is the underlying problem. However, our dynamic linker *does* understand the problem. And it *does* have a solution to it. And -rpath turns it off. So we cannot afford to use -rpath. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote: > > If you do want to be able to freely move libraries around, -rpath must > be forbidden. If -rpath is available for users, you can't move > libraries around and expect things to work. There are lots of things which users can do which might appear to work, and then break later. The user should understand what -rpath is for, and why he should use it, and when he should use it. As far as I can, it is *not* useful for the packages which are part of a 'managed' system like Debian. It *is* useful for users custom-compiling things in custom dirs. Can you tell -rpath to store the rpath for libmycustomthing.so and not for libc.so? (Not a rhetorical question - I genuinely don't know the answer). If not, then I'd suggest that it's rpath that's broken. > > We even support separate versions of software, to some extent, although > > I'd agree completely that our support in this area is not what it might > > be. > > And that's the very reason why I've never been able to adopt any of > the available packaging systems: the only way to keep multiple > working versions is to use a separate directory for each version of > each package. In general, it is not useful to have multiple versions of the same package. In specific cases, it can be. I don't think that libtool is the right vehicle for you to evangelise your dislike of packaging systems and the FHS. > > If you want to test one version, you simply run it with > > > ./configure --prefix /home/me/nicepackage > > But isn't this exactly what the packaging systems are trying to avoid, > i.e., that people have to compile systems on their own? And then, how > could I make sure that my test build works exactly as the pre-compiled > upgrade, so that I could use the packaging system for the update? You would download the debian package. You would very slightly edit the rules file (which is like the makefile) to change the prefix passed to configure. You would then run dpkg-buildpackage. Or simply debian/rules binary. If the program wasn't debian packaged at all, you'd read some documentation on how to create a debian package ;-) > This is something that I feel that should be taken care of by the > existing GNU/Linux distributions. In fact, I've got a bunch of ideas > that I'll probably never find time to implement :-( about how to > maintain multiple versions of packages installed and allowing each > user to select which version he wants to use, either by explicit > version number or by tags such as `stable', `test', `old', etc, tags > that are determined by the system manager when he installs the > package. These are all worthy ideas. The idea of a 'fluid file system' or a 'tagged file system' which allows to mark abitrary subsets of your files with tags (like 'belongs_to_package_x' or 'part_of_debian_version_2.0') is a very worthy idea. The idea of extending debian's package system to cope elegantly with concurrent versions is (probably) a good idea. However, none of these things are currently available for Linux. What is available, is a distribution with well-thought (not arbitrary) structure and standards. A distribution used by many people, although not as many as RedHat (which has similar standards in most respects anyway). We have considered library dependencies. We have a working system. It is reasonably elegant. It is convenient for the users. It is not the only answer. Nonetheless, you are refusing to support it. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote: > > > The contract simply states that the library will be found. Which > > library is used can be determined by the linker. > > Except that, if you replace the library with an incompatible one, you > *are* breaking the contract. We don't replace libraries with incompatible ones. We bring in new libraries, which are incompatible. We keep the old ones, which are compatible. Our linker knows how to tell which is which. Who cares where they are stored? Actually, we do care where they are stored. My point is, that it doesn't matter if the new library is in the location the old library used to occupy. Our linker knows which is which. > > Furthermore, there's no reason to assume that the user will *not* have > used -rpath himself, so moving libraries does have a potential for > breaking user programs, therefore it should best be avoided. This is a valid point. It is my feeling that -rpath should not be used for libraries in the 'standard' paths, which allows them to move (which is a useful feature). It is reasonable to use it for libraries in unusual places (another useful feature). > I think a solution that is not general is not a good solution. Since > the solution of moving shared libraries around has the potential of > causing problems, if I were you, I'd work harder to try to find a > complete solution (which I happen to have already suggested) instead > of trying to blame libtool or other users for doing things that are > perfectly correct, but not in the way that would let you replace > incompatible libraries. I agree with your suggested solution, which amounted to more complex understanding and use of inter-library dependencies by the tools. However, I don't have the expertise to implement this. And I disagree with you (strongly) about the correct use of the existing system. > > > Our distribution cares greatly about separating packages from each other. > > Not from the point of view of the end user. When they want to find a > tool, they may `ls /usr/bin /usr/local/bin' and will be presented > *thousands* of files. I'd rather have a classification system in > which I could have links (or similar) to all programs in a common > directory, but in which I could search for programs by subject. I'd > like to have development tools such as compilers in one directory, > text writing tools such as word processors and text editors in > another, system administration utilities in another, and so on. > Additionally, I'd like to be able to keep multiple versions of a > package installed, and the only way I could do that is by installing > each version in a separate directory, and selecting which version to > use via soft-links in the directory that happens to be in my PATH. > We do have a classification system. And we don't use the filesystem for it. We have lists of packages, with descriptions. We even support separate versions of software, to some extent, although I'd agree completely that our support in this area is not what it might be. > How does the current packaging system allows me to test one version of > a package while other users of the same host are running a stable > version of that tool? Or are the GNU/Linux distributions all moving > towards the Micro$oft model of single-user workstations? Of course not ;-) If you want to test one version, you simply run it with ./configure --prefix /home/me/nicepackage or whatever. But you knew that. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: GNOME in potato needs slink libs
On Wed, 27 Jan 1999, Ossama Othman wrote: > Hi Jules, > > > > Another quick question... > > > Why does potato's GNOME require slink's gtk/gnome/etc libs? > > > > Because potato is not yet a complete distribution, and should be > > 'overlayed' over slink? > > Ah, I see. I did a "clean" potato installation, i.e. not over slink. > > Anyone have any idea when GNOME for potato will be updated? No rush or > complaints, I'm just curious since I want to test the imlib packages on > potato's GNOME once I start releasing imlib package updates. I have almost all of GNOME 0.99 propogated to my mirror now. The only missing link is libgtop0. So, soon, would be my guess. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: -rpath with libtool and Debian Linux
On 27 Jan 1999, Alexandre Oliva wrote: > > Having libtool default to -rpath is what's causing problems. > > This is IMHO completely backwards :-) > > When a program is linked with a shared library, a contract is > established between them stating that the library (or any newer but > compatible version thereof, on systems that support library > versioning) will supply the symbols that the program resolved from it, > and the program will be able to find the library at that point. If > you move the library and replace it with an incompatible one, you're > breaking the contract and the versioning mechanism, so you can't blame > the program for crashing, nor the tool that created the program. The contract does not state that the library will be found in a particular location on the filesystem hierarchy. The contract simply states that the library will be found. Which library is used can be determined by the linker. Where is the need for rpath here? The combination of library versions uniquely identifies, to a suitably well configured linker, which library to find. > > I've seen one too many instances of " crashes on Debian" that turned > > out to be " is a libc5 binary with an RPATH of /usr/X11R6/lib" which on > > any reasonably up to date Debian system contains libc6 X libraries. > > See? You replaced one library with an incompatible one without > modifying its version number to mark it as incompatible. Isn't this > breaking the contract? How could you expect it to work? It did work. On all binaries without -rpath. It worked. What do you mean, 'How could we expect it to work?' > >> > However, Alexandre Oliva <[EMAIL PROTECTED]> brings up an important > >> > point: -rpath is necessary if one is installing libraries and binaries > >> > linked to those libraries in one's home directory, > > > That is a special case. The default should be sane for regular cases. > > You see the regular case as the one you use the most. I see it as the > one I use the most. I don't install any packages in /usr or > /usr/local because I find it *horrible* to have a huge /usr/local/bin > without any clear separation between packages. It's a pity that the > GNU/Linux distributions don't care about clearly separating packages > from one another... I'm sorry, but I'm flabbergasted. To think that the person in charge of libtool actively disagrees with a) The whole point of packaging systems b) The FHS Our distribution cares greatly about separating packages from each other. And it does it very well. There is no need to acheive this by enforcing such package structure on the file-system - which package a file belongs to is a concept orthogonal to where the file lives in a sensible filesystem. Worried, Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: GNOME in potato needs slink libs
On Wed, 27 Jan 1999, Ossama Othman wrote: > Hi guys, > > Another quick question... > Why does potato's GNOME require slink's gtk/gnome/etc libs? Because potato is not yet a complete distribution, and should be 'overlayed' over slink? /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Licenses for non-software works, and the definition of software, and , the new DFSG
Hi, In response to an issue on -legal, I am reopening the debate on how free those parts of debian which are not software (or not precisely software) should be. IMO, this debate should be conducted on -policy, and I ask all replies to this message to trim the CC: line. This issue was discussed in length on policy last year. One such thread is 'Free Software Needs Free Documentation', which begins at http://www.debian.org/Lists-Archives/debian-policy-9808/msg00042.html Another thread 'Start for a discussion about free documentation in Debian' begins with http://www.debian.org/Lists-Archives/debian-policy-9808/msg00052.html Four or five other threads follow - please use the list-archives browser if you have a web browser capable of it. Being biased, I like the summary I gave in http://www.debian.org/Lists-Archives/debian-policy-9808/msg00254.html *Please*, if you have strong views on this subject, at least skim the above threads, and those which follow on related issues, before entering the debate. It was very drawn out last time. It is an important issue, and I don't think we should vote on a new DFSG which doesn't address it. Allow me to summarise some points of fact and some points of view: 1) Technical documentation should be 'free' in the GPL sense. This was widely held by all participants in the debate. 2) 'Artistic works' need not be free. This suggested to us the creation of a new section in debian, 'verbatim', in which works in certain classes could be distributed. The line between documentation and 'works of art' may not be clear, and there may be a mixture in one document. 3) Licenses are generally not free This is more or less a fact, actually. The GPL does not give the permission to modify, notwithstanding the fact that some other licenses are very clearly derived works. 4) Some good, 'free' software has non-free documentation This poses a dilemma for our principles. Our conclusions, IMO, should be included either in the new DFSG, if we accept it, or incorporated into the current, if not. Jules ..putting on flame suit... /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: New logo strategy
On Tue, 26 Jan 1999, Daniel Martin wrote: > > If we are going to have a gimp.org done contest, I would like to see > that the rules allow people to use things that are not gimp, but that > are DFSG free software. I find the command-line pnm tools very useful > in manipulating images, and it would be nice if I could use them. It > would also be nice if I could use xpaint, or something else that > allows me to draw simple straight lines and ellipses - freehand > drawing with the mouse is very difficult. Whilst I have no objections to such a change in rules, I am baffled that anyone could prefer xpaint to gimp, even for drawing straight lines and ellipses. Try fiddling with the selection tools, and the 'path' or 'pen' tool. (And use layers lots..) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: New logo strategy
On Mon, 25 Jan 1999, Steve Greenland wrote: > On 25-Jan-99, 19:06 (CST), Wichert Akkerman <[EMAIL PROTECTED]> wrote: > > I agree with James Treacy's observation that we will probably need two > > logos: one logo with a liberal license that people can just freely, and > > another, more restricted logo for things like official CD's and so. > > To phrase this in another way: we will have a logo that everyone can > > slap onto their webpage, t-shirts, posters, etc., and a logo that can be > > used for `official' products, like CD's made using our own iso-images. > > Sorry, I think this is a bad idea: > > 1. We have to agree on *two* logos :-). > > 2. Far more importantly, it fractures the identity of the logo, which > is one of the major points of *having* a logo. > > 3. It creates a first-class and second-class logo. Nah. A 'submission' to the contest is a pair of logos. Linked to each stylistically, one of them says 'official' or something. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: dpkg --print-architecture [WAS: Release-critical Bugreport for January 25, 1999]
On Mon, 25 Jan 1999, Marcelo E. Magallon wrote: > On Mon, Jan 25, 1999 at 12:15:11AM -0600, BugScan reporter wrote: > > > Package: emacs20 (main) > > Maintainer: Rob Browning <[EMAIL PROTECTED]> > > 28177 dpkg --print-architecture requires gcc > > > > > > Package: xlib6 (main) > > Maintainer: Branden Robinson <[EMAIL PROTECTED]> > > 31610 xlib6: requires gcc but declares no dependency (dpkg > > --print-gnu-build-architecture?) > > Aren't this two the same kind of bug? Having no idea why the maintainer > chose this particular way to implement this, wouldn't it be easier to put > this information *on the script* at *compile-time*? > > Something like > > ARCH := $(shell dpkg --print-gnu-build-architecture) > > debian/whatever.postinst: debian/whatever.postinst.in > sed -e 's/@ARCH@/$(ARCH)/' $< > $@ This seems like a workable solution, for slink. For potato, we will have a new tool, dpkg-architecture, which will solve this problem more completely (see policy archives). Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: dpkg port to HP-UX
On Mon, 25 Jan 1999, loic wrote: > Fabrizio Polacco wrote: > > > Now I have to evaluate packaging systems for that platform, and I would > > like to push a Free solution, a debian one specifically (because it's > > the best :-). > > We do think the same... (we do the same thing:) > I'm setting up a dpkg package manager under solaris... > ...But the porting work has already been done. > > Good luck, > Loic. > > (And maybe contact Julian Bean about it; look at his message on debian-dpkg, > http://www.debian.org/Lists-Archives/debian-dpkg-9812/msg00021.html) In that message I merely express an interest - it's a cool idea. In fact, I think Ben Collins has a working system on Solaris - check out earlier emails in the same thread. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: filters: Licence problems
On Sun, 24 Jan 1999, Antti-Juhani Kaijanaho wrote: > On Sun, Jan 24, 1999 at 12:48:07PM -0600, David Welton wrote: > > (and it's 'humor' by the way;-))) > > humour is a perfectly valid word. Ask your nearest dictd with Webster > and Wordnet installed, for example. Humour is correct (in British English). The American (pah!) spelling is humor. I'm sure the original poster knew this, hence the smiley. /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Crypto software that *is* exportable from the USA
On Sun, 24 Jan 1999, Wichert Akkerman wrote: > Previously Paul Sheer wrote: > > Also: there is no GPL secure shell (as far as I know). > > But people are working on that. From what I hear it's on the verge of > becoming useable. Don't ask me about the name, I always forget it. It's called psst. (Or at least, the project is called psst). If you want a URL, go to freshmeat, find the GNU privacy guard home page, and follow the link :-) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: the Great X Reorganization, package splits, and renaming
Umm.. I still think we're talking at cross-purpose. 1) xfonts-* C/R/P xfnt-*. Yes, I knew this was true. Yes, I knew Branden knew this :-) 2) Branden doesn't like xfnt-* hanging around. We agree. 3) However, if someone were to create xfnt-* packages which *Depend* on the corresponding xfont-* package, then the user will automatically install the new xfont-*, which will in turn automatically deinstall the xfnt-*, so the cruft doesn't hang around. Branden, do you object to this last? Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: the Great X Reorganization, package splits, and renaming
On Sat, 23 Jan 1999, Steve Greenland wrote: > Why are we going to this trouble? If you want to rename package a1 to a2, > simply make a2 conflict and replace a1 -- dselect or dpkg will do > the rest. If you want to make 'upgrade' automatic, then you'll also > need to upload a new version of the a1 package (empty would seem to > be feasible) that depends upon a2. > > And yes, I just tried this. It works, using dselect with the apt method > anyway. I installed a version of a1 that did not require a2, and then > created a new version of a1 that did, and then add a local archive that > had both the new version of a1 and a2 in it to my apt sources.list file. > Dselect->update,select,install worked just fine. > > Also went back to the original a1, and ran dpkg --install a1.deb a2.deb. > That also worked. > > There's no need to make the dummy packages do anything. In particular, > the xfonts-* packages already have the necessary replaces/conflicts. The > only thing necessary is to upload new xfnt-* packages with the necessary > depends. Branden has indicated that he's not interested in doing that. I don't think Branden realised that the conf/repl/prov trick will automatically deinstall the xfnt packages. My understanding of his objection was the ugliness of having them hang around. I have Cc:ed [EMAIL PROTECTED] into this email. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: the Great X Reorganization, package splits, and renaming
On Sat, 23 Jan 1999, Raul Miller wrote: > ( > until dpkg --remove xfntwhatever; do > sleep 120 > done >/var/tmp/removexfntwhatever.log 2>&1 & > ) OK. We have three solutions suggested now: a) dummy packages (and live with them) b) dummy packages, which self-remove c) packages with the old names, which tinker with dpkg/dselect's databases so it looks like the new packages are installed instead (which is true, since they have the same contents). I suggest the X maintainer choose one. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Unmet Deps revisted
On Fri, 22 Jan 1999, Steve McIntyre wrote: > On Fri, 22 Jan 1999, Santiago Vila wrote: > > >Please note that a suboptimal packaging does not legitimate the conflict. > >For example, my unzip and unzip-crypt packages do conflict at each other, > >and they are optional, so I should probably make them compatible, like > >pgp-i and pgp-us, for example. [ And of course, I will not mind that > >unzip-crypt is demoted to extra until I repackage them ]. > > > >(Yeah, I put my own packages as examples of suboptimal packaging! > >I hope the pgp-i and pgp-us example will help you to see that surely most > >of these conflicts are gratuituous). > > I guess so. Hmmm. I'm still not convinced it's a major thing to be worried > about. I presume nobody's going to argue that "extra" packages can't > conflict with each other...? Of course not. That's the *whole* point. Extra is precisely the priority for packages with conflict with other packages (in any priority, including extra). Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Dpkg Update Proposal
On Fri, 22 Jan 1999, Craig Sanders wrote: > the libgtk* versions are compatible with each other. the libgtk*-dev > versions, are not (it would be possible to make it so by installing > header files in /usr/include/gtk-VERSION, but you'd still have to modify > every source file that #included it. in other words, it could be done > but probably isn't worth the effort unless it's done upstream as well). > > fortunately, the -dev packages conflict with earlier versions, so it's > not a problem. > > debian's way of handling this allows for all versions of libgtk to be > installed simultaneously, allowing progress AND backwards compatibility > without conflict. Actually, we could acheive concurrent dev packages with use of the alternatives mechanism and the (upstream) gtk-config programs. > BTW, this is only a "problem" because the upstream libgtk1.1.x changes > the programming interface without changing the .so number. they've got > valid reasons for doing so (and they do advertise that fact), so there's > really no need to come up with a general solution to a specific problem > with one or two unstable/rapid development upstream packages. There's no law (AFAIK) that it has to be the major number that changes to signify API changes. It's simply the way you choose to organise your symlinks. And it's consistent to name the package after the API version. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
RE: KDE status?
> > It's all available in the archives... Let's not start THAT discussion again, > > ok? > > Sure no problem. I had no intention of doing so. I was just curious as > to the status. There will be no argument from me, especially since I > agreed with Debian's stance on the matter. :) > Brief summary, then: KDE will not be in slink. KDE will be in potato if a) KDE change their license (in which case it can go into contrib) b) Qt change their license (in which case they may both be able to go into free) b) is the likely outcome, since troll are designing a new Qt license, which Joseph Carter <[EMAIL PROTECTED]) is looking at with a view to making it both DFSG-free (which it almost certainly will be) and GPL-compatible (trickier). For more background, please read the archives of debian-legal,debian-devel and kde-licensing :-) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: doc-base control file madness
On 21 Jan 1999, Ben Gertzfield wrote: > > "Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes: > > Ben> I've recently looked into the doc-base control file > Ben> format. It seems pretty sane, except I realized since it does > Ben> not provide for any macro expansion, I will have to edit the > Ben> 8 or 9 doc control files libgtk1.1.13-doc (and 1.1.14, and > Ben> 1.1.15, ad nauseum) provides EVERY SINGLE TIME there is a new > Ben> release. > > Dale> Can't you use something like m4 as a pre-processor and do > Dale> macro expansion that way? > > That would work, but it would be nice if it were built into the > control file language. Many people will need this functionality in the > future. Aside: Actually, the important versioning issues raised by libgtk might need addressing in another way, although I can't think of the Right Way just now. ObMacros: In general, it is IMHO silly to rewrite, yet again, a macro substitution engine into a special purpose piece of software (doc-base) when we already have several good, fast macro substituters (cpp, m4) and a framework from which they can easily be run (debian/rules). Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: packages.debian.org
On Wed, 20 Jan 1999, James A. Treacy wrote: > On Wed, 20 Jan, 1999, [EMAIL PROTECTED] wrote: > > Given that from your description swish++ sounds like a general purpose > > indexer, which has been set up to index 'natural language' is it the best > > one > > for our purposes? > > > Once I removed a few conditions for removing words from indexing that weren't > appropriate for us, the system works quite well. Excellent. In that case, my objection has no substance. > The index file for the Package web pages alone is about 6.5M and indexes > over 8000 files, I don't think that a simplistic search system will work > very well on something this large and this popular (swish++ is very fast). > Of course, this pales in comparison to what I have planned next. If I can > work out a few details, I may use swish++ for searching on the mailing > list archives (~1GB and > 160k files). Of course, that *is* the kind of thing swish++ is designed for, so I can hardly criticise that. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: mc bug? or i've not read the manuals
On Thu, 21 Jan 1999, Tibor Koleszar wrote: > Hello, > > So, if you have a script with a setuid flag after you edit+save it in > mc's editor the flag will dissapear... > I dont know, but i think it's a bug. > Let me know if it is, and i'll report it. i've observed the same thing in emacs. Presumably it's an OS level safety feature. (Seems sensible to me) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Debian v2.1 ("Slink") Deep Freeze
On 19 Jan 1999, James Troup wrote: > Santiago Vila <[EMAIL PROTECTED]> writes: > > > Could somebody explain me, why, oh why, do we have to wait more than > > two months for trivial ftp.debian.org bugs to be fixed? > > Perhaps because the more you whine about it the more prone we are to > ignore you? Personally, I really hope that's not the case. Bugs against ftp.debian.org are often important - these ones are holding up slink's release (granted, they're not the only things holding it up). It would be upsetting to think that our ftp.debian.org maintainer team was choosing to spite the whole distribution because some developers were whining. It is also always upsetting to see an 'ad hominem' answer to an important question - however the original question was couched. So, could I (respectfully) ask someone on the ftp.debian.org team to explain the delay? If the problem is time constraints on the individuals concerned - which is something we can all have sympathy for - then perhaps the team would like to ask for volunteers to help with the spade-work. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Debian v2.1 ("Slink") Deep Freeze
On Tue, 19 Jan 1999, Santiago Vila wrote: > > Surely not? > > > > Surely the Replace/Provide/Conflict combination will make dselect pick the > > new ones? > > I'm sorry but I'm afraid this is not the case. > > I hate to say this, but please read the packaging manual and/or the policy > manual. I think you could be a little bit confused about the meaning of > some of these fields. > > If you want a short explanation, here is one: dselect will not take > in account *any* of the fields in the packages you *don't* have installed, > unless there is an unsatisfied dependency. Doh. Of course, you're right. I wasn't thinking clearly.. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Debian v2.1 ("Slink") Deep Freeze
On Tue, 19 Jan 1999, Santiago Vila wrote: > On Tue, 19 Jan 1999, Brandon Mitchell wrote: > > > On Tue, 19 Jan 1999, Santiago Vila wrote: > > > > > Mmm, what about the needed compatibility packages? > > > Will you have some time for this? > > > > > > I think it is absolutely essential for the success of Debian 2.1 that > > > nobody will automagically lose functionality in the upgrade process. > > > > Done in experimental changes file: > >* xbase is now a pseudo-package used to smooth upgrades from hamm or > > earlier systems > >* what was the new xbase is now xfree86-common > > Please, remember that we need also pseudopackages xfnt100, xfnt75, etc. > > Otherwise dselect will not select the new ones in favour of the old ones > unless the user had some package which specifically depended on some > of the old one and now depends on the new one. Since we can't guarantee > that this will always be the case, we need pseudopackages for all the xfnt > old packages and for every other package that changed its name. Surely not? Surely the Replace/Provide/Conflict combination will make dselect pick the new ones? (although this doesn't work for apt-get upgrade, I don't think) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Comments on Debian packages and installation
On Tue, 19 Jan 1999, Anthony Towns wrote: [Thanks to anthony for a concrete list] > > Some of the other packages in this situation: > > rsync suggests ssh > > inn suggests pgp > kbackup suggests pgp > kbackup-doc suggests pgp (the documentation for KBackup) > tm suggests pgp (tm is a MIME package for Emacs) > elm-me+ suggests pgp > > ...ie, things which don't have a free alternative just yet, but will RSN. I wouldn't mind losing all of these. Documentation is welcome to mention that the software can use pgp. > mutt depends on gnupg or pgp or pgp5i > fvwm2-plus suggests xv or xloadimage > > ...ie, things which /do/ have a satisfactory free alternative, and note it. > (What will happen here, btw? Does it stay as an or, or does the non-free > alternative get move to an Enhances? Even though it doesn't enhance mutt if > you installed gnupg?) I personally would just as soon see the non-free ones ditched here too. > > mikmod suggests unzip, lha and zoo > (ie, "If you like, I can deal with compressed stuff!") > ...ie, a reasonably valid use, that would be annoying to move!! Woo! :) I don't see any great value in this suggestion. It can be documented. > > dpkg suggests developer-keyring (which is in contrib) > dpkg-dev suggests developer-keyring > these could probably be done the other way around > transfig suggests netpbm-nonfree > this could probably be done via netpbm-nonfree enhances netpbm > > ...ie, ones that work just as well the other way around anyway. Indeed. I'd like to see Enhances: used for these. So, MHO is: 1) Ban suggestions from main to non-free or contrib 2) Implement enhances for the last set of examples 3) Ditch the rest (well, the rest above). Lots of people aren't going to agree with me on this one... My 2c Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
autoconf/aclocal.m4/gtk-config issues - RF information
Hi all,
I've seen the edges of a few flamewars associated with autoconf/configure
style scripts, and I'm wondering if anyone can point me to (or provide me
with) arguments covering the following points:
Given a 3rd-party library A, which includes header files, and a 3rd-party
program B, which uses headers from A, what is the canonical way for B to
discover the location of A?
Some programs seem to use macro files which they install in
/usr/share/aclocal. Some programs supply 'config' programs
({gtk,gimp,imlib}-config) which report header and link flags. Some
programs rely on a standard location (either /usr[/local]/include or
/usr[/local]/include/).
And I think I've seen people being disparaging of each of these methods..
Many debian programs provide /usr/share/aclocal files... but I've seen
people be fairly rude about the autoconf/automake/aclocal package too...
Any pointers to appropriate FMs appreciated..
Jules
/+---+-\
| Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd|
| Jules aka | [EMAIL PROTECTED] | Richmond, Surrey |
| Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* |
++---+-+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\--/
Re: I propose
--On Mon, Oct 19, 1998 12:59 pm +0200 daville <[EMAIL PROTECTED]> wrote: > Good morning, > >I'm a student in a french engineering school and I develop an > application of mathematics. The problem is: I'would like what are > requirements for including this application in one of Linux > distribution (for example Debian distribution). Well, the only answer we can give is the Debian answer. This is as follows: The software must be 'free'. The definition of the term 'free' in the context of debian is given in: http://www.uk.debian.org/social_contract [If your web-browser handles content negotiation, and you have set french as your preferred language, you will see the French version, which you may find more convenient. Alternatively, you can use the URL http://www.uk.debian.org/social_contract.html.fr which jumps straight to the french version] So, your software must conform to the 'Debian Free Software Guidlines' (defined in the second half of that web page). Then, you need someone to 'package' your software for distribution. This might either be yourself (which would require you applying for debian developer status), or alternatively, any other Debian developer who is interested in your program. You could post to this mailing list describing your program in more detail, to ask if someone wishes to package it. Hope that helps, Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
