Is there a scheduled time to see the
compromised servers up again?
sincerely.
Debian is caching debs rather than targzs. What i got from here,
if the argument is on deciding on whether project shold cache-old
the source code tarballs rather then binaries - i got debs from here
as binary , because i did not come accross other binaries cached in
the system - , I cannot see
However, I think it's unacceptable to expect an applicant stay in
limbo without any update as to the process of their application. I'm
quite happy to wait for a long time, as long as I know that something is
happening, albit slowly.
While I was reading that, I would like to say here,
For
On [06/08/03 17:29], Halil Demirezen wrote:
What I would like to point out here is, totally over the world claims
that debian is being obsolete. New releases are so slow. Yes they are
Why do you you think that over the world Debian is being obsolete?
Do you have some evidence or proof
Incidentally, the entire NM system seems geared toward package
maintainers only, if you read the web pages. (That was not
particularly encouraging.)
It seems in that way. However, AM asks you what to do in Debian.
When you choose a specific section, You are not supposed to know
that issue.
I am currently on NM process. And as far as I know, there have been
totally over 700 developer of Debian officially.
What I would like to point out here is, totally over the world claims
that debian is being obsolete. New releases are so slow. Yes they are
partially right. However, with 700
You checked too long ago. Casals.debian.org is an SGI Indigo2, MIPS
R4000 CPU.
Williams.debian.org and vaughan.debian.org will be MIPSel boxes, as soon
as Sun ships them to me, I get them online, and the sysadmin team gets
them configured. Supposedly I'll have the boxes within a week or
I do not know whether there is, but, what about making a architecture
archive for debian package managers to use, test, update their packages
maintainers..
pgpc9w36PWV3K.pgp
Description: PGP signature
some useless architecture like arm or m68k
Are we in dilemma on should we support arch that are not used widely? or
We should support all architectures
what i prefer is the second one.
an arch if nobody is interested in doing the work?
do you mean someone who is interested in the maintanence of these
architectures?
Did I get wrong? I so, Lets think that We quit support for those architectures.
Debian
will be unaware of them. Portability?
sincerely
pgp0UNNYoRrSG.pgp
So, are you volunteering to help those of us without access to either of
the above architectures with bugs found in our packages? I'm not
saying that all architectures shouldn't be supported equally. I just
don't have access to either of the above architectures to correct
problems found in
And in the past months some packages (among them mutt, which even fixed a
For example, I came accross a segfault with micq. However, I could not find
the reason for this bug. Why i pointed out this is that there may be a probable
bug there.
sincerely.
i added
deb http://http.us.debian.org/debian unstable main contrib non-free
to sources.list
however, after i got updated, i got such an error. Is it because of my
utility's version or
a general problem?
E: Dynamic MMap ran out of room
E: Error occured while processing python2.2-imaging-tk
Why is it a bug for the compilation of a program to depend on one of the many
script interpreters in Debian?
If the upstream authors want to write shell code that can only be interpreted
by tcsh in their build scripts then it shouldn't be a bug in the Debian
package as long as the tcsh
Hi,
As writing a network based program, does debian forces i should use standard
structures in headers files? for example:
struct iphdr
i can construct this structure my own. However, does debian want to see there
__standard__
structures in .deb packages?
sincerely.
--halil
15 matches
Mail list logo
