Re: Adopting these packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 04 January 2002 17:03, Daniel Stone wrote: (BCC'ed to [EMAIL PROTECTED]). I will adopt the KDE packages, while Chris calc Cheney will take Qt, and will also be the KDE3 maintainer when it comes around to it; by the time KDE2.2 is phased out in favour of KDE3, I won't have the time to maintain KDE, so it works out nicely. :) d Please CC all replies to me; the MX for the domain I get all list mail on is down, so I'm reduced to reading lists through the archives. If you don't, I reserve the right to have a long, flaming, thread about the fact. Oh, and sorry about the line wrapping - LookOut! Express doesn't have it. :\ Hi Daniel, I'm a KDE hacker. I would like to eventually adopt KDE3 packages. Could Chris please contact me? Unfortunately I'm not available until February, but if you have any problems I'd try to help. Thanks, - -- Eray Ozkural (exa) [EMAIL PROTECTED] Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8NymzfAeuFodNU5wRArY1AJ99z5fT3cSDSg/+ONmtYqj6JnzDIQCdFrQX ws32zGnOqw/ynCBZwPYvoXQ= =yKYi -END PGP SIGNATURE-
Does BTS clean old bugs?
On the bts web interface, it's written that closed bugs are cleaned up after a period of inactivity. Are they permanently erased? I'd prefer that a complete history of all bugs is preserved. Thanks, -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Does BTS clean old bugs?
Josip Rodin wrote: On Sun, May 06, 2001 at 03:00:56PM +0300, Eray Ozkural (exa) wrote: On the bts web interface, it's written that closed bugs are cleaned up after a period of inactivity. Are they permanently erased? I'd prefer that a complete history of all bugs is preserved. They aren't, that sentence is unclear, a bug has already been filed. Yes, it is a bit ambiguous indeed. Thanks, -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
ITP: cgen -- cpu tools generator
Package: wnpp Severity: wishlist From Red Hat, CGEN (pronounced seejen) is a framework for developing generators of CPU-related tools such as assemblers, disassemblers and simulators. It specifies a description language for describing the architecture and organization of a CPU without reference to any particular application. Additional applications can be written within the framework. CGEN is written in Scheme and can be run under the GNU Guile interpreter. It is placed under a free software license. License explanation: GPL 2 or later with the exception that the output code may be used in an unlimited fashion. Which is usual for a development tool. URL: http://sources.redhat.com/cgen/ -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: How to report bugs (was glibc thing)
Greg Stark wrote: Just writing in your conclusions is useless 90% of the time. Your conclusions may be right but the maintainer doesn't have ESP and can't necessarily deduce where they came from and what the bug is. I will try to assemble a test case as soon as I have some time. It's been a long time, but I hope I will be able to replicate the bug. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
Branden Robinson wrote: Ah, so you have a time machine which you used to tell your earlier self that there was going to be trouble from me over bug 81397? No comments. :) You CC'ed your *initial report* to debian-devel and debian-x, before I had anything at all to say on the subject. Yes, I did. At any rate, you didn't have to publicly insult me. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
Hi Martin, please cc to me Martin Bialasinski wrote: I have developed a great liking for bug reports somehow. Then you just need to develope some skill for a) analysing bugs and writing useful reports and b) not going crazy when developers ask further question if they don't have a cristal ball handy. When I have more time on my hands, the bug reports become more comprehensive. Excuse me for being paranoid about bug reports, but some of the bug reports are really being overlooked. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#81396: root shell fscked after upgrade to woody
Colin Watson wrote: http://www.chiark.greenend.org.uk/~sgtatham/putty/ (hmm, I appear to have that memorized - I end up grabbing it any time I'm at a public Windows-based Internet terminal). way cool. a mud addict friend of mine always used putty, now i see why :) you can even do x-win style cut and paste with putty!! i didn't know it had ssh support. For what it's worth, I discovered entirely by accident that if you install telnetd-ssl then the telnet client in Windows 98 and above will connect to it and seamlessly do SSL negotiation, while of course non-SSL-capable telnet clients will still be able to connect insecurely. that sounds even better. perhaps ms is a good place to work at. :) thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
Branden Robinson wrote: I can handle it just fine when clueful people characterize me as psychotic. When professional ignorami like you get hysterical on two mailing lists and the BTS simultaneously over a FAQ, because you upgraded your production system to an unstable, unreleased operating system in a fit of hallucinogenic stupor, you do nothing but earn my contempt and a deserved rant. What do you expect when you swear like that upon an innocent bug report? BTW, I'm not a professional ignorami whatever that means, dear literary pioneer of the list. I upgraded our research cluster to unstable because I wanted to use it for testing the latest cluster software. If you call your insults to another contributor to debian deserved rant, then I'd think you are either misinterpreting your status or unaware of any social skills. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Bug#81396: root shell fscked after upgrade to woody
Hi
Manoj Srivastava wrote:
There is not enough information in this report to actually do
anything about debugging the problem. You don't even mention what
shell you are using as /bin/sh; what you have in /etc/environemnt;
what you have in the configuration files for the rot user, whether
you have tried any debugging echo statements (or set -x); whether you
have wnything in /etc/profile
Pretty standard in fact.
[EMAIL PROTECTED]:~# cat /etc/passwd | grep root
root:x:0:0:root:/root:/bin/bash
[EMAIL PROTECTED]:~# cat .bashrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files for examples
# If running interactively, then:
if [ $PS1 ]; then
# enable color support of ls and also add handy aliases
eval `dircolors`
alias ls='ls --color=auto '
alias ll='ls -l'
alias la='ls -A'
alias l='ls -CF'
alias dir='ls --color=auto --format=vertical'
alias vdir='ls --color=auto --format=long'
# set a fancy prompt
PS1='[EMAIL PROTECTED]:\w\$ '
fi
[EMAIL PROTECTED]:~# cat .bash_profile
# ~/.bash_profile: executed by bash(1) for login shells.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.
umask 022
# the rest of this file is commented out.
# include .bashrc if it exists
#if [ -f ~/.bashrc ]; then
#source ~/.bashrc
#fi
# set PATH so it includes user's private bin if it exists
#if [ -d ~/bin ] ; then
#PATH=echo `~/bin`:${PATH}
#fi
[EMAIL PROTECTED]:~# cat /etc/environment
LANG=C
--
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo
Bug#81396: root shell fscked after upgrade to woody
This is how it looks like [EMAIL PROTECTED]:~$ telnet borg Trying 139.179.21.143... Connected to borg.cs.bilkent.edu.tr. Escape character is '^]'. Debian GNU/Linux woody borg.cs.bilkent.edu.tr login: root Password: [EMAIL PROTECTED]:~# echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games [EMAIL PROTECTED]:~# su [EMAIL PROTECTED]:~# echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin [EMAIL PROTECTED]:~# exit exit [EMAIL PROTECTED]:~# exit logout Connection closed by foreign host. [EMAIL PROTECTED]:~$ How should I debug this? Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
Hamish Moffatt wrote: On Sat, Jan 06, 2001 at 07:48:58PM +0200, Eray Ozkural wrote: Such primitive reaction of yours is not likely to arouse interest in prospective contributors; to join debian and to work with people like you. Fortunately, Eray, we're not all here for your amusement. I'm not addressing you Hamish. In all of our exchanges, there have always been a dose of respect. Not with the xfree86 maintainer, though. In every exchange, he is acting like a raving lunatic. He's swearing like that in a public list. When a future developer sees that, what will he think? Will he be happy that he will be able to encounter some psychotic script guy? I'm talking only of the xfree86 maintainer. When a person is arrogant but a genius otherwise, you can overlook his ignorance of social norms from time to time. But this person is not that talented. And he is one of the most arrogant and irresponsible young computer-oriented persons I have ever encountered. His actions are simply not tolerable. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Bug#81396: root shell fscked after upgrade to woody
Hi Matt!! I don't report a bug due to misconfiguration. Let's see if what you see applies, though. Matt Zimmerman wrote: First, man su to find out where su(1) is getting its environment from. Searching for 'environment' on that man page, you can find this: The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the super user. This may be changed with the ENV_PATH and ENV_SUPATH defini- tions in /etc/login.defs. When using the -m or -p options, the users environment is not changed. Then, read /etc/login.defs. Note the values of the ENV_PATH and ENV_SUPATH options. These are used by login(1) and su(1). Test login(1) and su(1) and make sure they are doing what you expect. If they aren't, find out why. If they are behaving contrary to their documentation, file a bug. If they are, continue. [EMAIL PROTECTED]:~$ cat /etc/login.defs | grep ENV # Three items must be defined: MAIL_DIR, ENV_SUPATH, and ENV_PATH. #ENV_TZ TZ=CST6CDT #ENV_TZ /etc/tzname ENV_HZ HZ=100 #ENV_HZ HZ=1024 ENV_SUPATH PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin ENV_PATHPATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games #ENVIRON_FILE See Matt? This isn't the source of the problem. I didn't even touch it. Let's go on, sure. I'll try to overlook your insults and get to solve the problem. I checked it and it seems that I can login on this box (woody) directly with the SU path when I login from the console as root. But on borg which I observed the bug, when I login as root I only get the ENV_PATH man telnetd. Find out where telnetd is supposed to be getting its environment from. Traditionally, telnetd has called login(1) to complete the login process, but it sounds like that may have changed, or different options are being used. I don't run telnetd (and neither should you), so I can't walk you through this step as I don't have the package installed. I used telnet to demonstrate how it looks to a normal root login. We use telnet here because this is a diverse university network; we can't force people to run ssh and any moron could go root on this machine if he really wanted to. No tight physical security either. We trust each other here. Those are the major components that you're dealing with. Investigate the problem step by step, testing each component individually, and determine which component is causing the problem. If the problem appears to be caused by a software bug, isolate the smallest possible test case, and report a bug against the package which contains the buggy component. Optionally, you may investigate further, fix the problem, and include a patch. Really? Unfortunately Matt the components don't really include telnetd. Thank you for attending UNIX System Administration 101, followed by a brief introduction to deductive problem solving. Now please stop reporting bugs against general, and subscribe to a UNIX help mailing list. Why are you pretending that this is an FAQ. This happened twice on systems that I used, and was caused by an upgrade. I marked it important not because it is difficult to solve, but because it would apparently disrupt operation in a bad way. If you have a valid reason, you may decrease the priority to normal but otherwise stop ranting and try to help solving it. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
Oliver M . Bolzer wrote: You are still not getting it, arn`t you? It is not about the content at atll, is about quoting PRIVATE mail in PUBLIC places without asking FIRST. Sorry for shouting, but this has to be said. Yes, I am getting it. But I'd always thought that content did matter. [*] Legally, you might be allowed to (fair-use) quote private mail sent to you as one end of the communication pipe, but we are talking netiquette here. Really, it is not yours to decide wheter it is wrong or not to make that mail publicly available. It is only the authors choice. He might have whatever reasons to not want the content to be seen by the public. All right. I publicly apologize to Henrique for not asking him first. Ignore what I have quoted from him and consider only what I have written: --- Users here are not at all interested in the psychological state of a particular developer. On the contrary, every developer should be required to deal with every bug report in an objective manner. Inappropriate dismissal or incorrect evaluation of bug reports could be dealt with if bug reports were subject to peer review. I think that review by wider audience may be instrumental in that... - Thanks, [*] When we talk just about code, objectively, I wouldn't hesitate to post it to public places. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
Hamish Moffatt wrote: There IS a debconf question about it.. it's not like it just does it to you without asking. Maybe the debconf priority of the question is too low if too many people are missing it. Do you think this is also what prevented display managers (xdm, gdm, wings are the ones that I tries) to function correctly? Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
Hamish Moffatt wrote: On Sat, Jan 06, 2001 at 11:34:04PM +0200, Eray Ozkural (exa) wrote: If you call your insults to another contributor to debian deserved rant, then I'd think you are either misinterpreting your status or unaware of any social skills. I'm sorry, WHO is misinterpeting their status? I think the xfree86 maintainer is misinterpreting his status. As a prospective developer, I'd be greatly surprised if anybody told me that developers have the right to swear publicly in an outburst of adolescent frenzy. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Russell Coker wrote: I'm sure that Ben will welcome your contributions towards maintaining the libc6 package. All you have to do is read the list of bugs, solve some, and send in patches. I'm not trying to bash Ben. He did a wonderful work in resolving many bugs and generally keeping up-to-date with the CVS and builds of all architectures which is a difficult job. My suggestion is another: give packages multiple developers and have a more formal way for others to evaluate bugs... It wouldn't be wrong to have at least 2 developers especially for important packages. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Matt Zimmerman wrote: Oh, and just to chime in on this little bit, I did not start maintaining glibc until Aug 31, 2000 (my first changelog entry). So no, I have not been sitting on this for 7 months. Get your facts straight. And just to chime in, I appreciate the huge effort and many juicy changelog entries that have gone into libc6 recently. I do, too. I appreciate Ben's skills and effort. Sorry if there's misunderstanding. For instance, there was this bug about fmemopen() and a few days later, the fix from CVS was in debian. Amazing. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Russell Coker wrote: This is already being done for some packages. Check the maintainer address on the gcc package for an example. The thing that determines this is whether there are multiple people who are skillful and willing to work. If you want to be the second developer for libc6 then start fixing some bugs! Ahem! *choke* Perhaps, I must start with the (inaccurate) bug I'd reported!! I'll just determine the cause of that bug and see what I can do myself. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
[Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Hi, I'm sending this mail because libc maintainer seems to have closed the bug I've issued without doing any investigation on his own. Here's my original message --- Subject: libc6-dev: PTHREAD_ERRORCHECK_INITIALIZER_NP not defined as claimed in docs Date: Wed, 03 May 2000 22:03:20 +0300 From: Eray Ozkural [EMAIL PROTECTED] To: [EMAIL PROTECTED] Package: libc6-dev Version: 2.1.3-8 Severity: normal The preprocessor macro seems to be undefined. There are also other subtleties while using pthread lib, such as the __USE_UNIX_98 stuff, which I really don't know (I only use c++, and UNIX_98 sections don't seem to come along. Why is that?) Thanks a bunch, -- Now, I think what I say is fairly obvious but the package maintainer dismisses this bug like this with a changelog entry: * No reference to which docs, nor is there a test case, so: closes: #63511 The maintainer might have a lot of things to do, the package might have too many bugs open, and in the course of eliminating bugs he might have been too quick in his assessment. I DON'T CARE. If he hasn't the time/energy/mood to cope with a clear bug report like this (only the subject line is enough, the body is just comments) then I think more than one developer must work on libc maintenance; I don't know how many maintainers it currently has... Anyway, here is the _explanation_ for the bug report. There's a preprocessor symbol in posix threads. It's called PTHREAD_ERRORCHECK_INITIALIZER_NP. I claim that it has not been defined although it is said to be defined in the docs. Which docs? Obviously, the info manual since there is only *one* freakin' manual. Where in that manual? Any luser with a info browser that can search would find it: From File: libc.info, Node: Mutexes, Next: Condition Variables, Prev: Cleanup Handlers, Up: POSIX Threads Variables of type `pthread_mutex_t' can also be initialized statically, using the constants `PTHREAD_MUTEX_INITIALIZER' (for timed mutexes), `PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP' (for recursive mutexes), `PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP' (for fast mutexes(, and `PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP' (for error checking mutexes). So. That's where I say it is. Also I'm saying that I was using the lib from C++, so might this be causing my problem? And I pointed out that there might be some other problems with the preprocessor symbol _USE_UNIX_98. Of course, as the mighty maintainer of libc, Ben *does* know about UNIX 98 I presume. And that UNIX 98 *is* supported in libc, while in that version of the package it seemed to be *unsupported*. WHAT TO DO: --- * re-open the bug * learn about pthread, learn about preprocessor symbols in pthread, learn about UNIX 98, learn about info browsers. * find the corresponding node in the info manual. * try to use PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP * find out if it is defined or not. * if it is not defined * investigate why not. * see if this has any relation with _USE_UNIX_98 as hinted in the bug report * fix it * else * request submitter to replicate the bug * investigate further If bug submitters did all the maintenance work themselves, then there would be little need for the maintainer(s). I don't have to submit a test program for a bug as obvious as this one, neither do I have to submit a patch. That's maintainer's responsibility. I've just reported what I had thought, some many many months ago, to be a problem. Of course, the maintainer has not done anything about this report for 7 months, and then he closes it like that. Not good. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo---BeginMessage--- This is an automatic notification regarding your Bug report #63511: libc6-dev: PTHREAD_ERRORCHECK_INITIALIZER_NP not defined as claimed in docs, which was filed against the libc6-dev package. It has been closed by one of the developers, namely Ben Collins [EMAIL PROTECTED]. Their explanation is attached below. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact the developer directly, or email [EMAIL PROTECTED] or me. Darren Benham (administrator, Debian Bugs database) Received: (at 63511-close) by bugs.debian.org; 29 Dec 2000 20:17:00 + From [EMAIL PROTECTED] Fri Dec 29 14:17:00 2000 Return-path: [EMAIL PROTECTED] Received: from auric.debian.org [206.246.226.45] (mail) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 14C5xU-0005hm-00; Fri, 29 Dec 2000 14:17:00 -0600 Received: from troup by auric.debian.org with local (Exim 3.12 1 (Debian)) id 14C5cZ-0002Op-00; Fri, 29 Dec 2000 14:55:23 -0500 From: Ben Collins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Bug#63511: fixed in glibc 2.2-7
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Peter Palfrader wrote: Did you do this first? No. I'm sending it here because I want it to be seen. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Manoj Srivastava wrote: Wanted to make an ass of yourself in public, eh? Yep. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Ben Collins wrote: WOW. Go fucking figure. YOUR BUG REPORT says PTHREAD_ERRORCHECK_INITIALIZER_NP while this info page shows PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP argh. my first great mistake of the millenium. fuck me real hard. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Manoj Srivastava wrote: Indeed, you should feel lucky that even the non standard PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP is provided by the implementation, even though not present in ISO/IEC 9945-1 Yep, I know what NP means. My trouble was something else but I had thought that it was due to the symbol I told of being undefined. When I was doing it I was writing c++ wrappers for a large portion of the pthread lib, so if I can recall it correctly this time I guess the trouble was that I could not initialize error checking mutexes and had to resort to the basic ones... Are all three types of mutexes supported under glibc? According to the info manual it should be but...? Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Ben Collins wrote: WHAT TO DO: - Get a clue - Read better Roger that. Getting a clue: It looks like I was having a bad day; due to the nature of hack mode I have done it incorrectly Reading better: Looks like I'm still having a bad day. If I can't strcmp then how will I rightfully complain about my bug not getting attention? Sorry Ben. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Ben Collins wrote:
Oh, and just to chime in on this little bit, I did not start maintaining
glibc until Aug 31, 2000 (my first changelog entry). So no, I have not
been sitting on this for 7 months. Get your facts straight.
I'm really ashamed, Ben. Sorry, sorry, sorry. :{
--
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Now it's my unavoidable duty to find out what has caused me to file this bug. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
Tim Bell wrote: Now I'm sure Ben is plenty busy with libc6 and whatever else he does, and I don't mean to blame him for this slipping through. But the thought that bugs are getting closed without being fixed is worrying. That's my point. A package like libc6 is burdensome. It would not be fair to expect that a single person will always be able to keep a high level of responsiveness. It is worrisome that some bugs just go unnoticed because of shortage of volunteer time or for some other reason because this hurts the overall quality of the distribution. I think quality is one thing that Debian can and must surpass other distributions. I strongly feel that packages, especially important/big ones must have multiple developers / peer reviews and we should have some sort of check on how well the bugs have been evaluated. Still, I must apologize because the bug I reported was inaccurate, and all that. However, I would not have reported it if there was no problem. No bug should be closed without some investigation and communication by the maintainer. BTW, might bugzilla be better than Debian BTS in some aspects? Just a thought... Regards, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: RFC: pools and catagories of packages
[EMAIL PROTECTED] wrote: I don't know about freshmeat (I only use it for the software search engine), but IMHO Sourceforge suffers just as much or probably even more so from the current Debian hierarchy problem: too generic or just overcrowded categories. That's two of the problems I'm trying to address. Another is the structure of ontology: a single inheritance tree doesn't seem to be sufficient. Plus, we need a part-of hierarchy as well I'm sure... -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: bugs + rant + constructive criticism (long)
Branden Robinson wrote: You know, kinda like the way I went nuclear on Wichert when he broke vim. You use vi? Emacs rules. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80544: [rename] can't rename dir with valid permissions
Nathan E Norman wrote: On Thu, Dec 28, 2000 at 03:05:50AM +0200, Eray Ozkural (exa) wrote: Martin. Yes. I tried. Do you think I'm a newbie or something? Why do you think the file is owned by root? It's on windows partition... Hold on ... this is an msdos partition mounted? If so, check out man 8 mount; specifically the uid and gid options. i don't touch uid. it gets to be root but gid I changed, it's group windows and user exa is in group windows and I can rightfully move files in that partition BUT gmc (and most possibly mc) will not be able to rename stuff, though you can move files ;) It's a bug for certain! Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80544: [rename] can't rename dir with valid permissions
Chad Miller wrote: On Thu, Dec 28, 2000 at 05:41:28PM +0200, Eray Ozkural (exa) wrote: BUT gmc (and most possibly mc) will not be able to rename stuff, though you can move files ;) It's a bug for certain! Whoa. I don't understand that; what's the difference between moving and renaming? There isn't. gmc thinks there is. that's the bug! -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80544: [rename] can't rename dir with valid permissions
Hi Martin, in the light of what has been discussed... could you please replicate the bug and report upstream? thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: RFC: pools and catagories of packages
esoR ocsirF wrote: Greetings, IANAD, but I would like to suggest an idea that I had. There has been a lot of interest in getting packages arranged by different catagorizations, something like the menu. Most ideas that I have seen so far seem to imply adding new fields to the debs, but his seems like overkill to me. I'm working on it. :) Ideas were not constrained to adding new fields to the debs, which isn't sufficient on its own. Couldn't a new packages be created, something like a Catagories.deb that contained a databased of entries for each type? like... Graphics |_Gimp |_Xfig etc... Hmm. Have you read the discussion on this ML? Misclassification... thread I don't think another big tree is good enough. and when somebody thought that a package should be added to a catagory they just submitted a bug against the catagory package. Extra catagories could be added by bug requests also. This would allow package maintaners the ability to say where there packages belong but also the users would be able to feed back into the catagories as well. Well, good but not enough. We need a better way for developers and most probably *users* to work on categorization. You will be hearing some words about this from me *real soon now* Let me skip all the boring stuff and come to the exciting part. I'll develop an ontology tool for editing ontologies of the sort we need. What we need is an ontology formalism that supports categories and relations (such as sub-category or part-of). And does these in an intuitive way, etc. Right now I'm working on choosing a suitable formalism. So far my inclination is towards making my own simplified stuff because: * either they are too general (full KB support [ask,tell..], FOL, inference, axioms, etc.) like KIF based stuff. * or they are too specific. like SHOE. Ultimately, I will proceed in the following order * first, you will hear a design of this stuff. it will probably be a graph based formalism. similar to Conceptual Graphs perhaps, but will have just enough formalism to support our needs. and it *will* be intuitive * second, an implementation of this formalism as a pet language will follow. i'm supposed to finish this in 10 hours, but not likely :) * third, some kind of a user interface for single-person editing of ontologies * fourth, a client/server implementation will come. I'm hopeful that as soon as I get to the second stage, we will be able to get some part of the ontology right. If you are interested in this stuff, let me mention a cool feature I'm thinking of: generic ontologies: these are meta-ontologies that can be instantiated, it will be quite useful for us. I can do some ASCII art now!! Yehaaaw! Death to graphics formatS!! Now, all this discussion assumes you know a little bit about ontologies. You might wanna check ontolingua stuff. Check it out at http://www.ksl.stanford.edu/software/ontolingua/ On this list, I *promise* to post a more comprehensive description and collection of links which I'm doing as part of a grad. cs course. It's sort of a small web site done with screem. A generic ontology (I'm doin' only trees to simplify things) 080808080808080808080808080808080080808080808080808080808080 I remain consistent with my previous diagrams, it should be clear any way... / - - - - - - - - - - - - - - -\ |InfoProcApp: | Data | * * *| /|\ | / | \ | Processor Editor Presenter | | \- - - - - - - - - - - - - - - / InfoProcApp: Information Processing Application The box indicates a generic ontology package here named InfoProcApp. Here is a candidate ontology derived from InfoProcApp /-\ | GfxProcApp: | | Graphics | | *** | |/ | \| | / | \ | | Filter PaintApp Viewer | \-/ Now think of other stuff like this. The important thing is that we can say that these are all InfoProcApps. Now imagine this higher level hierarchy Application * * / \ InfoProcApp ** / \ DocProcApp--- GfxProcApp * ** * / \ / \ HTMLProcApp TextProcApp JPEGProcApp AnimProcApp * / MPEGProcApp Just to give a glimpse. Even the very simple generic ontology I gave can be very useful in devising a useful ontology. Of course that's not my last trick. :) The bag's full of 'em.. ;)
Re: RFC: pools and catagories of packages
Neal H Walfield wrote: I think that this is a reasonable idea, however, it only addresses a small part of the problem. I feel that a better solution would be to use a similar method to perl modules: a hierarchal name space. In fact, we We'll have better than that :) My tool will have a full package implementation (similar to Ontolingua's) but of course I'll avoid perl syntax at all costs!!! :) The cool part will be that we won't be making the same assumptions as a half-decent OO language. Apologies to perl freaks here, but that's what it is... By assumptions, I mean that symbol import/export will be a general construct in my impl. I think it will have to be as general as CLOS package system but let me finish the design first. Details later.. :) Frankly, I'm thinking of a single colon or a single dot for that... :) Of course the syntax is *totally* irrelevant here. It's the semantics that matters. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
vacation
I'll be off for a few days, so I may not be able to answer the posts in RFC: pools... thread. Happy New Year!! -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80343: general: Lack of policy on which files should be owned by which user
Peter Eckersley wrote: If my I want a file to be readable by everybody *except* user fred, I can set permissions: [EMAIL PROTECTED]:~ ls -l plot-against-fred -rwr--1 pde fred 1 Dec 27 17:12 plot-against-fred Of course, I need root access to do it :( ^^^ That's what troubles me. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80343: general: Lack of policy on which files should be owned by which user
Hamish Moffatt wrote: This is a big nuisance. I spent months working on a project with a shared directory without individual user groups. Worse yet, you can end up with a CVS repository full of files with user-only permissions (using a local CVS repositor, rather than remote). Ok. Then what I did was correct. I set up a developers group and put all devels there, then I changed umask to 002 in /etc/profile. I guess that's the way it works for multiple CVS users, right? Since there are per user groups, the umask won't disrupt any other operation. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80544: [rename] can't rename dir with valid permissions
Hi Martin, cross-posting to debian-devel because your assessment of the bug is totally wrong. Martin Bialasinski wrote: Hi, I can rename a directory to which I have permissions in shell orion:mp3$ ls -ald Rob\ Zombie/ drwxrwxr-x2 root windows 16384 May 21 2000 Rob Zombie/ These permissions are irrelevant. You want to change a directory item, therefore you need to have write permission on the directory containing this entry. Did you actually *try* to rename the directory on the shell, or did you conclude it should work from the above permissions? Martin. Yes. I tried. Do you think I'm a newbie or something? Why do you think the file is owned by root? It's on windows partition... And YES I've got group write rights. Why do you think I say that I have permissions? Do you think everyone reporting a bug is a lamer? Revise your prejudice please. orion:exa$ groups exa dialout cdrom audio dip video windows I can do ANYTHING I WANT to those files okay? only in gmc renaming (that is the old mv) will fail But gmc thinks I don't have sufficient rights and thus doesn't allow me to graphically change the name from properties!! awesome bug. I assume, you don't run gmc as root, and your primary group is also not windows. insufficient assumptions. primary group? hah. I can either change a file. Or not. Either I'm in a group or *not*. There is no in between like a *primary group*. If an application makes such a distinction, and does not allow renaming on the basis of a vacuous distinction like this, we call it a BUG. BTW, the same gmc happily moves files and dirs in the same directory. The only thing it can't do is renaming which is AFAIK the same thing as moving files. Check it out for yourself: orion:Stuff$ ls -ald desktop.* -rwxrwxr-x1 root windows 125 Nov 20 1998 desktop.ini orion:Stuff$ mv desktop.ini desktop.what! orion:Stuff$ ls -ald desktop.* -rwxrwxr-x1 root windows 125 Nov 20 1998 desktop.what! orion:Stuff$ mv desktop.what! desktop.ini orion:Stuff$ ls -ald desktop.* -rwxrwxr-x1 root windows 125 Nov 20 1998 desktop.ini orion:Stuff$ I am not making these up. It isn't fiction. I'm reporting a true event. :( I don't have to defend a bug like this. If you tried to actually reproduce it before dismissing it like this, you would see what an annoying bug it is. Do you prefer that the bug remains unreported? *sigh* I feel like a lot of bugs are being *censored*. :( -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80544: [rename] can't rename dir with valid permissions
Jason Henry Parker wrote: At a guess, I would say this is a non-bug. I'm saying that I can't rename a file using gmc which I *can* otherwise rename. So your first guess in not very accurate. You know how to rename something in gmc, yes? You do that in the properties of a file, by editing the name and then clicking okay. The edit widget there becomes a ghost item in this startling case. Try to reproduce what I do there. The permissions on parent are irrelevant. That's a vfat filesystem. Permissions are same everywhere anyway if you wonder. orion:exa$ cat /etc/fstab | grep vfat /dev/hda2 /winvfatdefaults,user,exec,suid 1 0 /dev/hdb1 /data vfatdefaults,user,rw,exec,gid=105,umask=002 1 0 /dev/sda4 /zipvfatdefaults,user,exec,rw,noauto0 0 /dev/sda1 /zip/ppa-bugvfatdefaults,user,exec,rw,noauto0 0 that happens to be data and gid 105 is windows !!! -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
(a small correction) Re: Bug#80544: [rename] can't rename dir with valid permissions
Eray Ozkural (exa) wrote: Try to reproduce what I do there. The permissions on parent are irrelevant. That's a vfat filesystem. Permissions are same everywhere anyway if you wonder. Sorry sorry sorry sorry. Permissions on parent of course do matter as you express. However, in this case the permissions are uniform so the problem is not that. Anyway, I can rename in bash but not in gmc. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80343: general: Lack of policy on which files should be owned by which user
Hamish Moffatt wrote: On Tue, Dec 26, 2000 at 04:43:53AM +0200, Eray Ozkural (exa) wrote: I like using groups to give different sets of rights and I'm annoyed by Debian giving every user his own group. Is that reall necessary? No, but it's a good idea. It makes it much easier to work in directories shared with other users (but not all users), because you don't have to keep changing your umask all the time, or even worse, fixing file permissions because you (or somebody else) forgot to change their umask. I always thought it was a paranoid kind of security feature in Debian. I might be wrong of course. How does giving every user his own group makes it easier for him to share files without system administrator's intervention? I couldn't guite get it, sorry I just woke up but I simply don't understand it. A small example? What's the harm in it? It populates the groups? I want only meaningful groups there. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80343: general: Lack of policy on which files should be owned by which user
Brian May wrote: zsh has in /etc/zshrc: [[ $UID == $GID ]] umask 002 || umask 022 My only dislike is it overrides my default setup in ~/.zshenv of 077. It seems wrong to put this stuff in zshrc, that only gets used for interactive shells. zshenv gets processed for all shells, but is run before zshrc. I use bash. Is this zsh better? :) Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager?
Joseph Carter wrote: On Sun, Dec 24, 2000 at 07:54:00PM -0900, Ethan Benson wrote: personally the plain text database is one of dpkg's greatest assets. its a royal pain to repair a binary database when it gets fscked. and yes i have already been saved from a total reinstall through the ability to fix dpkg's broken database with a text editor. if your talking about a different database then nevermind. Berkeley DB to text and back is pretty easy. Also, I was speaking of binary indices which are even easier to regenerate if corrupted. When I talked about binaries, people flamed me ruthlessly and without legitimate reasons. Hope your comments make them grok the point. Having bulky stupid slow text files all around your system is no guarantee of recoverability or reliability, whatever. Such feature comes from smart coding, not that things are text. The ideal system would be that doesn't need your manual intervention to keep things running. Example: checkpointing of package information which we _don't_ have. Some random postinstall file gets fscked and the system stalls, then you gotta fix it by hand. Ah, and if a large portion of the database is gone, there is nothing your stupid hand can do, anyway. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Misclassification of packages; libs and doc sections
Hi Thomas, I got back to working on ontology, and I'd like to give an answer to one of your previous remarks. Your last e-mail was a bit harsh but I'm hoping that you will find my view worthwhile. ;) Thomas Bushnell, BSG wrote: I think that logic has a great deal to do with semantics. I think that the mathematical notion Category Theory has a great deal to do with logic and semantics. And I don't think that the mathematical notion Category Theory has a great deal to do with the traditional philosophical notion of Category. As I read the views of Category Theorists themselves, I found out that their views were quite parallel with yours. They thought of metaphysics to be a distinct sphere of endeavor from that of mathematics as is the general attitude of a mathematician. In countless encounters, mathematicians did admit that they held their task as a subjective and intuitive effort rather than an objective hard science and that it had a boundary of its own. That its use did not necessarily indicate a relation with another field. I may use mathematics to explain a sociological phenomenon, but mathematics is not related to sociology; it remains separate. I believe most would claim such even for physics which itself has given way to new branches of mathematics. Anyway, mathematicians would mostly tell me mathematics != philosophy in strong words. Unfortunately, I have to disagree :) The creators of mathematical theories, which have been used in AI to explain how facts of world are to be represented, would say that the terms they have used are only borrowed. *The semantic content is entirely different* That I believe is also what you have stated in various ways. That the term category in Category Theory is very different from Category in study of ontology in philosophy. That is precisely where I think we *should* be skeptical about. After thinking about Feyerabend's view of scientific practice, I reached the following argument: Artificially separating mutually related theories into predefined domains of theories is not a fruitful methodology. It isn't because it is the enforcement of a particular progress methodology. That it is the correct way to draw a hard line between the philosophy and science of a thing. I cannot offer a proof of my argument why this methodology is wrong, because it has to be a historical rather than an analytical one. That I am not very skilled at; and I have limited space in this e-mail. In the context of our discussion, I think my argument would imply something of the following sort: We should not exclude the possibility that a new theory of categories, be it more metaphysical or more mathematical, depends on an important relation between the mathematical Category and philosophical Category regardless of whether prominent philosophers or mathematicians deny such a relation. That was a cumbersome sentence, but I can't word it better now :) The simpler statement would be that in new research we should utilize ideas from both worlds and try to exploit similarities as well as differences between them. I know this sounds confusing but I think it is an anything goes argument for research. We should not inhibit scientific practice before it happens. I've written this small piece because I was inspired by a work of Nicola Guarino. If you're interested I can send you links to some of his papers. Of course you can take a look at his work yourself. At this location there are many papers authored by him: http://www.ladseb.pd.cnr.it/infor/ontology/Papers/OntologyPapers.html Merry Christmas, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager?
Brian May wrote: 2. Get rid of maintainer scripts (don't ask me how...) so that upgrading packages is guaranteed not to destroy your computer, even if the package came an from untrusted source. This could be carried further by saying no daemons can be started by UID=root without express permission by some protected config file. Perhaps maintainer scripts can run from a chroot and/or non-root environment (issues remain unsolved). Won't ask you how :) Here's a MFTL sol'n :) You need to devise a package description/configuration language that is declarative rather than procedural. What comes to my mind would be some sort of logical language, maybe something based on Prolog. That the statements as your example would be implemented with it and then the package interpreter would handle the procedural aspects of upgrading. No religious wars, all right? :) Cheers, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Oops
Mistakenly sent to debian-devel. This is off topic. Merry Xmas to you all!! Cheers, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80343: general: Lack of policy on which files should be owned by which user
Brian May wrote: - harder to administrate /etc/passwd as more users exist. I like using groups to give different sets of rights and I'm annoyed by Debian giving every user his own group. Is that reall necessary? cu, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Misclassification of packages; libs and doc sections
Anand Kumria wrote: In future please send those kinds of emails privately. mis-take. :) -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80343: general: Lack of policy on which files should be owned by which user
Nathan E Norman wrote: On Tue, Dec 26, 2000 at 04:43:53AM +0200, Eray Ozkural (exa) wrote: I like using groups to give different sets of rights and I'm annoyed by Debian giving every user his own group. Is that reall necessary? It's useful when you're in a development environment where you've got directories that are group writable. On the other hand, I'd guess most large-scale development projects now use CVS rather than group writable directories as a sharing mechanism. I put CVS users in a group called developers. Is that wrong? Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Bug#80343: general: Lack of policy on which files should be owned by which user
Brian May wrote: exa == exa Eray writes: exa Brian May wrote: - harder to administrate /etc/passwd as more users exist. exa I like using groups to give different sets of rights and I'm exa annoyed by Debian giving every user his own group. Is that exa reall necessary? I don't do that on my machine here. Just edit /etc/adduser.conf Previously you had to be careful that the default umask was setup correctly, not sure if this is an issue or not now. Yep. I discovered that umask issue. I guess it's still a problem. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger wrote: Hello! I'm starting work on a new linux package manager. The idea is to be able to replace rpm, dpkg, apt, dselect (backend) with one,written mostly from scratch and designed to be as simple (code, not features) and clean as possible. For now, the work will be strictly academic, but if it works out, it may evolve into future standard package manager. open up a co-ordination page on sourceforge and start a public design process. do not stick to a religious idea like it should be written in C, or in perl. if you're really doing it for univ./research institute you will need some new features, otherwise the tool you're describing is a simple python/perl wrapper script that provides a common CLI to those tools that you mention. It would call 'em, UNIX way. So you need to give more details on what you want to achieve. Having some concrete goals is very important in this free software enterprise. So my question is: What do you wish for in a package manager? That it isn't just a package manager. It should cook the coffee for me. More importantly: It should be re-usable as a library for implementing packages/modules for PLs· That would make it pretty academic :) As a matter of fact I claimed to Anthony Towns that I'd rewrite dpkg for a test of skill during a friendly exchange. That's one of the features I really want for my future implementation. What do you think? Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager?
Joseph Carter wrote: I think if dpkg used some sort of hashed database index it would be a hell of a lot nicer to people's CPUs and memory. Whether or not that requires a re-implemenetation of dpkg or not isn't for me to say since I haven't looked at dpkg's code in 3 years. That smells like re-write. The scent of painstaking coding. Mmmm. -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: What do you wish for in an package manager?
Dwayne C . Litzenberger wrote: I wrote.. It should be re-usable as a library for implementing packages/modules for PLs· Erm, now I'm getting confused. I assume you mean that this package manager should also be a framework for loadable modules. Isn't that way outside the scope of a package manager? Can you give me an example? No. I don't think all the things a loader/linker does is useful here. But I do think that in a language that supports modularity, there would be a lot of common things a package manager ought to support. The most obvious and important being dependency information. Which modules use which modules? Less obvious perhaps a recursive namespace implementation. Think subpackages. You can view a package as something that exports/imports symbols perhaps. It doesn't have to be limited to files and directories. What I would want to see is a more abstract view of the process. In fact, one should view this as part of a software-engineering toolchain. It should play nicely with a corresponding build system, config system, etc. Off the top of my head of course. :) Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: Singapore Linux Conference
Branden Robinson wrote: Wow, I may have to revise my opinion of France, then. Isn't France the same country that tried to spy on Netscape's SSL implementation? -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Re: biweekly debian-installer status report
Randolph Chung wrote: The recent article in one of the Linux magazines about using netboot and dhcp to automate installs in a computing lab was very interesting. How can debian installer do something like that? i didn't see this article, but in many cases these are done with ghost images -- you create a boot image, and all machines either boot with that image (nfsroot type), or you duplicate the image over to the machine. it would seem that automated installs using either an answer file that is part of your installation media, or using configuration gotten from a central configuration database (ldap, pgsql, or what have you) will give you the flexibility needed to do mass installs in, for example, a lab environment. Of course you've checked Thomas Lange's FAI. The new installer should provide the same functionality as FAI. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
How do I build a package that requires the _source_ of another?
I'm building a package that needs the source of another (existing) package in Debian. You have to configure the source directory of that other program. What's the proper way to do that? I don't want to replicate the source dirs becase they take many megabytes. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How do I build a package that requires the _source_ of another?
On Wed, 13 Sep 2000 20:27:43 Marcus Brinkmann wrote: Avoid it like hell. This is really unpleasant. Please, please consider all alternatives. For example, fixing the program so that it doesn't require the other source. I was wrong anyway, but I'll avoid that in the future :) Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Insight progress
For those who're keen on seeing the insight and sourcenav packages, I've made some progress on the matter. I was unable to spare any volunteer time due to a hardware crash this week and a problem with the lame cable company the week before that, so there was a small delay. :I It seems that the package doesn't have to be a big tarball as previously suggested. It'll be called insight as I've ITP'd and the gdb version 5.0 will be a separate package. Go gdb! As far as I've tested it, both gdb5.0 backend and the GUI frontend are excellent. sourcenav package will be following insight. My work consisted of testing each file in the installation target against candidates in the Debian dist, that is I've determined all the dependencies. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: Source-Navigator
Yep, I ITP'ed sourcenav and insight.. a _minor_ problem with the tcl/tk stuff, but I think I'll just wrap it up soon. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: Source-Navigator
I ITP'd this before, hands off :) Why don't you check the list BTW? And the wnpp? That's why the BTS is being used, right? Here are the bug report numbers for your reference #68583: ITP: Insight #68584: ITP: sourcenav These are the ITP's I made some time ago, still working on them. I've had a machine crash, etc, but I still intend to do it. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dpkg-scanpackages arguments, output Packages files, and apt
I was running dpkg-scanpackages to construct a custom apt source. This was the first time I really ran it, so I encountered the peculiar style that I had to conform to. This was what I had to write to make a Packages file in a flat dir: [EMAIL PROTECTED]:~/public_html/debian$ dpkg-scanpackages . override ./ Packages This is a line from the output Packages file: Filename: ././ddclient_2.3.1-1_all.deb And this is the line required to indicate it as an apt source deb http://borg/~exa/debian/ ./ IMHO, this is all wrong. In the first one, the clumsy ./ is redundant, working directory can, and _should_, be assumed for the third argument. In the second, the output is redundant, it should simply be ddclient_2.3.1-1_all.deb and in the third one, the ./ is redundant, it should be regarded as default. And I was amazed at the fact that you need to provide both Packages and Packages.gz for some strange reason. I think apt-get should check if there is a Packages.gz, and if it isn't present fallback to Packages For which of these should I file bugs? Please don't tell me that these are the way they should be, they are obviously counter-intuitive and must be fixed. It shouldn't be difficult for the authors of apt, anyway. Thanks, -- -+++-+++-++-++-++--+---++- --- -- - - + Eray exa Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED]. ^ . .
apt source for sather and ddclient
You may use the following apt source for my ddclient deb and the sather debs that I've fixed for woody. deb http://139.179.21.143/~exa/debian/ ./ Please see ITPs on wnpp and on this list for information on these packages. Thanks, __ -+++-+++-++-++-++--+---++- --- -- - - + Eray exa Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED]. ^ . .
Re: Crazy idea: removing version numbers from debian
Thomas Guettler wrote: But I am interested what you think about this crazy idea to remove version numbers (like debian2.2) from debian? It's really crazy. Removing version numbers mean that the dependency graph must be synchronized globally which is impossible AFAIK. In addition to this, it renders the package pools idea essentially useless, which is the sane thing that is needed. :) A better idea would be to perhaps indicate symbolically the usability level of the package in the binary format. That might give users some convenience, I dunno. I have a lot of crazier ideas about distribution, release management and package classification so keep these mental inventions coming. :) This is exactly the place to discuss these. Thanks, -- -+++-+++-++-++-++--+---++- --- -- - - + Eray exa Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED]. ^ . .
Re: Rfp: galeon
orion:exa$ galeon /usr/bin/galeon-bin: error in loading shared libraries: libgtkembedmoz.so: cannot open shared object file: No such file or directory What's happening? Where's this library? How could I install the package if this is a dependency? Thanks, -- -+++-+++-++-++-++--+---++- --- -- - - + Eray exa Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED]. ^ . .
Re: Rfp: galeon
If that lib's in M17, how do I get M17 debs? Thanks, -- -+++-+++-++-++-++--+---++- --- -- - - + Eray exa Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED]. ^ . .
Re: Rfp: galeon
Seems like my mirror has somehow not been able to update. The latest I've got is M15.. Should check fmirror configuration. Thanks, -- -+++-+++-++-++-++--+---++- --- -- - - + Eray exa Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED]. ^ . .
Re: Intent To Split: netbase
I proposed using symlinks for programs in */sbin to enable normal users to see them in their default path, but now I think this is a bit messy. (For instance, /sbin/ifconfig - /bin/ifconfig, lots of these would be ad hoc) For simplicity's sake, I think it's just good enough to include /sbin, /usr/sbin and /usr/local/sbin in user's default path. That way, filesystem standard compliance is not disturbed, and the users have those programs in their path by default. Thanks, __ Eray Ozkural
Re: How many CDs in potato?
On Tue, 15 Aug 2000 19:16:16 Peter S Galbraith wrote: Can anyone tell me how many CDs the official ISOs have for: - i386 main + main/non-US ( + contrib ?) - sources I have a home made 4 CD set of binary i386 main + contrib + non-free I don't know how many CDs sources take. __ Eray Ozkural
Re: How many CDs in potato?
On Tue, 15 Aug 2000 19:36:26 Ben Collins wrote: Official sets are main+contrib, which is 3cd's. This can include non-US or not (only CD1 is different in that case). Sometimes vendors provide a 4th binary CD with non-free (may or may not include non-US/non-free). The source CD's are also 3 images main+contrib. Not sure how they handle non-US and non-free. That's a lot of CDs. Especially if you want the source, too. I wonder if it is possible to burn a DVD for the complete Debian 2.2 distribution? __ Eray
Re: Intent To Split: netbase
On Tue, 15 Aug 2000 21:43:31 Manoj Srivastava wrote: The question that seems to want to be raised is whether this is true? Are people really confused more by having extra commands available, or are they confused by _not_ havingcertain commands present? I was confused by not having ifconfig in my user path. On this machine, there's only a dial-up net connection, and it has some small connectivity problems. I need to check whether the line's really up. I found myself going super-user to issue the command rather than running /sbin/ifconfig. Which is in my opinion a stupid thing to do :), but of course it felt convenient to run sudo ifconfig, and then hmmm let's see... we must come to the conclusion that there are thousands of programs with non-sense names anyway, so it would be beneficial for the user to have anything that he can run on his path. If you want people to be able to navigate in the list of available executables in a meaningful way, please author a program that does it. Bash's command completion just doesn't scale. Menu system is a good start, but not the ultimate way to find out about which programs you may run. I'd recently written in another mail to this list: --- Although ifconfig resides in /sbin, /sbin is not in the standard user path. However, many users need to run ifconfig, such as checking the IP address, or whether a dial-up link has really come up. I think it would be beneficial to supply a symbolic link to /usr/bin for this purpose. It seems that some other programs might require similar arrangements. Rationale for this proposal: Users do not need to know the location of programs that they can run, they must be able to run all the user programs that they can. A user program in this context refers to programs which are intended to be run by people, In this sense, ifconfig seems to be a user program as well as a program that can be run automatically. -- Yes, and I got a wise reply claimining that ifconfig is a system program, and a user should manually augment his path if he wishes to run it. I request you to re-consider the proposal. Supplying a symbolic link would be better than putting the /sbin in user's path, because we may then decide which programs in /sbin are needed by normal users. Thanks, __ Eray Ozkural
Re: Pgcc in Deb
On Sun, 02 Apr 2000 20:28:41 David Starner wrote: Um, that's not what I've heard. Since optimizing for the Pentium will sometimes pessimize the Pentium (Pro, II, III), and the speedup from most programs is not that great, and anything that needs it can be recompiled locally, it wasn't worth the archive space or the manpower or extra trouble. I disagree. From experience, I know that up to %50 speedup can be gained in number crunching stuff. I'd suspect %20 could be pretty normal for most CPU hungry apps, and the overall speedup would be significant. __ exa Eray Ozkural, CS Dept, Bilkent Univ.
Re: A progressive distribution
Michael Stone wrote: On Wed, Mar 15, 2000 at 03:27:18PM -0500, Jaldhar H. Vyas wrote: > On Wed, 15 Mar 2000, Ed Szynaka wrote: > > > How does this account for drastic changes to something like libc that > > > might take weeks or months to shake out? > > Build daemons could take care of the 90% or so of packages that would just > need a recompile. That ignores the arguments over what needs to be recompiled, the time needed to discover problems, the time needed to make the compilations work, etc. Build daemons are not omnipotent. (Otherwise they'd be build deities...I digress.) All right. Why doesn't anyone take the tools developed in mozilla.org seriously? I think their build tracking tools are quite excellent. I'm sure that it would be a breeze to hinge a debian source build back-end to that and get it up and running together with the fancy web interface. -- Mike Stone Part 1.2Type: application/pgp-signature -- -+++-+++-++-++-++--+---++- --- -- - - + Eray "eXa" Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED] . ^ . .
Beyond Package Pools (Was: Re: A progressive distribution)
J.H.M. Dassen (Ray) wrote: On Wed, Mar 15, 2000 at 14:12:49 -0500, Jacob Kuntz wrote: try this hypothetical release method out: there are two trees. let's call them devel and production. debian saavy folks (maintainers) run devel. new packages are uploaded to devel where they are tested extensivly. when a package has been in devel for more than (for instance) two weeks, and it has no release critical and few important bugs, it graduates into production. the production branch should always work. But it won't. This approach ignores the fact that stability is a property of a release as a whole (the set of packages and their interdependencies, ISOs, boot floppies and the upgrade path from the previous release) rather than the sum of the stability of individual packages. Ray So, that's why the current scheme is correct? It obviously suffers from latency, though it doesn't suffer from quality. It doesn't suffer from quality, because releases are being managed, in order for a package to get into stable it has to go through extensive testing. That's in fact the main advantage of Debian. Now, how do we combine this with responsiveness, and an organic distribution like the FreeBSD? (in which there is rock-stable distro, a working distro, and an unstable distro, three of which are constantly developing) Here is the outline of a proposal which might do that: 1. Define subsystems within the debian system. One example is the X subsystem. However, that's too big. The point here is that the current classification of packages would be too coarse grained. I would suggest that, for instance, X applications that support gnome and are IRC clients are one class while console IRC applications are another class. A classification scheme as this would a) make browsing and finding of packages easier since it makes better use of real world semantics b) can be used to formalize things, it's just a DAG 2. Divide and conquer the release process. Define the dependencies and interfaces of each subsystem with others. Then, reorganize the release process as follows: a) A Release Team is responsible for each subsystem. The Release Team does not have to be comprised of developers of packages of that subsystem. Release Team decides which packages graduate to working and then to stable. Except that Release Teams may define other flavors of distributions for their subsystem. [Here I assume that package pools is working, and has three virtual distros called: stable, working, unstable] b) According to the number of packages (or the sum of weights of packages) in that subsystem and the number of dependencies with other subsystems (that's important), we give a weight to that subsystem. According to some thresholds, small subystems are release-managed by the smallest-weighted Team, closest up in the hierarchy. Some other thresholds may be used to indicate the importance of the release in that part of Debian. c) Debian has some serious glueware, config tools, and a complicated package management. The policy for dealing with package management and etc. seem to be quite effective at the moment. No need to fiddle with that. However, the Debian specific software is represented also in the regular release process, and since their weights would be great their importance would have been shown faithfully. The use of these tools, and policy is made even more comprehensive and documented extensively for other developers. d) There is a System Release Team which overlooks the activities of subsystem Release Teams and coordinates them and guides them towards some goals such as the release goals that Debian had in potato. The Release Teams can have their own release policies and quality considerations, however they would have to state their reasoning. The System Release Team *doesn't* have absolute control over the Release Teams, they just represent the overall concern for Debian. 3. Implement this new scheme. In the low level, tools such as debdiff and build daemons will have significance. In the high level, package pools, release management tools, and a web based status / modular organization tool must be handled, probably the bug tracking system should interface with this tool. Perhaps, the bigger release teams must have their own mailing lists and other communication media, too. A developer should be able to find other developers' contact information easily, and participate in subsystem discussions... This is quite open-ended. A point which might strike is the existence of task packages. Don't they constitute, somewhat the required organization? The answer is both yes, and no. The task packages in their natural extension could represent a part-of hierarchy in Debian. However, they have overlapping
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Paul M Sargent wrote: On a side note. I'm really not sure that this 'release' stuff works on debian. Coordinating the development cycles of an infinite number of packages is impossible. What I would like to see is an unstable tree where all development is done. As packages reach maturity they 'graduate' to the stable tree. A snapshot of stable tree at any time works. The unstable tree just becomes a place for developers to share packages. What happened to the package pools proposal? It's as if Debian developers are suffering from amnesia. I guess the package pools, as an idea at least, had found a significant appeal in this list. According to some form of that proposal, what you've mentioned and even better release flexibility would be possible. The key point is a continually evolving release. As has been said before, Debian isn't commercial. It doesn't have to behave like it is with releases. With a proper package pools system, Debian will have decoupled its archive structure from its logical structure. Well, not that innovative but a *linux*.com company would certainly push it as a technological advantage. It would seem that the independence of releases from actual archive content would lead to the possibility of avoiding the current rock-stable-and-completely-outdated stable and scary-and-top-notch-unstable release cycle. People could then prepare debian releases at some point between the two extremes. What is more, I think developers could organize themselves as teams, who try to maintain sub-releases for sub-systems. I think that kind of a flexible, and *distributed* release management is pretty open-ended. That seems to be the right way to motivate 500+ people working on such a large thing. To make this work major changes would have to be coordinated, but there is no reason that a major Perl change has to impact a major X change. Base packages like libc become more tricky though. Absolutely. While debian stable has a great QA, people *who do not run it on their spacecraft* will eventually yearn for the latest software. However, they will find the unstable distribution dangling to their disappointment. For instance, I've had some months of insanity due to a mysterious breakage of printing tools in potato. Few would then dare to make an upgrade to unstable. That is, you would certainly like some consistency and reliability, but not at the cost of missing a huge proportion of good software out there. That's what distribution is all about, right? Giving people some choices. Paul -- Paul Sargent mailto: [EMAIL PROTECTED] __ exa Eray Ozkural, CS, Bilkent Univ.
Re: FreeBSD-like approach for Debian? [was: Re: Deficiencies in Debian]
Hi, I'm not a debian developer yet (and seems like I won't even attempt till I feel that new maintainers are welcome), but I just wanted to comment on how a re-organization might be done. First of all, I'd like to state that dpkg system is all very well thought. Speaking of modularity, package management system is meant to provide it. However, making the base system as tight and as versatile as possible, I think has it benefits. Hmm, like how a small and open microkernel is the first condition for a modular OS core, the base system must be very selective about what is contained, and how new modules are introduced. BTW, keeping the source code of the base system in an integrated way is also useful, the base source could be responsible for defining some system characteristics and the boot environment. This might also make some base configuration possible: baseconf? I'm not sure, but it could help porting to other kernels as well... Another issue is the division of Debian archives and development into logical sections such that development gets a speed-up. In that respect, a minimal change to the current organization is necessary. Otherwise, the delays could even get longer. A good place to start is the profiles one can choose for dselect at install time. It looks like the tasks you can choose from are some gue collections of package. My proposal is throwing out an is-a/part-of hierarchy into those tasks. That way, the class diagram could account for the logical organization. The original system that assigns each package a maintainer need not be changed. Suppose that we allow the smallest leaf task to consist of 16 packages at most. Then what is required will be to assign each task a release-maintainer. I am aware that it is pretty rough at the time I write (and think). Nevertheless it might be a good start. (By leaf task, I mean those tasks which don't contain instances of others) Those tasks which have others as their parts or inherit from others may build a categorization that is both sensible and manageable. It seems to me that both part-of and is-a hierarchies (allowing multiple inheritance) is necessary to break down Debian into comprehensible units. In addition to this, such a categorization would be vertical to main/contrib/non-free separation -+++-+++-++-++-++--+---++- --- -- - - + Eray eXa Ozkural . . . . . . + CS, University of Bilkent,Ankara^ . o . . | mail: [EMAIL PROTECTED] . ^ . .
Re: FreeBSD-like approach for Debian? [was: Re: Deficiencies in Debian]
On Wed, 15 Sep 1999, Anthony Towns wrote: On Wed, Sep 15, 1999 at 02:34:55PM +0300, Eray Ozkural wrote: I'm not a debian developer yet (and seems like I won't even attempt till I feel that new maintainers are welcome), If you've got a really useful package done up that you think would add to Debian, get someone to sponsor you. I've heard the sponsorship idea, but I doubt it works gracefully. If you've got some free time, and just want to help, write some manpages, fix some bugs, work on boot-floppies, stuff like that. submitting bugs is the easiest, and I try to do it whenever possible. Though I'd prefer to code things. Activity like that's *very* welcome. Specifically, I'm about to install a Debian based Beowulf-cluster. I'll package things up and make them available. I'm considering beowulf kernel patches, scripts, adm tools, doc, etc. Hopefully, installing beowulf nodes and server/development workstations that run Debian will be easier. `baseconf', is, I guess, what the bootfloppies' dinstall program does. If you're interested, you could probably mangle dinstall and debconf to come up with something that achieves all that and more. I know what dinstall does. I thought of something that would help conf. a base system on an already installed system, actually being a front end to configuration scripts for the spooky base source I was talking about. Another issue is the division of Debian archives and development into logical sections such that development gets a speed-up. In that respect, a minimal change to the current organization is necessary. Help make the current system work. Spend a couple of months on that, then start thinking about what can be changed, having been a part of it on the inside, as well as just watching. Definitely, that's what I should do. Though all the slink's I installed are working great except a couple of rare bugs. It's really not as horrible as everyone seems to want to make out. It's got us to being among the very best distributions on just about every level, and it's managing to keep us there, too. Well, I think it's far from being horrible. So far, this is the only Linux distribution that cares about technical issues. Wht I proposed was meant to organize things in a way to improve on some of the aspects. In particular, I think the release work could be better coordinated if a logical higher level categorization is brought. Cheers, aj, wondering at what point he should killfile the naysayers instead of trying to refute them Keep cool, -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds __ exa
