so over time you don't remove binary packages for older releases from
archive.debian.org? and it turns out that you can use archive.debian.org and
snapshot.debian.org
On Wed, 04 Jan 2023 16:24:56 +, Andrew M.A. Cater wrote:
> On Wed, Jan 04, 2023 at 02:45:51PM +0200, to...@ukr.net wrote:
> > Hi! I'm interested in a question about the archive/old versions. The site
> > https://www.debian.org/distrib/archive.en.html states that ove
On Wed, Jan 04, 2023 at 04:24:56PM +, Andrew M.A. Cater wrote:
> On Wed, Jan 04, 2023 at 02:45:51PM +0200, to...@ukr.net wrote:
> > Hi! I'm interested in a question about the archive/old versions [...]
[...]
> This does make it hard if you come across an old machine
On Wed, Jan 04, 2023 at 02:45:51PM +0200, to...@ukr.net wrote:
> Hi! I'm interested in a question about the archive/old versions. The site
> https://www.debian.org/distrib/archive.en.html states that over time you stop
> keeping binary packages for older versions. Please tell me,
Hi! I'm interested in a question about the archive/old versions. The site
https://www.debian.org/distrib/archive.en.html states that over time you stop
keeping binary packages for older versions. Please tell me, over time, you
remove binary packages from archive? Please give me the answers!
On Mon, Feb 25, 2019 at 12:58:50AM -0800, npdflr wrote:
> I have gone through the link: (Exploring Cryptographic Software in
> Debian's Main Archive) https://www.debian.org/legal/cryptoinmain
>
> I would like to clarify what I have understood: one is not allowed to
> use D
On 15324 March 1977, npd...@zoho.com wrote:
I have gone through the link: (Exploring Cryptographic Software in
Debian's Main Archive) https://www.debian.org/legal/cryptoinmain
I would like to clarify what I have understood: one is not allowed to
use Debian's main archive for comm
Hi,
I have gone through the link: (Exploring Cryptographic Software in Debian's
Main Archive) https://www.debian.org/legal/cryptoinmain
I would like to clarify what I have understood: one is not allowed to use
Debian's main archive for commercial use (as it contains community
On Fri, Nov 30, 2018 at 5:48 AM Bill Chapman wrote:
> I’m trying to search for an archived package at this URL but the link is
> broken:
> https://historical.packages.debian.org/squeeze/
This website has not yet been fully setup yet so it isn't surprising
that it is broken.
> Can you tell me if
On Thu, Nov 29, 2018 at 09:19:14PM +, Chapman, Bill [US] (MS) wrote:
> I'm trying to search for an archived package at this URL but the link
> is broken: https://historical.packages.debian.org/squeeze/
The error seems to be
Not Found
The requested URL /cgi-bin/dispatcher.fcgi/squeez
I'm trying to search for an archived package at this URL but the link is
broken: https://historical.packages.debian.org/squeeze/
Can you tell me if this will be fixed or is off line permanently.
Thanks,
Bill Chapman
This is a test mailing, to check if the address
archive@mail-archive.comO_ADDRESS%
causes bounces, tries to challenge-response or autoresponds
back to Mailinglists, or Mailinglist-Senders.
If you get an unsubscription message afterwards, one of the above
problems has been confirmed.
Fix the
Hi Aurelien,
I noticed today when I went to run `apt-mirror`, that my apt-get
update started to complain about some keys:
W: GPG error: file: lenny/updates Release: The following signatures
were invalid: BADSIG 9AA38DCD55BE302B Debian Archive Automatic Signing
K
ey (5.0/lenny)
W: You may want
half has an Internet
Access of less then 1 MBit. Now, this will change.
Also most of you know, that I am Debian User since more hen 10 years and
Linux Developer.
I am running my own Debian Mirrors and I had a very huge Archive mirror
of 21 TByte which was gone down for some time...
Now I am
ther
words, "We keep the right to kick *any* recruit for whatever reason."
Note that I'm not saying the archive team *intended* to express that.
This is one way the caveat could be understood.
Pretending that there exists this limitless pool of people who want to do
really tedio
* Joerg Jaspert <[EMAIL PROTECTED]> [080806 20:48]:
> currently our archive has the feature(?) that a source package in component a
> (like main) can build a binary package in component b (like contrib).[1]
>
> Now, this feature is blocking (or making it way harder) to do
Charles Plessy <[EMAIL PROTECTED]> writes:
> In the end, the contrib category is free software
The works in 'contrib' are free software. That's not enough for them
to be in 'main', because 'main' is defined as more than just an
arbitrary collection of free software. 'main' is the Debian operating
; This would solve the problem for our puzzled users as well as for the
> developpers packaging software that is partially dependant on things not
> available in the main archive, and the consistency of the Debian
> operating system would be:
> - guaranteed for packages of priority opt
o why not simply
downgrade it as a priority level, lower than "extra"? This would solve
the problem for our puzzled users as well as for the developpers
packaging software that is partially dependant on things not available
in the main archive, and the consistency of the Debian operat
On Thu, Aug 07, 2008 at 01:28:49AM +0100, Adeodato Simó wrote:
> I do think that allowing packages in main to provide binaries in contrib
> is useful, so I'd like to hear what the benefits would be if we'd agree
> to lose it.
I have no idea if there are technical benefits in dropping the support
f
* Julien Cristau [Wed, 06 Aug 2008 21:38:00 +0200]:
> On Wed, Aug 6, 2008 at 20:47:50 +0200, Joerg Jaspert wrote:
> > Now, the idea would be to deprecate this feature, used by 8 packages in
> > unstable, dropping complications in the database backend and the pool
> > layout which we would want t
On Wed, Aug 06, 2008 at 08:47:50PM +0200, Joerg Jaspert wrote:
>
> But before we take a final decision I want to hear more input on it. So
> here are your 5 seconds, please give input. :)
To me, this sounds like a step in the right direction to unfuzzy the
distinction between Debian itself (main)
ave a new (additional, maybe
> stripped to be smaller) source tarball for the one package in the other
> component. Well. 8 of them. A very tiny set compared to the whole
> archive, and the question is there if that really means we have to keep
> it.
I have no opinion one way or the other
On Wed, Aug 6, 2008 at 20:47:50 +0200, Joerg Jaspert wrote:
> Now, the idea would be to deprecate this feature, used by 8 packages in
> unstable, dropping complications in the database backend and the pool
> layout which we would want to avoid.
>
Maybe you could tell us what the benefit of dropp
Hi
currently our archive has the feature(?) that a source package in component a
(like main) can build a binary package in component b (like contrib).[1]
Now, this feature is blocking (or making it way harder) to do some
database re-designs we want to do for the central archive database, so
we
Hello Raphael,
Raphael Geissert wrote:
> I know this won't help dealing with already received spam and such, but it
> may help reduce the amount of spam received in the future.
Reducing the amount of spam is good. However, when I wrote
>> Also note that all this is about the ar
Raphael Geissert <[EMAIL PROTECTED]> wrote:
> I administer some servers with customers and these are some of the facts
> I've found:
> * Many spam emails do not comply with the specs
>Meaning: enforcing the RFC's when receiving emails could block some spam
I agree entirely. Also, Exim's acl's
Hello Thomas
Thomas Viehmann wrote:
>
> Maybe we could start with debian-project at the present and go back in
> time from there until we get bored, but I'm open to suggestions.
I administer some servers with customers and these are some of the facts
I've found:
* Many spam emails do not comply
Le Wed, Nov 14, 2007 at 11:50:02AM -0600, Manoj Srivastava a écrit :
> The Unsure would be manually inspected, and used to further
> train the filters; as well as any erroneous classification
> (TOE). Periodically, we TUNE (Train Until No Error) the Corpus.
Maybe another heuristic to tri
-- and then send back the message
>> ID's of Ham and Spam back to Debian.
> There is a couple of almost-mboxes linked from [1]. Before the first
> "From " there is a mbox-like header but from there on it is a regular
> mbox archive consisting of the nominations. Prelimin
k to Debian.
There is a couple of almost-mboxes linked from [1].
Before the first "From " there is a mbox-like header but from there on
it is a regular mbox archive consisting of the nominations.
Preliminary results indicate that around 2/3 of the submissions for
debian-project are actual
ng/unstable).
> You get
> - a (probably buggy) console program to show you mails and ask for
> your opinion,
> - a largish mbox file (for debian-project it is 6M uncompressed / 2M
> compressed) with the messages,
> - a chance to do something about the spam in our web archive.
file (for debian-project it is 6M uncompressed /
2M compressed) with the messages,
- a chance to do something about the spam in our web archive.
Maybe we could start with debian-project at the present and go back in
time from there until we get bored, but I'm open to suggestions.
Please conta
On Fri, Nov 02, 2007 at 10:22:00PM +0100, Thomas Viehmann wrote:
> Hi,
>
> it has been claimed that the Debian list archives contain spam email
> messages.
>
> There is a "report as spam" button in on the list archive page of each
> message, but presently, spam i
Hi,
it has been claimed that the Debian list archives contain spam email
messages.
There is a "report as spam" button in on the list archive page of each
message, but presently, spam is by and large not removed from the
archives. The submissions seem to help (more or less) with findin
On Wed, Jul 25, 2007 at 09:15:38PM +0200, Cord Beermann wrote:
> Hallo! Du (Javier Fernández-Sanguino Peña) hast geschrieben:
>
> >If there any concerns from listmasters related to this patch I would really
> >like to hear them and would try to give a hand to make these improvements get
> >used in
Cord Beermann <[EMAIL PROTECTED]> wrote:
> http://lists.debian.org/debian-devel-announce/2007/07/msg00011.html
> Especially the listarchive-part is currently nearly without manpower.
Yeah, how's that going? Please send a second call if you don't find
enough non-European help.
Regards,
--
MJR/sl
Hallo! Du (Javier Fernández-Sanguino Peña) hast geschrieben:
>If there any concerns from listmasters related to this patch I would really
>like to hear them and would try to give a hand to make these improvements get
>used in our web archives.
http://lists.debian.org/debian-devel-announce/2007/07
On Wed, Jul 25, 2007 at 07:32:19PM +0200, Thomas Viehmann wrote:
> Thomas Viehmann wrote:
> > If the one thing keeping us from deleting list spam (which I found out
> ...we don't...
> > after reporting entire months of d-devel spam) is the indexing and thus
> > linking, I'd happily try to come up w
spam report log in order to read a
list of spam messages to skip when constructing web indices
(probably leaves room for efficiency improvements)
- does not change the mbox files, only changes the generated indices
- no detection yet in updatemail whether the archive should be updated
bec
Hi,
[I've sent this to -private before, but then I realized it was
off-topic for -private (thanks, mj)]
Disclaimer:
First of all, I'd like to say that I didn't use the archives, and that I
won't do it if any objection is made.
The email itself:
As some may know, I'm starting to develop a socio
On Tue, Feb 20, 2001 at 02:49:14PM +0100, Rene Mayrhofer wrote:
> Ok, I know I am a bit late, but since I recently got my Debian
> developer status and this is exactly what I asked for in my mail on
> 2001-01-01, I second this.
> Are 2 seconds (this should be the 2. second on this phrasing if I
> h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
> Okay, hopefully the final language change:
>
> Proposal is to change section 2.1.5 of the Debian policy to say:
>
>Non-free programs with cryptographic program code must be stored
> on
>the "non-us" server because
[Yes, I know I'm (a bit) late, but I think one point has to be raised,
and as no-one has done so as far as I can tell...]
You are all aware that the http://www.bxa.doc.gov/Encryption/Default.htm
are Crypt Policies of the *Administration*, right?
And we also know that this administration has chang
> Okay, hopefully the final language change:
>
> Proposal is to change section 2.1.5 of the Debian policy to say:
>
>Non-free programs with cryptographic program code must be stored on
>the "non-us" server because of export restrictions of the U.S.
>
>Programs which use patented algo
On Thu, Jan 11, 2001 at 09:20:35AM -0800, Pete Lypkie wrote:
> >Programs which use patented algorithms that have a restricted
> >license must also be stored on "non-us", since the "non-us" server
> >[...]
> > By the way, what does "restricted license" mean in this context?
> > Surely ev
On Thu, Jan 11, 2001 at 10:06:41AM +, Julian Gilbey wrote:
> Better English:
>
>Programs which use patented algorithms that have a restricted
>license must also be stored on "non-us", since the "non-us" server
>is located in a country where patenting algorithms is not
>permitte
> > This would be non-DFSG if we couldn't distribute it at all.
On Wed, Jan 10, 2001 at 11:17:05PM -0800, Seth David Schoen wrote:
> You can certainly say "this _archive_ is only for the use of residents
> of the following countries" and even try to enforce that, as long as
> you don't actually tr
On Wed, Jan 10, 2001 at 04:27:37PM -0800, Wichert Akkerman wrote:
> Okay, hopefully the final language change:
>
> Proposal is to change section 2.1.5 of the Debian policy to say:
>
>Non-free programs with cryptographic program code must be stored on
>the "non-us" server because of export
Raul Miller writes:
> On Thu, 11 Jan 2001, Wichert Akkerman wrote:
> > > non-US/main, since the license to the software itself is free.
>
> On Thu, Jan 11, 2001 at 02:47:57PM +0100, Adrian Bunk wrote:
> > But if I don't misunderstand chapter 7 (and 8) of the GPL a program
> > licenced under the G
On Thu, 11 Jan 2001, Wichert Akkerman wrote:
> > non-US/main, since the license to the software itself is free.
On Thu, Jan 11, 2001 at 02:47:57PM +0100, Adrian Bunk wrote:
> But if I don't misunderstand chapter 7 (and 8) of the GPL a program
> licenced under the GPL that is threatened by a patent
On Thu, 11 Jan 2001, Wichert Akkerman wrote:
> Previously Marco d'Itri wrote:
> > But is it non-US/main or non-US/non-free?
>
> non-US/main, since the license to the software itself is free.
But if I don't misunderstand chapter 7 (and 8) of the GPL a program
licenced under the GPL that is threate
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> Package which have a DFSG-compliant license and don't use a patented
> algorithm will be allowed in main (as happens right now).
Which algorithms qualify as "patented"? Those for which are patent
exists, or those where the patent owner has published
On 11 Jan 2001 01:29:14 +0100, Adrian Bunk wrote:
> On Wed, 10 Jan 2001, Wichert Akkerman wrote:
>
> >...
> >Programs which use patented algorithms that have a restrictied
> >license also need to be stored on "non-us", since that is located
> >in a country where it is not allowed to pa
On Wed, Jan 10, 2001 at 04:16:18PM -0800, Wichert Akkerman wrote:
>
> This is a slightly updated changed to reflect comments from people.
> Debian developers can second this proposal for inclusion in the
> policy text.
>
> Proposal is to change section 2.1.5 of the Debian policy to say:
>
>N
% http://www.iki.fi/gaia/ %%%
Keep the Deja Archive Alive!
http://www2.PetitionOnline.com/dejanews/petition.html
ist
>
>Of course that raises the question: What can Debian do to prevent export
>to one of those 7 contries, and do we really want to do so?
On another list I saw a discussion regarding this (the FSB list archive
http://www.crynwr.com/cgi-bin/ezmlm-cgi/0/ thread "Exporting Crypto
Previously Marco d'Itri wrote:
> But is it non-US/main or non-US/non-free?
non-US/main, since the license to the software itself is free.
Wichert.
--
/ Generally uninteresting signature - ignore at your convenience \
| [EMAIL
On Jan 11, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
> Programs which use patented algorithms that have a restrictied
> license must also be stored on "non-us", since that is located in a
> country where it is not allowed to patent algorithms.
But is it non-US/main or non-US/non-free?
On Thu, Jan 11, 2001 at 12:38:40AM +0100, Adrian Bunk wrote:
> That means if you use an algorithm that is patented in Germany
> the package will be in non-us? You better rename this "non-US"
> to "patented/main" and add the other needed "patented/contrib",
> "patented/non-free" and "patented/non-US
Previously Adrian Bunk wrote:
> Any examples of such countries?
See an earlier post I made, that listed them all.
> * Tell all the FTP mirrors of non-US that must of them are no longer
> allowed to ship non-US (e.g. ftp.de.debian.org is located in Germany
> where it's not 100% forbidden to pa
Yay. More random crossposts amongst multiple lists. Bcc'ed to -project.
On Thu, Jan 11, 2001 at 01:13:32AM +0100, Wichert Akkerman wrote:
> In addition, packages which have a DFSG-compliant license and use
> a patented algorithm that does not have a restrictive license will
> also be allowed in ma
On Wed, 10 Jan 2001, Wichert Akkerman wrote:
>...
>Programs which use patented algorithms that have a restrictied
>license also need to be stored on "non-us", since that is located
>in a country where it is not allowed to patent algorithms.
>...
Any examples of such countries?
> If t
Okay, hopefully the final language change:
Proposal is to change section 2.1.5 of the Debian policy to say:
Non-free programs with cryptographic program code must be stored on
the "non-us" server because of export restrictions of the U.S.
Programs which use patented algorithms that have
Okay, one more final language change:
Proposal is to change section 2.1.5 of the Debian policy to say:
Non-free programs with cryptographic program code need to be stored
on the "non-us" server because of export restrictions of the U.S.
Programs which use patented algorithms that have
hy it takes a while before
new packages get added to the archive.
Wichert.
--
/ Generally uninteresting signature - ignore at your convenience \
| [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ |
| 1024D/2FA3
On Thu, 11 Jan 2001, Wichert Akkerman wrote:
> > So for the export restrictions only a "non-US/non-free" will be needed.
>
> crypto export restrictions, yes. Right.
>
> > That means if you use an algorithm that is patented in Germany the package
> > will be in non-us? You better rename this "non-U
This is a slightly updated changed to reflect comments from people.
Debian developers can second this proposal for inclusion in the
policy text.
Proposal is to change section 2.1.5 of the Debian policy to say:
Non-free programs with cryptographic program code need to be stored
on the "non-
Wichert Akkerman wrote:
> The exact restrictions are listed in some legal documentation; you can
> find it at the URL I gave earlier. We could indeed consider this on a
> per-package basis, but this would mean a lot of extra work for our
> ftpmaster team, which I don't think is warranted for non-fr
Previously Andrea Glorioso wrote:
> Correct me if I'm wrong, but does this mean that program which are
> under a DFSG-compliant *license* and which don't have
> patent-encumbered code will be allowed to stay in main?
Package which have a DFSG-compliant license and don't use a patented
algorithm wi
Robert Thomson wrote:
>
> On Wed, Jan 10, 2001 at 10:41:39PM +, Tim Haynes wrote:
> > Robert Thomson <[EMAIL PROTECTED]> writes:
> > > So long as you don't mail a CD, cross a border, or force-feed to a mirror
> > > in one of the 7 victim countries, then you're fine.
> >
> > But, if you don't m
Previously Adam Heath wrote:
> What if the non-free program contains source, but is non-free for other
> reasons?
The exact restrictions are listed in some legal documentation; you can
find it at the URL I gave earlier. We could indeed consider this on a
per-package basis, but this would mean a lo
Previously Adrian Bunk wrote:
> So for the export restrictions only a "non-US/non-free" will be needed.
crypto export restrictions, yes. Right.
> That means if you use an algorithm that is patented in Germany the package
> will be in non-us? You better rename this "non-US" to "patented/main" and
Robert Thomson wrote:
>
> On Wed, Jan 10, 2001 at 01:10:55PM -0800, Joey Hess wrote:
> > Wichert Akkerman wrote:
> > > * DFSG free programs with crypto can be made and (re)distributed
> > > from the US now, as long as you don't consciously export it to
> > > one of 7 countries which are on a s
On Wed, 10 Jan 2001, Wichert Akkerman wrote:
>...
> Non-free programs with cryptographic program code need to be stored
> on the "non-us" server because of export restrictions of the U.S.
So for the export restrictions only a "non-US/non-free" will be needed.
> Programs which use
On Wed, Jan 10, 2001 at 10:41:39PM +, Tim Haynes wrote:
> Robert Thomson <[EMAIL PROTECTED]> writes:
> > So long as you don't mail a CD, cross a border, or force-feed to a mirror
> > in one of the 7 victim countries, then you're fine.
>
> But, if you don't mind me being absolutely clear, putti
Previously Sean 'Shaleh' Perry wrote:
> I was of the understanding that we would also have to notify the US of what is
> on our site.
We only need to tell them that our site has crypto stuff from what I
understand.
Wichert.
--
Robert Thomson <[EMAIL PROTECTED]> writes:
> On Wed, Jan 10, 2001 at 01:10:55PM -0800, Joey Hess wrote:
> > Wichert Akkerman wrote:
> > > * DFSG free programs with crypto can be made and (re)distributed
> > > from the US now, as long as you don't consciously export it to
> > > one of 7 countr
On Wed, Jan 10, 2001 at 01:10:55PM -0800, Joey Hess wrote:
> Wichert Akkerman wrote:
> > * DFSG free programs with crypto can be made and (re)distributed
> > from the US now, as long as you don't consciously export it to
> > one of 7 countries which are on a special blacklist
>
> Of course th
I was of the understanding that we would also have to notify the US of what is
on our site.
At 12:51 PM 01-10-2001 -0800, Wichert Akkerman wrote:
In light of this I'm proposing to change section 2.1.5 of the
Debian policy to say:
Non-free programs with cryptographic program code need to be stored
on the "non-us" server because of export restrictions of the U.S.
Programs
On Wed, Jan 10, 2001 at 13:10:55 -0800, Joey Hess wrote:
> Wichert Akkerman wrote:
> > * DFSG free programs with crypto can be made and (re)distributed
> > from the US now, as long as you don't consciously export it to
> > one of 7 countries which are on a special blacklist
>
> Of course that
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> I've been reading through the current US export policies
Wichert> in between lately to see if we still need non-US, or at
Wichert> least in the way we currently have it (there is lots of
Wichert> info on the c
On Wed, 10 Jan 2001, Wichert Akkerman wrote:
>
> Non-free programs with cryptographic program code need to be stored
> on the "non-us" server because of export restrictions of the U.S.
What if the non-free program contains source, but is non-free for other
reasons?
> Programs whi
On Wed, Jan 10, 2001 at 12:51:03 -0800, Wichert Akkerman wrote:
> In light of this I'm proposing to change section 2.1.5 of the Debian
> policy to say:
Yes! IMHO it's definitely time to make it possible for packages in the
regular main archive to support crypto (mozilla, w3m, lyn
Wichert Akkerman wrote:
> * DFSG free programs with crypto can be made and (re)distributed
> from the US now, as long as you don't consciously export it to
> one of 7 countries which are on a special blacklist
Of course that raises the question: What can Debian do to prevent export
to one of
Previously Wichert Akkerman wrote:
> * DFSG free programs with crypto can be made and (re)distributed
> from the US now, as long as you don't consciously export it to
> one of 7 countries which are on a special blacklist
Extra info: those 7 are Cuba, Iran, Iraq, Libya, North Korea, Sudan
and
I've been reading through the current US export policies in between
lately to see if we still need non-US, or at least in the way we
currently have it (there is lots of info on the crypto policies at
http://www.bxa.doc.gov/Encryption/Default.htm).
* DFSG free programs with crypto can be made and
On Thu, Jul 06, 2000 at 10:03:26PM -0500, Bolan Meek wrote:
> About Craig's increasingly insulting and offensive protest about the
> constitutionality of this CFV, to wit:
the only person i have been insulting to is the moron who deserves it.
cretins should learn to shut their mouth and stop anno
On Wed, Oct 20, 1999 at 02:11:00AM +0100, Julian Gilbey wrote:
> > Philippe Troin <[EMAIL PROTECTED]> writes:
> >
> > > 1) The way the Debian archive works requires the data to be stored
> > > twice (source package and .deb).
> >
> > Why
Fabien Ninoles <[EMAIL PROTECTED]> writes:
> On Tue, Oct 19, 1999 at 09:43:57PM +0200, Goswin Brederlow wrote:
> > Philippe Troin <[EMAIL PROTECTED]> writes:
> >
> > > 1) The way the Debian archive works requires the data to be stored
> > >
On Tue, Oct 19, 1999 at 09:43:57PM +0200, Goswin Brederlow wrote:
> Philippe Troin <[EMAIL PROTECTED]> writes:
>
> > 1) The way the Debian archive works requires the data to be stored
> > twice (source package and .deb).
>
> Why not allow Source only packa
On Wed, Oct 20, 1999 at 10:57:51PM +0200, Goswin Brederlow wrote:
> Torsten Landschoff <[EMAIL PROTECTED]> writes:
>
> > On Tue, Oct 19, 1999 at 09:43:57PM +0200, Goswin Brederlow wrote:
> >
> > > Why not allow Source only packages ?
> >
> > That will win nothing. You can't use apt-get on them,
On Tue, Oct 19, 1999 at 09:29:53PM +, Alexander Koch wrote:
> [f'up]
>
> On Tue, 19 October 1999 21:43:57 +0200, Goswin Brederlow wrote:
> > Why not allow Source only packages ?
>
> Something like that is the only workable thing, methinks.
> Having a source where a source is 99+ % the same da
On Fri, Oct 22, 1999 at 04:56:28PM +0200, Goswin Brederlow wrote:
> Anthony Towns writes:
>
> > [1 ]
> > On Tue, Oct 19, 1999 at 11:00:14PM +0200, Torsten Landschoff wrote:
> > > On Tue, Oct 19, 1999 at 09:43:57PM +0200, Goswin Brederlow wrote:
> > > > Why not allow Source only packages ?
> > >
Anthony Towns writes:
> [1 ]
> On Tue, Oct 19, 1999 at 11:00:14PM +0200, Torsten Landschoff wrote:
> > On Tue, Oct 19, 1999 at 09:43:57PM +0200, Goswin Brederlow wrote:
> > > Why not allow Source only packages ?
> > That will win nothing. You can't use apt-get on them, have to rebuilt
> > and h
On Wed, Oct 20, 1999 at 05:15:38PM +, Zygo Blaxell wrote:
> Here's a proposal:
ObShudder: How about a patch instead?
> Maintainers could have the option of not uploading a
> ..deb at all if their packages
Also, there doesn't seem to be any way of making a changes file to upload
source witho
Hi.
I like Fabien's idea of "user can choose a Small and Lean Debian, or
a Big and Resourceful Debian" :)
# well, I should go to -policy and express my placet for your proposal.
In article <[EMAIL PROTECTED]>
Fabien Ninoles <[EMAIL PROTECTED]> writes:
> > > On 18 Oct 1999 18:16:58 -0700, Phili
Torsten Landschoff <[EMAIL PROTECTED]> writes:
> On Tue, Oct 19, 1999 at 09:43:57PM +0200, Goswin Brederlow wrote:
>
> > Why not allow Source only packages ?
>
> That will win nothing. You can't use apt-get on them, have to rebuilt
> and have them twice locally.
You could set the arch flag i
On 19-Oct-99 Goswin Brederlow wrote:
> Why not allow Source only packages ?
And use apt-get source.
---
Christian Surchi, [EMAIL PROTECTED], www.firenze.linux.it/~csurchi
PGP fingerprint = 05 CE 0B BE BF FC B6 14 53 CA C7 8E AE 3A F2 6A
GPG fingerprint = D1E2 9A9D 1712 0E94 8671
1 - 100 of 126 matches
Mail list logo