Re: Another load of typos
Hi, my current plans are now as follows: Submit maint-only bug reports regarding "a" vs. "an" for the following "words", including a reference to this thread in the mailing list archive: > ACPI > Adlib > AX.25 > EsounD > FLTK > FPU > FTP > IETF > IMAP > Internet > IP > IPv4 > IPv6 > IR > IrDA > ISDN > ISO-C > L2TP > LCD > LDAP > LED > LGPL > LR (as in parser) > LRU > MP3 > MPEG > MRTG > MS > MTA > NDTP > NNTP > NT > NTFS > ODBC > OO > RDBMS > RPC > RSD > X11 > X (as in X window system) > XML ... not for: > FAQ ... and probably not for (that is, not unless you tell me otherwise): > HPGL > HTML > HTTPS Any further comments? Cya, Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
Hi, > > now that the problems with my last bunch of bug reports on mostly "its" > > vs. "it's" mistakes some months ago seem to be solved, I've found another > > load of typos of the "a" vs. "an" flavor, about 110 in total. > > please please please...for anything which can be localized (especially > debconf templates) add something about translations in the bug > reports. [...] > So, I really suggest that you separate things between package > descriptions and debconf templates. For the latter, plese get in touch > with debian-i18n. Well, so far it's package descriptions only; so nothing to worry about, you think? Though debconf templates probably would be a good idea to have a look at :-) Cya, Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildd redundancy (was Re: Bits (Nybbles?) from the Vancouver...)
On Wed, Mar 16, 2005 at 04:37:13PM -0500, Roberto C. Sanchez wrote: > >For example both public debian m68k machines are located on the same window > >sill at the Univ. of Duesseldorf. IMHO not the best place to position > >important infrastructure. > I agree. A sturdy table, or even a shelf or server rack would be > a much better place ;-) Indeed... and I believe that some problems of the machines originate from that and I fear that the temperature differences there might cause breakage of the hardware... But that's just a personal fear and assumption... > Just out of curiousity (and speaking as a non-DD that has been trying > to follow the flood mails over the last few days), why is it that I > seem to remember numerous offers of infrastructure support to Debian > in the way of hosting and machines but there still appears to be a > dearth of resources? I could explain that to you, but then again I would be accused of ranting... ;-) -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Wed, Mar 16, 2005 at 07:49:23PM -0800, Thomas Bushnell BSG wrote: > Joel Aelwyn <[EMAIL PROTECTED]> writes: > > > If you really want this fixed, I suggest finding someone who is well versed > > in both network security issues and Internet protocol fundamentals (not > > just TCP or even just IP, but all the other lovely beasties out there) and > > convincing them it's worth their time (I hear money is often an excellent > > motivator). The issues involved with writing a serious, production-capable > > network stack are really quite non-trivial (and yes, I *do* speak from > > personal experience in this). > > We have a network stack, thank you very much. > > The question is: which specific features do you want? > > "Deny by default" is all you mentioned, and that's already done. > Next? Fine, if you want to get pedantic, the following is a bare minimum of capabilities I would expect from any network processing on a 'real' (non-toy) network stack, where 'network stack' means everything between hardware driver and delivery of data to a userland application. It's late, so this may not be exhaustive. * The ability to associate a network interface with an IP host address, including network/netmask information for that IP subnet, and capable of handling CIDR networks. * The ability for an interface to receive, by default, only traffic that is destined for that interface. (Non-promiscuous mode; promiscuous mode availability is a big plus, but not required from the OS point of view) * The ability to check all inbound and outbound traffic (as well as throughbound if the system is capable of operating as a router between multiple networks) on any interface against a series of filtering rules. * Filtering rules must be able to match against any supported IP protocol, including protocol-specific information (ports for UDP and TCP, for example), as well as ICMP (including message types). IP packets must be able to be matched against source and destination network/host values, as well as additional IP information (such as TOS bits). * Filtering rules must be able to accept, reject, or drop (silent reject) network packets. The ability to manipulate the network stack decisions further (adding routing information) is a bonus, as is the ability to trigger a sub-chain of rules for evaluation. * The ability to log rejected or dropped traffic specifics. * The ability to log per-rule traffic statistics (packet count is required; packet size total is nice; other statistics may be useful). * The ability to match certain exceptionally useful flags in very common IP protocols (SYN, ACK, FIN, RST, etc, for TCP, as an example). Unless marked as 'nice to have', everything above is a *must* for running even basic firewall configurations on a host expected to face the Internet. If you can do those, and configure them in some semi-sane fashion, then you probably meet the expectations reasonable people would have for "basic firewalling". Or, in summary: * The ability to talk to a modern (CIDR) IP network. * The ability to look at the relevant header information on any protocol required to run as a buildd (includes IP, TCP, and UDP at the very least, quite possibly others I can't name offhand). * The ability to accept, reject, or drop packets based on the above. * The ability to monitor, both statistically and specifically, what the filtering rules are doing. I'm fairly sure there are things I'm forgetting, as well, but if your network stack can do the above, extending it to do anything I've forgotton is unlikely to be problematic for any code with a remotely sane internal architecture (hell, Linux can do it, and I don't consider the network internals to be all that sane...) -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Thu, 17 Mar 2005, Karsten Merker wrote: Some, maybe. Are there lots of people running servers on m68k and arm? ^^^ Perhaps not on m68k, but at least I do on sparc and mipsel, and I doubt that I am the only one. Well, at least the Debian project itself is running some important servers on Sparc hardware. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Aurélien Jarno [Mon, 14 Mar 2005 14:38:01 +0100]: > Another example, I have uploaded lineakd yesterday, it is already built > on all arches, except arm and ia64 [2]. In that case, I consider ia64 as > a slow arch. ia64 and hppa seem to have had some kind of trouble this week, but I see incoming full of ia64/hppa uploads now. I think most of us will recognize them as the first to upload, most of the times . At least, that's the case for the 90% of KDE uploads (which means that the machine is fast, and the buildd admin signs promptly). -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 You've come to the right place. At debian-devel we are always willing to argue over the meanings of words. -- seen on [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
* Tollef Fog Heen [Wed, 16 Mar 2005 16:15:01 +0100]: > * Wouter Verhelst > | In practice, the fact that wanna-build runs on ftp-master means it gets > | updated right after the Debian Installer (the one that sends you the > | ACCEPTED or REJECTED mails, not the other one that'll be used for Sarge) > | runs. This is great, because it means the wanna-build database is > | updated every fifteen minutes, and ASAP. It doesn't get any faster than > | that. > Merkel has a mirror which is updated more often than every mirror > pulse. So, w-b could easily run on merkel or another host which has a > mirror of the accepted queue. I'm genuinely curious whether there are any reasons that a d-d-c plus d-d-c-$ARCH subscription doesn't suffice, given incoming is public. (Other than "it gets cumbersome", that is.) One can maintain a private mirror of incoming with that. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 A conclusion is simply the place where someone got tired of thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Wed, Mar 16, 2005 at 07:50:13PM -0800, Thomas Bushnell BSG wrote: > Joel Aelwyn <[EMAIL PROTECTED]> writes: > > > * SCC systems have buildds. > > > > * Buildds must be network accessible. > > > > * The first rule of securing a machine exposed to the wilds is "Deny by > > default, allow by need". > > Exactly which firewalling are the existing buildds doing? (I'm asking > for information; if you don't know, then you don't know.) For buildds, since I don't run one as either local or DSA admin, I couldn't tell you offhand. I know what I'd *expect* them to be doing, as general guidelines, which closely resembles what I do on servers I deploy facing the net, but I don't know what they *are* doing. I have no particular reason to believe that they aren't running a sane set of firewalling rules; in fact, I would assume that they are, but I don't feel impolite enough to annoy someone's HIDS log with random checking. I also wouldn't expect details to be posted to the list; while security through obscurity is not *sufficient*, there are times when it is *useful*. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
On Wed, Mar 16, 2005 at 07:32:37PM -0500, Ben Collins wrote:
> On Wed, Mar 16, 2005 at 06:11:39PM -0800, Thomas Bushnell BSG wrote:
> > Ben Collins <[EMAIL PROTECTED]> writes:
> >
> > > The requirement sucks, lets leave it at that. If the machine dies, I can
> > > have two to replace it within a day or two.
> > >
> > > The point being, there's no reason to have two seperate machines when one
> > > can do the job. As long as it keeps up, then there should be no cause for
> > > concern.
> >
> > If you have one machine, and it dies, and it takes you a day or two to
> > replace it, then it cannot "do the job". If you can guarantee that it
> > never dies (somehow), then maybe it could.
>
> Ok, I can guarantee that it never dies. The hardrives are raid 5
> configuration, and the power supplies are redundant, and if any of the
> three cpu/mem boards goes bad, I can just remove it and let the other two
> (4x cpu's and 4gigs ram) run. Then there's also two 10/100mbit ethernet
> adapters.
>
> It wont die all together, it's an enterprise class system. It's meant to
> keep going, even if it has to limp to do so. Even with 1 cpu/mem board, it
> still would have 2 cpu's and 2gigs of ram.
And when the network to that building dies due to Backhoe-Induced Fiber
Fade, it will cheerfully sit there and chug along at a very fast idle with
nothing to do.
Don't even bother bringing up "redundant fiber". It may be, if it hasn't
been regroomed, and twenty plus years of network administrators have
learned the hard way that the gun is ALWAYS loaded. The best you can hope
for is a misfire.
This applies equally to having twenty buildds sitting in a rack, of course.
If the purpose of the B={1,2}+1 rule is, in part, protection against
buildds vanishing off the face of the earth, we need to decide just what
level of redundancy we really want - resilience to fiber cuts? City power
loss or statewide rolling blackouts? Tsunami? ISP business failures?
In case you missed the point, I've known networks knocked out by each of
the above, in some cases permanently (or for long enough to be effectively
equivalent). Hell, I shut off the primary ISP link for Guam for non-payment
at a former employer, multiple months in a row. The iron doesn't do us any
good if it isn't reachable. If we're going to propose new standards, let's
not forget to include important details.
For example:
* The architecture must have sufficient primary and backup buildds, of
sufficient capability, to meet the following requirements:
- No failure of power grid (up to regional size), physical facility, or
network access (alone or in combination) can take down enough machines
that no buildds are available for any period longer than six hours, at
any time, or require local admin intervention to come online in case of
a failure. It must be possible to return the port to normal operation
within one week from initial failure.
[ If we're concerned about acts of god or man that can hit multiple ]
[ regional power grids, we have a very different set of concerns. ]
[ This also allows for primary/hot-backup machines, as long as the]
[ backup machines can be brought online by DSAs with no local admin ]
[ required, and within six hours. If the DSA folks need to take ]
[ longer than a week to return the buildds to operation, that's their ]
[ domain, but it must be *possible* to do within a week by reasonable ]
[ standards - not 24x7 multiple-person herculean efforts. Restoring a ]
[ buildd is likely to take local admin intervention, of course. ]
- During normal operation, the buildds must be able to keep up with
day to day package compilation loads. This means that the average
package-built-and-uploaded rate must be at least 110%, and that the
architecture completely empties the build queue at least once per week.
[ If it wasn't obvious, 110% is deliberate ludicrous; it's a minor]
[ detail that frankly should probably be determined by observing ]
[ our current 'successful' buildds, the ones nobody complains about ]
[ in general, and seeing how well they really do. The second clause ]
[ could be made irrelevant by changing the build ordering algorithm ]
[ to one that doesn't have starvation failure cases, but unless it]
[ is, it matters that the buildds for an architecture *regularly* ]
[ empty the build queue under normal operation. Putting it at a week ]
[ is my own personal guess at a balance between 'not penalized for]
[ upload surges' (from things like BSPs) and 'maintainers can assume ]
[ that low priority uploads can proceed to testing without undue ]
[ delay'. ]
- At least one buildd supporting security-related build queues must be
available at all times, even during degraded operations. All buildds
which handle secur
Re: [RFC] OpenLDAP automatic upgrade
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > On Wed, 16 Mar 2005, Quanah Gibson-Mount wrote: >> The patches for BDB 4.2.52 are freely available from Sleepycat. They are >> required to be in place if you want a stable BDB 4.2.52 distribution. I >> would be very surprised if the package maintainer hadn't already included >> the patches in their build. I also post links to the patches from my > Yes, they are included. In fact, I would expect Debian BDB 4.2 to be much > more stable than whatever is available from Sleepycat, as a rule of thumb. Good good. :) >> As for BDB 4.3: >> You cannot use BDB 4.3 to load databases past a few million entries into >> OpenLDAP. The way BDB handles logs changed enormously between BDB 4.2 and >> BDB 4.3, and its log management is not stable, often running out of >> space. In addition, numerous users have written the OpenLDAP list >> complaining of issues they've hit using BDB 4.3 with OpenLDAP 2.2. The >> solution was for them to move back to BDB 4.2.52+patches. This became > I would expect that to cause trouble with just about everything that uses > huge indexes and databases with BDB 4.3. Or does it show up only in > OpenLDAP usage patterns (OpenLDAP is known to find all lurking bugs in BDB > that others never hit :-) ). Well, I only use BDB with OpenLDAP, so I can't say one way or the other. ;) >> In short, I cannot find a single reason to run OpenLDAP against BDB 4.3, >> and even the current OpenLDAP release notes that BDB 4.2 is required. I >> can find many reasons to not use BDB 4.3. > Not good. That might mean a lot of trouble to get 4.3 out of sarge, and > revert all packages back to 4.2 :( Well, I'd say at least for OpenLDAP 2.2, it really needs to be done if a Debian wants to release a stable OpenLDAP setup. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
Bernd Eckenfels <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]> you wrote: > > getting things back. The point of the N+1 rule, as I understand it, > > is to give a different kind of redundancy, so that we don't have to > > wait a day or two. > > How many current debian services are hosted that way? You mean serious services, that if they are broken make everything else wait? Only the ftp archive, which is mirrored. Why should this one get a rule that, say, the BTS or the mailing lists do not? Because in my history of being involved with Debian, which is something like eight years now, I have never seen the BTS be gone for a day; I have never seen the mailing lists stop working for a day. There may have been one or two that didn't hit my radar screen. By contrast, I have seen an arch's autobuilders all be gone for a day--or much longer. So experience tells us that redundancy in the autobuilders is more important, because they have historically been less reliable as a class. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
In article <[EMAIL PROTECTED]> you wrote: > getting things back. The point of the N+1 rule, as I understand it, > is to give a different kind of redundancy, so that we don't have to > wait a day or two. How many current debian services are hosted that way? Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
Auric is down, because it is a only a U60. I attempted to move some drives around, and I did put them in the wrong place. The delay in getting it fixed is, as I said, getting a response from James to move the new machine there. No reason to fix auric if I can just replace it. Stop chasing red herrings, and just get back to work. Sparc has always been and always will be a maintained architecture. On Wed, Mar 16, 2005 at 07:17:42PM -0800, Thomas Bushnell BSG wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > Ok, I can guarantee that it never dies. The hardrives are raid 5 > > configuration, and the power supplies are redundant, and if any of the > > three cpu/mem boards goes bad, I can just remove it and let the other two > > (4x cpu's and 4gigs ram) run. Then there's also two 10/100mbit ethernet > > adapters. > > So why isn't auric running now? It's down on a "RAID failure" or > something like that, right? > > If a cpu/mem board goes bad, is "just remove it" necessary for the > machine to keep working? What worries me is not the high-reliability > enterprise hardware doing it's job, but your "day or two" delay in > getting things back. The point of the N+1 rule, as I understand it, > is to give a different kind of redundancy, so that we don't have to > wait a day or two. > > Thomas -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Hi Roland, On Mon, Mar 14, 2005 at 04:04:45PM +0100, Roland Mas wrote: > Steve Langasek, 2005-03-13 20:45:09 -0800 : > > It's also not clear how much benefit there is from doing stable > > releases for all of these architectures, because they aren't > > necessarily useful to the communities surrounding those ports. > I would like to refer to the (also numerous) flamewars we've had on > "why should we release after all?". There have always been reasons to > keep providing releases, and these reasons apply as much to "minor" > architectures as they do for "major" ones. At least from what's been > publically discussed. Certainly, there are reasons why it benefits us (FSO "us" within the community) to release Debian for each of the architectures that sarge will be released with. However, this doesn't come for free; the release can only progress as fast as the slowest architecture at any given time, which means that if we don't have a very rigid standard for how slowly a release arch is allowed to move along, we have a very slow release process indeed. This proposal is, first and foremost, about setting concrete criteria that we can hold the ports to for etch, to get away from wishy-washy, "one more week for kernel updates on $arch", "$arch2 isn't doing so well, maybe we should drop it from testing" problems that the release team is currently suffering from. The idea of setting criteria should not be controversial, though I can understand that specific criteria we've suggested may be. Second, and only second, is the recognition that there is a certain measure of overhead that can't be dealt with in parallel by porters, and introduces delays in the release process. This includes factors such as per-arch toolchain churn when major toolchain changes are introduced, as well as having to do some things the hard way in britney right now, and any central coordination that needs to be done by ftpmasters (configuring wanna-build access, managing the archive size, etc). The last might be mitigated by expanding the ftpmaster team, if it's a problem; but the big one here is the toolchain, because each "build, test, fix" cycle has a lengthy "let the package get picked up by autobuilders, wait to see what breaks" stuck in it. This kind of thing makes it worthwhile, from a release standpoint, to consider reducing our release architecture count even if all our architectures meet the objective quality criteria we set. This is why the "N <= 2 autobuilders" criterion has been looked at as a means for deciding which architectures we might want to drop from the release. It's possible that setting the other requirements would give us a reduced count of architectures for etch; but it's also possible that all the port teams will pull together and manage to satisfy the release arch requirements for all 12 architectures. That would be great, but it would still leave us with those coordination/synchronization problems that can't be solved by throwing more manpower at them. It's difficult to say what the concrete per-arch impact of these problems is on the release cycle, because I think they're lost in the noise right now of those problems that *can* be brought under control; but my gut feeling is that 11 architectures is already above the threshold at which it starts to hurt us. In that case, it makes sense to consider dropping the slowest, legacy architectures from the release. > > This change has superseded the previous SCC (second-class citizen > > architecture) plan that had already been proposed to reduce the > > amount of data Debian mirrors are required to carry; prior to the > > release of sarge, the ftpmasters plan to bring scc.debian.org > > on-line and begin making non-release-candidate architectures > > available from scc.debian.org for unstable. > I'd like this plan to drop the "SCC" name then. It used to be just a > matter of where to go to fetch packages. Now it's officially > obsoleted architectures. Very different things, and keeping the name > would be misleading. Very different things, which is why the "SCC" name (or "ports", as it looks like we might prefer) is only used to refer to the mirror division -- not to whether or not an arch is an RC (release candidate). > > - the Security Team must be willing to provide long-term support for > > the architecture > > - the Debian System Administrators (DSA) must be willing to support > > debian.org machine(s) of that architecture > > - the Release Team can veto the architecture's inclusion if they > > have overwhelming concerns regarding the architecture's impact on > > the release quality or the release cycle length > This is where the "objective" is questionable. Please, at least > require that the reasons for all three of these potential refusals be > motivated. Er, I don't really think that was ever in question; the point here is to not paint ourselves into a corner where we say "we didn't think of this issue before, but it's a serious problem
Re: Error
лл£¡ÊÕµ½£¡ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
Ben Collins <[EMAIL PROTECTED]> writes: > Stop chasing red herrings, and just get back to work. Sparc has always > been and always will be a maintained architecture. Actually, work right now consists of answering paniced emails from my students worried about their test on Friday, and waiting for a compile of ec-fonts-mftraced to complete (which takes several hours). Other people often say that sparc has historically been one of the more problematic buildd's because of bad handling of dep-wait and so forth. I don't know how much credence to give this. One of my hopes for the new ftp/scc criteria is that buildds will be much better maintained than they are currently, with a single set of clear standards, which every single buildd is required to follow, and with extra buildd capacity. Saying "trust me, nothing bad will ever happen" is really unimpressive. s390 is supposedly one of the fastest Debian archs, but gee?! I've seen enterprise servers collapse overnight, and what keeps the enterprises using them reliable is that they have a guy on a beeper-leash who comes in at 3am and gets it going again. Yes, all the things you indicate are wonderful reliability tools, *if* you have the guy who is on a beeper-leash and will come in at 3am. If you don't is it too much trouble to ask for a second machine so that progress can still be made while you take a day or two to fix a problem? I have no objection to you taking a day or two, I'm just asking for a backup so that the project doesn't have to wait for it. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Joel Aelwyn <[EMAIL PROTECTED]> writes: > * SCC systems have buildds. > > * Buildds must be network accessible. > > * The first rule of securing a machine exposed to the wilds is "Deny by > default, allow by need". Exactly which firewalling are the existing buildds doing? (I'm asking for information; if you don't know, then you don't know.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Joel Aelwyn <[EMAIL PROTECTED]> writes: > If you really want this fixed, I suggest finding someone who is well versed > in both network security issues and Internet protocol fundamentals (not > just TCP or even just IP, but all the other lovely beasties out there) and > convincing them it's worth their time (I hear money is often an excellent > motivator). The issues involved with writing a serious, production-capable > network stack are really quite non-trivial (and yes, I *do* speak from > personal experience in this). We have a network stack, thank you very much. The question is: which specific features do you want? "Deny by default" is all you mentioned, and that's already done. Next? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Wed, Mar 16, 2005 at 03:13:16PM -0800, Thomas Bushnell BSG wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > > > On Mar 16, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > > > One of the conditions for SCC is "fully functioning Unix, including > > > DNS and firewall support." What specifically is intended by "firewall > > > support"? > > I think that simple ACLs are the bare minimum. > > Ok, can you point me at the specific feature, and why is this feature > important for packaging in SCC? Consider: * SCC systems have buildds. * Buildds must be network accessible. * The first rule of securing a machine exposed to the wilds is "Deny by default, allow by need". Therefore, a box which does not provide basic firewalling capabilities (whether that's achieved by configurable ACLs, mind-reading the human traffic trigger, or pixies inspecting every packet) is thus not suitable for running a buildd on, and thus can never achieve SCC status. Sorry, but being able to cope with a hostile environment *is* a requirement in today's network, and there isn't any real way around that fact. I have no clue where Hurd network filtering stands at the moment, so I can't comment on how far it is from having this feature. I wouldn't be willing to admin any such box that was plugged into a network using a ten foot pole, and I don't see why the DSA folks should be expected to either. If you really want this fixed, I suggest finding someone who is well versed in both network security issues and Internet protocol fundamentals (not just TCP or even just IP, but all the other lovely beasties out there) and convincing them it's worth their time (I hear money is often an excellent motivator). The issues involved with writing a serious, production-capable network stack are really quite non-trivial (and yes, I *do* speak from personal experience in this). -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
On Wed, Mar 16, 2005 at 06:11:39PM -0800, Thomas Bushnell BSG wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > The requirement sucks, lets leave it at that. If the machine dies, I can > > have two to replace it within a day or two. > > > > The point being, there's no reason to have two seperate machines when one > > can do the job. As long as it keeps up, then there should be no cause for > > concern. > > If you have one machine, and it dies, and it takes you a day or two to > replace it, then it cannot "do the job". If you can guarantee that it > never dies (somehow), then maybe it could. Ok, I can guarantee that it never dies. The hardrives are raid 5 configuration, and the power supplies are redundant, and if any of the three cpu/mem boards goes bad, I can just remove it and let the other two (4x cpu's and 4gigs ram) run. Then there's also two 10/100mbit ethernet adapters. It wont die all together, it's an enterprise class system. It's meant to keep going, even if it has to limp to do so. Even with 1 cpu/mem board, it still would have 2 cpu's and 2gigs of ram. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is xprint still used by mozilla, etc?
On Tue, 15 Mar 2005 21:58:55 -0800, Marc Wilson <[EMAIL PROTECTED]> wrote: > On Tue, Mar 15, 2005 at 05:30:50AM +0100, Jonas Gall wrote: > > On Mon, 14 Mar 2005 14:04:40 -0800, Marc Wilson <[EMAIL PROTECTED]> wrote: > > > Apparently you missed the flamage when Mozilla's maintainer went insane > > > and > > > started requiring it. :) > > That were the days of Xprint release 008 which was not a kicker - but > > in the meantime both Xprint server (now at version 1.0) and Mozilla > > client were improved a lot. > > So what you're saying is that now xprint breaks in slightly more obscure > ways rather than the incredibly obvious way it did previously? Last as I tested it was working (that was two days ago!). Jonas -- .-. .-.Yes, I am an agent of Satan, but my duties (_ \ / _) are largely ceremonial. | |[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arch-specific packages and the new SCC requirements
On Wed, Mar 16, 2005 at 11:12:29AM -0800, Thomas Bushnell BSG wrote: > > To be in SCC, under the proposal we're all discussing, an arch must > have build 50% of the archive, not counting arch-specific packages. > > The Debian Hurd project has another category that should be excluded > because they are kernel-specific. (The current list on the web page > is update, makedev, ld.so, modconf, modutils, netbase, pcmcia-cs, > procps, ppp, pppconfig, setserial. There are surely more.) > > Ideally we would have a new field in the control file to specify > Kernel (or System), which would normally be "any", but for packages > like these would be "linux". But that's a hornets nest of potential > problems. > > We could ask the maintainer of update (say) to change it from > "Architecture: any" to "Architecture: i386 mk68 ...". But that's > tedious, brittle, and we all hate it. > > What would really win, of course, is "Architecture: !hurd-i386". But > negative declarations are currently not yet supported. They should > be. > > None of this is insoluble, and I assume that it won't be a serious > problem taking account of it, but it does mean that applying the 50% > and 90% threshholds will require more than simply looking at > statistics and applying them, because we don't currently have a > fully-robust way to indicate the relevant kind of "arch specific". The 'type-handling' package by Robert Millan appears to already be in use for addressing exactly this sort of thing (since, as far as I am aware, he wrote it for working on various BSD ports), at least in terms of simplifying the Architecture: entry. See the cdbs source package for some useful things this can deal with. Teaching the build statistics stuff to understand what the real number of packages for a given architecture for is a separate question, of course. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
Ben Collins <[EMAIL PROTECTED]> writes: > Ok, I can guarantee that it never dies. The hardrives are raid 5 > configuration, and the power supplies are redundant, and if any of the > three cpu/mem boards goes bad, I can just remove it and let the other two > (4x cpu's and 4gigs ram) run. Then there's also two 10/100mbit ethernet > adapters. So why isn't auric running now? It's down on a "RAID failure" or something like that, right? If a cpu/mem board goes bad, is "just remove it" necessary for the machine to keep working? What worries me is not the high-reliability enterprise hardware doing it's job, but your "day or two" delay in getting things back. The point of the N+1 rule, as I understand it, is to give a different kind of redundancy, so that we don't have to wait a day or two. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An idea from a Debian user
In article <[EMAIL PROTECTED]> you wrote: > A lot of work has been done in webmin for this. Web interfaces are > generally preferred in this century :-) and gkdebconf, base-config or configure-debian. However the neaness of debian is mostly due to its classical unix design. And this is somewhat unfriendly to control panels. (And DDs are not the typical user (and therefore developer) of such tools) Some debian clones may be more friendly in this area. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] OpenLDAP automatic upgrade
On Wed, 16 Mar 2005, Quanah Gibson-Mount wrote: > The patches for BDB 4.2.52 are freely available from Sleepycat. They are > required to be in place if you want a stable BDB 4.2.52 distribution. I > would be very surprised if the package maintainer hadn't already included > the patches in their build. I also post links to the patches from my Yes, they are included. In fact, I would expect Debian BDB 4.2 to be much more stable than whatever is available from Sleepycat, as a rule of thumb. The dire days of BDB 4.2 royally screwing over your database in any non-joke box are gone, fortunately. As for BDB 4.3, I have no idea. > As for BDB 4.3: > You cannot use BDB 4.3 to load databases past a few million entries into > OpenLDAP. The way BDB handles logs changed enormously between BDB 4.2 and > BDB 4.3, and its log management is not stable, often running out of > space. In addition, numerous users have written the OpenLDAP list > complaining of issues they've hit using BDB 4.3 with OpenLDAP 2.2. The > solution was for them to move back to BDB 4.2.52+patches. This became I would expect that to cause trouble with just about everything that uses huge indexes and databases with BDB 4.3. Or does it show up only in OpenLDAP usage patterns (OpenLDAP is known to find all lurking bugs in BDB that others never hit :-) ). > In short, I cannot find a single reason to run OpenLDAP against BDB 4.3, > and even the current OpenLDAP release notes that BDB 4.2 is required. I > can find many reasons to not use BDB 4.3. Not good. That might mean a lot of trouble to get 4.3 out of sarge, and revert all packages back to 4.2 :( -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, Mar 16, 2005 at 05:11:47PM +0100, Toni Mueller wrote: > > Hi Steve, > > On Wed, 16.03.2005 at 15:23:42 +, Steve McIntyre <[EMAIL PROTECTED]> > wrote: > > I wrote: > > >Btw, why, or how, do other projects with much fewer users and also much > > >fewer developers, manage to release for more than 4 architecture? > > >*BSD come to mind... > > > > By having a much smaller set of software, mainly. The core BSDs are > > *tiny* compared to what we try to ship in Debian. > > that would not explain the kernel problems that were mentioned on this > list. The NetBSD team, at least, has precisely one kernel. Linux has not had "one kernel" for some time, as I understand it, but rather, a base set of kernel sources and some large number of ports have their own port-specific additions that may or may not mesh well with any given revision. In addition, the kernel, core libraries, and core utilities - that is, everything that is not "third party software" of some sort, and actually lives in "src" instead of "pkgsrc" (Package Sources), is released in lockstep. The Debian equivalent would be, oh, roughly "Kernel, Libc, Essential" (and *maybe* "Required") being released as a "New Debian Release", with all of the rest building and working correctly to a greater or lesser degree depending on how active the maintainer of that package source is about it, modulo some basic QA to purge the truly utterly broken stuff. You'll note that we've been in base-freeze with a more-or-less stable, solid Sarge core for, uhm, how long now? All the rest, at least from a package perspective, is gravy to the BSD folks. If you want to know (apart from infrastructure) why it takes so long, try doing a package count. Getting 10,000 *anything* to move together is a challenge, whether it's packages or lemmings. Once you do, the results can be quite impressive, granted, but it takes some doing. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
I demand that Adrian Bunk may or may not have written... > On Thu, Mar 17, 2005 at 12:29:28AM +, Darren Salt wrote: >> I demand that Adrian Bunk may or may not have written... >> [snip] >>> And without testing, all these transition problems wouldn't exist. >> And without testing, there are those who currently use testing who'd use >> stable instead, or possibly go elsewhere. >> (I'm currently using testing. Updating an installation from unstable over >> a dial-up connection isn't /quite/ what I want...) > Even if you are using unstable, noone forces you to update all packages on > a daily basis. True, but even with (say) weekly updates, the quantity of packages is likely to be lower due to things like RC bugs, uploads of newer versions before the previous versions have made it into testing, etc. > The main reason of people I know who are currently using testing is simply > that Debian stable is much too outdated for being useful. There's that too; and yes, that's one of the reasons why I'm using it. [snip rest; I'll let others argue about it all or whatever...] -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | Let's keep the pound sterling Do not clog intellect's sluices with bits of knowledge of questionable uses. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
On Wed, Mar 16, 2005 at 04:31:19PM -0800, Thomas Bushnell BSG wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote: > > > In article <[EMAIL PROTECTED]> you write: > > > >I have an e3500 to replace both auric and vore (and the raid), but I > > > >haven't gotten an ok from James to do so yet. > > > > > > That would cut the number of sparc buildds down to one, when two are > > > required for RC archtectures under the new proposal. > > > > That's ok because two buildd's can run on the one machine. It has 6 cpu's. > > That cannot be the requirement. The point has to be an additional and > independently functioning piece of hardware. If the disk blows or it > is compromised or something, the others should be able to continue. The requirement sucks, lets leave it at that. If the machine dies, I can have two to replace it within a day or two. The point being, there's no reason to have two seperate machines when one can do the job. As long as it keeps up, then there should be no cause for concern. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] OpenLDAP automatic upgrade
Torsten Landschoff <[EMAIL PROTECTED]> writes: >> Some issues to consider for the 2.1 to 2.2 process: >> >> 1) OpenLDAP 2.1 generally used BDB 4.1. OpenLDAP 2.2 should only be used >> with BDB 4.2.52+patches when using bdb or hdb as the backend (Ignore the >> documentation with OpenLDAP 2.2.23 stating it requires BDB 4.3, that >> statement is incorrect). > Yes, I accidently built it with BDB 4.2 and it worked. But - what is the > problem with 4.3? And what patches will be needed for 4.2.52 - it's not > like I can go and change the libdb4.2 packages, I'll have to ask the > maintainer for that favour. The patches for BDB 4.2.52 are freely available from Sleepycat. They are required to be in place if you want a stable BDB 4.2.52 distribution. I would be very surprised if the package maintainer hadn't already included the patches in their build. I also post links to the patches from my website on building OpenLDAP: http://www.stanford.edu/services/directory/openldap/configuration/ specifically in this case: http://www.stanford.edu/services/directory/openldap/configuration/bdb-build-42.html You can ignore the custom patch about transactions, as that is not an official sleepycat patch, but one written by Howard Chu, one of the primary OpenLDAP developers. As for BDB 4.3: You cannot use BDB 4.3 to load databases past a few million entries into OpenLDAP. The way BDB handles logs changed enormously between BDB 4.2 and BDB 4.3, and its log management is not stable, often running out of space. In addition, numerous users have written the OpenLDAP list complaining of issues they've hit using BDB 4.3 with OpenLDAP 2.2. The solution was for them to move back to BDB 4.2.52+patches. This became such a problem that with the OpenLDAP 2.2.24 release (done today), the README file was updated to say: SLAPD: BDB backend requires (latest) Sleepycat Berkeley DB 4.2 I've been running OpenLDAP 2.2 with BDB 4.2.52+patches since OpenLDAP 2.2.6 was released, and any issues I've had were with bugs in OpenLDAP, not with BDB. I also ran benchmarks against BDB 4.3 based OpenLDAP 2.2 servers, and they performed no better (and slightly worse) than BDB 4.2 based OpenLDAP 2.2 servers. In short, I cannot find a single reason to run OpenLDAP against BDB 4.3, and even the current OpenLDAP release notes that BDB 4.2 is required. I can find many reasons to not use BDB 4.3. >> 2) Several changes were made to how ACL's were handled between OpenLDAP >> 2.1 and OpenLDAP 2.2. You cannot simply upgrade the database and expect >> everything to work. The ACL's must also be reviewed and correctly >> updated. > Surely. For simple installations it might work without that though and > not every slapd package is installed to run the Stanford directory > server. :) I doubt that it will work for even simple installations. The very syntax of many of the ACL declarations were changed. I had to go through and update every single ACL in my ACL file for it to work right. ;) >> 3) OpenLDAP bdb/hdb based databases are highly dependent on a well >> configured DB_CONFIG file for the particular database in question. Simply >> doing a slapcat/slapadd is really not sufficient for ensuring that the >> resulting directory server will run well. A poorly configured >> DB_CONFIG file can lead to the slapadd process taking hours or days. In >> addition, there are two flags that should be set in the DB_CONFIG file >> before the slapadd takes place, that should then be commented out once the >> add is completed. > Erm, the upgrading process is already really complex, and I fear I don't > feel like implementing this in maintainer scripts. Which options are you > thinking of, BTW? And the documentation for DB_CONFIG is really lacking > as well, let's hope somebody wakes up the sleepy cats ;) The two flags I am thinking of for BDB 4.2 are: # Just use these settings when doing slapadd... #set_flags DB_TXN_NOSYNC #set_flags DB_TXN_NOT_DURABLE They turn off checks that aren't necessary when performing a slapadd. I also advise reading: http://www.stanford.edu/services/directory/openldap/configuration/bdb-config-42.html http://www.openldap.org/faq/data/cache/1075.html > I wonder why the OpenLDAP server can not tune most of the BDB parameters > itself during runtime. It has by far more information at its hands than > the Debian maintainer scripts have. If you really want to have this conversation, I suggest talking to Howard Chu (Howard Chu <[EMAIL PROTECTED]>). He's the author of back-bdb and back-hdb (The OL development team tends to refer to back-hdb as Howard's DB. :P). >> 4) If someone is using ldbm as their backend database, I'd throw a warning >> noting that bdb/hdb are the preferred backends of OpenLDAP. ldbm is rife >> with issues such as not catching data inconsistencies, leading to poor >> directory performance and potential data loss. > Where is the difference to bdb? ;-) http://www.openldap.org/faq/data/cache/756.html
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Thu, Mar 17, 2005 at 01:26:17AM +0100, Matthias Urlichs wrote: > No Debian tool depends on s/32/64/ or s/$/64/. As for me, I type "ppc" > instead of "powerpc" very often, even though I should know better by now. Likewise. This would seem to be a case of "once may be regarded as a misfortune, twice looks like carelessness". To deviate from the LSB *and* the apparently intuitive name purely to remain "consistent" with an unfortunate existing name (when even that consistency is fairly bogus) would seem a particularly foolish thing to do. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
Ben Collins <[EMAIL PROTECTED]> writes: > The requirement sucks, lets leave it at that. If the machine dies, I can > have two to replace it within a day or two. > > The point being, there's no reason to have two seperate machines when one > can do the job. As long as it keeps up, then there should be no cause for > concern. If you have one machine, and it dies, and it takes you a day or two to replace it, then it cannot "do the job". If you can guarantee that it never dies (somehow), then maybe it could. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An idea from a Debian user
On Thu, Mar 17, 2005 at 12:28:55PM +1100, Evan Cox wrote: > My suggestion has come from frustration in trying to maintain Debian Sarge > from the CLI. I am very use to some sort of system control center, for > common tasks such as iptables, network connection/configuration, configuring > hardware, repartitioning, or resizing hd's, backups etc. This could be quite > a list but will stop there. A lot of work has been done in webmin for this. Web interfaces are generally preferred in this century :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Thu, 2005-03-17 at 01:07 +, Scott James Remnant wrote: > On Thu, 2005-03-17 at 01:57 +0100, Andreas Jochens wrote: > > > On 05-Mar-17 00:10, Scott James Remnant wrote: > > > No, I would just prefer consistency. You've deliberately chosen an > > > architecture name that's jarringly different from your 32-bit variant; > > > that's a rather bold thing to do, and I think you need to justify that. > > > > The decision to use the name 'ppc64' is based on the LSB and it is > > consistent with the decision of all other distributions I know of. > > > But it isn't consistent with Debian's previous decision on the PowerPC > port. In particular, the LSB mandates "ppc32" for what we call > "powerpc". Ok, so if I follow you: We did it wrong for powerpc, and that justifies doing it wrong again for ppc64 ? Hrm... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
An idea from a Debian user
Hi Guys, I hope this is the right area to send this email. My apologies if I am wrong. If so, please forward to the appropriate area. I have fiddles with Linux distro's for approx 3 years, and found Debian 3 months ago. I adore it, and will be using debian from now on. I would like to offer a suggestion to the team about an idea for a package to add to Debian. This idea is the one feature that I feel is lacking and hope this idea aligns to your goals for Debian. My suggestion has come from frustration in trying to maintain Debian Sarge from the CLI. I am very use to some sort of system control center, for common tasks such as iptables, network connection/configuration, configuring hardware, repartitioning, or resizing hd's, backups etc. This could be quite a list but will stop there. My idea is to create a frontend program that is similar to the profile 'Midnight Commander' in Konqueror (ie screen splint into 3/4 top and 1/4 CLI) that begins with iconised area relevant to the administration task, and ends with a screen of relevant commands for the appropriate task and when appropriate some GUI features. From my point of view, a program like this would be a fantastic learning assistant in the crossover from point and click to CLI, and add a central administration section to Debian. Eg: I have formatted my hd with resizer format, and have separate partitions for /, /var, /usr, /home, /tmp and swap. I would like to see a graphic representation of the usage of my hd, and resize the partitions but fear making an error via the command line. This is where the program can help, by showing me a graph of this and suggesting what commands to use for the task. Please let me know if you want more info, or if ideas like this are a nuisance. Cheers Evan
Re: Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Thu, Mar 17, 2005 at 12:29:28AM +, Darren Salt wrote: > I demand that Adrian Bunk may or may not have written... > > [snip] > > And without testing, all these transition problems wouldn't exist. > > And without testing, there are those who currently use testing who'd use > stable instead, or possibly go elsewhere. > > (I'm currently using testing. Updating an installation from unstable over a > dial-up connection isn't /quite/ what I want...) Even if you are using unstable, noone forces you to update all packages on a daily basis. The main reason of people I know who are currently using testing is simply that Debian stable is much too outdated for being useful. I do believe that it was still possible to release a new stable Debian once a year [1] - and that this was still possible using a "traditional freeze" without testing. For making testing really usable, security support would be required. This requires manpower (that might perhaps be available). And it requires something else: The testing scripts would have to handle build dependencies as if they were dependencies. This shouldn't be too hard to implement, but my impression is, that the sole reason why it isn't implemented until now is, that it would increase the amount of manual work required by both the release team and all Debian developers even more. And this leaves still the question whether it's worth sacrificing eight architectures. cu Adrian [1] no, I'm not talking about point releases -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Thu, Mar 17, 2005 at 01:07:05AM +, Scott James Remnant wrote: > On Thu, 2005-03-17 at 01:57 +0100, Andreas Jochens wrote: > > > On 05-Mar-17 00:10, Scott James Remnant wrote: > > > No, I would just prefer consistency. You've deliberately chosen an > > > architecture name that's jarringly different from your 32-bit variant; > > > that's a rather bold thing to do, and I think you need to justify that. > > > > The decision to use the name 'ppc64' is based on the LSB and it is > > consistent with the decision of all other distributions I know of. > > > But it isn't consistent with Debian's previous decision on the PowerPC > port. In particular, the LSB mandates "ppc32" for what we call > "powerpc". Debian did not really make a previous decision on "powerpc" port; it evolved. At the time, none of these issues existed, and powerpc seemed like the logical thing to call it. I think Andreas has given good justification for using ppc64. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] OpenLDAP automatic upgrade
* Quanah Gibson-Mount wrote: [...] > You do *not* want to run OpenLDAP against BDB 4.3. Releasing Debian > with its OpenLDAP compiled against BDB 4.3 would be a serious > mistake. You forgot to explain _why_ OpenLDAP compiled against BDB 4.3 should be a serious mistake. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
Scott James Remnant wrote: >On Thu, 2005-03-17 at 01:57 +0100, Andreas Jochens wrote: >> >> The decision to use the name 'ppc64' is based on the LSB and it is >> consistent with the decision of all other distributions I know of. >> >But it isn't consistent with Debian's previous decision on the PowerPC >port. In particular, the LSB mandates "ppc32" for what we call >"powerpc". And why precisely do we need to be consistent with an architecture name chosen in the past? Names seem to be chosen arbitrarily; if we can agree with other distros and the LSB on what we call a new 64-bit PowerPC, that seems like a no-brainer to me... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Hey Steve, Steve Langasek wrote: >On Mon, Mar 14, 2005 at 11:41:59AM +, Steve McIntyre wrote: > >> >- the release architecture must have N+1 buildds where N is the number >> > required to keep up with the volume of uploaded packages > >> >- the value of N above must not be > 2 > >> When you say "N+1" buildds for a release architecture, do you mean >> _exactly_ N+1, or _at least_ N+1? > >At least; although, there are some concerns about plugging too many machines >into wanna-build for each arch, both for scalability reasons (hopefully >addressed once we have connection caching support on newraff) and, I >suspect, for security reasons (since the thinner we spread our autobuilder >network, the more danger there is, statistically, of a trojan being >injected), so it may be that in most cases no more than N+1 would actually >be allowed at any one time. The scalability issue can be solved, either with connection caching or maybe some other way. The security argument seems a little thin, to be honest - we already have binaries built and uploaded from developers' machines all over the world. So long as an arch team can communicate effectively, I'd push for a greater number of buildds for better resiliency. >> Also, a common complaint I've heard recently is that several of the >> SCC architecture buildd problems were being caused by lack of >> time. Not machines, not offered effort, but lack of time to do buildd >> setup/maintenance work by central buildd admins. Note: I'm NOT >> attributing this to malice or incompetence - people need to sleep and >> have some semblance of a life outside Debian, after all! m68k has >> shown that a larger team of buildd admins and machines can work >> effectively, allowing the least powerful of our architectures to keep >> up admirably well in recent months. Is the plan for etch to still >> continue to run with centrally-controlled buildds, or will it be >> opened up? > >The partial answer I was given for this was to wait and see how well >ftp-master scales once connection caching is in place, before committing to >giving porters free reign to plug new autobuilders into the network. OK, cool. I await the results of the changes with interest. :-) Thanks, -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Welcome my son, welcome to the machine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On 05-Mar-17 00:10, Scott James Remnant wrote: > No, I would just prefer consistency. You've deliberately chosen an > architecture name that's jarringly different from your 32-bit variant; > that's a rather bold thing to do, and I think you need to justify that. The decision to use the name 'ppc64' is based on the LSB and it is consistent with the decision of all other distributions I know of. > Obviously I have no power to overrule you on your choice of architecture > name, but I'd like to try and appeal to some common sense in you, if > there is any. I think that common sense would be to follow the LSB and to use the LSB conforming package name that all other distributions use. Again, the name of the port could be changed and the existing archive could be recompiled. But I think that people would later come to the conclusion that deviating from the standard was a bad thing in this case. I did not yet hear a single vote for the package name 'powerpc64' from anybody who is actively involved in the p(ower)pc64 port. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
Ben Collins wrote: >On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote: >> In article <[EMAIL PROTECTED]> you write: >> >I have an e3500 to replace both auric and vore (and the raid), but I >> >haven't gotten an ok from James to do so yet. >> >> That would cut the number of sparc buildds down to one, when two are >> required for RC archtectures under the new proposal. > >That's ok because two buildd's can run on the one machine. It has 6 cpu's. That'll help to get things built, yes. :-) However, part of the point of the N+1 specification is for redundancy/resiliency... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Dasmohapatra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to join a team
Thomas wrote: >Tollef Fog Heen <[EMAIL PROTECTED]> writes: > >> Most of the teams here work by the principle of «submit working >> patches and be useful». I don't think having a formalised process to >> join the CD-image team (randomly chosen) is very useful. > >BTW, I hope to be able to make a web page that explains whatever I >learn from this thread, so it's not just idle. > >I presume the following is true (but different teams are different, so >that's what I'm looking for, what is different) for the teams you are >speaking of: > >1) Anyone can join the mailing list and participate in the > discussions; >2) Anyone can propose patches; >3) Only some people can install the patches. > >Number (2) is true everywhere; number (1) is true only for some teams, >and number (3) raises the question: who chooses who can install the >patches directly and who cannot? To continue using the CD team as an example: 1) We have people from all over participating - d-i people, d-cd people, users, developers 2) Anyone can suggest changes/patches 3) CVS commit access is open to all DDs If more people want to come and help get CDs and DVDs done, please dive in. Some of the effort is centralised so far (like creating the official images), but we'd love to share that out when possible. And of course there's always more work in testing... :-) -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Thu, 2005-03-17 at 01:57 +0100, Andreas Jochens wrote: > On 05-Mar-17 00:10, Scott James Remnant wrote: > > No, I would just prefer consistency. You've deliberately chosen an > > architecture name that's jarringly different from your 32-bit variant; > > that's a rather bold thing to do, and I think you need to justify that. > > The decision to use the name 'ppc64' is based on the LSB and it is > consistent with the decision of all other distributions I know of. > But it isn't consistent with Debian's previous decision on the PowerPC port. In particular, the LSB mandates "ppc32" for what we call "powerpc". Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: about Nybbles : how to keep all those archs releasable complying with the Vancouver Project
I demand that Marc Haber may or may not have written... > On Wed, 16 Mar 2005 14:02:20 +0100, Frank Küster <[EMAIL PROTECTED]> > wrote: >> luna <[EMAIL PROTECTED]> wrote: >>> We all have seen this proposal for "dropping architecture" and a lot of >>> us are crying because their favourite pet architecture will be dropped. >> Wrong. My favourite arch is i386, and still I dislike very much the >> original plan. > I have to agree with Frank. I have a Sparc machine in my basement for > years, have never booted it, and doubt that I'll actually be coming around > to working with that box in the foreseeable future. I have thus never used > an architecture other than i386, but I find the availability of my > preferred platform on other architectures an important thing nevertheless. Had I an Iyonix, I'd be quite likely to set it up as a dual-boot machine. Perhaps one day, when I can get hold of one second-hand to replace this Risc PC... -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys) The Boy Scouts have adult leadership. The Coast Guard doesn't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
I demand that Adrian Bunk may or may not have written... [snip] > And without testing, all these transition problems wouldn't exist. And without testing, there are those who currently use testing who'd use stable instead, or possibly go elsewhere. (I'm currently using testing. Updating an installation from unstable over a dial-up connection isn't /quite/ what I want...) [snip] -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | http://www.youmustbejoking.demon.co.uk/progs.linux.html> Wit has truth in it. Wisecracking is simply calisthenics with words. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, Mar 16, 2005 at 11:07:56AM -0500, Stephen Frost wrote: > * Kyle McMartin ([EMAIL PROTECTED]) wrote: > > On Wed, Mar 16, 2005 at 03:06:19PM +, Rob Taylor wrote: > > > Yes, that makes total sense. Would there likely be major objections to > > > this? > > > > > > > Even less (likely zero) testing of packages by the maintainer before they > > upload? This is definitely a serious problem... > > > > Famous last words... > > "Oh, I'll just make this one change, rebuild source and upload." > > What about requiring a binary upload with the source upload, but then > rebuilding the binary on the buildd of the uploaded binary *anyway*? > Having the extra check that it actually *builds* on that buildd would be > a good thing, the security team will probably need it once it's stable.. Was proposed in the last major "binary vs. source" flamewa^W discussion, and met with, IIRC, the resounding sound of crickets chirping. However, I think that one of the statements which have been made about "Why can't random porter DDs build and upload if the wanna-build admins don't add a buildd" - to wit, "It is important to make sure *the* buildds can rebuild it if we have to do a security update" - should apply to our favorite popconular arch just as much as any other. Which is to say, "building from source on i386" should be a required step whether or not it was uploaded that way. On the flip side, having a DD at least demonstrate that *some* system is able to build the thing without blowing chunks can potentially save us some number of "Augh, don't people even CHECK this stuff anymore?" on the part of the buildd signers, and preserving their sanity is a Good Thing. Or, in other words, I rather like the idea of "You are required to upload at least one copy of each binary, but all binaries will be built from source on the buildds." The one situation that would need to be addressed (but this is true today, and is a social issue that requires other things to solve) would be folks firing off a source+binary upload, and then immediately uploading a binary-only upload as the "port" upload. Whether "don't do that" is sufficient, or we should limit binary uploads to a separate "trusted buildd admin" keyring, or something else entirely, well... I'm sure we can find a good solution, I don't know which one would be best. Hmmm. I may just have found a wishlist item for debpool, though. :) -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Bits (Nybbles?) from the Vancouver release team meeting
Hi, Karsten Merker wrote:
> On Wed, Mar 16, 2005 at 02:02:09PM +0100, Sven Luther wrote:
>
>> For that matter, it would probably make sense to drop 2.4 kernels fully
>> in the not so far future.
>
> I would like to strongly advise against that - 2.6 does not even work
> properly on several i386 machines for me, not to talk about other
> architectures.
Hopefully those problems will get fixed in the next year or so.
Otherwise the maintainers of these kernels will be in the same awkward
situation m68k is in -- it still needs 2.2 kernels for Mac because nobody
bothered to forward-port the architecture's bits to 2.4 until it was
basically too late.
Given the pace 2.6 is progressing at, I expect there not to be a "too
late" in the next months.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
Hi, Scott James Remnant wrote:
> You've deliberately chosen an
> architecture name that's jarringly different from your 32-bit variant;
> that's a rather bold thing to do, and I think you need to justify that.
>
He did, didn't he? LSB conformity, for one. No Debian precedent for
appending "64" to the 32-bit name, for another.
No Debian tool depends on s/32/64/ or s/$/64/. As for me, I type "ppc"
instead of "powerpc" very often, even though I should know better by now.
In light of these facts (OK, the last one is a bit spurious, but still),
please justify asking Andreas for a strong justification. ;-)
> Obviously I have no power to overrule you on your choice of architecture
> name, but I'd like to try and appeal to some common sense in you, if there
> is any.
That last half-sentence was uncalled-for.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
Ben Collins <[EMAIL PROTECTED]> writes: > On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote: > > In article <[EMAIL PROTECTED]> you write: > > >I have an e3500 to replace both auric and vore (and the raid), but I > > >haven't gotten an ok from James to do so yet. > > > > That would cut the number of sparc buildds down to one, when two are > > required for RC archtectures under the new proposal. > > That's ok because two buildd's can run on the one machine. It has 6 cpu's. That cannot be the requirement. The point has to be an additional and independently functioning piece of hardware. If the disk blows or it is compromised or something, the others should be able to continue. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
Hi, Ola Lundqvist wrote:
> Hello
>
> On Wed, Mar 16, 2005 at 03:27:27PM +0100, Matthias Urlichs wrote:
>> Hi, Rob Taylor wrote:
>>
>> > Do you think it might be better have a trusted builder keyring, with
>> > strict rules on what makes a trusted builder (it seems rather a
>> > different set of issues to that addressed by the DD criterion)?
>>
>> That makes sense -- but only if Debian switches to source-only uploads.
>
> Why is source-only uploads needed for this?
>
I didn't say it was needed, I said it doesn't make sense.
Either anybody can build and upload anything -- then strict rules
and checks are overkill.
Or packages are built by firewalled trusted build systems. That doesn't
make sense to do that only when we feel like it -- if we have to have
"build machines need to be secure systems" rules, these should be applied
to every package, with the possible exclusion of "real" binNMUs.
At the moment we basically trust every DD not to have a compromised
machine (or, horrors, a malicious DD) -- worse, we ignore the possibility
of binary Trojans, which aren't evident from source code and thus much
harder to track down if something happens. I think that, long-term, this
might be a bit too risky.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .d.o machines which are down (Re: Questions for the DPL candidates)
On Tue, Mar 15, 2005 at 08:44:49PM -0800, Blars Blarson wrote: > In article <[EMAIL PROTECTED]> you write: > >I have an e3500 to replace both auric and vore (and the raid), but I > >haven't gotten an ok from James to do so yet. > > That would cut the number of sparc buildds down to one, when two are > required for RC archtectures under the new proposal. That's ok because two buildd's can run on the one machine. It has 6 cpu's. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
Adrian Bunk <[EMAIL PROTECTED]> writes:
> It seems what makes Thomas suspicous is that of all current ports of
> Debian (Linux, *BSD, GNU/Hurd), the only one that might be affected is
> GNU/Hurd - this requirement is therefore either void for all current
> Debian ports or it was meant specifically against GNU/Hurd.
I'm not so much suspicious as simply asking what the requirement means
("firewalling support" could refer to many different features), and
also why it was added.
I'm assuming that the requirements were written for their own sake,
because they represent important things that are relevant to the
particular cases they cover, and not because the authors of the
proposal were trying to achieve some pre-determined list of archs.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Thu, Mar 17, 2005 at 12:24:00AM +0100, Marco d'Itri wrote: > On Mar 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > > > One of the conditions for SCC is "fully functioning Unix, including > > > > DNS and firewall support." What specifically is intended by "firewall > > > > support"? > > > I think that simple ACLs are the bare minimum. > > Ok, can you point me at the specific feature, and why is this feature > I think that the minimum is per-interface permit/deny ACLs which could > match at least on IP protocol number, TCP/UDP ports and ICMP types. > > > important for packaging in SCC? > Because Debian should not waste resources to support a toy OS (in this > case defined as one not secure enough to stay on the internet for real > work). The statement in the announcement was: - the port must include basic unix functionality, e.g resolving DNS names and firewalling "resolving DNS names" is obviouly required. But why is "firewalling" required? It's the question what a "toy OS" is, and whether a "toy OS" might be supported by Debian. It seems what makes Thomas suspicous is that of all current ports of Debian (Linux, *BSD, GNU/Hurd), the only one that might be affected is GNU/Hurd - this requirement is therefore either void for all current Debian ports or it was meant specifically against GNU/Hurd. Thomas' question is simply whether five of your six DPL candidates have signed that they want to kick GNU/Hurd even out of the proposed SCC archive or not. Steve's announcement only listed actions without giving the rationale for each of them, and it would therefore be required that someone of the 12 people who signed this announcement should clarify this point. > ciao, > Marco cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling ...
Hi, David Schmitt wrote:
> Collecting tidbits of
> information concerning the various packages rotting in NEW and making that
> information public.
A list of packages-in-NEW is available on the Web, including binary
package names, bugs closed, et al.
Nothing more can be done by the average bored DD, since they cannot access
these packages, hence not do most of the necessary checks.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Thu, 2005-03-17 at 00:31 +0100, Andreas Jochens wrote: > On 05-Mar-16 22:24, Scott James Remnant wrote: > > > So you would add 'powerpc64' support to dpkg if the port changes its > > > package name accordingly? > > > > > Yes, that'd be applied to the 1.13 branch straight away. > > > > > However, I still do not understand why you and/or the Project Leader > > > want to override the decision of the porters and choose a different name > > > than the LSB specifies. I am not saying that Debian should always follow > > > the LSB blindly, but I cannot see a good reason for deviating from the > > > LSB in this case. > > > > > Because it's a 64-bit version of an already supported architecture. > > Having "ppc" and "ppc64" would be fine, as would having "powerpc" and > > "powerpc64". Having "powerpc" and "ppc64" is inconsistent. > > Inconsistent like i386/amd64 or s390/s390x? There is no rule which > says that for a 64 bit architecture a '64' suffix has to be appended. > There is not even a single case in Debian where this has been done, > as far as I know. > Indeed not, because we're only really starting to see both 32-bit and 64-bit variants of architectures in Debian. > Moreover, I seriously doubt that this is an honest argument. I think you > just want to decide the architecture name yourself. > No, I would just prefer consistency. You've deliberately chosen an architecture name that's jarringly different from your 32-bit variant; that's a rather bold thing to do, and I think you need to justify that. Obviously I have no power to overrule you on your choice of architecture name, but I'd like to try and appeal to some common sense in you, if there is any. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Bug#299856: ITP: coils -- [Biology] prediction of coiled-coil secondary structure
Package: wnpp Severity: wishlist * Package name: coils Version : no version Upstream Author : Rob Russell <[EMAIL PROTECTED]> * URL : http://www.russell.embl.de/cgi-bin/coils-svr.pl * License : GPL Description : [Biology] prediction of coiled coil secondary structure Protein sequence based prediction of coiled coil secondary structures. The algorithm is described in Lupas, van Dyke & Stock, Predicting coiled coils from protein sequences Science, 252, 1162-1164, 1991. A preliminary lintian-free Debian package is at http://bioinforamtics.pzr.uni-rostock.de/~moeller/debian/coils Sponsors welcome. Steffen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On 05-Mar-16 22:24, Scott James Remnant wrote: > > So you would add 'powerpc64' support to dpkg if the port changes its > > package name accordingly? > > > Yes, that'd be applied to the 1.13 branch straight away. > > > However, I still do not understand why you and/or the Project Leader > > want to override the decision of the porters and choose a different name > > than the LSB specifies. I am not saying that Debian should always follow > > the LSB blindly, but I cannot see a good reason for deviating from the > > LSB in this case. > > > Because it's a 64-bit version of an already supported architecture. > Having "ppc" and "ppc64" would be fine, as would having "powerpc" and > "powerpc64". Having "powerpc" and "ppc64" is inconsistent. Inconsistent like i386/amd64 or s390/s390x? There is no rule which says that for a 64 bit architecture a '64' suffix has to be appended. There is not even a single case in Debian where this has been done, as far as I know. Moreover, I seriously doubt that this is an honest argument. I think you just want to decide the architecture name yourself. I am saying this because a few month ago you wrote this: On 04-Nov-24 08:29, Scott James Remnant wrote: > Please file this request with the powerpc64 port team, rather than with > the dpkg maintainer. > > Support for this architecture will not be included until the port team > have picked a name for it. This seemed to imply that you would respect the decision of the porters and that you do not want to decide the name yourself. Now that there is a decision and a whole archive with 85% of the packages compiled, you do not accept that decision. You are basically saying: "Take the name 'powerpc64' which I like best - or that architecture will not be supported." But you do not have any convincing reason for not accepting the choosen name. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More bits from SPI
On Wed, 2005-03-16 at 09:20 -0600, John Goerzen wrote: > Due to a scheduling conflict with our regular meeting date of April > 19, the Board elected to meet on April 12 instead. The time will be > the same as always, 19:00 UTC. > > Please note: this will be a different *local* time for people in much > of the world due to daylight saving time. (UTC does not change for > DST). > > Please double-check the time in your specific timezone. > This sounds like a good opportunity to advertise gworldclock :) It lets you display the time in different timezones (for instance, your local time, and UTC), and has a "rendezvous" function where you can specify the time&date in one of the timezones and find out what time (& date) that will be in the others. It uses standard TZ functionality (/usr/share/zoneinfo/, etc), which accounts for daylight savings times. Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping testing (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Wed, Mar 16, 2005 at 07:51:16PM +0100, David Schmitt wrote: > On Wednesday 16 March 2005 18:12, Adrian Bunk wrote: > > I already sent two mails [1,2] where I expressed my opinion that dumping > > testing might be an option since it's the main reason for the underlying > > problems that seem to cause the proposed removal of two third of the > > Debian architectures from the Debian releases while it hasn't proven to > > bring any real benefits for the release. > > > > The interesting thing is that while people answered to other parts of > > these emails, noone said anything about my points regarding testing - > > neither in favor nor against them. > > You fail to list and address the points testing claims to address. > > Therefore I judge this part of your otherwise quite sensible mail ranting I > don't have to argue for or against because it has no real content except > expressing your personal animosities. > > Ouch. Seems like I fell into the communication trap myself. Here is a weak > try > at refuting your proposal: > > To archive a stable release, arches have to be in sync, there should be only > a > single version of every library and packages have to be installable. This > seem to be the problems I believe testing was designed to solve. Incidentally > this almost the list of "problems" you identify being the cause of testings > problems. Kinda matches. Going back to a frozen-only release cycle would > ignore these problems until half a year before the release. Then the same > work that is now done for testing would have to be done anyways: arches > brought to sync, libraries transitioned and package installability > guaranteed. I agree with you that testing helps with some problems like getting packages in sync and installable. But currently testing needs regular manual help by the five members of the release team to keep on running. Exactly the same amount of work they are currently doing [1] might bring the same effect without testing since this information (and much more) is also available without testing. "libraries transitioned" is a big point against testing: Transitions of API-compatible libraries are a pain _only_ due to testing. In unstable, such a transition can easily be done within a few days. But the transition to testing requires that all affected packages (which might be 100 source packages for some transitions) are ready _at the same time_, more exactly: - each package mustn't have more more RC bugs than the testing scripts estimate for the version in testing - each package must be built on every single architecture - the dependencies of every single affected package must be met after the transition - this way, often several transition generate a mega-transition of packages that have to go into testing at the same time Even if all this was fulfilled, a manual hint is still required. And for bigger transitions, there are always manual adjustments required since these requirements aren't fulfillable in practice. Check how many of the announcements of your release team mention as an important point that this transition was finally finished or that transition is the next important milestone. And without testing, all these transition problems wouldn't exist. > Thus I make two observations: > > 1) Only dropping testing would increase the risk (by delaying the detection > of > the problems) without noticeable reductions in amount of work (if Debian > still aims at a 12-18 month release cycle) As I tried to explain above, the same information is already available elsewhere and the same amount of work currently spent into testing might as well suffice to treat them equally. > 2) Providing a better alternative is more efficiently done by those > dissatisfied with the status-quo (i.e. you) as opposed to those who worked > hard to establish the status-quo as solution to their problems (i.e. > ftp-master and release team). Was this meant ironically? In case it was: If you work in a field, it often happens (and it's unfortunately quite normal) that you get a narrow view. > Thank you for still caring about Debian! > > Regards, David cu Adrian [1] as already said: I do not deny that the release team does much work -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On Wed, 2005-03-16 at 23:59 +0100, Andreas Jochens wrote: > On 05-Mar-17 09:46, Benjamin Herrenschmidt wrote: > > Have we any proper way of doing multiarch setups ? The "proper" way to > > do ppc64 is to have both archs libs and 32 bits userland for most > > things, as ppc64 native code is slightly slower. > > Detailed measurements of 32 bit vs. 64 bit code for different > applications have yet to be made. One of the purposes of the native 64 > bit approach is that such comparisons will become easily possible. > Without having native 64 bit libraries and binaries this would be just > guesswork. Note that it's not just guesswork. We've been there at IBM, though I could install gentoo64 and redo a bunch of measurement one of these days. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On Wed, 2005-03-16 at 23:59 +0100, Andreas Jochens wrote: > On 05-Mar-17 09:46, Benjamin Herrenschmidt wrote: > > Have we any proper way of doing multiarch setups ? The "proper" way to > > do ppc64 is to have both archs libs and 32 bits userland for most > > things, as ppc64 native code is slightly slower. > > Detailed measurements of 32 bit vs. 64 bit code for different > applications have yet to be made. One of the purposes of the native 64 > bit approach is that such comparisons will become easily possible. > Without having native 64 bit libraries and binaries this would be just > guesswork. Fairly easy to do using gentoo as a reference :) The ppc64 native port may have an "academic" interest, but as I wrote, I'd rather concentrate on having a biarch setup for now. > > Also make sure the compiler is biarch as the kernel build will soon > > require this. > > The compiler in the current ppc64 archive is fully biarch, i.e. it can > produce 64 bit and 32 bit binaries. There is also a 64 bit and a 32 bit > glibc version in the archive. Good. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Wed, 2005-03-16 at 22:24 +, Scott James Remnant wrote: > On Wed, 2005-03-16 at 23:14 +0100, Andreas Jochens wrote: > > > On 05-Mar-16 22:01, Scott James Remnant wrote: > > > On Wed, 2005-03-16 at 22:48 +0100, Andreas Jochens wrote: > > > > > > My concern is the same as that of the Project Leader, that the existing > > > powerpc port is called "powerpc" -- and that we should at least try to > > > be consistent with already chosen architecture names. > > > > > So you would add 'powerpc64' support to dpkg if the port changes its > > package name accordingly? > > > Yes, that'd be applied to the 1.13 branch straight away. > > > However, I still do not understand why you and/or the Project Leader > > want to override the decision of the porters and choose a different name > > than the LSB specifies. I am not saying that Debian should always follow > > the LSB blindly, but I cannot see a good reason for deviating from the > > LSB in this case. > > > Because it's a 64-bit version of an already supported architecture. > Having "ppc" and "ppc64" would be fine, as would having "powerpc" and > "powerpc64". Having "powerpc" and "ppc64" is inconsistent. Then "fix" powerpc :) And use alias tricks if you can to keep the old name. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Mar 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > One of the conditions for SCC is "fully functioning Unix, including > > > DNS and firewall support." What specifically is intended by "firewall > > > support"? > > I think that simple ACLs are the bare minimum. > Ok, can you point me at the specific feature, and why is this feature I think that the minimum is per-interface permit/deny ACLs which could match at least on IP protocol number, TCP/UDP ports and ICMP types. > important for packaging in SCC? Because Debian should not waste resources to support a toy OS (in this case defined as one not secure enough to stay on the internet for real work). -- ciao, Marco signature.asc Description: Digital signature
Re: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
> However, I still do not understand why you and/or the Project Leader > want to override the decision of the porters and choose a different name > than the LSB specifies. I am not saying that Debian should always follow > the LSB blindly, but I cannot see a good reason for deviating from the > LSB in this case. Me neither... especially since all other distros, afaik, call it ppc64... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On 05-Mar-17 09:46, Benjamin Herrenschmidt wrote: > Have we any proper way of doing multiarch setups ? The "proper" way to > do ppc64 is to have both archs libs and 32 bits userland for most > things, as ppc64 native code is slightly slower. Detailed measurements of 32 bit vs. 64 bit code for different applications have yet to be made. One of the purposes of the native 64 bit approach is that such comparisons will become easily possible. Without having native 64 bit libraries and binaries this would be just guesswork. > Also make sure the compiler is biarch as the kernel build will soon > require this. The compiler in the current ppc64 archive is fully biarch, i.e. it can produce 64 bit and 32 bit binaries. There is also a 64 bit and a 32 bit glibc version in the archive. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-ppc64-devel] Re: Bug#263743: Call For Help - Please support the ppc64 architecture
> Anyway, the biarch approach will also need a 'dpkg' which supports > separate 64-bit ppc64 packages in the end. > > What are your concerns? Do you refuse to support a native 64-bit > powerpc64/ppc64 port? Or do you want a different name for it? I think there is not real point in doing so, or mostly academic, but feel free to do it anyway. I'd rather see more efforts be put in the biarch port for now though. And as I wrote earlier, just beware that the compiler has to be biarch in both cases or you'll have a hard time building kernels. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Mar 16, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > > > One of the conditions for SCC is "fully functioning Unix, including > > DNS and firewall support." What specifically is intended by "firewall > > support"? > I think that simple ACLs are the bare minimum. Ok, can you point me at the specific feature, and why is this feature important for packaging in SCC? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Required firewall support
On Mar 16, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > One of the conditions for SCC is "fully functioning Unix, including > DNS and firewall support." What specifically is intended by "firewall > support"? I think that simple ACLs are the bare minimum. > Those who felt this necessary, can you please describe which specific > features you believe are necessary, and why? Only a toy OS like Windows need an external firewall to protect them. -- ciao, Marco signature.asc Description: Digital signature
Re: [Debian-ppc64-devel] Call For Help - Please support the ppc64 architecture
On Wed, 2005-03-16 at 20:27 +0100, Andreas Jochens wrote: > Hello, > > This is a call for help from the 'ppc64' porters. > > On 05-Mar-14 16:14, Martin Michlmayr wrote: > > Also, as with the amd64 port, there is disagreement about the name. > > While ppc64 would be nicer and in line with the LSB, our current > > PowerPC port is called powerpc and therefore it would make more sense > > to call the 64 bit port powerpc64. > > There has been a decision of the Debian Technical Committee concerning > the name of the amd64 port which basically says that the porting team > should decide on the architecture name generally (see [1]). > > The ppc64 porters decided to use the name 'ppc64' as the package > name a few month ago. > > .../... It's a fully 64 bits setup as it seems ? That is rather inefficient. Have we any proper way of doing multiarch setups ? The "proper" way to do ppc64 is to have both archs libs and 32 bits userland for most things, as ppc64 native code is slightly slower. I have repeated that over and over again but it seems I have been ignored so far... Also make sure the compiler is biarch as the kernel build will soon require this. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of buildds?
On Wed, Mar 16, 2005 at 10:00:15AM -0800, Thomas Bushnell BSG wrote: > > Either you trust me as a person or you trust some kind of software snippet, > > aka gpg key. > I don't know who you are. The snippet tells me who you are. even with that snippet you don't know me. You just know, that there's a person that declares to be me... maybe it's my twin brother using my name and id card... -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Wed, Mar 16, 2005 at 10:24:04PM +, Scott James Remnant wrote: > Because it's a 64-bit version of an already supported architecture. > Having "ppc" and "ppc64" would be fine, as would having "powerpc" and > "powerpc64". Having "powerpc" and "ppc64" is inconsistent. and deviating from an already established standard isn't? i'm wondering what the actual benefits of having a similarly (powerpc/powerpc64) named port are, apart from being aesthetically pleasing. sean -- signature.asc Description: Digital signature
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On 05-Mar-16 22:01, Scott James Remnant wrote: > On Wed, 2005-03-16 at 22:48 +0100, Andreas Jochens wrote: > > > On 05-Mar-16 21:16, Scott James Remnant wrote: > > > On Wed, 2005-03-16 at 20:27 +0100, Andreas Jochens wrote: > > > > > > > This is a call for help from the 'ppc64' porters. > > > > > > > Which group? According to Sven Luther's e-mail to debian-devel there > > > are currently two competing efforts for this port. > > > > What are your concerns? Do you refuse to support a native 64-bit > > powerpc64/ppc64 port? Or do you want a different name for it? > > > My concern is the same as that of the Project Leader, that the existing > powerpc port is called "powerpc" -- and that we should at least try to > be consistent with already chosen architecture names. > > amd64 was reasonably unique in that it wasn't derived from any existing > architecture name. And in fact, in that case, I championed using the > LSB-mandated name (or as close thereto). > > If anything, that's ruled that Debian does not attempt harmony with LSB > names for architectures. So you would add 'powerpc64' support to dpkg if the port changes its package name accordingly? It would be possible to change the name to 'powerpc64' without too many problems. The port does not have many users yet and it will take only three or four weeks to recompile the current archive with a new package name. However, I still do not understand why you and/or the Project Leader want to override the decision of the porters and choose a different name than the LSB specifies. I am not saying that Debian should always follow the LSB blindly, but I cannot see a good reason for deviating from the LSB in this case. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, 16 Mar 2005 17:19:31 +0100, Thiemo Seufer uttered
> AFAIR it wasn't fixed but dropped, nobody seemed to care about
> sun4c any more.
>
You need to check your assertions better. Joshua Kwan has done a hell
of a lot of work with sparc{32,64} recently. Anyway, sun4c is not the
only sparc32 sub-arch, there is also sun4, sun4d and sun4m.
[EMAIL PROTECTED]:~% apt-cache search kernel-image | grep sparc32 |
tail -n 4
kernel-image-2.4.27-2-sparc32 - Linux kernel binary image for sun4c,
sun4m and sun4d
kernel-image-2.4.27-2-sparc32-smp - Linux kernel binary image for SMP
sun4m and sun4d
kernel-image-2.6-sparc32 - Linux 2.6 kernel binary image for sparc32
systems
kernel-image-2.6.8-2-sparc32 - Linux kernel binary image for
UltraSPARC (sparc32) systems
It seems there is a thinko in the short description for
kernel-image-2.6.8-2-sparc32, but the long description is correct.
Cheers,
--
Steve
I may be love's bitch, but at least I'm man enough to admit it.
- Spike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Wed, 2005-03-16 at 23:14 +0100, Andreas Jochens wrote: > On 05-Mar-16 22:01, Scott James Remnant wrote: > > On Wed, 2005-03-16 at 22:48 +0100, Andreas Jochens wrote: > > > > My concern is the same as that of the Project Leader, that the existing > > powerpc port is called "powerpc" -- and that we should at least try to > > be consistent with already chosen architecture names. > > > So you would add 'powerpc64' support to dpkg if the port changes its > package name accordingly? > Yes, that'd be applied to the 1.13 branch straight away. > However, I still do not understand why you and/or the Project Leader > want to override the decision of the porters and choose a different name > than the LSB specifies. I am not saying that Debian should always follow > the LSB blindly, but I cannot see a good reason for deviating from the > LSB in this case. > Because it's a 64-bit version of an already supported architecture. Having "ppc" and "ppc64" would be fine, as would having "powerpc" and "powerpc64". Having "powerpc" and "ppc64" is inconsistent. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: [RFC] OpenLDAP automatic upgrade
Hi Quanah, On Tue, Mar 15, 2005 at 01:07:29PM -0800, Quanah Gibson-Mount wrote: > I currently maintain Stanford University's directory service, which is > based on OpenLDAP. I also am a member of the OpenLDAP core team, and I > hold down another job with Symas Corporation doing a variety of tasks, but > most relevantly benchmarking their OpenLDAP based product and teaching > classes on running and configuring OpenLDAP based directory services. Whew! > I have some comments on your upgrade plans listed here... ;) Great, fire! :) > Going from OpenLDAP 2.0 to 2.1 was non-trivial. Going from 2.0 to 2.2 is > very complex. Going from 2.1 to 2.2 is also non-trivial. Talk about stating the obvious ;) > Some issues to consider for the 2.1 to 2.2 process: > > 1) OpenLDAP 2.1 generally used BDB 4.1. OpenLDAP 2.2 should only be used > with BDB 4.2.52+patches when using bdb or hdb as the backend (Ignore the > documentation with OpenLDAP 2.2.23 stating it requires BDB 4.3, that > statement is incorrect). Yes, I accidently built it with BDB 4.2 and it worked. But - what is the problem with 4.3? And what patches will be needed for 4.2.52 - it's not like I can go and change the libdb4.2 packages, I'll have to ask the maintainer for that favour. > 2) Several changes were made to how ACL's were handled between OpenLDAP > 2.1 and OpenLDAP 2.2. You cannot simply upgrade the database and expect > everything to work. The ACL's must also be reviewed and correctly > updated. Surely. For simple installations it might work without that though and not every slapd package is installed to run the Stanford directory server. :) > 3) OpenLDAP bdb/hdb based databases are highly dependent on a well > configured DB_CONFIG file for the particular database in question. Simply > doing a slapcat/slapadd is really not sufficient for ensuring that the > resulting directory server will run well. A poorly configured > DB_CONFIG file can lead to the slapadd process taking hours or days. In > addition, there are two flags that should be set in the DB_CONFIG file > before the slapadd takes place, that should then be commented out once the > add is completed. Erm, the upgrading process is already really complex, and I fear I don't feel like implementing this in maintainer scripts. Which options are you thinking of, BTW? And the documentation for DB_CONFIG is really lacking as well, let's hope somebody wakes up the sleepy cats ;) I wonder why the OpenLDAP server can not tune most of the BDB parameters itself during runtime. It has by far more information at its hands than the Debian maintainer scripts have. > 4) If someone is using ldbm as their backend database, I'd throw a warning > noting that bdb/hdb are the preferred backends of OpenLDAP. ldbm is rife > with issues such as not catching data inconsistencies, leading to poor > directory performance and potential data loss. Where is the difference to bdb? ;-) > 5) I don't know what version of OpenLDAP 2.2 that debian is considering > for inclusion, but I wouldn't go with anything less than OpenLDAP 2.2.23 > based on my experiences. That's what I am working on. > Essentially, the process of upgrading a directory service to OpenLDAP 2.2 > is generally something that should be done by the person who runs the > service. There are a host of issues that must be addressed to properly > upgrade. That's for sure but I want to be able to do automatic upgrades for the simple cases. And at least help the admin by dumping the directory before starting the upgrade and taking care of the old database files in case he decides to downgrade again later :) Thanks for your comments Torsten signature.asc Description: Digital signature
Re: [RFC] OpenLDAP automatic upgrade
On Tue, Mar 15, 2005 at 05:04:26PM -0800, Quanah Gibson-Mount wrote: > >> The first. Basically upstream changes the database format quite often. > >> I am even not entirely sure if the database format stays compatible in > >> the 2.1 or 2.2 line but I'd expect it to. The 2.2.23 Debian packages > >> uses libdb4.3 instead of libdb4.2 as used in 2.1.x so the reload has to > >> be done in any case. > > Just to be very clear on this again. You do *not* want to run OpenLDAP > against BDB 4.3. Releasing Debian with its OpenLDAP compiled against BDB > 4.3 would be a serious mistake. And this is why? So far 2.2.23 with libdb4.3 seems to be much more stable than anything before. Greetings Torsten signature.asc Description: Digital signature
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On 05-Mar-16 21:16, Scott James Remnant wrote: > On Wed, 2005-03-16 at 20:27 +0100, Andreas Jochens wrote: > > > This is a call for help from the 'ppc64' porters. > > > Which group? According to Sven Luther's e-mail to debian-devel there > are currently two competing efforts for this port. There is only one native ppc64 port. There are people like Sven Luther and others who try to convert the current powerpc port into a biarch port, which is still mainly 32-bit based. This approach intends to add a 64-bit kernel and a biarch toolchain to the powerpc port and will allow the installation of selected 64-bit libraries and 64-bit binaries besides the 32-bit ones. This is somewhat similar to the i386 port which has already been extended with a 64-bit (amd64) kernel, a biarch (gcc-3.4) toolchain and some amd64 64-bit libraries. This kind of 64-bit extension of a 32-bit port is not the same thing as a native 64-bit port. Anyway, the biarch approach will also need a 'dpkg' which supports separate 64-bit ppc64 packages in the end. What are your concerns? Do you refuse to support a native 64-bit powerpc64/ppc64 port? Or do you want a different name for it? Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Wed, 2005-03-16 at 22:48 +0100, Andreas Jochens wrote: > On 05-Mar-16 21:16, Scott James Remnant wrote: > > On Wed, 2005-03-16 at 20:27 +0100, Andreas Jochens wrote: > > > > > This is a call for help from the 'ppc64' porters. > > > > > Which group? According to Sven Luther's e-mail to debian-devel there > > are currently two competing efforts for this port. > > What are your concerns? Do you refuse to support a native 64-bit > powerpc64/ppc64 port? Or do you want a different name for it? > My concern is the same as that of the Project Leader, that the existing powerpc port is called "powerpc" -- and that we should at least try to be consistent with already chosen architecture names. amd64 was reasonably unique in that it wasn't derived from any existing architecture name. And in fact, in that case, I championed using the LSB-mandated name (or as close thereto). If anything, that's ruled that Debian does not attempt harmony with LSB names for architectures. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Buildd redundancy (was Re: Bits (Nybbles?) from the Vancouver...)
Ingo Juergensmann wrote: On Wed, Mar 16, 2005 at 12:20:34AM -0800, Blars Blarson wrote: If we are going to require redundancy, I think we should do it better and add: - at least two buildd administrators *nod* - systems located in at least two different facilities (different cities and backbones if at all possible) This allows the buildd administrator to take vacations, etc. This allows for redundancy in case of fire, flood, earthquake etc. For example both public debian m68k machines are located on the same window sill at the Univ. of Duesseldorf. IMHO not the best place to position important infrastructure. I agree. A sturdy table, or even a shelf or server rack would be a much better place ;-) Just out of curiousity (and speaking as a non-DD that has been trying to follow the flood mails over the last few days), why is it that I seem to remember numerous offers of infrastructure support to Debian in the way of hosting and machines but there still appears to be a dearth of resources? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: Vancouver meeting - clarifications
El mar, 15-03-2005 a las 19:53 -0500, Joey Hess escribiÃ: > Marc Haber wrote: > > The architectures you plan to release have a working installer, > > anaconda, for years. d-i was developed to allow release of all > > architectures. You are dropping that requirement, flushing all d-i > > efforts down the drain. > > I didn't design d-i, begin to implement it, or lead the d-i project > because anaconda lacked support for architecture $FOO. I did so because > I saw the need for a unique installer to be developed for Debian that > met all of its needs. Supporting many architectures is only perhaps 10% > of those needs. And for statarting d-i I want to give you a great THANK YOU. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Bug#299830: ITP: python-beautifulsoup -- error-tolerant HTML parser for Python
Package: wnpp Severity: wishlist Owner: Decklin Foster <[EMAIL PROTECTED]> * Package name: python-beautifulsoup Version : 1.2+cvs20041017 Upstream Author : Leonard Richardson <[EMAIL PROTECTED]> * URL : http://www.crummy.com/software/BeautifulSoup/ * License : Python Description : error-tolerant HTML parser for Python The BeautifulSoup class turns arbitrarily bad HTML into a tree-like nested tag-soup list of Tag objects and text snippets. A Tag object corresponds to an HTML tag. It knows about the HTML tag's attributes, and contains a representation of everything contained between the original tag and its closing tag (if any). It's easy to extract Tags that meet certain criteria. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#299771: ITP: ttf-antp -- Antykwa Poltawskiego font family
Adam Borowski <[EMAIL PROTECTED]> schrieb: > On Wed, 16 Mar 2005, Frank Küster wrote: >> Miros/law Baran <[EMAIL PROTECTED]> schrieb: >> > The font is included in the tetex-base package, along with other Type1 >> > GUST-sponsored fonts (Antykwa Toru?ska etc.) - I think such a package >> > will be redundant. >> >> Well, tetex-base only has the afm and pfb files, along with some >> TeX-specific stuff. There are no TrueType fonts; having them might be >> worth a package. > Is it even possible to directly use TeX fonts from a high-level > GTK/whatever program without modifying the program in question? If so, > it's way too unobvious for me... Yes, at least if you substitute "Postscript Type1 fonts" for "TeX fonts". The lmodern-x11 package is an example how to do it. There's even a patch around to make a tetex-xfonts package (#138394), but we postponed this until after sarge (autumn 2004, you know?). I cannot judge whether the TTF fonts are better suited for screen representation than Type1. >> Did you submit your new hinting to the upstream authors at gust.or.pl? > Well, you're overestimating my part. What I did was _removing_ the > existing hinting, as it's worse than no hints at all. Ah, well. But that's also an improvement. It might be, however, that the existing hinting worked fine in the Type1 fonts, and just wasn't converted to TTF properly? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#299828: ITP: python-mpdclient -- Python interface to MPD (Music Player Daemon)
Package: wnpp Severity: wishlist Owner: Decklin Foster <[EMAIL PROTECTED]> * Package name: python-mpdclient Version : 0.10.0 Upstream Author : Nick Welch * URL : http://www.musicpd.org/py-libmpdclient.shtml * License : LGPL Description : Python interface to MPD (Music Player Daemon) mpdclient is a simple Python interface to MPD, the Music Player Daemon. It provides an interface analogous to the libmpdclient C library, allowing for expeditious scripting of any mpd instance and ease of MPD client development. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to join a team
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > I presume the following is true (but different teams are different, so > that's what I'm looking for, what is different) for the teams you are > speaking of: > > 1) Anyone can join the mailing list and participate in the >discussions; > 2) Anyone can propose patches; > 3) Only some people can install the patches. > > Number (2) is true everywhere; number (1) is true only for some teams, I think for most of them, the security team being the most prominent exception. > and number (3) raises the question: who chooses who can install the > patches directly and who cannot? When I got my DD account, I think it was the then most active DD on the debian-tetex-maint list who asked the DSA to put me into the group that own the teTeX CVS. And I guess today it's up to me if one more DD (Henning?) wishes to get CVS access, too. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Call For Help - Please support the ppc64 architecture
Hello, This is a call for help from the 'ppc64' porters. On 05-Mar-14 16:14, Martin Michlmayr wrote: > Also, as with the amd64 port, there is disagreement about the name. > While ppc64 would be nicer and in line with the LSB, our current > PowerPC port is called powerpc and therefore it would make more sense > to call the 64 bit port powerpc64. There has been a decision of the Debian Technical Committee concerning the name of the amd64 port which basically says that the porting team should decide on the architecture name generally (see [1]). The ppc64 porters decided to use the name 'ppc64' as the package name a few month ago. That decision was mainly based on the fact that the Linux Standard Base LSB 2.0 states that 'ppc64' is the correct package name for the architecture. Other distributions like Fedora and Gentoo also use the name 'ppc64'. The Linux kernel uses 'ppc64', while the GNU toolchain uses 'powerpc64' with 'ppc64' as an alias. In the meantime, an archive for the ppc64 port has been set up on alioth (see http://debian-ppc64.alioth.debian.org/READ_ME for details). That archive uses the name 'ppc64' as the package name. An autobuilder for ppc64 is running, which follows the Debian unstable distribution. The autobuilder is self-hosting since January 2005, i.e. it runs the ppc64 port itself. The ppc64 archive on alioth currently has more than 85% of the packages from the Debian unstable distribution compiled. That number is still (slowly) rising. Every help will be appreciated, of course. Please help the ppc64 port by including support for the ppc64 architecture in 'dpkg' and other packages. Many thanks to all package maintainers who already applied patches to their packages to support the ppc64 architecture. Regards Andreas Jochens [1] http://lists.debian.org/debian-ctte/2004/06/msg00115.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Wed, 2005-03-16 at 20:27 +0100, Andreas Jochens wrote: > This is a call for help from the 'ppc64' porters. > Which group? According to Sven Luther's e-mail to debian-devel there are currently two competing efforts for this port. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: post-sarge transitions: slang
On Wed, Mar 16, 2005 at 06:39:11PM +0100, Christian Perrier wrote: > > slang should, I hope, be a fairly small change; OTOH, we seem to still have > > conflicting slang1 and slang1a-utf8 packages in the archive (conflicting > > -dev packages at least), so it would certainly be nice to wrap this up and > > only have to carry one version of this core library for etch. > IIRC, a slang transition directly or indirectly affects D-I, am I > right? Yes, it does. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: procmail and Large File Support
Le Mer 16 Mars 2005 21:36, Ron Johnson a Ãcrit : > On Wed, 2005-03-16 at 21:18 +0100, Ola Lundqvist wrote: > > Hello > > > > On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: > > > On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: > > > > Hello. > > > > > > > > I have several reports saying procmail does not support mbox > > > > folders larger than 2GB. Questions: > > > > > > OT here, but WTF are people smoking, to have 2GB mbox files? > > > > Some people tend to have really large inboxes. I have had a number > > of customers that have several GB inbox. They tend to get quite a > > lot of attachments (reports etc) and do not have the time to delete > > mail. > > File quotas will fix that in a hurry. that's definetely a (sorry) stupid answer. anyway, it feels not very sensible to use mbox flat file and not maildir for such big mailboxes ;) -- ÂOÂ Pierre Habouzit ÂÂO OOOhttp://www.madism.org pgpDscTu7I9Fr.pgp Description: PGP signature
Re: Vancouver hierarchy - proposed terminology
Scripsit Sven Luther <[EMAIL PROTECTED]> > On Tue, Mar 15, 2005 at 09:56:03PM +, Henning Makholm wrote: >>An IRREGULAR architecture either does not make releases, or release >>according to a schedule that does not match the REGULAR one. (One >>possible instance of this is "we'll try to parallel the REGULAR >>release, but they are not going to wait for us if we blow a tyre >>along the way"). The porters must provide their own release >>management and staging area (management). > I think it would make sense to distinguish between IRREGULAR and > INDEVELOPMENT architectures here. Perhaps, but I was trying to find suitable terms for the distinctions in the Vancouver plan, not to invent my own. (And personally I hope that the eventual outcome of this discussion will be a set of rules that will allow every architecture with sufficiently dedicated porters to become REGULAR, such that the only IRREGULAR architectures will be those where the porters themselves do not think that the port is ready for a stable release yet). > That said, i just wonder if the solution to this would not simply be for the > release team to simply have one or more assistant in charge of the IRREGULAR > architectures, instead of insisting the porters do the release on their own, I understand that one of the (perceived) problems is not just lack of manpower in the release team, but the fact that migration to REGULAR testing is unacceptably slow if it has to wait for architectures that do not satisfy REGULAR criteria (whatever these might end up being after discussion). > Your proposal also ignores security team's requirement which may be > orthogonal to the release team requirements, as their timeline is > fully different (post-release vs pre-release). My proposal does not give terms for security status, because no such distinction exists in the Vancouver plan as published. If a plan that does involve different security states gets constructed, I'll be happy to attempt to coin words for them. However, the later posting from Martin Schulze seems to indicate that the only thing the security team really wants to have is a stable autobuilder system and REGULARity of the released source base. This implies to me that it probably won't be necessary to invent further categories for security support. -- Henning Makholm "Gå ud i solen eller regnen, smil, køb en ny trøje, slå en sludder af med købmanden, puds dine støvler. Lev!"
Re: procmail and Large File Support
On Wed, 2005-03-16 at 21:18 +0100, Ola Lundqvist wrote: > Hello > > On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: > > On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: > > > Hello. > > > > > > I have several reports saying procmail does not support mbox folders > > > larger than 2GB. Questions: > > > > OT here, but WTF are people smoking, to have 2GB mbox files? > > Some people tend to have really large inboxes. I have had a number of > customers that have several GB inbox. They tend to get quite a lot > of attachments (reports etc) and do not have the time to delete mail. File quotas will fix that in a hurry. > It will grow quite fast. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "Give a man a fish, you feed him for a day, teach him to fish, he gets mad at you for making him have to work so hard." signature.asc Description: This is a digitally signed message part
Re: procmail and Large File Support
Hello On Fri, Feb 25, 2005 at 07:45:47PM -0600, Ron Johnson wrote: > On Sat, 2005-02-26 at 00:53 +0100, Santiago Vila wrote: > > Hello. > > > > I have several reports saying procmail does not support mbox folders > > larger than 2GB. Questions: > > OT here, but WTF are people smoking, to have 2GB mbox files? Some people tend to have really large inboxes. I have had a number of customers that have several GB inbox. They tend to get quite a lot of attachments (reports etc) and do not have the time to delete mail. It will grow quite fast. Regards, // Ola > -- > - > Ron Johnson, Jr. > Jefferson, LA USA > PGP Key ID 8834C06B I prefer encrypted mail. > > LUKE: Is Perl better than Python? > YODA: No... no... no. Quicker, easier, more seductive. > LUKE: But how will I know why Python is better than Perl? > YODA: You will know. When your code you try to read six months > from now. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arch-specific packages and the new SCC requirements
John Hasler <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG writes: > > The Debian Hurd project has another category that should be excluded > > because they are kernel-specific. (The current list on the web page is > > update, makedev, ld.so, modconf, modutils, netbase, pcmcia-cs, procps, > > ppp, pppconfig, setserial. > > Pppconfig is not kernel-specific. It's just a little Perl program that > edits some PPP files. While I have never tried it, I see no reason why it > wouldn't work on Solaris or BSD. > > I'm quite surprised that the Hurd still doesn't support PPP. pppconfig is for the ppp package, which is kernel specific, and Hurd ppp support needs to be a totally different way. Supporting PPP is a very low priority. Which isn't the point; the point is that the "ppp" package is kernel-specific. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 04:35:24PM -0800, Thomas Bushnell BSG wrote: ... > Now one major question is: are these chosen by self-perpetuating work, > or are they chosen by the DPL, or by someone else? Does the DPL have > the power (where the Constitution doesn't say otherwise) to appoint > additional people to perform these tasks (even over the objection of > the incumbents) or remove people from them? ... When the proposed Constitution was being discussed, I asked Ian if positions like ftpmaster, release manager, etc. should be specifically mentioned. His reply was that they were delegates, which suggests that the answer is "Yes." Regards, Bob -- _ |_) _ |_Robert D. Hilliard<[EMAIL PROTECTED]> |_) (_) |_) 1294 S.W. Seagull Way <[EMAIL PROTECTED]> Palm City, FL 34990 USA GPG Key ID: 390D6559 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arch-specific packages and the new SCC requirements
Thomas Bushnell BSG writes: > The Debian Hurd project has another category that should be excluded > because they are kernel-specific. (The current list on the web page is > update, makedev, ld.so, modconf, modutils, netbase, pcmcia-cs, procps, > ppp, pppconfig, setserial. Pppconfig is not kernel-specific. It's just a little Perl program that edits some PPP files. While I have never tried it, I see no reason why it wouldn't work on Solaris or BSD. I'm quite surprised that the Hurd still doesn't support PPP. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not make gratuitous source uploads just to provoke the buildds!
Andreas Barth wrote: * Matthew Palmer ([EMAIL PROTECTED]) [050313 01:05]: On Sat, Mar 12, 2005 at 03:12:12PM -0800, Steve Langasek wrote: Er, packages *do* eventually get built; they just don't get built in any kind of FIFO order. Er, no. Unless there's some sort of aging process (not yet described in the threads here) which will result in an extra package called zappa in section x11 from eventually being promoted above a package aardvark in section admin, it is entirely possible that package will never be built. All it requires is for the rate of new packages entering the queue before zappa to be equal to or greater than the rate of packages leaving the queue due to having been built or removed. If that happens for a too long period, we might consider such an architecture to be too slow to keep up, and will eventually discuss about kicking it out of the architectures we wait for testing migration at all, or even kicking it out of testing at all. Not waiting for such an arch has happened and might happen again. I think it makes sense to shorten the list of arches we wait upon for testing migration, but I fail to see the usefulness of removing an arch from testing. You may not see the usefulness of testing, but I run production servers on it because there are just too many packages that are too old and buggy or not available in the old stable release. Yes, I've only used i386 and PPC, but that should not exclude that functionality from the users of those architectures that are not as popular (even if you need a log scale to see their relative popularity). Mike
Re: status of buildds?
Hi,
Thomas Bushnell BSG:
> I was speaking specifically of porter uploads; my discussion is about
> the specific case of s390 complaining that they can't do their porting
> work (which includes simply compiling packages) because the w-b admins
> won't add whatever buildd. My point is that porters already have all
> the authority they need to build and upload packages.
I'm not disagreeing with you. It's not even that difficult to bite the
bullet and install Hercules, if no handy s390 machine happens to sit in
your basement (and triple your power bill).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: Key management using a USB key
Eric Dorland wrote: An arguably more secure approach would be to use a cryptographic smart card in a usb key form factor with OpenSC. Unfortunately integration with ssh and gpg is lacking at this point, but I hope to be able to do something about that post-sarge (ssh has support but doesn't compile it in, and gnupg support will come with gnupg 2.0). gnupg 1.4 (as in sid) supports OpenPGP cards like the one I'm presently using (bought from g10code). The form factor is Chipcard-Reader+Chipcard, but it's there. Kind regards Thomas -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, Mar 16, 2005 at 12:09:08PM +1000, Anthony Towns wrote:
> Ola Lundqvist wrote:
> >>- the release architecture must have N+1 buildds where N is the number
> >> required to keep up with the volume of uploaded packages
> >Sane.
> >>- the value of N above must not be > 2
> >Testing related. I do not really understand why this is a problem but
> >somebody may be able to tell.
>
> Uh, no, it's not testing related at all. By the time packages are
> considered for testing, it's completely irrelevant how or where they
> were built.
Thanks for the information. I picked that up from some other thread of
this discussion. And I should have put a '?' after testing related. :)
> The reason for the N = {1,2} requirement is so that the buildds can be
> maintained by Debian, which means that they can be promptly fixed for
> system-wide problems, and which means access to them can be controlled,
> rather than opening up users of that architecture to exploits should a
> random disgruntled non-developer have access to the machine and decide
> to abuse it, eg.
Sounds reasonable.
> >>- the Debian System Administrators (DSA) must be willing to support
> >> debian.org machine(s) of that architecture
> >I assume people can help with this too, or?
>
> Doing DSA work involves more than having root on a random box on the
> internet. It's a specific task, not something that every developer is
> already doing under a different title.
I can understand this, but I still think that people may be able to help
here. I think there are quite a lot of experienced developers/system admins
out there that can help with this. But you probably already know that.
> >>We project that applying these rules for etch will reduce the set of
> >>candidate architectures from 11 to approximately 4 (i386, powerpc, ia64
> >>and amd64 -- which will be added after sarge's release when mirror space
> >>is freed up by moving the other architectures to scc.debian.org).
> >I'm missing sparc here, but that is only me... But even if that one is
> >included the drop will probably help some.
>
> Personally, I'd like to see sparc, alpha and/or potentially arm and s390
> stick around as release architectures too; mostly that would require
> them to be actively maintaining their architecture and trying to compete
> with i386 for being better supported, which isn't something I've seen
> happen for years now. Which is disappointing, because sparc at least was
> beating the pants off everyone else (though still behind i386) a while ago.
>
> I haven't seen much evidence of hppa, mips, mipsel or m68k coming
> anywhere near balancing the cost/benefit tradeoff for sticking around in
> the release; but there are listed criteria now, if they're the
> architectures are that valuable, I don't see any reasons for porters to
> be complaining instead of demonstrating they can meet or surpass all of
> them, or mitigate any concerns anyone might have for the others.
>
> >>- there must be a sufficient user base to justify inclusion on all
> >> mirrors, defined as 10% of downloads over a sampled set of mirrors
> >This as stated before, probably a too tight limit. I think 10% of the
> >downloads if i386 is excluded is a better metric. :)
>
> 10% of downloads if i386 is excluded is about 0.5% of downloads. So, uh,
> no. powerpc's pretty consistently around 2%, ia64 and others are at 1%
> or below.
I may misunderstand the criteria here, or you misunderstood me.
If we do not calculate the downloads from i386, which I assume is the major
part ( like 90-95% ? ). The total amount of downloads is decresed with
about 90-95%. Ahh this is really tricky to explain. Math is better. :)
T := total downloads for all arches
I := total downloads for i386 arch
D := total downloads for all arches except i386 := T - I
i := total downloads for some other arch
If i/D > 0.1 then arch is accepted
if i/D < 0.1 then not
This rule is probably better than i/T as i386 is such a major portion of
the downloads. I do not think that any arch (more than i386) can pass
a 10% limit if i/T is used as measure.
I hope this was a bit more clear. :)
> >>- binary packages must be built from the unmodified Debian source
> >> (required, among other reasons, for license compliance)
> >This is a bit vauge. Is porting uploads possible?
>
> I don't understand why people are confused on this. If you want to
> upload a binary to the archive, you upload the source you used to build
> it as well. If you needed to modify the upstream source, your patch is
> included in the .diff.gz. If the package was already in the archive, you
> mail the patch to the maintainer, and if it's urgent, do an NMU.
>
> It's not anything subtle.
I think people may (at least I do) think about the possibility to upload
arch specific source uploads. I do not really think that is a perfect
solution but it may help in some specific circumstances. But ...
on the other hand it will cause a lot of problems with the curre
Re: status of buildds?
Matthias Urlichs <[EMAIL PROTECTED]> writes: > Hi, Thomas Bushnell BSG wrote: > > > The Developer's Reference contains the procedures for binary NMUs. > > The BinNMU procedure covers the "a binary was built incorrectly and I can > fix it without touching the source" situation. Third-level Debian version > numbers and all. > > What we're talking about here, however, is "a binary wasn't yet built at > all because the buildd didn't yet get to it", i.e. a Porter Upload, > section 5.10.2. Thanks for the terminological clarification. I was speaking specifically of porter uploads; my discussion is about the specific case of s390 complaining that they can't do their porting work (which includes simply compiling packages) because the w-b admins won't add whatever buildd. My point is that porters already have all the authority they need to build and upload packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
Hello
On Wed, Mar 16, 2005 at 03:27:27PM +0100, Matthias Urlichs wrote:
> Hi, Rob Taylor wrote:
>
> > Do you think it might be better have a trusted builder keyring, with
> > strict rules on what makes a trusted builder (it seems rather a
> > different set of issues to that addressed by the DD criterion)?
>
> That makes sense -- but only if Debian switches to source-only uploads.
Why is source-only uploads needed for this?
Regards,
// Ola
> --
> Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
>
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
--
- Ola Lundqvist ---
/ [EMAIL PROTECTED] Annebergsslingan 37 \
| [EMAIL PROTECTED] 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
