Re: Changes in dpkg Pre-Depends
Guillem Jover wrote: It's one of the few native packages (if not the only one) that is still statically linking. dpkg appears to be dynamically linked on my unstable/amd64 box: kee...@keegan:~$ file /usr/bin/dpkg /usr/bin/dpkg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped Am I missing something? Apologies in advance if so. - Keegan -- Keegan Quinn Software Support Engineer Storix, Inc. (619) 543-0200 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b7f3376.9050...@storix.com
Re: Debian Light Desktop - meta package
On Fri, Apr 14, 2006 at 10:19:20AM +0200, Christian Perrier wrote: > I would vote against too much choices if we go this way, > though. Probably if the multiple desktop environments suggestion is > implemented, it should be restricted to four choices: > > -"I dont know" > -KDE > -Gnome > -Light desktop > > Offering too many choices would add much confusion and we have to > remember that tasks are mostly targeted at novice users I agree with your concepts here, but I have an idea. Perhaps something like this could be offered: * Full desktop (or "Heavy" maybe?) * KDE * GNOME * Light desktop (or "Advanced" maybe?) * openbox * fluxbox * etc. I don't know if this would be practical but I think it could be useful. HTH, -- Keegan Quinn <[EMAIL PROTECTED]> http://keegan.sniz.org q="'" qq='echo q=\"$q\" qq=$q$qq$q \&\& eval \$qq' && eval $qq signature.asc Description: Digital signature
Re: Changes in formal naming for NetBSD porting effort(s)
On Mon, Dec 15, 2003 at 11:03:00PM +, Roger Leigh wrote: > Demons are evil, and the BSD mascot is a demon (albeit a stylised > one). On the other hand, it's not /intended/ to be evil. In this > particular case, my personal thought on this is that the intent > outweighs the fact that it's a demon (come on, the BSD daemon on the > front of my FreeBSD Services box is holding a spanner and wearing > trainers--that's not exactly evil, is it?). What drives the assertion that "demons are evil?" I'm neither religious or highly educated on the matter, but I've never really thought of them as such. Other summaries in this thread have pointed out their neutrality. Can you provide some references? I've no vested interest here, I just find this discussion interesting, and I like the names offered by Branden. Thanks; my apologies if this is considered OT... - Keegan
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 02:29:48PM +, Colin Watson wrote: > Why not call it "linux-experimental" or "linux-rmh" or similar then? I'm > sure a lot of people would be much happier with your proposal if it > didn't claim the important namespace of "linux", which implies that it > is the preferred kernel package. Indeed. I would be much happier to see "linux-kernel-rmh" instead of just "linux". - Keegan signature.asc Description: Digital signature
Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86
(As if this ITP hasn't been nit-picked quite enough...) On Sun, Nov 09, 2003 at 03:12:19PM +0100, Mattia Dongili wrote: > Description : Synaptics TouchPad driver for XFree86 > > An input driver for the XFree86 X server to enable advanced features > of the Synaptics Touchpad including: > ... H... In the first instance you use the capitalization "TouchPad", in the second "Touchpad". Maybe they should be consistent? - Keegan signature.asc Description: Digital signature
Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)
On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote: > On 05-Nov-03, 19:14 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote: > > I'm in two minds whether or not to ask this, but I've been wondering > > about the naming scheme for linux packages - kernel-*. Why not > > linux-kernel-* or linux-* ? If alternative kernels in debian become > > more popular, is there a potential for confusion in the future? > > Surely these won't all show up in the same Packages file...if you're > running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the > Linux and Hurd kernels even be in the list? It would be nice to be able to [relatively] easily switch between kernels. I have no idea if that is possible, but it would be nice. :) - Keegan signature.asc Description: Digital signature
Re: Bug#219277: ITP: gnusound -- Powerful sound editor
On Wed, Nov 05, 2003 at 02:21:12PM +0100, Marc Dequ??nes wrote: > GNUsound is a sound editor for Linux. It supports multiple tracks, > multichannel output, and 8, 16, or 24/32 bit samples. It can read > a number of audio formats through libaudiofile, and saves them as > WAV. GNUsound supports a large number of high-quality audio > effects through the LADSPA plugin architecture. Does GNUsound work with ALSA, OSS/Free, or something else? - Keegan signature.asc Description: Digital signature
Re: Bug#215058: ITP: libdvb -- library to tune and command DVB cards
On Fri, Oct 10, 2003 at 03:41:23AM +0200, Sam Hocevar wrote: > * Package name: libdvb > Version : 0.5.0 > Upstream Author : Marcus Metzler <[EMAIL PROTECTED]> > * URL : http://www.metzlerbros.org/dvb/index.html > * License : GPL > Description : library to tune and command DVB cards > > This library offers an abstraction layer over the Linux DVB kernel drivers > to tune and command DVB cards. Common uses include scanning transponders, > selecting channels and retrieving TS data. What is 'DVB?' Some type of radio interface? It would be nice if the final description said something about that. - Keegan signature.asc Description: Digital signature
Re: many scripts fail if /tmp/tempfile.$$ exists -> local DOS vulnerability
On Fri, Sep 05, 2003 at 12:50:01AM +0200, Santiago Vila wrote: > Jakob Lell wrote: > > [...] > > Is it a good idea to report bugs against all packages containing this > > local DOS vulnerability? > > Yes, but please follow our common guidelines for reporting bugs. > If you plan to submit many of them, ask here before you start. Isn't that exactly what he did, in the message you just replied to? I, for one, think it sounds like a good idea. - Keegan pgp4A7StvkRHr.pgp Description: PGP signature
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 04:31:59PM +, benfoley wrote:
> On Friday 29 August 2003 09:28, Steve Lamb wrote:
> > On Fri, 29 Aug 2003 00:36:57 -0700
> > Adam McKenna <[EMAIL PROTECTED]> wrote:
> > > Well, since we're pointing fingers, it's really SMTP that's broken by
> > > design, and all anti-spam programs (including C-R systems) are merely
> > > stopgap measures that try to make up for SMTP's shortcomings.
> >
> > Oddly enough Spamassassin doesn't exasperate the problem. TDMA does.
>
> exacerbate is probably what you meant here.
Actually, I think exasperate is perfectly valid as well.
From WordNet (r) 1.7 [wn]:
exasperate
v 1: exasperate or irritate [syn: {exacerbate}, {aggravate}]
2: make furious [syn: {outrage}, {infuriate}, {incense}]
3: make worse; "This drug aggravates the pain" [syn: {worsen},
{aggravate}, {exacerbate}] [ant: {better}]
- Keegan
pgpkdhOOQymzr.pgp
Description: PGP signature
Re: Bug#203903: ITP: mcp-plugins -- LADSPA plugins designed for Alsa Modular Synth
On Sat, Aug 02, 2003 at 07:02:35PM +0200, Andrea Glorioso wrote: > Description : LADSPA plugins designed for Alsa Modular Synth > > Setof LADSPA plugins that vastlyimprove the sound of > AlsaModularSynth. Currently they consist of these plugins: Are these really specific to ams? LADSPA-compliant plugins can generally be used with any LADSPA host software. You might want to update your descriptions to reflect that fact. Having ams Recommend: this package should be sufficient to denote the relationship. Glad to see these getting packaged! Thanks, - Keegan pgpm1H2d67pX7.pgp Description: PGP signature
Re: CUPS should be the default print service in Debian/Sarge
On Thu, Jul 31, 2003 at 03:38:55PM +0200, Petter Reinholdtsen wrote: > I believe it would be a good idea if the default print system in the > next release of Debian (Sarge) is changed to CUPS. CUPS is a more > complete, more userfriendly and RFC complient printing system. FWIW, I've had very good experiences with the CUPS in unstable, so I'd not object to this. OTOH, installing it without it being 'default' is already quite trivial. What would this change entail, exactly? Just my non-DD US$0.02. - Keegan pgpD9zk1xuo7I.pgp Description: PGP signature
Re: Closing cinelerra ITP [was: cleaning of the wnpp / RFP]
On Wed, Jul 23, 2003 at 11:15:57AM -0400, Michael Furr wrote: > This isn't to say that it can _never_ enter debian, just that a > significant amount of code hacking would have to take place as well as a > general audit. Needless to say, I do not have time(nor the hardware) to > make these modifications, nor support the resulting modified program. > If anyone feels up to this task, I would be happy to send over my > patches from my [incomplete] attempt at packaging. Barring that, I will > close this ITP in a few days. Could you change the bug back to an RFP instead? Then at least this note will survive, in case anyone ever does have time to deal with these issues. Thanks, - Keegan pgprcR07qE6k7.pgp Description: PGP signature
Bug#202556: ITP: apradar -- a GTK+-based graphical netstumbler
Package: wnpp Version: unavailable; reported 2003-07-22 Severity: wishlist * Package name: apradar Version : 0.41 Upstream Author : Don Park <[EMAIL PROTECTED]> * URL : http://apradar.sourceforge.net/ * License : MIT Description : a GTK+-based graphical netstumbler This project makes use of the Linux kernel wireless extensions, available in the 2.4, 2.5, and 2.6 series. It is meant to obviate the need for manually configuring wireless network cards. The upstream author is quite pleased that his software has been packaged. The results are available at the following apt source: deb http://rune.thebasement.org/debian unstable keegan deb-src http://rune.thebasement.org/debian unstable keegan Sponsorship offers will be warmly welcomed, although I am aware of some issues related to the build process which I am working out with the author, and I'll be writing a manual page. - Keegan pgplRoZ4Ud9ee.pgp Description: PGP signature
Re: Work-needing packages report for Jul 11, 2003
On Fri, Jul 11, 2003 at 05:34:23PM +0200, Marcelo E. Magallon wrote: > So, you mean, this is not the package our users should be looking at > when they search for a VoIP application? It's not only orphaned but > not even used? *HINT* *HINT* It would be nice to see some popularity-contest data for this, and perhaps even all of the packages in your list... Of course it's not perfect, but that might give us some vague idea of how widely used these packages are. - Keegan pgpCmCoiPLlzH.pgp Description: PGP signature
Bug#200580: ITP: xmms-null -- null output plugin for XMMS
Package: wnpp Version: unavailable; reported 2003-07-08 Severity: wishlist * Package name: xmms-null Version : 2.0.1 Upstream Author : Håvard Kvålen <[EMAIL PROTECTED]> * URL : http://havardk.xmms.org/plugins/null_output/ * License : GPL Description : null output plugin for XMMS XMMS output plugin which simply throws the signal away. Useful for testing and benchmarking. Also useful for nullifying the output when using a DSP plugin for broadcasting, or if you don't have a soundcard. The upstream author of this software has been contacted; I am waiting for a reply before beginning serious packaging work. - Keegan pgpfWVWl8yv9k.pgp Description: PGP signature
Bug#200579: ITP: xmms-oddcast -- XMMS plugin for broadcasting
Package: wnpp Version: unavailable; reported 2003-07-08 Severity: wishlist * Package name: xmms-oddcast Version : 2.0.1 Upstream Author : oddsock <[EMAIL PROTECTED]> * URL : http://www.oddsock.org/tools/oddcastv2_xmms/ * License : GPL Description : XMMS plugin for broadcasting From the website: OddcastV2 - XMMS is made up of two separate programs. The first is an XMMS effect plugin does the very simple task of taking the audio data from XMMS and sending it to the second program which is a standalone program called (aptly enough) "oddcastv2". Obviously, this is not a very good long description for the final result. I am open to suggestions. This will depend on the oddcast package previously ITP'd. Upstream distributes these pieces of software in one tarball; they may or may not be built from a single source package in the end. As I understand it, both pieces should be usable seperately. The upstream author of this software has been contacted; I am waiting for a reply before beginning serious packaging work. - Keegan pgpqmByfD4Crt.pgp Description: PGP signature
Bug#200576: ITP: oddcast -- encodes and transmits audio to a streaming server
Package: wnpp Version: unavailable; reported 2003-07-08 Severity: wishlist * Package name: oddcast Version : 2.0.1 Upstream Author : oddsock <[EMAIL PROTECTED]> * URL : http://www.oddsock.org/tools/oddcastv2_xmms/ * License : GPL Description : XMMS plugin for broadcasting From the website: The wxWindow UI standalone program which is responsible for taking the raw audio data (fed to it via the effect plugin) and converting it to the appropriate compressed audio codec (MP3 and Vorbis supported) and then sending it out to the appropriate streaming server (Shoutcast, Icecast1.x, Icecast2 supported). "oddcastv2" will also perform things like resampling (going from 44kHz to 22kHz or to 32kHz) as well as channel down/upmixing (converting from Mono to Stereo and vice-versa). Obviously, this is not a very good long description for the final result. I am open to suggestions. This will be a dependancy of the xmms-oddcast package, which will be ITP'd shortly. Upstream distributes these pieces of software in one tarball; they may or may not be built from a single source package in the end. As I understand it, both pieces should be usable seperately. The upstream author of this software has been contacted; I am waiting for a reply before beginning serious packaging work. - Keegan pgpc0omAKCFdJ.pgp Description: PGP signature
Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)
On Tuesday 24 June 2003 10:59 am, Emile van Bergen wrote: > Hi, > > On Tue, Jun 24, 2003 at 11:44:51AM -0500, Adam Heath wrote: > > Tell me when you upload this, so I can file an rc bug against it, for > > modifying other packages conffiles. > > *g* > > 5 serious replies already -- sorry Adam, I'm afraid there are just too > many people that lack even the most basic sense of humour. Or perhaps not everyone thinks a threat of an RC bug is a laughing matter. - Keegan
Re: advise for packaging duali "arabic spell checker"
On Sunday 22 June 2003 12:48 am, Mohammed Sameer wrote: > i was thinking about splitting duali itself into 2 packages: > 1- duali "the main dictionary" > 2- duali-dev "contain the script" > duali-data build-depends on duali-dev while duali itself depend only on > duali-data > > I really don't know what to do so i thought about asking here for help. The plan you outlined seems quite sensible to me. - Keegan
Re: no freshness dating inside Packages.gz
On Tuesday 17 June 2003 03:09 pm, Dan Jacobson wrote: > Sure, "you don't need to know the date, as you are using sid and did > apt-get update, you are assured it's the latest version". Well, one > doesn't need the maintainer field either etc. Are you implying that knowing the date you last updated somehow helps you find out who created the package? ls -l /var/lib/apt/lists/*Packages This would give you the time your Packages files were last updated. Is this what you were looking for? Your message does not exactly make it clear. - Keegan
Re: Every spam is sacred
On Friday 13 June 2003 05:13 pm, Don Armstrong wrote: > Oh, what the hell. This damn song won't get out of my head, so now you > all get to be subjected to it to[1]: FWIW, the original version of this song has also been in my head for weeks. Thanks for digging up the full text :) > 1: Misery loves company. Ad infinitum.
Re: Bug#195236: ITP: eclipse-cdt -- C(++) Development Tools for Eclipse
On Thursday 29 May 2003 05:15 am, Jan Schulz wrote: > As I'm more a java guy (it's a C IDE written in java), I would like > to have someone testing the functionality. I will drop a mail with > the apt repository, when I'm ready with packaging... > > As I'm not a DD yet, this packages will need a sponsor. I hope > Takashi Okamoto will do that (he is currently sponsoring my eclipse > packages), but I haven't asked yet :) As you are neither a programmer in the relevant language, a user of the software, or a Debian developer, are you certain you wish to package this software? Not being a DD is a fairly minor detail - I have filed ITPs myself without being a developer - but I believe it is generally a good idea to use software -before- packaging it... Unusable packages do far more harm than good, and I can see how this could easily become such a case. Just a suggestion... - Keegan
Re: Where are translated man pages packaged?
On Friday 16 May 2003 12:13 pm, Keegan Quinn wrote: > On Friday 16 May 2003 11:45 am, Fabio Massimo Di Nitto wrote: > > On Fri, 16 May 2003, Keegan Quinn wrote: > > > > more than once i had to install small dns servers on boxes with less > > > > than 100Mb flash and stuff like that... so basically also the minimal > > > > installation has to be tight.. then rm doc and man and after install > > > > the minimum sets of pkgs to provide the services. > > > > > > Please do not try to force this methodology upon the standard Debian > > > base system. Administrators of embedded systems have many tools to > > > deal with these problems already, that do not require ever unpacking > > > the full base onto the target. > > > > sorry but i can hardly read from the previous post that i am trying to > > force something to someone. I guess this is just a misunderstanding. > > Perhaps the word 'force' was a bit harsh, but it's essentially how it works > for an end-user. It seemed to me that you were suggesting that the > standard installer should be optimized for embedded systems, which does not > sound like a very good idea. These systems have many specialized needs > which cannot be easily accounted for. Although, in retrospect, I wouldn't object at all to a different installer which is actually designed for embedded systems. :) I'm not sure if work is being done along these lines or not. - Keegan
Re: Where are translated man pages packaged?
On Friday 16 May 2003 11:45 am, Fabio Massimo Di Nitto wrote: > On Fri, 16 May 2003, Keegan Quinn wrote: > > > more than once i had to install small dns servers on boxes with less > > > than 100Mb flash and stuff like that... so basically also the minimal > > > installation has to be tight.. then rm doc and man and after install > > > the minimum sets of pkgs to provide the services. > > > > Please do not try to force this methodology upon the standard Debian base > > system. Administrators of embedded systems have many tools to deal with > > these problems already, that do not require ever unpacking the full base > > onto the target. > > sorry but i can hardly read from the previous post that i am trying to > force something to someone. I guess this is just a misunderstanding. Perhaps the word 'force' was a bit harsh, but it's essentially how it works for an end-user. It seemed to me that you were suggesting that the standard installer should be optimized for embedded systems, which does not sound like a very good idea. These systems have many specialized needs which cannot be easily accounted for. - Keegan
Re: Where are translated man pages packaged?
On Friday 16 May 2003 01:07 am, Fabio Massimo Di Nitto wrote: > On Fri, 16 May 2003, Colin Watson wrote: > > > I agree with Wouter. For me would be an issue having the base system > > > bigger than it is now. Specially preparing very small "black box" where > > > i need to save as much space as i can even during the installation > > > phase. > > > > Can't you basically just 'rm -rf /usr/share/doc /usr/share/man' if > > you're tight on space? > > Of course... but also during the installation? > > I don't mind at all cleaning up after... but during is a bit of a pain.. > > more than once i had to install small dns servers on boxes with less than > 100Mb flash and stuff like that... so basically also the minimal > installation has to be tight.. then rm doc and man and after install the > minimum sets of pkgs to provide the services. Please do not try to force this methodology upon the standard Debian base system. Administrators of embedded systems have many tools to deal with these problems already, that do not require ever unpacking the full base onto the target. - Keegan
Re: Answers to "Why is package X not in testing yet?"
On Thursday 15 May 2003 09:51 am, Joe Buck wrote: > Joe Buck wrote: > > > However, the output is redundant in many cases. > > On Thu, May 15, 2003 at 08:37:45AM +0200, Björn Stenberg wrote: > > Fixed now. > > Terrific! I'm impressed at your bug-fixing speed; there's a quick "fixed > now" to almost every issue. This script is a huge contribution. > > I have one more question, but this is probably more about the rules for > "testing". The script says > > > Updating fam makes 177 packages uninstallable on alpha: amor, ark, > > bibletime, dcoppython, eyesapplet, fifteenapplet, galeon-nautilus, ... > > I can't figure out why this is so: why would updating fam break so many > apparently unrelated packages, but only on alpha? Architectures are processed alphebetically, so alpha is first. Most likely this breakage would occur on most architectures, if they were checked. (This should be / is in a FAQ somewhere?) - Keegan
Re: security in testing
On Thursday 15 May 2003 08:31 am, Matthias Urlichs wrote: > Hi, Matt Zimmerman wrote: > > In that case, I invite any maintainer with a security fix for their > > package in 'testing' to upload it to testing for > > testing-proposed-updates. Problem solved. Are you the one who will be > > responsible for reviewing the packages? > > testing, in the absence of a freeze, is a moving target and continuously > updated from unstable, without any kind of review. I fail to see why a > t-p-o => testing path, or even a separate-testing-updates solution as I've > originally proposed, would need a review, but I'm willing to be > enlightened. To prevent the normal progression of packages into testing from unstable, and thus the original point of testing, from being lost. If this path is used for anything other than security updates, testing becomes completely pointless, as I see it. - Keegan
Re: security in testing
On Wednesday 14 May 2003 04:53 pm, Björn Stenberg wrote: > What's worse, saying testing is not for public use means there is _no_ > place to get updates, since unstable is obviously not an option for end > users. This makes Debian the only linux distribution I know of that > completely eschews software updates between frozen releases (except for > security fixes). Hmm. Funny how myself and every admin I know have only very minor issues with running unstable. What, pray tell, makes it such an 'obvious' non-option for end users? Well-timed unstable snapshots are often more 'stable' than commercial Linux releases, in my limited experience. Sure, every now and then a badly-broken package makes it in for a day or two. This seems to be far less harmful than the massive headache that treating 'testing' as a usable release seems to be causing. > The amount of backporting and apt-pinning going on suggests not all Debian > end users are content with yearly updates. A testing-like "middle ground" > release for end users definitely has a place in the Debian universe. I do like the sound of this, but saying it has a place and actually making it happen are very different things. There seems to be a lot of the former, and little of the latter - perhaps because unstable actually works just fine for the majority of people actually working on it? Just a guess, from my limited perspective. - Keegan
Re: show all Suggests packages not installed
On Wednesday 14 May 2003 11:05 am, Manoj Srivastava wrote: > On Wed, 14 May 2003 09:36:57 -0700, Keegan Quinn <[EMAIL PROTECTED]> said: > >> The only solution I think is if dpkg were to take over > >> responsibility for deleting configuration files, so that the postrm > >> script doesn't have to worry. > > > > I think that in this situation, package a should check if a-beta is > > installed during its postrm purge, and avoid taking over... Is > > there some reason you think this doesn't work? > > What if I am not aware of a-beta? What if a-beta does not > exist when package a was created? What if there are several a-betas, > and I miss a few? One would hope to see more coordination between Debian maintainers of such similar packages than that. (In fact, in this example, I would expect a and a-beta to have the same maintainer, although it would by no means be necessary.) However, you are right, there will always be corner cases, and there are potential synchronicity issues with this approach, involving partial upgrades; I still think it is better than not trying at all. Solving this properly remains a worthy goal. - Keegan
Re: show all Suggests packages not installed
On Tuesday 13 May 2003 07:31 pm, Brian May wrote: > On Tue, May 13, 2003 at 09:21:33AM -0700, Keegan Quinn wrote: > > On Monday 12 May 2003 04:40 pm, Brian May wrote: > > > Also, just blindly purging packages can be dangerous, in some cases old > > > packages will purge files used by newer packages that are still used by > > > the system. > > > > I'm pretty sure that would be a bug. You should report this behavior if > > you see it. Although I won't deny this happens, purging completely > > unused packages is generally a good idea, unless you want your system > > building up a nice history of everything it has ever been used for. > > However, there is no good solution. > > eg. assume package a and a-beta conflict. > > Package a postinst creates a /etc/a.conf file. ie. a configuration file, > not a conffile. > > Naturally the purge has to remove it. > > However, the system adminstrator installs package > a-beta instead. > > This removes package a (because of the conflict) but doesn't run the > purge script. > > Years latter, adminstrator say "I can purge > package a". > > He does so. > > Package a-beta stops working. > > Reason: when purging package a, the postinst script has no way of > knowing that /etc/a.conf is still being used by package a-beta, and > erases it. > > The only solution I think is if dpkg were to take over responsibility > for deleting configuration files, so that the postrm script doesn't have > to worry. I think that in this situation, package a should check if a-beta is installed during its postrm purge, and avoid taking over... Is there some reason you think this doesn't work? Certainly dpkg handling would be cleaner, but since configuration file formats often change, it might not be quite so easy to implement. There are other tools and concepts for dealing with that problem, though.. (Debconf, UCF, three-way diffs, different configuration file location..) - Keegan (PS: No need to Cc me, I'm on the list.)
Re: show all Suggests packages not installed
On Monday 12 May 2003 04:40 pm, Brian May wrote: > Also, just blindly purging packages can be dangerous, in some cases old > packages will purge files used by newer packages that are still used by > the system. I'm pretty sure that would be a bug. You should report this behavior if you see it. Although I won't deny this happens, purging completely unused packages is generally a good idea, unless you want your system building up a nice history of everything it has ever been used for. - Keegan
Re: libstdc++... Help please
On Tuesday 29 April 2003 11:05 am, Andreas Metzler wrote:
> David Starner <[EMAIL PROTECTED]> wrote:
> >> sid=unstable - you know that, don't you?
> >
> > We need someone to test unstable, don't we? We can not realistically
> > test our distribution if the only people running it are those with many
> > computers who put it on one they aren't really using. Please don't give
> > our testers crap for actually testing the system in real life
> > situations.
>
> If somebody _needs_ his computer working 100% ("I've got an essay due
> in 24 hours...") and runs unstable on it imho some reminder that this
> might be a bad choice is *required*.
Running unstable in general is no big deal - in fact I would go so far as to
say that on many days, an unstable snapshot is better than a commercial Linux
stable release - but people should be exercising some significant care when
upgrading, especially under deadlines like this. Lots of people (like me)
have no problem running unstable, encountering and dealing with bugs, but
people in this position need to take responsibility for introducing new code
into their own systems.
In other words, if you have serious (non-Debian) work to do on an unstable
machine that is functioning properly, don't upgrade - doing this is like
asking, "are there any new bugs I can work on?" If you don't really want to
work on those bugs right then, wait!
- Keegan
Re: i386 compatibility & libstdc++
On Friday 25 April 2003 08:06 am, Arnd Bergmann wrote: > On Friday 25 April 2003 15:43, Matt Zimmerman wrote: > > On Fri, Apr 25, 2003 at 01:37:04PM +0200, Emile van Bergen wrote: > > > Hmm... I'd argue for putting the split at either 386 vs 486+ (the > > > latter at least has a math copro and CMPXCHG), or at 386-pentium vs > > > 686+. > > > > See the beginning of this thread; the problem is that libstdc++ has drawn > > a line between 386 and 486. > > No, the only thing that is enforced is that i386 systems cannot use the > i486+ ABI. It is a very possible solution to have use the i386 ABI on any > system and the i486+ ABI only on i686+. > > That will however mean that third party software using libstdc++5 with the > i486 ABI won't work will not work on systems with an instruction set older > than i686. It's a compromise, but I think it's still better than forcing > everyone on the i486 compatibility that is just as obsolete as i386 (i.e. > you won't buy any _new_ i486 machines in order to run Debian). I beg to differ. I've purchased a pair of embedded 486/133 machines for use as communication computers running Debian, just in the last couple months. Many others are doing the same with older laptops and even desktops. I would see it as a great shame to lose this support. > If we really want to split i386 in 'compatible' and 'fast', the i686 border > makes sense because users who care about speed probably bought the machine > during the last two years and those should be i686 compatible. Not everyone buys brand new whiz-bang machines. I do not think we should create arbitrary boundaries - this thread began with a boundary that was enforced by code, not just a perception of which machines are newer or faster or more readily available. - Keegan
Re: Bug#189370: acknowledged by developer (irrelevant)
On Monday 21 April 2003 04:24 pm, Adam Heath wrote: > On Mon, 21 Apr 2003, Keegan Quinn wrote: > > On Monday 21 April 2003 03:29 pm, Atsuhito Kohda wrote: > > > Am I missing something? > > > > Only the fact that, as Debian maintainer, you do not have the right to > > decide which files Debian users may or may not edit. Policy says they > > can do as they like, regardless if you like it or your packages care for > > their way, and you are not allowed to overwrite their actions. > > > > Now, am I missing something? > > Yes, lots. > > Only configuration files are protected as you say. Conffiles are > automatically protected by dpkg, but not all configuration files are > conffiles. So, you're saying that the texmf.cnf file in question is not a configuration file? Section 11.7.1 from policy seems to say otherwise. Maybe I'm seriously misreading something. I didn't mean to bring conffiles or dpkg into this at all, but perhaps I missed some part of the discussion. configuration file A file that affects the operation of a program, or provides site- or host-specific information, or otherwise customizes the behavior of a program. Typically, configuration files are intended to be modified by the system administrator (if needed or desired) to conform to local policy or to provide more useful site-specific behavior. (I realize I don't need to point to policy as a stick to beat people with, et al. I'm becoming a bit confused just following this thread, and am wondering where that happened, since the core issue seems straightforward.. If I am in need of more sleep, please point that out.) - Keegan PS. I'm subscribed, no need for a Cc.
Re: Bug#189370: acknowledged by developer (irrelevant)
On Monday 21 April 2003 03:29 pm, Atsuhito Kohda wrote: > Am I missing something? Only the fact that, as Debian maintainer, you do not have the right to decide which files Debian users may or may not edit. Policy says they can do as they like, regardless if you like it or your packages care for their way, and you are not allowed to overwrite their actions. Now, am I missing something? - Keegan
Re: Nameserver-pushing mechanism
On Monday 14 April 2003 02:36 am, Thomas Hood wrote: > Proposal: Implementation steps for dynamic resolver configuration [snip] > * New "resolver" package includes /etc/init.d/resolver which > generates /run/resolv.conf from /run/resolver/interface/* > and does a run-parts on /etc/resolver/update.d/ ... > * Modified resolver package depends on the latter versions > of the networking daemon packages and ifupdown. On > installation, optionally changes /etc/resolv.conf into a > symlink to /run/resolv.conf If we're going to have /run/resolver, why not use /run/resolver/resolv.conf? We're making all of these nice, clean new directories, and already kludging them up. Just a minor nit-pick. This FHS-remodeling business is serious stuff... - Keegan
