Re: Bits (Nybbles?) from the Vancouver release team meeting
Stephen Gran schrieb: This one time, at band camp, Ingo Juergensmann said: On Mon, Mar 14, 2005 at 12:47:58PM +0100, Julien BLACHE wrote: Moreover, the criterias given in your mail are just so oriented towards/against some architectures, that it's a bad joke (I was going to write "disgusting", really). It's a total change of direction: from "as long as there are people who care, we will release those arch" to "no matter if there are people who care, we just release mainstream archs". :-( No, I thought the proposal stated quite clearly, if there are users and there are porters, a given arch is able to be included. All that means is that those interested will actually have to do some of the work to support things like security and the kernel. I know many of you already do quite good work as porters, and I mean no offense. But I can see quite clearly that it would be difficult for the security team or other groups to keep up with things growing the way they are. We need a working d-i on $arch We need working kernel on $arch and we need security updates on $arch Soliution any $arch debian releases has to add <= 1 developer to d-i, security and kernel team. Anyting else was already sayed by someone else. greets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/ http://www.x-tec.de
Re: Bits (Nybbles?) from the Vancouver release team meeting
Greg Folkert schrieb: On Tue, 2005-03-15 at 00:58 -0800, Steve Langasek wrote: Hi Aurélien, On Mon, Mar 14, 2005 at 10:56:51AM +0100, Aurélien Jarno wrote: Steve Langasek a écrit : The much larger consequence of this meeting, however, has been the crafting of a prospective release plan for etch. The release team and the ftpmasters are mutually agreed that it is not sustainable to continue making coordinated releases for as many architectures as sarge currently contains, let alone for as many new proposed architectures as are waiting in the wings. Would it be possible to have a list of such proposed architectures? I think this has already been answered, by someone who knows better than I. [snip] Architectures that are no longer being considered for stable releases are not going to be left out in the cold. The SCC infrastructure is intended as a long-term option for these other architectures, and the ftpmasters also intend to provide porter teams with the option of releasing periodic (or not-so-periodic) per-architecture snapshots of unstable. My primary desktop machine is an i386, but it was sometimes ago and for a limited period of time and hppa machine, because my i386 had problems. It allowed me to continue my work on Debian packages. In the case this new infrastructure is set up, does upload from a SCC architecture to unstable would still be allowed? If no, source only upload must be allowed again. Since non-RC (release candidate) architectures are going to be in the same unstable tree as the RC architectures (uploads to ftp-master, etc.), I don't see any reason that this would be disallowed. - there must be a sufficient user base to justify inclusion on all mirrors, defined as 10% of downloads over a sampled set of mirrors AFAIK, only i386 currently meet this criterion. Of the architectures currently in sarge, that's correct. It's assumed that amd64 will easily meet this 10% mark for etch. (If it doesn't, then the cut-off probably has to be re-thought, since it doesn't make much sense to have a 1/11 split between ftp.d.o and scc.d.o, *particularly* when the 11 archs together *would* most likely account for > 10%.) BTW, I am not sure this is really a good way to measure the use of an architecture, mainly because users could use a local mirror if they have a lot of machines of the same architecture. How about using popcon *in addition* to that? This isn't being used to measure the use of the architecture; it's being used to measure the *download frequency* for the architecture, which is precisely the criterion that should be used in deciding how to structure the mirror network. Okay, I have to comment here, seeing that I personally have at two separate locations, two complete mirrors, that I use nearly everyday. They only update when a change in the archive is detected. That means *MY* $PRETTY_BIG_NUMBER of usages of my own mirrors in each locale will mean nothing. I do my own mirror(s) so as to reduce the load on the Debian network. I actually scaled back what I use, now only having 5 arches I support, SPARC(and UltraSPARC), Alpha, HPPA-RISC, PowerPC and x86(Intel and otherwise). I dropped IA64 a while ago and will pickup X86_AMD64 when it become part of Sid Proper. How would you address the fact the bulk of my usage is not even seen by your network. To be eligible for inclusion in the archive at all, even in the (unstable-only) SCC archive, ftpmasters have specified the following What about experimental? experimental would also be available. architecture requirements: I would add as for the core set architecture: - there must be a developer-accessible debian.org machine for the architecture. This gets a little tricky for non-RC architectures, because if it's not already (or currently) a released architecture, we have no stable distro that can be installed on it, which means we have no security support for it; without security support, DSA isn't willing to maintain it, which means they probably aren't going to want to put a "debian.org" name on it, either -- and they certainly won't want to give it privileged access to LDAP. You could say that "there must be a developer-accessible machine for the architecture" without specifying "debian.org"; but I'm not sure that we should *require* this, either. Particularly for ports that are waning and are not expected to become RC architectures in the future, I think porters should be free to decide whether to spend the effort on maintaining such a machine since its absence only hurts that port, not the release. I am currently in the process of acquiring rotated out of production machines for 3 of the 5 architectures I support. I make a run to the right-coast of the US once every 2 months and pickup sometimes 10 - 4-16 processor machines with disk and typically a dozen of GB of memory and gaggles of disk. I rebuild/recondition most of these machines and distribute them to NPOs that need this kind of horsepower but can't afford current stuff or
Re: Alternative: Source-Centric Approach [w/code]
Mark Brown schrieb: On Tue, Mar 15, 2005 at 11:01:06PM +0100, Adrian Bunk wrote: On some mirrors? -> Not all mirrors have to mirror all ports. The mirroring part of the proposal is effectively just a proposal to rearrange the archive in order to make this easy for mirror admins. [-snip-] [EMAIL PROTECTED]:/root/scripts$ cat anonftpsync #! /bin/sh set -e # This script originates from http://www.debian.org/mirror/anonftpsync # Note: You MUST have rsync 2.0.16-1 or newer, which is available in slink # and all newer Debian releases, or at http://rsync.samba.org/ # Set the variables below to fit your site. You can then use cron to have # this script run daily to automatically update your copy of the archive. # Don't forget: # chmod 744 anonftpsync # TO is the destination for the base of the Debian mirror directory # (the dir that holds dists/ and ls-lR). TO=/home/mirrors/debian # RSYNC_HOST is the site you have chosen from the mirrors file. # (http://www.debian.org/mirror/mirrors_full) RSYNC_HOST=mastermirror.stayout.int # RSYNC_DIR is the directory given in the "Packages over rsync:" line of # the mirrors file for the site you have chosen to mirror. RSYNC_DIR=debian/ # EXCLUDE is a list of parameters listing patterns that rsync will exclude. # With a blank EXCLUDE you will mirror the entire archive. EXCLUDE="\ --exclude binary-alpha --exclude binary-arm \ --exclude binary-m68k \ --exclude binary-ia64 --exclude binary-mips* --exclude binary-hppa --exclude binary-sh \ --exclude *_hurd-i386.deb --exclude *_mipsel.deb \ --exclude *_s390.deb \ --exclude *_alpha.deb --exclude *_arm.deb \ --exclude *_m68k.deb \ --exclude *_ia64.deb --exclude *_hppa.deb --exclude *_mips.deb --exclude *_sh.deb \ --exclude slink --exclude slink-proposed-updates \ " # There should be no need to edit anything below this point, unless [-snip-] Were's the problem? greets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/ http://www.x-tec.de
Re: Bits (Nybbles?) from the Vancouver release team meeting
Anthony Towns schrieb: Sven Luther wrote: I think the main reply is for developers using said archs. Developers *developing* on those architectures need to use unstable anyway. If there aren't any users, then there's no much point doing any development. Are there any users? If so, what are they doing? Keep in mind that some of us are not allowed to talk in public about what we're running on our boxes. Cheers, aj grets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/ http://www.x-tec.de
Re: scripts to download porn in Debian?
Ron Johnson schrieb: On Tue, 2005-01-25 at 12:34 +0200, Kalle Kivimaa wrote: [-snip-] And yes, I've already thought of that. However, I'd rather some things (URLs, in this case) not be dropped my children's laps, even though they could be blocked further upstream. When they start to get curious about such things, let 'em learn about porn the old fashioned way... ;) Looks like an other round of underestimating children and censorship is coming up. 1. Kids are smarter than most of us think. When they are not interested in (say porn) they'll ignore it and or complain about it. 2. If they are interested they outsmart most parents anyway[1]. [1] Whena 13 year old starts to ask smart questions about how that web censor stuff in china works one should think twice about explaining it or et least get a foot in the door for a share of the money he'll make by selling his classmates anonymizing service. -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/
Re: scripts to download porn in Debian?
Petri Latvala schrieb: On Tue, 2005-01-25 at 23:32 +0100, Tilo Schwarz wrote: On Tuesday, 25. January 2005 12:15, Tollef Fog Heen wrote: * Ron Johnson | "They" don't want this inappropriate material dumped into their | children's laps right along side the things that the parents *do* | consider appropriate. Then they should supervise their child's use of the computer. Relying on Debian as some sort of filter for not letting a child see or read something some parent might consider harmful is stupid. Exactly. Especially since almose everybody has a program called browser installed which can be used to download all kinds of stuff... But the difference here is that with a browser you must _deliberately_ search for "all kinds of stuff"... or mistype a url As I sayed in an other post grown ups tend to underistimate kids. Younger kids just aren't interested in porn and will ignore and or complain about it. There's no damage done there. Remember not too long ago famelies were lifing in the same room a life long. I guess I don't have to drow anyone on this list a picture about it. greets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/
Re: Status of 'sarge' for the amd64 architecture
Adrian Bunk schrieb: On Sat, Apr 23, 2005 at 01:20:42PM -0700, Steve Langasek wrote: On Sat, Apr 23, 2005 at 04:24:28PM +0200, Adrian Bunk wrote: A silly question to you as release manager: What exactly are the technical reasons why amd64 can't simply be shipped as 12th architecture with sarge? We are already running into size constraints (on an ongoing basis) with our mirrors due to the size of the archive. Some of our mirrors have had to choose between distributing Debian and distributing other stuff -- some pick one, some pick the other, but in either case it's bad for the users. The ftpmasters believe it is not in our interest to exacerbate this situation by adding another arch before a sensible per-arch partial mirroring solution is in place. Hm is that a problem with the master archive structure? We mirror against ftp.de.debian.org via rsync and it's very easy to tell rsync just what you want[1] [1] At least that's what we did 'till 3 weeks ago sice then wh have a full debian mirror + amd64 + marillat debs + blackdown.org java debs (amd64 as well) and Ubuntu stuff. Thats 183 GB of files right now. We use a couple of partial mirrors as well that carry only i386 or sparc or amd64 debs without source. greets Uwe -- Jetzt will man das Internet nicht einfach ein paar Leuten wie der IETF überlassen, die wissen, was sie tun. Es ist zu wichtig geworden. - Scott Bradner http://www.highspeed-firewall.de/adamantix/ http://www.x-tec.de
possible problem for debian was [NTP considered basic] misc@openbsd.org
Hi, I just catched this conversation on the misc OpenBSD mailinglist. Does this in any way afflict debian? greets Uwe -- X-Tec GmbH Institute for Computer and Network Security WWW : http://www.x-tec.de/ IPv6: http://www.ipv6.x-tec.de/ --- Begin Message --- > I'd like to encourage the OpenBSD developers to move > NTP support into the "base" package. We cannot. The code is not free enough. --- End Message --- --- Begin Message --- > Theo de Raadt Wednesday, May 14, 2003 10:14 AM > > I'd like to encourage the OpenBSD developers to move > > NTP support into the "base" package. > > We cannot. The code is not free enough. I'm curious if you could be more specific here, because at first glance it seems the NTP copyright is at even less restrictive than the berkeley copyright (i.e. it does not require mention in advertising as bsd's does). I copy the entirety below. Rick *** * * * Copyright (c) David L. Mills 1992-2003 * * * * Permission to use, copy, modify, and distribute this software and * * its documentation for any purpose and without fee is hereby * * granted, provided that the above copyright notice appears in all* * copies and that both the copyright notice and this permission * * notice appear in supporting documentation, and that the name* * University of Delaware not be used in advertising or publicity * * pertaining to distribution of the software without specific,* * written prior permission. The University of Delaware makes no * * representations about the suitability this software for any * * purpose. It is provided "as is" without express or implied * * warranty. * * * *** --- End Message --- --- Begin Message --- * Permission to use, copy, modify, and distribute this software and * * its documentation for any purpose and without fee is hereby * * granted, provided that the above copyright notice appears in all* this is a misplaced modifier that has a 2nd meaning -- that it cannot be sold. i've talked to lawyers. it's a real problem, and they say they won't fix it. sorry. --- End Message ---
