>
> 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
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
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
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
> 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
> > 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
> 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
> * 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
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
Is there anybody here using the Sangoma WANPIPE cards to do X.25?
Brian
( [EMAIL PROTECTED] )
---
When you love someone, you're always insecure.
> > Hmmm... If things were installed by hand ("dpkg --install dpkglib...")
> > or if install were to fail between the two packages, then you could have
> > a problem where the install tool doesn't function, right?
>
> Right. But since libdpkg is still a part of the dpkg package we
> shouldn't nee
> > > Previously Brian White wrote:
> > > > apache32204 user directories allow symlinks to other files
> > > > [0] (Johnie Ingram <[EMAIL PROTECTED]>)
> > >
> > > We should just force SymLinksIfOwnerMatch for /home to solve
> > You know, I don't see this as "grave". It means that a user can
> > effectively "export to the world" any file readable by www-data. In
> > general, this means only things that can be read by public. So,
> > the user can't intentionally export anything that he/she couldn't already
> > do by
> Previously Brian White wrote:
> > apache32204 user directories allow symlinks to other files [0]
> > (Johnie Ingram <[EMAIL PROTECTED]>)
>
> We should just force SymLinksIfOwnerMatch for /home to solve this.
You know, I don't see this as &q
> > To do so would indicate that Slink officially supports v2.2 of the kernel,
> > which it does not.
>
> What about a README file that says: No, Debian doesn't officially
> support 2.2, but for those people who hadn't enough bandwidth but
> enough courage here are the sources.
I don't mind so muc
> > We do not officially support the 2.2 kernel in Slink. People who want to
> > use 2.2 will have to compile it themselves and may have to upgrade some
> > packages.
> But what about shipping an extra directory support_2.2 which
> contains the kernel packages and the necessary utilities together
> > Ok, so if we really want a Debian 2.1 that is 100% kernel 2.2.x
> > compatible it needs this package to be included in frozen.
> > I've just uploaded it in Incoming/ 10 minutes ago.
> > Non-developers can also access it at http://www.ldsol.com/~vincent/
> > (NB: there are _2_ binary packages to
> In my more than honest opinion, I think util-linux 2.9g should be included
> in slink. Developments in the computer business are going fast, as everyone
> knows, and on the day slink will get released, I think a lot of people who
> are going to upgrade to slink, also want to have the newest kerne
> > Disclamers are of marginal use. It will appear as installable and tell
> > people to "install me" just as an elevator buttun tells people "push me".
>
> Installing a kernel 2.2 source package just dumps a tar file in /usr/src. I
> don't see how this could break a system. Actually building and
> > > > Including the source package I could be convinced of. At least then
> > > > people have to think about what they're doing before causing potential
> > > > problems.
> > >
> > > This "think about what they are doing" thing is precisely one of the
> > > reasons the "extra" priority does exis
> > Including the source package I could be convinced of. At least then
> > people have to think about what they're doing before causing potential
> > problems.
>
> This "think about what they are doing" thing is precisely one of the
> reasons the "extra" priority does exist.
>
> According to th
> > > There is precedent for this as there is a 2.1.125 package in slink now.
> > > I think it's not a big deal if there are big disclaimers attached that
> > > slink is not a 2.2 targetted dist.
> >
> > Disclamers are of marginal use. It will appear as installable and tell
> > people to "install
> Brian> make any difference. Both will show up in dselect and it would
> Brian> be trivial for someone to install the new kernel... and then
>
> Heh, thats the idea. :-)
>
> Brian> wonder why things don't work.
>
> Little things that few notice, apparently -- I would've sworn slink
> and 2.2.
> > Would anyone object if kernel 2.2 were packaged up at least as a
> > kernel-source package for slink? 2.0.3x would remain slink's default kernel,
> > would be used on the boot disks, etc, but this would let people get ahold of
> > kernel 2.2 easily on a debian cdrom, and it would let us say tha
> > No. We had enough problems upgrading from 2.0.35 to 2.0.36. This would
> > be a major change and have corresponding reprocussions. I'm sure it's
> > very stable, but it will have incompatibilities.
>
> No-one's saying this would be the default kernel. I think including a kernel
> image woul
> On Thu, Jan 21, 1999 at 12:34:57PM -0800, Joey Hess wrote:
> > Would anyone object if kernel 2.2 were packaged up at least as a
> > kernel-source package for slink? 2.0.3x would remain slink's default kernel,
>
> I'de really like to see a kernel-image too, atleast for the non-i386 ports
> to use
> Would anyone object if kernel 2.2 were packaged up at least as a
> kernel-source package for slink? 2.0.3x would remain slink's default kernel,
> would be used on the boot disks, etc, but this would let people get ahold of
> kernel 2.2 easily on a debian cdrom, and it would let us say that debian
> > dpkg 17624 dpkg: installs regular dir when .deb contains
> > symlink !
> > 21182 dpkg: dpkg can go into an infinite loop with
> > --force-configure-any
> > 28519 dpkg: dpkg creates circular symlinks
> > 28817 dpkg takes no
> >Debian v2.1 ("Slink") Deep Freeze
> >
> > After considerable delay, Slink is almost ready for release. As such, it
> > will go into the "deep freeze" on Wednesday, January 20th.
>
> Brian, will you please consider to do a ftp.debian.org bug hunting *before*
> doing any deep
> > After considerable delay, Slink is almost ready for release. As such, it
> > will go into the "deep freeze" on Wednesday, January 20th. New uploads
> > will be _greatly_ restricted. Also, the following packages will be
> > removed because of release-critical bugs still open against them:
>
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
> 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
&
> > > 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
> > 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
> 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
> 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
> > > 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
> > 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
> > > 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.
> > 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
>
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
> > 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
Could I get some official word on which architectures wish to be included
in the 2.1 release of Debian? Thanks!
Brian
( [EMAIL PROTECTED] )
---
> > 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
> 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
> > 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
> 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
> > 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
> >
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] )
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
> 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] )
--
> > 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
> ^
> 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
> > 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
I've heard that somebody is packaging "twin". Does anybody know who?
Brian
( [EMAIL PROTECTED] )
---
Generated by Signify v1.04. For this and m
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.
> 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] )
--
> > 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
> > > > 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?
>
> 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
> > > 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
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
> > 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
> > 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
> >> 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
> > 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
> > 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
> > 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
> 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
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
> > > 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
> > 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
> > 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
> 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
> > > 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
> 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
> 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
> > > 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
> > 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
> > > 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
> > > 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'
> 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
> > 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
> 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
> > 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
> > 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
> 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
> 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
> > > 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
> 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
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
> 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
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
> 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
> > 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
> >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
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
> > 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.
>
> > 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,
1 - 100 of 120 matches
Mail list logo
