|
|
Subject: Re: Unidentified subject! - msg#00090
List: debian.devel.project
Kabayan Kengkoy wrote:
> /pub/linux/debian/dists/potato/main/binary-all/devel/deb
>
> is not downloadable
Of course not. What makes you think it should be?
In my local mirror:
home:/debian/dists/potato/main/binary-all$ ls
admin devel editors interpreters math net sound text x11
base doc games libs misc shells tex utils
and they are all directories.
--
To UNSUBSCRIBE, email to debian-project-request@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Was this page helpful?
Thread at a glance:
Previous Message by Date:
click to view message preview
Re: Fwd: Is it possible to unsubscribe from the debian-userslist?
Hmm. That's interesting. I recently unsubscribed from many
mailinglists, following the instructions at the bottom
of each email, and automated replys were immediately sent
to me.
On Thu, 2002-05-09 at 17:53, Siward de Groot wrote:
> On wednesday Bill Stoye wrote:
>
> > Thank you for your help; I finally got off the list.
>
> so it turns out that it is possible,
> albeit after a delay of 2 weeks.
>
> I think it is not-nice and unnecessary to keep users uninformed of the
> situation.
> As it is now, they find that unsubscribing doesnt work and listmaster
> doesnt respond,
> until that happy day 2 weeks later.
> This seems weird for an organization that claims that the users are
> their first priority.
>
> If the problem is in the process of being solved,
> it would be nice to receive an estimate of when this will be from
> listmaster(s).
> (preferably in the form of a daily post to d-u, so everybody knows
> about it).
>
> As long as it is not solved, it is good manners to put a notice on the
> subscription webpage
> saying "it may take a couple of weeks before an unsubscription request
> is processed".
> I hereby request you to put such a notice on said webpage.
>
> Out of curiosity i would like to know whether anybody offered help to
> listmasters
> or are they just considered 'external to debian so fuck them' ?
> With all the programming talents in Debian an usubscription script
> shouldnt be hard to get right.
>
> i hope this will make Debian even better than it already is.
>
> have fun !
>
> Siward
>
>
> --
> To UNSUBSCRIBE, email to debian-user-request@xxxxxxxxxxxxxxxx
> with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
>
--
+------------------------------------------------------------+
| Ron Johnson, Jr. Home: ron.l.johnson@xxxxxxx |
| Jefferson, LA USA http://ronandheather.dhs.org:81 |
| |
| You ask us the same question every day, and we give you |
| the same answer every day. Someday, we hope that you will |
| believe us... |
| Donald Rumsfeld, to a reporter |
+------------------------------------------------------------+
--
To UNSUBSCRIBE, email to debian-project-request@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Next Message by Date:
click to view message preview
Re: Working on debian developer's reference and "best packaging practices"
-project Bcc'ed only.
On Thu, May 09, 2002 at 11:17:28PM +0100, Julian Gilbey wrote:
> On Fri, May 10, 2002 at 04:02:47AM +1000, Anthony Towns wrote:
> > On Mon, May 06, 2002 at 06:19:54PM +0100, Julian Gilbey wrote:
> > > > > Then each section could either have the structure:
> > > > > or we could merge them, and have policy dictates all in the form MUST,
> > > > > SHOULD, MAY, MUST NOT, etc., as in the RFCs.
> > > > I'm quite confident that trying to differentiate between requirements
> > > > and guidelines like this will turn out to be completely unhelpful and
> > > > a large waste of time, personally.
> > > Don't RFCs do this frequently? And I've never heard people making
> > > such a complaint about them.
> > RFCs have a different goal to -policy. RFCs specify things that get
> > implemented by different groups and have to be interoperable. -policy
> > doesn't.
> > There is only one "dpkg", [...]
> Who's talking about dpkg here?
Manoj, for one:
] [...] The policy group shall never propose additions to
] dpkg functionality, the way the section shalll be formulated. What
] shall be in the section is what the maintainers _must_ have in order
] for their packages to be built. This is the core interface that dpkg
] already presents [...]
> Policy covers far more than that.
Actually it covers different things than that, which is my whole point.
The RFC-style M/S/M remarks are just tangential.
> For
> example, when talking about shared and static libraries, there may be
> exceptional cases where both the shared library and the development
> parts (headers and static library) live in the same package. Then one
> would say something like "Source packages providing shared libraries
> SHOULD produce a binary package containing the shared library and
> another binary package containing the development files (headers and
> statically compiled library). The shared library MUST be compiled
> with the -fPIC option and the static library MUST NOT be compiled with
> this option. ..." (Please don't correct me on details here -- I
> haven't checked them up and that's not the point.)
Which is to say that if I demonstrate that your "MUST" or "MUST NOT"
could happen to have exceptions, that you're not going to listen, and
thus I've got no way of usefully demonstrating my point, which is that
almost every "MUST" you might choose will have some sort of exception,
and thus should be a SHOULD.
In the above, for example, the xlibs-pic package provides static libraries
that are compiled with -fPIC, making your MUST NOT inappropriate.
> So here, the "SHOULD" means that it must behave in this way unless
> there are exceptional circumstances, and the "MUST" means that there
> are no exceptions. I may be wrong in the details of this specific
> case, but this is the way I am thinking.
I completely understand the distinction you're trying to make, I just
think you'll find that there aren't many situations where "MUST" is
appropriate, and that there aren't any where it's particularly useful.
Cheers,
aj
--
Anthony Towns <aj@xxxxxxxxxxxxx> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
pgp1koUPok2sN.pgp
Description: PGP signature
Previous Message by Thread:
click to view message preview
Unidentified subject!
/pub/linux/debian/dists/potato/main/binary-all/devel/deb
is not downloadable
--
To UNSUBSCRIBE, email to debian-project-request@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Next Message by Thread:
click to view message preview
Re: Fwd: Is it possible to unsubscribe from the debian-userslist?
On wednesday Bill Stoye wrote:
> Thank you for your help; I finally got off the list.
so it turns out that it is possible,
albeit after a delay of 2 weeks.
I think it is not-nice and unnecessary to keep users uninformed of the
situation.
As it is now, they find that unsubscribing doesnt work and listmaster
doesnt respond,
until that happy day 2 weeks later.
This seems weird for an organization that claims that the users are
their first priority.
If the problem is in the process of being solved,
it would be nice to receive an estimate of when this will be from
listmaster(s).
(preferably in the form of a daily post to d-u, so everybody knows
about it).
As long as it is not solved, it is good manners to put a notice on the
subscription webpage
saying "it may take a couple of weeks before an unsubscription request
is processed".
I hereby request you to put such a notice on said webpage.
Out of curiosity i would like to know whether anybody offered help to
listmasters
or are they just considered 'external to debian so fuck them' ?
With all the programming talents in Debian an usubscription script
shouldnt be hard to get right.
i hope this will make Debian even better than it already is.
have fun !
Siward
--
To UNSUBSCRIBE, email to debian-project-request@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
|
|