Beowulf/Mosix Packages(Was: Re: FreeBSD-like approach for Debian?)
Yep, the debian-beowulf list is pretty silent. Now that I'm going to be installing an x86 cluster within 2 weeks, I might get my hands on some useful clustering software before the code freeze. Drake Diedrich says he can sponsor the packages, so it'd be great to package the good stuff. There's a load of software to consider but I think I can sum it up as my work on the cluster progresses... __ Eray Ozkural - This message was sent using Bilkent University WEBMAIL Services http://mail.bilkent.edu.tr
An extended proposal concerning Metapackages
While discussing Free-BSD style base system installation I'd come up with the
following suggestion:
\begin{quote}
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 arbitrary collections of packages. 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
\end{quote}
Now, what I speak of sounds pretty nice, but it is too theoretical to improve
upon. As I understand, the latest thread on metapackages have somewhat
approximated to what I'd suggested.
There are a number of facts to sort:
1) dpkg provides an is-a hierarchy: package x is a contrib, devel, required
package. That is a straightforward classification, but it is beginning to
become insufficient as the archive size grows.
2) Installation profiles/tasks/metapackages: these provide us with some
elementary part-of organization. However, the current approach does not scale
perfectly and it's likely that there's room for improvement.
3) A revision of package organization is quite beneficial: it can help users
(installation/menus/documentation) and developers (better co-ordination for
release work, better comprehension of the software in Debian).
4) The implementation must not require a major rewrite of related components.
(The new categorization must be vertical to the existing ones)
So, how do you achieve such functionality? I think that, while keywords are a
good aid for searching packages, they don't constitute a sufficently formal
categorization. We should aspire at constructing a rigorous OO model for
defining: what type a package/task is, and what the structure of a package/task
is.
Once categories/classes for the Debian archive are developed, it will be
possible to keep them up-to-date with little effort. What's more, all packages
in Debian that >>list the packages<< can make use of the tools/libs that have
been written. Defining the organization using OO methods will also help us
analyze the system in better detail. When the subsystems are designated
precisely, the system can be made more modular: the relationships between
modules can be properly determined, and improved upon.
How this should be implemented, I believe, is a question that isn't trivial. I
suspect it would be easier to use a language which already has support for OO
programming. ;) But also I think making it some kind of library would work
best. I'm afraid changes at both apt/dpkg level and
metapackages/dinstall/whatever level is necessary for ramping up to such
functionality.
Hope you don't flame me for not being a Debian developer and referring to
Debian developers as "us". However, I'd like to make all the thought
contribution possible if not as source code. I'm not blindly advocating an OO
design/implementation, but I suggest such a thing because it is the only right
way to go. Sometimes I feel a push for the design part of things, that's it.
__
Eray 'exa' Ozkural
CS, Bilkent Univ., Ankara
-
This message was sent using Bilkent University
WEBMAIL Services http://mail.bilkent.edu.tr
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: 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)
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 parts. That's why they're not strictly part-of hierarchies. Indeed, they represent differing "user views" of the system. This might, and *must* be merged with a formal part-of and is-a hierararchy, as it might cure some of the worse pains that await Debian in the future (when we have 20.000+ packages!) I have an idea of these user views as a way to formalize the Quality Assurance process, so that it can be modularized in a way similar to the one I have suggested for the Release process. Package pools, of course, is the main issue here. It is *the* mechanism which lets developers create their own virtual distros, etc. This proposal lays out a way to combine the flexibiliy of package pools with the quality provided by the Debian releases. Comments welcome, Regards, -- -+++-+++-++-++-++--+---++- --- -- - - + Eray "eXa" Ozkural . . . . . . + CS, Bilkent University, Ankara ^ . o . . | mail: [EMAIL PROTECTED]. ^ . .
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: 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: 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
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: 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]
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]
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]
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 "module"s 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
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
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: 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 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: 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: 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#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
ive 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.. ;) Caveat Emptor: Some guy or two are sure to show up and make more bigotry in the lines of "we don't need this stuff. get us some stupid tree that works, and we'll be set...".. Hell, No! That's the last thing I will ever do!! And I will not take any such comment seriously. To my knowledge I'm the sole person who has made any serious attempt at software package ontology and I would like to make the most useful tool possible. When the tool gets to be a bit standard, I'll deploy it for other interesting applications. (the most immediate is some kind of a bookmark /personal-data manager) Constructive comments most welcome. Criticism without reading any of the papers I'd linked to before on this list will not be tolerated!!! 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
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: 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
[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--- Begin Message ---
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 (Exi
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: [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
Bug#81396: root shell fscked after upgrade to woody
Package: general Version: N/A; reported 2001-01-06 Severity: important After I upgraded from potato to woody on an i386 machine, I observed a strange sympton I login as root. It doesn't matter where, console, X or from network... When I check the environment, normal user environment is present. If I run apt-get upgrade for instance the program will complain that path doesn't have the *sbin directories which is the way it should be. The quickest way to fix it is to type # su and then I can run any root process without errors on this child shell. I observed the exact error on another installation while upgrading from slink to potato so I presume this is a bug which has not been addressed yet. I had then thought this was a "feature" not a "bug" but now I'm certainly sure it's a bug because the machines I installed from scratch *never* show this behaviour. Thanks, -- System Information Debian Release: woody Architecture: i386 Kernel: Linux borg 2.2.14 #1 Wed Mar 29 19:43:52 EEST 2000 i686
[authorization] fails silently for normal users, cannot start server
Package: xserver-xfree86 Version: 4.0.1-9 Severity: important When I try to start X server as a user, the X server complains that the authorization has failed and terminates. Likewise when trying to login from gdm (tried other display managers, too) I can't paste anything now but as far as I can summarize: from auth.log, a message like PAM_unix[...]: authentication failure; (uid=0) -> exa for gdm service exa is a normal user here, and gdm is the standard gdm. exa's uid is 1000 That's when I try to login from gdm. When I try to login from console the error is more silent. PAM_unix[..]: (login) session opened for user exa by LOGIN(uid=0) what is going on here? :((( none of our users can login to X for the past 6 weeks!!! help please. Thanks, -- System Information Debian Release: woody Architecture: i386 Kernel: Linux borg 2.2.14 #1 Wed Mar 29 19:43:52 EEST 2000 i686 Versions of packages xserver-xfree86 depends on: ii debconf 0.5.34 Debian configuration management sy ii libc6 2.2-6 GNU C Library: Shared libraries an ii xserver-common4.0.1-11 files and utilities common to all ii zlib1g1:1.1.3-11 compression library - runtime
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: 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
mozilla 0.7
Hi Myth and all, I filed a bug report about the new mozilla 0.7 release. It looks like it's got PSM built in so it will comfort a lot of people. It would be highly appreciated if you could give it a whirl. Regards, __ Eray
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
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
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-
