Re: A progressive distribution
On Wed, Mar 15, 2000 at 09:35:16PM +0100, J.H.M. Dassen (Ray) wrote: On Wed, Mar 15, 2000 at 15:06:57 -0500, Jaldhar H. Vyas wrote: It wouldn't help with out and out buggy programs but at least it would catch dependency problems. It would catch problems with the dependencies a package declares. But it's no substitite for integration testing, part of which checks that the declared dependencies of a package accurately reflect the real dependencies. true. that's why there will still a need for the freeze/test/release part of the cycle even after automated snapshot releases are possible. snapshots will get the latest stuff out to the nearly-bleeding-edge users fast (hopefully once/month)...those users will then use test the software. final testing as an integrated system will be done as normal, with our usual freeze/test/release procedure...but should go faster because many of the serious package bugs will have already been found by snapshot users. as i recall it, the basic package pools idea was something like: development cycle: incoming - packages arrive here and stay until all dependancies are met (i.e. satisfied by the packages in unstable or incoming) unstable - packages auto moved to here by dinstall if no dep. problems ??? - packages auto moved to here after basic criteria met (e.g. in unstable for 2 weeks with no bug reports). can't remember what this stage was to be called. snapshot - built automatically from the latest stuff in '???'. release cycle: frozen - forked from the latest snapshot when the release team feels it is nearly ready. stable - final release, after testing, debugging, and integration work (both cycles can, and probably will, occur simultaneously. the release cycle can happen as often as the release team have the energy for it, perhaps with as little as a few weeks or a month between a stable release and the next freeze) target users: 'unstable' will probably be used mostly by developers and bleeding-edge type users. 'snapshot' will be used by those with fewer guinea-pig genes, who want something up-to-date but with major obvious problems resolved. 'frozen' is for those who just can't wait for stable or who want to help with final testing. 'stable' is for everyone. craig -- craig sanders
Re: A progressive distribution
On Thu, Mar 16, 2000 at 11:02:31AM +1100, Craig Sanders wrote: ??? - packages auto moved to here after basic criteria met (e.g. in unstable for 2 weeks with no bug reports). can't remember what this stage was to be called. i feel a need to write some more about this stage. this is the workhorse of the package pools/rolling release idea, this is where there will be the most work to be done, fine-tuning the criteria (and probably the source of the loudest and longest debates). there have already been several discussions on appropriate criteria...some as simple as the automatic after two weeks example above. others as complex as manual, requiring endorsement by X number of people. by trying different criteria here, we'll eventually come to the ideal compromise between stability and speed of release. we probably wont get it right the first time around. the tests here will mostly be regarding usability/stability of the package, and how it integrates into the system - i.e. it will be driven by user bug reports as most packaging bugs will have already been caught by the dinstall process which moves packages from incoming to unstable (which would check for dependancies and run a lintian test, holding or rejecting packages which have errors) craig -- craig sanders
Re: Permission policy
On Wed, Mar 15, 2000 at 01:12:49PM +0100, Volker Ossenkopf wrote: I need some advice to solve a recent bug report regarding a frozen package. You could make it suid to a user who has 2 additional groups. In that case the program should reset its uid after the devices are open (same would be true for suid root, but thats not a good idea). BTW: there is a idea for settig groups for console access to devices like cdrom, floppy, sound, mic, cam... so each user who logs into the sonsole will get added to that groups, then your program does not need to be sgid anyrthing, which is bad anyway since everybody even on networked terminal could start it. Greetings Bernd
Re: Apt-Problem
On Wed, 15 Mar 2000 19:18:24 +0530, Syed said: On Wed, 15 Mar 2000 14:17:54 +0100 (CET), Andreas Tille [EMAIL PROTECTED] said: Andreas http://ftp.tu-clausthal.de/pub/linux/debian/dists/frozen/main/binary-i386/devel/libtool_1.3.3-9.deb Andreas Size mismatch E: Unable to fetch some archives, maybe try Andreas with --fix-missing? Andreas As I said I could install the package using dpkg -i Andreas /var/cache/apt/archives/partial/libtool_1.3.3-9.deb Andreas without any warning/error. I got the same error when I was doing an apt-get upgrade last night. It was with man-db. But when I did an apt-get upgrade after sometime again, it did not reget the package again, but installed with the same old package succesfully. anybody knows what this is ?? - Khader I had the same problem (and same output) when doing apt-get upgrade last night. I used apt-get clean and apt-get install man-db before trying apt-get upgrade again. The problem went away, so I thought it had been a hardware problem on my end, but I guess I was wrong. Anyone know what happened? -ptw
intent to package VTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have a start on packaging The Visualization Toolkit, as described at http://www.kitware.com/vtk.html Interested persons may see my preliminary efforts at http://master.debian.org/~bottoms/debs/ I am accepting comments on my choice of package names for the component binary packages: vtk- Binary Tcl interpreter libvtk - .so files for C++ and Tcl bindings libvtk-dev - Header files libvtk-patented - Software patents and commercial use restrictions vtk-python - Python bindings vtk-examples - as included in upstream source I'd like to hear comments on Mesa/OpenGL issues. Right now I am building against mesag3. Also, this could be built with Java bindings - any good strategies for building a vtk-java package? There also appears to be some attempt to build against MPI libraries. After a little bit of testing, I expect to be able to upload the set for inclusion in woody by this weekend. (Built on a potato system) - -Maitland -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard http://www.gnupg.org/ iD8DBQE40EctkwbJvNrxBUwRAqNaAJ44xcWnJl4XNm2dTE2VH0l+VNq8xwCfXkMA BT7CX5hh+tHMaToHnuZXJhk= =ZC+j -END PGP SIGNATURE-
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On 15-Mar-00, 01:06 (CST), Craig Sanders [EMAIL PROTECTED] wrote: DO NOT PUT WORDS IN MY MOUTH. your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. Hmm, it's ok for you to misrepresent other people's arguments, but not the other way around, as follows: so why do you have a problem with infrastructure (i.e. package pools in one form or another) which makes it easier to build a snapshot image? do you have some kind of aversion to automating tedious and time-consuming tasks? DO NOT PUT WORDS IN MY MOUTH. your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. (And you *are* mispresenting my point, because you completely ignored the next paragraph where I spoke favorably about package pools.) and fuck you too! how dare you fucking misrepresent my position and twist what i said in such a reprehensible manner? Why not? You do it to everybody else. In the meantime, plonk! Cheers, sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
On Wed, Mar 15, 2000 at 08:41:01PM -0600, Steve Greenland wrote: On 15-Mar-00, 01:06 (CST), Craig Sanders [EMAIL PROTECTED] wrote: DO NOT PUT WORDS IN MY MOUTH. your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. Hmm, it's ok for you to misrepresent other people's arguments, but not the other way around, as follows: so why do you have a problem with infrastructure (i.e. package pools in one form or another) which makes it easier to build a snapshot image? do you have some kind of aversion to automating tedious and time-consuming tasks? DO NOT PUT WORDS IN MY MOUTH. notice that i asked questions. it up to you to confirm or deny or ignore a question. it implicitly gives you the opportunity to accept or refute the query, without a prejudgement of the situation. what you did was quite different. you came up with a reprehensible misinterpretation of what i said and what my views are, and then projected it onto me. you *stated* that your offensive misrepresentation was my position. do you comprehend the difference? your argument for want of a better term is obviously so poor that you have no choice but to misrepresent mine to make your points. (And you *are* mispresenting my point, because you completely ignored the next paragraph where I spoke favorably about package pools.) no, i stated that you made no points. that was a) true, and b) nothing like deliberately misrepresenting your points. and fuck you too! how dare you fucking misrepresent my position and twist what i said in such a reprehensible manner? Why not? You do it to everybody else. fuck off, lying scum. In the meantime, plonk! plonk your fucking self. arsehole. craig -- craig sanders
Re: Permission policy
On Thu, Mar 16, 2000 at 01:43:22AM +0100, Bernd Eckenfels wrote: BTW: there is a idea for settig groups for console access to devices like cdrom, floppy, sound, mic, cam... so each user who logs into the sonsole will get added to that groups, then your program does not need to be Which is a waste of effort if the user can create a sgid shell. -- Mike Stone pgpoOhrqTUiQq.pgp Description: PGP signature
Re: A progressive distribution
In article [EMAIL PROTECTED] you wrote: You know, the whole concept of 'a release' is orthogonal to the way I think about Debian. We've been through that before, too, and I understand the various reasons that it's important for us to make a release from time to time... but I doubt any of my machines will ever run a release. The beauty of the Debian development model in the presence of sufficient network bandwidth is that you don't have to wait until some release happens to get new functionality or bug fixes... The package pool concept on some level is just an efficiency hack for managing the master archive site better, but it is also fundamental enabling technology for supporting the idea of having multiple simultaneous flavors of Debian. this is the workhorse of the package pools/rolling release idea, this is where there will be the most work to be done, fine-tuning the criteria (and probably the source of the loudest and longest debates). Absolutely. What I realized after talking to Manoj at some length face-to-face at the Usenix Tech conference in New Orleans a couple of years ago is that we will need to have different snapshots (I actually don't like that name) with different criteria. He and I had a fundamental difference of opinion about how automated the package promotion to stability should be. I think we both had reasonable approaches, and there's no reason not to implement both if people want them. The beauty of the package pool concept is that the cost of each flavor is pretty low, so there's no reason we can't have a number of them. Some might be different levels of stability towards a release, some might be proper subsets like Debian Jr. There are a number of secondary issues, like how many versions of each package you can afford to have in the pool before you run out of disk space, but those are all manageable... and we'll learn by doing. I gathered from Guy's email a while back that a prototype might be underway on a Debian machine somewhere. I have spent a bunch of time talking with the other developers at work, one of whom gets paid to do revison control and release management for a living, about this. I believe there are enough interested people willing to work that we *will* have something in place before woody, but I've promised myself that I won't personally do any more work on package pools until potato releases. Bdale
Re: priority of x-window-manager
Hi. Branden Robinson [EMAIL PROTECTED] writes: On Wed, Mar 15, 2000 at 09:04:47PM +0900, Changwoo Ryu wrote: Korean (and maybe Japanese) X users often see the Netscape titlebar incorrectly displays Korean web page title. Many of the window managers still don't care about this and just draw the raw string with XDrawString(). The correct behavior is decoding the received compound strings and drawing the decoded ones with XmbDrawString(). I'm willing to support such a priority increase now; but first, please come up with a list of specific things that a window manager needs to do. Thank you Branden, and Changwoo. I am happy to read this. We can't just say add 10 points if the window manager is internationalized without telling the possible thick-headed American package maintainer how to determine whether it is or not. :) I have thought that users can judge if the specific software is correctly internationalized or not, and they will file their report on BTS if they find the wrong priorities. But your concern may be reasonable. One item would obviously be: + The window manager should use XmbDrawString() instead of XDrawString() for non-error/non-diagnostic text output. Please come up with more, if there are any, and I'd be happy to make a new policy proposal incorporating your suggestions. In fact, the true internationalization may require more than just replacing XDrawString() with XmbDrawString(), but this is a good indicator as a start point, I think. # Anyway, users will file their report on that package if it can not be used. Just one thing: Error text output could be localized one (libc does have localized error messages for such as No such file or directory or File exists. So excluding error output is not good in this case, I think. -- Taketoshi Sano: [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
Intent to Package udmsearch
udmsearch is a website indexer and, I'm going to package it! More info about it at http://mysearch.udm.net/ -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 Eye-Net Consulting http://www.eye-net.com.au/ [EMAIL PROTECTED] MIEEE [EMAIL PROTECTED] Debian developer [EMAIL PROTECTED]
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Steve Greenland: Hmm, it's ok for you to misrepresent other people's arguments, but not the other way around, as follows: Craig Sanders: so why do you have a problem with infrastructure (i.e. package pools in one form or another) which makes it easier to build a snapshot image? Steve Greenland: (And you *are* mispresenting my point, because you completely ignored the next paragraph where I spoke favorably about package pools.) Here's what Steve wrote: If you want to work on the unstable stuff, I think the package-pool implementation would good place to start. Craig Sanders: notice that i asked questions. it up to you to confirm or deny or ignore a question. Statements are confirmed or denied, not questions. Questions are answered. There's a gigantic difference between these two questions: do you have a problem with infrastructure (i.e. package pools ...)? why do you have a problem with infrastructure (i.e. package pools ...)? You wrote the latter, which clearly misrepresents what Steve wrote. You seem like a smart guy, so I can only assume you were being dishonest, and not just incompetent. Combine that with your selfishness, your arrogance, and your excessive, unnecessary, and juvenile obscenity, and here's what you get: *plonk* -- Brian Kimball
Re: priority of x-window-manager
On Thu, Mar 16, 2000 at 02:16:42PM +0900, Taketoshi Sano wrote: We can't just say add 10 points if the window manager is internationalized without telling the possible thick-headed American package maintainer how to determine whether it is or not. :) I have thought that users can judge if the specific software is correctly internationalized or not, and they will file their report on BTS if they find the wrong priorities. But your concern may be reasonable. Well, what I want to do is have very clear guidelines so that we don't have any bug terrorism. Violating policy is often interpreting as being a release-critical bug -- so if we put this into policy, I want to try to be very clear about what kinds of i18n problems are going to hold up a release, or cause a package to be removed from consideration for a release, and what kinds won't. One item would obviously be: + The window manager should use XmbDrawString() instead of XDrawString() for non-error/non-diagnostic text output. Please come up with more, if there are any, and I'd be happy to make a new policy proposal incorporating your suggestions. In fact, the true internationalization may require more than just replacing XDrawString() with XmbDrawString(), but this is a good indicator as a start point, I think. Yes, that's what I'm trying to get at. Obviously there's more to i18n than just replacing function calls, or everything would have been i18n'ed already. :) But since I have only a shallow understanding of i18n issues generally, and in implementing them in X window managers specifically, I wanted to request input on this issue. # Anyway, users will file their report on that package if it can not be used. Just one thing: Error text output could be localized one (libc does have localized error messages for such as No such file or directory or File exists. So excluding error output is not good in this case, I think. Yeah, but here's where we run into the specter of l10n again -- which I very strongly feel shouldn't be mandated by policy. Here's what I'm getting at -- if an X client has been internationalized, and it provides locale specific information to the window manager, the window manager needs to be able to deal with that. The XDrawString() vs. XmbDrawString() issue is a perfect example; I've *seen* the title of my Netscape window become total gibberish (in any language), because the window manager didn't use a multi-byte character aware function to render it -- if it did, I'd see proper Japanese glyphs (which I don't understand, either -- but I recognize them as human language rather than a machine-readable encoding method like Shift_JIS or EUC-JP). Error messages are another story. If the error messages come from outside the window manager, and are already localized, then the window manager shouldn't mangle them. I don't, however, think that the window manager should be compelled by Debian policy to have an internal message catalog for various languages. To sum up, what I'm saying is this: I think a Debian window manager policy should say that window managers should be given higher priority if they DON'T mangle localized information that they are intended to pass along to the user. And that is what I understand internationalization of computer software to mean -- it makes localization transparent and possible. -- G. Branden Robinson|Men use thought only to justify their Debian GNU/Linux |wrong doings, and speech only to conceal [EMAIL PROTECTED] |their thoughts. roger.ecn.purdue.edu/~branden/ |-- Voltaire pgpzcMtghfvPb.pgp Description: PGP signature
Re: Embedded(/RT) Debian? Embeddian GNU/Linux?
* Joe Block [EMAIL PROTECTED] [000315 18:25]: I'm interested. I'd like to be able to make a boot disk with ntfs vfat support so I can use it as a rescue disk for hosed windows boxes. Ideally, I'd like to see a shell script that asks what network card the target box uses and creates a new rescue floppy with just that module. I am not sure the stuff I am working on is optimal for your purposes. But of cause you are free to do with the stuff what you like to do. I put a mds (minimal debian system) snapshot on ftp.andrive.de/pub.
ITP mgeupsd
Package: mgeupsd Architecture: any Conflicts: powstatd, bpowerd, genpower Description: UPS monitoring software for MGE (Merlin Gerin) Pulsar UPS series It operates in the usual for Linux UPS daemon way, i.e. if the UPS changes status, it creates /etc/powerstatus and sends SIGPWR to init. Mgeupsd is also able to act as a server for remote monitoring through the network if more than one machine is connected to the UPS. MGE does have software to monitor this UPS on it's web site, but it did not make a suitable UNIX workstation UPS daemon (I have a feeling it was some kind of port of some kind of dos/ms-win software). This works for me, and I think other debianers with this family of UPSs might appriciate it. -Robert -- [EMAIL PROTECTED] | Bother, said Pooh as he struggled with finger for (pgp|gpg) key| sendmail.cf, It never does quite what I | want. I wish Christopher Robin was here.
Re: ITP mgeupsd
On Wed, Mar 15, 2000 at 11:21:14PM -0800, Robert Stone wrote: Package: mgeupsd Architecture: any Conflicts: powstatd, bpowerd, genpower Provides: ups-monitor Conflicts: ups-monitor This will catch all the other ups daemons. I am packaging Network UPS Tools (NUT). I have finished and am just waiting for my sponsor to upload the package. NUT will soon be a woody package. NUT provides a pretty decent client/server architecture for supporting multiple boxen on one UPS. The project provides interfaces to wide variety of UPS's. I am not the author of NUT. However, if you are the author of mbgeupsd, you may wish to contribute to NUT. NUT can be found at http://www.exploits.org/nut/ Just an idea, Luca -- Luca Filipozzi, EMYRnet
sendmail M4 to run DNS based spam filters per RCPT
I've written an M4 file for sendmail 3.9.3, and packaged it up as a debian package. I'd like to contribute it, and I'm willing to maintain it, since I'm doing so anyway here where we use it. However, I do not have time to keep up with this mailing list, and after perusing www.debian.org, and this list, I'm left to wonder if it's even worth my time to jump through hoops pursuing debian developer status. The source and binaries are at: ftp://ftp.oro.net/pub/useful/sendmailblacklistbyrcpt* Here is a description of the package: This package makes available an independent feature to sendmail, similar in function to the FEATURE(rbl) offered in standard sendmail 3.9.3. Blacklists_by_rcpt allows greater control over when DNS based blacklists should or should not be consulted for spam blocking. It presently supports the MAPS Real-Time-Black-Hole (RBL), the MAPS Dialup-Users-List (DUL), the MAPS Relay-Spam-Stopper (RSS), and the Open Relay Behavior-modification System (ORBS). It is compatible with FEATURE(virusertable), FEATURE(access_db), and FEATURE(blacklist_recipients). This package may not be compatible with versions of sendmail earlier that 3.9.3. The standard Sendmail 3.9.3 FEATURE(rbl) adds these tests to ruleset check_relay, blocking traffic before the SMTP dialog even begins. This package places the tests in ruleset Local_check_rcpt so that decisions can be made about which test(s) to run (if any) based on the recipient address. This also allows sendmail to include the recipient address when logging rejected mail. Also, unlike FEATURE(rbl) mail is rejected with the transient error 451 as per RFC2505 (see http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2505.txt) which allows some hope of eventually delivering mail which was temporarily blocked undesireably. The tests to be run are declared in /etc/mail/blacklists. This file is a standard hash database. After installing it, and after editing it, you must rebuild it with the commaind makemap hash blacklists blacklists while in it's directory. The right-hand-side (RHS) of /etc/mail/blacklists is either a complete address such as [EMAIL PROTECTED], a domain such as @dom.ain, a username such as user@, or the text :DEFAULT:. Note that all valid entries in the RHS (except :DEFAULT:) contain an @ sign. The Left-Hand-Side (LHS) contains a colon delimited and bounded list of the tests to be run such as :RBL:DUL:RSS:ORBS: EXAMPLE: :DEFAULT: :RBL:DUL:RSS: [EMAIL PROTECTED] : friend@:RBL:DUL:RSS:ORBS: @bigbiz.com:DUL: [EMAIL PROTECTED] : The list is searched first for a complete address, then for a username (global to all domains), and then for a domain name. The search stops on the first match. Tests are performed in the order RBL, DUL, RSS, then ORBS; without regard to the order of appearance in the blacklists file. In this example mail to [EMAIL PROTECTED] and to [EMAIL PROTECTED] get no filtering at all; all other addresses at bigbiz.com get only the DUL list, except that user friend will get the full treatment at any domain, even [EMAIL PROTECTED]. Everyone else gets the the :DEFAULT: settings of :RBL:DUL:RSS: You will need to edit your .mc master configuration file to include HACK(blacklists_by_rcpt) and run sendmailconfig again. RIGHTS -- This is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Re: So, what's up with the XFree86 4.0 .debs?
Hi Branden,
On Sun, Mar 12, 2000 at 10:32:06PM -0500, Branden Robinson wrote:
Hmm. I am using the following patch, which I got from slashdot of all
places:
--- xc/config/makedepend/cppsetup.c.origSun Mar 12 15:47:41 2000
+++ xc/config/makedepend/cppsetup.c Sun Mar 12 15:48:21 2000
@@ -188,7 +188,7 @@
return 0;
do {
var = (*s)-s_value;
- if (!isvarfirstletter(*var))
+ if (!isvarfirstletter(*var) || !strcmp((*s)-s_name, var))
break;
s = lookup_variable (ip, var, strlen(var));
} while (s);
It did seem to fix the problem. If someone who understands cppsetup.c
could comment and it turns out that this patch doesn't in fact disable some
feature of cppsetup, I will submit this patch to XFree86.
This is the code to evaluate the value of a macro. E.g. if you write
#define FOO BAR
#define BAR BAZ
it will lookup FOO and get BAR, then lookup BAR and get BAZ which
is not a macro.
Now ANSI-C defines that you can say
#define FOO FOO
and the preprocessor will handle this without looping. The old code lookup
up FOO, found FOO as value, looked up FOO ad nauseum. The patch just
checks if the macro is defined as itself and breaks the loop in that case.
I think this patch is perfectly valid and should go upstream.
HTH
Torsten
--
Torsten Landschoff [EMAIL PROTECTED] [EMAIL PROTECTED]
Debian Developer and Quality Assurance Committee Member
Re: TeTeX bugs
-BEGIN PGP SIGNED MESSAGE-
Denis Barbier writes:
On 15 Mar 2000, Christoph Martin wrote:
Denis Barbier [EMAIL PROTECTED] writes:
On Tue, Mar 14, 2000 at 01:11:03PM +0100, Stephane Bortzmeyer wrote:
Since the teTeX in slink works fine and the one is potato is broken
(a bug in babel which prevents compilation of *every* document in
French), I prefer the old stuff.
I've provided information to close #42698, here it is again
PS: I'm not a Debian developer.
--- tetex-src-1.0.orig/latex/base/ltoutenc.dtx Thu Mar 4 09:51:25 1999
+++ tetex-src-1.0/latex/base/ltoutenc.dtx Wed Mar 15 00:02:29 2000
@@ -800,6 +800,7 @@
%\begin{macrocode}
[EMAIL PROTECTED]
\accent#1 [EMAIL PROTECTED]
[EMAIL PROTECTED]
%\end{macrocode}
% \end{macro}
%
I will bring this patch in in the next day. I was busy fixing some
other packages.
Hi Christoph,
i do not know whether teTeX is built from tetex-src (i guess it is not
in fact), so you probably have to patch latex.ltx. But tetex-src should
be fixed too.
You are right.
This patch is the one incorporated into new releases of LaTeX by the
LaTeX Team.
I would like to include the new latex version into potato. Thomas
Esser has even included in a minor upgrade to tetex. Normally his work
is very good. But I am not shure if it is a good idea to bring all
this into potato now.
We could have a try and a lot of testing.
What do the other Debian tetex maintainers think of that.
What other bugs are important enough to be fixed for potato.
Christoph
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 5.0i for non-commercial use
Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface
Charset: noconv
iQEVAwUBONCm5W4/9k35XC9tAQGKMggAvAVwcfusJO6WheI64tQ9XAfLIXmXNg0B
iRI3AKvCJhHJjjZtNqBCv1Mu732bSByDMPrxcrBh6LhhxITQXhbb1DxlJEKeE7L8
TITGX8jgyXjnGF4dEbop6eSHRgE3HFthBMo/P3Tf7h+ZeNu+BXGLWdL6NCgxLqWE
S0wogrCmPj3YiaFr5S2dBdtmhHpMEslCmEv+h38wYvibs3YtEls97w8FQIKg1fN5
+R55qbauggXgTm6sHzNNREemn2R9qgmdwBH1W2UCLhiHhgBlGRxyVqn8G/egh/u3
EfKNTB6C3DfbqJ2tFF+yKFfw51R9T0YwpUlXck7ds89qpt4KiQGKqw==
=NN2y
-END PGP SIGNATURE-
Re: realplayer installer and frozen
On Wed, Mar 15, 2000 at 01:26:17PM -0700, Bob Nielsen wrote: I tried the woody installer on a potato system. It installed realplayer, but it doesn't seem to work. No messages or core dump--nothing happens. I also tried installing the tarball and installing the .deb created by running alien on the .rpm, with the same results, so it would appear that the installer is not the problem. I had the same problem. Installing libstdc++2.9-glibc2.1 fixed it on my system. You also have to make sure the REALPLAYER_HOME environment variable is set correctly. - Dave -- +--+---+ | David Webb | The believer is happy; the doubter is wise. | | [EMAIL PROTECTED] | - Hungarian Proverb | +--+---+
Re: realplayer installer and frozen
David Webb wrote: I had the same problem. Installing libstdc++2.9-glibc2.1 fixed it on my system. I cannot reproduce this. Works fine for me without that library installed. You also have to make sure the REALPLAYER_HOME environment variable is set correctly. Nor can I reproduce this. -- see shy jo
Re: Permission policy
On Thu, Mar 16, 2000 at 01:43:22AM +0100, Bernd Eckenfels wrote: On Wed, Mar 15, 2000 at 01:12:49PM +0100, Volker Ossenkopf wrote: ... BTW: there is a idea for settig groups for console access to devices like cdrom, floppy, sound, mic, cam... so each user who logs into the sonsole will get added to that groups, then your program does not need to be sgid anyrthing, which is bad anyway since everybody even on networked terminal could start it. I am by setting all linux installations this way: I add this line to /etc/security/group.conf: login;tty?|tty??!ttyp*;*;Al-2400;floppy, audio and configure pam to use it. -- --- | Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Re: Permission policy
Radovan Garabik [EMAIL PROTECTED] writes: On Thu, Mar 16, 2000 at 01:43:22AM +0100, Bernd Eckenfels wrote: BTW: there is a idea for settig groups for console access to devices like cdrom, floppy, sound, mic, cam... so each user who logs into the sonsole will get added to that groups, then your program does not need to be sgid anyrthing, which is bad anyway since everybody even on networked terminal could start it. I am by setting all linux installations this way: I add this line to /etc/security/group.conf: login;tty?|tty??!ttyp*;*;Al-2400;floppy, audio and configure pam to use it. This has a trivial attack. Once someone logs in to the console, he is a member of the floppy group, therefore he can do the following: cp /bin/sh ~ chgrp floppy ~/sh chmod g+s ~/sh And later when he logs in through the network, he simply runs ~/sh to regain access to the floppy group. (of course, this attack can be prevented using mount options to disable setgid executables on all filesystems where users have write access) - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: realplayer installer and frozen
On Thu, Mar 16, 2000 at 01:36:49AM -0800, Joey Hess wrote: David Webb wrote: I had the same problem. Installing libstdc++2.9-glibc2.1 fixed it on my system. I cannot reproduce this. Works fine for me without that library installed. You also have to make sure the REALPLAYER_HOME environment variable is set correctly. Nor can I reproduce this. I've played around with my system some more. Here's what I tried: 1. Removed libstdc++2.9-glibc2.1 - realplayer kept working 2. Changed REALPLAYER_HOME - realplayer stopped working 3. Corrected REALPLAYER_HOME - realplayer started working again 4. Unset REALPLAYER_HOME - realplayer kept working In short, REALPLAYER_HOME was the sole cause on my system and unsetting it completely seems to be the best fix. - Dave -- +--+---+ | David Webb | The believer is happy; the doubter is wise. | | [EMAIL PROTECTED] | - Hungarian Proverb | +--+---+
[joey@infodrom.north.de (Martin Schulze)] Re: Re: kernel building
This is *still* happening. Will someone please do something about it? root isn't even mentioned in the headers. I get this error when I mail with one of my complex cookie'd from lines, and don't when I simplify it. Why is this feature even in place? Does it add any kind of value to stop root users posting, even if it doesn't kill innocent mail in the process? m. ---BeginMessage--- You should not send mail from your »root« account. The »root« is a login that bypasses all security protection on your system. The root account should only be used to perform system administration, and only used for as short a time as possible. You should *not* use the »root« account for daily use or as your personal login. Why not? Well, one reason to avoid using root's privileges is that it is very easy to do irreparable damage as root. Another reason is that you might be tricked into running a Trojan-horse program -- that is a program that takes advantage of your super-user powers to compromise the security of your system behind your back. Any good book on Unix system administration will cover this topic in more detail -- consider reading one if it is new to you. Please use adduser and create a regular user account for you and send mail from that account. If you haven't sent from a root account there is a chance that our list server has inserted a line like Sender: [EMAIL PROTECTED] which confuses the lists software. In that case please wait few hours and resend. From [EMAIL PROTECTED] Thu Mar 16 11:33:07 2000 Return-Path: [EMAIL PROTECTED] Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2) from murphy.debian.org by finlandia.Infodrom.North.DE via smail with smtp id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Thu, 16 Mar 2000 11:33:04 +0100 (CET) Received: from ([216.234.231.6]) by teergrube (0 sec delayed, relaying denied) Received: (qmail 13818 invoked by uid 847); 16 Mar 2000 10:32:31 - Received: (qmail 13781 invoked by uid 38); 16 Mar 2000 10:32:31 - Received: (qmail 13774 invoked by uid 38); 16 Mar 2000 10:32:30 - Date: 16 Mar 2000 10:32:30 - X-From_:[EMAIL PROTECTED] Thu Mar 16 04:32:30 2000 X-Envelope-Sender: [EMAIL PROTECTED] Received: (qmail 13752 invoked from network); 16 Mar 2000 10:32:26 - Received: from mooneye.ucc.gu.uwa.edu.au (HELO ucc.gu.uwa.edu.au) (130.95.13.9) by murphy.debian.org with SMTP; 16 Mar 2000 10:32:26 - Received: from mussel.ucc.gu.uwa.edu.au ([EMAIL PROTECTED] [130.95.13.18]) by ucc.gu.uwa.edu.au (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id SAA17126; Thu, 16 Mar 2000 18:32:22 +0800 Received: (from [EMAIL PROTECTED]) by mussel.ucc.gu.uwa.edu.au (8.9.3/8.9.3/Debian 8.9.3-6) id SAA01423; Thu, 16 Mar 2000 18:32:21 +0800 X-Authentication-Warning: mussel.ucc.gu.uwa.edu.au: dichro set sender to [EMAIL PROTECTED] using -f Sender: [EMAIL PROTECTED] From: Mikolaj J. Habryn [EMAIL PROTECTED] To: DI Peter Burgstaller [EMAIL PROTECTED] Cc: debian-alpha@lists.debian.org Subject: Re: kernel building References: [EMAIL PROTECTED] Old-Date: 16 Mar 2000 21:32:21 +1100 In-Reply-To: DI Peter Burgstaller's message of Wed, 15 Mar 2000 15:23:17 +0100 (MET) Message-ID: [EMAIL PROTECTED] Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Diagnostic: Mail coming from a daemon, ignored X-Envelope-To: debian-alpha Delivered-To: [EMAIL PROTECTED] X-Loop: [EMAIL PROTECTED] Regards, SPI and Debian listmaster -- Debian GNU/Linux - The Universal Operating System [EMAIL PROTECTED] [EMAIL PROTECTED] ---End Message---
Re: Apt-Problem
On Wed, 15 Mar 2000, paul wrote: I had the same problem (and same output) when doing apt-get upgrade last night. I used apt-get clean and apt-get install man-db before trying apt-get upgrade again. The problem went away, so I thought it had been a hardware problem on my end, but I guess I was wrong. Anyone know what happened? Using the third mirror helped for me. May be your mirror was OK while your second trial. Kind regards Andreas.
Re: Embedded(/RT) Debian? Embeddian GNU/Linux?
Hi, ive been hanging around boot-floppies for a while, and am interested in minimum debian systems. I think what your trying to do could well cover a lot of ground boot-floppies tries to cover, if your not familiar with how the debian boot floppies work, you may get a bit out of it, i love the mklibs.sh script to minimise libraries. I think the way boot floppies current work leaves a fair way for improvements, and after potato stabilises i believe boot-floppies will become much more modular and hopefully closer to what you are looking for. I think a worthy challenge for debian is to get smaller as well as bigger. I was thinking today it would be great if there was some way to create a split debian package, like a normal package could be split into the necessary binaries, and config files in one package, and docs etc in a seperate package, this way you could install one part, then later install the other part and have it recognise the whole normal deb installed Im trying to get into frame buffers at the moment Ill checkout what youve got so far, maybe i can help you out... or learn something. Thanks Glenn McGrath Andreas Schuldei wrote: My first mail seems to got lost. excuse me if this turns up twice. In fact I am working on an minimal debian (-based) system. I am building an embedded system which tries to be as small as possible. I started with the linux router project, took some parts from the bootfloppys and wrote some Makefiles to take essential Binaries etc out of my running potato. Right now (since half an hour) I have a 2.2.14 kernel, glibc-2.1.3, busybox plus some other stuff in 1382 Kbytes (unpacked) in the ramdisk. (this does not count the kernel, of cause. It is booted from floppy, where it takes 905 kbyte alltogether. It should be easyly adaptable and is modular by design (like lrp is). Anyone intersted should get back to me. I would be glad to cooperate. It is gpl, of cause. I am not on this list, so please reply to me privatly, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mailcap stress (was: Potato fresh install)
On Mon 13 Mar 2000, Santiago Vila wrote: On Mon, 13 Mar 2000, Paul Slootman wrote: Also, when upgrading mime-support, it always offers to replace the conffile /etc/mailcap, which is NEVER a smart thing to do. Maybe /etc/mailcap should be one of the base files, and not part of mime-support? This is Bug #34294, which I reported more than a year ago and it has not been fixed yet. Glad to know I'm not the only one to think this is a bug. I have tried to convince the maintainer (Brian White) several times about the need to change this, without much success. He says /etc/mailcap almost never changes and he does not see the need to modify the way /etc/mailcap is handled. That's strange, as I've been asked whether to replace it on numerous occasions during upgrades to the current potato (every month or so). Maybe the conffile mechanism doesn't always work properly? Or was I confused... (it's been known to happen :-) Ans it still doesn't address the situation where packages are being configured but mime-support isn't yet. If this is not a bug in mime-support, then lots of packages would be violating policy because they modify /etc/printcap (a configuration file You mean /etc/mailcap I hope of another package) every time they register their MIME viewers... Well, if they do it with update-mime it should be OK (unless mime-support has been installed but not yet configured, that is). Time to make a policy proposal? It would be something like: Do not ever use the conffile mechanism to initialize a database. Sounds reasonable. Anything that gets updated via an update-foo thingie shouldn't be a conffile, as it is NEVER useful to upgrade to the version in the newest package on an installed system. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
Re: Danger, Branden Robinson! Danger!
On Mon 13 Mar 2000, Stephen Zander wrote: Joseph == Joseph Carter [EMAIL PROTECTED] writes: Joseph Only 6000? We must be getting lazy. 6000 is way too Joseph easy. Better try for 8000. Now one ever thought the Dow would break 10k: took 'em 10yrs to get from 3k to there. I'm sure we can do it in 2yrs (which is about when woody will be out, right? :)) I still think we should be honest and report the number of source packages, not binary packages; e.g. I find the following all parts of just one package: glibc-doc i18ndata libc6 libc6-dev locales It _is_ useful to be able to install these separate parts, of course... Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
Re: [joey@infodrom.north.de (Martin Schulze)] Re: Re: kernel building
On Thu, Mar 16, 2000 at 09:47:41PM +1100, Mikolaj J. Habryn wrote: root isn't even mentioned in the headers. This is the only occurrence: Received: from mussel.ucc.gu.uwa.edu.au ([EMAIL PROTECTED] [130.95.13.18]) Why is this feature even in place? Isn't it obvious? :) You should not send mail from your »root« account. The »root« is a You should *not* use the »root« account for daily use or as your What are these character around root? They don't seem like quotes to me... If you haven't sent from a root account there is a chance that our list server has inserted a line like Sender: [EMAIL PROTECTED] which confuses the lists software. In that case please wait few hours and resend. Maybe this is the problem? Why would this happen, anyway? -- enJoy -*/\*- don't even try to pronounce my first name
Re: [joey@infodrom.north.de (Martin Schulze)] Re: Re: kernel building
JR == Josip Rodin [EMAIL PROTECTED] writes: JR On Thu, Mar 16, 2000 at 09:47:41PM +1100, Mikolaj J. Habryn JR wrote: If you haven't sent from a root account there is a chance that our list server has inserted a line like Sender: [EMAIL PROTECTED] which confuses the lists software. In that case please wait few hours and resend. JR Maybe this is the problem? Why would this happen, anyway? That would be a valid idea, were it not for the fact that it *consistently* bounces mail with a from address of [EMAIL PROTECTED], and accepts [EMAIL PROTECTED]. Consistently. Within timespans of seconds, minutes, hours, days, weeks, or months. m.
Two maintainer entrys in bug reports by maintainer
Hello cited from Debian bug reports by maintainer This page lists the package maintainers against whose packages there are outstanding, fowarded or recently-closed bug reports. A maintainer -- by the way here is a typo. ... * Andreas Tille [EMAIL PROTECTED] (1 outstanding Bug) * Andreas Tille [EMAIL PROTECTED] (1 outstanding Bug) ... The e-mail addresses are both valid, but it's the same maintainer (at least I get the mail from both :-) ). It is my task to use always the same address or is it a bug in the bug system? Kind regards Andreas.
Re: Two maintainer entrys in bug reports by maintainer
On Thu, Mar 16, 2000 at 01:12:21PM +0100, Andreas Tille wrote: * Andreas Tille [EMAIL PROTECTED] (1 outstanding Bug) * Andreas Tille [EMAIL PROTECTED] (1 outstanding Bug) The e-mail addresses are both valid, but it's the same maintainer (at least I get the mail from both :-) ). It is my task to use always the same address or is it a bug in the bug system? Neither. Do as you wish :) Personally I prefer using a unique Maintainer: field in all of my packages. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Danger, Branden Robinson! Danger!
On Thu, 16 Mar 2000, Paul Slootman wrote: On Mon 13 Mar 2000, Stephen Zander wrote: Joseph == Joseph Carter [EMAIL PROTECTED] writes: Joseph Only 6000? We must be getting lazy. 6000 is way too Joseph easy. Better try for 8000. Now one ever thought the Dow would break 10k: took 'em 10yrs to get from 3k to there. I'm sure we can do it in 2yrs (which is about when woody will be out, right? :)) I still think we should be honest and report the number of source packages, not binary packages; e.g. I find the following all parts of We can report both... Overrides covers the binary packages and Sorces covers the source packages, right? just one package: glibc-doc i18ndata libc6 libc6-dev locales It _is_ useful to be able to install these separate parts, of course... I've been working on a selective source building script, so I know just what you mean. Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
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] . ^ . .
Re: pgp-gpg keys, uploaded package not dinstalled?
On Tue, Mar 14, 2000 at 10:55:31AM +0200, joost witteveen wrote: Hi, Until recently I only had a PGP key, and as suggested by /usr/share/doc/debian-keyring/README.gz, I've now generated a GPG one, signed it with my PGP key, and submitted it to [EMAIL PROTECTED] A couple of hours later I uploaded a package (fakeroot_0.4.4-5) signed with my new GPG keys. You can't use the new key until you get an ack that it's been accepted into the keyring. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Two maintainer entrys in bug reports by maintainer
On Thu, 16 Mar 2000, Josip Rodin wrote: It is my task to use always the same address or is it a bug in the bug system? Neither. Do as you wish :) :) So far the funny side of this aspect, but together with the fact that there are problems in sending PM to the maintainer (see a running thread on this list) it might lead to the situation that a developer never notices a bug. I for myself check bugs against my packages using a script which calls lynx with a certain address (not with two or more). Personally I prefer using a unique Maintainer: field in all of my packages. Perfectly all right and believe it or not it was my intention just to stick on a single e-mail address (simply [EMAIL PROTECTED]) for this purpose, because I had trouble when my other address was changing and so I decided to use the Debian address for all Debian purpose). While there are some unchanged packages this is a problem obviousely. Should I file a bug report against the bug system? (Filing a bug-report against myself is hard in this case because I can't fix it ;-).) Kind regards Andreas.
Re: A progressive distribution
On Wed, 15 Mar 2000, Bdale Garbee wrote: In article [EMAIL PROTECTED] you wrote: After reading this nice diskussion with all it's aspects, I want to complete the mess and suggest a distribution called e.g. progressive beetween stable(frozen) and unstable. I gather you haven't read the discussion of package pools in the archive? Not all of it, and after reading some people not having the same option of that I wanted to suggest an additional idea, that is more simple (both in the sence of less advantages and less work). First things first. Let's get potato released, As I wrote, nothing can be changed before. Hochachtungsvoll, Bernhard R. Link
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
xfs question
Now that xfs per default does not listen on a tcp port anymore, could anyone please tell me how to configure x (i.e. XF86Config) to use unix domain sockets instead? Thanks. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Re: xfs question
16.03.2000 pisze Michael Meskes ([EMAIL PROTECTED]): Now that xfs per default does not listen on a tcp port anymore, could anyone please tell me how to configure x (i.e. XF86Config) to use unix domain sockets instead? e.g. by setting the FontPath to `unix/:-1' regards, Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] For life is but a dream whose shapes return Some frequently, some seldom, some by night...
Re: ITP: mpg123-el
Nils Jeppe [EMAIL PROTECTED] writes: On Sat, 4 Mar 2000, Andrew D Lenharth wrote: I'm in the midst of doing this myself. There are even two impeding pieces of consumer electronics about to hit the market which will play an ISO-9660 CDROM with mp3's on it. I did this. DO you know how cheep a CDROM tower is? Mine is populated with 4x drives which is plenty I just keep all my mp3-encodedd CD's on harddisk. It's almost 6GB, but hd's are really cheap these days and it means I never, ever have to swap cd's anymore. Plus I get some additional space on my shelves since I could move all my cd's into the basement :-) I keep them all on hard disk; I have two niftp 27 GB disks on my machine, so that has plenty of room for all my music. The reason I want the consumer electronics I mentioned is for *portable* use. I'm going to burn all these mp3s back onto (way fewer) CD-ROMs and I can cart them around with me easily. The consumer electronics are portable Discman like things, which play either regular audio CDs or CD-ROMs containing mp3s. Thomas
Re: realplayer installer and frozen
I checked and REALPLAYER_HOME was set to the G2 directory (from an old manual installation). I changed it to /usr/lib/RealPlayer7 and realplayer started working. Then I deleted REALPLAYER_HOME environmental variable altogether and it still worked. This would indicate that it isn't required, but if it exists, it must point to the correct location. Thanks. On Thu, Mar 16, 2000 at 04:38:46AM -0600, David Webb wrote: On Thu, Mar 16, 2000 at 01:36:49AM -0800, Joey Hess wrote: David Webb wrote: I had the same problem. Installing libstdc++2.9-glibc2.1 fixed it on my system. I cannot reproduce this. Works fine for me without that library installed. You also have to make sure the REALPLAYER_HOME environment variable is set correctly. Nor can I reproduce this. I've played around with my system some more. Here's what I tried: 1. Removed libstdc++2.9-glibc2.1 - realplayer kept working 2. Changed REALPLAYER_HOME - realplayer stopped working 3. Corrected REALPLAYER_HOME - realplayer started working again 4. Unset REALPLAYER_HOME - realplayer kept working In short, REALPLAYER_HOME was the sole cause on my system and unsetting it completely seems to be the best fix. -- Bob Nielsen, N7XY (RN2)[EMAIL PROTECTED] Tucson, AZ DM42nh QRP-L #1985 SOC #77http://www.primenet.com/~nielsen
Re: ITP: dvipdfm - A DVI to PDF translator
Jason Gunthorpe [EMAIL PROTECTED] wrote: Right now there are 4 ways to produce PDF's (AFAIK) [...] That said, my current favorite method is to use gs 6.0's ps2pdf, my documents all have eps figures! There are other problems however - ... Another problem is that the times font (or any native postscript font for that matter!) does seem to support ligatures! This problem is not limited to just PDF however, postscript files output from dvips and viewed in ghostscript show pound signs for 'fi' and other ligatures are similarly wrong. Converting that postscript to PDF naturally propagates this error : The ligatures are supported, but dvips switches the characters in the font around. This can be fixed by turning off the G option in the /etc/texmf/dvips/config.pdf file. % Character shifting. You want to do this using the BlueSky/AMS/YY fonts. % It remaps certain ``control character'' positions to an another range % where these characters are repeated. This option is compatible (and will % have no effect on) standard Adobe or other Type 1 fonts that do not use % to problematic positions. It is INCOMPATIBLE with any fonts that use % these control character positions but that DO NOT repeat them in the % exact same way as the BlueSky/... fonts. I don't know of any, but I % haven't even tested this with BaKoMa fonts. %G - Brian
RE: Bug#58174
I don't think bugs like this should slow down our release cycle at all. IMO this bug should be downgraded to normal. Comments anyone? sounds fair, and little items (sorry) like metamail should not hold us up.
testers / sponsor wanted
hi i just packaged my 'perlbeat' (http://tools.desire.ch/perlbeat) and am now looking for people to test it and for a sponsor. thanks stefan
Less interactive upgrades.
One of the minor annoyances in Debian is the prompting that goes on during package upgrades. It's not the fact that the prompting occurs... I like the fact that it doesn't silently redo the system configuration... but rather the fact that it occurs thoughout the upgrade process. Debconf helps matters. It allows for configuration questions to be asked the start of the installation process, which could then proceed automatically. At least, that's the theory. The problem I have is that dpkg keeps on prompting me as to the disposition of config files I have changed. Don't get me wrong, I like the fact that it asks me what to do... I just wish it would do it at the start, and proceed cleanly through the upgrade without further prompting. Since it would be unkind of me to subject the list to the above without proposing a solution, here's my answer to this: - When apt runs to upgrade packages, it will call a new program (which I plan to write) in the same way that it calls dpkg-preconfigure. TNP would scan the list of upgraded packages, looking for config files. (This scan could go rather fast, as it only looks at config files, rather than having to unpack the whole thing.) Where it finds changed config files (using the same rules as dpkg) it will add them to a list. The list will then be presented to the user, probably sorted by package. Each of the changed config files will be there, and the user will be able to select which ones he wishes to replace. (Other options, like show a diff, edit file, and background TNP will be given to allow the user to make an informed choice.) Once the user is through with picking which config files he wants to replace, the program will write the information to a well-known file and terminate. - The well known file will contain lines that look something like this: /etc/config/file0 package keep b20482b9ffb207ba5448cedee746c690 The first entry is the config filename, the second is the name of the package it's associated with. The third is whether the config file is to be kept (keep) or replaced (replace). I don't think it will be used directly by dpkg, but it would come in handy in the case of cluster upgrades, where a script might run over the file and replace all the md5sums on the files marked keep. But in normal use it'll be ignored. The last field is the md5sum of the version of the file that will be used. I'll get back to that in a second. - Once the file is being appropriately created, dpkg will be modified to optionally take as an argument to an option the name of the well known file. It will read the information into a hash at the start. Then when a configfile prompt would be displayed, the filename and package are looked up to get a md5. If the md5 matches that of the old conffile, it proceeds the same as if one said 'N' to the prompt. If the md5 matches the new file, it's the same as answering 'Y' to the prompt. If the md5 is different from both, or the md5 can't be looked up, the normal prompt will be displayed. (This covers the case of a config file changing between TNP and dpkg runs.) This, along with debconf and a program like debecho (which doesn't exist, but if it did would allow logging of informational messages to a file) would allow for unattended installations and upgrades, after the initial QA session. I think that would be a real good thing to have, especially if we don't lose flexability when it happens. I'd like to know what people think about this... I'm considering starting coding on this during spring break next week, and it'll use a bit of infrastructure in common with ddiff. I'd also like to know if there's a preferred textui toolkit for use during installs/upgrades, or if I should just roll my own. I'm interested in hearing comments, suggestions, flames, summer job offers, package name ideas, etc... I would like to get going on this by next week, however. Oh, and for those who are wondering: I've decided to work on this rather than bettering ddiff integration because this is something that can work stand-alone to better the user experience, while ddiff will require new or different archives to achive maximum usefulness. (Ie, the diffs have to be stored somewhere.) I'll be returning to ddiff once I finish this, which should go rather quickly, and I'll probably do an ITP for ddiff before them. (I have the packaging essentially done, but I want to wait to hear back about some bug reports before a sponsored upload is done.) Lastly, is there a more appropriate list than debian-devel for announcing projects like this? -- Tom Rothamel - http://onegeek.org/~tom/ --- Using GNU/Linux Writing from home, just outside Northport, NY. The Moon is Waxing Gibbous (85% of Full).
Re: Less interactive upgrades.
On Thu, Mar 16, 2000 at 02:18:25PM -0500, Tom Rothamel wrote:
One of the minor annoyances in Debian is the prompting that goes on
during package upgrades. It's not the fact that the prompting
occurs... I like the fact that it doesn't silently redo the system
configuration... but rather the fact that it occurs thoughout the
upgrade process.
Debconf helps matters. It allows for configuration questions to be
asked the start of the installation process, which could then proceed
automatically. At least, that's the theory.
The problem I have is that dpkg keeps on prompting me as to the
disposition of config files I have changed. Don't get me wrong, I like
the fact that it asks me what to do... I just wish it would do it at
the start, and proceed cleanly through the upgrade without further
prompting.
Since it would be unkind of me to subject the list to the above
without proposing a solution, here's my answer to this:
In /etc/apt/sources.list add these lines:
DPkg
{
Options {--force-confdef;}
}
This will make dpkg always choose the default option to the conffile
questions. If there is no default, it will still prompt (not likely), so
you can also add --force-confold, so that if there is no default, it will
choose to keep the old conffile.
Problem solved :)
--
---===-=-==-=---==-=--
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] '
`---=--===-=-=-=-===-==---=--=---'
Re: Less interactive upgrades.
sounds nice. there's another thing about apt-get which IMHO should be changed (if this option already exists i'm sorry for being too lame for the docs): my connection often suffers time-outs and i afterwards have to do a --fix-missing. i think it would be nice if you could tell apt-get to try again on timeouts. regards stefan On Thu, Mar 16, 2000 at 02:18:25PM -0500, Tom Rothamel wrote: One of the minor annoyances in Debian is the prompting that goes on during package upgrades. It's not the fact that the prompting occurs... I like the fact that it doesn't silently redo the system configuration... but rather the fact that it occurs thoughout the upgrade process. Debconf helps matters. It allows for configuration questions to be asked the start of the installation process, which could then proceed automatically. At least, that's the theory. The problem I have is that dpkg keeps on prompting me as to the disposition of config files I have changed. Don't get me wrong, I like the fact that it asks me what to do... I just wish it would do it at the start, and proceed cleanly through the upgrade without further prompting. Since it would be unkind of me to subject the list to the above without proposing a solution, here's my answer to this: - When apt runs to upgrade packages, it will call a new program (which I plan to write) in the same way that it calls dpkg-preconfigure. TNP would scan the list of upgraded packages, looking for config files. (This scan could go rather fast, as it only looks at config files, rather than having to unpack the whole thing.) Where it finds changed config files (using the same rules as dpkg) it will add them to a list. The list will then be presented to the user, probably sorted by package. Each of the changed config files will be there, and the user will be able to select which ones he wishes to replace. (Other options, like show a diff, edit file, and background TNP will be given to allow the user to make an informed choice.) Once the user is through with picking which config files he wants to replace, the program will write the information to a well-known file and terminate. - The well known file will contain lines that look something like this: /etc/config/file0 package keep b20482b9ffb207ba5448cedee746c690 The first entry is the config filename, the second is the name of the package it's associated with. The third is whether the config file is to be kept (keep) or replaced (replace). I don't think it will be used directly by dpkg, but it would come in handy in the case of cluster upgrades, where a script might run over the file and replace all the md5sums on the files marked keep. But in normal use it'll be ignored. The last field is the md5sum of the version of the file that will be used. I'll get back to that in a second. - Once the file is being appropriately created, dpkg will be modified to optionally take as an argument to an option the name of the well known file. It will read the information into a hash at the start. Then when a configfile prompt would be displayed, the filename and package are looked up to get a md5. If the md5 matches that of the old conffile, it proceeds the same as if one said 'N' to the prompt. If the md5 matches the new file, it's the same as answering 'Y' to the prompt. If the md5 is different from both, or the md5 can't be looked up, the normal prompt will be displayed. (This covers the case of a config file changing between TNP and dpkg runs.) This, along with debconf and a program like debecho (which doesn't exist, but if it did would allow logging of informational messages to a file) would allow for unattended installations and upgrades, after the initial QA session. I think that would be a real good thing to have, especially if we don't lose flexability when it happens. I'd like to know what people think about this... I'm considering starting coding on this during spring break next week, and it'll use a bit of infrastructure in common with ddiff. I'd also like to know if there's a preferred textui toolkit for use during installs/upgrades, or if I should just roll my own. I'm interested in hearing comments, suggestions, flames, summer job offers, package name ideas, etc... I would like to get going on this by next week, however. Oh, and for those who are wondering: I've decided to work on this rather than bettering ddiff integration because this is something that can work stand-alone to better the user experience, while ddiff will require new or different archives to achive maximum usefulness. (Ie, the diffs have to be stored somewhere.) I'll be returning to ddiff once I finish this, which should go rather quickly, and I'll probably do an ITP for ddiff before them. (I have the packaging essentially done, but I want to wait to hear back about some bug reports
Re: Less interactive upgrades.
On Thu, Mar 16, 2000 at 02:25:10PM -0500, Ben Collins wrote:
In /etc/apt/sources.list add these lines:
DPkg
{
Options {--force-confdef;}
}
This will make dpkg always choose the default option to the conffile
questions. If there is no default, it will still prompt (not likely), so
you can also add --force-confold, so that if there is no default, it will
choose to keep the old conffile.
Problem solved :)
Yes, but a different problem then the one that I was aiming to
solve. I actually like the fact that dpkg asks those questions, and
that I can override it's defaults... I just want to have all those
questions asked at once at the beginning of the upgrade session,
rather than spread out over the entire unpack process.
--
Tom Rothamel - http://onegeek.org/~tom/ --- Using GNU/Linux
Writing from home, just outside Northport, NY.
The Moon is Waxing Gibbous (86% of Full).
New version of xserver-svga gives poorer display on laptop
I have a laptop that uses the S3 Virge/MX video chip. I had this working well with the xserver-svga from slink. I recently upgraded to 3.3.6-3 and found that the quality of the display became significantly worse. I have not seen any reference to such a problem anywhere I have looked. Since I don't have any idea how the xserver works, I don't have a clue about the cause of the problem, let alone how to solve it. The nature of the problem is this: There is a tendency for the image to be smeared to the right. This is particularly noticeable with the mouse cursor, which trails a small comet around, about 1.5 inches long. In an xterm window (black foreground, white background, all the characters tend to smear to the right. This effect is fairly permanent, but not so permanent as the comet from the mouse cursor. Sometimes the screen is almost clear, but at other times it is so blurred as to be nearly unreadable. This is at its worst in xterms; an xeyes shows ragged edges to the black parts, but no smearing. The root window again shows ragged edges (on a photo of Mars) and some abnormal areas of colour (some bits of shading with bright dots where I used to see a more gradual colour change). I have tried all the documented options to the server and find that none of them make any difference. Can you suggest anything else to try, apart from reverting to the slink version? Hardware: generic laptop; FCC approval: LMDNX2000-S-01 (this would be common whatever the badge) XF86Config (extract): Section Monitor Identifier Primary Monitor VendorName Unknown ModelName Unknown HorizSync 31.5-57.0 VertRefresh 50-90 Modeline 1024x768 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync EndSection Section Device Identifier Primary Card VendorName Unknown BoardName S3 ViRGE/MX (generic) chipset s3_virge VideoRam4096 #Option lcd_center #Set_LCDClk pixel_clock_for_LCD #Option xaa_benchmark Option fifo_conservative Option pci_burst_on Option pci_retry Option hw_cursor Option slow_edodram Option early_ras_precharge EndSection Section Screen Driver Accel Device Primary Card Monitor Primary Monitor DefaultColorDepth 16 SubSection Display Depth8 Modes1024x768 EndSubSection SubSection Display Depth15 Modes1024x768 EndSubSection SubSection Display Depth16 Modes1024x768 EndSubSection SubSection Display Depth24 Modes1024x768 EndSubSection SubSection Display Depth32 Modes1024x768 EndSubSection EndSection Section Screen Driver SVGA Device Primary Card Monitor Primary Monitor DefaultColorDepth 16 SubSection Display Depth8 Modes1024x768 EndSubSection SubSection Display Depth15 Modes1024x768 EndSubSection SubSection Display Depth16 Modes1024x768 EndSubSection SubSection Display Depth24 Modes1024x768 EndSubSection SubSection Display Depth32 Modes1024x768 EndSubSection EndSection Section Screen Driver VGA16 Device Primary Card Monitor Primary Monitor SubSection Display Depth4 Modes1024x768 EndSubSection EndSection Section Screen Driver VGA2 Device Primary Card Monitor Primary Monitor SubSection Display Depth1 Modes1024x768 EndSubSection EndSection Section Screen Driver Mono Device Primary Card Monitor Primary Monitor SubSection Display Depth1 Modes1024x768 EndSubSection EndSection Startup trace: XFree86 Version 3.3.6 / X Window System (protocol Version 11, revision 0, vendor release 6300) Release Date: January 8 2000 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (see http://www.XFree86.Org/FAQ) Operating System: Linux 2.2.13lvm_reiser i686 [ELF] Configured drivers: SVGA: server for SVGA graphics adaptors (Patchlevel 0): NV1, STG2000, RIVA 128, RIVA TNT, RIVA TNT2, RIVA ULTRA TNT2, RIVA VANTA, RIVA ULTRA VANTA, RIVA INTEGRATED, GeForce 256, GeForce DDR, Quadro, ET4000, ET4000W32, ET4000W32i, ET4000W32i_rev_b, ET4000W32i_rev_c, ET4000W32p, ET4000W32p_rev_a, ET4000W32p_rev_b, ET4000W32p_rev_c, ET4000W32p_rev_d, ET6000, ET6100, et3000, pvga1, wd90c00, wd90c10, wd90c30, wd90c24, wd90c31, wd90c33, gvga, r128, ati, sis86c201, sis86c202, sis86c205,
Re: Less interactive upgrades.
- When apt runs to upgrade packages, it will call a new program (which I plan to write) in the same way that it calls dpkg-preconfigure. TNP would scan the list of upgraded packages, I've had the same thought, but not enough time to begin such a project. I wonder if there would be some way to integrate this with the existing debconf system -- if it uses the same interface, etc., end-users will be much happier. Will -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | | http://www.cis.udel.edu/~lowe/ | |PGP Public Key: http://www.cis.udel.edu/~lowe/index.html#pgpkey| --
terminfo
What's wrong with terminfo ? Every time I install new upgrade from potato everything in /etc/terminfo disappears, stuff in /usr/lib/terminfo then has a bunch of links pointing to non-existing info in /etc/terminfo and generally things dont works. i.e. trying to start mc with /usr/lib/terminfo pointing to black hole ends up with segmentation fault. -- [EMAIL PROTECTED] * vaan olkoon teidän puheenne 'on, on' tahi 'ei, ei' * * mitä siihen lisätään on pahasta. Matteus 5:37 *
PC / Internet fax solution
I stopped by your web site and thought you may be interested in our PC/internet based fax service. You can send 1 to 1,000,000 faxes in just minutes to any destination in the US, Canada, and Europe for as low as 7.4 cents per minute. Our user-friendly submission software lets you queue your job on our server within minutes. Why not try the system for FREE. We will be happy to send 100 Faxes on your behalf to your fax list immediately. Simply go to http://www.efaxcast.com/submit.htm
Re: Permission policy
On Mar 16, Michael Stone [EMAIL PROTECTED] wrote: Which is a waste of effort if the user can create a sgid shell. Do you really mount user-writeable directories without the nosuid option? -- ciao, Marco
Re: Another packages wishlist
Carlos Barros wrote: On Fri, Mar 03, 2000 at 08:19:39PM -0200, Aigars Mahinovs wrote: Yann Dirson wrote: [snip] ** RHide: a curses-based IDE for FreePascal, with Borland look-and-feel http://www.tu-chemnitz.de/~sho/rho/rhide/rhide.html [snip] I'm quite new to Debian (4 month) and IANADD, but I'll try to pkg this as I use it in DOS. I'll make a staticly linked binary only package for now, while trying to compile the sources myself (I'll use the binaries made by author for now). I'll need a sponsor for this until I will become a developer myself. This one I think requires a not free library. rhtvision. I was a sponsor of the rhtvision and setedit packages and it has problems due to rhtvision is derivated from tvision and tvision is not free. -- Carlos Barros. o well ... then i withdraw the ITP will wait for better times or, maybe can statically linked binary only package be placed at least in non-free? -- Mail You Later! Aigarius [EMAIL PROTECTED] --- Origin: Not enough hard drive space... please delete windows. PLEASE!!! ---
ITP: swapd -- dynamic swap allocator
Hello all, I have packaged swapd -- demon that checks free memory and if system needs more virtual memory, this demon makes another swapfile and adds it to the system. There is a problem with the kernel, because by default it has MAXSWAPFILES set to 8 which with 4 Mb swap files makes only 32 Mb of swap, which is not enough, so you should recompile your kernel with MAXSWAPFILES in $(kernel_src)/include/linux/swap.h set to 64 (at least). Please test it, you can download it from http://www.zednet.lv/~aigarius/debs.html (pointer page). IANDD jet, so I'll need someone to sponsor me until I am a DD :). -- Mail You Later, Aigars mailto:[EMAIL PROTECTED]
Re: PC / Internet fax solution
Umm, Ok spam on the devel list?? What the hell is the world coming to. Josh
Re: Debian and GNOME, partnership with Helixcode?
On Wed, Mar 15, 2000 at 01:17:56AM -0500, Jaldhar H. Vyas wrote: On Wed, 15 Mar 2000, Fabien Ninoles wrote: However, I'ld like to see a standard meta-info files about the package, which had informations necessary to create a packages, like compilation commands, files (including informations like documentation, binary or data), menu entries (means execution), name, author, copyright file, changelog files, daemon, etc... This will really help to create more package and even an automated tools (just like autoconf) that generate everything needed according to your installation. I'm not sure if it's feasible but I'ld thought that a tool like autoconf wasn't possible too if I doesn't use it so often ;) Didn't someone recently do an ITP for a program that let you create packages in different formats? If it works well it would be cool. That would be me. The package is in Incoming for unstable (it's called epm). It's evidently in use by its creators to distribute commercial packaged software, so one would assume it doesn't suck too bad. It was my thought to enhance it in such a way that it could be used to create official-quality Debian packages (assuming that it isn't already). Then people (like, say, 3Dfx :-) could be persuaded to produce EPM package description files instead of RPMs, and a developer would have the comparatively easy job of just running epm on the files and uploading. At least, that's the theory. At the very least, it should work OK for producing mostly-Debian-friendly packages with little effort, or bootstrapping the creation of official packages.
Re: Permission policy
On Thu, Mar 16, 2000 at 09:39:41PM +0100, Marco d'Itri wrote: On Mar 16, Michael Stone [EMAIL PROTECTED] wrote: Which is a waste of effort if the user can create a sgid shell. Do you really mount user-writeable directories without the nosuid option? 1. Depends on the environment. Unfortunately, nosuid isn't guaranteed to work in all cases (e.g., sperl). 2. The point was that the auto group function isn't a magic bullet and needs to be evaluated in context. In some cases it might make more sense to have a world-writable audio device than to play games with groups. -- Mike Stone pgptDzDGj269s.pgp Description: PGP signature
Re: Less interactive upgrades.
On 16 Mar 2000 16:06:34 -0500, Will Lowe wrote: I've had the same thought, but not enough time to begin such a project. I wonder if there would be some way to integrate this with the existing debconf system -- if it uses the same interface, etc., end-users will be much happier. I plan to make the user interface modular, and coming out with a few of them. My current thinking is that this program (which I should probably name sometime soon) should have: - A Traditional interface, which would mimic the way dpkg does it, but at the start of config rather than throughout. - An interface that lists files, one per line, and lets the user pick on the command line. (Perhaps it will use readline.) - A full-screen interface. Perhaps it will use dialog, but I need to figure out how well that lets me bind operations to keys. I may end up having to roll my own thing. (Ick.) Debconf integration doesn't seem all that likely, as the two are fairly orthagonal. (In the Debian world, configuration and configuration files seem to be rather distinct things.) However, I think I can make the look fairly seamless. (Getting it working is what I'll try first, however.) One other question: Does anyone think having a never ask about this config file again option is a good thing? I'm torn. -- Tom Rothamel - http://onegeek.org/~tom/ --- Using GNU/Linux Writing from home, just outside Northport, NY. The Moon is Waxing Gibbous (87% of Full).
Re: Less interactive upgrades.
Debconf integration doesn't seem all that likely, as the two are fairly orthagonal. (In the Debian world, configuration and configuration files seem to be rather distinct things.) Yes, they're pretty distinct, but it seems a little counterintuitive to have to configure a package twice: once with whatever questions debconf asks, and once again when asked about conffiles. I suppose it's ok if they're seperate programs, so long as the default way to handle things is to dpkg-preconfigure packagename1 dpkg-askaboutconffiles packagename1 dpkg-preconfigure packagename2 dpkg-askaboutconffiles packagename2 One other question: Does anyone think having a never ask about this config file again option is a good thing? I'm torn. Not on a per-conffile basis, I think. Maybe there should be a way to make the default for _all_ conffiles be ask no questions, (accept the dpkg N answer), send email about what you did. With BIG WARNINGS about how much stuff might break if you enabled it. Will -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | | http://www.cis.udel.edu/~lowe/ | |PGP Public Key: http://www.cis.udel.edu/~lowe/index.html#pgpkey| --
Re: Permission policy
Ruud de Rooij [EMAIL PROTECTED] wrote:
(of course, this attack can be prevented using mount options to
disable setgid executables on all filesystems where users have write
access)
But the user can still leave a process running with the privileges after he
logs out. Now whenever he logs in from anywhere else in the world, he can
request the privileges from that process.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Two maintainer entrys in bug reports by maintainer
Andreas Tille [EMAIL PROTECTED] wrote:
Should I file a bug report against the bug system?
(Filing a bug-report against myself is hard in this case because
I can't fix it ;-).)
I think if you reupload your packages with the correct Maintainer field, then
the bug system will fix itself.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
