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 any
> 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
> 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 ob
> 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
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 main
>
> 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
>
> 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 w
>
> 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.
> 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 fou
>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
De
> 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.
> 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 t
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
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
