> I just received this from Brian. The feature of dpkg to skip certain
> directories when unpacking a .deb has been discussed already. How easy can
> this be implemented?
In fact, as part of the Deity project, I'd like to do something a little
more elaborate. I'd like to be able to remove or chan
> great. since i meet other debian developers at the linux congress, i my
> a big friend of a cvs server with all debian packages. does anyone have
> a server with enough hard disks and a good conection to run it ?
We are running cvs.debian.org over an ISDN line. Currently the only
code under it
> the list of debian packges needing a new maintainer is growing all the
> time. so - what about removeing some packages, if they are no longer
> maintained, or (better) moving them into section contrib (or a new
> section "orphaned" ?).
There is a "project/orphaned" directory where things can be
This was incorrect...
> *** ***
> *** Release of Bo is HOLDING for CRITICAL BUGS!***
> *** ***
> *** There is one remaining critical bug that must
> > In fact, as part of the Deity project, I'd like to do something a little
> > more elaborate. I'd like to be able to remove or change any arbitrary
> > path. (This was originally Behan's idea, actually.)
>
> Ok, then I'd suggest I change the proposed section in our Policy to state
> that curr
> > because CVS always wants write access to the directory (for lock files)
>
> Yep. I've seen patches for this at MIT, but I don't think they're in
> the mainline... You've also got some potentially major access control
> problems; look at what freebsd does, and consider that you *don't*
> wan
> > We are running cvs.debian.org over an ISDN line. Currently the only
> > code under it is the Deity project.
> >
> > I can make other source trees and set up other users if others want to
> > do distributed development this way.
>
> I need a shared CVS repository for boot-floppies. Especially
> Some background: In the '80s, Infocom produced a lot of excellent
> adventure games, and they published them all in portable, completely
> architecture-independant 'story files'. When you bought the game, you
> got an interpreter and a story file, (although you normally didn't know
> that). Si
> Right now, I believe we have an old version of the ITF interpreter in
> the "infocom" package. This should probably be scrapped, as it is
> highly obsolete given our current Z-machine knowledge.
I wasn't aware that the Z-machine knowledge had changed in the past
half-dozen years or so. The "in
> > E.g. boot-floppies. I regularly receive patches from the people doing
> > the ports to other architectures. If they could merge them into the
> > CVS repository, they needn't wait until I released a new version.
>
> What provision do you suggest for code-review? It's important for things
> lik
> > None of the Infocom games can be distributed, however. You have to
> > buy them.
>
> Heh. I guess that means we cant package up any of these then
>
> ftp://ftp.gmd.de/if-archive
No, but you can leave a pointer to this place in the description somewhere.
See the "apple2" package descrip
> > However now that I *have* done what I should have done two years ago
> > and familiarized myself with the license, I think that there is a
> > significant problem with the ncurses license as it stands---in that it
> > does not guarantee anyone the right to distribute modified versions.
> >
> >
> > I agree with you on this. I personally believe that Debian should relax
> > this requirement about non-modifiable & redistributable code not being
> > suitable for the primary distribution. I've never seen how it helps any
> > cause other than sticking a finger in the eye of those who might l
> > That depends on how you look at it.
> >
> > If the author does not do significant maintenence or has abandoned the
> > package then this is true.
>
> What if the author doesn't want you to do ports? We have one case of
> this already. We also have some cases of "author rudely dropped dead
> wi
> > But your promise in not the point. The author wants this promise
> > from everybody. It's the best way to be assured that improvements
> > get distributed to everyone and not just a select group.
>
> What if the author decides to not accept a change?
>
> Say the author considers the intent
> How about a description on www.debian.org on how to submit a bug report? With
> a link that will
> download software (f.e. the bug package) to make a bug easier etc etc.
Having a form that can be filled out on the web would also be a good idea.
Brian
> Do you know if they will be selling the Official 1.3.0 CD
> or the Official 1.3.1 CD with the new XFree86 3.3 release?
I would not count of X3.3 being release on 1.3.1. The X packages are
_huge_ and I doubt they will be anywhere close to completely tested by
that time.
> > What is the policy for uploads into unstable regarding libc6?
> > Must all new programs goint into unstable be linked with libc6?
>
> Since Debian 2.0 is meant to be a libc6 system, the answer is yes. Of
> course, if the libraries that the program depends on are not yet
> available for libc6,
> > I'd like to set a date after which all new uploads must be libc6. How
> > does July 31st sound?
>
> I'd like to have 2 different dates:
> - 1st deadline for libraries.
> - 2nd deadline for other packages.
>
> That could make something like:
>
> * July 15th: All libraries *must* be libc6.
>
There are some maintainers that must keep their machines on the stable
tree (and thus libc5) for various reasons.
Is there a machine somewhere these developers can log in to for the sole
purpose of building release packages?
Brian
> >Just to be clear... Are they obsolete (i.e. should be removed) or
> >are they orphaned (i.e. no longer supported)?
>
> repair was a bug-reporting script I wrote a long time ago, it never
> really achieve all the functionality intended and is probably out of
> date with respect to the modern bu
> > Do we also want to remove all libc5 dependant packages at some point? I
> > think this would be a good idea since otherwise things are going to get
> > pretty messed up. We might want to do all three immediately.
>
> * all packages should be libc6 when "hamm" is frozen. (later?)
Yes, they s
> I've had these messages before, and followed the instructions for
> stating that I no longer maintain the packages in question. But they
> still keep appearing.
These things tend to get overriden by the automated scripts.
> Can somebody *please* sort this out, and tell me that they have don
John Goerzen wrote:
>
> OK, I've sent an e-mail to that address. It's been about 24 hours
> since that time now, so let's give him a few more days to respond. In
> the mean time, let's get somebody willing to take over xemacs just in
> case. IMHO, XEmacs is the most powerful editor in our syste
> cfengine: tries to do "make distclean", but that target doesn't
> exist.
I've added a "-" in front of this call.
> gnats: diff patches file
> (gnats-3.101.orig/gnats/contrib/tkgnats/print/Description_Summary)
> whose directory does not appear in tarfile
After almost two weeks of trying, the following maintainer addresses
have bounced mail.
All of these addresses come from the "Maintainers" file under the
"indices" directory of the Debian archive. If the address in the
actual package does not match what is provided here (and thus in
the Maintaine
> Do we have a netscape 4.0 install package? I cannot connect with master
> right now so I cannot check it.
There used to bea 4.0-beta installer, but it didn't work for the later
betas, so I removed it.
Brian
( [EMAIL PROT
> > > I think it would be good to divide the "/usr/doc" directory into sub
> > > directories. It should be divided in the same as the Debian ftp site,
> > > and packages should put their documentation into the same slot as the
> > > one they got ftp'd from.
> > >
> > > The directory is very larg
> Just to let everyone know, EGCS has very recently (hours) just put out
> their first release!
>
> ftp://ftp.cygnus.com/pub/egcs/releases/egcs-1.0
>
> It contians it's own integrated libstdc++, libg++ is not supported right
> now and is obscolecent.
Interesting. I didn't think it was a Cygnu
> Brian> Morality is a touchy subject and (in my opinion) the _only_ place to
> Brian> draw this line is all or nothing.
>
> Agreed, except that clearly illegal stuff should be banned, of
> course. I doubt anyone would condone a child_pornography.deb package,
> for instance :-)
Yes, "the law" is
> > Nope, didn't seem to be flagged for install on my end. I would have
> > suggested keeping the same name and conflicting with the versions of dump
> > and quota that would have depended on the libraries.
>
> OK. I think I'll change the name back to "e2fsprogs", and just make it
> conflict w
> > Just ask and the gateway will be gone. I did this because I thought this
> > would be of benefit to the project. If you want to make Debian smaller and
> > make it difficult for people to access information about the project then
> > that is your problem.
> >
> > The gateway was set up after ap
> I've had a look at all the current packages, details are below (some
> programs are probably fine). I think most of these packages should be
> "fixed" is someway - either:
>depending on emacs|xemacs
>description includes "does not work with Xemacs"
>description includes "already inclu
> > In this case, if somebody has the knowledge to build their own 2.1 kernel
> > (since one didn't come on the CD), then they have the knowledge necessary
> > to get packages from "unstable".
>
> It's very unpleasant to have to download things whn you have just bought a
> CD. And many users are
> They work if you're using a 2.1.x kernel. Since plenty of people can be
> expected to get Debian on multi-CD sets which include kernel sources, I
> still believe we should ship them.
>
> Also, what happens when Linus finally puts out the 2.2.0 kernel? I don't
> think we're going to be making a
> > > They work if you're using a 2.1.x kernel. Since plenty of people can be
> > > expected to get Debian on multi-CD sets which include kernel sources, I
> > > still believe we should ship them.
> > >
> > > Also, what happens when Linus finally puts out the 2.2.0 kernel? I don't
> > > think we'
> > > What if THEY GOT IT OFF A CD, NOT THE NET? Yes, there are people that are
> > > going to buy CD distributions that include kernel sources, and these
> > > distributions will include 2.1.x and 2.2 when it's released. WHAT DO WE
> > > LOSE by putting support for them in hamm?
> >
> > I think
> > I understand this and it is a good point. My concern is with people
> > who are trying to install Debian and the difficulties they encounter.
> > There have been several posts lately from experienced people who tried
> > to install Debian and had it blow up in their faces. Such happenings
> > c
> > > How many of these people had problems from properly built packages?
> >
> > All of them. It was that the packages didn't work in certain situations.
>
> Were these "Extra" packages?
One was X. I don't recall off hand what the other problems were.
> > > What about people who need such su
> Brian, here in Germany, every Megabyte you have to download is costing real
> money. A lot of money. Please put as much on the CD as possible. Declare it
> extra, put it in an unstable dir, put warnings all over the place, but
> please include it.
>
> We already exclude non-free comlpetely for g
> Currently it seems to me that debian-devel is serving two unrelated
> purposes. On the one hand it is a forum for developers to pick each
> others brains, and ask opinions of interested debian users.
>
> On the other hand, it also serves to monitor the status of the frozen and
> unstable distri
> > > Also, how likely are the current versions of these programs
> > > to work with future versions of the unstable 2.1 kernel and the 2.2
> > > kernel that will eventually come from it?
>
> True enough. But a Debian 2.1.x package and packages that works with it
> could be good for seeing and try
> I intend to package the new communicator that allow free redistribution. It
> will go into non-free(no source), but at least the users won't have to
> download the tarball themselves.
That would be great! I posted a couple weeks ago asking for someone to
help with this because I don't have the
> > Just so there's no confusion: you're refering to the Netscape-branded
> > product, right?
>
> I think we should use the following nomenclature -
>
> 1. Mozilla - Sources and binaries compiled from the sources downloaded from
> http://www.mozilla.org/
>
> 2. Netscape Communicator - Binaries d
> > 2.1 kernel-requiring stuff (and a current 2.1 kernel?) can be included
> > under "contrib". This keeps it out of "main" and puts it into the realm
> > of "user-beware". (Note: This is not to insinuate that everything in
> > contrib is dangerous or anything, but just that you should think at
> > > I intend to package the new communicator that allow free redistribution.
> > > It
> > > will go into non-free(no source), but at least the users won't have to
> > > download the tarball themselves.
> >
> > That would be great! I posted a couple weeks ago asking for someone to
> > help with
There seems to be a lot of speculation about the upcoming release of Hamm.
The date "April 20th" seems to be the favorite date that is getting passed
around.
I can guarantee everyone right now that no release will be made at that
time. Because of the delays in freezing hamm and sheer lack of manp
> Marcus, I was just clarifying (once more) the status of gettext in Debian.
>
> It is in experimental because the author asked me not to distribute it
> "widely". This means that even if it is not accesable by dselect, we
> should not put it on CDs yet.
Ah. I had forgotten that.
> If a packag
> > From a logical point of view, I think project/experimental is the best
> > choice. Why don't we include selected directories from there on the official
> > CD (I think of gettext (ouch, don't beat me), 2.1.x software, ...)?
>
> Project/experimental is not part of hamm.
Yes. That's exactly my
> > Why don't we include selected directories from there on the official
> > CD (I think of gettext (ouch, don't beat me), 2.1.x software, ...)?
>
> gettext is in experimental so that it will *not* be included in CDs...
>
> If we start putting experimental things in CDs, then we should create
> a
> > Another thing to note... Dpkg won't let you build part of a package or
> > assign different version numbers to different .deb files created from
> > the same source. (At least, I've never been able to get it to do so.)
>
> Will this be nescessary? The libc5 thing is only temporary, and I do
> >> Another thing to note... Dpkg won't let you build part of a package or
> >> assign different version numbers to different .deb files created from
> >> the same source. (At least, I've never been able to get it to do so.)
>
> You certainly can do that, check out bash/libreadline for instance
> > So, when will Hamm be released? You decide. It's up to the devolpers
> > to set the date by fixing the problems that are currently holding up
> > the release. As soon as the last release-necessary bug gets closed or
> > downgraded, we'll probably be ready to ship.
>
> Brian: I would like to
> > So, when will Hamm be released? You decide. It's up to the devolpers
> > to set the date by fixing the problems that are currently holding up
> > the release. As soon as the last release-necessary bug gets closed or
> > downgraded, we'll probably be ready to ship.
>
> Can I propose the foll
This message is to inform everyone that Christian Hudon <[EMAIL PROTECTED]>
will be taking over the management of the "stable" Debian release. He will
be responsible for deciding which packages are worthy of "stable" and when
to make a new "point" release.
I think Christian is well suited for the
> > > Make it harder! From now on no new upstream versions to frozen. Cleaning
> > > Incoming. 1. May is 'early beta' and 1. June is release time (to have some
> > > more time for arch maintainers and testers).
> >
> > Please let's not delay it that long if we can prevent it. I would
> > very much
> Brian, this is a useful list, but please sort it by Maintainer or by Package
> rather than by bug number:
Several people have asked for this, but maintainers already get separate
reports about their packages and reports by package are available on
the web site, so I don't really understand the u
> > > > Several people have asked for this, but maintainers already get separate
> > > > reports about their packages and reports by package are available on
> > > > the web site, so I don't really understand the usefulness of presenting
> > > > it that way here. Is there something I'm missing?
>
> > The message is intended to inform _others_ of the problems that exists
> > in order to encourage them to help solve those problems. When people
> > whine about "When is Hamm going to be released?" I can just point them
> > to this weekly message and ask them what they've done to help.
>
> So t
> Brian, are you listening ?
Yes. I get my reports directly from the bug system so if it gets updated
there my reports will reflect that.
Brian
( [EMAIL PROTECTED] )
--
> > *** ***
> > *** Release of Bo is HOLDING for CRITICAL BUGS!***
> > *** ***
> > *** There is one remaining critical bug that must be resolved be
> I was looking at Ian Jackson's automated report of unanswered bugs, and
> the number of -very- old bugs is surprising. Closer examination of the
> oldest ones makes me think that the problem isn't so much the bugs but
> bad handling.
Reminders about bugs older than a certain age (currently abou
> Why is this information (about the need to upgrade dpkg
> *first*) not screaming out all over the web pages and the
> installation README's? (pardon me if the information is in the
> README's)
Perhaps dselect just needs to always update dpkg before calling
anything else? (dftp does t
Is there anybody here using the Sangoma WANPIPE cards to do X.25?
Brian
( [EMAIL PROTECTED] )
---
When you love someone, you're always insecure.
What do I have to do to fix this problem? My key is valid, has been
signed, and was uploaded to the keyserver via "gpg --send-keys".
Why do I continue to get these messages? The only way I can upload
packages is to use SSH to connect to ftp-master and then use wget
to fetch the various files fro
> * Brian White <[EMAIL PROTECTED]> [2003-09-20 07:37]:
> > Neither SCP nor anonymous-FTP methods work and I want to get that
> > fixed.
> >
> > SSH works. SCP doesn't.
>
> Well, it works for everyone else. So it would be good if you'd find
&g
> The queue daemon can no longer handle PGP 2.x keys; I don't know why
> and since a) the number of developers still using these kind of keys
> for uploads can be counted on the fingers of a mutilated hand, b)
> there are alternative methods of uploads available to the few who do,
> c) queued is in
> > SCP doesn't work (I suspect) because I'm using the "SSH2" package once
> > found in non-free.
>
> Oh, ssh2 is broken, yes. Try 'scp -1', perhaps?
I don't keep ssh1 installed for security reasons.
> > I mentioned this (and the reasons why) some time back.
>
> Care to reiterate? I can't re
> Brian White <[EMAIL PROTECTED]> wrote:
> [...]
> > I've avoided changing to OpenSSH at home because I'm unsure how to
> > convert the keys from the SSH2 format to the OpenSSH format.
> [...]
>
> Afaict ssh-keygen from OpenSSH can do that:
> -i
Why is the symlink provided? Where is the definition of the
ups-monitor virtual package written down? What is using this symlink?
I assume a good solution should take into account the answers to these
questions. :)
It's there to be called by various parts of "init", though right now I
think o
That seems a reasonable plan to me. I've orphaned the mime-support
package, however, because I have no time to work on it right now and do not
expect to have any for the foreseeable future.
-- Brian
On Fri, Jul 13, 2012 at 8:26 PM, Vincent Bernat wrote:
> ❦ 13 juillet 2012 12:18 CEST, Per Olo
43 AM, Charles Plessy wrote:
> Le Fri, Jul 13, 2012 at 10:12:34PM +0200, Brian White a écrit :
> > That seems a reasonable plan to me. I've orphaned the mime-support
> > package, however, because I have no time to work on it right now and do
> not
> > expect to have any fo
>
> Lastly, I would like to thank Brian for his impressively 16-years long
> work on
> mime-support. Brian, feel free to stay among the uploaders !
>
Thanks. I wish I had the energy to make some of the much-needed changes
but I'm just not involved with the project enough these days to have a goo
Hmmm... You're a little behind the times here.
> > hwtools 21288 hwtools: irqtune should be in /usr/sbin, or
> > rc.boot script fixed [34] (Siggy Brentrup <[EMAIL PROTECTED]>)
>
> Uhh, remove that package, and dozens of my machines go down or perform
> very slowly. Please don't.
I've heard that somebody is packaging "twin". Does anybody know who?
Brian
( [EMAIL PROTECTED] )
---
Generated by Signify v1.04. For this and m
> > Can anyone think of an automated way to weed out bug reports on versions
> > which haven't been released into hamm from the release-critical list? A
> > quick fix would be to modify the priority of the bug report, but that
> > would be The Wrong Thing.
>
> Automating this would be wrong, I thi
> Bug #22325, marked important, says that my package guavac has an
> unsatisfied suggestion on java-virtual-machine. I need your
> advice on what to do about it.
>
> My thoughts are:
>
> 1. It's a suggestion only, so nothing will break if it doesn't exist.
>Unfortunately dselect is a bit pick
> > The following bug reports *must* be fixed before the current frozen Debian
> > distribution can progress further in its development cycle. Reminders have
> > been sent to the maintainers of these packages yet nothing has been done to
> ^
> Debian 2 ships with Gimp 1 take that redhat :-)
That's assuming that we can get Hamm ready and ship it before RedHat's _next_
release.
Brian
( [EMAIL PROTECTED] )
--
severity 23000 normal
--
> The reason that sendmail broke is that you made a DELIBERATE modification
> to procmail that sendmail wasn't expecting. While I agree that sendmail
> should probably be more graceful about handling it, it is not a
> release-critical error. A vast majority of people (li
There is a bug against dhcp-client-beta that is causing it to be removed
from Hamm. Should all "dhcp-beta" packages be removed or is omitting just
this one okay? I need to know asap. Thanks.
Brian
( [EMAIL PROTECTED] )
> > I was told that dselect has problems with hamm being distributed on
> > more than one cd rom. Ian Jackson suggested that we should take a
> > look at dpkg-mountable. This means that a) dpkg-mountable might need
> > to be included in the boot floppies and b) we'll need at least one another
> >
> Thanks. From looking at your log, as I expected, the problem occurs
> when you try to install emacs20 and cvs-pcl simultaneously. This is
> because elib is not being properly "configured" (by the emacsen-common
> script) before cvs-pcl. This is a bug, but I'm worried about having
> time to fix
> > 1) Don't we have to recompile all our ncurses-based apps against 4.2?
>
> If we want all the ncurses-based apps to use the same version of ncurses,
> yes. I'm not sure if we have to, though if I were the release manager, I
> wouldn't release 2.1 before all ncurses-based apps used the same vers
> Does this mean also "no new documentation"?
No.
> For slink, I plan to provide the texi2html-converted HTML for all my GNU
> packages, which means a new package foo-doc for every GNU foo package.
> Do I absolutely have to do this before the freeze? Will all my foo-doc
> packages be rejected be
> > I suspect that it's in the best interest of the freeze to revert to Perl
>
> Thanks.
>
> > 5.004. I'm currently uploading the 5.004.04-6 release to master's
> > Incoming. I'll file a bug on ftp.debian.org that the 5.005 release
> > should be deleted and the 5.004 release installed.
>
> May
Could I get some official word on which architectures wish to be included
in the 2.1 release of Debian? Thanks!
Brian
( [EMAIL PROTECTED] )
---
> > Could I get some official word on which architectures wish to be included
> > in the 2.1 release of Debian? Thanks!
>
> So far, Alpha is looking "near" ready and we are shooting to release with
> slink/i386. A caveat, however, is that we need to resolve some big egcs
> issues SOON or else we
67 dhcp-client-beta has no /usr/doc directory [211]
(Rich Sahlender <[EMAIL PROTECTED]>)
freetype2-dev 27814 freetype2-dev: should not conflict with freetype1 [0]
(Anthony Fok <[EMAIL PROTECTED]>)
gnome-gnothello 27405 gnome-gnothello doesn't run here [10] (James
Lewis
> > perl 27604 Perl @INC needs /usr/lib/perl5 [7] (Darren
> > Stalder <[EMAIL PROTECTED]>)
> > perl 27738 perl: @INC does not contain /usr/lib/perl5 [0]
> > (Darren Stalder <[EMAIL PROTECTED]>)
>
> This doesn't affect the current perl version but the version to be
>
All packages destined for Slink must have been uploaded to master.debian.org's
incoming directory no later than October 16th, 18:30 GMT.
The process of freezing Hamm will take place over the weekend. No new
uploads will be processed after 18:30 GMT that day.
> > > Could I get some official word on which architectures wish to be included
> > > in the 2.1 release of Debian? Thanks!
> >
> > PowerPC has more or less given up on making 2.1. We're moving well,
> > but I'm of the inclination we shouldn't release until we have a truly
> > stabilized libc - o
> > All packages destined for Slink must have been uploaded to
> > master.debian.org's
> > incoming directory no later than October 16th, 18:30 GMT.
> >
> > The process of freezing Hamm will take place over the weekend. No new
> > uploads will be processed after 18:30 GMT that day.
>
> Due to wor
> > > We need a 2.1.x kernel source package, which isn't available for debian.
> >
> > I don't see why you couldn't create one just for the powerpc arch. Either
> > way, v2.2 of the kernel should be available before v2.2 of Debian.
>
> Yes, last rumors say that linux-2.2 came out short before chr
> What do you think we should do with the Gnome stuff?
>
> The Gnome 0.30 stuff is still under rather heavy development. The
> current packages in Slink are pretty much alpha-quality. Lots of
> things don't work. It sounds like there will probably be a 1.0
> release coming up in a few months th
> smb2www 27641 perl 5.005-02 breaks smb2www [0] (Craig Small
> <[EMAIL PROTECTED]>)
>
> This one also refers to the version of perl which has been
> removed. (It broke every module, so there are several such bug reports)
I knew about it, but not which bugs it affected. I'll
> > So far, Alpha is looking "near" ready and we are shooting to release with
> > slink/i386. A caveat, however, is that we need to resolve some big egcs
> > issues SOON or else we can't release (as is, 1.1b will not compile two or
> > three vital packages correctly).
>
> There is one, MAJOR, hug
> > > Oh, i can generate a kernel-image_2.1.125-1_powerpc.deb along with source
> > > and dsc files and upload it to master, but will you and the other arch
> > > maintainer agree with this??
> >
> > If it's a powerpc package only, I don't see why there would be a problem.
> > It should get install
> On Wed, Oct 14, 1998 at 12:19:30PM -0400, Brian White wrote:
> > strace26065 strace confused about sigaction flags [51]
> > (Wichert Akkerman <[EMAIL PROTECTED]>)
>
> Hmm. Why is this bug important anyway? I've looked at the bug report and
&
tp://www.debian.org/Bugs/
The official release date is yet unset, but with luck it can be as
early as the end of January. More likely, though, is mid-February.
Brian White <[EMAIL PROTECTED]>
Debian Release Manager
1 - 100 of 120 matches
Mail list logo
