Package: wnpp
Severity: wishlist
Owner: Bdale Garbee
X-Debbugs-Cc: debian-devel@lists.debian.org
Package name: openrocket
Version : 23.09
URL : https://openrocket.info
License : GPLv3+
Programming Lang: Java
Description : Model Rocket Simulator
[EMAIL PROTECTED] (David Schmitt) writes:
> On Monday 14 March 2005 11:10, Rene Engelhard wrote:
>> pcc is barely at 98%. I don't think that barrier should be that high. We
>> *should* at last release with the tree most important archs: i386, amd64,
>> powerpc.
>
> Please, 98% is not high. It is j
[EMAIL PROTECTED] (David Schmitt) writes:
>> 4.2) the package fails to build. This used to be a RC critical FTBFS,
>> but is not so anymore. The porter are responsible for fixing the bug and
>> uploading a fixed package to unstable, as they do now.
>
> Wouldn't it be better: "The porter are re
In article <[EMAIL PROTECTED]> you wrote:
: - new features
: - installation via serial terminal
An additional reason to do this is that non-PC platforms (Sparc, Alpha, HP
coming eventuall...) often run "headless" with onl a serial console and a
network interface for servers. Getting it right i
In article <[EMAIL PROTECTED]> you wrote:
: This list can be added to by anyone. What I'd like to ask for now is any
: comments on this.
A checklist like this is a good idea, particularly if it eventually provides
the list of things that initially need to be part of a regression suite for
the pa
In article <[EMAIL PROTECTED]> you wrote:
: -BEGIN PGP SIGNED MESSAGE-
: On Fri, 21 Nov 1997, Bdale Garbee wrote:
:> In bug report 15091, Christian Meder suggests to me that I make gzip
predepend
:> on libc6. It is not clear to me that this is a good thing to do.
: [ I t
For the record:
I have need of a port scanner tonight, I don't see one packaged, I happen
to like nmap, and I see no record that anyone else has indicated they are
packaging it...
Expect a package upload shortly... I've got the sources reworked for libc6,
and am finishing up the package now.
Fo
I've been maintaining 'ytalk'. I don't actually use it any more, and it's
the only X-based thing I maintain except xtrkcad, which is a binary-only
package that I don't have to futz with much. Therefore, I'd like to stop
maintaining ytalk...
Anyone want it? There are a couple of open bugs, but
In article <[EMAIL PROTECTED]> you wrote:
: Overlap between amanda-client_2.3.0.4-2 and amanda_2.3.0.4-2:
:usr/lib/amanda/amcat.awk
:usr/lib/amanda/amplot.awk
:usr/lib/amanda/amplot.g
:usr/lib/amanda/amplot.gp
:usr/lib/amanda/versionsuffix
:usr/man/man8/amplot.8.gz
:usr
In article <[EMAIL PROTECTED]> you wrote:
Neat idea (a mirror in space), but unlikely to happen.
: Hey, doesn't Bdale build satellites? :)
Yep. See www.amsat.org for more details... specifically, what I'm working on
today (literally) is documented at:
http://www.amsat.org/amsat/sats/ph
In article <[EMAIL PROTECTED]> you wrote:
: Given the creation of a bo-updates directory for those of us who wish to
: provide backported versions of hamm packages for bo (thanks Guy!), we now
: have the possibility to do this.
I'd encourage the packaging and release of a fresher xntp3/xntp3-doc
In article <[EMAIL PROTECTED]> you wrote:
: Anyone have a digitized copy of this? :)
Look on www.npr.org later tonight. The 'current' page still has the pieces
from the 7th... All the interesting stuff on NPR becomes available via
RealAudio shortly after broadcast.
Bdale
--
To UNSUBSCRIBE, e
I intend to package 'jstation' for Debian. This is a suite of Java-based
software that implements a full-featured ground station for amateur radio
satellites using the Pacsat protocols.
Because jstation depends on JDK 1.1, it will go to contrib despite being
GPL'ed itself. This might change
In article <[EMAIL PROTECTED]> you wrote:
I'm the tar maintainer for Debian, among other things.
: -z filter through gzip, bzip, bzip2 as appropriate
: That would be a nice thing.
But really hard to get right for compression. :-) For decompression, it is
conceivable that you could pick t
In article <[EMAIL PROTECTED]> you wrote:
:> Debian tar has a patch which hands off files to bzip2 if the -I option is
:> passed to it.
: Why wasn't the -z option expanded to recognize the bzip2 signature?
: That would seem to be a better solution to me.
Because the options are used both on comp
In article <[EMAIL PROTECTED]> you wrote:
: Hmm... it's actually probably a good idea to bzip2 the X sources.
: They're monstrous.
Probably a good idea. However...
The right way to handle this is for someone to broach the subject of using
compressors other than gzip for source packages over on
In article <[EMAIL PROTECTED]> you wrote:
: with MAKEDEV -I you can create device files in the local directory,
: even within fakeroot. what about adding a list of the normal devices to cruft,
: and report obsolete devices, strange permissions, etc. this would require
: some cooperation with the m
In article <[EMAIL PROTECTED]> you wrote:
: Yes, I know it may be too late to be changed, but are there any hints whom
: to contact to get this "fixed"?
The upstream maintainer, of course. Read the /usr/doc/tar/README.Debian file.
Also, note that if you pipe tar's output through cat or dd on th
In article <[EMAIL PROTECTED]> you wrote:
: Finally, realize that packages-wise, we probably rival RedHat's Alpha
: port---something on the order of 800+ packages are available on the
: Alpha. However, that's *half* of the number available in Debian/i386.
That raises an interesting question, tha
In article <[EMAIL PROTECTED]> you wrote:
: fast. Its not agood solution, so thats why I asked here about
: integrating bzip2 support into gzip.
Points well taken. You're just asking in the wrong place. You should take
this up with the gzip upstream maintainer. It is not a Debian packaging
is
The new tar behavior with respect to wildcards is not a change I
introduced just for Debian, it's a new upstream change that appears to
be quite intentional and well documented, as per this text from the tar
info docs:
The following table summarizes pattern-matching default values:
Members
On Tue, 2006-06-27 at 13:09 +0200, Jeroen van Wolffelaar wrote:
> But on the other hand, according to the 'be strict in what you send,
> liberal in what you accept' mantra, it makes sense for tar to not create
> tarfiles which in the past have caused issues for certain programs while
> there's a p
On Wed, 2006-06-28 at 10:36 +0200, Bill Allombert wrote:
> > Here, the only way seems to be putting an entry in NEWS.Debian (for
> > users script, ie things not under our control).
Good idea, Christian.
> In addition, I would suggest we reinstate the previous behaviour, but
> display a warning w
[EMAIL PROTECTED] (Barak A. Pearlmutter) writes:
> As a compromise that addresses some of the issues I would suggest the
> following: go with upstream, but add some convenience code, to whit:
>
> (1) Hot-wire tar to check an environment variable TAR_WILDCARD_DEFAULT
> and activate the --wildca
In article <[EMAIL PROTECTED]> you wrote:
: ... and the expected destination of those files.
That raises an interesting question for me, my apologies if it's docuemented
somewhere that I haven't found yet.
What's the protocol for picking a directory to dump a new package in?
It was pretty easy
Package: tar
Version: 1.11.8
When attemping to do remote tar operations using the archive name systax
specified in the info file, which is "[EMAIL PROTECTED]:file", if user is not
specified, tar core dumps, when it should use the current username as the
default.
This is probably part of the same
Package: inewsinn
Version: 1.4sec-7
I find it *really* annoying that inewsinn recommends trn, since I want tin,
which requires inewsinn or inn, but don't want trn. This makes me have to
go through conflict resolution every time.
Isn't it sufficient that trn and tin require inn or inewsinn?
Bdal
Package: trn
Version: 3.6-2
It's not clear to me why trn uses 'recommends' for a mail transport
and a news article injector, while tin uses 'depends'. I think that depends
makes more sense, so I'm filing this against trn.
Bdale
In article <[EMAIL PROTECTED]> you wrote:
: * delete mail spool file (what if it's nonempty?)
Tell the person running the script it's non-empty, and ask if they want it
deleted, anyway.
: * delete home directory. What do we do about saving
: files?
S
Package: mh
Version: 6.8.3-2
The 0.93R6 MH mail user interface package causes it to be impossible to
read any mail, since the default moreproc is '/usr/bin/more', and the current
Debian release appears to put more in '/bin/more' instead. You end up with
errors like:
[EMAIL PROTECTED]:~:
This is sort of long. Don't bother unless you care about what /usr's contents
look like, and/or you're desperate for reading material...
I've alluded in the past to my intention to package for Debian the cross
development tools we're using for AMD 29200 embedded systems development. I
care about
In article <[EMAIL PROTECTED]> you wrote:
: > We should document what we ship as we ship it.
: No argument, but that implies lots of work for maintainers
: when initially building packages and when upgrading to new
: upstream releases. I'm not sure that it's practical.
I think it's necessary.
In article <[EMAIL PROTECTED]> you wrote:
: Kenny Wickstrom writes:
: > My X server is
: > on my Win 95 machine. So to get xtet42 to install I needed to add the
: > --force-depends to the dpkg command line.
: xtet42 depends on X11R6 and recommends xserver. This is what Ian Murdoch
: said all X
We're working on code for ground support of the AMSAT Phase-3D satellite that
needs to use the readline and bfd libraries. We in this context is one other
member of the development team I support cross-development tools for, and
myself. John's running 0.93R6, I'm running something closer to in s
I accidentally sent this to just Ian the first time, here it is again...
In article <[EMAIL PROTECTED]> you wrote:
: Martin Schulze writes ("One question upon INN (and syslogd)"):
: > These logfiles are not turned with savelog by cron.sysklogd. Are they
: > turned by cron.inn? If not I might have
In article <[EMAIL PROTECTED]> you wrote:
: >Something ought to be done though, since more(1) can't be made to go
: >backwards through manpages. This is rather a serious deficiency.
: HP-UX's more(1) doesn't allow you to go back at all. Ever. :)
Until HP-UX 10.X, at which point it has very less-
In article <[EMAIL PROTECTED]> you wrote:
: I think we should arrive at a happy medium - uploads
: are verified against their .changes file and moved into an accessable
: area that is not their final resting place. Ian can then move them, with
: the confidence that their integrity has been checked,
In article <[EMAIL PROTECTED]> you wrote:
:
: I'd love that feature too. But that either requires a damn good script, or
: that everybody uses the same .changes format.
"Obviously", everyone should use the same .changes format... but I don't care
what that is, which is why I stayed out of the di
In article <[EMAIL PROTECTED]> you wrote:
: Here are new versions of libgdbm, libdb and libreadline.
I can't find these anywhere, and it's been a couple of days since the
announcement? I really, really, want to install libreadline-2.0-9 ASAP.
Bdale
Package: metamail
Version: 2.7-1
The script /usr/bin/showpicture provided with the metamail package, which is
used by Netscape, et al, to launch xv or xloadimage to display graphical
objects, is a csh script. There is no dependency specified by the metamail
package, and csh is not part of the bas
Package: source
Version: 1.3.43
The file drivers/scsi/hosts.c defines the sequence in which different SCSI
controller cards are identified. The AHA152X driver appears early in the list,
which is unreasonable if there is another, smarter, SCSI controller in the
system... since it will result in th
Package: source
Version: 1.3.43
The SCSI device driver for the AHA1740 only supports one card in a system at
one time. This is annoying.
Bdale
Package: base
Version: 0.93.6-13
It is utterly unreasonable for the system to try and do fsck's when the
system is booted with 'linux single'. The whole point of a single user boot
is that something is wrong that needs reasoned attention from a system
adminitrator. A single-user boot should do a
This release fixes the problem with specifying a null username when a remote
tape is specified to the 'f' argument. Previously, unless the fully qualified
form of
[EMAIL PROTECTED]:/dev/tapename
was used, a segmentation violation and core dump would result before anything
else happened.
In article <[EMAIL PROTECTED]> you wrote:
: It doesn't really matter if a 152X gets detected before a high-power
: whiz-bang SCSI-matic 2010 PCI adapter, because you can still put root
: on any SCSI controller you like.
You are correct, of course, Jeff, but the problem with having a card like
a 1
> Hmmm. This is somewhat more complex than it looks like. I cannot just
> remove /usr/bin/zcat because it is intimately linked with compress.
I disagree. The job of a package maintainer includes the process of doing
things like this to a package. I have to do the same thing for the tar
package,
ED MESSAGE-
Date: 08 Aug 96 04:00 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
Source: tar
Version: 1.11.11-2
Binary: tar
Architecture: i386 source
Description:
tar: GNU tar.
Changes: new upstream version - don't install the 1.1
In article <[EMAIL PROTECTED]> you wrote:
: > When mainstream is updated, hello-1.3 -> hello-1.4
: > Non-usual-maintainer updates, hello-1.3-8 -> hello-1.4-0.1
: > Usual-maintainer updates, hello-1.3-8 -> hello-1.4-1
: >
: > Usual-maintainer should never use -0 for revisions.
:
: I think this se
Package: ftp.debian.org
It appears to me that some files are incorrectly placed directly in the
buzz-fixed tree, instead of being in buzz-updates with appropriate
symlinks in buzz-fixed... all on master.debian.org.
The files in question:
buzz-fixed/source/manpages-de_0.1-4.tar.gz
In article <[EMAIL PROTECTED]> you wrote:
:
: The only incompatibility is that you might have to add a :bk: entry to
: the printcap in order to print to a BSD-lpd-based network printer.
I care a lot about compatibility with other BSD'ish lpd-based systems. I
could live with this easily.
Bdale
In article <[EMAIL PROTECTED]> you wrote:
: I don't know of a longterm solution short of
: duplicating the contrib and non-free trees into stable and unstable
: versions.
During the time when I was "master of master", I was working on a proposal for
restructuring the hierarchy... and this is the s
In article <[EMAIL PROTECTED]> you wrote:
: Why not just have rex-non-free rex-contrib and rex, etc.
I suppose this would be ok, but my own reasonableness trigger would jitter
less if it were something more like
rex/free
rex/non-free
rex/contrib
You end up with fewer syml
> Package: gzip
> Version: 1.2.4-11
>
> Execute these commands on the gzip file attached:
> gzip -cd a.gz
> gunzip a.gz; cat a
>
> The output of the former is clearly incorrect.
I can't seem to duplicate your problem.
> Note that
> if the output is redirected or piped then the error
> What happens is that the first page is displayed over and over again.
> The effect should be obvious if you are able to reproduce it.
Aha. Nothing like that here.
> Some more info about my system:
>
> kernel: 2.0.13
> libc5: 5.2.18-10
>
> I've tried this on a 1.2.8 machine with the same gzip
The problem appears to be that the z*grep wrappers don't handle
arguments which have multiple tokens. In other words, something like
'-i' works, but '-B 10' does not, since it can't distinguish that '10'
is part of the '-B' argument and not part of a pattern or filename. If
you can skip the spac
Package: lyx
Version: 0.10.3-1
This package installs /usr/X11R6/lib/X11/lyx/ and all child directories with
permissions 750, which prevents lyx from being able to read its own config
files at startup.
My quick hack fix was to run
find /usr/X11R6/lib/X11/lyx -type d -exec chmod 755 {} \;
In article <[EMAIL PROTECTED]> you wrote:
: BTW: Do you know anybody who really needs to put all the tools needed
: to build source packages onto floppies? :-)
Yes, I do. A friend has an older laptop that has a floppy drive, and that's
his only current path of getting bits in and out. He may
In article <[EMAIL PROTECTED]> you wrote:
> What do other think, and have you seen seeing the same runaway bug severity
> inflation I have?
Yes. Submitters seem to think that if they crank up the severity, the bug
will get more/quicker attention. At least in my case, that just isn't true.
I'm
In article <[EMAIL PROTECTED]> you wrote:
> tar -zxf control.tar.gz control ./control
You can also use
tar -zxf control.tar.gz *control
which does not produce an error, and extracts either one. This is the fix I
supplied for lintian when the tar upstream changed the way pathname whack
In article <[EMAIL PROTECTED]> you wrote:
> Bug stamp-out list for Mar 10 03:04 (CST)
> Package: dump (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
> 59935 dump: dump segfaults
A number of bugs have been fixed since the 0.4b12 snapshot that's in
In article <[EMAIL PROTECTED]> you wrote:
> Package: sawmill (debian/main).
> Maintainer: Mikolaj J. Habryn <[EMAIL PROTECTED]>
> 59760 sawmill: Sawmill fails to load -- missing file
> /usr/lib/rep/0.11/i686-pc-linux-gnu/timers.so
This is filed against version 0.25-1. The version in potato is
In article <[EMAIL PROTECTED]> you wrote:
> Package: pilot-manager (debian/main).
> Maintainer: Darren Stalder <[EMAIL PROTECTED]>
> 59202 pilot-manager: Method "GetRecord" missing in SyncPlan
The pilot-manager package is quite useful even if SyncPlan doesn't work, which
I can neither confirm n
In article <[EMAIL PROTECTED]> you wrote:
> does anybody know, wether there are ideas or plans to make
> an Debian GNU/Linux especially for embedded and/or realtime
> systems, i.e. "Embedian GNU/Linux"?
The problem is that "embedded" covers such a huge range these days. I've
built several embed
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 archi
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 m
In article <[EMAIL PROTECTED]> you wrote:
> It might be he wants to talk about -changes ? There he's right (and I do
> totally agree with him).
I'm not excited about a list per architecture, but I've often wondered if
only posting to the lists messages for uploads that include source might not
be
In article <[EMAIL PROTECTED]> you wrote:
> Package: bind (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
> 59649 bind: Gives core dump
Closed by 8.2.2p5-9, now in potato.
> Package: inn2 (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]&
In article <[EMAIL PROTECTED]> you wrote:
> I'm having some trouble, actually with a Cisco 6509 switch, but getting
> it to talk to 20 VALinux machines. My story:
Some folks at work saw similar weirdness with the negotiation on some HP
switch products, their solution was to configure the switch t
I have packaged 'pcrd', which is a utility for controlling an Icom PCR-1000
radio receiver. It is probably mostly of interest to amateur radio folk,
and so will go in the hamradio section.
The upstream site for this package is
http://www.mv.net/ipusers/cdwalker/pcrd.html
The PCR-1000 it
I've built a package of bidwatcher, which is a tool for users of eBay, that
assists in placing and monitoring bids. I don't really want to maintain the
package, though, so I'm calling for a volunteer to package this for real and
upload it. I'm happy to provide what I've done so far, but it's just
In article <[EMAIL PROTECTED]> you wrote:
> Bug stamp-out list for Mar 31 03:06 (CST)
> Package: bind (debian/main)
> Maintainer: Bdale Garbee <[EMAIL PROTECTED]>
> 61129 base: bind upgrade leaves two named's running
I see how this can happen in some odd cases.
[EMAIL PROTECTED] (Nicholas Lee) writes:
> Are there any thoughts to a chroot install option for bind?? Its not
> that hard to setup, but I wonder how it would fit into the debian
> policy.
I've been thinking about it after 9.1.0 releases, and after I add debconf
support. I don't run chroot'ed,
[EMAIL PROTECTED] (Adam Heath) writes:
> Bdale hates dbs, doesn't know what it is
I don't hate dbs. I just get annoyed when packages with complicated build-time
patching schemes won't build. My sense is that each of these schemes increases
the probability of build-time failures by deferring wor
It was just pointed out to me that there is a new RFP for bind9 packages
filed to the wnpp part of the BTS.
As the BIND package maintainer, I indicated many months ago my intention to
package BIND 9.X for Debian.
Unfortunately, the BIND 9.0.0 and 9.0.1 releases contained sources for
required
[EMAIL PROTECTED] (Brian May) writes:
> Does bind come with multiple libraries?
Yes. Four, I think.
Ok, I haven't looked at our policies for shared libs for a while, and I
obviously have some reading to do. Thanks for the warnings.
Bdale
[EMAIL PROTECTED] (Wichert Akkerman) writes:
> gzip --rsyncable, aloready implemented, ask Rusty Russell.
I have a copy of Rusty's patch, but have not applied it since I don't like
diverging Debian packages from upstream this way. Wichert, have you or Rusty
or anyone taken this up with the gzip
[EMAIL PROTECTED] (Matt Zimmerman) writes:
> As you know, it's been eons since the last upstream gzip release.
On advice of the current FSF upstream, we moved to 1.3 in November 2000.
I think it is entirely reasonable to talk to upstream about this before
contemplating forking.
Bdale
AIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: can we get rid of -I entirely, please?
> From: Bdale Garbee <[EMAIL PROTECTED]>
> Date: Mon, 08 Jan 2001 09:18:51 -0700
>
> After lots of discussion on the Debian developer mailing lists, the
> solutio
[EMAIL PROTECTED] (Roland Bauerschmidt) writes:
> Speaking of IA-64: Do we have a machine yet? AFAIK not.
Several Debian folk have acces of one kind or another to IA-64 hardware. I
am not aware of any IA-64 systems fully dedicated to Debian development.
I am in possession of an IA-64 box from H
I am unable to spend as much time updating the 'ntp' packages as they deserve,
and so I would like to find someone suitable to either join me in working on
them, or take them over outright.
There are a number of open bugs that need to be addressed, and I'm completely
unhappy with the current defa
n-devel is not high on my list right now.
> Bdale Garbee <[EMAIL PROTECTED]>
>amanda
>dump
Change made to both packages in my CVS for the next upload.
Bdale
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, 2009-12-10 at 23:59 +0100, Benjamin Drung wrote:
> Am Mittwoch, den 09.12.2009, 09:34 +0800 schrieb Paul Wise:
> > On Wed, Dec 9, 2009 at 8:07 AM, Benjamin Drung wrote:
> > > Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT:
> > >> On Mon, 2009-12-07 at 00:14 +0100, Benjamin D
Manoj,
As one of the few people around who has been part of the Debian project
as long as you have, please accept my sincere appreciation for your long
history of meaningful contributions... and in particular your lengthy
and honorable service as our secretary!
You have earned and retain my imm
> Now if only we could say positive things about people BEFORE they
> resign, wouldn't this be a better place?
+1E6
John, thank you for taking the time to write and post that note. I couldn't
agree more.
When Manoj and I joined the Debian project, there were only a couple dozen of
us, and
we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
"Vince Mulhollon" <[EMAIL PROTECTED]> writes:
> I can't participate in the debate at that time and date. Will a log of
> the debate be available via http and if so, where?
Yes, I'm sure a log of the debate will be made available online after the
eve
[EMAIL PROTECTED] (Colin Watson) writes:
> Generally speaking, Debian packages aren't relocatable anyway. Many of
> them (unavoidably) end up with paths compiled into binaries.
We may have to deal with this for things like allowing ia32 binaries to run
on ia64 systems... though so far, all of the
[EMAIL PROTECTED] (Don Armstrong) writes:
> If not, I'll just file a bug w/ patch.
That's the right thing to do for now, regardless.
Bdale
aj@azure.humbug.org.au (Anthony Towns) writes:
> On Tue, Aug 27, 2002 at 01:40:09PM +0200, Michael Meskes wrote:
> > I was just told the script updating testing doesn't run at the moment.
> > Is that true? If so, is there a reason? Are we already in freeze? :-)
>
> It's running, but it's not doin
[EMAIL PROTECTED] (Martin Schulze) writes:
>12. http://testdrive.hp.com/
Yes, this can be a good resource. I also invite anyone working on ia64
porting issues to the #debian-ia64 channel on irc.debian.org. There is very
little activity visible there, but people who can help are often lurk
[EMAIL PROTECTED] (Herbert Xu) writes:
> > kernel where all options were compiled into separate modules so simply
> > choosing the right modules constructs the optimal kernel.
>
> Guess what, that's how the current 2.4 kernel images are constructed.
Well, not really. All of the drivers and othe
[EMAIL PROTECTED] (Bas Zoetekouw) writes:
> If a package requires any binary package in order to be build from
> source, it must declare a dependency on that package.
It isn't *quite* that simple. Explicit build dependencies should only be
for packages that are neither essential nor build-
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Bdale Garbee <[EMAIL PROTECTED]> writes:
>
> > It isn't *quite* that simple. Explicit build dependencies should only be
> > for packages that are neither essential nor build-essential.
>
> But it's en
[EMAIL PROTECTED] (Rahul Jain) writes:
> maybe there should be meta-packages for packages that have embedded version
> numbers like that.
In the general case, yes. In this case, there is no need for one, since the
package in question is build-essential, and so need not be listed in a build
depen
Fellow Debian folk.
Those of us who run autobuilders have started seeing more cases of a new
class of problem showing up in our buildd email that we'd like your help
resolving.
It is possible in the Build-Depends specification of a package to give
alternatives using syntax like:
libltdl
[EMAIL PROTECTED] (Martin F Krafft) writes:
> i don't think a global solution is a good choice here. if i install
> bind9-chroot (hypothetically speaking), then bind9 should not possibly
> ever run non-chrooted again. this should be done via diversions.
Eee. Diversions are so, well, messy.
[EMAIL PROTECTED] (Wichert Akkerman) writes:
> Previously Steve Greenland wrote:
> > Stdout and stderr from the maintainer scripts. (This may be obvious, but
>> you didn't explicitly list it.)
>
> No, they should use debconf.
Regardless of whether packages are using debconf, I have wondered for *
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> But I think the point here is that the presence of a jillion normal
> bugs, unaddressed for years, constitutes a release-critical bug
While that's an interesting assertion, the real question is what it means to
"address" a bug. There are package
[EMAIL PROTECTED] (Adam Olsen) writes:
> http://lists.debian.org/debian-devel/2000/debian-devel-23/msg01353.html,
> which says there's a lintian error/warning called
> "ancient-standard-version", which I believe can detect when a debian
> package is far behind the upstream version.
Nope, it t
[EMAIL PROTECTED] (Brian Wolfe) writes:
> Actualy, I believe that the mkisofs maintainer should have seen that a
> new option was created and notified the maintainers of anything that
> depended on mkisofs ...
That's pushing it, I think. I've had several experiences as a maintainer
where somet
[EMAIL PROTECTED] (Lenart Janos) writes:
> On Sat, Dec 29, 2001 at 03:30:28PM +0100, Bas Zoetekouw wrote:
> > You wrote:
> > > As you might already have noticed Debian begun to bloat - so many
> > > unneeded, unused, unmaintained(!) packages.
> > > My opinion is that one DD alone couldn't upload N
1 - 100 of 140 matches
Mail list logo
